Fwd: Re: EDIS without proprietary dependencies

[Nancy Anthracite]

---------- Forwarded Message ----------

Subject: Re: EDIS without proprietary dependencies
Date: Saturday, September 17, 2011
From: Feras Kamal <Feras...@ehs.com.jo>
To: "sol...@solomonblaz.com" <sol...@solomonblaz.com>
CC: "nanth...@earthlink.net" <nanth...@earthlink.net>,
"gli...@glilly.net" <gli...@glilly.net>, "dlef...@orohosp.com"
<dlef...@orohosp.com>, "dalm...@e-cology.ca" <dalm...@e-cology.ca>

Hello Solomon,

Hope my note finds you well. Any update you could share with us at this stage.

Thanks
Feras

----- Original Message -----
From: Solomon Blaz [mailto:sol...@solomonblaz.com]
Sent: Friday, August 26, 2011 09:59 AM
To: Feras Kamal
Cc: nanth...@earthlink.net <nanth...@earthlink.net>; gli...@glilly.net
<gli...@glilly.net>; dlef...@orohosp.com <dlef...@orohosp.com>; dalmolin@e-
cology.ca <dalm...@e-cology.ca>
Subject: Re: EDIS without proprietary dependencies

Feras,

Thank you so much! It will be great to have your team's help,
especially when we need to try and get it running. But I figure we
should get it to build first. :) You all are of course welcome to
browse around the source at the svn repository George has set up once
we get the modifications going. Please do not hesitate to ask if you
have questions or important things to share.

Cheers,
Solomon

On Thu, Aug 25, 2011 at 8:19 PM, Feras Kamal <Feras...@ehs.com.jo> wrote:
> Hello Solomon,
>
> It is really great news to the vistA community and to me personally hearing
your support in setting EDIS without proprietary code.
>
> We ,in Jordan, will be in need of EDIS package as we see the importance
and the value of having this package in an Emergency Dept.
>
> Kindly consider the team here in Jordan for any request or work you see it
possible for them to do during this exercise.
>
> Thanks. again for your support.
>
> Feras
>
>
> ----- Original Message -----
> From: Nancy Anthracite <nanth...@earthlink.net>
> To: George Lilly <gli...@glilly.net>
> Cc: Solomon Blaz <sol...@solomonblaz.com>; Feras Kamal; Denise Lefevre
<dlef...@orohosp.com>; Joseph Dal Molin <dalm...@e-cology.ca>
> Sent: Thu Aug 25 13:22:59 2011
> Subject: Re: EDIS without proprietary dependencies
>
> I was ecstatic when Solomon found out that the code was already available
and
> he was ready to take this on. I could hardly wait for him to write to you
all
> and tell you the good news!
>
> We very seldom get a great break like this. This is one to savor. :-)
>
> On Thursday, August 25, 2011, George Lilly wrote:
>> Solomon:
>>
>> I'm really excited about what you are doing with EDIS, and I'd be
>> happy to help you on the weekend with using the svn server.
>>
>> I've set up an initial set of directories. you can add, rename, or
>> delete them as you see fit. You can see them here:
>>
>> https://trac.opensourcevista.net/browser/EDIS
>>
>> If you have subversion installed, you can check out the directories
>> using this command: (assuming linux)
>>
>> svn co https://trac.opensourcevista.net/svn/EDIS .
>>
>> (If you are using windows, I would recommend getting
>> http://tortoisesvn.net/ )
>>
>> That will make a copy of the whole directory structure on your system.
>> After you add the files to the directories, you add them to svn with
>> svn add.
>>
>> You commit them to the repository simply with this command:
>>
>> svn commit
>>
>> Please feel free to contact me for help with any of this.
>>
>> Thanks very much for your work.
>>
>> gpl
>>
>> On Thu, Aug 25, 2011 at 1:52 AM, Solomon Blaz <sol...@solomonblaz.com>
> wrote:
>> > Hello,
>> >
>> > Nancy listed all of you as people interested in EDIS and asked that I
>> > share with you some of our recent discoveries. I am one of the
>> > original developers of EDIS, though I haven't been involved with it
>> > for nearly 3 years now. Even though I'm rusty, I'm happy to help get
>> > EDIS over the hump and running on an open source stack.
>> >
>> > As you may know, EDIS as released by the VA has a dependency on a
>> > piece of software called KAAJEE, developed by another group, that is
>> > responsible for gluing together the authentication of users via VistA
>> > with the authentication of users in the EDIS web application.
>> > Unfortunately, KAAJEE is dependent on proprietary software and has
>> > other side effects that make the EDIS software as released via FOIA
>> > very difficult to work with. The good news is that not only is it
>> > possible to build and run EDIS without KAAJEE, but we actually
>> > prototyped it years ago. Once EDIS no longer uses KAAJEE, it can run
>> > on a fully open source stack, including Apache Tomcat and versions of
>> > Java other than 1.4.2, which was another negative side effect of
>> > employing KAAJEE.
>> >
>> > The REALLY good news is that it appears that the prototype code that
>> > provides an alternative to KAAJEE appears to be in the EDIS code
>> > released via FOIA. That means that I should be able to reconfigure
>> > the EDIS build and application to work without KAAJEE with relatively
>> > little effort (on the order of a few hours, perhaps?) and you all will
>> > be able to try it out on Tomcat and against your WorldVistA EHR
>> > instances. Without that prototype code it would've been significantly
>> > more effort to perform the KAAJEE-removal surgery. :)
>> >
>> > For those with interest in technical details, once we get the code in
>> > source control, the rough steps are:
>> > 1. remove all dependencies of EDIS build scripts on VA network
>> > infrastructure 2. potentially upgrade the build scripts to use the
>> > latest version of Apache Maven
>> > 3. remove KAAJEE and its dependencies from the EDIS web application
>> > 4. configure the EDIS web application to use the spring-security based
>> > implementation in the 'tracking-server-vista' module
>> > 5. build the liberated EDIS web application
>> > 6. dance in the streets
>> > 7. try it out, uncover next set of problems to solve, discuss next steps
>> >
>> > I hope to get started this weekend and will let you know how things
>> > are progressing if you have interest. Please let me know if there are
>> > any other ways I can be of help.
>> >
>> > Sincerely yours,
>> > Solomon
>
>
> --
> Nancy Anthracite
>

-------------------------------------------------------

--
Nancy Anthracite

[Nancy Anthracite]

---------- Forwarded Message ----------

Subject: Re: EDIS without proprietary dependencies

Date: Tuesday, October 04, 2011
From: Solomon Blaz <sol...@solomonblaz.com>

Whoops I forgot a couple of steps, here's the revised instructions:

install tomcat
copy main.war and help.war to the tomcat "webapps" directory -
/var/lib/tomcat6/webapps
set VistALink connection info in
/var/lib/tomcat6/webapps/main/WEB-INF/conf/vistalink-config.xml
restart tomcat
visit http://localhost:8080/main in your browser

VistALink connection info includes hostname,port of VistALink
listener,station number, and access/verify code pair for VistALink
application user.

Clear as mud? ;)

Cheers,
Solomon

