FORUM PLAN UPDATE
Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.



Mar 12, 2016, 11:20 AM
453 Posts

JAVA Scheduled Agent vs LotusScript

  • Category: Other
  • Platform: All
  • Release: 9.0.1
  • Role: Developer
  • Tags:
  • Replies: 10

In an application that I'm working on I have the following case.

1. in a native Notes application under certain conditions the app create a document and write it to the new XPages application.

2. In the XPages application I will have an Agent that runs say once an hour that picks up any of these documents and performs a fairly complex process on these documents.

Now my first thought is to write the agent as a Scheduled LotusScript agent (what I have typically done).

So my question is would Best Practices be to write this as a LS Agent or a JAVA Agent?

I have written several JAVA Beans but am far from a good JAVA developer, but am willing to give it a whirl. 

Does anyone know if there is a bit of a demo/tutorial as a starting point for a scheduled JAVA Agent?

Mar 12, 2016, 12:51 PM
110 Posts
I'm not sure if there's any difference between NORMAL Java Agent and Scheduled Java Agent

Other than one is triggered manually and the other will run automatically based on how you set it but maybe the following can help:

http://www-10.lotus.com/ldd/fixlist.nsf/8d1c0550e6242b69852570c900549a74/6bb91173537a6e5385256cb80055a7f1

I've not yet gone into Java in my XPages application nor have I written a single managed bean but if I can achieve the thing that I want in my agent using LotusScript I'll just use that. For Java agent I might have to concern about recycling when looping through documents, memory leaks and all those things.

Unless of course if you have some specific cases which is achievable only through Java such as using some third party .jar files then Java might be the only way.

Mar 12, 2016, 1:31 PM
453 Posts
I have several Java classes already deffined

and if I was able to access them from the scheduled JAVA Agent that might shorten the development time, but in my bit of investigation to this point I'm having trouble with this.

In my other JAVA code I would just do this:

In my other JAVA code I would type Utils. and would get a dialog of all of the public classes in the class Utils. So the JAVA Agent is doing something different. Utils.sysOut just formats the text and executes a System.out.println so it can't get much simpler.

I can actually do everything I need to in LS but thought I might extend my JAVA skills by doing this, spent a couple hours on it at this point, probably could have had the LS written and running by now. :-)

 

Mar 13, 2016, 3:36 PM
589 Posts
My advice

I would avoid Java agents.  As Baxter says because you can't easily use any Java written in the Xpages side, then there' very little point in me using Java Agents - with one exception.  If you know LotusScript I'd just stick with that as much as possible.  I think it comes down to this - do you want to re-code needed functionality in LotusScript - or do you want to Code your XPages Java in a manner that you can export to jar and then re-import it to Java agents, and keep that in sync etc.  I just don't think it's worth it and also I think there could be some memory leaks possible with Java agents.  That's my impression at least.

Now here's the one exception.  I've NOT done this yet but have heard of this working well for some people.

Create a Java agent that hits a URL.  On a schedule.  Problem solved.

What URL?  Well an "XAgent" of course.  :)

Now you have "Scheduled XPages Agents".

 

Dave 

Mar 14, 2016, 7:02 PM
298 Posts
counterpoint...
Depending on what you are doing in the agent there is better support in Java for stuff like XML handling.

Plus, who remembers LotusScript anymore?  I keep putting a semi-colon at the end of each line!

Howard
Mar 15, 2016, 12:03 AM
453 Posts
I would really like to have access to my java classes

My LS has gotten a little rusty, and I to keep throughing in the semicolon --very annoying.  Is there a bit of a primer on XAgents out there anywhere?

From some of what I have found I'm not sure if one can call the XAgent from a scheduled background java agent.  

In my application I'm going to process a number of document and create several related structures. None of it would have any user side. 

Mar 15, 2016, 11:24 AM
589 Posts
umm

Bill,

 

There is no user side to XAgents.  That's the whole point of them.  There's no rendering back to the user.  John Jardin on today's webinar just talking about a scheduled java agent calling XAgent.  It is usable for these needs.

 

 

Mar 15, 2016, 9:02 PM
110 Posts
What about DOTS?

Can it be considered as a scheduled Java agent? From what I've found so far, it seems like it's a better way (best practice?) if you want to go the Java path.

http://www.notesin9.com/2012/12/04/notesin9-093-introduction-to-dots/

http://lotusnotus.com/lotusnotus_en.nsf/dx/experimenting-dots-task-vs.-java-agent.htm

Of course your admin need to install the OpenSocial component (if you're on 9.0.1) but if it can satisfy your requirement then it's at least better than the XAgent method (which is more of a hack?).

Mar 16, 2016, 12:21 AM
453 Posts
I was going to watch the webinar but was tied up.

Will have to check it out. 

Mar 22, 2016, 1:55 PM
589 Posts
DOTS

Baxter,

 

In theory DOTS would be a preferred alternative I think.  BUT I'm pretty sure that running DOTS for custom services is technically not supported by IBM.  So it exists to do what they want, but you'd be using it at your own risk.  I THINK the Collaboration Today template on OpenNTF has some things that run under DOTS.  Might be a good starting point if you want to go down that path.

 

 

 

 


FORUM PLAN UPDATE
Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.