[Kevan Riley]

Hi Michael,

It had worked out great for us.  One tip, to save you some future difficulties.  Some of the directories created by an hcisiteinit are empty.  git does not track empty direcrtories.  So we create file called .empty for directories like Tables, tclprocs, java_uccs/src, etc. anywhere there might not bee any files.  Because, if one of these direcoties go missing processes wont start and sometimes it is not clear why.

Not purely git related but we make heavy use of the globalVariable functionality.  We have globalVariable INI files for Prod and for Test (and Dev).  We use this for any directories, ports, IP address etc. in the NetConfig.  That way after pulling from git, we just copy over  (overwrite)  the globalVariable.ini file with the approriate one for the specific environment (test, prod, etc.).

 

Good luck,

Kevan R.

[Kevan Riley]

Hi Michael,

We do not check in/ check out code at the Cloverleaf root.  We manage our code at the site level.  We have found this created much less headaches with merges.  In place of a single “master” branch, we have a master (or production) branch for each site (including one for our master site).  We branch from and merge into these “production” branches.  Our Producrtion environments are “pull” only (we actually use a fetch / reset process).

As to GUI/IDE integration, we do not.  We manage our git activities from the backend over SSH.  It might be possible to create and “allow” commands throught the IDE using the Remote Commands feature, but I have not spent any time investigating that since we have backend access.

Kevan R.

[Kevan Riley]

Hi Ram,

Our git process is not integrated with the IDE; we run the git commands from the prompt on the backend.  It did occur to me to create commands to exec from the “Remote Commands” feature of the IDE, but ultimately, for us it would be too complex to include all of our processes, and we have backend access for our team members, so there was no real need to do so.

We do use git beyond just backup.  The backup aspect and version history is pretty helpful.  We use the Web UI for merge (Pull) request merging, which is also very nice.  In addition, we use git for code promotion.  We do not allow push from the Prod env.  All changes must be made in test/dev and pushed to git.  Then we pull down to prod.  That way prod is always based on the master branch in git (for that site, see below).  We make heavy use of the globalVaraibles.ini to handle our test vs dev vs prod parameters.  Each site has a test, dev, prod, version of the globalVariables.ini.  We copy the appropriate one into place after the pull.

We manage branches at the site level, not the root.  Each site has its own “Master” branch.  This allows us to work on seperate sites amoung the team with minimal merge conflicts.

Kevan Riley

[Kevan Riley]

Hi Rob,

Its been a while since you posted this, do you still need any help with Cloverleaf and Git/GitHub?  I’ve been using GitHub with cloverleaf for 5+ years now including as a team of developers.

Kevan Riley

[Kevan Riley]

This begs the question… Is it preferable to use the “Encoding” setting on TCP/IP or use the TCP/IP PDL and the MLLP.pdl?

[Kevan Riley]

Why not save them as HTML, and use that format.  It is immediately viewable in the NetMonitor, and most things you would want to do in MS Word should be possible in HLTML.

[Kevan Riley]

Give this a shot.

Code:

global env

if {$argc != 1} {
puts “”
puts “”procbythread
puts “”
exit
}
set procname [lindex $argv 0]

set fh [open $env(HCISITEDIR)/NetConfig “RDONLY”]

while 1 {

if {[eof $fh]} {break}
set len [gets $fh line]

if {[string first “protocol” $line] == 0} {
set threadname [lindex [split $line  ” “] 1]
}
if {[string first [string toupper $procname] [string toupper $line]] >= 0} {
puts “$threadname: $line”
}

}

Save is as something like procbythread.tcl, set you site, and run it like:

hcitcl procbythread.tcl tps_log_hl7

[Kevan Riley]

[EDIT: it looks like Michael beat me to it… but since I typed all this, I am leaving it…]

If you are using AIX, we have had good experiences with setting the tcp_keepidle parameter.

[Kevan Riley]

Yes.

[Kevan Riley]

You can also enable it from the command line if you have backend access.  After doing the setroot, setsite:

hcicmd -p PROCESS -c ‘CONN eo_alias enable_pdl’

Where

PROCESS is the process the connection/thread is in

CONN is the thread/connection name

This assumes you  named your EO alias “enable_pdl”, if you named yours something different you will need to adjust the last argument accordingly.

Note:

This will not “stick”.  Once you restart the thread it will go back to whatever is set in the thread properties.  Whereas, if you put the setting in the thread properties, it will be “on” for you whenever you restart the thread until you remove it via the NetConfig.

(PS to unset the eoalias from the command line use this:

hcicmd -p PROCESS -c ‘CONN eo_alias {}’

or just bounce the thread if it is not setup in the thread properties.

)

[Kevan Riley]

On the “Thread” tab of the connection properties lower left below “File:” is “Msg EO Config:”.  Put it there.  You don’t really need this at the process level since you just care about the protocol information.  So this is thread/connection level.

One more note, make sure you remember to clear setting out once you have the connection working.  As you will see, it generates a lot of stuff in the log file.  You wouldn’t want all that stuff in there unless you were specifically diagnosing a problem.

[Kevan Riley]

I have found it useful in a case like this to create an Engine Output Alias, I call mine ‘pdl_info0’.  It contains this:

 ENABLE pdl pdl BDUG 0

This is then setup on the thread properties for the connection you are working with, and will enable you to see every character coming in and its Hex value which enables you to see the unprintable characters like the MLLP encoding characters.  Initially, the extra stuff in the engine log might look confusing.  Just take you time going through it.

You should also look out for errors (or warnings) with the verbiage “no more phrases to try”.  This is a sign that the MLLP encoding you are receiving is not correct.  “No more phrases to try” is the PDL driver indicating that it did not find the or the or .

[Kevan Riley]

Thanks!  I had expected our customer rep. to let me know as soon as he knew something since I have been asking him about it.  We have a Cloverleaf upgrade in our list of accountable project for this year.  So I am on the hook to get this tested and ready to go live by the end of the year.

[Kevan Riley]

So when is 5.8 going GA?

[Kevan Riley]

While I an not sure what methods of penetration that the testing software that was used performed, I will make a couple of general statements about this, as I understand things.

Since the typical interface in Cloverleaf is a persistent tcp/ip socket, it will always be vulnerable to ip/macs address spoofing type connection hijacking attacks.  As far as I know there is no way to mitigate this inside the firewall (ie. inside the “protected LAN”).  Once a connection has been hijacked, I would not expect the Cloverleaf connection to be able to recover on its own.  Cloverleaf relies on a proper closing of the tcpip connection to reset the state to “opening”.  If for any reason this closing handshake does not happen, Cloverleaf will usually remain in an “up” state even though the actual connection may not still be viable.  Without a transition to “opening” Cloverleaf will not try to reestablish the connection, since it would still “think” it is up.

The only remedy I know of for this is to monitor “Last Rd” and “Last Wt” times on the threads/connections and if a gap become apparent, restart the thread/connection.  I do this from Cron on our AIX system.  There maybe other/better ways, but this works well for us for a few connections we have that “die” in abnormal ways on a regular basis.

I hope this helps.

[Author]

Replies