On Tue, Oct 4, 2011 at 10:45 AM, Solomon Blaz <sol...@solomonblaz.com> wrote:
> Nancy,
>
> I think the easiest EDIS installation is:
>
> install tomcat
> copy main.war and help.war to the tomcat "webapps" directory
> visit http://localhost:8080/main in your browser
>
> If you need copies of the *.wars, let me know
>
> If you end up needing a simpler little one-line command line program
> that calls an rpc with some arguments, also let me know.
>
> Cheers,
> Solomon
>
> On Tue, Oct 4, 2011 at 5:50 AM, Nancy Anthracite
> <nanth...@earthlink.net> wrote:
>> That is good because you did not use my script so we have VistALink failing
>> with two different methods for installing it.
>>
>> So, does anyone have "instructions for idiots" for what I need to do to get
>> the EDIS part put on my machine (that has VistALink already) and then I
want
>> to work with Skip, (who is just now learning that I am cooking this up) to
see
>> if we can nail down what is going wrong. Knowing Skip, with what I know
and
>> what he knows, we can scope this out, but we will have to work together to
do
>> it and the soonest I can tackle that is later today if he is available.
>>
>> BTW, I asked Maury to set up the Google Group for me as he and I do well
>> together administering a couple of other groups - not that there is much to
>> administer except getting rid of the spam.
>>
>> On Tuesday, October 04, 2011, Wasim Naffar wrote:
>>> We got all the VistALink's installation, script and manual files from
>>> *Vistapedia*, this link:
>>> http://vistapedia.net/index.php?title=VistALink
>>>
>>> so, if you have different one and may solve our problem, please send me
>>> your server link for the vistALink download.
>>>
>>> Thanks Nancy,
>>>
>>>
>>> Regards,
>>>
>>>
>>> *Wasim Naffar*
>>> Senior Software Developer
>>>
>>> hakeem.JPG EHS logo.png
>>>
>>> Tel: +962 6 5800461 Fax: +962 6 5800464 Mob: +962 79 7300747
>>> www.ehs.com.jo <http://www.ehs.com.jo>
>>>
>>> On 10/03/2011 07:11 PM, Nancy Anthracite wrote:
>>> > Did you install VistALink using my files and script from my server, or
>>> > did you start from scratch?
>>> >
>>> > I would be interested in seeing if what I did with the SwingTester
>>> > somehow make VistALink not work right or if it is independent of that.
>>> >
>>> > On Monday, October 03, 2011, Wasim Naffar wrote:
>>> >> Depending on that, we will try to trace this issue on our vistALink by
>>> >> ourselves and will be great if someone from outside "M experts" help us
>>> >> in that.
>>> >>
>>> >> Sure, when we make any change or modification on both J2ee or vistALink
>>> >> will submit you that.
>>> >> currently we are focusing on fixing the *"Undefined local variable
>>> >> XOBSYS(PRIMARYSTATION#)"* issue, so for the other issues we can
postpone
>>> >> it as the 2nd priority.
>>> >>
>>> >> thanks for your help, hope to keep in touch
>>> >>
>>> >>
>>> >> Regards,
>>> >>
>>> >> *Wasim Naffar*
>>> >> Senior Software Developer
>>> >>
>>> >> hakeem.JPG EHS logo.png
>>> >>
>>> >> Tel: +962 6 5800461 Fax: +962 6 5800464 Mob: +962 79
>>> >> 7300747 www.ehs.com.jo<http://www.ehs.com.jo>
>>> >>
>>> >> On 10/02/2011 10:47 PM, Solomon Blaz wrote:
>>> >>> Nancy, Sounds good to me! ;)
>>> >>>
>>> >>> Wasim, it looks like you're encountering the same problem as we are
>>> >>> with VistALink on GT.M, but with a slight variation. The (growing)
>>> >>> evidence is that the M side of VistALink on GT.M is not setting up the
>>> >>> environment in which to invoke the routine of an RPC fully - it is
>>> >>> leaving out the parameters that are passed over the wire to the RPC -
>>> >>> thus your "Undefined local variable XOBSYS(PRIMARYSTATION#)" and our
>>> >>> "Undefined local variable CLIENTIP" errors... The only RPCs I can get
>>> >>> to run are ones that take no arguments.
>>> >>>
>>> >>> Hardcoding your primary station is treating the symptom and not the
>>> >>> cause, and I think we'll have difficulty hard coding every single
>>> >>> parameter passed between EDIS and VistA. If we could someone with
>>> >>> some deeper M background than myself to trace what is received from
>>> >>> the wire through right into the routine invoked by the RPC, we might
>>> >>> catch what is probably a simple oversight or typo and VistALink will
>>> >>> "just work" again.
>>> >>>
>>> >>> If you think your patch to the VistALink XML handling is important to
>>> >>> make permanent, please send me your changes and I can commit it into
>>> >>> the mainline. We could also set you up with commit priveleges if you
>>> >>> find yourself making a lot of enhancements and/or bug fixes.
>>> >>>
>>> >>> Great work, very exciting!
>>> >>>
>>> >>> Cheers,
>>> >>> Solomon
>>> >>>
>>> >>> On Sun, Oct 2, 2011 at 12:14 PM, Nancy Anthracite
>>> >>>
>>> >>> <nanth...@earthlink.net> wrote:
>>> >>>> What do you say to my setting up an Emergency Room Google Group for
>>> >>>> the emails associated with this and other Emergency Room projects.
>>> >>>> We can put the code and documentation on the Trac server and updates
>>> >>>> on progress for general consumption on the Trac wiki, but we can then
>>> >>>> invite the others who were asking to be involved to sign up on the
>>> >>>> Google Group for the email exchange, etc.
>>> >>>>
>>> >>>> On Sunday, October 02, 2011, Wasim Naffar wrote:
>>> >>>>> Hi Solomon,
>>> >>>>>
>>> >>>>> After we modified the source code *getDocumentForXmlInputSource
>>> >>>>> *method to just printout the /xml string/ that comes from vista we
>>> >>>>> found that there is a special character in the xml and that why java
>>> >>>>> fires exception during parsing it, so we will try to figure how to
>>> >>>>> solve it later cause it is not a major issue now. and as you said
>>> >>>>> there is no problem with tomcat:).
>>> >>>>>
>>> >>>>> anyway, we navigated through Install and Configure VistALink for
EDIS
>>> >>>>> as described in /edp_ig.pdf/, and we checked that vistAlink
listening
>>> >>>>> on a specific port successfully.
>>> >>>>> but now we faced this problem in the *primarystation* on vista.
After
>>> >>>>> we logged we got the following error:
>>> >>>>> SITECHK+6^XOBSRA, Undefined local variable: XOBSYS(PRIMARY
>>> >>>>> STATION#),150373850,-%GTM-E-UNDEF]]
>>> >>>>> find both attached *undefiend_primary_station100.txt* and
>>> >>>>> *Undefined_primary_station100.png*.
>>> >>>>> already we traced that and we found that happens in
>>> >>>>> *XOBSRA routine*, line number 272
>>> >>>>> QUIT:((+XOBSTRIP)'=XOBSYS("PRIMARY STATION#")),, so we just changed
>>> >>>>> it to be hardcoded:
>>> >>>>> QUIT:((+XOBSTRIP)'=*100*) ;;; as our PRIMARY STATION # 100
>>> >>>>>
>>> >>>>>
>>> >>>>> after that we tried to relogin again and we got an error from the
>>> >>>>> vista also, we found the xml from vista as the attached
>>> >>>>> *Division_not_supported.txt*
>>> >>>>> "Division [100] not supported: [STATION '100' is not active on this
M
>>> >>>>> system.] (security type [AV], DUZ: [1187])."
>>> >>>>>
>>> >>>>> do you have any idea or any suggestions about the above errors??!!
>>> >>>>>
>>> >>>>> thanks in advance,
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>>
>>> >>>>>
>>> >>>>> *Wasim Naffar*
>>> >>>>> Senior Software Developer
>>> >>>>>
>>> >>>>> hakeem.JPG EHS logo.png
>>> >>>>>
>>> >>>>> Tel: +962 6 5800461 Fax: +962 6 5800464 Mob: +962 79
>>> >>>>> 7300747 www.ehs.com.jo<http://www.ehs.com.jo>
>>> >>>>>
>>> >>>>> On 10/01/2011 08:45 AM, Solomon Blaz wrote:
>>> >>>>>> Hi Wasim,
>>> >>>>>>
>>> >>>>>> I don't think tomcat6 should be a problem, that is what we have
used
>>> >>>>>> in our demo instance as well. I've also deployed on jetty7 and the
>>> >>>>>> java web app part appears to run without trouble.
>>> >>>>>>
>>> >>>>>> I believe the JeeNamespaceHandler not found is not an issue we need
>>> >>>>>> to worry about - it appears to be logging at the DEBUG level - if
>>> >>>>>> it were WARN or ERROR I'd be concerned, but I think its just the
>>> >>>>>> Spring framework trying to be helpful. You can reduce the noise in
>>> >>>>>> your logs by setting your log level higher to WARN or ERROR, I
>>> >>>>>> think.
>>> >>>>>>
>>> >>>>>> The other ones look familiar to me but it has been several years.
>>> >>>>>> My suspicion is that the VistALink connection is not being fully
>>> >>>>>> established... perhaps it is not responding with its initial xml
>>> >>>>>> during the handshaking process or something, but I can't really
>>> >>>>>> tell you for sure as VistALink was developed by a different team.
>>> >>>>>> We haven't successfully gotten VistALink to respond to all of the
>>> >>>>>> EDIS RPCs yet in our demo instance either. I'm hoping I can set up
>>> >>>>>> some simpler way of testing out the VistALink connection, maybe by
>>> >>>>>> fetching the welcome message on the login page or something like
>>> >>>>>> that, but otherwise I'm not sure what to tell you other than we are
>>> >>>>>> also stuck getting VistALink to work correctly. Out of curiousity,
>>> >>>>>> are you able to telnet to the port that VistALink is listening on?
>>> >>>>>> Does it return anything if you send a newline (by pressing enter)
>>> >>>>>> after connecting via telnet?
>>> >>>>>>
>>> >>>>>> Thanks for your help,
>>> >>>>>> Solomon
>>> >>>>>>
>>> >>>>>> On Fri, Sep 30, 2011 at 4:31 PM, Wasim
>>> >>>>>> Naffar<wasim....@ehs.com.jo
>>> >>>>>>
>>> >>>>>> <mailto:wasim....@ehs.com.jo>> wrote:
>>> >>>>>> Hello Solomon,
>>> >>>>>>
>>> >>>>>> hope you doing well,
>>> >>>>>>
>>> >>>>>> I followed the source code to find where exactly this error
>>> >>>>>> happens and this what i reached:
>>> >>>>>> inside class
>>> >>>>>> *gov.va.med.xml.XmlUtilities*
>>> >>>>>> method *getDocumentForXmlInputSource(InputSource xml)
>>> >>>>>> *the xml arrgument always send as null value,
>>> >>>>>>
>>> >>>>>> note that this error appears after login directly, and
already
>>> >>>>>> we configured the vistAlink and the EDIS can connect to it
>>> >>>>>> without fire any exception as before, like host unknown, or
>>> >>>>>> connection refused...etc
>>> >>>>>>
>>> >>>>>> actually i didn't catch what the value of xml mean or what
>>> >>>>>> should it be??! might be we are missing something somewhere
>>> >>>>>> in VistA Side (vistaLink configuration), just we want to know
>>> >>>>>> what this value should be to know what we are missing...
>>> >>>>>>
>>> >>>>>> hope that will be more clear and will help you to get what
are
>>> >>>>>> happening here and what should we do.
>>> >>>>>>
>>> >>>>>> thanks in advance,
>>> >>>>>>
>>> >>>>>> Regards,
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> *Wasim Naffar*
>>> >>>>>> Senior Software Developer
>>> >>>>>>
>>> >>>>>> hakeem.JPG EHS logo.png
>>> >>>>>>
>>> >>>>>> Tel: +962 6 5800461<tel:%2B962%206%205800461> Fax:
>>> >>>>>> +962 6 5800464<tel:%2B962%206%205800464> Mob: +962
>>> >>>>>> 79 7300747 <tel:%2B962%2079%207300747>
>>> >>>>>> www.ehs.com.jo<http://www.ehs.com.jo>
>>> >>>>>>
>>> >>>>>> On 09/29/2011 11:43 AM, Wasim Naffar wrote:
>>> >>>>>>> Hello Solomon,
>>> >>>>>>>
>>> >>>>>>> it's Wasim from EHS-Hakeem, Jordan.
>>> >>>>>>> I would like to thank you for the help and answering us for
>>> >>>>>>> all the inquires.
>>> >>>>>>>
>>> >>>>>>> as you mentioned before, we modified the
>>> >>>>>>> /vistalink-config.xml/ file and set our values, then
>>> >>>>>>> restarted the tomcat,
>>> >>>>>>> so, we tried to login and we got this error as the attached
>>> >>>>>>> file *xml_parsing_error.txt*.
>>> >>>>>>> note that we use *tomcat6* and might be this is the problem.
>>> >>>>>>> what do you think?
>>> >>>>>>>
>>> >>>>>>> and you can see this error also in the attached
>>> >>>>>>> *JeeNamespaceHandler_notfound_error.txt*, which is also from
>>> >>>>>>> tomcat console and occurs when start the tomcat, but
actually
>>> >>>>>>> it doesn't make any sense and we can see the tomcat running
>>> >>>>>>> successfully and open the EDIS main index from browser
>>> >>>>>>> without any exception.
>>> >>>>>>>
>>> >>>>>>> thanks in advance,
>>> >>>>>>>
>>> >>>>>>> Regards,
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> *Wasim Naffar*
>>> >>>>>>> Senior Software Developer
>>> >>>>>>>
>>> >>>>>>> hakeem.JPG EHS logo.png
>>> >>>>>>>
>>> >>>>>>> Tel: +962 6 5800461<tel:%2B962%206%205800461> Fax:
>>> >>>>>>> +962 6 5800464<tel:%2B962%206%205800464> Mob: +962
>>> >>>>>>> 79 7300747<tel:%2B962%2079%207300747>
>>> >>>>>>> www.ehs.com.jo<http://www.ehs.com.jo>
>>> >>>>>>>
>>> >>>>>>> On 09/29/2011 08:45 AM, Solomon Blaz wrote:
>>> >>>>>>>> Hello everyone,
>>> >>>>>>>>
>>> >>>>>>>> Yes, sorry that you were trying to follow my generalized
>>> >>>>>>>> outline of steps that were more reminders for myself than
>>> >>>>>>>> specific instructions for others, but it is great to see
>>> >>>>>>>> that you have tomcat and the like up and running! :)
>>> >>>>>>>>
>>> >>>>>>>> Everything you need to run EDIS (other than tomcat itself)
>>> >>>>>>>> is built into the two .wars, main.war and help.war. All
>>> >>>>>>>> the dependent jars are inside main.war in WEB-INF/lib.
>>> >>>>>>>> There is an optional third .war called bigboard.war that we
>>> >>>>>>>> can talk about once the main application is up and running
>>> >>>>>>>> somewhere first. You don't need to worry about spring or
>>> >>>>>>>> spring-security or any of their dependencies unless you are
>>> >>>>>>>> trying to modify the java code or something like that,
>>> >>>>>>>> which will come later. So you were right to back out the
>>> >>>>>>>> changes you made to tomcat's configuration based on the
>>> >>>>>>>> stuff at:
>>> >>>>>>>> http://static.springsource.org/spring-
security/site/docs/2.0
>>> >>>>>>>> .x /refe rence/ca.html#ca-tomcat
>>> >>>>>>>>
>>> >>>>>>>> The next step for you to try to out is to configure the
EDIS
>>> >>>>>>>> VistALink connection information.
>>> >>>>>>>>
>>> >>>>>>>> You can do this by stopping tomcat, and editing a file
>>> >>>>>>>> inside main.war that tomcat expanded when you installed it
>>> >>>>>>>> at:
>>> >>>>>>>> $CATALINA_HOME/webapps/main/WEB-INF/config/vistalink-config
>>> >>>>>>>> .xml
>>> >>>>>>>>
>>> >>>>>>>> There should be a section that looks something like this:
>>> >>>>>>>> <bean
>>> >>>>>>>>
class="gov.va.med.edp.vistalink.locator.VistaLinkConnecto
>>> >>>>>>>> rCo nfi g">
>>> >>>>>>>>
>>> >>>>>>>> <property name="host" value="66.206.177.84"/>
>>> >>>>>>>> <property name="port" value="9310"/>
>>> >>>>>>>> <property name="name" value="WORLDVISTA DEMO
>>> >>>>>>>> CLINIC"/> <property name="primaryStation"
>>> >>>>>>>> value="500"/> <property name="accessCode"
>>> >>>>>>>> value="******"/> <property name="verifyCode"
>>> >>>>>>>> value="******"/>
>>> >>>>>>>>
>>> >>>>>>>> </bean>
>>> >>>>>>>>
>>> >>>>>>>> Set these values to the host, port, name, station number of
>>> >>>>>>>> your own VistA instance. access/verify code pair here
>>> >>>>>>>> refers to the access/verify codes of the EDIS APPLICATION
>>> >>>>>>>> PROXY user you set up as part of the EDP1_0.KIDS
>>> >>>>>>>> post-installation steps.
>>> >>>>>>>>
>>> >>>>>>>> EDIS uses VistALink, which uses a trusted connection
>>> >>>>>>>>
>>> >>>>>>>> (authenticated with these application credentials rather
>>> >>>>>>>> than end-user credentials) on top of which regular end
>>> >>>>>>>> users are authenticated. See the VistALink manuals for
>>> >>>>>>>> more info.
>>> >>>>>>>>
>>> >>>>>>>> Note that you may have to add the line with the "port" in
>>> >>>>>>>> it.
>>> >>>>>>>>
>>> >>>>>>>> Restart tomcat.
>>> >>>>>>>>
>>> >>>>>>>> Once you've got the VistALink connection configured, you'll
>>> >>>>>>>> be caught up with us and the current state of our demo EDIS
>>> >>>>>>>> instance and you'll run into an exception that looks
>>> >>>>>>>> something like:
>>> >>>>>>>>
>>> >>>>>>>>
gov.va.med.edp.vistalink.VistaLinkDataRetrievalFailureExcept
>>> >>>>>>>> ion
>>> >>>>>>>>
>>> >>>>>>>> : A system error occurred in M: USERINFO+59^XUSKAAJ,
>>> >>>>>>>> : Undefined
>>> >>>>>>>>
>>> >>>>>>>> local variable: CLIENTIP,150373850,-%GTM-E-UNDEF;
>>> >>>>>>>>
>>> >>>>>>>> We're working on identifying (and then fixing) this bug,
but
>>> >>>>>>>> right now the exact cause is unknown.
>>> >>>>>>>>
>>> >>>>>>>> Also, I have made some more changes to the java code that
>>> >>>>>>>> clean up some cruft left over from KAAJEE and added the
>>> >>>>>>>> missing "port" line and such which I will commit to svn
>>> >>>>>>>> soon and then I will rebuild the .war files and put them
>>> >>>>>>>> somewhere appropriate for sharing.
>>> >>>>>>>>
>>> >>>>>>>> Wasim, if you're interested in setting yourself up to build
>>> >>>>>>>> the latest .war files yourself, checkout the source with
>>> >>>>>>>> subversion (svn co
>>> >>>>>>>> https://trac.opensourcevista.net/svn/EDIS/trunk) and try
>>> >>>>>>>> looking at
>>> >>>>>>>>
https://trac.opensourcevista.net/browser/EDIS/trunk/java/REA
>>> >>>>>>>> DME and let me know how it goes. If there are changes we
>>> >>>>>>>> can make to it to make it clearer and/or more complete,
>>> >>>>>>>> please feel free to make edits that we can then commit back
>>> >>>>>>>> to source control or just contact me with suggestions. Or
>>> >>>>>>>> if you'd rather wait for us to get working copy of main.war
>>> >>>>>>>> first, that is OK too. :)
>>> >>>>>>>>
>>> >>>>>>>> Good job guys! As always, questions are welcome.
>>> >>>>>>>>
>>> >>>>>>>> Cheers,
>>> >>>>>>>> Solomon
>>> >>>>>>>>
>>> >>>>>>>> On Wed, Sep 28, 2011 at 2:56 PM, Nancy Anthracite
>>> >>>>>>>>
>>> >>>>>>>> <nanth...@earthlink.net>
>>> >>>>>>>> <mailto:nanth...@earthlink.net>
>>> >>>>
>>> >>>> wrote:
>>> >>>>>>>>> Did you get the .war files OK? At the time Solomon was
>>> >>>>>>>>> working on it and I was playing spectator, the trac server
>>> >>>>>>>>> was down so I don't know if he put them up there. They
>>> >>>>>>>>> were help.war and main.war.
>>> >>>>>>>>>
>>> >>>>>>>>> He was having trouble getting some of the RPCs that had
>>> >>>>>>>>> arguments to deliver the arguments. There does not seem
to
>>> >>>>>>>>> be any logging function inside VistALink link there is in
>>> >>>>>>>>> the RPC Broker so I was supposed to do some packet
>>> >>>>>>>>> sniffing for him that I have not done yet.
>>> >>>>>>>>>
>>> >>>>>>>>> See if the screen shots below will help you.
>>> >>>>>>>>>
>>> >>>>>>>>> On Wednesday, September 28, 2011, Khamis Siksek wrote:
>>> >>>>>>>>>> We are on it!! :-)
>>> >>>>>>>>>>
>>> >>>>>>>>>> We started the testing for EDIS and setting it up, many
>>> >>>>>>>>>> steps worked fine with:
>>> >>>>>>>>>>
>>> >>>>>>>>>> 1- We got the main.war successfully.
>>> >>>>>>>>>> 2- We deployed to tomcat successfully. login page appears
>>> >>>>>>>>>> without any exception at tomcat console.
>>> >>>>>>>>>> 3- enable SSL with Tomcat successfully.
>>> >>>>>>>>>> 4- Configured VistALink.
>>> >>>>>>>>>>
>>> >>>>>>>>>> until this point everything goes well.
>>> >>>>>>>>>>
>>> >>>>>>>>>> 5- but we stopped at this point; the spring-security
>>> >>>>>>>>>> framework configuration. We configured spring-security
>>> >>>>>>>>>> framework with tomcat as described in the following link
>>> >>>>>>>>>>
>>> >>>>>>>>>> http://static.springsource.org/spring-
security/site/docs/2
>>> >>>>>>>>>> .0. x/re ference/ca .html#ca-tomcat
>>> >>>>>>>>>>
>>> >>>>>>>>>> And we tried to find the way of how to configure, install
>>> >>>>>>>>>> and download all the libraries and xml files for the
>>> >>>>>>>>>> spring framework (acegisecurity.xml
>>> >>>>>>>>>> spring-security-catalina-XX.jar
>>> >>>>>>>>>> aopalliance.jar
>>> >>>>>>>>>> spring.jar
>>> >>>>>>>>>> commons-codec.jar
>>> >>>>>>>>>> burlap.jar
>>> >>>>>>>>>> hessian.jar), actually we got confused because we don't
>>> >>>>>>>>>> have clear idea about how& why we need to use this
>>> >>>>>>>>>> framework (spring framework). Please if you can elaborate
>>> >>>>>>>>>> more on it more it will be helpful and highly
>>> >>>>>>>>>> appreciated.
>>> >>>>>>>>>>
>>> >>>>>>>>>> so after all of that we got the error at the tomcat log
as
>>> >>>>>>>>>> follow:
>>> >>>>>>>>>>
>>> >>>>>>>>>> java.lang.NoClassDefFoundError:
>>> >>>>>>>>>>
org/springframework/security/adapters/AbstractAdapterAuthe
>>> >>>>>>>>>> nti cati onToken
>>> >>>>>>>>>>
>>> >>>>>>>>>> And that happens because we think we didn't find the
>>> >>>>>>>>>> correct jar files for that framework and/or we missed
>>> >>>>>>>>>> something during the configuration of spring-security
>>> >>>>>>>>>> with tomcat.
>>> >>>>>>>>>>
>>> >>>>>>>>>> therefore, we removed the spring configuration from
tomcat
>>> >>>>>>>>>> and start the tomcat normally to see what will happen,
and
>>> >>>>>>>>>> we got the following error as the attached file.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Can you help us to pass this? It will be also helpful if
>>> >>>>>>>>>> you put all the required packages/software on the same
>>> >>>>>>>>>> directory on trac server.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Note: I have CCed our main developer working on this task
>>> >>>>>>>>>> so you can communicate with him directly, his name is
>>> >>>>>>>>>> "Wasim Naffar". Best regards,

