I'm new to VistA, so please...

I'm new to VistA, so please bear with me if I ask something that should be obvious. I used the Vagrant installer (https://github.com/OSEHRA/VistA) and now I'm trying to connect to the instance. I found this VistaLink Testing Kit (https://github.com/shabiel/vistalink-tester-for-linux) that appears to do the trick, but I get stuck at the Access/Verify codes dialog. I tried all the ones listed in the Vagrant installer instructions, but they all fail. Are these the correct codes?

like0

Comments

Connection Troubles

Joseph Snyder's picture

Thanks for the question!

We'll take a look at the connection from that program.  There are a few ways to check that the access/verify codes are correct.  One way is to access the MUMPS/VistA environment from the command line, via the "mumps -dir" command, and attempt to sign in to the "ZU" menu with the same access/verify codes.  The red text represents what you would type in:

$ mumps -dir

OSEHRA>D ^ZU
NEW SYSTEM 304-262-7078
 
Volume set: PLA:vagrant-ubuntu-precise-64 UCI: PLA Device: /dev/tty1
 
ACCESS CODE: fakedoc1
VERIFY CODE: 1Doc!@#$
 
Good evening ALEXANDER,ROBERT
     You last signed on yesterday at 10:17
Select TERMINAL TYPE NAME: C-VT100//

 

If that doesn't work, its a problem with the access and verify codes.  If it does, we may be running into an RPC Broker issue that we've come across through CPRS which is a mismatch of cipher codes described here: https://www.osehra.org/blog/vista-m-and-delphi-guis-problem.

Hopefully, we'll get back to you with some more specific information soon.  Thanks again for the question!

 

- Joe

 
like0

Joe,

Joseph Carneiro's picture

Joe,

Thanks for the speedy response.  I followed the steps outlined above and they worked, so the problem is not with the codes.  To be more specific, I'm trying to connect via the VistaLinkRpcSwingTester.  In the jaas.config file I changed the ServerPortKey to 8001 since this is the port the instructions identify as the one for VistALink.  Please let me know if you need any more information to troubleshoot this issue.

Thanks again,

Joseph

like0

The cypher code is incorrect compared to the FOIA release

Christopher Edwards's picture

The FOIA release uses a different cypher code than the pre-compiled VistALink jar that is in the repository you linked to. You'll need to re-compile that application with the correct cypher code (after the Z tag in the linked code): https://github.com/OSEHRA/VistA-M/blob/master/Packages/Kernel/Routines/X...

Without the source code for that jar you won't be able to use that package to test VistALink.

like0

Christopher, thank you for

Joseph Carneiro's picture

Christopher, thank you for that bit of information.  I was able to create my own version of the vljFoundationsLib JAR with the cipher code in the link you provided and now I can connect to the VM.  Now I'm wondering if the reverse is possible: is there some way I can change the cipher on the VistA server so that it would work with the original VistALink JAR's?  In production we're going to be connecting to the VA's VistA server, so it would be ideal if our test VistA server used the same cipher code.  I know very little about the inner workings of VistA, so I don't know if what I'm asking is easy or difficult.  Thanks again to everyone.

like1

How to create vljFoundationsLib JAR with correct cipher code

emmanuel cleto's picture

Hello Joseph,

Can you detail how you were able to create your own version of the vljFoundationsLib JAR? Or can you post the JAR file? I am using NetBeans IDE to look at the JAR file:

public class VistaKernelHash {

    private static final int MAX_KEY = 20;
    private static final int COUNT_LIMIT = 2000;
    private static final String CDATA_BOUNDARY_OPEN = "<![CDATA[";
    private static final String CDATA_BOUNDARY_CLOSE = "]]>";
    private static final String[] CIPHER_PAD;

    private VistaKernelHash() {
        
    }

    public static String encrypt(String normalText, boolean preventEncryptionsContainingCDataSectionBoundaries) throws VistaKernelHashCountLimitExceededException {
       
    }

    public static String decrypt(String encryptedText) {
       
    }
}

like0

you can modify the cipher

Christopher Edwards's picture

Joseph:

You can modify the cipher on the vista side just do the reverse. you can edit the code in /home/osehra/r/XUSRB1.m on the VM.

like0

Christopher,

Joseph Carneiro's picture

Christopher,

I modified XUSRB1.m, but I'm unable to connect.  Either I made a mistake copying over the cipher or I'm missing a step.  Does the M code need to be compiled?  Do I need to stop and restart the VM?  Thanks again.

like0

a vm restart may be needed

Christopher Edwards's picture

depending on how good you are with the linux command line you can try to stop the vista services with sudo /etc/init.d/osehravista stop && sudo /etc/init.d/osehravista start or you can reboot the VM (sudo shutdown -r now). The problem is that the routine is still in memory and since the broker is a daemonized process you have to tell it to stop and start again for it to re-read the changed routine.

like0

Christopher,

Joseph Carneiro's picture

Christopher,

I modified the XUSRB1.m file and verified that the cipher matches what is in the VistALink JAR and it does not work.  I stopped and started the servies using the commands you provided as well.  I'm not sure what the problem could be since the codes match.  The code I'm using is the CIPHER_PAD in this class.  I converted all the escaped characters in the Java string, but do any characters need to be escaped on the M side?  Perhaps starting and stopping the service isn't enough to re-read the routine?  Please let me know if you have any other suggestions.

like0

restart the VM

Christopher Edwards's picture

Joseph:

M doesn't need any string escaping. At this point i'd just restart the VM and see if that works, making sure the routine is completely removed out of memory across all processes can be a challenge when doing remote debugging :).

like0

Christopher,

Joseph Carneiro's picture

Christopher,

I figured out the problem.  For some strange reason the paste operation was inserting a backslash character before every single quote character.  After correcting that I restarted the VM and now I am able to connect via VistALink.  Thanks so much for all the help, I really would not have been able to do it without your assistance.

like0