In mapping EDI to/from canonical the goal is to create “reusable” mapping services. For example, in mapping an X12 5010 850 to a canonical for Partner A, we would like to create the services in such a way that they can be reused for other trading partners and possibly other versions as well. But we also need to accomodate partner-specific differences.
Some thoughts I have are customizing the EDITPA so that a partner-specific map can be selected which would then invoke generic and/or specific services, adding “user exits” to the main mapping service so that specific services will be automatically invoked if they exist, executing the generic service and then applying partner-specific requirements, etc.
I would appreciate wM users’ comments and suggestions. wM EDI and TN are version 6.5.
.Please correct me if i misunderstood your requirement.
your requirement:
so you will be getting edi say 850 v 4030.Then you want to map it to cannonical doc based on the patner and you want to use this same mapping to 2 or more patners and 2 or more versions for whom you want to do the same mappings .
my Suggestion:
you call a service in processing rule that publishes the 810DT(EDI 810 doc after envelope service is used) .And in the trigger why dont you just keep a filter based on the patnerIDs and versions for which you want to use this mapping (and call a subscribe service that does the mapping for these patners)and for other patners you can use another filtered trigger.
I am not sure it works for diff EDI versions this is just my suggestion and correct me if i am wrong anywhere
Thanks very much for your prompt reply. It has not been determined if the TN document will be published, but the filter idea is definitely worth considering. I’m hoping to arrive at a resolution that will allow the use of one “main” map for a particular document type.
Let’s say that a generica service exists which maps X12 850 to canonical for partner A. When partner B is implemented, it is found that they are sending a segment (DTM, for example) that needs to be mapped differently then in the existing generic map. Otherwise, all the mapping is the same. So I would like to invoke the generic map (via processing rule, trigger, etc.) and override the mapping for the DTM segment with the partner-specific mapping.
I guess we could copy the generic map and rename it or place it in a folder (named based on the partner), but that would result in a different mapping service for each partner with a different requirement. So, if we have 50 partners sending the 850, we could potentially end up with 50 mapping services. Realistically, it would probably be more like 10 mapping services.
I suppose if we’re processing based on processing rule, we could invoke the partner-specific map based on the EDITPA (after customizing) or we could use the filter if the TN document is published.
Once again thanks. Please let me know if you need clarification.
It’s better use the filter on the TN document and in the main map call the appropriate partner specific mapping service (depends on the version,doctype) capture this info from the pipeline bizdoc vars…you will have the visibility and do a conditional routing and back to the main flow that outputs the canonical document for further backend processing.
Also you know esp mapping portion some/more segments wont be sent/used by all the TP’s in a generic way…
There could be many ways doing this,but go with the easier way to minimize the complexity and later for support wise.
“I guess we could copy the generic map and rename it or place it in a folder (named based on the partner), but that would result in a different mapping service for each partner with a different requirement. So, if we have 50 partners sending the 850, we could potentially end up with 50 mapping services. Realistically, it would probably be more like 10 mapping services.”
This is exactly the approach I’ve taken most recently. Don’t name maps based on partners. Name them independently. Then use them for 1 or more partners. This keeps the number of maps down but doesn’t get too sophisticated/complex such that you’re scared to touch one for fear of breaking something else.
Within a given map you can provide some flexibility where things are mapped conditionally but you’ll want to keep that to a minimum. Generally speaking, you don’t want a change to a map for a given partner to mess things up for other partners. So when it doubt, clone and modify.
IME, reusing maps is over-emphasized. The payback of reuse generally doesn’t outweigh the maintenance headaches. Where reuse is helpful is in utility services. For example, I have an buildN1 service that builds the N1 and child segments as needed given the inputs. This gets used in multiple maps.
An alternative to your callback/user-exit strategy is to not have just one top-level service, with “overrides” for various parts but instead have multiple top-level maps (one for each major mapping need) that use common helper services. I think this approach may be easier to implement, easier to test and easier to maintain.
“An alternative to your callback/user-exit strategy is to not have just one top-level service, with “overrides” for various parts but instead have multiple top-level maps (one for each major mapping need) that use common helper services. I think this approach may be easier to implement, easier to test and easier to maintain.”
As Rob told this is one best approach to do .This removes the repeation of the code and makes modifications more easier.
we are using this aproach for long time but one drawback we have seen in this is we should be very careful when modifying the subservices or helper services.(because any changes made may reflect other main services using it) And as Rob said Debugging is easier if we keep save and restore pipeline in these sub services.
Thanks to all for your responses. I like the idea of the partner-specific mapping being repeatable (versus reusable) as that does mimize the risks. So the processing rule (or trigger filter) would invoke the main processing service which would then invoke the appropriate top-level map for that partner/document. And the segment and utility mapping services would be reusable.
“An alternative to your callback/user-exit strategy is to not have just one top-level service, with “overrides” for various parts but instead have multiple top-level maps (one for each major mapping need) that use common helper services. I think this approach may be easier to implement, easier to test and easier to maintain.”
“As Rob told this is one best approach to do .This removes the repeation of the code and makes modifications more easier.
we are using this aproach for long time but one drawback we have seen in this is we should be very careful when modifying the subservices or helper services.(because any changes made may reflect other main services using it) And as Rob said Debugging is easier if we keep save and restore pipeline in these sub services.”
It will reduce the chance that a subservice which does segment mapping requires modification if the canonical and mapping service are initially designed so that all (or a reasonable number) of fields and conditions are accounted for even though they may not be used at that time. For example, the N3 segment mapping may not be necessary for the X12 850, but if it is handled when the subservice is initially created and is needed later for a different partner or transaction, there is no need to touch the subservice.
Obviously, this requires a little more time upfront and the canonical may include more fields than necessary (at least in the beginning), but it seems worth the effort in the long run.
Are there any drawbacks (performance, etc.) to this approach?
“I like the idea of the partner-specific mapping being repeatable (versus reusable) as that does mimize the risks. So the processing rule (or trigger filter) would invoke the main processing service which would then invoke the appropriate top-level map for that partner/document. And the segment and utility mapping services would be reusable.”
You’ve summarized it quite nicely. That reflects the point I was hoping to make.
If you dont mind can you please elaborate on the below
“It will reduce the chance that a subservice which does segment mapping requires modification if the canonical and mapping service are initially designed so that all (or a reasonable number) of fields and conditions are accounted for even though they may not be used at that time. For example, the N3 segment mapping may not be necessary for the X12 850, but if it is handled when the subservice is initially created and is needed later for a different partner or transaction, there is no need to touch the subservice”
I did not understand clearly what you mean .But let me give you an example of what we do
For out tranding patners we have an external field in which we set the tax flag as either 'true' or 'false'.So when an x12 810 comes (we defined 1 main service for 3 tranding patners processing rule) it calls our main service (this service is common to TP who excahange edi 810) .So in the porcessing rule what we do is we branch on the exteranl field tax flag .If it is true then we call our sub service which will calculate the tax amount(based on some segments in 810 )
I think this is what rob means by multiple main services with one or 2 sub services
“It will reduce the chance that a subservice which does segment mapping requires modification if the canonical and mapping service are initially designed so that all (or a reasonable number) of fields and conditions are accounted for even though they may not be used at that time. For example, the N3 segment mapping may not be necessary for the X12 850, but if it is handled when the subservice is initially created and is needed later for a different partner or transaction, there is no need to touch the subservice”.
I’m afraid I got “off track” a bit as I was referring to details regarding the sub-service mapping.
Thank you for your explanation of using extended fields to control sub-service execution. We plan to take the approach discussed (repeatable partner mapping and reusable segment and utilities).
I appreciate your input as well as that of others. You all have been very helpful.