>>> >>>>>>>>>>
>>> >>>>>>>>>> On 09/20/2011 10:25 PM, Feras Kamal wrote:
>>> >>>>>>>>>>> ----- Original Message -----
>>> >>>>>>>>>>> From: Solomon Blaz [mailto:sol...@solomonblaz.com]

>>> >>>>>>>>>>> Sent: Tuesday, September 20, 2011 07:46 AM
>>> >>>>>>>>>>> To:nanth...@earthlink.net
>>> >>>>>>>>>>>
<mailto:nanth...@earthlink.net><nanthracite@earthlink.
>>> >>>>>>>>>>> net
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> > <mailto:nanth...@earthlink.net> Cc: Feras
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Kamal;gli...@glilly.net
>>> >>>>>>>>>>> <mailto:gli...@glilly.net><gli...@glilly.net>
>>> >>>>>>>>>>> <mailto:gli...@glilly.net>; dlef...@orohosp.com
>>> >>>>>>>>>>> <mailto:dlef...@orohosp.com><dlef...@orohosp.com>
>>> >>>>>>>>>>> <mailto:dlef...@orohosp.com>; dalm...@e-cology.ca
>>> >>>>>>>>>>> <mailto:dalm...@e-cology.ca><dalm...@e-cology.ca>
>>> >>>>>>>>>>> <mailto:dalm...@e-cology.ca> Subject: Re: EDIS
>>> >>>>>>>>>>> without proprietary dependencies
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Hmmm, that sounds like you were on the right track to
me!
>>> >>>>>>>>>>> Maybe the VistALink listener was already installed in
>>> >>>>>>>>>>> VistA so you didn't need to the server part. The EDIS
>>> >>>>>>>>>>> web app is just like another client and should be able
>>> >>>>>>>>>>> to connect the same way the Java Swing Tester does. It
>>> >>>>>>>>>>> sounds to me like this part is working and we just need
>>> >>>>>>>>>>> to verify it.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> :)
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> After that, EDIS adds some setup on top of the base
>>> >>>>>>>>>>> VistALink for a special trusted "application user",
which
>>> >>>>>>>>>>> should be documented somewhere - I'd probably start by
>>> >>>>>>>>>>> looking in the EDIS install guide and see what it says.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> We'll need to talk one way or another to run everything
>>> >>>>>>>>>>> to ground, though, which is for the best - since it is a
>>> >>>>>>>>>>> higher bandwidth form of communication. :)
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Cheers,
>>> >>>>>>>>>>> Solomon
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Mon, Sep 19, 2011 at 8:12 PM, Nancy Anthracite
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> <nanth...@earthlink.net>
>>> >>>>>>>>>>> <mailto:nanth...@earthlink.net>
>>> >>>>
>>> >>>> wrote:
>>> >>>>>>>>>>>> I may not have it set up the way you need. I put
>>> >>>>>>>>>>>> VistALink Java on my client machines and then connected
>>> >>>>>>>>>>>> to the port on VistA on the server. I think I need to
>>> >>>>>>>>>>>> talk to you because it sounds like I need to put
>>> >>>>>>>>>>>> VistALink on the server.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> On Monday, September 19, 2011, Solomon Blaz wrote:
>>> >>>>>>>>>>>>> Feras (and others),
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Hello! Yes, certainly I can give you an update. My
>>> >>>>>>>>>>>>> apologies - the time I am able to spend on EDIS is
(and
>>> >>>>>>>>>>>>> will continue to be) limited. But the news is good!
>>> >>>>>>>>>>>>> I've got my quick outline from earlier as a basis for
>>> >>>>>>>>>>>>> a status update:

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 1. remove all dependencies of EDIS build scripts on VA
>>> >>>>>>>>>>>>> network infrastructure
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> This one is complete. Anyone can checkout the source
>>> >>>>>>>>>>>>> from subversion
>>> >>>>>>>>>>>>> athttps://trac.opensourcevista.net/svn/EDIS/trunk and
>>> >>>>>>>>>>>>> build EDIS without any hangups due to dependencies on
>>> >>>>>>>>>>>>> VA infrastructure.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> I've outlined the process here and am looking for
>>> >>>>>>>>>>>>> volunteers to try it
>>> >>>>>>>>>>>>>
out:https://trac.opensourcevista.net/svn/EDIS/trunk/jav
>>> >>>>>>>>>>>>> a/R EAD ME

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 2. potentially upgrade the build scripts to use the
>>> >>>>>>>>>>>>> latest version of Apache Maven
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> This is done. I ended up upgrading the build to
employ
>>> >>>>>>>>>>>>> the latest version of Apache Maven.

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 3. remove KAAJEE and its dependencies from the EDIS
web
>>> >>>>>>>>>>>>> application
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> This is also done. KAAJEE and its dependencies have
>>> >>>>>>>>>>>>> been eliminated. This means that EDIS can be deployed
>>> >>>>>>>>>>>>> on Tomcat, on any version of java (1.4 or later).

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 4. configure the EDIS web application to use the
>>> >>>>>>>>>>>>> spring-security based implementation in the
>>> >>>>>>>>>>>>> 'tracking-server-vista' module
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> I've stubbed in some preliminary glue to let users log
>>> >>>>>>>>>>>>> in to EDIS with spring-security on top of VistALink,
>>> >>>>>>>>>>>>> instead of KAAJEE. The login page is quite plain, and
>>> >>>>>>>>>>>>> the connection information to the M backend is baked
>>> >>>>>>>>>>>>> into the web app in a minimal but functional way, and
>>> >>>>>>>>>>>>> in theory it should work with an M backend, but that
>>> >>>>>>>>>>>>> has yet to be verified.

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 5. build the liberated EDIS web application
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> This works (see
>>> >>>>>>>>>>>>>
https://trac.opensourcevista.net/svn/EDIS/trunk/java/RE
>>> >>>>>>>>>>>>> ADM E), and the resulting EDIS main.war successfully
>>> >>>>>>>>>>>>> deploys on jetty and should also work on Tomcat.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> The java part of EDIS is now much more in line with
>>> >>>>>>>>>>>>> other standard java/Spring web applications, and
>>> >>>>>>>>>>>>> should now be much more accessible for other java
>>> >>>>>>>>>>>>> developers to pick up and run with. Its probably not
>>> >>>>>>>>>>>>> to the level of polish of off-the-shelf apps, but one
>>> >>>>>>>>>>>>> can start to work with the front end part of EDIS with
>>> >>>>>>>>>>>>> much less effort than before.

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 6. dance in the streets
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> This is still TBD. :)

