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

Java or PERL

System

Hi All,

Is it possible to code all the DCTs and PTs using only JAVA?
I have a team which is very much proficient in JAVA and they don't have skills in PERL.

Can we code DCTs, PTs, Workflow scripts, OpenDeploy scripts using JAVA?

We will be using Teamsite 5.5.2. on Solaris.

Thanks,
Ravindra

Find more posts tagged with

Comments

Adam Stoller

I believe the answer is "no" - or "not easily". Most of what you mentioned (DCTs, PTs, Workflow scripts [I read as WFTs?], OpenDeploy scripts [I read as deployment configuration files]) are primarily XML with hooks inserted to allow embedded code.

Keep in mind however - that I, personally, am somewhat Perl-biased and have not done any significant coding in Java so my answers are limited by experience and what I believe I've heard/read through both internal and public forums (such as this)

DCTs allow script sections for FormAPI - which defaults to javascript as the programming language. I believe you may be able to specify a different language for the script element, but I'm not sure how easy (or efficient) it would be to encode java there - perhaps someone else who's tried it can provide more experienced information in that area.

DCTs also allow you to specify inline scripts - which could be use to lanuch Java [CLT-oriented] programs - but again, I believe that all the baggage necessary to specify a Java program (classpath specifically) make this an unwieldy route to take.

I believe that PTs are similar in that respect with the major difference being that the default language is Perl by way of <iw_perl> tags. Again, I think it may be possible to use other languages - even by way of using Perl as an API between the PT and the Java program - but I would imagine that the performace is not too great.

WFTs provide the template_script element for embedding Perl code - again, you could use Perl as an interface between the WFT and your Java code, but ...

Externaltask and cgitask scripts could be written in Java - but again you need to specify all the classpath information when doing so - chances are you'll need a wrapper script (either in Perl or some other relatively simple language (bourne shell or C-shell derivitives, Windows batch files, etc.) to act as a simple layer to allow you to put all that information into the script rather than trying to encode it all with the command attribute inside the wft. Cgitask scripts are probably the most open to being written in Java at this time, but you would have to do your own parsing of the command line arguments and make a number of calls (either through OpenAPI or system calls to CLTs) in order to access the workflow elements and callback to the workflow engine).

OpenDeploy configuration files don't allow for any embedded scripting (Perl or otherwise) - so the only place this would come into play would be in terms of DNR scripts - which again would require the classpath information and would be run in an essentially CLT oriented manner.

The one place where Java is the prescribed language would be for OpenDeploy 5.6 (and beyond) with respect to the OpenDeploy Adapater Framework (see Appendix A in the OpenDeploy Administrator's Guide for more details).

Having said all that - I believe that work has been, and continues to be done regarding making Java and/or language-independent interfaces to the various products and product features. I'm not sure where things stand right now with those efforts (as I said, I don't do much Java programming myself), so feel free to keep asking in these forums or talking to your local Interwoven Sales and/or Support contacts to get more information.

