Integration Server and Java

[mcarlson]

See the attached. I think it came from WmSamples once upon a time.

Be sure to add java.io.* to the Imports section on the Shared tab.

Mark

[Gert Versteeg]

Thank you very much Mark. This is very helpfull.
It looks like it has been directly derived from the example for usage of the dir$ function in vbasic.
best regards
Gert

[mcarlson]

Yeah, that's it. No one knew how to do this in Java, so they looked at Visual Basic examples to figure it out. Good thing we have Bill Gates to show us how to do complicated tasks like list the files in a directory... sorry that's folder now that we have Windoze.

[ramchalluri]

WMSAMPLES package as it is named should not be used as is. This package contains some sample services for developers to get started. This package is not supported by any means. The same goes for PSUtilities pacakge.

The service you are asking (PSUtilities.file:listFiles) is avialable in PSUtilies. My recomendation is to get an idea of what they are doing and implement your own service in your own utils package.

You can download this package (if you don't have it) from Advantage.

[ychang]

There's a common notion about using Java when dealing with "complex algorithm" or "performance bottlenecks". I think the definition of complex and slow is highly dependant on the developer (with a small 'd'). There's so many things easily accomplished with Flow, but not obvious to beginners, that a lot of people feel that it's "complex". As for performance, when you're not using built-in facilities effectively, Flow can be slow. As example:

• Extracting data from XML with qualifiers (like IDOC or EDI), or other complex extractions. Slice through the XML with queryXMLNode.
• "deep" copy of documents/records. A lot of times "implicit looping" takes care of it.
• Lengthy string manipulations. pub.string:replace with RegEx makes mincemeat of strings.
• Code conversions with complex patterns. pub.string:lookupTable with, again, RegEx!
• Catching exceptions with custom Java wrapper (seen quite frequently). Use Try-Catch blocks.
• File I/O. A big can of worms actually, but seems to be a security blanket for a lot of people. Can substitute with FTP'ing to localhost. There's so many pit holes with file I/O and FTP that it deserves a separate post.
• Generating HTML/XML reports. pub.report has decent facilities.

Given the problems I've seen from the above list (and a lot more), I'm really skeptical when I see our developers (or others) writing Java codes during implementation. Performance problems is solved most often by effecient coding (in Flow), not writing Java.

OTOH, I make extensive use of two packages (written mainly in Java) provided by wM -- PSUtilities and OpenSSH. I just don't want to write my own! I think I'm averaging one Java service per 3 projects.

[Gert Versteeg]

Hi ramchalluri,
thanks for your advise.
What the service does is not to complex.
Files are placed is the local file system by a client that ftp's them in.
(wonder why the developers did not use the standard wm interface for this; but I inherrited the package and the decision is not documented; it is probably related to different applications that use this mechanism at our site)
and those file are processed by the application. In this particular case a webMethods service.
This service interrogates the file sytem for available files in a specified directory and then processes the files one by one. After processing the files are stored in a different place in the local file system.
Interrogation of the fiel system and move of the files is done by a java service.
Both functions could be done by usage of ftp functions to the local host (as mentioned in the next answer).

[Gert Versteeg]

Hi Ychang,
I cannot agree more. Usage of Java can never be a sollution for inefficient code. Years ago I programmed a PDP11 (an old computer system of a company called DEC ) mainly in Fortran IV. Sometimes we had performance problems (eveything should fit in 64 Kb of memory ) We choose assembly language (Macro 11) you win some; but you loose some to escpecially in maintainability.
With todays giga machines it should never be neccessary to use non-native tools like java in a flow inviromment.
Of course I know that java is the engine in webMethods, but usage of java for programming functionality thould not be neccessary.
By the way: if you reconsider the usage of the one java service that you wrote: was there really no other way?
--

[Varsha]

[quote=reamon]Yes, writing key services in Java can boost performance.

Why is that Java Services perform better than Flow Services ?
Are Flow Services converted to Java Classes by IS ?

[reamon]

1. It does seem ironic that we're talking about Java execution being faster than something else given the history of concern about the relative slowness of Java due to it being an interpretive run-time (JIT compilers and speedy CPUs have largely allayed those concerns). Java services are faster because FLOW services are more or less interpreted on the fly. Basically, an interpretive run-time is running on top of an interpretive run-time. Another speed advantage is gained by Java services if the JVM compiles them to native code.

2. No.

[pmarsteau]

Flow services are interpreted and at the bottom line converted to java code. So basically coding in Java will always be faster than coding in flow. My belief and my experience is coding in flow is suited for developers who do not have java background expertise. Any real java programmer will always code faster a service in java than in flow (that at the end result in java code). About readiness and debugging facilities, we do all of our coding, testing and debugging directly within eclipse IDE. Debugging is easier (and faster!) using eclipse using Developer IDE. Code is faster inline documented in Java code than using the Developer. You can badly code Java or code it the correct way, as you can "code" badly flow services or in the correct way. Handling exceptions in Java is way easier using Java than using TRY CATCH blocks in Flow (that are anyway handling underlying Java ServiceException).
In what I read in this thread I can buy no real arguments that would convince me to use Flow rather than Java, except if you cannot or do not know how to code Java efficiently.