>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 7. try it out, uncover next set of problems to solve,
>>> >>>>>>>>>>>>> discuss next steps
>>> >>>>>>>>>>>>>

>>> >>>>>>>>>>>>> It is now time for this step to expand into several
>>> >>>>>>>>>>>>> more. ;)
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> So I'd consider the current state of things to be
>>> >>>>>>>>>>>>> "ready for test". The front end builds and deploys,
>>> >>>>>>>>>>>>> but we haven't actually exercised the new
>>> >>>>>>>>>>>>> authentication mechanism against a running M backend.
>>> >>>>>>>>>>>>> It probably makes sense to do these things next:
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 1. set up tomcat on one of WorldVistA's servers for
>>> >>>>>>>>>>>>> test purposes 2. deploy the EDIS web application on it
>>> >>>>>>>>>>>>> 3. install VistALink in that instance of WorldVistA 4.
>>> >>>>>>>>>>>>> verify a successful connection to VistALink 5. install
>>> >>>>>>>>>>>>> the EDIS KIDS build in the same instance of WorldVistA
>>> >>>>>>>>>>>>> that has VistALink successfully running in it 6.
>>> >>>>>>>>>>>>> configure the EDIS/VistALink application user 7.
>>> >>>>>>>>>>>>> configure EDIS web application as necessary to make
>>> >>>>>>>>>>>>> the application work end-to-end
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> This would basically get us to the point where we have
>>> >>>>>>>>>>>>> a successfully running instance of EDIS that can be
>>> >>>>>>>>>>>>> looked at as an example. Nancy has already had some
>>> >>>>>>>>>>>>> success getting VistALink going, and I have attempted
>>> >>>>>>>>>>>>> to connect with VistALink's client side, but haven't
>>> >>>>>>>>>>>>> yet got it connecting all the way through. Its been
>>> >>>>>>>>>>>>> some years, but if I recall correctly, VistALink was
>>> >>>>>>>>>>>>> pretty fiddly and requires some patience when trying
>>> >>>>>>>>>>>>> to get it going. :) If anyone would like to volunteer
>>> >>>>>>>>>>>>> to try this out against their existing non-production
>>> >>>>>>>>>>>>> accounts, by all means, go for it, we'd love to know
>>> >>>>>>>>>>>>> what you discover.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> As always, please let me know how I can help.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Cheers,
>>> >>>>>>>>>>>>> Solomon
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> --
>>> >>>>>>>>>>>> Nancy Anthracite
>>> >>>>>>>>>
>>> >>>>>>>>> --
>>> >>>>>>>>> Nancy Anthracite
>>> >>>>
>>> >>>> --
>>> >>>> Nancy Anthracite
>>> >
>>> > --
>>> > Nancy Anthracite

[Wasim]

here we go,,

On Oct 9, 11:42 am, Wasim Naffar <w0795930...@gmail.com> wrote:
> Great;) the previous error has gone.
> but as you said we have other problem now and it is also a *j2ee runtime
> error*, you can find the attached files. I don't know if you mean the same
> one.
> so, after we troubleshooted the current issue with gtm, we found that j2ee
> application doesn't pass the "PARAMS" parameter to the EDPCTRL rpc.
> (i.e. the java sends it as empty value to gtm). you can check that.

> Regards,
> Wasim

> On Thu, Oct 6, 2011 at 6:35 PM, Solomon Blaz <solo...@solomonblaz.com>wrote:> Wasim,

> > This comes from a misconfiguration of the data access objects in the
> > data-access-config.xml. I wasn't passing in the
> > ConnectionFactoryLocator that looks up the connection info from the
> > vistalink-config.xml file. By default, EDIS would try to look that
> > stuff up in JNDI.

> > In any case, I've fixed the configuration error in the trunk (and
> > removed some old duplicated classes), so you can do an

> > svn update
> > and
> > mvn clean package

> > to build a new main.war with the latest stuff in it and this
> > particular problem should go away. After this, I'm still having
> > trouble getting EDIS RPCs to return anything, and will be interested
> > to see if you have the same trouble. I'm putting together a
> > command-line VistALink tester, but it'll be the weekend before I have
> > a chance to finish it.

> > Cheers,
> > Solomon

> > On Thu, Oct 6, 2011 at 8:17 AM, Wasim Naffar <w0795930...@gmail.com>
> > wrote:
> > > Hi Solomon and all,

> > > i reached to this point and it is a j2ee runtime error:
> > > Could not match stationNumber '100' to an institution mapping. find the
> > > attached files for full error log.
> > > anyone has any idea!!

> > > i traced the source code in that InstitutionMappingImpl class
> > > ,getJndiConnectorNameForInstitution method. what i found that the
> > > institutionMap (which is a TreeMap) dosn't have any element, and during
> > > runtime no call for the filler of this TreeMap. actually i got confused
> > > because the source code try to fill this institutionMap from "jndi
> > connector
> > > file" which doesn't not reach that statement in the source code.

> > > one question Solomon, do you have any idea if the jndi connector file has
> > > replaced with vistalink-config.xml??

> > > thanks in advance,

> > > Regards,
> > > Wasim



On Oct 4, 10:23 pm, Nancy Anthracite <nanthrac...@earthlink.net>
wrote:

> ----------  Forwarded Message  ----------
>
> Subject: Re: EDIS without proprietary dependencies
> Date: Tuesday, October 04, 2011

> From: Solomon Blaz <solo...@solomonblaz.com>

>
> Whoops I forgot a couple of steps, here's the revised instructions:
>
> install tomcat
> copy main.war and help.war to the tomcat "webapps" directory -
> /var/lib/tomcat6/webapps
> set VistALink connection info in
> /var/lib/tomcat6/webapps/main/WEB-INF/conf/vistalink-config.xml
> restart tomcat

> visithttp://localhost:8080/mainin your browser

>
> VistALink connection info includes hostname,port of VistALink
> listener,station number, and access/verify code pair for VistALink
> application user.
>
> Clear as mud?  ;)
>
> Cheers,
> Solomon
>

> On Tue, Oct 4, 2011 at 10:45 AM, Solomon Blaz <solo...@solomonblaz.com> wrote:
> > Nancy,
>
> > I think the easiest EDIS installation is:
>
> > install tomcat
> > copy main.war and help.war to the tomcat "webapps" directory

> > visithttp://localhost:8080/mainin your browser

> >>> >> 7300747www.ehs.com.jo<http://www.ehs.com.jo>

> >>> >>>>> 7300747www.ehs.com.jo<http://www.ehs.com.jo>

> >>> >>>>>> Naffar<wasim.naf...@ehs.com.jo

> >>> >>>>>>>>       <nanthrac...@earthlink.net>
> >>> >>>>>>>>       <mailto:nanthrac...@earthlink.net>

> >>> >>>>>>>>>>>       To:nanthrac...@earthlink.net
>
> <mailto:nanthrac...@earthlink.net><nanthracite@earthlink.>>> >>>>>>>>>>>       net
>
> >>> >>>>>>>>>>>       >  <mailto:nanthrac...@earthlink.net>   Cc: Feras

>
> >>> >>>>>>>>>>>       Kamal;gli...@glilly.net
> >>> >>>>>>>>>>>       <mailto:gli...@glilly.net><gli...@glilly.net>

> >>> >>>>>>>>>>>       <mailto:gli...@glilly.net>; dlefe...@orohosp.com
> >>> >>>>>>>>>>>       <mailto:dlefe...@orohosp.com><dlefe...@orohosp.com>
> >>> >>>>>>>>>>>       <mailto:dlefe...@orohosp.com>; dalmo...@e-cology.ca
> >>> >>>>>>>>>>>       <mailto:dalmo...@e-cology.ca><dalmo...@e-cology.ca>
> >>> >>>>>>>>>>>       <mailto:dalmo...@e-cology.ca>    Subject: Re: EDIS

> >>> >>>>>>>>>>>       without proprietary dependencies
>
> >>> >>>>>>>>>>>       Hmmm, that sounds like you were on the right track to
> me!
> >>> >>>>>>>>>>>       Maybe the VistALink listener was already installed in
> >>> >>>>>>>>>>>       VistA so you didn't need to the server part.  The EDIS
> >>> >>>>>>>>>>>       web app is just like another client and should be able
> >>> >>>>>>>>>>>       to connect the same way the Java Swing Tester does.  It
> >>> >>>>>>>>>>>       sounds to me like this part is working and we just need
> >>> >>>>>>>>>>>       to verify it.
>
> >>> >>>>>>>>>>>       :)
>
> >>> >>>>>>>>>>>       After that, EDIS adds some setup on top of the base
> >>> >>>>>>>>>>>       VistALink for a special trusted "application user",
> which
> >>> >>>>>>>>>>>       should be documented somewhere - I'd probably start by
> >>> >>>>>>>>>>>       looking in the EDIS install guide and see what it says.
>
> >>> >>>>>>>>>>>       We'll need to talk one way or another to run everything
> >>> >>>>>>>>>>>       to ground, though, which is for the best - since it is a
> >>> >>>>>>>>>>>       higher bandwidth form of communication.  :)
>
> >>> >>>>>>>>>>>       Cheers,
> >>> >>>>>>>>>>>       Solomon
>
> >>> >>>>>>>>>>>       On Mon, Sep 19, 2011 at 8:12 PM, Nancy Anthracite
>