My personal feeling is get someone on your team to pick up a copy of O'Reilly's Programming Perl - and have them sift through it for a day or two (as nerdy as it sounds, it's actually a fun read) - and I think they'll find it a particularly useful tool to have in their bag-o-tricks and relatively easy to use in all of the above situations...

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Fish,

Thanks a lot for your in-depth analysis and comments.

I am not very much comfortable with the idea of using PERL if we can leverage on the JAVA expertise we have. But I understood the reasoning you have made. I have to think about the options available and make my decision.

Thanks for your feedback.

Suggestions from others on this regard are welcome.

Regards,
Ravindra

Demo.pdf

MattP

Ravindra-
Your not alone. Many organizations have Java developers, and many don't want to code in perl. From what I have heard the app is moving towards more and more Java. From an app standpoint, the next release will not use any CGI and will be java based. I remember hearing that workflows will eventually not use perl any more either. There are other users on this forum that have worked for clients that request as little perl as possible.

I guess the position I would take is, do as much as you can with as little perl as possible. There are a lot of out of the box workflows you could start with, and it seems like the WF use the most perl. Get in touch with your account rep to see a roadmap for the app.as it relates to Java support.

Matt

Matthew Petitjean
BOC Group
Murray Hill, NJ 07974 USA

case01_SO040500009_Sample.txt

case01_SO040500009 for product control.pdf

Migrateduser

For Workflows, you may want to check out the new modular workflows, which allow you to do some basic customization without writing any code at all.

Migrateduser

Note that to connect to Interwoven services using OpenAPI you have to specify a SessionID or a username and password. Since the Java program is usually running on the TeamSite server and I generally don't want to store/pass information that should be secured I have Java call the Interwoven command line tools rather than OpenAPI methods (since I want to be able to use the same code whether it is a workflow externaltask calling the method or a JSP acting as a custom menu item or other custom URL, when the SessionID is available).

You can get by with very little Perl but you will probably end up with some (even if it just calls Java). I would recommend that whatever Perl does get coded be in a format that looks like Java - for instance use Perl modules extensively, use if instead of unless, always comment what special symbols like $. or $$ mean, etc. One of the things I don't like about this is that you end up with Java code and Perl code that does the same thing - such as a method to call a command line tool (you will probably want to modularize at least this in both Perl and Java).

Anywhere you want to embed logic - such as in a .wft, a .tpl, a .dct, or a CGI (custom menu item, etc.) you can call the Java binary on the command line passing a class that has a main function (or however you can call a Java program on the command line). My current project has a requirement for as little Perl as possible and I think it has been quite successful - actually one of the best Interwoven implementations I have worked on (largely do to the strong typing and class system). There is a performance impact every time you shell out to Java and you probably want to set up a Perl module to do this (and a Perl script to call at least one of the methods in the module) - to set up the environment (classpath, etc.), redirect the STDERR and STDOUT of the call to Java, log/trap errors/exceptions, etc.

If you want to replace the workflow instantiator CGI with a Java one I posted some code a while ago that uses the workflow engine to redirect to a custom JSP page that constructs workflow XML and uses OpenAPI to instantiate a job. Or you could embed a call to Java in a normal .wft using the Perl method described above but I would avoid that if you really want to go the Java route.

There is some documentation on one possible approach to an API class structure at http://www.cmsideas.com/javadoc/index.html - keep in mind this is my first real Java project and I kindof guessed at the task class/interface structure (I did do some analysis). Some of the classes you might want to look at are CMSFile (representing a file in a workarea - should be more generic to include files in staging and editions but I have found this isn't frequently needed), CommandLineInvoker and JobTask. These will at least give you an idea of some of the functionality you might want to incorporate. If you want to write job XML with Java instead of Perl/.wft, check the classes under com.cmsideas.interwovenapi.workflow - not all Interwoven functionality has been incorporated, but everything I have needed is there. I can also send you some documentation on using Java to call workflow externaltask processes if you are interested.

You can call Java from a DCT using inline calls and by embedding FormAPI callServer statements to JSPs or other Java URLs.

I think custom menu items need to be CGI scripts in IWHOME/iw-bin, but the script can simply return a redirect to the JSP/Java URL to the browser (I think if parameters such as the selected file need to be passed you have to construct a hidden form and post it). The way I found to specify the classpath for a JSP running under Interwoven's distribution of TomCat was kindof funny - I had to stop the servlet daemon, run some script in IWHOME/install to uninstall the service, then modify the script to include my classpath and run it to install. And every time I update the classes I have to restart TomCat (it seems to keep my classes in memory). I haven't spent enough time on it to know if what I'm doing is the right thing, but it at least works. The version of Java that ships with TeamSite is pretty old - I couldn't get it to work with current XML parsers so I had to replace IWHOME/tools/java1.3 with a new SDK for the JSPs to work. There may be a better way - a properties file that points to the JDK, or a script such as the daemon installer, and I am not sure it is supported but again it at least works. I know you're not supposed to use the Interwoven TomCat, but the stuff I am doing is pretty lightweight - doesn't seem to require another TomCat installation (and I'm not sure you can install two versions of TomCat on one machine? Since there is JAVA_HOME/CLASSPATH/whatever to worry about?).

I have code examples of most of this, but it is now pretty specific to my current project. If you can tell me specifically what you want to do I can send you some examples.

Anybody else that is doing this or has any information, whatever insight you could provide would be greatly appreciated.

TableRowsTogether55.ssd.zip

24422.pdf

fjvelasco

Hi all

What about using Java in the new TS 6.0?

Migrateduser

Not sure if this was meant for me but I have no development experience in 6.0 and I haven't found any clients using it even for new projects. I imagine it's very much the same as 5.5 as the backend is still the same, but with the newer and future releases I believe there is even less reason to use Perl.

fjvelasco

Thanks, I imagine that Interwoven will make accessible Java like Perl in the next version.

Thanks again.

gzevin

in TS 6 there is a new Content Services SDK. and there are some examples. it is supposed to supersede the Opan API, but I am struggling to imagine that there is something at the moment thst can substitute the vast perl API that exists at the moment.

and john is right - the backend is still 5.5.2 - so not much has changed. At teh launch of TS 6 I heard that in 6.5 even the workflows will be Java-based (it means goodbye perl!

), but as usual I would take thses words with a pinch of salt

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU