|
CPRS still isn’t using a CCOW passcode, so that shouldn’t be an issue. I don’t think that using the SDK seems a likely problem either, since you’ve been successful with the non-FOIA stuff. I’d start out by comparing the data from the acceptor between sessions - one that doesn’t work against the one that does. If they are different, that should point us in the right direction. I’d expect differences in the station number or something, but that would be the same for connecting to different institutions. I’d be looking for differences in the data fields/names – like where we saw the word test added to the end. If they are the same . . . well, I’d rather not think about that.
The XU SID STARTUP is an option that is supposed to be scheduled to run at startup. Being a background job, it doesn’t generate any output. The XU SID ASK is the option that builds the string that identifies the system. I believe that string, is updated by XU SID STARTUP – in hopes of preventing test systems that were mirrored from production systems from appearing to still be production systems.
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Sommers
Hey Mike, I don’t think I’ve seen you here – welcome! To the list, Mike and I have worked a few CCOW “things” (not always a problem) at several VAMCs. I could take this off-list but I think it may be of benefit to those who want to go down this route.
So the test and production thing was the fact that the strings passed around within the Context Manager were slightly off between Production and Test systems. In particular, the issue was apparent with iMedConsent™ at eHealth University (?) because we were looking for a specific construction of the site number. In that situation, CPRS worked fine – but iMedConsent™ didn’t join context because (if I recall) the DUZ’s acquisition number didn’t match CCOW’s site number which was parsed out of that slightly mangled string. iMedConsent™ cross checks a few values between our RPC session and CCOW to make sure everything’s copacetic.
It this particular problem with the FOIA version, CPRS isn’t even working. But just in case, I did switch the system to Production and I’m getting the same thing. One thing to note, XU SID STARTUP reported nothing – at all – it just returned. Am I supposed to get a read out or check some Global?
Anyways, still getting it. I’ll restart Cache, my box, and check the Vergence logs.
Mike, did CPRS ever go with a keycode? I don’t happen to have one. I’m using the local Desktop Vault that’s part of the Sentillion SDK.
For everyone else. CCOW requires two pieces. The Locator sits on the desktop and maintains communication between the applications (on the desktop) and the Vault. The Vault sits (at the VA) on the network and maintains context for the user/patient. The SDK includes a Vault that sits just on the desktop for testing purposes. It’s available for free from their web site if anyone wants to try it out. And technically there’s a third piece which is the API that sits between my code (or CPRS) and the Locator. I’m sure someone will elaborate or find a good URL but I’m strapped for time.
Shiny.
/David.
David Sommers, Architect | Dialog Medical
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Palmer, Mike
I just had one of those light bulb moments. If I remember correctly there is a couple of issues that may cause it. I don’t know specifically how the CPRS.exe and FOIA databases are configured, but there is code in the Kernel that tries to determine if the system is a production or test system. It changes the applications pass through CCOW – applications may or may not behave properly when they get an unexpected string. The purpose of the code was to prevent the context sessions from confusing connections between production and test systems.
Sentillion software - If you run the acceptor (\program files\sentillion\desktopcomponents\acceptor.exe) you’ll see what is being passed.
The options you may need to run on the system to make it know it is a ‘production’ system are: XU SID ASK XU SID STARTUP
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Sommers
Actually my Locator and Vault seem fine. I still have my “old” CPRS exe and it connects fine to the non-FOIA database. When using a newer CPRS against the FOIA database (OR the older CPRS against the FOIA database), I get that same error.
I’m wondering if something on the server-side within OR or Kernel needs to be tweaked, configured, or just plain enabled. I may have to compare settings between the two or check my network traffic to get down into it.
I was just wondering if anyone has had a similar problem.
Roy, have you tried using the FOIA version? A clean DB?
/david.
David Sommers, Architect | Dialog Medical
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roy Gaber
We experienced that same issue at a VA Medical Center, re-installing the vergence locator was the key to our solution, it should be installed as a privileged user.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Sommers
So this question is the complete opposite of what many users will experience in the field. I’m having a problem getting CCOW to work with FOIA. After I setup the latest FOIA to my specs, I can’t get CPRS Chart to get the patient selection screen (after login) and I have all the Sentillion/Vergence bits in place.
We usually are the one’s to troubleshoot many of the CCOW issues in the field in relation to iMedConsent™ but this is the first time I’ve had CPRS not even attempt a context session and only with the FOIA version.
Figure I’d ask the list but I would really like to hear from Cameron - since you are DUZ=1 in the system ;) I’m thinking it’s a Kernel level option or something with login/RPC but I’ve just not come across this before.
And disabling CCOW on the command line arguments is not an option because our app requires context. I still have my “other” VistA database that works but I’d like to get the FOIA version working (and it’s “fresh”).
/David.
David Sommers, Architect | Dialog Medical p> 800.482.7963 x46 | p> 770.982.7851 x46
|
