Thanx for the input everybody. We're also in the earliest stages of our implementation. We've settled on Seeburger and are this week installing XI. The team has had a week of training on XI but it wasn't EDI specific. We have been looking at auto map generators like Contivo but in the end it will need to prove real immediate ROI before we take on another tool.
As for mapping, I understand about the one map. The concern here about the one-map approach is related to regression testing: if you have only one map per transaction for all partners, and a new partner is added, or an old partner needs to change something, then do we need to do regression testing for all partners because of the change in the one map?
As a developer, I know that we can isolate partner-specific logic within the code of the one map so that it doesn't affect other partners, but the business folk paying the bills don't have the same level of comfort in the logic. The folk at Contivo also recommend doing one big base map capturing everything. They didn't answer the regression testing question very well, however.
Another approach I'm considering is to build one base transaction map that will be used by all partners and will capture the 90 or 95% of the standard that all partners use. Then where there are partner specific requirements that can't be accomodated in the standard, write separate mapping logic to handle exceptions after the base map executes.
It's still too soon for us to make a final decision on mapping approach. At my last project, we did one map per transaction per partner. But we were using a legacy EDI translator through a legacy EAI hub that was being coded by inexperienced developers offshore and was separate from our application system (SAP) development team. We exported or imported the IDocs, and took care of all SAP dev, they did everything else within the EDI architecture outside of SAP.
Thanx to all!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.