Re: [U2] UniVerse call to Java class
Baker Hughes wrote: 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. I realize this doesn't answer your question, but have you considered cutting out the middleman in this scenario - meaning the LP software? The software vendor may also offer an XML web service gateway that will allow you to communicate with them directly from UV. They must have some kind of web service available that their own software is connecting to. We're in the process of going live with this kind of setup with Verisign, and the implementation was not very difficult. -John -- John Hester System & Network Administrator Momentum Group Inc. (949) 833-8886 x623 http://memosamples.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse call to Java class
On 1/11/06, Baker Hughes <[EMAIL PROTECTED]> wrote: > That's wild, a separate JVM for each thread? I thought it was been slow > to load but... > So, I just kicked off a runLPClientTest.sh and set the thread count to > 18. > Then from another session I did 'ps -eaf | grep java' > Only 1 process was spawned. Doesn't this mean just 1 jvm? I don't know what their Java code is doing, and I haven't seen your test script. I was cautioning you against executing "java" at the command prompt repeatedly as every time you do that, it creates a JVM. > They have a C API as well. Do you think that would be faster/thinner? > I see now, UV is much more prepared to do a C call, than a Java call. Problem solved. (There should be sample code in the same general area you looked for the other samples.) > In-house talent pool was leaning us toward the Java API. When all you have is hammer... ;) (Did you notice that I went straight for the Servlet/HTTP solution? To me... everything's a web service.) -- Wendy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse call to Java class
On 1/11/06, Wendy wrote: >I may have edited it out, but one question I had was, what kind >of volume are we talking about here? Five transactions an hour? A minute? A second? More? 300 authorizations an hour, max; 2 thousand a day, max. This is growing steadily though. >You do *not* want to do the equivalent of: >PCPERFORM "java com.exampleMyClass param1 param2" >either directly, or indirectly by calling a script that does the same thing. It's going to >create a JVM (Java Virtual Machine) every time. That won't scale at all. That's wild, a separate JVM for each thread? I thought it was been slow to load but... So, I just kicked off a runLPClientTest.sh and set the thread count to 18. Then from another session I did 'ps -eaf | grep java' Only 1 process was spawned. Doesn't this mean just 1 jvm? >I'm finding it hard to believe that a Java API is the only way to talk to the LiveProcessor >software _and_ that all you can do with the Java API is make a call to process a single >transaction. But assuming that's all true, I'd approach this one of two ways: They have a C API as well. Do you think that would be faster/thinner? I see now, UV is much more prepared to do a C call, than a Java call. In-house talent pool was leaning us toward the Java API. >I'd still lean towards a sockets-based solution. UV would use CallHTTP to talk to an >instance of Jetty or Tomcat running a little Servlet that picks up HTTP request parameters, >makes the call to the LP server, gets that response, and then sends a response back to UV. We are doing something like this now to perform an extended search on a webservice for parts lookup, but it seems rather slow. Maybe it's just the 492kz+ parts it's searching through. >I don't like this as much: Have UV write a record to a table with the transaction >information. From Java, with UOJ, constantly read records from that table, process the >transactions, and write back to it. Make sure you lock the records properly. This would be a single threaded solution? (1 phantom or cron to control) and require polling? (which means the next batch can't start until the last one ends) The reason I thought we should make 1 auth = 1 call is to immediately service each Auth request, as soon as CSR hits key to File order (or whatever trigger we invent in order taking process, though CSR will not be waiting, necessarily, for response. We close the sale whether/not Auth has been received, leave it to Credit to mop up later). >I don't see why you can't talk directly to the LiveProcessor software with CallHTTP or a >plain Socket, though. Their Java client has to be connecting somehow... The Java client is connecting with TCP to the LP software. Thanks for help, it's keeping the cranial juices flowing. -Baker --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse call to Java class {Unclassified}
Baker, > -Original Message- > From: [EMAIL PROTECTED] On Behalf Of Baker Hughes > Sent: Thursday, 12 January 2006 10:03 > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] UniVerse call to Java class > > It looks like the closest we can get to a Java call is either: > a) embedded shell command in Basic Sub call If you use something like ShellSentence = "MyShellScriptName -a ":ARG1:" -b ":QUOTE(ArgWithSpaces):" -X ConstantString" PERFORM "sh /c '":ShellSentence:"'" You can pass arguments on the command line. > b) 'Execute' a Voc pointer from Basic Sub that has a shell command >Does anyone have an example of this? >a & b don't offer easy way to pass arguments, do they? > > c) wrap the Java call in a C program and call that through the GCI > I guess I could just use their C API (after all the hair pulling to get > the Java API to run) > > A couple goals to guide methodology: > 1) Multi-thread capability, persistent until finished, 1 authorization = 1 call > 2) Speed, with desire to eventually make this 'on-line' authorizations >if responses are fast enough (in milliseconds) I doubt if the 'PERFORM "sh /c ... ' approach will scale above a very small level Hope this helps Mike > > Thanks to everyone for the corporate musings. > > R. Baker Hughes > UniVerse Programming > Mouser Electronics, Inc. > > > > from Gordon - > >UV has the GCI (General Call Interface) that allows it to > make calls to > > >external subroutines written in C, C++ and Fortran 77. > > > >P.S. I think we should add this functionality request to our > enhancement > >request list. Fortran 77? Does that even exist anymore? > I'm thinking > a > >Java interface would be much more in demand that a Fortran 77 one. > > Well said. > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse call to Java class
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: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse call to Java class
On 1/11/06, Brutzman, Bill <[EMAIL PROTECTED]> wrote: > I believe that there is a way to invoke a Unix command-line thing (program) > from within UniBasic. On UniData it's PCPERFORM. I may have edited it out, but one question I had was, what kind of volume are we talking about here? Five transactions an hour? A minute? A second? More? You do *not* want to do the equivalent of: PCPERFORM "java com.exampleMyClass param1 param2" either directly, or indirectly by calling a script that does the same thing. It's going to create a JVM (Java Virtual Machine) every time. That won't scale at all. I'm finding it hard to believe that a Java API is the only way to talk to the LiveProcessor software _and_ that all you can do with the Java API is make a call to process a single transaction. But assuming that's all true, I'd approach this one of two ways: I'd still lean towards a sockets-based solution. UV would use CallHTTP to talk to an instance of Jetty or Tomcat running a little Servlet that picks up HTTP request parameters, makes the call to the LP server, gets that response, and then sends a response back to UV. The Servlet container will handle threading, parsing the request and forming the response, etc. All you'll have to do is call request.getParameter(...) insert the Java code to talk to the LP server, and response.write(...). I think. I haven't done pure Servlets for a while. :) I don't like this as much: Have UV write a record to a table with the transaction information. From Java, with UOJ, constantly read records from that table, process the transactions, and write back to it. Make sure you lock the records properly. I don't see why you can't talk directly to the LiveProcessor software with CallHTTP or a plain Socket, though. Their Java client has to be connecting somehow... -- Wendy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse call to Java class
It looks like the closest we can get to a Java call is either: a) embedded shell command in Basic Sub call b) 'Execute' a Voc pointer from Basic Sub that has a shell command Does anyone have an example of this? a & b don't offer easy way to pass arguments, do they? c) wrap the Java call in a C program and call that through the GCI I guess I could just use their C API (after all the hair pulling to get the Java API to run) A couple goals to guide methodology: 1) Multi-thread capability, persistent until finished, 1 authorization = 1 call 2) Speed, with desire to eventually make this 'on-line' authorizations if responses are fast enough (in milliseconds) Thanks to everyone for the corporate musings. R. Baker Hughes UniVerse Programming Mouser Electronics, Inc. from Gordon - >UV has the GCI (General Call Interface) that allows it to make calls to >external subroutines written in C, C++ and Fortran 77. > >P.S. I think we should add this functionality request to our enhancement >request list. Fortran 77? Does that even exist anymore? I'm thinking a >Java interface would be much more in demand that a Fortran 77 one. Well said. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [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.). So, why don't you use the test scripts. Enhance them and then call them from uniVerse BASIC. I do that all the time for automated FTP data transfers for real-time dual database updating. If you need some pointers for command-line options, I'll be willing to help sans-fee, if it's cursory and not time-consuming. If you want the script written, I can do that, for fee. I've done that for others who needed help for picking up and passing to their database, the real-time data transfers. (that was an awkward sentence, almost like English is my primary language. Okay, it is; American English.) HTH Karl > > Thanks for taking the time. I'm thankful for this community. TIA. > > R. Baker Hughes > UniVerse Programming > Mouser Electronics, Inc. > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > -- karl _/ _/ _/ _/_/_/ __o _/ _/ _/ _/_/ _-\<._ _/_/_/ _/_/_/ (_)/ (_) _/ _/ _/ _/ .. _/ _/ arl _/_/_/ _/ earson[EMAIL PROTECTED] -- IT Director, ATS Industrial Supply, Inc. http://www.atsindustrial.com Toll-free: 800-789-9300 x29 Direct2Desk: 801-978-4429 Facsimile: 801-972-3888 -- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse call to Java class
I believe that there is a way to invoke a Unix command-line thing (program) from within UniBasic. --Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: Wednesday, January 11, 2006 1:28 PM To: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse call to Java class
I don't even know if this is possible as I'm not a C or Java programmer. UV has the GCI (General Call Interface) that allows it to make calls to external subroutines written in C, C++ and Fortran 77. It seems to me that you should be able to create a "wrapper" in C++ that would call the Java API and then return the data from the Java credit card software to the UV application. Again, I don't know if C++ can be made to "talk" with Java either. Just an idea, Gordon P.S. I think we should add this functionality request to our enhancement request list. Fortran 77? Does that even exist anymore? I'm thinking a Java interface would be much more in demand that a Fortran 77 one. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 01/11/2006 01:28:00 PM: > 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. [snip] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
