Richard Schilling wrote: >With the recent discussion on writing Java clients, I thought I would >mention that in the upcomming release of OpenEMed (www.openemed.net), >written completely in Java, we'll be releasing a client for GT.M. This >makes OpenEMed a client of the GT.M platform. And of course, our next >step after that is to work on getting OpenEMed to read the VistA data >set directly. > >Once we have OpenEMed integrated into the VistA platform, we'll be able >to make VistA a federated service on the network a-la the Java platform. > >Whether or not we use the higher level fileman functionality to read the >VistA global space is yet to be determined, but so far I've accomplished >what many seem to be asking for - a simple Java client that does >straight reading/writing of the MUMPS global space.
Very interesting. On the surface this sounds similar to some of Steve Zeck's initial work in making a Perl interface to GT.M. In the first level he defined a Perl module for implementing MUMPS data objects. These data objects represent MUMPS globals and have methods corresponding to all of the standard functions for working with MUMPS data. In the second level he has begun defining higher level objects that correspond to the data records from the fileman defined data structures. I think there is quite a bit of common work to be done in analyzing the functionality and devising a high level interface to it regardless of your approach and technology. For instance, a listing of what data elements are involved in different reports, interfaces, and data entry forms, how those relate to functional areas and menus, and how they map to data elements from other systems. >I found quite a bit of difficulty in working with the RPC broker code >due to the aforementioned reverse engineering problem. And, all of the >source code distributed with the existing Delphi components has been >unnecessarily complicated for what we've needed to do so far. Documentation and discussion of the difficulties and complications and other substantial findings could be helpful to others considering reverse engineering or re-engineering with other languages or approaches. >The GT.M >server side code I've written is pretty well self-documented, and can be >downloaded from the OpenEMed CVS repository now (look in >src/tools/gov/lanl/Database/GTM for OEMEDSRV.m). I looked at it a little. I think I found some minor errors where you are converting search filter operators to MUMPS in function convertOperator http://cvs.sourceforge.net/viewcvs.py/openmed/OpenEMed/src/tools/gov/lanl/Database/GTMSearchFilter.java?rev=1.4&view=auto ">=" (greater_than_or_equal_to) is not a standard MUMPS operator (at least in GT.M 4.4). The equivalent is "'<" (not_less_than) "<=" (less_than_or_equal_to) is not MUMPS. The equivalent is "'>" (not_greater_than) An equivalent for "in" might be "[" (contains), except with the operand order reversed. How far have you gotten in generating MUMPS search conditions? >Richard Schilling >Cognition Group, Inc. >Seattle, WA > --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