> >>> >>>>>>>>>>>       <nanthrac...@earthlink.net>
> >>> >>>>>>>>>>>       <mailto:nanthrac...@earthlink.net>

[Solomon Blaz]

Hi Wasim,

Thanks for your all of your effort trying to track this down. You are
now at the same point we are (with the same error), so if we break
through with a solution it should happen for both of us. :)

I spent the weekend away from computers so haven't had a chance to
finish a little testing application to verify my theory that the
problem is in how VistALink was ported to GTM from Intersystems Cache.
I suspect that ALL parameters aren't getting passed from the thing
that processes the TCP/IP connections into the thing that calls the
RPC routine, but not knowing anything about it all we can do is to try
to isolate it.

Speaking to some folks around here for clues, one possible avenue to
research is the script that sits between the operating system and
VistA handling network traffic. They thought that as long as GTM
exposes a network device to VistA, we should be fine without the
script and just let M handle network connections. Apparently this
isn't possible in DSM because of the large difference in speed between
VMS network handling and M I/O. So at least with Caché on Linux, we
always ran VistALink's listener inside VistA itself and it was fine.
Anyone know much about GTMs networking capabilities, or somewhere we
can RTFM?

Cheers,
Solomon

> --
> You received this message because you are subscribed to the Google Groups "VistA Emergency Room" group.
> To post to this group, send email to vista-emer...@googlegroups.com.
> To unsubscribe from this group, send email to vista-emergency-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/vista-emergency-room?hl=en.
>
>

[Nancy Anthracite]

Solomon, the RPC Broker and the swing tester both get handled with XINETD.

If you look at the directory /etc/xinetd.d/ you will see a script that hands
the input off to a script at the user level that hands it off to a routine.
From TCPdump, it looks like nothing ever even gets to the port.

I have to run. I will give you more details later although Khamis may beat me
to it.

> >> >>> >>>>>>>> g .xml

--
Nancy Anthracite

[Solomon Blaz]

Yes, that is awfully suspicious, especially since EDIS is receiving an
error message from M about undefinied variables. Perhaps its getting
through on some other port somehow?

I'm pretty sure xinetd is the right place to start poking around,
though I have to admit I'm out of my element there.

Thanks as always,
Solomon

[Nancy Anthracite]

I understand your suspicions, but we are getting data in from the Swing
Tester. Perhaps what I was doing to test when I as doing the dump was not done
right with EDIS.

Since virtually nothing is going in that port unless the swing tester is used,
I can set up a packet grabber on the port so that when you get a chance, you
can run it and see.

What I was doing was bringing up Tomcat and logging in and trying to capture
the packets then. What that the wrong thing to try?

Skip helped me look as well.

One thing I wondered is if there is some other place in all of this code that
you set a port and the default is the usual VistALink port. I can try to put
this listener on that port if I know what the default is.

> >> >> >>> >>>>>>>> fi g .xml

> >> >> >>> >>>>>>>>>>>>> d build EDIS without any hangups due to

--
Nancy Anthracite

[Nancy Anthracite]

That you set a port did not really necessarily mean you, Solomon. It was a
very poor choice of words. I should have said "someplace that a port is set".

> > >> >> >>> >>>>>>>> on fi g .xml

> > >> >> >>> >>>>>>>>>>>>> an d build EDIS without any hangups due to

[Nancy Anthracite]

If I understand what you are asking, I think I might have a slightly different
than expected response that might be wrong, so I leave it to the Java guys to
tell you if I am all wet.

I think that EDIS uses an application server called Tomcat that is on the
server where xinetd is working and the Swing Tester is an entirely different
sort of a way to handle this. Tomcat, to me, is like a special Apache with
more horsepower to handle lots of Java applications. Java is installed on the
server.

With the Swing Tester, Java is installed on the client machine and the
rendering is done there and I guess in that sense it is more like CPRS sending
out RPCs to a remote server. With Tomcat it is done through a browser
connecting to the server and Tomcat uses the browsers capability to render the
GUI on the client machine.

I think they both go to the same port, and the Swing Tester seems to me to be
getting data in and out but the Tomcat method isn't. The Tomcat method feeds
the data to the port from 127.0.0.1 and the Swing Tester feeds it to the port
from the IP of my laptop.

Normally I test xinetd from the command line by telneting to the same port
that CPRS uses from the command line and using 127.0.0.1, so xinetd definitely
can listen to the local machine as well as the remote machine as long is the
port is not set to block.

OK, Java guys, where did I get this wrong?

On Tuesday, October 11, 2011, Skip Ormsby wrote:
> Is the 'swing tester' a short cut?

> > > >> >> >>> >>>>>>>> -c on fi g .xml

> > > >> >> >>> >>>>>>>>>>>>> nk an d build EDIS without any hangups due to

[Wasim Naffar]

Nancy, you are right according to the definition for both the SwingTester client & Tomcat, but what i would like to mention is:
you can install Tomcat on a different machine like what i did. find the bellow scenario:
- installed the tomcat including EDIS, on machine for example 192.168.0.100.
- open EDIS from browser from any other machine on my network like 192.168.0.101.
- installed vistALink on 192.168.0.102 where xinetd and gtm is working.
what i mean is, if you install Tomcat on different machine, then the Tomcat will feed the data to the vistaLink port from different IP not local-IP.

and please note that tomcat uses TCP/IP to connect to vistalink, but swingTester client may use TCP or may use UDP protocol to send and receive data, but i guess it uses TCP cause it uses the same vljConnector-1.5.0.026.jar which EDIS using it also, but let me check that.
plus keep in mind that we can run vistalLink service without xinetd, that means can directly connect to the vistaLink service without passing from xinetd.
so, currently we are running vistALink without configure it with xinetd and will trace the vistALink side to see if we can find somewhere that logs the received packets.

Regards,
Wasim

[Nancy Anthracite]

XINETD is set up like this so maybe it has the wrong or not enough protocols
like you suggested, so I added IP and UDP:

tm:/etc/xinetd.d# cat vademo4-09VistALink
service vademo4-09VistALink
{
port = 9310
socket_type = stream
protocol = udp tcp ip
user = vademo4-09
server = /home/vademo4-09/EHR/VistALinkConnect.sh
type = UNLISTED
wait = no
disable = no
}

Then I got the same error but the good news is the swing tester still works
even though the listener says it is listening only as tcp but the tcp protocol
is listed after the udp under protocol, so I assume it really is handling more
than one protocol.

BUT, when I put in the wrong access and verify code, looks what comes back! To
me this means that like you said, Wasim, that it is getting in there and it is
probably not by going through xinetd. And if it knows the access and verify
is wrong, doesn't that mean there is something being delivered? Or am I
missing the point??

> > > > > >> >> ml restart tomcat

[Nancy Anthracite]

The way things are on the demo machine I have now for the demo, Tomcat is
listening on port 9312 and so is VistALink. Is that the way it should be?

> > > > > > >> >> .x ml restart tomcat

[Solomon Blaz]

Hello everyone,

It sounds to me like you've got the basic picture, Nancy. If tomcat
and VistALink are on the same machine, they can't use the same port.
I think the way you set it up at first you had VistALink on port 9310,
and tomcat on port 9312. I don't remember if we had them on the same
machine or not. The traffic you would want to capture with tcpdump is
not the traffic between your browser and tomcat, but between the web
application running in tomcat and VistALink.

Out of curiousity, what RPC are you calling with the swing tester? Is
it one that takes parameters/arguments?

I've almost got a little command line vistalink tester ready to go,
hopefully tonight after the day job I can finish it up and send it
out. Then we can all try calling various RPCs with arguments directly
and see what happens.

Wasim, did you have some success setting up VistALink without xinetd
(and therefore without VistALinkConnect.sh)?

Cheers,
Solomon

On Wed, Oct 12, 2011 at 8:59 AM, Nancy Anthracite

[Nancy Anthracite]

I had two VistALinks running, one for wvehr3-09 and one for vademo4-09 so that
is why there was confusion about the two ports.

So how is Tomcat going to know which VistALink to use? I have to point it at
a port because I have multiple instances of VistA running on this machine and
that is how I keep them all in their own place. Each is installed under a
different Linux user. The only thing they might share is GT.M. They all have
separate instances of Mailman and the HL7 listener, etc.

On Wednesday, October 12, 2011, Solomon Blaz wrote:
> Hello everyone,
>

> >> > > > > > >> >> fig .x ml restart tomcat

> >> > > > > > >> >> cep t>

> >> > > > > > >> >> /RE A

> >> > > > > > >> >> >>> >>>>>>>>>>> .ne t>

--
Nancy Anthracite

[Wasim Naffar]

new news :):)
We troubleshooted the vistALink side with our mumps expert "Sharaf", he did many things on that mumps routines like escape the undefined variable error, escape the authentication codes and some other modifications just to reach and pass to the next step, and the result was not bad.
finally we see new EDIS page that said "Version Incompatibility", find attached files,
1st attached "Version_Incompatibility.png"  about the EDIS version is not compatable with vistA server, therefore only we tried to change the version number in vistA then we got the 2nd attached "Version_Incompatibility_2.png", which is a flash page (swf action script), but also displayed "version incompatibility", we also changed it on vistA side and refreshed the browser but we got blank flash page on browser,

we traced the log on Tomcat and the code in mumps and we found that until this step the vistA returned this response  "
 'EDPCBRD RPC' returned: <user area="1" areaNm="Emergency Department" version="1
.0" />" to EDIS, but EDIS did nothing after that.... solomon if you want i can send you the tomcat consol log to see what happened if that may help.

next step, we will try to trace the EDIS -java and action script(as) source code- to find why and how the java behave after this response came from vistA.

I think now we need to ask someone about those different versions may can give us any hints that will help us.

Nancy, it doesn't make any sense if you installed Tomcat at the same or different machine, just as solomon said if they are in the same machine must be on diff ports.
I guess the problem is in the gtm code, that what we are trying to fix now and what we already fixed, and maybe after that we will face a problem somewhere else and may need to do some modifications on the EDIS source code also... maybe.

Solomon, actually we still working with xinetd, but i think it doesn't make any sense if we run through or without.

 
Regards,
Wasim

[Nancy Anthracite]

Even if you don't need xinetd, whiat it does form me is provide a directory to
look in to see what services are running to each instance of vista on what
port. As we pile more and more instances on to one server for training and
development, it helps me keep my sanity! So I hope you will at least leave
that option open as you go ahead with this.

[Solomon Blaz]

On Wed, Oct 12, 2011 at 10:41 AM, Wasim Naffar <w0795...@gmail.com> wrote:
> new news :):)
> We troubleshooted the vistALink side with our mumps expert "Sharaf", he did
> many things on that mumps routines like escape the undefined variable error,
> escape the authentication codes and some other modifications just to reach
> and pass to the next step, and the result was not bad.
> finally we see new EDIS page that said "Version Incompatibility", find
> attached files,
> 1st attached "Version_Incompatibility.png"  about the EDIS version is not
> compatable with vistA server, therefore only we tried to change the version
> number in vistA then we got the 2nd attached
> "Version_Incompatibility_2.png", which is a flash page (swf action script),
> but also displayed "version incompatibility", we also changed it on vistA
> side and refreshed the browser but we got blank flash page on browser,

