- This topic has 23 replies, 8 voices, and was last updated 9 years, 3 months ago by
.
-
Topic
-
-
Replies
-
-
-
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 wrote:
Code:
If TCL proc can executes xlates, we could take Cloverleaf implementations to next levelI had suspected that dynamic xlate version at run time might be your motive, while using something like a lookup table to define what version gets run (ex: test or prod or facility or other).
Now let me think out loud a second:
Code:
Cloverleaf requires you to recycle the process or purge what is running in memory to reload new changes in memory.Okay dynamically calling a xlate via TCL say using a lookup table would possibly get around this reloading requirement, but now you might be hit with slowness from loading the xlate into memory with each message translated which is a possible trade off to keep in mind.
Undoubtedly it is easy to get derailed by dwelling on the barriers, but I’m interested to hear more details about what you envision the usage, if everything worked like you wanted it to work.
I get the feeling you are thinking outside the box and hearing your ideas of how this could potentially be used could stimulate some dialogue that could get others to thinking outside the box with you.
For example, symbolic links on the back end can be used to point to versions of xlate but still requires it be reloaded in memory to take effect by doing something like recycling the process, at least that is how I pick up changes because it always works and covers picking up all changes.
I recall when I used the language Universe at another company it was interpretive and really nice that what you called to run was a variable that pointed to the version of the code defined in a lookup table so to speak.
This allowed any mixture of TEST and PROD dynamically per user, giving me the chance to develop new versions of TEST code as if it was running in PROD, but before it was promoted to PROD.
On a similar line of thinking, I had asked in a previous Clovertech post if the master site could be set granularly at the site level.
It was embraced as a good idea and Infor responded to me they had plans to add that feature, but i’m not sure if it has been done, or when it will be done.
This was my first approach to toggle a TEST site to run as if it was using the PROD master site once developed but before migrating to PROD.
These are the types of ideas I hope your description will inspire, if you are willing to provide example details to help get us to your level of inspiration.
Russ Ross
RussRoss318@gmail.com -
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 ❓
-
-
-
-
-
-
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.
-
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 you will see those measurements only with the first message which passes through the Xlate, the second one on will be considerably faster.
I suspect your employer did not spend all that mooney on Cloverleaf and then pay you more to essentiallly write another engine.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
If Cloverleaf were not limited to essentially only two nodes per interface (ignoring multiple destinations), i.e. a starting point and an end point, then it could function as Vishal is thinking about.
Where each thread is an independent node and multiple nodes can be assembled into an ESB business process, perhaps easily assembled with an almost drag and drop construction (as long as the interface contract is honored).
Im thinking of an EAI engine which can define services, connect them together in a BPEL context and make it easier to use compensating transactions.
I know we can use the OVER disposition to send a message back to the inbound side of a thread, but thats really not the same thing because you can’t use OVER in the SEND-OK or SEND-FAIL.
The performance limitation of stand-alone (i.e. tcl-invoked) xlates is considerable; I’d rather see individual messages able to travel across multiple threads, perhaps using a DISPOSITION of OVER in the SEND-OK proc.
Peter
Peter Heggie
-
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. All of your messages would come from the same inbound and would go to the same outbound thread, but the trxid proc would generate the route to get the correct XLT.
This would also have the advantage of error checking and default behavior if a bad XLT is called.
-
-
-
-
I truly think that this can be done via two threads with a generate route. That will allow you to not have to call the hcixlttest and hit the disk a lot of times. I got an example of a generate route proc many years ago and it had these two blocks in the example:
Code:# the newRoute variable is different for raw vs Xlate:
# (Xlate requires defining variable xltSpec)
#
# set newRoute “{ { DEST $destConn }
# { PROCS {{ARGS {{}} } { PROCS {} } } }
# { TYPE raw } }”
#
#
# set newRoute “{ { DEST $destConn }
# { POSTPROCS { { ARGS {} } { PROCS {} } } }
# { PREPROCS { { ARGS {} } { PROCS {} } } }
# { TYPE xlate }
# { XLATE $xltSpec } }”What I did was to use a “table” to look up my outbound thread name. You could do the same for the xlate name and have a outbound thread that has a TCL proc on the outbound stack “proto” the data message back to the original thread and do it as a reply back. Below is the code that I used to do the lookup but it does not have an xlate in it.
Code:
set destConn “”
set destConn [tbllookup $utable $lookup]if { ![cequal $destConn “TBD”] } {
set newRoute “{ { DEST $destConn }
{ PROCS {{ARGS {{}} } { PROCS {} } } }
{ TYPE raw } }”
msgrouteset $msgId $newRoute
lappend dispList “CONTINUE $msgId”
echo “routed message to $destConn”
} else {
set errMsg “Data msg does not have an outbound value in $utable for a lookup (input) value of $lookup”
msgmetaset $msgId USERDATA “{MSG $errMsg}”
lappend dispList “ERROR $msgId”
echo “errored message because of no known destination ($destConn)”
}Rob
-
In Cloverleaf 6.0 and beyond (maybe in 5.8 as well) you can also do a re-route from inside an Xlate or via Tcl – that might help.
I think Cloverleaf can probably do what you want although you may need to use some tcl.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
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) –
-
- The forum ‘Tcl Library’ is closed to new topics and replies.
