tcl command

[Mason Miller]

I am trying to seperate a value into to parts I am recieveing example LAB1234 and I want to put LAB in OBR-3 and 1234 in OBR-4 does anyone know if this is possible or does anybody know of a tcl proc. that will do this.

From OBR|||LAB1234|

to     OBR||^LAB|1234|

Thanks

Topic

[Anonymous]

There are many ways to skin this cat…..but here is one way:

Set your inbound to …OBR.#3

Set your outbound to   OBR.#3.[1]  (Since you said you want it as ^LAB

                                OBR.#4.[0]

Have a pretcl that splits the original OBR3 and split it into a list for the outbound fields:

set var $xlateInvals

set xlateOutVals “[string range $var 0 2] [string range $var 3 end]”

Make sure you have a space between the two string range statements.

There may be a simpler way to do this but I hope this helps.

Tom Rioux

The Methodist Hospital

[Max Drown (Infor)]

Lots of ways to do this. Here’s one idea.

Code:

hcitcl>set inVal LAB123
hcitcl>set outVal1 [string range $inVal 0 2]
hcitcl>echo $outVal1
LAB
hcitcl>set outVal2 [string range $inVal 3 5]
hcitcl>echo $outVal2
123
hcitcl>

-- Max Drown (Infor)

[Max Drown (Infor)]

Thomas beat me to it.  😯

-- Max Drown (Infor)

[Robert Kersemakers]

Thomas G Rioux wrote:

set var $xlateInvals

set xlateOutVals “[string range $var 0 2] [string range $var 3 end]”

You’re playing with fire here; xlateOutVals should always be a list!

So use this instead:

Code:

set var $xlateInvals
set xlateOutVals [list [string range $var 0 2] [string range $var 3 end]]

Can’t argue with the rest though…

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Anonymous]

I understand that xlateOutVals is a list.  That is why, if you would have read the whole entry, that I put a space between the two string range commands, in essence, making it a list.  

As I said…many ways to skin a cat…and no fire!

[Robert Kersemakers]

I saw the space, but in your case you need to be absolutely, 100% certain that there are no spaces in the incoming string!

If you have “L B1234” as the incoming value, then you will have “L B 1234” as xlateOutVals in your case. Which means you will get “L” in OBR.#3 and “B” in OBR.#4.

Just treat xlateOutVals as a list and not as a string, and you don’t need to worry about this!

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Anonymous]

This is where knowing your data comes into play.  If the field will ever have a space, then you are correct, the list command should be used.  I was assuming that the field would never have a space in it.  

That raises however a good scenario and question that we may would like to get some opinions on.  Lets suppose we knew the data should never have a space in it.  If the data came across with a space, the we knew it would be an obvious error.   If we use the list command, then we risk delivering a message to the ancillary system with bad data.  If we use the method I employed, then that message fails on the engine.

The question is this:  Do we want to deliver bad data to the ancillary systems?  Is it their job to validate the data and not the engines?  

I have a similar situation on a charge interface.  If the data within the field in question is not as expected, the message fails and an email is sent to the users of the sending of system.

I’d like to know how others may be handling this situation.

Thomas G. Rioux

The Methodist Hospital.

[Jim Kosloskey]

Actually by using the list I think we are OK.

input = L B1234

set xlateOutVals

[string range $input 3 end]]

Yields {L B} 1234

Which is a two element list with {L B} being the first element and 1234 being the second element.

If the sending system is populating a space in the source subfield and it is not supposed to be there and the decision is made that the Integration Engine should apply business rules then I gues one could check the resultant component built and see if it contains any spaces, then error out. But then shouldn’t the receiving system apply the business rule if it is so critical to the receiving system? Also couldn’t eroring out the message cause a situation where follow on messages arrive out of order (unless we now want the Integration Engine to remove all potential follow on messages which could cause the receiving system a problem.

I guess it depends on the philosophy to be deployed.

Most of the work I have done relies on the sending and receiving systems to apply editing and other business rules and relies on the Integration tool to get the data from the sending system to receiving systems in a timely manner, the format required, and assuring delivery.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Mason Miller]

Thank you very much this worked great.

[Author]

Replies