AWESOME! You guys are ahead now, very exciting! So you're into the
EDIS user interface now, which is very cool!

> I think now we need to ask someone about those different versions may can
> give us any hints that will help us.

This part I know a little about. :) So EDIS is like CPRS in that it
checks that the version of the user interface it is serving up matches
the version installed on the server in VistA. When there is a
mismatch, you get the first version incompatibility message you saw.
The client version is "baked" into the .war file, set in all the maven
pom.xml files that describe the build. The server version is set in a
menu option somewhere, I believe. It sounds like you were able to
change that successfully, producing the second error message. When I
removed KAAJEE from the client side of EDIS, I set the client version
number to "1.0.1.WorldVistA-SNAPSHOT" to distiguish it from EDIS 1.0.
I think you're getting the second error because I forgot to change the
version number in one spot inside the Flex application. So, we can
either set the version number back to "1.0", or update that one spot
to "1.0.1.WorldVistA-SNAPSHOT" to get this to go to the next step. Do
you have a preference?

The line in question is at:
https://trac.opensourcevista.net/browser/EDIS/trunk/java/tracking-ui-core/src/main/flex/gov/va/med/edp/model/TrackingModelLocator.as#L57

It should read:
public var appClientVersion: String = "1.0.1.WorldVistA-SNAPSHOT";

I'll go ahead and commit this change to subversion to help get things
running for now, but we should think about what to set this to, to
make the installation process easiest in the future.

> Nancy, it doesn't make any sense if you installed Tomcat at the same or
> different machine, just as solomon said if they are in the same machine must
> be on diff ports.
> I guess the problem is in the gtm code, that what we are trying to fix now
> and what we already fixed, and maybe after that we will face a problem
> somewhere else and may need to do some modifications on the EDIS source code
> also... maybe.
>
> Solomon, actually we still working with xinetd, but i think it doesn't make
> any sense if we run through or without.

If you all are using xinetd successfully with CPRS and the RPC Broker
listener, then I don't see why it wouldn't work with VistALink - I was
thinking that the parameters that should get passed through to the
Remote Procedures weren't getting sent through by the code that sits
between xinetd and GTM. Did I understand you correctly that when you
"escaped" the undefined variables that you actually got them coming in
successfully from the EDIS client? Or have you put in a stopgap that
sets the undefined variables just to get it through to the next thing?

Little command-line tester .jar almost ready. Will post it here when
its passble. Also, ran into some issues with the age of some of the
EDIS java libs (servlet 2.3, spring 2.0). Wasim, do you have any
problems with me upgrading the web app to servlet 2.5 and spring 3.0
so we're on more modern and still supported APIs?

news, news, indeed! :)

Cheers,
Solomon

[Solomon Blaz]

On Wed, Oct 12, 2011 at 10:41 AM, Nancy Anthracite
<nanth...@earthlink.net> wrote:
> I had two VistALinks running, one for wvehr3-09 and one for vademo4-09 so that
> is why there was confusion about the two ports.

Aha! makes sense!

> So how is Tomcat going to know which VistALink to use?  I have to point it at
> a port because I have multiple instances of VistA running on this machine and
> that is how I keep them all in their own place.  Each is installed under a
> different Linux user.  The only thing they might share is GT.M.  They all have
> separate instances of Mailman and the HL7 listener, etc.

Tomcat/EDIS uses the port that is set in the vistalink-config.xml...
Is the vademo4-09 still listening on 9310?

Cheers,
Solomon

[Nancy Anthracite]

Yes, it is, but I can move it to another port. Let's assume it will be
9314 because I think that one is not in use but available. I will
confirm it shortly.

--
Nancy Anthracite

[Nancy Anthracite]

OK, the port for the vademo4-09 with xinetd for VistALink is 9314 and
the port for /var/lib/tomcat6/webapps/main/WEB-INF/config/vistalink-
config.xml is 9310

[Nancy Anthracite]

http://openforum.opensourcevista.net:9312/main/login.html is what is
working, Solomon, but the config file says

gtm:/home/nancy# cat /var/lib/tomcat6/webapps/main/WEB-
INF/config/vistalink-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.0.xsd">

<util:set id="vistaAccounts">
<bean
class="gov.va.med.edp.vistalink.locator.VistaLinkConnectorConfig">
<property name="host" value="127.0.0.1"/>

<property name="port" value="9310"/>
<property name="name" value="WORLDVISTA DEMO CLINIC"/>
<property name="primaryStation" value="500"/>

<property name="accessCode" value="EDISUSER1"/>
<property name="verifyCode" value="VISTAIS#1"/>
</bean>
</util:set>

</beans>

So VistALink and Tomcat were not listening on the same port after
all. You might want to change the config file or restart tomcat, you
choice.

[Solomon Blaz]

I see! So right now, tomcat is listening for http traffic on 9312,
and VistALink is listening for VistALink traffic on 9314. Yeah, I'll
update the main.war here pretty soon.

[Wasim Naffar]

Hi Solomon,

actually I think we will not face any problem if you make this upgrade(servlet 2.5 and spring 3.0). you can do this upgrade then we will download your changes from svn and build the .war again to see what will happen.


Regards,

Little command-line tester .jar almost ready.  Will post it here when
its passble.  Also, ran into some issues with the age of some of the
EDIS java libs (servlet 2.3, spring 2.0).  Wasim, do you have any
problems with me upgrading the web app to servlet 2.5 and spring 3.0
so we're on more modern and still supported APIs?

news, news, indeed!  :)

[Solomon Blaz]

Wasim,

Great, it'll be a little while before I'm able to do this upgrade, but in the meantime go ahead and do an svn update to get the latest from the trunk - I committed that change with respect to the version number mismatch problem you were seeing and would love to know what happens next!  :)

Thanks,

Solomon

[Wasim Naffar]

Hi all,

Sorry last week we were so busy with other issues related to Our Hakeem project in Jordan, and we don't have enough time to continue in EDIS.

Solomon, If you remember we reached to the flash page, and we got a blank flash page.
We use firefox 7.1, flash player 10, so we installed firebug & flashbug which has flash trace (trace log) to see if there is any error from flash, and we got the following:

--------------------------------------------------
XML Parsing Error: no element found
Location: moz-nullprincipal:{5ce33f00-2ae8-42a8-8e5b-b08319e25023}
Line Number 1, Column 10: [<results>]
  <user countDown="60000" duz="1230" progMode="0" rptExport="0" rptProvider="0" rptXRef="0" site="68" siteNm="PRINCE HAMZAH HOSPITAL" station="100" time="3111023.1033" timeOut="1200000" userNm="WAS,WAS VLT" version="1.0.1.WorldVistA-SNAPSHOT"/>
---------------------------------------------------

you can find the attached for more details.
do you have any idea about that!!! anyone can help!!!


Regards,
Wasim

[Wasim Naffar]

Hello Solomon,

currently we are suspending at this point:
after login successfully we traced a part in the Flex application which is "XMLResultFormattingResponder"-"function result(data:Object)", and we found that the Flex application receives two xml responses as below

1st one is

<?xml version='1.0' encoding='UTF-8'?>

<results>
<user countDown="60000" duz="1230" progMode="0" rptExport="0" rptProvider="0" rptXRef="0" site="68" siteNm="PRINCE HAMZAH HOSPITAL" station="100" time="3111025.101956" timeOut="1200000" userNm="WAS,WAS VLT" version="1.0.1.WorldVistA-SNAPSHOT" ></user>
 
</results>

and, the 2nd one is

<?xml version='1.0' encoding='UTF-8'?>

<results>
<user area="1" areaNm="Emergency Department" version="1.0.1.WorldVistA-SNAPSHOT" />
 
</results>


actually, after Flex application receives those xml and call
responder.result(new ResultEvent(ResultEvent.RESULT, resultEvent.bubbles, resultEvent.cancelable, xml, resultEvent.token, resultEvent.message));
nothing has reflect to the browser, only blank flash page appear on the browser, so we tried many times to change the values of the xml attributes hardcoded inside the Flex application, just to see if anything will happen but nothing change. Only if I change version="1.0.1.WorldVistA-SNAPSHOT" to be something different i got the same incompatibility error as before. therefore everything is well, but i guess something missing in the xml body or somewhere else!!!

Do you have any idea if the Flex application is waiting other xml response or other values? Any example of what those xml should look like(values)!!, any screenshots of the first flash contents. actually I don't have any idea of what this flash page will display. Anyone can help?

Thanks in advance,

Regards,

[Nancy Anthracite]

As I recall, Solomon said he would not be in town this week so I expect he
won't be getting this until the weekend.

--
Nancy Anthracite

[Solomon Blaz]

Indeed, I am traveling... :)

Wasim, that looks like valid XML to me. I agree with your suspicion that there might be something missing from the body, but my memory is poor and I can't remember what it might be. I vaguely remember something in the install guide about assigning yourself options and then rebuilding menus before it would work the first time. Does that sound familiar?

Out of curiosity, how did you get VistALink working in your account? It would be very helpful in reproducing bugs if we could get that going in a demo VistA account.

I return home Monday, when I may be able to spend some time on this again. :)

Take care,
Solomon

[Wasim Naffar]

Finally it is working well,, horreyy.. :):):)

After navigated through the flex application source code, as expected, we got that  xml response still missing something, and there was an Array in the Flex application still as empty, so filled it hardcoded. from 1 - 9 ...,
then we got the right xml response and it looks as below:

<results>
  <user countDown="60000" duz="1230" progMode="0" rptExport="0" rptProvider="0" rptXRef="0" site="68" siteNm="PRINCE HAMZAH HOSPITAL" station="100" time="3111029.220434" timeOut="1200000" userNm="WAS,WAS VLT" version="1.0.1.WorldVistA-SNAPSHOT"/>
  <view data="1" label="Sign In"/>
  <view data="2" label="Triage"/>
  <view data="3" label="Update"/>
  <view data="4" label="Disposition"/>
  <view data="5" label="Edit Closed"/>
  <view data="6" label="Display Board"/>
  <view data="7" label="Assign Staff"/>
  <view data="8" label="Reports"/>
  <view data="9" label="Configure"/>
</results>

after all of that, we got the first lovely screen on the browser and the first hint; therefore we understood that there is something missing from VistA side.
You are soo close Solomon:), we found that we need to assign EDIS Views to Users, which is described in the edp technical manual (7.2. Include EDIS Options in Users’ Menu Trees) - edp_tm.pdf.

find attached for some screenshots, I took for you :):)

Solomon & Nancy, I will send you the full details and complete steps for what we did in the VistA side. actually i didn't do that by myself in the GT.M, but our M expert who helped me and did that in GT.M Side. so I will take a full logs from him and will send you back immediately. What I remember that he did two things, stop the undefined variable error from GT.M, and escaped some lines in some M routines,
also after display the flash pages we faced other error from GT.M  and already we fixed that, so I will send you all of that in a brief doc to be as reference for all of us.

many thanks for all of you for the hard effort and help,

Cheers :):)
Wasim

[Nancy Anthracite]

FANTASTIC! We were working on this today also at our call And after the call
I had been pouring over the installation manual and putting in parameters and
getting nowhere. I gave up and took a nap and magic happened while I slept!!

WOW!

I am so glad you got it!

Congratulations!! Now for me to settle down and read this so we can get it,
too. :-))))))!

[Joseph Dal Molin]

Mabrook (congratulations) to everyone ... this is terrific example of
international collaboration!!!

Joseph

> EDIS Options in Users� Menu Trees) - edp_tm.pdf.

> <w0795...@gmail.com <mailto:w0795...@gmail.com>>wrote:

