Deep documents vs shallow documents

[spg]

Hi,
I would like to get some opinion from others about using shallow documents instead of deep documents for EDI mapping.
What I mean here is, the EDI module installed document types are exhaustive and have all the possible segments and elements all of which may not be required for a given mapping requirement.
In such cases (which to my experience is most of the time) does it make better sense to use shallow documents which has only the elements which are relevant to the requirement ?
Shubhro

[Ramesh_Sambandan]

shubhro,

It is better if you use a shallow copy of the document rather than using the installed doc, so that you have only the fields which have to be mapped.and it doesn’t make any difference even if you use a deep copy of the doc.

ramesh.

[reamon]

ramesh wrote:
“It is better if you use a shallow copy of the document…”

Can you elaborate on “better?” IMO, using the installed document definitions intead of a custom subset simplifies maintenance, avoids definition errors and avoids duplicate doc definitions. Using the segment mapping approach described in the wM EDI docs helps reduce the clutter of the full definitions when mapping.

[spg]

Rob,
To avoid definition errors what I do is define the wmEDI installed doc type as an input parameter in the input tab of the flow service which does the mapping. This allows me to have all the elements with their proper EDI names in the mapping steps.
Once the mapping is complete, I go back to the input tab and make the document a shallow one. As a result my mapping steps look simple (because the document type does not show the whole EDI tree of segments and elements) and I am still able to use the valid EDI names.
Do you see any problem with that ?
Shubhro

[reamon]

It’s not that I see a problem with reducing the structure, it’s more that I see no real advantage. Anyone that is familiar with EDI structures generally has no problem ignoring unused segments and quickly navigating to segments of interest. Indeed, the surrounding segments can help one quickly visually locate a segment of interest based on its relative location.

I am not a fan of customizing standard structures and I don’t believe the use of reduced structures provides any benefits but can only introduce hard-to-find errors during maintenance (e.g. “Did I add in all the right levels for the previously unused segment that we are now using?”).

[Ramesh_Sambandan]

shubhro/Rob,

“better”------i mean mapping would be easy…but comes with extra maintainence overhead.

ramesh.

[Yemi_Bedu]

Hello,

We do use EDI and do segment mapping for outbound. If you have a short and concise project that doesn’t change like x12 830 3010 forever, then it will be easier to be straight forward and monolithic. We however, use two standards (x12, unedifact), about 6 transactions, and 8 versions interspersed. We can make the core against a transaction specification and share amongst versions. It is part of many programmers nature to use DRY techniques to reduce redundancy. When we have to add new translations for field codes, we can quickly go to a DTM segment and have everyone benefit. In our case, we work with a general mapping and then have some who are exceptions get custom maps. Good day.

Yemi Bedu

[gupta_r.17495]

I agree with Yemi’s way of edi segment mapping,we also follow the same pattern mapping of individual segments and invokes it in main maps when it is generic depends on the version compatibility.

HTH,
RMG

[Yemi_Bedu]

Hello,

I had some blinders on when I made my last post. When you are using developer and have a document reference, you are not actually working with all the seen elements. That is the biggest reason why it is good for us. We don’t have to guess what element and which location we want beyond something like UNH/NAD/DTM/REF. When we make a mapping service, we copy from the elements that have the GCD of internal sub-segments into the input and/or output of the service and that helps to future proof our designs a little.

We don’t make a separate small document. For us that would bring the problems that Rob disccussed. One issue though it that we have to remember the dependency manually, though we don’t change such things outside of completely wrong implementations.

Also, what helps is the have layers of degree of mapping. We have a canonical mapping set that gets the hierarchy and simple code translations setup (like “DUNS” into code 92). Then we have a hard mapping that merges common sections into stiff segments groups (like sendtime and receivetime into one dtm loop) that is usuable with convertToString. Good day.

Yemi Bedu

[ychang]

The “Divide-and-Conquer” approach can be taken to the extreme when you have a fairly standardized internal document such as SAP IDocs. Then your message mappings would become just a mix of mostly common segment mappings (such as DTM to IDocs E1EDK03/EDP03) and a small portion of message-specific mappings. Object reuse at its best!