Survey: Who has been successfully leveraging CIS Java UPoC?

HealthPartners uses an interface built on Java RMI calls to pass messages to an external pharmacy application.  The Java portion was coded and is maintained by our web team.

We converted all our TPS procs to Java UPOC about 2 years ago.  Overall we’ve found improved productivity using Java TPS.

We did not find any enhanced or degraded performance; our measurements of performance indicated the bulk of the processing time and work relates to the recovery database (disk access, etc.).

We use Eclipse IDE and SVN for source editing and version control, which helps us resolve most syntax and basic logic errors before testing.  With strict typing (as opposed to Tcl’s loose typing) we eliminate a lot of uncertainty in our build, particularly when revisiting a proc we haven’t touched in 6-18 months.  

We were able to build some utility classes to allow code re-use.  In Tcl we would simply string multiple procs together, but then we were moving back and forth between the Cloverleaf client and/or NetConfig and the proc editor to see all the processing for a given interface.  With Java (using Eclipse) we’re able to trace everything that happens to a message in the same place without sacrificing code reuse.

One particularly tricky interface required us to put at least 2 minutes delay between messages for the same patient (otherwise the receiving system would re-order adds and deletes).  We ended up using Java collections to create essentially separate “queues” for each patient as they came in (and remove the queue when the last message for a patient was processed to avoid memory leaks).  A Java timer would trigger the upload of messages using the Apache Commons HTTP client libraries to upload to the web server.  It has some imperfections, but the upload is a lot cleaner and more stable than when we used Tcl and curl; we didn’t implement the separate queues until after moving to Java, so I don’t have a comparison there.

Where I have a choice I will always use Java UPOCs over Tcl and Xlate.  The biggest things for me were the strongly typed language and the well supported IDE.

When talking about choosing Java UPOC over TCL and Xlate, does that mean you use raw routes, and choose Java code instead of TCL?

But you still use TRXID determination and multiple routes and details?

Why is Eclipse testing better, as far as testing code? Because you can see multiple panes open at the same time, while Cloverleaf tabbed windows requires another click to make the testing window visible?

I guess most of the work we do in Cloverleaf is coding and testing, but still, to some degree you have to flip back and forth between Eclipse and Cloverleaf because Eclipse does not have the (NetConfig) protocol  configurator, or any of the HL7 or hierarchical formatters or alert configurators.

While I have used Java in SeeBeyond, no one else here at the hospital has Java coding experience so we have to be careful about maintainability.

Yes, using the Java code instead of Tcl for raw routes.  We do use TRXID for nearly all our route determination, though we have a few places where we route based on more than message type, and we use Java procs there.

Eclipse has syntax highlighting, code completion, and can look up standard functions from the Java API.  I also find the Java API to be more consistent than Tcl’s, but that’s probably a personal preference.  It’s also useful to be able to quickly switch to the definition of a function call to see what’s being done.  

Our Tcl procs before were all single body with no function or methods and code reuse was only done by chaining multiple procs together.  This isn’t a restriction of the language, but it was all I saw from the various people and consultants represented in the code base.  Our move to Java helped us shed some of that legacy difficulty, and it makes it very easy to find every piece of processing relating to, say, RXR-2 in VXU messages.  We still switch windows, but we spend less time switching between them and more in the same place.

Maintainability is the big reason not to switch from what you know and do, and I wouldn’t recommend it to everyone for that reason.  But I’ve really liked it, and when I have a choice I’ll pick Java.  Often I won’t have a choice, and that’s okay.

Yes. We are using java upoc (TPS class) for using JDBC to access data from IBM iseries.