Making RPC Calls to WorldVista Container

[Daniel Bang]

Hi team,

I'm very new to the world of Vista Development and Systems Integration, and have just started dipping my toes into this for a personal project. The first thing I'm trying to accomplish is:

1. Setting up a WorldVista/Vista container such as https://hub.docker.com/r/worldvista/worldvista-ehr/ (completed)

2. Successfully creating a RPC via Java Client/Script from my local computer to the Vista instance.

For task 2, I have a few outstanding questions and am running into blockers:

1. Does the VistA container linked above accept arbitrary RPCs? It seemed from the description that it might via port 9430. 

2. If I can send RPCs to said port, which RPC library (in Java) would allow me to easily form and send the API request with the correct auth credentials/context?

3. If such a library doesn't exist, how would I go about manually forming such a request and successfully send the request?

Happy to give more context or chat more through this, as I am likely making a lot of incorrect assumptions about the overall architecture.

Thanks,

Danny

[Sam Habiel]

Hello Daniel,

Welcome to hardhats!

Answers:

1. 9430 is correct. Make sure you pass ports in the docker startup (-p).

2. I completely forgot and was rather stunned to find out (when I googled for "vista rpc java") that I prepared an example 8 years ago: https://gist.github.com/shabiel/25bdb59ab69fcd27ffc6, and it's the first result on Google!!! But Java is not my specialty; I googled "vista rpc java" and there are a couple of libraries available. Chris Uyehara wrote one, and he follows this list.

A few pieces of advice when interacting with RPC calls:

- Make sure that the user you are using does not have expiring access/verify codes.

- We have an infamous "hash" problem, which you need to be careful of. You should be by and large okay; but if you cannot login and there is no other explanation, this could be it. But there are RPCs (XWB*) that don't require log-in.

I am curious why you are interested in VistA. We are kind of at the tail end of its popularity wave...

--Sam

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/5d044c19-d504-431d-9b88-a76aabf953e7n%40googlegroups.com.

[Daniel Bang]

Thanks for the message Sam!

I actually also saw that file while researching this topic a few days ago, but didn't know if it was the most up-to-date, which is why I wanted to ask if there was a newer library. But no worries! I think this will be sufficient for my purposes. And just for testing purposes, I was going to use the PROV123 accounts, so should be good there re: expiring access codes :).

As to why I'm interested in VistA, I've been working with the VA for a project at work for a bit of time now, and just wanted to start tinkering on the side for a personal project to see which EHR platforms I can connect to and interface with from an external platform. Most likely will have more questions as I hack away, and might message or look here as they come up.

Thanks,

Danny

[Nancy Anthracite]

You might want to join the WorldVistA Support Call on Saturday mornings at 10:30 AM Eastern.  I will not claim Sam's expertise with the docker images, but there are people with a lot of VistA expertise on the call.

https://meet.goto.com/530169149 

 

 You can also dial in using your phone. 

United States: +1 (646) 749-3122 

 

 Access Code: 530-169-149 

--

Nancy Anthracite

> >> I'm *very* new to the world of Vista Development and Systems

> >> Integration, and have just started dipping my toes into this for a personal

> >> project. The first thing I'm trying to accomplish is:

> >> 1. Setting up a WorldVista/Vista container such as

> >> https://hub.docker.com/r/worldvista/worldvista-ehr/ (completed)

> >> 2. Successfully creating a RPC via Java Client/Script from my local

> >> computer to the Vista instance.

> >>

> >> For task 2, I have a few outstanding questions and am running into

> >> blockers:

> >> 1. Does the VistA container linked above accept arbitrary RPCs? It seemed

> >> from the description that it might via port 9430.

> >> 2. If I *can *send RPCs to said port, which RPC library (in Java) would

> >> allow me to easily form and send the API request with the correct auth

> >> credentials/context?

> >> 3. If such a library doesn't exist, how would I go about manually forming

> >> such a request and successfully send the request?

> >>

> >> Happy to give more context or chat more through this, as I am likely

> >> making a lot of incorrect assumptions about the overall architecture.

> >>

> >> Thanks,

> >> Danny

> >>

> >>

> >> ---

> >> You received this message because you are subscribed to the Google Groups

> >> "Hardhats" group.

> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to hardhats+u...@googlegroups.com.

> >> To view this discussion on the web visit

> >> https://groups.google.com/d/msgid/hardhats/5d044c19-d504-431d-9b88-a76aabf953e7n%40googlegroups.com

> >> <https://groups.google.com/d/msgid/hardhats/5d044c19-d504-431d-9b88-a76aabf953e7n%40googlegroups.com?utm_medium=email&utm_source=footer>

> >> .

> >>

> >

>

>

[Daniel Bang]

Hi Nancy,

Thanks so much! Will hope to attend when I can, but might be tricky given the time and where I'm located.