> > <sol...@solomonblaz.com <mailto:sol...@solomonblaz.com>>wrote:

> > >>> Wasim,
> > >>>
> > >>> Great, it'll be a little while before I'm able to do this
> upgrade, but
> > >>> in the meantime go ahead and do an svn update to get the latest
> from
> > >>> the trunk - I committed that change with respect to the version
> number
> > >>> mismatch problem you were seeing and would love to know what
> happens
> > >>> next! :)
> > >>>
> > >>> Thanks,
> > >>> Solomon
> > >>>
> > >>> On Mon, Oct 17, 2011 at 1:14 AM, Wasim Naffar

> > <w0795...@gmail.com <mailto:w0795...@gmail.com>>wrote:

> > >>>> Hi Solomon,
> > >>>>
> > >>>> actually I think we will not face any problem if you make this
> > >>>> upgrade(servlet 2.5 and spring 3.0). you can do this upgrade
> then we
> > >>>> will download your changes from svn and build the .war again
> to see
> > >>>> what will happen.
> > >>>>
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Little command-line tester .jar almost ready. Will post it
> here when
> > >>>> its passble. Also, ran into some issues with the age of some
> of the
> > >>>> EDIS java libs (servlet 2.3, spring 2.0). Wasim, do you have any
> > >>>> problems with me upgrading the web app to servlet 2.5 and
> spring 3.0
> > >>>> so we're on more modern and still supported APIs?
> > >>>>
> > >>>> news, news, indeed! :)
> > >>>>
> > >>>> On Sun, Oct 16, 2011 at 10:20 PM, Solomon Blaz

> > <sol...@solomonblaz.com <mailto:sol...@solomonblaz.com>>wrote:

> > >>>>> On Wed, Oct 12, 2011 at 10:41 AM, Wasim Naffar

> <w0795...@gmail.com <mailto:w0795...@gmail.com>>

> <mailto:vista-emer...@googlegroups.com>.

> > >>>>> To unsubscribe from this group, send email to
> > >>>>> vista-emergency-...@googlegroups.com

> <mailto:vista-emergency-room%2Bunsu...@googlegroups.com>.

> > >>>>> For more options, visit this group at
> > >>>>> http://groups.google.com/group/vista-emergency-room?hl=en.
> > >>>>>
> > >>>> --
> > >>>>
> > >>>> You received this message because you are subscribed to the Google
> > >>>> Groups "VistA Emergency Room" group.
> > >>>> To post to this group, send email to
> > >>>> vista-emer...@googlegroups.com

> <mailto:vista-emer...@googlegroups.com>.

> > >>>> To unsubscribe from this group, send email to
> > >>>> vista-emergency-...@googlegroups.com

> <mailto:vista-emergency-room%2Bunsu...@googlegroups.com>.

> > >>>> For more options, visit this group at
> > >>>> http://groups.google.com/group/vista-emergency-room?hl=en.
> > >>>>
> > >>> --
> > >>>
> > >>> You received this message because you are subscribed to the Google
> > >>> Groups "VistA Emergency Room" group.
> > >>> To post to this group, send email to
> > >>> vista-emer...@googlegroups.com

> <mailto:vista-emer...@googlegroups.com>.

> > >>> To unsubscribe from this group, send email to
> > >>> vista-emergency-...@googlegroups.com

> <mailto:vista-emergency-room%2Bunsu...@googlegroups.com>.

> > >>> For more options, visit this group at
> > >>> http://groups.google.com/group/vista-emergency-room?hl=en.
> >
> >
> > --
> > Nancy Anthracite
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "VistA Emergency Room" group.
> > To post to this group, send email to
> vista-emer...@googlegroups.com

> <mailto:vista-emer...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> vista-emergency-...@googlegroups.com

> <mailto:vista-emergency-room%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> http://groups.google.com/group/vista-emergency-room?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "VistA Emergency Room" group.
> To post to this group, send email to
> vista-emer...@googlegroups.com

> <mailto:vista-emer...@googlegroups.com>.

> To unsubscribe from this group, send email to
> vista-emergency-...@googlegroups.com

> <mailto:vista-emergency-room%2Bunsu...@googlegroups.com>.

[Sam Habiel]

Good job Wasim.

Sam

>> EDIS Options in Users’ Menu Trees) - edp_tm.pdf.

[Wasim Naffar]

Thank you all:), and special thanks for Solomon & Nancy. Actually with your support and your help we reached to that.
Thanks again,,, hope to keep in touch

Regards,
Wasim

[Feras Kamal]

Thanks to all the folks in the vistA community along with the EHS software team..... It is really great success.

Feras

-----Original Message-----
From: vista-emer...@googlegroups.com [mailto:vista-emer...@googlegroups.com] On Behalf Of Joseph Dal Molin
Sent: Sunday, October 30, 2011 12:42 AM
To: vista-emer...@googlegroups.com
Subject: Re: [vista-emergency-room] Re: Fwd: Re: EDIS without proprietary dependencies

Joseph

> EDIS Options in Users' Menu Trees) - edp_tm.pdf.

[Solomon Blaz]

AWESOME!

I think I shall go do a little dance in the street... :)

Great job Wasim and team, Nancy, Skip, everybody!

Hooray!

Cheers,
Solomon

[Wasim Naffar]

Thank you Solomon :)

Sorry for the delay on the updates on G.TM for you, but actually they compile,test those patches and updates, plus we are working on Arabic issue for EDIS.

Currently, we have an issue for the Charset encoding. As you know we use Arabic characters to send or retrieve data from Vista.
So we need to change the Charset for the EDIS to be windows-1256. Already i tried to find the way to change the Charset encoding in the java side as bellow:
        request.setCharacterEncoding("windows-1256");
        response.setCharacterEncoding("windows-1256");
for the TrackingController class and other servlets. At this moment just i want to test the request case from browser to vista. and make sure that the arabic send correctly to G.TM.
still noting change.

I guess we need this change in vljConnector package, because this package is responsible to open and connect to G.TM. As you know we don't have the source code for that jar file.

Do you have any idea of how or where we can change the charset encoding from EDIS !!!!!

Thanks in advance,

Regards,
Wasim

Cheers,
Solomon

--
You received this message because you are subscribed to the Google Groups "VistA Emergency Room" group.

[Nancy Anthracite]

No source code sounds like I need to do something.

What exactly are you missing? Is it VistALink source code or EDIS source
code?

--
Nancy Anthracite

[Nancy Anthracite]

I am afraid Vitalia Devlin could not help us on this one. I just submitted a
FOIA request for VistALink 1.5 and 1.6 (assuming there is a library for 1.6)
library jar files.

[Sam Habiel]

Nancy

Wasim can correct me if I am wrong, but I believe that .jars already
contain the source code.

Sam

[Nancy Anthracite]

It would not be the first request I have withdrawn if that is true!

--
Nancy Anthracite

[Wasim Naffar]

Sam,
You are right, and already I used a java decompiler tool to get that source code, but unfortunately i didn't get clear source code, i guess they use obfuscate the contents of the jar, that is why i request the source code.
From my side still searching to get that, but this is not guaranteed.


Regards,
Wasim

[Nancy Anthracite]

Just to be sure, what you need is not here?

http://opensourcevista.net:8888/NancysVistAServer/VistALink1.5/XOB_1_5.ZIP

[Sam Habiel]

FYI: Nancy, the entire next week is a Holiday in Jordan.

On Sat, Nov 5, 2011 at 7:22 AM, Nancy Anthracite

[Nancy Anthracite]

Thanks, Sam.

--
Nancy Anthracite

[John McCormack]

Yeah, it's in a special hidden directory with the obscure name src under jars directory.

[Nancy Anthracite]

Well, it was hidden because they didn't know to look there!

I was digging about hunting for the 1.6 code today, and it referenced kids
build I could not find for VistALink 1.5, which got me hunting and I found
this and it did look promising.

This file is also on http://downloads.va.gov.

So if we are sure we have what they need, I will withdraw the FOIA request. In
the meantime, I will let Vitalia and the FOIA office know we may have found it
until the vacation is over.

On Saturday, November 05, 2011, John McCormack wrote:
> Yeah, it's in a special hidden directory with the obscure name src under
> jars directory.
>
> On 11/5/2011 6:14 PM, Nancy Anthracite wrote:
> > Thanks, Sam.
> >
> > On Saturday, November 05, 2011, Sam Habiel wrote:
> >> FYI: Nancy, the entire next week is a Holiday in Jordan.
> >>
> >> On Sat, Nov 5, 2011 at 7:22 AM, Nancy Anthracite
> >>
> >> <nanth...@earthlink.net> wrote:
> >>> Just to be sure, what you need is not here?
> >>>
> >>> http://opensourcevista.net:8888/NancysVistAServer/VistALink1.5/XOB_1_5.

> >>> ZI P

--
Nancy Anthracite

[Solomon Blaz]

Yup, the VistaLink source is in the spot John pointed out...

Wasim, it looks like you might be able to change the character
encoding in the gov.va.med.net.SocketManager - that looks like where
they are reading/writing bytes to/from sockets... :)

Cheers,
Solomon

[Wasim Naffar]

Hi all,
hope you doing well.

Sorry but we were in vacation last week in Jordan.

We still working on the last issue "charecter encoding".
Solomon was right:), i found that class gov.va.med.net.SocketManager in the "vljFoundationsLib-1.5.0.026.jar"  and I replaced the charset from Cp1252 to Cp1256 for both writer & reader. After that the arabic chars from browser to vista is clear and valid.
but the problem now in the display at browser, the arabic characters appear as question marks ????? -rubbish data- .

Solomon, I checked that the response xml from vistA to J2ee is correct and it is not rubbish, but when send from j2ee to Flex here is the problem!!  do you have any idea where I need to change?!! in the j2ee or may in Flex side!!
 
thanks in advance,

Regards,
Wasim

[Nancy Anthracite]

Did you see my email about the source code in the .jars? The VA folks are
waiting to find out if we have what we need or not.

[Solomon Blaz]

Nancy,

I believe that we have the java source to VistALink's java bits and
shouldn't require anything else from VA at this time. Thanks for your
follow-through.

Wasim,

I think you're on the right track. EDIS is 3-tiered and so has two
potential network jumps for character encoding to take effect...
You've already cracked the one between VistA/Java... I can't remember
exactly where the character encoding/decoding happens on its way from
the servlet app to Flex - I'd guess that its going out as UTF-8,
though. I'll have to dig around a bit to find that out for you.

Cheers,
Solomon

On Tue, Nov 15, 2011 at 5:48 AM, Nancy Anthracite

[Nancy Anthracite]

Good timing! I just got an email from Vitalia asking if we were set or not.
Now I can thank them and let them close out that request.

--
Nancy Anthracite

[Wasim Naffar]

Hello Solomon,

Finally I catch it ;)
 
In the gov.va.med.edp.web.controller.TrackingController.java, which is in the tracking-server-core module,
I found the response charset was ISO-xxxx, that was the problem.
just inside the handleRequestInternal() method I set the response.setCharacterEncoding("UTF-8");

Happily, Arabic language is working well with ER ;):)

so, now we are writing and documenting our changes and logs for both server application EDIS, and VistA side,
which we will submit and share with you after we finished and test it immediately.

Nancy,
for the help.war, there is an image folder missing, can you ask VA about that?

many thanks all,

Cheers,
Wasim

[Solomon Blaz]

Awesome!  That TrackingController sounds vaguely familiar.  Excellent work!

[Nancy Anthracite]

Give me as much detail as you can about the help.war and where the image
folder is located so I can help Vitalia find it, please.

[Wasim Naffar]

Hi Nancy,

Actually we can say that the help.war is a user guid for the EDIS users, where the users can open it from EDIS browser and will display in the browser also.

