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; } } }

Workflow implementation with Java

Rogerok

Hi all:

I want to know did anyone write external task with Java and OpenAPI instead of Perl?

Find more posts tagged with

Comments

Migrateduser

If I recall correctly (and it looks like I do from browsing the javadoc), OpenAPI doesn't include a method for CallBack in the IWTask class. The one time I ever developed an external task in java was because we couldn't get the DB2 DBD to build on the perl included with 5.x, so we wrote the data extractor in java and wrote a wrapper for it to do the callback. If you wanted to do it all in java you could just have your code execute the iwcallback CLT with the proper arguments.

In fact - I just looked and it turns out that that is still what is happening under the hood in the perl module TeamSite::WFTask.

Migrateduser

I wrote workflow externaltasks in Java for a 5.5.2 project last year. They are now migrating from 5.5.2 to 6.1 and they are scrapping all the Java and moving to Perl.

One problem at that time was that OpenAPI required authentication information that Workflow processes running as SYSTEM on Windows could not provide. There may be a solution to this (authenticating by file), or you may be comfortable storing a password somewhere on the system, but we couldn't get it working and didn't want to store the password. We resorted to command line tools, which basically removed most of the value of OpenAPI (which I found pretty hard to work with - many lines to do almost nothing, but then I'm not really a Java programmer, and it also hides a useful error/debug messages, such as on create job). Since those Perl modules already basically wrap the CLTs (granted, the API is not complete, most subroutines have limitted options, some of the code is poorly written and documented and error control is almost completely missing), a custom Java API reinvents some parts of the wheel.

With either CLT calls or OpenAPI you will almost certainly need a custom API abstracting some of the details to make development easier and reduce the sheer custom code volume, but you have to maintain this API with each release. It works, but it's quite an investment. For instance, a class representing a file on the IFS as an object, providing some behaviors and properties, can easily exceed 5,000 lines (including comments). With a good API (and I highly recommend that if you go the Java route you invest heavily in API analysis and implementation), many development tasks become trivial and TeamSite is almost pleasant to work with.

There's a pretty serious problem here - for many organizations Perl is not appropriate tool for enterprise-class applications, but there do not seem to be any reasonable alternatives for either templating or workflow, even in 6.x. Don't get me wrong - I think Java and C# are the way to go for modern, web-friendly enterprise applications. There are numerous advantages (strong typing, finding syntax errors at compile instead of runtime, all the benefits of Java and true OO, etc.). I just can't find a way to make it cost-effective in TeamSite.