The way to go is a C wrapper for the Java API - most efficient way etc.... You need to watch you don't "leak" though.
As an alternative I would recommend putting a free-standing wrapper around a Java listener process running as a service (daemon) and having it listen on a socket stream. The UniVerse process which wishes to make a call to the CC verifier then makes a socket call to open a socket stream to the listener. The listener in turn spawns a thread to deal with the received connection request and resumes listening for the (next) call. Meanwhile ..... The spawned thread handles the request via direct Java API and returns the result on the socket data stream before terminating the thread. This is a neat approach (if I say so myself) and I've used it in the past (or very similar ones anyway) to create TAPI and ATAPI interfaces into U2 with a full client/server API in GCI (before native socket support). The "Listener process" approach allows you to add different API interfaces as other daemons and just have them listen on a different port. That way no change to the BASIC programs is needed, just a port number in a configuration file needs editing. You can add other CC services fairly easily as requirements change. Hope it helps Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: 11 January 2006 18:28 To: [email protected] Subject: [U2] UniVerse call to Java class Thanks to Wendy, JayJay, and Kevin who responded to my previous posts about Java. Your replies, and the docs, all indicate that the U2 Java API only accommodates calls TO UV or UD databases, or Basic subroutines. >From the code examples (found, thanks Wendy), and docs, it appears there is no UV call to a Java class, from within a Basic subroutine. In this credit card project, the UV host is actually the client, calling a Java API which communicates with a Linux host running Live Processor software (by Retail Decisions). The LP server then passes the Auth request or settlement to the actual credit card processor across a frame. We can run the Java client (a testing shell script) from the Unix command line and test the connection and run Test scenarios. That all works. What I need help on is some elegant way to make the client call from UV Basic, hopefully passing/receiving some arguments/parameters. The client is multi-threaded so the connection is persistent for the life of each call, returning a Transaction ID and various response codes (decline/approval & why, etc.). Thanks for taking the time. I'm thankful for this community. TIA. R. Baker Hughes UniVerse Programming Mouser Electronics, Inc. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
