› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Copying multiple fields to multiple fields in one Xlate
I saw an Xlate the other day that only had 5 copy commands. On the source side of each copy command were all the desired fields in a segment. On the target side was a list of all the appropriate target fields that match up with the source fields. I would like to hear people thoughts on this technique.
The only time I have multiple locations on the source side is when I need several values passed into a proc. On the target side, I specify multiple locations.
What is best practice?
Mike
<><
Mike,
What you observed works.
My personal choice is to use individual COPY Actions.
At times if the receiving system is to receive EVERY field, component, and sub-component of a segment I will use a PATHCOPY at the segment level.
I don’t believe there is a global ‘best practice’ for this item – I believe like politics this is a local best practice.
You need to decide what will work best for you and how much you want to restrict the construct of an Xlate.
My thoughts anyway,
email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.
While technically you can have a single COPY to handle all of the desired input and output fields, aesthetically I prefer individual COPY statements and PATHCOPY statements. It alleviates the potential for accidentally deleting a field from the input or output side and then skewing your mapping.
To Jim K’s point, it is all what works best for you and your organization.
Jim Cobane
Henry Ford Health
Jims,
Thanks for your thoughts. I am trying to establish some standards to make maintenance easier down the road. I have a few more coding style questions.
1. When translating from say v2.3 to v2.5, do you bulk copy and then fill in the gaps caused by new groupings added in 2.5 or do you just pathcopy the segments individually. It is a bit of work either way, but at least with the pathcopy, you know exactly what is going to land in the target.
2. Do you put your comments for an If or Iterate before the command or in the first line inside?
3. Do you have any other documentation tricks? It is on my wishlist to have Infor add tab or another tab to each possible translate action for notes. In a Copy action, there are already Pre Proc and Post Proc tabs. Just add another tab called Notes. Have the title be white if no comments, black if there are. It would create a really nice way to make very granular documentation about the inner workings of an Xlate.
Mike
<
Mike,
1) I don’t use BULKCOPY.
2) Either and sometimes both. Here is something I also do (found this from the Cloverleaf implementers – thanks Jame McPheron etal):
For HL/7 I copy segment by segment (see #1 above) in the order of the outbound messagemand at each segment I put something like this: IF =MSH eq =MSH and inside that IF I put all the MSH related stuff. I do the same for the other segments using the segment ID (Like PID, PV1, etc.).
So when I open the Xlate I see kind of a table of contents:
IF =MSH eq =MSH
IF =PID eq =PID and so on..
When I want to work on the PID segment for example I just exand that IF and all of my PID related Actions are there.
I try to do the same for mixed mesage format Xlates and other message formats.
3) I use as many COMMENT Actions as I deem necessary to compliment the Actions. In one release the Comments honored Line feeds so in a single comment you could put a paragraph of information. That has disappeared – should would be nice if it were back. But I have to assume a basic level of competency for the next person.
I am not sure I see the use for the Notes suggestion at least in my case but others may find it useful. I guess my basic position here is the people working on an Xlate should have more than a basic understanding of what they are doing or they should not be touching it. My COMMENTS then are to indicate those things which are unusual.
If someone needs to know the ‘story’ as to why the Xlate exists it is my opinion that information should be included in a separate specification which documents the entire integration.
By the way I initialize all of my temp variables and ITERATE Counters I will control in a section right at the beginning so I can easily see what temp variables, etc. are in use.
email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.
Mike,
What Jim outlined is what we typically do as well. We have used BULKCOPY when appropriate, but it is more the exception than the rule. I will also put a comment before the IF statements and also around a group of statements if they were added later due to a change in the interface with notes about the change and when it was added; or for any actions that are a bit “unusual” happening in the Xlate. We also use the IF =MSH eq =MSH method for readability.
Hope this helps.
Jim Cobane
Henry Ford Health
I am working on an Xlate, so I thought I would try the “If =MSH eq =MSH” style both Jims mentioned. This works great until you run into group iterations.
If when translating from HL7 2.5.1 to 2.5, I have two options to map TQ1 and TQ2 from left to right.
1. Iterate through group 1(0).1(0).1 and then pathcopy 1(0).1(0).1(%g1) to 1(0).1(0).1(%g1).0(0). This will move the entire TQx structure.
2. Iterate through group 1(0).1(0).1 and then pathcopy TQ1 and then create another iterate to step through the possibly repeating TQ2.
The same applies to other groupings like 1.1.0 that contains ORC and OBR and 1.1.3 that contains OBX. Do you try to iterate at the highest level possible so you don’t have to recreate the entire tree or do you get much more granular and only pathcopy at the segment level? The later seems like a lot of extra work to accomplish basically the same result.
Mike
<
As for the ‘Bookmark’ for groups I do something like
IF =ORC_Group eq =ORC_Group
Then put the ITERATE(s) etal inside.
As for nested groups I do ITERATEs at each level. Looks like more work until you have to break into it later when they change their minds (they always change their minds if you don’t nail down their needs early and even then).
So when they say they want that ‘really simple little’ change I don’t have to figure out the various new basis and remember to add in the counters in the proper places of the address paths for the basis and the Action. I just need to add or remove. This ‘really simple little’ change of course needs to be done immediately leaving little time to figure out where everything goes. I would rather spend the time at the beginning when I have the time than be in a panic later when unreasonable demands surface.
Just my thoughts…
email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.
To add to the conversation that you are having with Jim Kosloskey, you may encounter cases on how to order your top down mappings in your xlate.
This typically arises when the ordering on the inbound side is different than the ordering on the outbound side.
This also happens when doing a mapping from say HL7 to a different record layout format like FRL or VRL or HRL.
That leaves you with decidding do you order your xlate mappings based on the input record layout or based on the output record layout.
Jim has consistantly advised us to order xlate mappings based on the output record layout.
Plus we try to only copy fields that are used by the downstream system.
However, we try to define the variant to allow any filed to be copied so when future fields are requested then just adding a copy statement will do the trick without modifying already mapped xlate paths.
Russ Ross
RussRoss318@gmail.com
Russ (and Jim),
Thanks for your thoughts. Because Jim has been around for so long and has been so generous with time giving advice here on Clovertech, he has influenced a generation of Cloverleaf developers and many of his personal best practices I am sure have been adopted far and wide.
As I try to implement some standards here at TMF, it makes sense that we build things like most other Cloverleaf developers do.
We really appreciate all your comments,
Mike
<