[Mark McDaid]

Not trying to hijack this post, but I have a related question, trying to do an http post from Cloverleaf.  When I execute the httppost the status returned is 400 Bad Request.  But when I run httppost with DEBUG turned on, I can see that the receiving end is actually returning 201 Created.  And I confirmed that the recipient is successfully receiving the post.  Here is the DEBUG output:

Code:

C:>tcl
tcl>httppost {{URL http://hummsystems.appspot.com/api/sms/send/invite/web/00a815
32-8c11-0246-336d-720f17006bb1} {DATA data=%7B%22PatientFirstName%22%3A%20%22GLE
NN%22,%22MobilePhoneNumber%22%3A%20%22(512)845-7830%22,%22ProviderID%22%3A%20%22
314%22,%22ProviderFirstName%22%3A%20%22DAVID%22,%22ProviderLastName%22%3A%20%22W
EEKS%22,%22AppointmentTime%22%3A%20%2220180404065036%22,%22LocationID%22%3A%20%2
2ac394e50-40a6-50f9-bd89-68e1b0da6e08%22%7D&authToken=e8d3af48-4b8a-400c-b3d5-9e
6ed8224451} {DEBUG 1}}
* Hostname was NOT found in DNS cache
*   Trying 172.217.12.84…
* Connected to hummsystems.appspot.com (172.217.12.84) port 80 (#0)
> POST /api/sms/send/invite/web/00a81532-8c11-0246-336d-720f17006bb1 HTTP/1.1
User-Agent: Quovadx CISAgent
Host: hummsystems.appspot.com
Accept: */*
From: anonymous@unknown.com
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 372

* upload completely sent off: 372 out of 372 bytes
< HTTP/1.1 201 Created
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: POST, GET, PUT, UPDATE, OPTIONS, DELETE
< Access-Control-Allow-Headers: Content-Type, Accept, X-Requested-With, apikey,
accountid
< Access-Control-Max-Age: 1000000
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Cloud-Trace-Context: 0ae0477e26a14203d8c259160ee9390a
< Date: Mon, 23 Apr 2018 19:31:01 GMT
< Content-Type: text/html
* Server Google Frontend is not blacklisted
< Server: Google Frontend
< Content-Length: 0
< X-Cache: MISS from WPBCWEB.arc.local
< Via: 1.1 WPBCWEB.arc.local (http_scan_byf/3.3.1)
< Connection: close

So, why is it giving a return status of 400 when a 201 was actually sent?

[Mark McDaid]

I was trying to resend from within Net Monitor and from the command line.

Thanks,

[Mark McDaid]

Chris,

That’s what I’ve tried telling them on multiple occasions, but I give up.  I don’t want to delay this project over port selection.  I’m just going to use the ports that they want me to use, and move on.  At least I know I’m not crazy (well, maybe just a little).   🙂

[Mark McDaid]

David,

Thanks for the reply.  I guess that makes sense.  Gives me some more to think about.

Thanks,

[Mark McDaid]

Hi Tim,

I have one particular interface with our radiology vendor that has been problematic over the past 3 years.  The problem is that once every 2-3 weeks, the process hangs with no alert and no indication of any problem.  This occurred when we were on version 5.2, and it still occurs now that we are on version 5.6 rev 2.  There has to be something coming across that interface from radiology, but I’ve never been able to figure out the root cause of the process hanging.  So, my solution (work-around) was to put the radiology interfaces in their own site within Cloverleaf.  Within this site there are 2 processes, ARA and monitorARA.  The ARA process contains the actual interface threads, the monitorARA process is used for the purpose of detecting when the ARA process becomes hung.  There are 2 threads within the monitorARA process, a timer thread that creates a simple “hello” message every 30 seconds, and another thread that sends the message to a third thread (fr_monitorARA) via a TCP/IP hop, that is in the actual ARA process.  I have an alert setup to go off when this fr_monitorARA thread has not received a message in more than 45 seconds (since it should be receiving a message every 30 seconds from the monitorARA process).  I then wrote a script that handles all of the shutdown, clean-up, and restart of the ARA process.  This script is set to fire when the alert fires.  This setup has worked well for the past 2 years.  It doesn’t solve the cause of the problem, but it keeps the interfaces going without human intervention.

[Mark McDaid]

Ok, I’ve sent you an email to the address you have listed.

Thanks,

[Mark McDaid]

Jim,

Could you post the replacement hcisplitinterchange proc that you mentioned that fixes the flaw?

Thanks,

[Mark McDaid]

Thanks for the quick reply, Jim.  I do have the implementation guide for the 837.  It’s a whopping 742 pages, so it’s a bit difficult to digest, that’s why I wanted to check and make sure what we are trying to do is even possible before I spend a lot of time working on this.  Thank you for the insight.  Sounds like this is going to be quite a challenge.  🙂

Thanks,

[Mark McDaid]

You could do this:

Code:

set segment [string map {”\.in+0\” “~”} $segment]
set segment [string map {”\.br\” “~”} $segment]
set segment [string map {”\.in-0\” “~”} $segment]

Because the character signifies an escape sequence, you must escape it with an additional .

[Mark McDaid]

Maybe I’m missing something here or don’t understand what you’re trying to do, but you can set persistent environment variables on your server.  See the attached screenshot.

[Mark McDaid]

That’s some very skilled writing.  Watch out, now they’re going to ask you to present at the next user’s conference.   😀

[Mark McDaid]

Well, we use the same method as Nate, which is why I was asking.  😳  I appreciate everyone’s responses.  Now I’ve got some ideas to think about for future implementations.

[Mark McDaid]

Gerri,

We have a similar problem with one of our processes that gets hung about once every 2 weeks.  The process is called ARA.  My solution was to setup another process called monitorARA.  In this process I have 2 threads, ARAtimer and to_ARAprocess.  The timer thread creates a simple ‘helo’ message every 30 seconds.  This message is routed to the thread to_ARAprocess that sends the message to a new thread that I setup in the ARA process called fr_monitorARA.  The sole purpose of this thread is for receiving and killing the ‘helo’ message.  That way I could setup a last received alert on the fr_monitorARA thread of 45 seconds.  When the ARA process gets hung it stops receiving messages on the fr_monitorARA thread, and 45 seconds later the alert fires, which sends an email, and also runs a script that I wrote to cleanup and restart the hung process.  I’ve been using this setup for about 6 months now and it works great.  Let me know if you need any more details.

[Mark McDaid]

Jim,

Thanks for the suggestion.  I will try that and see what it reveals.

[Mark McDaid]

That’s what I needed to know.  Thank you.

[Author]

Replies