Hi Sam, I was able to do a little bit of hacking and got the RPC calls to successfully send to the container! Right now it seems as though after I log in (using PROV123 creds), I am having trouble locating a correct context id. 

Thus, my RPC calls post login fail with either a 

"the remote procedure XXX is not registered", or "Application context has not been created!" if I run c.context("XWB BROKER XXXXX");

Also running XWB CREATE CONTEXT does not seem to work the way I was expecting.

What RPC or directory would I need to execute/search to know what valid Contexts exist in the container that I can switch to?

[Sam Habiel]

Hello Daniel,

Sorry but not sorry for the delay. I don't respond to hardhats emails on weekends. Kevin T knows that well!

It's good that you can log-in successfully. That's half of the struggle.

Contexts are RPC type menu options. There are a lot of them:

Select OPTION: SEARCH FILE ENTRIES

Output from what File: PATIENT// 19  OPTION  (11261 entries)

  -A- SEARCH FOR OPTION FIELD: TYPE
  -A- CONDITION: =  EQUALS
  -A- EQUALS: RPC
Enter a value which 'TYPE'
must EQUAL, in order for truth condition
-A- to be evaluated as "true".


     Choose from:
       A        action
       E        edit
       I        inquire
       M        menu
       P        print
       R        run routine
       O        protocol
       Q        protocol menu
       X        extended action
       S        server
       L        limited
       C        ScreenMan
       W        Window
       Z        Window Suite
       B        Broker (Client/Server)


  -A- EQUALS: Broker (Client/Server)

  -B- SEARCH FOR OPTION FIELD:

IF: A//     TYPE EQUALS "B" (Broker (Client/Server))

STORE RESULTS OF SEARCH IN TEMPLATE:

Sort by: NAME//
Start with NAME: FIRST//
First Print FIELD: .01  NAME
Then Print FIELD:
Heading (S/C): OPTION Search//

DEVICE: HOME// ;;99  VMS
OPTION Search                                         AUG 14,2023@09:27   PAGE 1
NAME
--------------------------------------------------------------------------------

ACKQROES3
ACKQROES3E
ANRVJ_BLINDREHAB
AXAWPBGUI PATCHES
CRHD SHIFT CHANGE HANDOFF
CW MAIL
DENTV DSS DRM GUI
DGBT CLAIM DEDUCTIBLE PAID
DGRR GUI PATIENT LOOKUP
DGRR PATIENT SERVICE QUERY
DSIF FEEBASIS
DSIF FEEBASIS PAYMENT
DSIR MENU OPTIONS
DSIV DOCMANAGER
DVBA CAPRI GUI
EC GUI CONTEXT
EDPF TRACKING SYSTEM
EDPS BOARD CONTEXT
FSC RPC
GMV V/M GUI
HMP APPLICATION PROXY
HMP PATIENT ACTIVITY
HMP SYNCHRONIZATION CONTEXT
HMP UI CONTEXT
HMP WB DOMAINS
HMP WB PTDEM
IBD SCANNING WORKSTATION
IBTAS EBILLING RPCS
ISI DATA IMPORT
JLV WEB SERVICES
KMPD CM DEVELOPER TOOLS
KPA VRAM GUI
MAG DICOM GATEWAY FULL
MAG DICOM GATEWAY VIEW
MAG DICOM QUERY RETRIEVE
MAG DICOM VISA
MAG SYS-WIN WRKS
MAG UTILITY
MAG WINDOWS
MAGJ VISTARAD WINDOWS
MAGKAT
MAGTP WORKLIST MGR
MBAA SCHEDULING CALENDAR VIEW
MBAD APP PROXY BROKER MENU
MBAD BROKER MENU
MD CLIO
MD GUI MANAGER
MD GUI USER
MD HEMODIALYSIS USER
MDCP GATEWAY CONTEXT
MHV CLIENT
MWVS MEDICAL DOMAIN WEB SVCS
NHIN APPLICATION PROXY
NUPA ASSESSMENT GUI
OOPS GUI EMPLOYEE
OOPS GUI EMPLOYEE HEALTH MENU
OOPS GUI SAFETY OFFICER MENU
OOPS GUI SUPERVISOR MENU
OOPS GUI UNION MENU
OOPS GUI WORKERS' COMP MENU
OR BCMA ORDER COM
OR CPRS GUI CHART
ORAM ANTICOAGULATION CONTEXT
ORRCM REPORTING
ORRCMC GENERAL
ORRCMC QUERY TOOL
PRCHL GUI
PRPF RPC UTILS
PRSN VANOD EXTRACT
PSA GUI UPLOAD
PSB GUI CONTEXT - USER
PSN VISTALINK CONTEXT
PSO WEB SERVICES OPTION
PXRM REMINDER GUI
QACI PATS RPC ACCESS
QACV PATS RPC ACCESS
RMIMFIM
RMPF ROES3
RMPR GUI DOR
RMPR NPPD GUI
RMPR PFFS GUI
RMPR PURCHASE ORDER GUI
ROR GUI
SC PCMM GUI WORKSTATION
SCMC PCMM GUI WORKSTATION
SCMC PCMMR APP PROXY MENU
SCMC PCMMR WEB USER MENU
SD API
SD WAIT LIST GUI
SDECRPC
TIU MED GUI RPC V2
VAFCTF RPC CALLS
VBECS VISTALINK CONTEXT
VEJDWPB CORE RPCS
VIAA01 RTLS RPC MENU
VIAB WEB SERVICES OPTION
VPR APPLICATION PROXY
VPS KIOSK INTERFACE
WEBB BED MGMT SOLUTION
WEBG WEBVRAM GUI
WEBN NATL UTIL MGMT INTEG
WII RPCS
XHDXC DESKTOP
XHDXC DESKTOP
XOBE ESIG USER
XOBV VISTALINK TESTER
XQAL GUI ALERTS
XTMUNIT
XU EPCS EDIT DATA
XULM RPC BROKER CONTEXT
XUPS VISTALINK
XUS IAM USER BINDING
XUS IAM USER PROVISIONING
XUS KAAJEE PROXY LOGON
XUS KAAJEE WEB LOGON
XUS SIGNON
XUSSPKI UPN SET
XWB BROKER EXAMPLE
XWB EGCHO
XWB RPC TEST
YS BROKER1
YTQREST PATIENT ENTRY
utMUNIT



                         123 MATCHES FOUND.

