Agile Mapping
If you have just a few Trading Partners, having a unique and separate map for each of them might be a good option. However, if you have plans to scale your integration to 10s, 20s, or 100s and 1000s of trading partners, having a one map to one trading partner strategy is a recipe for a difficult to maintain and support integration solution. And it doesn’t have to be this way. There are a few strategies that will help you create an integration that will scale and be easy to support.
Industries have common ways to handle data.
This is something that we should understand. Mandating that others use your standard usage implementation may work if you are Wal-Mart, but is not really necessary. Most supply chain integrations are industry specific. Probably most EDI integrations even the non-supply chain ones are also industry specific. And you will find that most of the Trading Partners in a industry need to use the same data sets. And you will find that most of them are using them in about the same way.
What this means is that when you set up a map for one Trading Partner, most of that mapping will also work for the next one. This allows us to write maps that are flexible and can handle the variations in the data without having to have a map for each partner, or a crazy set of conditions that say, For Trading Partner 1 do xyz.”
This is of course for an inbound process of in other words, EDI data we receive from others. And it is simple to accept a par number of other piece of data in more than one location and map that to our canonical.
What is more tricky to visualize is how this works on the outbound. Well it is possible to map a part number or other piece of data to more than one location, this can be confusing to the trading partners that are receiving it. Instead, we do a pre map manipulation or pre mapping for trading partners that step out of the normal map. We could also have a post map process if your technology makes that the better choice.
Here is how that will look. First, we will have a map that is our standard preferred mapping. This map takes our canonical data and maps it into our outbound EDI format. Next, we create a process that will either modify the structure or content of our canonical to reflect the custom needs. We also adjust the map to recognize and handle the new fields. Alternatively we could have a post map that maps our standard outbound EDI and alters data or structure.
Strategies:
1. Broad mapping:
This is a mapping strategy that I have found works well on mapping data received well from Trading Partners. One illustration can be found in the discussion of line item data. Where a specific piece of data may be found in more than one location, you create your map to accept this data in all of the valid locations and out put that into your canonical.
It is also possible to do this on the outbound or map that formats data for consumption by your Trading Partners. This is not as straight forward, but there are times when you can see conditions in the data that cause the format or output to change. When these conditions exist, include them in the mapping and you will have a more agile and flexible map.
2. Pre mapping:
This is a map before the map. Well it doesn’t really have to be a whole map. But the concept is this; Data received or sent to a Trading Partner needs to be changed on a more Trading Partner specific basis. It doesn’t actually need to be a TP condition, these pre maps can detect a data format, and alter it before sending it to the map.
For instance, I had a instance where we had a TP that was consistently sending us a DUNS number with the ID of “1″ and we needed “01″ for our system. So we put together a pre-process that would look for these qualifiers of “1″ and altered it to “01″. In this way our map didn’t have to have funky code, and we were able to integrate with these trading partners without having to ask them to change their vendor data in their DB that was trimming leading zeroes. In any case, I have found that pre mapping is useful when there are consistent standards violations or data manipulation that can be corrected systematically.
3. Post mapping:
This is similar to the pre mapping, but your process happens after the map. This is a good use for mapping data out to your Trading Partner. And again, they don’t have to be trading partner specific. Data going out is altered slightly in form or format before it is delivered.
Again, I had a trading partner that transmitted catalog and part lookups in a format with a dash in the part number. But they didn’t like getting the dash back on their orders. So we instituted a simple mapping change that would strip dashes for them. But later we realized that having a process to fix part number formats was something that more than one Vendor Trading Partner was requesting. So we moved the mapping condition to a post mapping process that would look at the TP and find any part number rule and apply it.
Flexible and Agile is just better.
Okay, so that is a broad generalization. But I can back it up with years of experience. I never regret mapping broadly and implementing pre and post processes. But I do regret when I have mapped narrowly, tried to have a single trading partner specific map, or include all types of TP specific logic into a map.
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
