Initiating a java external task

Can you initiate a java program from the external task's command attribute ?

Is there an example that demonstrates this ?

Find more posts tagged with

Comments

Migrateduser

sure. You just need a command v="..." that calls the program, passing it any needed args. You will likely need to use absolute paths for the java runtime and the program file.

And you can even use openapi to do your callback from inside the java program, if needed.

However, the startup time for the JVM is high, this might not be a good idea performance-wise.

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

Adam Stoller

For an external task you can execute anything that can be called from the command line, read command line arguments, and that can - at the least - be able to execute CLTs (such as iwcallback).

Normally the problem with trying to run a Java executable directly is that there are so many things you need to put on the command line, like CLASSPATH settings and such, that it become unwieldy to do so directly from the WFT. Instead, using a "thin" batch file (Windows), shell script (Unix), or Perl script (both) wrapper around the Java program will make it much easier to implement.

Does that make sense?

--fish
(Interwoven, Curriculum Development)

conmgmt

The java program I mentioned in the thread will be running on another box.
If I call the perl script from the external task's command attribute, can this perl script call the java program on another box? How would I do that.
Also, what perl module do we need to import in order to call java programs?

Migrateduser

Ah. Well, that's more complex.

If the other server allows remote shell commands, you could use rsh to invoke the java program using an externaltask. But few organizations allow rsh anymore.

You could write a cgi script on the TS server, put it in iw-home/httpd/iw-bin (required location), and have it, when called, either redirect to the other server, or use a frame or an SSI include directive to access the other system. This assumes the other server either has a CGI wrapper program you can call to envoke the Java program, or a servlet engine running your program as a JSP.

All things considered, pretty kludgy. It would be best if you could get the Java program onto your TS server.

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

akalve

We are trying to execute java code from wokflow external task with the following command....

<command v="<command v="/space/.../test.ipl"/>
test.ipl has a system command to execute a shell script as follows....

system("/bin/sh", "process_xml.sh")

process_xml.sh sets the classpath and executes a java program.

When we execute the perl script, test.pl from the command line the process runs fine.
When we execute this through workflow, we get a java coredump.

We also tried to execute the java program from the workflow external task as follows....

<command v="/usr/java/bin/java -cp ./space/.../java:/space/xalan-j_2_4_0/bin/xalan.jar:/space/xalan-j_2_4_0/bin/xml-apis.jar:/space/xalan-j_2_4_0/bin/xercesImpl.jar /space/...java/ProcessXML xml2dcr"/>

Looks like it does nothing....

any ideas/suggestions ?

Migrateduser

You said, "we get a java coredump." I am guessing that you mean a Java stack trace. What does that message tell you is the problem? Does it say class not found?

Also note:

1. Your workflow shouldn't have
<command v="<command v="/space/.../test.ipl"/>
You should instead have
<command v="/space/.../test.ipl"/>
This is probably just an error in your email message.

2. If all your Perl script is going to do is execute a Bourne shell script, there is no need. You could just invoke the shell script directly from the external task's command.

3. When you write something like
system("/bin/sh", "process_xml.sh")
you are making an assumption the the script is in the current working directory. It is safer to use a fully qualified path. Ditto for "./space" in your classpath.

Brinko Kobrin
Interwoven Staff Engineer

conmgmt

1. You are right...it was just an error in the email ...
our command looks as follows....

<command v="/space/.../test.ipl"/>
(its a fully qualified path)

2. We are using the perl script to execute a bourne shell script because, the shell script executes a java program, does a few things such as checking for existence of error log file and based on the error file's existence, sets a status flag, which we are passing back when the ipl code returns. This status code is what we want to use in our callback and determine the next step.

3. We are using fully qualified path.

Regarding the core dump, it gives a segmentation dump, no java dump.

We have tried several options such as calling java directly from the <command> such as ...

<command v=java -cp fully-qualified-classpath fully-qualified-path/ProcessXML>

None of the options work. It would be nice if you have a sample worflow external task code script that calls a java program.

fuzzy

did any get one back to you about getting the java call working?
it would be nice if you could post some info if you have resolved the issue since I am sure many others will be doing this as well.

Edited by fuzzy on 02/12/03 01:27 AM (server time).

Migrateduser

We are using Java for all ExternalTask processes on this project. At the last two projects we used .NET.

I would recommend wrapping the calls to Java with...a Perl script. That way your Java home directory, etc. can be set dynamically. And you can also dump the STDOUT/STDERR to a log file, to find out what errors may occur. I also use the same class for all ExternalTasks - I only have one class with a main() method and I pass which externaltask processes I want to execute to it on the command line. So your actual v argument might be more like

v="IWHOME/iw-perl/bin/iwperl IWHOME/custom/bin/CommandWrapper.ipl generate validate submit deploy email"

I have some documentation on this and even code I could share if anyone is interested.

As far as invoking classes on remote machines, I don't think that is specific to TeamSite so I would consult general Java documentation for that.

Someone made a comment about being able to use OpenAPI if you do this - but I don't think so. It seems that most OpenAPI stuff requires a username/password or session ID, which I don't want to store anywhere. For JSP you can use OpenAPI, but I don't think you should for ExternalTask logic. So I had to write my own API that wraps calls to the command line tools.

There was another comment about performance. It may take a while to start the JVM, but I think all in all it is faster than Perl if you are doing anything significant. And the strong typing and object-oriented aspects, compiled code, and modern development environment is worth it. Plus, that startup cost is minimal/negligible - users don't generally care how many milliseconds an ExternalTask takes - they care how long it takes to bring up the templating window.

Interesting article about Java at http://developers.slashdot.org/article.pl?sid=03/02/09/1347215&mode=thread&tid=108 - not sure how true it is.