see attached , screenshots for the help application and the icon on the EIDS that open the help browser.
maybe that will be more clear.

the help.war is one of the EDIS modules which is a j2ee application, will deploy on tomcat too.
it's path in the repository is https://trac.opensourcevista.net/svn/EDIS/trunk/java/tracking-help

you can imagine it as folder called help and this help folder has subfolder called images, this images folder is not exist inside this help folder.


Nancy, can you send "Ahmad" invitation to this room?. Ahmad is our M expert and he is preparing the patches, updates and logs which related to  GT.M and VistALink.
his account : Ahmad....@ehs.com.jo


Regards,
Wasim

[Nancy Anthracite]

Vitalia found an images directory in the EDIS software and pulled it out
for me to download, which I did, and posted it on
http://opensourcevista.net:8888/NancysVistAServer/EDIS-images.zip . Will
you please see if this is what you need? I suspect it is a different
images directory you need but before I say anything to Vitalia, I want to
be sure this is not the right one.

room+uns...@googlegroups.com.

[John McCormack]

You should be able to find these files in the EDIS zip file after extracting.

ed/tracking-help/src/main/webapp/images/

[Wasim Naffar]

Great Nancy ;) those images what we want for the help module. thanks Nancy as usual :)
John, you are right ;). I copied these images into the folder ed/tracking-help/src/main/webapp/images/
so we have those images in the browser now :):)

Cheers,
Wasim

[Nancy Anthracite]

So is it all working now so that Oroville can take a shot at using it
there?

> > ishttps://trac.opensourcevista.net/svn/EDIS/trunk/java/tracking-help

> > <sol...@solomonblaz.com> <sol...@solomonblaz.com>wrote:

> > <sol...@solomonblaz.com> <sol...@solomonblaz.com>wrote:

> > <sol...@solomonblaz.com> <sol...@solomonblaz.com>wrote:

> >
> > AWESOME!
> >
> > I think I shall go do a little dance in the
> >
> > street...
> >
> > :)
> >
> > Great job Wasim and team, Nancy, Skip,
> >
> > everybody!
> >
> > Hooray!
> >
> > Cheers,
> > Solomon
> >
> > --
> > You received this message because you are
> >
> > subscribed to
> >
> > the
> >
> > Google Groups "VistA Emergency Room" group.
> >

> > To post to this group, send email tovista-emergency-
ro...@googlegroups.com

> > To post to this group, send email tovista-emergency-
ro...@googlegroups.com

> > . To unsubscribe from this group, send email

> > tovista-emergency...@googlegroups.com. For more

options,
> > visit this group athttp://groups.google.com/group/vista-emergency-
> >
> > room?hl=en.
> >
> > --
> >
> > Nancy Anthracite
> >
> > --
> > You received this message because you are subscribed
> >
> > to
> >
> > the
> >
> >
> > Google
> >
> > Groups "VistA Emergency Room" group. To post to this
> >
> > group,
> >
> > send
> >
> > email
> >
> > to vista-emer...@googlegroups.com. To
> >
> > unsubscribe
> >
> > from
> >
> >
> > this
> >
> > group, send email

> > tovista-emergency...@googlegroups.com.

> >
> > For
> >
> > more
> >
> > options,
> >
> >
> > visit this group athttp://groups.google.com/group/vista-emergency-
> >
> > room?hl=en.
> >
> > --
> >

> > Nancy Anthracite
> >
> > --
> > You received this message because you are subscribed to
> >
> > the
> >
> > Google
> >
> > Groups "VistA Emergency Room" group.
> >
> > To post to this group, send email to
> >
> > vista-emer...@googlegroups.com.
> >
> >
> > To unsubscribe from this group, send email to
> >
> > vista-emergency-...@googlegroups.com.
> >
> >
> > For more options, visit this group at
> >
> > http://groups.google.com/group/vista-emergency-room?hl=en.
> >
> > --
> > You received this message because you are subscribed to the
> >
> > Google
> >
> > Groups
> >
> > "VistA Emergency Room" group.
> >

> > To post to this group, send email tovista-emergency-
ro...@googlegroups.com

> > . To unsubscribe from this group, send email

> > tovista-emergency...@googlegroups.com. For more
options,
> > visit this group
> > athttp://groups.google.com/group/vista-emergency-room?hl=en.

> >
> > --
> >
> > Nancy Anthracite
> >
> > --
> > You received this message because you are subscribed to the
> >
> > Google
> >
> > Groups "VistA Emergency Room" group.
> >
> > To post to this group, send email to
> >
> > vista-emer...@googlegroups.com.
> >
> >
> > To unsubscribe from this group, send email to
> >
> > vista-emergency-...@googlegroups.com.
> >
> >
> > For more options, visit this group at
> >
> > http://groups.google.com/group/vista-emergency-room?hl=en.
> >
> > --
> > You received this message because you are subscribed to the
> >
> > Google
> >
> > Groups
> >
> >
> > "VistA Emergency Room" group.
> >

> > To post to this group, send email tovista-emergency-
ro...@googlegroups.com

> > . To unsubscribe from this group, send email

> > tovista-emergency...@googlegroups.com. For more
options,
> > visit this group
> > athttp://groups.google.com/group/vista-emergency-room?hl=en.

> >
> > --
> >
> > Nancy Anthracite
> >
> > --
> > You received this message because you are subscribed to the Google
> >
> > Groups
> >
> > "VistA Emergency Room" group.
> >

> > To post to this group, send email tovista-emergency-
ro...@googlegroups.com

> > . To unsubscribe from this group, send email

> > tovista-emergency...@googlegroups.com. For more
options,
> > visit this group
> > athttp://groups.google.com/group/vista-emergency-room?hl=en.

[Joseph Dal Molin]

Joseph

[Ahmad Sharaf]

Dear all,

i was working with wasim on migrating EDIS to GT.M platform and with your help we were able to run it, so as you know its working now and im going to share the steps we did on GT.M server side,

- exporting GT.M environment variables $gtm_noundef and $gtm_zquit_anyway, these two environment variables are very important to export to eliminate two of the issues that i don't think anyone would have if VistA was running on cache, exporting these variables will narrow the gap between running VistA on cache and GT.M.

- installing the attached patch, mainly this patch will fix different issues in the attached EDIS and VistALink routines, which falls in the following criteria.

1- relational operators that GT.M can not compile like using of ">=", GT.M can handle single operator at the time.
which exists in EDPRPT5, EDPRPTBV, EDPYPRE routines.

2- re-authentication problem, which cause lose of data in VistALink in XOBVRPC routine, i have to mention that the fix in  this routine is  a workaround, it needs deeper investigation and permanent solution, but the fix is enough to make ER work.   
 


--
Sincerely,
Ahmad Sharaf.

[Sam Habiel]

Good Job Ahmad!

As you well know (but some of the audience may not) most of what you
mention below are violations of the Mumps 95 Standard.

Sam

[Wasim Naffar]

Great Ahmad ;)

I would like to mention one point that we have an issue with the login authentication.
the system allow any user credentials (Access & Verify codes) to login regardless if these codes are valid or not, (i.e. there is no authentication in the login).
It was fine but now is not :(

As Ahmad said, we need more investigation and we need to follow "XOBVRPC routine" to see where is the problem!!!,
anyone have any idea about that??,  what is the differences in that routine and why that happens!!!


Regards,
Wasim

[Nancy Anthracite]

Can you elaborate about when it was fine and when it became not fine?

--
Nancy Anthracite

[Wasim Naffar]

actually i don't remember when it was fine, but what i remembered that when i set wrong A&V codes i got message that is invalid codes and can't login. I guess this happened after Ahmad did changes on "reauthentication in XOBVRPC routine" or somewhere else in VistA routines.
Therefore we need someone to help and explain where is the EDIS authentication!!! and to follow if the "XOBVRPC routine" changes are in the right place or not!!!!

Regards,
Wasim

[Wasim Naffar]

Hi,
The system now only check on the proxy user credentials and the menu for that proxy user, and doesn't authenticate the EDIS user. I mean when a user try to login and set any access&verify code the application validates the proxy user account not the EDIS user credential!!, and pass a user to the next screen successfully without validate the EDIS user credential, just validate the proxy user account.
So we need to know where is that checkup happen and why the system is validate and check only the proxy user not the normal EIDS user and doesn't make any validate on the EDIS user account??!!!

Is the problem come from the J2EE side or from the VistA side!! anyone can you help please?

thanks in advance,

Regards,
Wasim

[Nancy Anthracite]

Could it be that Solomon bypassed that? He said the following in his README
on the Trac server:

"Currently the EDIS Big Board web application (bigboard.war) has no
authentication mechanism configured at all. VA's implementation was a
WebLogic specific 2-way SSL authentication mechanism. If you want
automatically authenticating big boards you will need to implement the
equivalent yourself."

--
Nancy Anthracite

[Nancy Anthracite]

PS, can we get all of the changes you have made uploaded to the trac server,
please?

[Wasim Naffar]

He was talking about (bigboard.war), but here we are talking about (main.war), and as he said in "EDIS_details.txt" specifically in point 3
3. remove KAAJEE and its dependencies from the EDIS web application,
plus he wrote :
I've stubbed in some preliminary glue to let users log in to EDIS with
spring-security on top of VistALink, instead of KAAJEE. The login page
is quite plain, and the connection information to the M backend is
baked into the web app in a minimal but functional way, and in theory
it should work with an M backend, but that has yet to be verified.

So we want to know if we need to implement our login authentication or it already implemented.
Because as I said, before we made the changes on VistALink it was working well and when i tried to enter invalid user EDIS credentails i got message that credentials are invalid, but after that it doesn't!!!

Solomon, can you explain please? shall we need to implement our authentication or not!!

Regards,
Wasim

[Solomon Blaz]

Sorry all, I've been wrapped around the axle with my day job...

Um, correct, you guys are using main.war and not bigboard.war which is
a whole different set of authentication problems. In the VA, the big
board kiosks automatically authenticated with no user logged in via a
special certificate that had to be individually installed on each
kiosk machine. But that's just FYI. It sounds like you are
encountering a different problem.

So EDIS uses VistALink in its "J2EE" mode, which has a slightly
different authentication model to the regular old client/server model
used by the RPC Broker and CPRS. VistALink allows you to configure a
"trusted" connection between a VistA account and a java application
server, in this case, the EDIS app server. That's where the "proxy"
credential come in. They are for the trusted connection between the
java app server and VistA. Next, each user signs in with their own
credentials on top of the trusted connection. Many users can be
signed in to the same java app server at the same time. VistALink
completely handles this "re-authentication" of the trusted connection
to whichever user is calling an RPC in order to fulfill a web request.
What KAAJEE did was implement the web-based sign-in screen and
cooperates with M-side VistALink in order to make sure users are
authenticated correctly. I replaced the java/web side of this with
spring-security, because it is the java side of KAAJEE that had
dependencies on WebLogic, but the replacement is calling the exact
same RPCs as KAAJEE/VistALink for authentication. You can see where
this occurs in the VistaLinkUserDetailsService class, here:
https://trac.opensourcevista.net/svn/EDIS/trunk/java/tracking-server-vista/src/main/java/gov/va/med/edp/springframework/security/userdetails/vistalink/VistaLinkUserDetailService.java

The 'XUS KAAJEE GET USER INFO' RPC is called in the 'XUS KAAJEE WEB
LOGON' context to log in a user, and the 'XUS KAAJEE LOGOUT' RPC is
called to log them out.

I believe those RPCs are part of VistALink, even though they have
"KAAJEE" in their names.

The upshot - you shouldn't have to do anything special with
authentication and should be relying on out-of-the-box VistALink. If
you've had to hack on VistALink's M code in order to get it to work on
GT.M, then that is where I'd look for the problem. I'm afraid I'm not
too much help in that arena. :)

Cheers,
Solomon