Forum Replies Created
-
AuthorReplies
-
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
I have updated the NetConfig files to ensure that no threads are initially started.
Thanks Charlie 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 amHi 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.
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
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.
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.
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.
March 24, 2015 at 1:34 am in reply to: Question: FRONT-END TPS TCL PROC PERFORMS 99% OF THE WORK #82176David 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
}March 23, 2015 at 1:53 am in reply to: Question: FRONT-END TPS TCL PROC PERFORMS 99% OF THE WORK #82174David 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 valueChangeFieldReplaces the 4th component of the field with the new valueRangeChk truncates the components to match the destinationHere 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!
March 20, 2015 at 3:48 am in reply to: Question: FRONT-END TPS TCL PROC PERFORMS 99% OF THE WORK #82169Hi Tom.
I haven’t received an update … but I have attached a sample of a Proof Of Concept translation.
The namespace setup
March 9, 2015 at 3:01 am in reply to: Question: FRONT-END TPS TCL PROC PERFORMS 99% OF THE WORK #82166Hi 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.
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
March 4, 2015 at 1:52 am in reply to: Throttling messages inbound to Cloverleaf from a foreign sys #82123I’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.
-
AuthorReplies