[Richard Hart]

After starting the 12 threads for process icm_prod_ih.

54788  9999 /apps/aise01t/cis5.8/integrator/bin/hciengine -S he00387 -p icm_prod_ih

110872 10048 /apps/aise01t/cis6.1/integrator/bin/hciengine -S he00387 -p icm_prod_ih

[Richard Hart]

I have updated the NetConfig files to ensure that no threads are initially started.

[Richard Hart]

Thanks Charlie

[Richard Hart]

Thanks Jeff.

I get the same results you did with RHEL 5.8 with Cloverleaf 5.8 and 6.1.

problem solved.

I tried the %r option and this also produced inconsistent results.

Code:

[5.8] aise01t> hcitcl
hcitcl>puts “[clock format [clock seconds] -format {%a %x %X}]”
Fri 10/30/2015 09:13:31 AM
hcitcl>puts “[clock format [clock seconds] -format {%a %x %r}]”
Fri 10/30/2015 09:13:42 AM

[6.1] aise01t> hcitcl
hcitcl>puts “[clock format [clock seconds] -format {%a %x %X}]”
Fri 10/30/2015 09:13:54
hcitcl>puts “[clock format [clock seconds] -format {%a %x %r}]”
Fri 10/30/2015 09:13:59 am

[Richard Hart]

Hi Guys.

Thanks for the replies.

Quote:

Check that your locale did not change

The 6.1 release was installed sometime ago and I am not aware of any changes to locale settimgs.

The details above were completed by setting root (5.8/6.1), executing hcitcl and then the clock command.

Quote:

… changing it to %r gives lower case am/pm

I’ll give it a go

It’s a low priority issue at the moment, but I’ll post updates.

[Richard Hart]

Hi Karl.

If we have been requested to do this, we set up a non-production Cloverleaf site to connect to the new application.  The production messages are sourced from daily cycled SMAT files and are either sent in batches (using the standard file load), or sent at an approriate time, based on the messages MSH timestamp.

This provides the production data 1 day late

[Richard Hart]

Hi Rick.

We are on linux (migrated from AIX) and work on the server.

We login to the server with our own account and use ‘sudo’ to change user to the code owner (hci) or runtime owner (hcimgr).

i.e.

 sudo su – hci

or

 sudo su – hcimgr

We ensure that our local accounts are in the same *nix group as the ‘hci*’ accounts.

[Richard Hart]

Hi Mike.

We also use Cloverleaf for non patient related interfaces, including one keeping the timesheet program up-to-date with new incident cases.

Our set up is publish and subscribe, where each Cloverleaf site is dedicated to an application (PAS, LIS, RIS …) and the Cloverleaf (internal to the server) threads complete the subscribe.

[Richard Hart]

Hi Mike.

We’ve been using web services in Cloverleaf since 2008.

In our case many of the interfaces could have been created by extending HL7 and been a lot simpler, but the architects insisted on web services.

Some of the outbound methods we use could not be completed in the previous Cloverleaf IHB and we have used the TclCurl code for these.

My colleague has been working with the new Cloverleaf CAA WS and this will replace a lot of the complex custom code we created.

We have had no performamce issues receiving upto (peak) 5 document (256k PDF) message per second.

[Richard Hart]

David Barr wrote:

So you’re saying that the globals are only to pass data between TPS procs that are all on the inbound TPS stack? I was more worried about using the global variables to pass data from the inbound TPS to pre-xlate or OB TPS.

Typically the global variables are within the module to store data for later use or used in another ‘Xlate’ procedure within the module.

eg

In email creation, data is stored in the global variables during the ‘translation’ section and then used to create the email.

In this code snippet, data is stored in the various globals BLOCK_PT_IDENTIFIER, BLOCK_PT_VISIT .. and the mail template REPORT_EMAIL

Code:

               #
               # Send the email and a add debug display
               #
           if {$myEmail} {
               set myAddress [GlobPCSB$HciConnName GET REPORT_MAILUSER]
               set myRptPatientId [GlobPCSB$HciConnName GET BLOCK_PT_IDENTIFIER]
               set myRptPatientVisit [GlobPCSB$HciConnName GET BLOCK_PT_VISIT]
               set myRptMsgControlId $myMsgCtrlId
               set myRptMsgTS [GlobPCSB$HciConnName GET MSG_TS]
               set myRptMsgType [GlobPCSB$HciConnName GET MSG_TYPE]
               set myRptFacility $mySndFac

                   #
                   # Note that each segment is prefixed with a space so that the MS email
                   # format looks better.
                   # Otherwise each segment data line contains the segment ID!!
                   #
               set myRptMsg ” [msgget $aMsgId]”
               set myRptMsg [regsub -all “r” $myRptMsg “rn “]

                   #
                   # Substitute the values
                   #
               set mySubject  [subst -nocommands -nobackslash $mySubject]
               set myMessage  [subst -nocommands -nobackslash [GlobPCSB$HciConnName GET REPORT_EMAIL]]

               libEmail GlobPCSB$HciConnName $myAddress $mySubject $myMessage

               Print GlobPCSB$HciConnName “EMAIL TO     :>$myAddress$mySubjectn$myMessage<" I
           }

