ClearHealth project compiles VistA to MUMPS-LESS web interface.
Fred Trotter
version of VistA working without MUMPS.
Apparently the strategy is to compile the MUMPS code to C, run it
through some extensive processing, and then it becomes available in a
fashion that can be called from php.
They are currently in beta in one hospital with this technology.
I know very little about it so I cannot field questions. For those who
are very interested, take a look at this post on the ClearHealth
forums:
http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
I am sure they might field questions from you on that same forum.
Interesting times :)
-FT
--
Fred Trotter
http://www.fredtrotter.com
Joseph Dal Molin
is simply awe inspiring :-)
J
Joseph Dal Molin
J.
> .
>
Nancy Anthracite
--
Nancy Anthracite
Chris Richardson
Roger A. Maduro
should have the same functionality as CPRS but running on a browser. I
don't any of the MUMPS code is changed.
Roger
rtweed
would want to learn it instead of junking it. A lot of people will be
busy quite happily learning Python right now, simply because Google's
App Engine requires it. Turn a Google or Yahoo onto the wonders of
Mumps and globals and the tide would turn for sure. Will it happen?
Probably not.
In the meantime, all you can do is be safe in the knowledge that most
of these efforts have been ultimately doomed to failure for one reason
or another. The amazing thing is that nobody ever thinks to do any
research into the many high profile casualties there have been over
the years, or consider the untold millions (or is that billions?) that
have been poured down the "replace mumps at any cost" toilet. Why
should their efforts be successful in the light of such grim evidence?
Shrug your shoulders, smile sweetly and give a knowing sigh...
Chris Richardson
That is not what they said. They said " a web-based version of VistA
working without MUMPS" and "the strategy is to compile the MUMPS code to C,
run it through some extensive processing, and then it becomes available in a
fashion that can be called from php." I believe that both GTM and Cache can
work with PHP just fine without having to be converted to "C". I would love
to see their data model and watch their performance stats. I have a pretty
good idea what those will look like. If they wanted to say that they were
just replacing CPRS, then they should say so. If they didn't replace CPRS,
they could still claim that CPRS runs without MUMPS right now (as long as
you don't expect any data to come with it). If I am not mistaken, GT.M is
already written in "C" or some other compiler and pretty well optimized for
the data handling model. Re-inventing MUMPS in C would be a trick, getting
scalability and performance would be a miracle. Say you could (by some
miracle), what would you be loosing? Access to the source code (it is all a
black box and the end user is kept at arms length from verifying the
operation of the code). The user is at the mercy of the vendor once again.
Is this a good thing? I don't think so. Where is the good here?
Interesting, but is it really necessary? What is wrong with MUMPS? I
have heard of such efforts to replace MUMPS for over 20 years. If all of
this effort to replace MUMPS was so easy, it would have been done already.
It isn't a matter of money, the DoD and the VA have spent gobs of money to
replace it. What is keeping them?
Joseph Dal Molin
based medicine and realize that the opportunity cost of chasing the next
software fad in health systems is measured in lives.
Joseph
> .
>
Roger A. Maduro
As I said, I've head some extensive discussions with the Clear Health
guys on this. They took at look at CAV Systems' MJSP
<http://mjsp.sourceforge.net/>. This is an open source toolset that
can be used to create rich HTML clients that can run on top of Mumps
applications. MJSP has been used by CAV Systems to create some
beautiful browser-based web apps for Mumps applications. I have seen
these demoed and seen the CAV guys write HTML code for the base Mumps
app on the fly. It's impressive. CAV Systems' code however (for the
web piece) is J2EE. You can read the sourceforge documentation to get
the details.
ClearHealth has been doing all their browser work using PHP. Thus they
either used the MJSP code that connects to Mumps to connect to the RPC
broker or developed similar code using MJSP as the model (I am still
not clear). Then they used PHP to render the web front end. What the
Clear Health people told me is that they have not touched the Mumps
code, so I don't know where that part comes from.
The idea here is to replace the Delphi code behind CPRS with an
Ajax/Web 2.0 framework.
At this point, I would say that David Uhlman or some of the Clear
Health guys will hopefully provide some more details. I think this is
a very significant development and hope that they continue working on
it.
Roger
st...@stevenowen.com
client as the next generation CPRS. That's why I'm putting together a
developer's virtual machine based on M/gateway's Enterprise Web Developer
platform. Write your methods on the mumps side, compile the php pages on
the mumps side, and output them to your webserver. Plus, it has custom tags
to make use of javascript toolkits like extJS.
Yeah, very cool stuff this web 2.0
Chris Richardson
I'm not at odds at all with rehosting CPRS as a thin client. The
coordination of the clients with the server is a major headache in the
field. The webification of VistA is the logical extension of the
technology, but if you read the statements being made, that was not at all
clear from their words. MUMPS never was to run on the client, but it is
very difficult to run CPRS without VistA and the RPC interface (or weblink
or any of the other technologies being brought forward) on the server.
I can't tell you the number of times I have seen people say, "CPRS is
great, but now if we could just get rid of that darned VistA" without
knowning that the power of the rendition of CPRS or a web interface is still
the VistA-MUMPS back end service. BTW, the idea of running VistA from the
web is not new, Jim Self and his folks at UC Davis have accomplished this
about 15 or more years ago.
Maury Pepper
www.clear-health.com/download/tepr-2008.pdf
One slide contains this summary:
● Web Based CPRS
● Possible Web Based ViewCentric
● Proven System, Excellent Record
● Ease of Web Based Systems,
especially over M stack
● End-to-end system with
scheduling and billing
● Inpatient or ambulatory
Compatible with CH Advantage
● M/CACHE to PHP/MySQL & C,
Modern Technology
● Compatible with HealthCloud
I don't know how to interpret the next to last point which refers to M/CACHE.
Roger mentioned CAV Systems and their Java library. They also have a product (not open source) called JUMPS which will convert MUMPS to Java + SQL. Perhaps ClearHealth has used this or considered using it.
st...@stevenowen.com
C...that seems a bit odd if they can access the mumps backend via MJSP
david...@gmail.com
discussion coming from us directly. I do not in any way want to offer
a general commentary on why some people want to use MUMPS or don't
want to, or X language is better than Y, I am not looking to instigate
a flame war or really say that what we are doing is a better or worse
approach from a technical standpoint than anything else. It is the
right approach for us. Additionally I need to make clear that this is
a preliminary announcement, we have moved beyond proof of concept but
there is still a lot to be done. We now have 2 beta sites we will be
rolling out over the course of the next 12-18 months while actively
seeking 1 or more additional sites.
What we are doing:
*Implementing a CPRS-like web based interface
*Breaking a live VistA server into static libraries and components
that can be utilized outside of a running GT.M instance or at-least a
continuously running instance
*Extracting datasets and so forth tied up in CACHE to be accessible in
other things including MySQL
*Integrating features that based on our market aren't present or are
underrepresented in a VistA/WorldVistA/etc installation with regard to
scheduling and X12 electronic billing.
*Enabling a lot of interfaces and integration points so that both data
and logic, that from our standpoint were difficult to work with in
VistA, are accessible using things like a PHP module and web services.
*The entirety of what we are going will be licensed under a feasible
combination of GPL and LGPL
What we aren't doing:
*Saying the M/Mumps/WorldVistA etc is good, bad or otherwise
*Saying we have a completed production ready system right now
*Saying it is trivial to get from where we are now to a completed
production system
*Building a web based front-end that uses RPC/etc to talk to a VistA
server
With respect to understanding the industry and the history of VistA we
aren't novices here, we are by most measure the largest open source
healthcare solution in patients, sites and dollars in the US. We
understand the engineering challenges. We understand that in the past
people have tried various other strategies and have failed. I am happy
to have fruitful discourse about what we are doing, I am not
interested in having a zealous back and forth about why we should or
shouldn't be doing this. If you disagree with our approach or think we
are crazy for x,y, or z that is absolutely your right and noted for
the record.
With regard to the "doomed to fail" comments, we are not naive and
have been doing complicated difficult things with Open Source with a
combined experience amongst are staff of more than 100 years. People
are welcome to their opinion but I think if you look at the life of
virtually any large open source project today it arose from a
situation where a lot of people said "doomed to fail". Linux, Apache,
MySQL, and PHP as well as many others have all, at times, had that
comment made about them and they now represent the most popular system
for each of their respective markets .
Our analysis of the market indicated that there were a lot of
institutions interested in VistA based solutions that for a variety of
practical reasons had difficulties integrating with the current
architecture, making customizations to the current architecture or
addressing needs in a different way than the current architecture can
reasonably provide for, that is our motivation for doing what we are
doing.
I expect that the first open source licensed code bundle we will be
releasing is still several weeks away. As the discussion indicated
there are a lot of technical challenges to what we are doing and we
want to first release to be reasonably accessible with regard to its
ease in compiling and getting running a basic version of the WebVistA
system. We do have some screenshots and such we will be releasing as
time permits.
I hope this clarify to some extent where we are and I am happy to
response to any inquiries beyond that. Thanks.
-David Uhlman
Customer Happiness Guru & CEO
ClearHealth Inc.
K.S. Bhaskar
you use Kevin O'Kane's MUMPS to C translator to translate VistA to C?
Anything you can say to explain your server side technology would be
appreciated.
Regards
-- Bhaskar
On May 22, 3:27 pm, daviduhl...@gmail.com wrote:
> I wanted to weight in here so that there can be some on-record
> discussion coming from us directly. I do not in any way want to offer
> a general commentary on why some people want to use MUMPS or don't
> want to, or X language is better than Y, I am not looking to instigate
> a flame war or really say that what we are doing is a better or worse
> approach from a technical standpoint than anything else. It is the
> right approach for us. Additionally I need to make clear that this is
> a preliminary announcement, we have moved beyond proof of concept but
> there is still a lot to be done. We now have 2 beta sites we will be
> rolling out over the course of the next 12-18 months while actively
> seeking 1 or more additional sites.
Jim Self
BTW, the idea of running VistA from the web is not new, Jim Self and his folks at UC Davis have accomplished this about 15 or more years ago.
I think we clearly showed *how* it could be done about that long ago with a web interface to our own system (VMACS, for veterinary medicine) and some general tools and demo applications showing some of the possibilities for general M-to-Web applications, including high-level data to table generation in HTML, Javascript, and later XML.
More recent are some tools for generating and processing AJAX data entry forms tied to Fileman API's and data definitions. There is also an initial implementation of a functional menu interface for the VistA Options file.
-- --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Information Technology Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) --------------------------------------- M2Web Demonstration with VistA (http://vista.vmth.ucdavis.edu/) ---------------------------------------
Jim Self
I think they are taking the right approach by developing a rich browser client as the next generation CPRS.
That's why I'm putting together a developer's virtual machine based on M/gateway's Enterprise Web Developer platform. Write your methods on the mumps side, compile the php pages on the mumps side, and output them to your webserver.
What advantages do you see in generating dynamic HTML, Javascript, etc for VistA from php instead of doing it from mumps?
Or might you be doing both? That might be relatively easy with EWD and/or M2Web?
Plus, it has custom tags to make use of javascript toolkits like extJS.
I built some preliminary M2Web tools a while back for generating and processing Dojo based data entry forms for VistA from Fileman data definitions and API's. These can be used to make applications with very little source code.
Unfortunately the version I started with (Dojo 0.43) lacked some of the functionality I would like to see in a full scale data interface and upgrading to the current version (1.1) requires significant re-learning and re-programming. Their data API's and data enabled widgets have changed greatly between versions.
Yeah, very cool stuff this web 2.0
Still there must be some commonality in the different approaches...
If you keep a blog reporting your progress and problems along the way (and/or report it to hardhats) it might help to illuminate the way for you as well as others.
rtweed
> I agree that EWD seems worth investigating. (Sorry, Rob, but I haven't
> gone very far with that yet. When I last tried, there were some issues
> with getting the appliance to load in Parallels on my Mac.)
network driver it uses seems much more reliable
> What advantages do you see in generating dynamic HTML, Javascript, etc
> for VistA from php instead of doing it from mumps?
the actual markup, Javascript etc is being served up from. It
abstracts that away from you so it's largely irrelevant.
The real advantage of EWD is that it makes the task manageable and
scalable. With increasingly complex UI functionality becoming
possible with the latest generations of Javascript-based widgets from
the likes of Yahoo, Dojo, ExtJS etc, the pages you have to serve up
become increasingly complex to write and (critically) to maintain.
That's where EWD's Ajax framework comes in - it simplifies how you
conceptually design your pages, and also where the custom tags come
in, because they can simplify the complex JSON-structured Javascript
coding required for these widgets down to a bunch of simple to use and
simple to understand XML tags. Witness the EWD/ExtJS desktop which
you can get working with just 2 custom tags: see
http://gradvs1.mgateway.com/download/extjs4.0.684.pdf, page 34.
A separate question is whether EWD could be made to work with GT.M
without the need for PHP. The model there would be akin to WebLink
and Cache. That's something I'm currently pondering. However, as
people who use EWD with Cache know, there would be no difference
within your EWD pages: whether and how an EWD application runs with
PHP, CSP, JSP or WebLink is handled by EWD's compiler and makes no
difference to the developer.
>
> Or might you be doing both? That might be relatively easy with EWD
> and/or M2Web?
>
> > Plus, it has custom tags
> > to make use of javascript toolkits like extJS.
>
> Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few
> links from google comparing them but all from before Dojo 1.0.
>
everyone else is now playing catch-up with them. The latest ExtJS
widget library is nothing short of stunning and unbelievably
sophisticated. From what I've seen of the current CPRS interface,
there's not one bit of functionality that couldn't be done using ExtJS
widgets. The problem is that it would involve some very complex use
of the ExtJS widgets, but the good news is that EWD would make it do-
able and maintainable.
I'm afraid that the days of the hacked-together MUMPS routine to
generate web pages are out the window when you're into this level of
UI sophistication. You need a tailor-made toolset to make it
practical, manageable and maintainable and avoid going insane!
> I built some preliminary M2Web tools a while back for generating and
> processing Dojo based data entry forms for VistA from Fileman data
> definitions and API's. These can be used to make applications with very
> little source code.
>
complex, it's that if you attempt to emulate something like the CPRS
interface, you end up with so much stuff to write, manage and
maintain. You need automation tools like EWD to allow you to
conceptually simplify the process and allow you to crank out the
pages. And of course you need to maintain state and security, all
stuff done automatically for you by EWD so that burden is relieved
also.
> Unfortunately the version I started with (Dojo 0.43) lacked some of the
> functionality I would like to see in a full scale data interface and
> upgrading to the current version (1.1) requires significant re-learning
> and re-programming. Their data API's and data enabled widgets have
> changed greatly between versions.
at a blistering pace. One more reason for custom tags: to abstract
the physical implementation so the underlying code can be kept up to
date with the widget libraries whilst their use in your pages can
remain relatively constant.
> Yeah, very cool stuff this web 2.0
>
> I agree. There seem to be many ways to go about developing it. So much
> to learn and so little spare time to do it in...
idea, right?
>
> Still there must be some commonality in the different approaches...
>
> If you keep a blog reporting your progress and problems along the way
> (and/or report it to hardhats) it might help to illuminate the way for
> you as well as others.
and Vista, so I too am looking forward to what he'll be able to
demonstrate in the hopefully not too distant future
Rob
Fred Trotter
Remember that this is completely second hand information.
I have neither seen the code, the process, nor the interface. I am
just parroting what was said in the talk at TEPR and I could easily be
wrong. I think it is pretty relevant that Roger has been talking to
the same people and has a very different technical summary. I would
assume that my 10000 foot summary turns out to be pretty off base. The
only reason I indicated that it was not just a CPRS replacement was
that I understand that David either has the pharmacy stuff working or
believes that he will be able to get it working.
As with anyone who has even a passing familiarlity with
MUMPS, I appropriately dubious. However I have seen David do some
amazing things with PHP, and I while he may sometimes be
overconfident, I have never known him to completely BS. So I am very
interested to see what they have. I just wanted you to know that I do
not actually know what they have... so make sure you do not rely on my
understanding too much.
On Thu, May 22, 2008 at 9:37 AM, Chris Richardson <r...@rcresearch.us> wrote:
>
> Roger;
>
> That is not what they said. They said " a web-based version of VistA
> working without MUMPS" and "the strategy is to compile the MUMPS code to C,
> run it through some extensive processing, and then it becomes available in a
> fashion that can be called from php." I believe that both GTM and Cache can
> work with PHP just fine without having to be converted to "C". I would love
> to see their data model and watch their performance stats. I have a pretty
> good idea what those will look like. If they wanted to say that they were
> just replacing CPRS, then they should say so. If they didn't replace CPRS,
> they could still claim that CPRS runs without MUMPS right now (as long as
> you don't expect any data to come with it). If I am not mistaken, GT.M is
> already written in "C" or some other compiler and pretty well optimized for
> the data handling model. Re-inventing MUMPS in C would be a trick, getting
> scalability and performance would be a miracle. Say you could (by some
> miracle), what would you be loosing? Access to the source code (it is all a
> black box and the end user is kept at arms length from verifying the
> operation of the code). The user is at the mercy of the vendor once again.
> Is this a good thing? I don't think so. Where is the good here?
>
> Interesting, but is it really necessary? What is wrong with MUMPS? I
> have heard of such efforts to replace MUMPS for over 20 years. If all of
> this effort to replace MUMPS was so easy, it would have been done already.
> It isn't a matter of money, the DoD and the VA have spent gobs of money to
> replace it. What is keeping them?
>
>
--
Fred Trotter
http://www.fredtrotter.com
George Timson
writes more MUMPS code and XECUTEs it on the fly. MUMPS really is the
"X language", to use Mr. Uhlman 's term. :-)
FileMan uses XECUTE all over the place. To be able to run a FileMan
report "outside a continuously running instance", how would the XECUTE
command be handled?
--George Timson
Chris Richardson
I am not trying to shoot the messenger, just find out where the reality
ends and the FUD begins. Yes, this is interesting work, and I have seen
many attempts at replacing MUMPS with compiled code on multiple occassions,
but why? Why is there all of this effort to replace one tool which was way
ahead of its time? Does VistA need to be re-writen, sure, but why not use
what we have and what works rather than build a compiled monstrosity that
you may or may not get the source code for. Where is the advantage? Lets
use what works, has worked, and has proven to be scalable beyond many of the
other environments that are being proped up to try to replace it, and only
coming in a poor second in nearly every case. I have seen no other system
out there that can hold and manage more than 30 years of patient history
like VistA can (the major exception is Octo Barnetts' model at Beth Israel
Hospital in Boston, but that is a MUMPS model as well. MUMPS must be doing
something right.
----- Original Message -----
From: "Fred Trotter" <fred.t...@gmail.com>
To: <Hard...@googlegroups.com>
Sent: Friday, May 23, 2008 1:45 PM
Subject: [Hardhats] Re: ClearHealth project compiles VistA to MUMPS-LESS web
interface.
>
Aylesworth, Marc CTR USAF AFMC AFRL/RISE
Marc Aylesworth
RRC C3I Grooup
525 Brooks Road
Rome, NY 13440
PH: 315-330-2422
________________________________
http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
Interesting times :)
-FT
--
Fred Trotter
http://www.fredtrotter.com <http://www.fredtrotter.com/>
Maury Pepper
kdt...@gmail.com
to standard object files, and is callable by php.
It's called GTM.
Kevin
Fred Trotter
Generally that makes it a non-starter.
kdt...@gmail.com
call in from other languages. For example, someone has written an
interface form perl to GTM. So if php 5 is not able to connect to
another program written in c that has predefined channels for such a
connection (such as GTM), then I would see that as a limitation of
php.
I suspect that it is doable, but there just hasn't been a need for it,
so the channel has not yet been created.
Kevin
kdt...@gmail.com
http://www.fidelityinfoservices.com/FNFIS/Markets/NonFinancialIndustries/Healthcare/GTM/Product/TechnologyDetail/
Kevin
kdt...@gmail.com
finish office charts...)
According to this link:
http://www.php.net/manual/en/intro.pdo.php
There would need to be a database driver written for GT.M
This is a list of databases already having a driver established.
The following drivers currently implement the PDO interface:
Driver name Supported databases
PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase
PDO_FIREBIRD Firebird/Interbase 6
PDO_IBM IBM DB2
PDO_INFORMIX IBM Informix Dynamic Server
PDO_MYSQL MySQL 3.x/4.x/5.x
PDO_OCI Oracle Call Interface
PDO_ODBC ODBC v3 (IBM DB2, unixODBC and win32 ODBC)
PDO_PGSQL PostgreSQL
PDO_SQLITE SQLite 3 and SQLite 2
So a connection is theoretically possible, but not currently ready to
go. I would guess that the interface would need to talk SQL, so one
would have to include a GT.M SQL engine as well....
Sigh, it's hard when it seems that 98% of the rest of the world talks
a different language...
rtweed
path=mgwsiMenu) provides a connection between GT.M and:
- PHP (all versions)
- Java Server Pages
- ASP.Net
Our latest version, due for release soon, adds Python and Ruby to the
list.
In all cases MGWSI allows you to access a GT.M system from within any
of these environments, to access and manipulate globals and/or to
invoke routines/functions and send/receive data.
It's free too!
Rob
kdt...@gmail.com
Does it doe the interface via one of the PDO type drivers mentioned in
my prior post? Can you elaborate a bit on the technology? How is it
set up? I don't operate much in PHP etc, so don't know the details.
I guess with this the LAMP stack could be:
L - Linux
A - Apache
M - MUMPS :-)
P - PHP
Kevin
edsalvador
language.
I think it is a matter of Vista gaining traction in the physician
practice community. You can knock the current commercial EMR
applications all you want, however, they have anywhere from hundreds
to thousands of users.
How many does Vista have? What is being done by WorldVista to gain
market share?
When you can solve this issue, the point will be moot.
Ed
On May 21, 10:33 pm, Joseph Dal Molin <dalmo...@e-cology.ca> wrote:
> ....what some people will do to avoid learning a new programing language
> is simply awe inspiring :-)
>
> J
>
>
>
> > Today at TEPR, ClearHealth announced that they have a web-based
> > version of VistA working without MUMPS.
>
> > Apparently the strategy is to compile the MUMPS code to C, run it
> > through some extensive processing, and then it becomes available in a
> > fashion that can be called from php.
>
> > They are currently in beta in one hospital with this technology.
>
> > I know very little about it so I cannot field questions. For those who
> > are very interested, take a look at this post on the ClearHealth
> > forums:
>
> >http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
>
> > I am sure they might field questions from you on that same forum.
>
> > Interesting times :)
>
>
> - Show quoted text -
K.S. Bhaskar
porting a few older PHP modules to PHP 5 is a show-stopping obstacle?
I know people who saw how small http://downloads.sourceforge.net/fis-gtm/phpgtcm.tar.gz
is, read it and then wrote their own Java interface to GT.M.
In any case, you can also use PIP (http://www.fis-pip.com &
http://sourceforge.net/projects/pip) to get FOSS JDBC/SQL access to an
M/Fileman database, but that may be more work.
Also, as Rob points out, the M Gateway code (which is really cool)
provides another great free (don't know if it is Free) way to access M/
Fileman data.
I fully understand if you are stymied by lack of interest - let's not
forget that MUMPS is infectious! 8-)- - lack of funding, lack of
enthusiasm, etc., but you shouldn't be stymied by a lack of
technology.
Regards
-- Bhaskar
K.S. Bhaskar
For the last three months WorldVistA EHR has been downloaded from
Source Forge at the rate of around 1400 downloads/month and last week
was at 98.38 percentile of all projects by activity at Source Forge.
The WorldVistA project (mostly FOIA VistA flavors) was at 96.83
percentile last week and has been averaging around 700 downloads/month
for the last three months.
GT.M (independent of activity and downloads bundled with VistA) was at
98.73 percentile last week, and has been averaging 600 downloads/month
over the last three months.
So, you're probably right - it's a dying application on a technology
that's about to go belly up. Time to move on to something else...
any decade now.
-- Bhaskar
Fred Trotter
to GTM bridge. From what I can tell python has many of the same
web-enabled benefits of php, with stricter OOP.
Again, it is really an issue of what is doable and what I personally
have the bandwidth for.
edsalvador
Download stats are meaningless unless physicians actually use the
application.
Where are the real-world stats?
Ed
I agree that the applications has potential.
However, like someone told me:
Sh*t in one hand and wish in the other. See which one gets filled-up
faster.
rtweed
Developer (EWD) (http://www.mgateway.com/ewd.htm). MGWSI is the key
underlying reason why EWD can potentially cross-compile to PHP or
potentially any other web technology: MGWSI provides a normalised way
of accessing GT.M (or Cache) from them all.
You can use MGWSI manually however if you really want to hand-craft
your PHP, Python or whatever (personally I no longer see the point
doing this any more as EWD automates the whole process and avoids me
having to write any PHP or whatever code).
MGWSI is a general-purpoose service that mediates between two systems,
one deemed to be the server (in this case GT.M) and the other the
client (eg PHP, JSP etc). The endpoints may be on the same or
separate hardware: provided they can communicate via TCP/IP, then
MGWSI will integrate them. One instance of MGWSI can support access
to multiple GT.M and/or Cache servers from a client environment,
allowing it to support distributed back-end data or heterogeneous
database access.
All the documentation for MGWSI is included in the downloadable zip
file from our web site (www.mgateway.com), but here's a few examples
which will perhaps help to explain how you use it.
PHP:
$result = m_proc("myFunc^myRoutine", $ar2, "London");
Invokes a call from within PHP to GT.M, the equivalent of s result=$
$myFunc^myRoutine(.ar2,"London")
where ar2 is an array. Arrays are mapped automatically between PHP's
associative arrays and M's local arrays. GT.M may update the array if
required and send back new content.
Various low-level primitive global calls, eg:
m_set("^MGWCust", 1, "Rob Tweed");
m_set("^MGWCust", 2, "John Smith");
from within PHP would create:
^MGWCust(1)="Rob Tweed"
^MGWCust(2)="John Smith"
Java Server Pages equivalent to the above (ie calls from within JSP
pages):
m_jsp.ma_arg_set_array (args, 1, records, 1); // pass-by-
reference.
m_jsp.ma_arg_set_string(args, 2, "London", 0);
m_jsp.ma_proc("myFunc^myRoutine", args, 2)
key[0] = "1"; // no of subscripts
key[1] = "1"; // value of subscript 1
m_jsp.ma_set("^MGWCust", key, "Rob Tweed");
key[1] = "2";
m_jsp.ma_set("^MGWCust", key, "John Smith");
All the other language interfaces work similarly to either the JSP or
PHP ones. You have functions for:
- setting globals
- killling globals
- traversing globals ($order equivalent)
- merging to/from globals or local arrays
- invoking routines (+ sending/receiving data)
- invoking functions (+ sending/receiving data)
MGWSI is deliberately kept very simple and straightforward, but allows
complete flexibility. The great thing about MGWSI is that it allows
you to invoke legacy functions from within any of the supported web
technologies/languages, making it idea for interfacing with existing
Vista business logic.
If you want to see MGWSI in action, the simplest approach is to
download our EWD Virtual Appliance which includes MGWSI pre-installed
and pre-configured in a VMWare Virtual Machine based on Linux/PHP/
Apache/GT.M. Most of the time in the Virtual Appliance you won't even
be aware it's there, since it's providing the gateway between GT.M and
EWD-generated PHP applications.
You'll also be using MGWSI if you download the Asus Eee kit for EWD
which I described in a recent post here and which Steve Owen has been
using.
For more information,. download MGWSI and consult the documentation.
All our products are free to download and use without restriction and
can be obtained from