Require confirmation of procedure for call-server() to java servlet...

Hello all,

TS 6.7.1 SP1, Win 2K3

I'm new to the forum and could use some confirmation that I'm on the right track with FormAPI, Java, and TeamSite. I haven't been able to find specific TS documentation with regards to integration with and applications of java. So I've been reading between the lines, and trying to put it all together...

With FormAPI we're moving towards implementing java server calls instead of perl and I'm hoping that the community might confirm some initial java implementation investigation that I've pieced together from here and there.

Interwoven Servlet Engine is installed within TeamSite6.7.1 here - C:\iw-home\servletd\

We should place FormAPI servlets within C:\iw-home\servletd\webapps\ If we create C:\iw-home\servletd\webapps\example.jsp we should then be able to use call-server("http://localhost:8080/example.jsp"), parameters, true); to call the java servlet, run logic, populate and return javascript to the FormAPI...

Because we're within the same domain it's not necessary to do any sort of cgi script to call the java servlet...

Can someone confirm that I'm on the right track? I've read through (a few times) the FormAPI Developers docs, Forms Publisher Dev Docs.. Is there specific documentation somewhere? Thank you in advance.

Find more posts tagged with

Comments

Keywil

TS 6.7.1 SP1, Win 2K3

1 - Interwoven Servlet Engine is installed within TeamSite6.7.1 here - C:\iw-home\servletd\

2 - We should place FormAPI servlets within C:\iw-home\servletd\webapps\ If we create C:\iw-home\servletd\webapps\example.jsp we should then be able to use call-server("http://localhost:8080/example.jsp"), parameters, true); to call the java servlet, run logic, populate and return javascript to the FormAPI...

3 - Because we're within the same domain it's not necessary to do any sort of cgi script to call the java servlet...

Can someone confirm that I'm on the right track? I've read through (a few times) the FormAPI Developers docs, Forms Publisher Dev Docs.. Is there specific documentation somewhere? Thank you in advance.

Also has anyone implemented Struts framework within Interwoven Servlet Container to handle CallServer requests through struts actions?

Keywil

anyone?

We're planning a Teamsite implementation (6.7.1 SP1) on Win2K3 and would like to handle IWDatacapture.callServer() calls with java instead of perl.

I have experience with Struts and figured that implementing a java struts framework for our callServer functions (and perhaps) WorkFlow external tasks might make it easier to organize and reuse classes and code.

Since struts is a fairly popular java framework I would have thought that someone has done this already.

I read somehere that Struts1.2 doesn't seem to work well with teamsite. Struts 1.1 should be used. Can someone confirm this?

I realise that the scope of my thread has changed - my apologies if this thread is now in the wrong category. Administrators please feel free to move properly position the thread.

I'm hoping that someone can point out any 'gotchas wrt Struts and Teamsite before we go down that path.

nipper

That lack of answers should give you the feedback you were looking for.

Could it work ? Possibly. Should it work, again possibly. Is it common nope. Is it a great idea to diverge from the common approaches. That is a business decision you need to make.

What is the reason for struts instead of Perl ?

Keywil

Thanks for the reply Nipper.

I've read a number of posts that seem to indicate that Interwoven is leaning towards Java in the future and our shop has java expertise. Perhaps I'm wrong about Interwoven and Java..

regarding Struts VS Perl - I'm sure you would agree - there are more than 1 way to skin a cat. Take a 100 developers and set them out to solve a problem and you might have a 100 different solutions. Some would separate logic and presentation, some would merge them together, some use a database, some use xml flatfiles.. etc.. etc.. it is difficult to create consistency of code because there are no rules.

If you use a common framework rules then at least the file structure would be consistent across projects.

Because struts is a commonly used MVC framework it would (arguable) be easier and quicker for new developers (assuming they knew struts) to become productive because they would already know the locations of action classes and presentation templates etc.. It might be easier to manage many different implementations in the future.. by swapping developers in and out of projects as needed. The java code base and structure would be consistent across projects...

That was my thinking...

Keywil

Clarification : Since Struts is primarily used for web applications I figured we might be able to use it to organize java code wrt callServer() functions but maybe that can't be done within the Interwoven servlet container...

I guess I'll do some more reading and digging... If we really wanted to do callServer() with Struts maybe we'd have to do this within a Tomcat installation (configured to use some other port than 8080) and use callServer() to call there and return the javascript..

IWDataCapture.callServer("http://localhost:tomcatPortOtherThan8080/someaction.do", parameters, true);

I'll keep reading...

ISCBorisB

Clarification : Since Struts is primarily used for web applications I figured we might be able to use it to organize java code wrt callServer() functions but maybe that can't be done within the Interwoven servlet container...

I guess I'll do some more reading and digging... If we really wanted to do callServer() with Struts maybe we'd have to do this within a Tomcat installation (configured to use some other port than 8080) and use callServer() to call there and return the javascript..

IWDataCapture.callServer("http://localhost:tomcatPortOtherThan8080/someaction.do", parameters, true);

I'll keep reading...

Hth

Keywil

Thanks for the reply Boris, that's very helpful. I've got a lot to chew on and read. I appreciate it.

It was my understanding (mind you without having read the CSSDK documentation yet) that CSSDK was for providing web services across domains. If your java was on the same server/domain as TeamSite then CSSDK would not be required. A straight call would suffice... I'll read that documentation.

ISCBorisB

Thanks for the reply Boris, that's very helpful. I've got a lot to chew on and read. I appreciate it.

It was my understanding (mind you without having read the CSSDK documentation yet) that CSSDK was for providing web services across domains. If your java was on the same server/domain as TeamSite then CSSDK would not be required. A straight call would suffice... I'll read that documentation.

True, CSSDK supports both JNI and SOAP - but that's just transport. It's main purpose though is to expose some Interwoven
functionality as Web services. Client applications can be both local (running on the same IWOV host) or remote.