[Richard Hart]

David Barr wrote:

I don’t think storing message data in global variables is a good idea. What happens if your engine process is stopped with messages that have already been through inbound TPS but are still in the recovery DB?

I store that kind of stuff in message metadata.

Hi David.

Cloverleaf keeps track of the module stack and the message has either been stored successfully after translation or not. If not, it is re-processed.

We use metadata to pass data between unrelated modules.

The globals are available for a single message translation. The namespace and access function (in this code Glob$HciConnName) allows a simple method to pass data (eg parsing characters) to the library routines or other translation modules.

Code:

   set myId 3
   set myField [lindex $aAllFields $myId]
   set myFac [RetComp Glob$HciConnName $myField 4]
   set myECode [EstablishmentList $myFac]
   set myField [ChangeField Glob$HciConnName $myField 4 R $myECode]
   set myField [RangeChk Glob$HciConnName $myField {20 8 8 4 1}]
   set aAllFields [lreplace $aAllFields $myId $myId $myField]

In this snippet, field 3 is the ‘working field’ and the library routines are:

 RetComp returns the 4th component of the field which is used  as a lookup value

 ChangeField Replaces the 4th component of the field with the new value

 RangeChk truncates the components to match the destination

Here is another ‘routing code’ snippet, where data is stored in globals and then logic applied:

Code:

   XlateMsg GlobRCTI$HciConnName

       #
       # Default the message routing to the ‘kil’ thread
       #
   set myTrxId KILL

       #
       # If the requesting/performing department is ‘XX’
       #     route to KILL (the default)
       #
   if {![string equal [GlobRCTI$HciConnName GET REQ_DEPT] XX] && ![string equal [GlobRCTI$HciConnName GET PERF_DEPT] XX]} {
           #
           # Default the message routing to the ‘SMAT’
           #
       set myTrxId SMAT

           #
           # If the requesting/performing department is ‘X’
           #     route to SMAT
       if {![string equal [GlobRCTI$HciConnName GET REQ_DEPT] X] && ![string equal [GlobRCTI$HciConnName GET PERF_DEPT] X]} {
               #
               # Check in the priority order and break if we have a valid
               # site
               #
           foreach myGlob {ACCT_NO REQ_DEPT PERF_DEPT} {
               set myCode [GlobRCTI$HciConnName GET $myGlob]
               set myWanCode [EstablishmentCode [EstablishmentCode $myCode S] wan ]
               if {$myWanCode ne “UNKNOWN” && [lcontain [GlobRCTI$HciConnName GET TRX_LIST] $myCode]} {
                   set myTrxId $myCode
                   break
               }
           }
       }
   }
   return $myTrxId
}

Please read Max’s post for Infor recommendations!

I started use TCL when we had isssues with version 3 and have found it very efficient to develop in – we have always been on *ix and work on the sever which also makes lie easier for us.

TCL translations work for us, but they do require a solid coding background!

[Richard Hart]

Hi Tom.

I haven’t received an update … but I have attached a sample of a Proof Of Concept translation.

The namespace setup

[Richard Hart]

Hi Tom.

We perform most of our translations in TCL. Previously management have blocked our request to share our code.  I’ve tried again and have a meeting later this week to discuss.

Essentially, we treat a message as string, split into segments and only parse the segments if a translation for the segments exists.

[Richard Hart]

Hi Todd.

We are on *ix and generally run one script that loops through the Cloverleaf sites and then calls a second script to perform  the action.

When the second script has completed its work, the envieronment is dropped until the next call.  The second script can also be called from  the command line.

eg

cycleAllLog.sh calling

 cycleLog.sh

cycleAllSmat.sh calling

cycleSmat.sh

purgeAllSite.sh calling

 purgeSite.sh

[Richard Hart]

I’ve previously throttled inbound messaging by delaying the ACK sent back from Cloverleaf using the thread ‘phold_obd’ feature.

I’ve not attempted what you are trying achieve, but it may be worh investigating.

Note that this will only work in the ACK message is of type data.

[Author]

Replies