nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can External Tasks be written with the CS SDK

Bill Klish

TeamSite 6.5
Windows 2003

We are starting out fresh with a brand new install and want to write all of our code using Java instead of Perl. I have been playing around trying to get an external task to work using the CS SDK, but unlike the perl WFworkflow and WFtask modules, there is no way to get a CSWorkflow or CSTask without first establishing a CSClient (which assumes I have the username/password or a session string). In another post I have going the getClientForTrustedUser looks promising, but before going down that road, I am curious if I am missing something else here.

I am trying to call a Java Application (simple class with main argument) from an external task command attribute. I am using the JRE provided with TeamSite (iw-home/tools/java/bin/java) to launch the program. The following parameters are sent to the task:

arg 0 - job id
arg 1 - task id
arg 2 - area vpath
arg 3 - attached file 1
arg 4 - attached file 2
arg 5 - attached file 3
....

Within the task I investigated the System properties to see if I had a session string to use, but found nothing. There is no easy way to get the environment settings like $ENV in perl, so I decided to post here before spending a lot of time trying to code something to search this out.

So, does any of this information live somewhere that the Java class has access to (in the environment) or should I use the getClientForTrusted user routine? Or, is it not even possible to do this in java?

The user that is coming back from System.getProperty("user.name") is SYSTEM, which is not the user defined in the WFT for this task. So, to get the user name correct, we would have to do a task.getOwner if I could get a task object. Also, this makes me think that any files that are touched/created, etc. by this task will be owned by user SYSTEM, instead of the user running this task.

As I think more about this, I will have no way to know what role the user is either. I will just know the name of the user executing the external task. So, the only thing I could think of is to scan the roles files to find where they are, but that seems like a kludge to get this to work.

Find more posts tagged with

Comments

Johnny

You should have a generic PERL stub that actually executes the java app with a pre defined set of params... that could include the user id, session (if there is a session in the $ENV.. never checked myself), taskid and possibly jobid and workarea.

You should ignore the file list args that get passed in. Retrieve them via the task object.

The fact that you are on windows might be a problem as all external tasks are running as SYSTEM and not the user specified in the job. I'm not sure what this means for getClientForTrustedUser

In the end I would really review what you're trying to achieve by using Java exclusively..
cgi tasks definitely, but external tasks may just not be worth the hassle compared to PERL.

John Cuiuli

frame.JPG

frame.zip

Bowker

Actually I'm doing exactly what you want.

I have my external tasks executing Java code directly to perform all my external tasks using CSSDK.

Here is a piece of code that may help.
<pre>
if (args.length < 3) {
System.out.println("usage: ... userid jobid taskid");
} else {
userId = args[0];
jobId = Integer.parseInt(args[1]);
taskId = Integer.parseInt(args[2]);

props = new Properties();
props.load(new FileInputStream(strServerPath + "\\config\\" + propertiesFile));

csFactory = CSFactory.getFactory(props);

csClient = csFactory.getClientForTrustedUser( username, null, Locale.getDefault(), application, null );
</pre>

A couple of notes.
1) The role is passes as 'null' since the getClientForTrustedUser will use the highest role the user is authroized for. However, in 6.7 (?) the "roles" concept is changing so don't worry too much about that.
2) The issue on "system" owning the files. Yea - that's still an issue that should be cleared up in 6.7.
3) If you are using CSSDK for on-line activities and use the getClientForTrustedUser routine there are some issues there too dealing with file ownership.

Dan Bowker
Northern Trust
Web Publishing Technology

Bowker

Bill,

I notice you are in the Chicago area. On the afternoon of June 16th I'm hosting a User Group meeting downtown. I don't know if you made my presentation at GearUp, but I'll be re-presenting it there with a demo of how we're using CSSDK. There should be time for questions and answers.

Dan Bowker
Northern Trust
Web Publishing Technology

Bill Klish

I did attend your presentation at Gear Up. I should be around on the 16th. I need to respond to your post (on my to do list)

Bill Klish

Some follow up questions.

1) Ultimately, this will be running on unix, so I would like to have the actual usernames or those assigned in the task. Since, I haven't had a chance to test this on a unix box, I am curious what the username will come up as. What is the value of your username in the code snippet you provided?

2) What is application in the getClientFromTrustedUser routine?

3) Are you invoking these external tasks using the jre provided with TeamSite or your own?

Bowker

Very good question. I forgot one minor detail....I've added the username to the parameter list being passed in. When I build the workflow, I add the workflow owner's id to the run statement in the external task..

The application is anything you want. It (as I understand it) is not currently used.

I don't know - I believe it's my own. I'm useing 1.5 for all my development and I believe TS is 1.3.

Dan Bowker
Northern Trust
Web Publishing Technology

prasanthj

Hi,
can u please post the code snippet of the wft or the job description file where u call the java application from external task?
Please forgive me for the ignorance.... I am new to teamsite, and am doing some research on CSSDK

Thanks,
Prasanth

vash.txt

Bowker

Here is the task I use for sending an e-mail to the original author in the event an approver rejects the changes. I strongly suggest putting in a timeout option in the event your java code fails.

<externaltask description="My Test Job" name="Reject Notify Author" owner="****\yyyyy" retry="f" start="f">

<areavpath v="/contentManagement/main/content/WORKAREA/development"></areavpath>

<successors><successorset description="Author"><succ v="Author"></succ></successorset></successors>

<command v="java -Djava.library.path=e:\apps\interwoven\teamsite\cssdk sendNotification ****\yyyyy"></command>

<timeout v="+000001"><succ v="Author"></succ></timeout>

</externaltask>

Dan Bowker
Win 2k3 Server Enterprise SP1
TS 6.5/SP2
CSSDK 2.5/SP2
OD 6.0.2/SP1

prasanthj

Hi Bowker,
I have tried that and its working perfectly... Thank You.
Now, Where can I find the System.out messages that I generate from the Java program that I execute from <command v=java ...../> ?
Can u put some lights on this? My aim is to debug the program which I am running, and see to what extend it is getting executed.

Thanks in advance

Prasanth

dazzlad

Use a logging package like apache.commons.logging to write to disk.

Darren.

Bowker

Look in the big bucket next to your server....you know, the bit bucket Smiley Wink

We have not found where they go. I created our own log files to write to. Error messages are hard to capture. I had a lot of "try {} catch {}" code to capture errors.

Maybe IWOV can shed some light on where error messages end up.

Dan Bowker
Win 2k3 Server Enterprise SP1
TS 6.5/SP2
CSSDK 2.5/SP2
OD 6.0.2/SP1

Bill Klish

The only way to see your system.out messages would be to run the your command v=java... line in a command window, or the unix shell. You should be using a standard logging framework within your Java code, such as log4j or commons-logging to record debug, info, error, etc. messages. I don't believe that interwoven is capturing your System.out messages anywhere. The only places I would look would be your iwtrace.log file or servletd_out.log (windows) or servletd.log (unix).

prasanthj

The Simple thing which I did was, to catch all the exceptions and write it to a fileoutputstream.
with minimal overheads, the issue was solved.