@pete-gilbert
Forum Replies Created
-
AuthorReplies
-
I wasn’t implying that you base 64 encode the entire hl7 v2.x message, just the rtf payload. The only time that I’ve base64 encode an entire hl7 v.x2 message, is when I am sending it wrapped in a soap envelope, and that was the best way to avoid inadvertently having a special xml character (like teh & or the > or the <) in the wrong place. And, yes, those folks sent me a base 64 encoded HL7 ack message wrapped in a soap envelope.
Jim Kosloskey wrote:Pete,
Well you would need to decode the message in order for your acknowledgment proc to get the Control ID (MSH-10) at the very least in order to construct a valid acknowledgment. You do construct a valid acknowledgment ?
Also if you needed to get at any of the individual fields in the message that are not binary data (these tend to be results – and no one treats result messages commonly – so we almost always need to do something to the message), you would need to decode. Once decoded, separator issue potentials exist among others.
The HL/7 folks actually are a pretty smart group and their proposed solution is the best way to handle the situation. Of course, not many vendors understand the potentials let alone follow them.
I think the shotgun approach of encoding the entire mesage has limited potential but might be the only resolution if the respective vendors cannot do their part.
Jim Kosloskey
wouldn’t you just base64 encode the document/payload before sending it and then have the recieving side un-encode it? We are running QDx 5.3 and QDX 5.5r1 on aix 5.2 with GM 2.3 to monitor about thirty production sites on six engines. Another thing that would be nice is a simple interface to temporarily disable an alert that you know is going to fire during some maintenance procedure. Something along the lines of a check box to disable the alert. what we get told now is to create a copy of the alert file and delete the alerts that you don’t want to trigger. Then make that copied file the active alert file. Then you have to remember to move the real alert file back into place once the maintenance has been performed. That works, but it is clunkier than it should be. oh….one more thing: The command entry for an alert should be more than a single line of text that allows me to see thirty characters. Being able to see only a portion of the command makes it difficult to create or debug.
See the screenshot example.
I’d like to see more flexibility in the message that gets displayed when an alert triggers. Why am I limited to plain text in 2007? Let me give you a blob of html that gets rendered in a web browser, or allow me to specify a url for the message (i.e., a link to support information that is maintained elsewhere, for example in a wiki). I’d also like to be able to reference the site, process and thread names in the text of the message as variables (for example, @sitename, @processname or @threadname). I have to hard code these in the message now.
We’d also like to see better integration with other monitoring tools. We use HP Openview here, and I have to call scripts with parameters to get Cloverleaf alerts to show up in Openview.
Provide some ability to preview the alerts. As it stands now, I code it and don’t know that I got the syntax wrong until the operators tell me that the condition occurred, but they did not recieve an alert.
Also, whatever you do should be documented, with good examples.
We hadn’t realized there was also a bug with purge cache. We are upgrading to 5.5 because it is supposed to fix a bug with the purge cache in 5.3!!!!!!! If Quovadx is reading this: this is basic functionality and it is appalling that production code is released containing such flaws. This is especially irritating as we were told to upgrade to 5.5 to fix a bug in the purge cache feature of 5.3.
I was wondering if anyone knew why GM displays the times for a thread converted to my local time, but the process time is displayed using the server’s time zone? For example, we have an engine for our central time zone sites. The thread plastread and plastwrite times display in my time zone (eastern), but the process time central (i.e., Started at Tue Sep 25 16:48:35 2007).
Does anyone know why the one is converted to my time zone and the other remains the engine’s time zone?
I forget where I got this from, but these are xml schemas for HL7 2.3.1. I downloaded the j2re-1_3_1_20-windows-i586 patch and applied it to my machine, but now all of the netmonitor status times are displayed in GMT. What do I have to do to get the JVM in Cloverleaf to use the timezone that my pc is using? Is there a patch for the JVM that comes with the 5.3 client? I couldn’t get the tzupdater to run on it. sleeping seemed preferable to having the engine try to reconnect 20 times a second 🙂 We put this thread into its very own process, because I didn’t want it to break anything else.And the process works. The remote service was unavailable earlier this morning (404 error), and when it came back up, it started rejecting every message that we sent to it (500 error). So, we queued things up..the thread is showing RED in Global Monitor with 125 messages in the queue. Our operators notified us and I sent a note off to the vendor’s tech support.
We tested for this kind of failure. This is our first https interface, and since we had to write the code ourselves, I wanted to make sure that it failed gracefully. It’s nice to see it actually do so.
I ended up coding this using curl (because the httpquery package wouldn’t allow me to configure the http headers properly). We are actually sending an HL7 2.x message in a SOAP wrapper. I ended up handling the errors like this: if {[catch {curl::transfer -url $url
-post 1
-httpheader $httpHeader
-postfields $soapEnv
-httpauth basic
-userpwd $useridpw
-verbose 0
-sslverifypeer 0
-infohttpcode httpcode
-errorbuffer error
-bodyvar httpResponse } ]} {
echo “***ERROR from tclcurl sending to REMOTE. Error is ” $error
sleep 30
return “{ERROR $mh}”
}
#
# a returncode of 200 is success.
#
if {$httpcode == 200} {
echo “Message was successfully sent to REMOTE”
} else {
echo “*** Error sending to REMOTE”
echo $httpcode
echo $httpResponse
echo “Original Message from LAB:”
echo $msg
echo “Soap Envelope that was sent to REMOTE:”
echo $soapEnv
sleep 30
return “{ERROR $mh}”
}
return “{CONTINUE $mh}”
}
Note that because I am doing this in a UPOC, returning ERROR actually puts the message into the recovery database and it will try to resend. I am told that this is a feature
🙂 So, if there is an error (like the remote server is down, or it thinks the message is invalid), we queue up and keep on trying. This will cause the thread to back up, and our operators will notice and we will start troubleshooting.I sent the client ini change out to all of the developers here. It seems to have helped, but we are still having one or two spasms per day. These spasms only occur between 0900 and 1700 on weekdays, so I’m pretty sure it is something that one of our developers is doing that is causing the spasm. Curiously, we have five other interface engines and have not experienced these sorts of spasms on them. Can anyone think of anything else that I should look at?
I got this from another post. The jvm arg is set as: jvm_args=-Xmx256m
Yesterday, I counted five spasms, lasting from 8 to 14 minutes. We’ve had two so far, today.
-
AuthorReplies
