Checking Thread Status

[David Harrison]

How can I check the status of a thread in a tcl proc?

What I want to do is: on an inbound thread, check the status of the outbound and create an HL7 ack message with an appropriate error text if the thread is not connected.

Thanks,

Dave

Topic

[James Cobane]

Dave,

Take a look at the msi extensions within Cloverleaf; these tcl extensions provide the facility to take a look at the thread stats (the same info that you see when you click the ‘Status’ button from the Control Panel in NetMonitor.

With that said, I’m not clear on your ultimate goal – if the outbound thread can’t connect to the external system, the engine will queue the transaction until it can re-connect.  From the engine standpoint, the message is not yet ‘sent’, so it wiould not be expecting a reply.  If you want to react in some fashion if you have not received a reply within some timeout period, then you should look at putting a proc employed in the ‘Reply Gen’ context of the thread.

Hope this helps.

Jim Cobane

Henry Ford Health

[David Harrison]

Jim,

Thanks for the information.

The interface I working on is between a maternity system and PAS. The new baby registration takes place on the maternity system which triggers an ADT^A04. Cloverleaf translates this and sends it to PAS which responds with a message to indicate success, or an error of some kind. This message is translated into an ACK message containing the appropriate error text and Cloverleaf sends it back as a reply.

The maternity vendor is expecting an acknowledgment so if the outbound thread is not connected for any reason I want to be able to inform the system that the link is down. When the link is restored, the queued messages will be sent to PAS but ACKS will not be sent back to maternity.

I hope this makes sense. Obviously if there are other ways of achieving this then I would welcome suggestions.

Thanks,

Dave

[Jim Kosloskey]

David,

If, in the future, the messages from the Maternity system were to be sent to additional systems (other than the PAS), which system’s acknowledgment would the Maternity System want before sending another message?

For example, let’s say the Maternity system’s mssages need to go to PAS and LAB. Both systems will provide an acknowledgment. Which one do you send back to the Maternity system, or do you send both? If you only send one, what if the second one has an error? f you send both then the Maternity system needs to be able to handle multiple returned acknowledgments for one message sent – I don’ know of many application systems that can do that.

In my opinion, the end-to-end ackowledgment method you are descibing is not workable.

email: jim.kosloskey@jim-kosloskey.com

[David Harrison]

Jim,

I agree with your logic in the case you presented

[David Harrison]

In the light of the advice received I decided not to proceed with this. However, I now have a different use case.

I am implementing an interface whereby a vendor connects to a Cloverleaf thread, sends a QRY^A19 and waits 10 seconds whilst Cloverleaf processes the query, sends it to our PAS  and processes the result back to the vendor system as an ADR^A19. The vendor system then disconnects from Cloverleaf.

This works ok but if the connection to PAS is down, the query is queued until such time as the PAS interface is restored, after which the query is processed and the result queued awaiting another connection by the vendor system. In the meantime the vendor system has timed out and aborted the query. The next time the vendor system connects with a new query, it gets the result from the previously aborted query.

I

[Chris Williams]

Dave,

If you’re just wanting to get the status of a given thread, it’s fairly simple. There is a keyed list in the msi for each thread with the following items:

ALIVE LASTEXTRACT LASTUPDATE START STOP PSTATUS PLASTREAD PLASTWRITE PLASTERROR PLASTERRTEXT XLATECNT FORWARDCNT ERRORCNT MSGSIN MSGSOUT BYTESIN BYTESOUT IBLATENCY OBLATENCY TOTLATENCY IBPRESMSQD IBPOSTSMSQD OBPRESMSQD OBDATAQD OBREPLYQD INTERTHREAD

For more info on msi go to hcitcl and enter “help msi”

Code:

# do this only once in your proc before making any msi calls
   msiAttach

# get list of thread names currently in msi
# there may be more than you’ve defined in NetConfig

   set threads [msiTocEntry]

# get keyed list for the specific thread into $klist

   set klist {}
   msiGetStatSample $threadName klist
   
# get thread status into $stat

   set stat {}    
   keylget klist PSTATUS stat

[David Harrison]

Thanks Chris,

In Cloverleaf 5.6 I found a tcl command called CheckThreadStatus which, when given the argument of a thread name will return the status, which is exactly what I was looking for.

I made the mistake of creating a tcl proc called CheckThreadStatus which led me up the garden path for a while as it gave me very confusing error messages.

If anyone can tell me how to remove a tcl proc I would be grateful!

Thanks,

Dave

[Chris Williams]

If you want to remove the one you wrote, just open it in the script editor in Cloverleaf, delete all the lines, then save the file. You should see the proc drop off the list of Tcl Scripts.

[Max Drown (Infor)]

David Harrison wrote:

Thanks Chris,

In Cloverleaf 5.6 I found a tcl command called CheckThreadStatus which, when given the argument of a thread name will return the status, which is exactly what I was looking for.

I made the mistake of creating a tcl proc called CheckThreadStatus which led me up the garden path for a while as it gave me very confusing error messages.

If anyone can tell me how to remove a tcl proc I would be grateful!

Thanks,

Dave

I don’t see that script in my installation of 5.6. Can you paste the script here? Also, where is that script located on your box?

-- Max Drown (Infor)

[David Harrison]

Max,

It’s not a script it’s a command within hcitcl. In my training site I have a thread called MDSCLI_IN:

Code:

alice % setsite training
alice % hcitcl
hcitcl>CheckThreadStatus MDSCLI_IN
opening
hcitcl>

[Max Drown (Infor)]

Thanks.

-- Max Drown (Infor)

[David Harrison]

I have another use case for checking the status of a thread within an Xlate. The problem is the msiAttach command takes 15 to 20 seconds to execute and this would seriously impact the interface. I get the same result in Cloverleaf version 5.6 and version 6.0.

There is a tcl command CheckThreadStatus but this also takes the same time to execute (it appears to use msiAttach)

The only other way I can think of doing it is to use

[Christy Hodges]

Where does CheckThreadStatus live? I want to look at the source file.  It works great, but I want to see the source….

[Jeff Dinsmore]

I’m not sure where the proc itself lives – I did some cursory searching – but we can its content and arguments using Tcl’s “info” command .

On my CL5.6 box, CheckThreadStatus is just calling ::msi::Msi_protocolStatus for the supplied thread.

Below is the result of  “info body CheckThreadStatus”

Code:

return “[::msi::Msi_protocolStatus $thread]”

“info args CheckThreadStatus” shows a single argument

Code:

thread

Jeff Dinsmore
Chesapeake Regional Healthcare

[Rob Abbott]

David Harrison wrote:

I have another use case for checking the status of a thread within an Xlate. The problem is the msiAttach command takes 15 to 20 seconds to execute and this would seriously impact the interface. I get the same result in Cloverleaf version 5.6 and version 6.0.

Regarding msiAttach, it only needs to be done once when the thread starts.  If you need to use msi* commands I would suggest putting an msiAttach in the start mode of your TPS.  Then it only runs once.

Rob Abbott
Director, Product Management - Infor Cloverleaf

[Author]

Replies