Need tips for site overhaul

Ryan,

I would say that site breakouts are more of a philisophical exercise than technical.

The biggest problem I have with my processes is inter-process communications (passing from an inbound thread in one process to an outbound thread in another).  We seem to be one of the few companies that do not have an unlimited thread license, and those with the purse strings don’t want to pay for threads that are not directly connected with an external system.  Thus, I don’t have the threads to pass messages out of one process and into another in such a way as to not cross the process boundry.

I had asked Rob A. if there was any way in the future to not count inter-site and inter-process communication threads when the license counter figures your compliance, but I can see where that could have problems.  Untill then, I have to make do with what I can talk the boss into buying.

Ryan,

One thing I’m surprised at though is that 99% of your translation is done via Tcl.

Ryan, we are in a similar boat, except we are moving up from 5.4 to the newest version.  We also use TCL for most of our processes, there are some xlates here and there, but not much.  TCL’s seem to be a lot more robust and powerful.

Anyway, that said, I have been working on breaking out our processes, not just for an aesthetics sake, but to lessen the impact of making changes to threads on the go and for the rare *knock on wood* process hang.  We have some processes that, if you don’t take them down/bring them up in a certain order, you run into issues with other systems, among other little things, and, as we all know, if you add a new thread or make some changes, you have to stop and start the process to get everything kosher.  Also, in the case of a panic, all the threads in that process are effected.  Here is what I am doing (using outbound ADT for an example):

Outbound ADT from STAR feeds about 15 other threads, I have separated them into three groups, high, medium, and low.  The naming is for our 24 hour operators to know not to call us at 3AM if something in the low catagory dies, but you could, of course, use whatever you wanted for naming.  I then have ADT coming into a main, ADT out, this sends messages to adt_high, adt_med, adt_low, all under the process “ADT.” adt_high, adt_med, and adt_low are all tcp types, sending to the local host (in another environment actually), to adt_out_high, adt_out_med, and adt_out_low, all in the processes of their respective names (since this is acting in a server to client way, there are no issues with cross processing).  Those split off into those three processes, each containing 4 to 10 threads.  

I know that is sorta hard to follow w/o a flow chart, but I think you get the idea.  Also, I know that you would end up with extra threads this way, but 1) it keeps the process cleaner (especially when you use an extra “loop” environment for part of the routing) 2) making changes effects fewer systems and 3) panics and other hangs make less of an impact

Donna,

To each their own.

The power of Cloverleaf is the ability to choose the philosophy that best suits your situation.

We use Xlates exclusively here for translations. We have been through 2 upgrades (3.5 to 5.2 to 5.6) and did not experience any significant issues as I recall wherein our Xlates needed modifications to work.

On the other hand, with both upgrades we did need to make changes to some of our Tcl procs due to differences in the level of Tcl deployed.

In our situation we have found using Xlates to be the beter fit than Tcl for translations. We do have some Tcl for things that are not handled natively in the Xlates and for things like acknowledgment handling, filtering, etc.

I’m on Donna’s side.

While the Xlates were great for ease of learning Cloverleaf and getting interfaces implemented, they eventually became too much of a maintenance issue for us.

However, I also agree with Jim.

To each their own.

Before I got to this shop, they were heavy on the Tcl side.   With the move to a new HIS system, the need was to have as much done in an Xlate as possible.   For all the various data manipulation being done, the outbound TPS can have some pretty intense Tcl procs or have a might big stack.   Not very effecient when attempting to troubleshoot an issue.

It is my understanding that the xlates employs Tcl in the background when doing the data manipulation.   If this is the case, it just seems to me to make more sense to do as much as you can within the xlate.   I understand that there will be differences in some way or another that will necessitate the need for Tcl.

With all that said, the vast majority of what we used to do in a Tcl stack is now being done within an xlate.

Just my 2 cents….

Tom Rioux

If we are choosing up sides (in a good-natured way, of course) I would side with Jim K.

My reasoning is that it is easier to bring in a cloverleaf person and have them jump right in to the translate tool instead of having to explain all of the subtle nuances of your TCL library.

Once the stacked translates are a reality I will be an even greater proponent of the translate because it will be possible to create segment level translations and mix and match them when creating new interfaces.

Besides, if the translate doesn’t work right then I can blame Healthvision.  If the TCL code doesn’t work right then I have to blame myself.

😆