[Vishal Patole]

Just to keep you all updated, below given TCL proc plugged into “TPS Inbound data” of a WSA thread. And I can see prototype is working as expected. [Implementation is done on Cloverleaf server using a WSA (Web Service Adaptor) thread listening on configured port. WSA thread reads; HL7 data from request body, loads XLATE file (reference set in request metadata / header) –

[Vishal Patole]

Rob Lindsey wrote:

I truly think that this can be done via two threads with a generate route.

[Vishal Patole]

TEST

[Vishal Patole]

Terry Kellum wrote:

If the needed translate is provided in the data stream, you could use a trxid proc to determine which translate to call by a route.

[Vishal Patole]

Jim Kosloskey wrote:

One of the reasons it is taking so long is none of the engine provided caching is taking place.

If you run the same Xlate inside Cloverleaf instead of inside your harness

[Vishal Patole]

hcixlttest is expensive for translating HL7 messages, based on initial round of testing single message takes around 500 to 600 ms for translation. I did read somewhere contribution was done to translate/transform messages using TCL scripts.

I am sure it will be much more faster comparing to xslt. Trying to locate tcl package/sample for reference which does parsing and or translation of messages.

[Vishal Patole]

Also I manage to write TCL script to achieve what I want. TCL script uses hcixlttest shell command to run xlate and it always expects data file to test with [infile].

Do you guys have any idea or know alternative whereby I can pass data stream instead of datafile while running xlate?

[Vishal Patole]

Thanks everyone for responses

@Rob – do you have sample example for me. Not sure how will I use generate route here?

[Vishal Patole]

I am in  touch with Infor R&D unit on this already, and licensing is not an issue here.

[Vishal Patole]

What I am trying to do here is; exposing Cloverleaf translation mechanism as a Translation Service which can be used by any consumer or an application.

With WSA 2.0; I can bind a given thread to a port and expose it as a web service. By combining TCL + Xlate + WSA; I am trying to build service layer which is decoupled from other systems and can be used as a translation engine. We have implementation unit who builds custom xlates and over the time we have build good inventory of xlates. Goal is, how easily I can expose these translation logic as a service.

thinking loudly;

a) Scaling with WSA thread is super easy.

b) Xlates are tied to local host.

c) Connections are not tied to xlates

d) Not going for dynamic xlates as for us, managing and to operationalise static xlates are cheap.

3) Test performance and thread safety

Does it make sense ❓

[Vishal Patole]

I don’t think you can (you can execute the Xlate testing tool – maybe send the output to a file).

– Not happy to hear this but I believe we have alternative, by using Java class instead of TCL PROC.

But why in the world would you want to?

– That’s how I think and development happens. I do have concrete plan/vision and asked task is one of the challenge in achieving my goal.

What’s wrong with using Cloverleaf routing to execute the Xlate?

-Nothing wrong in Cloverleaf routing to execute the Xlate.

If TCL proc can executes xlates, we could take Cloverleaf implementations to next level

[Vishal Patole]

As per my analysis what I understood is box is packaging tool and allows you to import or export packages in CIS implementations. Embedded tcl procs are not part of package is known bug.

Curious to know what do you mean deployment?

[Vishal Patole]

We are using 5.8.6 and migrating shortly to latest 6.0.2 version.

Cloverleaf native protocols works fine and we are also using it widely in our different types of implementations.

Reason I have submitted these questions because we have a need where dynamic message routing will happen where; message will be received by thread which is configured for WSA 1.0(JAVA protocol) and we needs to route that message to thread which is in different site.

Routing has to be dynamic as we do not prefer thread for inter site routing in a site which hosts WSA thread as well. (This is to reduce number of hosted threads per site).

TCL >> To route message dynamically

set msg [msgget $mh]

set newmeta “ORIGSOURCECONN $::HciConnName SOURCECONN $thread TYPE data CLASS engine”

set newmh [msgcreate -recover -meta $newmeta]

msgset $newmh $msg

lappend dispList “KILL $mh” “CONTINUE $newmh”

This works as long as destination thread is in same site.

[Author]

Replies