Most users on demo machines are set-up to have the OR CPRS GUI CHART context as a secondary menu option, or a primary menu option in the tree somewhere. That's what I would try. Inquire into file 19 for that entry to see all the associated RPCs.

I would try this RPC probably, as it's the easiest:

NAME: ORWU DT                           TAG: DT
  ROUTINE: ORWU                         RETURN VALUE TYPE: SINGLE VALUE
  APP PROXY ALLOWED: Yes
 DESCRIPTION:
 Returns date in internal VA FileMan format.

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/55f8bce2-14b1-4f39-b908-79c69e78403dn%40googlegroups.com.

[Daniel Bang]

Hi Sam,

Thanks so much for this! I was able to make the correct RPC calls so this was super helpful :)

One question I had-- does this specific container only support http, NOT https requests? It seems whenever I try to make any https calls to the port, I continuously receive a javax.net.ssl.SSLException: Unsupported or unrecognized SSL message on my client side, and didn't know if this is something I can work around in some way (the client I'm using only uses https protocol)

Thanks,

Danny

[Sam Habiel]

I presume you are trying to access the YottaDB GUI on HTTPS, as it doesn't make sense to access RPC broker on HTTPS, as it is not an HTTP protocol. Is that right? Or are you talking about accessing RPC on HTTPS?

--Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/a6a970da-9942-4781-bd3b-cded7a915005n%40googlegroups.com.

[Daniel Bang]

Hi Sam,

I might be confusing myself, but basically I used a similar library as you had used to then send SOAP APIs to port 9430 of the Container. My understanding is that the socket package used in the library developed by Chris Uyehara uses HTTP to send the XML response to port 9430. I had thought then that port 9430 would then accept SOAP APIs sent via HTTP, but is this not the case?

Thanks,

Danny

[Daniel Bang]

Hmm... As I've been digging into the library and the Broker documentation, looks like my assumption was wrong. It seems to be vanilla TCP/IP sockets?

[David Whitten]

Well, it is generic TCP/IP sockets running the VA's RPC broker protocol.
This is a home grown communication protocol that can run on top of an
ssh connection, but is not compatible with any other industry remote
procedure call protocol,

Dave

> To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/061c7cc3-04e8-40ce-a82c-59e3f46e2801n%40googlegroups.com.

[Sam Habiel]

Daniel,

David Whitten answered your question. I think you are mixing up the so-called "proprietary" protocol in VistALink, which looks pseudo-SOAPy, and the RPC protocol, which is a straight binary protocol. VistALink also has a separate (but not the same as the RPC one) binary protocol. All of the 3 still execute RPCs by and large in VistA. And for completeness' sake, there is also the M2M broker; and you guessed it, also executes RPCs.

If you have wireshark, you can open it up and look at the Broker protocol. I have this page which has some dumps as well: http://www.vistapedia.com/index.php/VISTA_XWB_Broker_Troubleshooting.

As to whether you can make a broker protocol use TLS: the answer is pretty simple from a theoretical perspective: TLS is on a separate layer of the OSI model. It's as simple as having an stunnel service on the front-end rather than the more typical xinetd. But by and large nobody has really implemented TLS on broker services for many reasons (mainly pre-existing clients having to be updated).

--Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/CAH8N84y4UEUL8oYuB%2Bjtu0dnOm_GRCH%3DRbeO0osv_B%3De7P8EPA%40mail.gmail.com.