Yes, I know that when working with computer applications that there is no real magic or pixie dust; however, in the world of data modeling the HCL Integration Platform (HIP) Merge function is as close to magic as it gets. While all of HCL Integration Platform (HIP) is extremely powerful, the way that this Merge allows us to easily combine and separate the definitions of data definitions is particularly elegant.
When working with the metadata representations (which we call Type Trees or trees) in HCL Integration Platform (HIP) we rely on Merge to operate on our data definitions at a global level. Merge, as its name indicates, enables us to combine portions of two trees together (merging); it also allows us to create a new tree with just a subset of the original (paring); and to automatically remove unneeded components from a tree (pruning). Let’s look at these three smart operations.
This is the most obvious use of the merge function. In this case we have two type trees and it would be more convenient to have our components in one tree. Let’s say that I’m designing a structure for reporting operational temperature readings in appliances, and a coworker is designing a structure for reporting the time and duration of door opening and alarm events in appliances. We could work independently knowing that we can merge the definitions of our various sensor reading records into one tree. The best way to do this is to create a new (third) tree and merge our two trees in.
Now you have a single tree with your group for temperature record and your coworkers group for doorOpening records and the groups and items that both records are composed of. All of this definition is ‘merged’ in just a few key clicks.
This sounds a bit backwards: Use a merge function to pare down a structure? However, it is probably the most common use of the merge function in HCL Integration Platform (HIP) and it is very powerful. This is very often used with industry standards which tend to have a multitude of transactions in one version of a standard. When we distribute the HCL Integration Platform (HIP) Industry Packs we typically include one tree for standard version; each tree typically has hundreds of transactions defined. This is a great way to distribute definitions for standards but is not the ideal way to use the definitions in your transformation maps.
One downside of using a big tree with more components than you need is that when mapping you have to do more searching to find the components you are looking for and it is possible that if you pick the wrong one you will have some rework to do. For example, one day I was being jus a bit lazy and started a HIPAA Claim map on a copy of the full HIPAA 5010 standard tree. In itself, this is not a problem; however, I picked as my mapping root the institutional claim transaction and not the professional claim transaction. Yes, the component names are slightly different and if I had been paying attention (which I wasn’t – I already said I was being lazy that day) I would have seen the difference before I spent a large chunk of time doing drag-and-drop-mapping until, suddenly a segment that should have been there wasn’t in my structure. Yep, I lost time that day. Had I been smarter at the beginning and just merged out the single transaction that I needed not only would I have not made that mistake, but my tree data dictionary would only have had the subset of components that were applicable – and everything would have been easier to find.
As you saw above you can both merge and copy components from one tree to another tree. The main difference is that copy will copy the selected component and optionally it’s list of components but it will not create any child components. Merge will auto-magically create them for you.
Another positive by-product of paring your data definitions with merge is that the chance of unintentionally changing a standard tree and losing track of the change you have made is lessened. If I do not modify the ‘standard’ tree and only merge from them and always do any mapping with a subset tree then I know that my standard tree is really the standard.
This is the easiest way to kill off orphans and should be employed frequently. Wait, that last sentence sounded a bit scary, but it’s OK – I’m only talking about orphaned components in your data definitions. Orphans are those components defined in the tree but not actually used anywhere – they are parentless. By definition, all of your structural roots are intentional orphans, they are parentless but represent an object that you are probably planning on using during your data transformation process. It’s the unintentional orphans which cause us grief – they can confuse us. While working on defining our data definitions we often clone, rename and move our items and groups around and (if you are like me) are very hesitant to delete a component that we actually might still need. I know, there is a ‘Where Used’ feature in HCL Integration Platform (HIP) properties which tells us where an individual component is referenced – and that’s great if you want to look at every component one-by-one in your tree. But if you want to prune out everything that is not needed in your structure it’s really as simple as:
Now you have a new tree with just that group and all of its descendants. Any component which was in the old tree which was not referenced in that structure magically (there’s that word again) was pruned out and is not in the new tree. This pruning step is a best practice for all of your production type trees as nothing says sloppy like a component with no reason to be in a data definition.
So, is Merge magic? Probably not but it is a smart and powerful utility that will make your life easier.
HCL Integration Platform (HIP) is a trademark of IBM Corporation in at least one jurisdiction and is used under license.