Re: [Hardhats-members] new Java client for VistA.
Richard Schilling wrote: >> 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 haven't seen Zeck's work. The basic MUMPS interface is a Perl Module called Db-GTM available from CPAN. http://search.cpan.org/~szeck/Db-GTM-1.27/GTM.pm It's worth a look if you are at all interested in accessing MUMPS data from other programming languages. I would like feedback from anyone who gives it a serious look or actually uses it. It is designed to be natural and easy for Perl programmers to work with without sacrificing any of the speed or functionality that MUMPS programmers take for granted. >But, one thing I decided early on was to >start with a very simple interface - from the bottom. We've already got >the top-down design elements (object models, table models, VistA data >models, etc...) handled, really. Do you actually have a representation of the VistA metadata in your code already? I didn't see this or perhaps I didn't recognize it when I saw it. Admittedly, I took a very quick look at the code, but that was exactly the sort of thing I was most interested in finding. >What I've focused on was a very simple >bottom-up approach: send a string to the server over a socket and get a >response back. > > >> >> 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. > >Correct - OpenEMed's design takes this approach with respect to >interfaces. This is what CORBA and the CORBAMED standards give us. The That would be great if true, but I suspect we are not talking about the same things. I was thinking of the functionality and data in VistA. I already have metadata driven web interfaces in M2Web that expose the data and metadata in JSON, HTML, and XML formats. Perhaps these could be used as a starting point for a higher level interface to CORBA? >other tasks - identifying discrete data elements/reports/etc... has >received a lot of attention. There's more documentation on that then >anyone has time to read. ??? Please point me to where this essential part of the design of practical applications in VistA is clearly layed out. > >Also, some of the challenges anyone faces in laying an object model on >top of a mumps data store are: > >* handling the fact that the MUMPS data store is a b-tree structure: >with all the "SQLesque" table design structures out there - including >those in VistA (e.g. fileman) - there's some extra work in mapping >things properly. What do you mean by a "proper" mapping? >The irony is that the Greystone data store b-tree is a >natural fit for object-oriented data models, but storing data like that >wasn't a design goal of the original VistA developers. Fileman was >created, rather, to give developers and users kind of a "file systems >view" of VistA. It's easier to export VistA data into flat files right >now than to build up a proper object heirarchy as a result. ESI Objects >addresses this nicely, but I'm not at the point yet where I can spend >the time to take advantage of it. > >* limitations mumps places on data storage: mumps references need to be >created properly, and mumps commands have a limit of 255 characters, etc... No they don't. Most current MUMPS implementations can store thousands of characters in a single data value and can execute command lines of thousands of characters also. Data stored in GT.M globals is limited by the block size (4KB, 8KB, 16KB, etc) of the datasets used for individual globals. There is a configurable limit (default=2KB) on the size of executable strings, but string length for local variables is currently 1MB. >> 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. >> > >I don't get the impression that there's an interest by the RPC Broker >creators to have it reverse engineered. it's pretty obvious at the lack >of documentation, isn't it? > >It's a valid design choice on their part - just use the Delphi >components. In my case my customers haven't requested that I use >Windows based Delphi components, and it's not an option to build a
Re: RE: RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.)
Okay, thanks. - Original Message - From: Todd Berman <[EMAIL PROTECTED]> Date: Sunday, October 23, 2005 6:56 am Subject: RE: RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.) > On Sun, 2005-10-23 at 00:36 -0400, Roy Gaber wrote: > > Understood. > > > > What is it that you are looking for? The application data can > be had by > > looking at the RPC code on both the client and the server. You > can view it > > using a sniffer as well. > > Roy, > > His point is not that he is incapable of figuring it out, nor that > it is > particularly difficult (I hope, because it really is not). His > point is > that without documentation, you can't promise that code will always > work, there can be subtle (and not so subtle) changes that will break > his work. > > At least, thats how I read the emails, I could be wrong. > > > --Todd > > > > --- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > ___ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.)
On Sun, 2005-10-23 at 00:36 -0400, Roy Gaber wrote: > Understood. > > What is it that you are looking for? The application data can be had by > looking at the RPC code on both the client and the server. You can view it > using a sniffer as well. Roy, His point is not that he is incapable of figuring it out, nor that it is particularly difficult (I hope, because it really is not). His point is that without documentation, you can't promise that code will always work, there can be subtle (and not so subtle) changes that will break his work. At least, thats how I read the emails, I could be wrong. --Todd --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.)
Understood. What is it that you are looking for? The application data can be had by looking at the RPC code on both the client and the server. You can view it using a sniffer as well. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Schilling Sent: Saturday, October 22, 2005 8:15 PM To: hardhats-members@lists.sourceforge.net Subject: RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.) Roy Gaber wrote: > TCP I'm not talking about the networking protocol. I'm talking about the data protocol used at the application level - the RCP Broker message structure itself. The VA docs make it clear that RPC Broker communication details were meant to be hidden to all software clients that are not a) another VistA server, or b) Delphi clients or c) internal VistA and/or operating system processes. Again, It's a smart move on the VA's part because it gives the development team quality control on client communications. And in all fairness the the need for non-VA people to write other types of clients may not have been a high enough priority so far. In any case the exact details of RPC Broker messages are a mystery to those outside the RPC Broker development team. See the "RPC Broker Systems Manual," v-1.1, page 2-17: "RPC BROKER MESSAGE STRUCTURE" - partly reads as follows: The basic RPC Broker merssage structure consists of the following: * A header portion (which includes the name of the remote procedure call). * The body of the message (which includes descriptors, length computations, and M parameter data). Also, look in the "RPC Broker Technical Manual," Version 1.1; Patch XWB*1.1*40 (Page 13-2): "INTERFACES" No *non*-VA products are embedded in or required by the RPC Broker software, other than those provided by the underlying operating systems. (emphasis theirs) Richard Schilling > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Richard > Schilling > Sent: Friday, October 21, 2005 4:51 PM > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] new Java client for VistA. > > Nancy Anthracite wrote: > >>You mentioned the Broker documentation, and I know you are not referring > > to > >>this particular documentation, but I was poking around the Broker > > components > >>while attempting to use Delphi a few months back and the Help files with > > them > >>were really wonderful. It was like a friend was right there trying to > > help > >>me out and was doing a bang up job of it. > > > From the end user standpoint and delphi developer standpoint it's > great. No question. But I haven't seen any documentation yet on the > actual protocol used on the wire yet. Have you run across this? > > Richard Schilling > > > > --- > 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 > > > > --- > 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 > --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RCP Broker Message Structure (was Re: [Hardhats-members] new Java client for VistA.)
Roy Gaber wrote: > TCP I'm not talking about the networking protocol. I'm talking about the data protocol used at the application level - the RCP Broker message structure itself. The VA docs make it clear that RPC Broker communication details were meant to be hidden to all software clients that are not a) another VistA server, or b) Delphi clients or c) internal VistA and/or operating system processes. Again, It's a smart move on the VA's part because it gives the development team quality control on client communications. And in all fairness the the need for non-VA people to write other types of clients may not have been a high enough priority so far. In any case the exact details of RPC Broker messages are a mystery to those outside the RPC Broker development team. See the "RPC Broker Systems Manual," v-1.1, page 2-17: "RPC BROKER MESSAGE STRUCTURE" - partly reads as follows: The basic RPC Broker merssage structure consists of the following: * A header portion (which includes the name of the remote procedure call). * The body of the message (which includes descriptors, length computations, and M parameter data). Also, look in the "RPC Broker Technical Manual," Version 1.1; Patch XWB*1.1*40 (Page 13-2): "INTERFACES" No *non*-VA products are embedded in or required by the RPC Broker software, other than those provided by the underlying operating systems. (emphasis theirs) Richard Schilling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Schilling Sent: Friday, October 21, 2005 4:51 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] new Java client for VistA. Nancy Anthracite wrote: You mentioned the Broker documentation, and I know you are not referring to this particular documentation, but I was poking around the Broker components while attempting to use Delphi a few months back and the Help files with them were really wonderful. It was like a friend was right there trying to help me out and was doing a bang up job of it. From the end user standpoint and delphi developer standpoint it's great. No question. But I haven't seen any documentation yet on the actual protocol used on the wire yet. Have you run across this? Richard Schilling --- 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 --- 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 --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] new Java client for VistA.
TCP -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Schilling Sent: Friday, October 21, 2005 4:51 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] new Java client for VistA. Nancy Anthracite wrote: > You mentioned the Broker documentation, and I know you are not referring to > this particular documentation, but I was poking around the Broker components > while attempting to use Delphi a few months back and the Help files with them > were really wonderful. It was like a friend was right there trying to help > me out and was doing a bang up job of it. From the end user standpoint and delphi developer standpoint it's great. No question. But I haven't seen any documentation yet on the actual protocol used on the wire yet. Have you run across this? Richard Schilling --- 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 --- 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
Re: [Hardhats-members] new Java client for VistA.
I agree - it's very simple. The first thing I did was sniff the RPC protocol on the network. I did that a few years ago. But the problem is that without the protocol properly documented by the RPC Broker team I can't make any assumptions at all that what I'm seeing come across the network in a given IP session represents all possible cases. And I don't feel comfortable making guesses at the semantics of the control characters and separators that come in the transmission. It's kind of frustrating in a way because the protocol is so simple but writing my own protocol and client/server is much safer than risking downtime because the RPC Broker protocol changes and I don't have documentation to rewrite my code. As soon as I am comfortable with the documentation that's there I'll make an effort when I have time to write my code to the RCP Broker spec. Richard Schilling Todd Berman wrote: On Fri, 2005-10-21 at 13:51 -0700, Richard Schilling wrote: Nancy Anthracite wrote: You mentioned the Broker documentation, and I know you are not referring to this particular documentation, but I was poking around the Broker components while attempting to use Delphi a few months back and the Help files with them were really wonderful. It was like a friend was right there trying to help me out and was doing a bang up job of it. From the end user standpoint and delphi developer standpoint it's great. No question. But I haven't seen any documentation yet on the actual protocol used on the wire yet. Have you run across this? Honestly, Ive never seen a simpler protocol over the wire. It is pretty painfully easy. The harder issue is to figure out what the data returned is, basically "What does piece 12 of this string do?". But the over the wire stuff is very trivial. I believe I implemented it in about an hour. --Todd --- 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 --- 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
Re: [Hardhats-members] new Java client for VistA.
On Fri, 2005-10-21 at 13:51 -0700, Richard Schilling wrote: > Nancy Anthracite wrote: > > You mentioned the Broker documentation, and I know you are not referring to > > this particular documentation, but I was poking around the Broker > > components > > while attempting to use Delphi a few months back and the Help files with > > them > > were really wonderful. It was like a friend was right there trying to help > > me out and was doing a bang up job of it. > > From the end user standpoint and delphi developer standpoint it's > great. No question. But I haven't seen any documentation yet on the > actual protocol used on the wire yet. Have you run across this? > Honestly, Ive never seen a simpler protocol over the wire. It is pretty painfully easy. The harder issue is to figure out what the data returned is, basically "What does piece 12 of this string do?". But the over the wire stuff is very trivial. I believe I implemented it in about an hour. --Todd --- 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
Re: [Hardhats-members] new Java client for VistA.
Nancy Anthracite wrote: You mentioned the Broker documentation, and I know you are not referring to this particular documentation, but I was poking around the Broker components while attempting to use Delphi a few months back and the Help files with them were really wonderful. It was like a friend was right there trying to help me out and was doing a bang up job of it. From the end user standpoint and delphi developer standpoint it's great. No question. But I haven't seen any documentation yet on the actual protocol used on the wire yet. Have you run across this? Richard Schilling --- 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
Re: [Hardhats-members] new Java client for VistA.
You mentioned the Broker documentation, and I know you are not referring to this particular documentation, but I was poking around the Broker components while attempting to use Delphi a few months back and the Help files with them were really wonderful. It was like a friend was right there trying to help me out and was doing a bang up job of it. On Friday 21 October 2005 04:31 pm, Richard Schilling wrote: > 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 haven't seen Zeck's work. But, one thing I decided early on was to start with a very simple interface - from the bottom. We've already got the top-down design elements (object models, table models, VistA data models, etc...) handled, really. What I've focused on was a very simple bottom-up approach: send a string to the server over a socket and get a response back. > 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. Correct - OpenEMed's design takes this approach with respect to interfaces. This is what CORBA and the CORBAMED standards give us. The other tasks - identifying discrete data elements/reports/etc... has received a lot of attention. There's more documentation on that then anyone has time to read. Also, some of the challenges anyone faces in laying an object model on top of a mumps data store are: * handling the fact that the MUMPS data store is a b-tree structure: with all the "SQLesque" table design structures out there - including those in VistA (e.g. fileman) - there's some extra work in mapping things properly. The irony is that the Greystone data store b-tree is a natural fit for object-oriented data models, but storing data like that wasn't a design goal of the original VistA developers. Fileman was created, rather, to give developers and users kind of a "file systems view" of VistA. It's easier to export VistA data into flat files right now than to build up a proper object heirarchy as a result. ESI Objects addresses this nicely, but I'm not at the point yet where I can spend the time to take advantage of it. * limitations mumps places on data storage: mumps references need to be created properly, and mumps commands have a limit of 255 characters, etc... > 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. I don't get the impression that there's an interest by the RPC Broker creators to have it reverse engineered. it's pretty obvious at the lack of documentation, isn't it? It's a valid design choice on their part - just use the Delphi components. In my case my customers haven't requested that I use Windows based Delphi components, and it's not an option to build a Java applicaiton around them anyway. ESI objects is a valid choice in lieu of Delphi components - if you have the time to work with that product. >>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/D >atabase/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? This is a very early release of the code - perhaps too early. I'm working through the issues you mention issues and many others you'll find. One challenge here is that OpenEMed is designed to work well with SQL like language structures such as the "LIKE" command. I have some more work to do to get my code to function under the OpenEMed design model as it should. Richard Schilling Cognition Group, Inc. Seattle, WA --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, do
Re: [Hardhats-members] new Java client for VistA.
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 haven't seen Zeck's work. But, one thing I decided early on was to start with a very simple interface - from the bottom. We've already got the top-down design elements (object models, table models, VistA data models, etc...) handled, really. What I've focused on was a very simple bottom-up approach: send a string to the server over a socket and get a response back. 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. Correct - OpenEMed's design takes this approach with respect to interfaces. This is what CORBA and the CORBAMED standards give us. The other tasks - identifying discrete data elements/reports/etc... has received a lot of attention. There's more documentation on that then anyone has time to read. Also, some of the challenges anyone faces in laying an object model on top of a mumps data store are: * handling the fact that the MUMPS data store is a b-tree structure: with all the "SQLesque" table design structures out there - including those in VistA (e.g. fileman) - there's some extra work in mapping things properly. The irony is that the Greystone data store b-tree is a natural fit for object-oriented data models, but storing data like that wasn't a design goal of the original VistA developers. Fileman was created, rather, to give developers and users kind of a "file systems view" of VistA. It's easier to export VistA data into flat files right now than to build up a proper object heirarchy as a result. ESI Objects addresses this nicely, but I'm not at the point yet where I can spend the time to take advantage of it. * limitations mumps places on data storage: mumps references need to be created properly, and mumps commands have a limit of 255 characters, etc... 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. I don't get the impression that there's an interest by the RPC Broker creators to have it reverse engineered. it's pretty obvious at the lack of documentation, isn't it? It's a valid design choice on their part - just use the Delphi components. In my case my customers haven't requested that I use Windows based Delphi components, and it's not an option to build a Java applicaiton around them anyway. ESI objects is a valid choice in lieu of Delphi components - if you have the time to work with that product. 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? This is a very early release of the code - perhaps too early. I'm working through the issues you mention issues and many others you'll find. One challenge here is that OpenEMed is designed to work well with SQL like language structures such as the "LIKE" command. I have some more work to do to get my code to function under the OpenEMed design model as it should. Richard Schilling Cognition Group, Inc. Seattle, WA --- 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
Re: [Hardhats-members] new Java client for VistA.
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
Re: [Hardhats-members] new Java client for VistA.
Very interesting! On Oct 19, 2005, at 3:55 PM, 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. 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. 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). Richard Schilling Cognition Group, Inc. Seattle, WA === Gregory Woodhouse [EMAIL PROTECTED] "Good acts are like good poems. One may easily get their drift, but they are not rationally understood." --Albert Einstein --- 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
[Hardhats-members] new Java client for VistA.
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. 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. 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). Richard Schilling Cognition Group, Inc. Seattle, WA --- 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
