The general (Gear 6 and EDI Samples) approach would be:
Create an N1 segment mapping service (named somthing like "mapN1Segments) that has a list of N1 documents as the service input. The service output would contain a separate document (or a signle document with multiple child document types) for every type of N1 segment you expect. The output documents represent XML fragments for just the <address> (N1 equivalent) elements you are creating.
Within the service, loop over the N1 list, and inside the loop, branch on N103 to populate the different output documents.
I have found that as requirements change over time (new N103 types come into play), it is inconvenient to change segment mapping service output specifications. So all of my segment mapping services take both EDIValues and a canonical as both input and output.
This allows the segment mapping services to hide the details of how they build the canonical, and be invoked as a sort of “assembly line” that builds-up the canonical a bit at a time. New segment mapping services can be inserted in the outer flow in any order, and no fragments need to be managed in the outer flow.
Since now the segment mapping service has knowledge of the canonical, the price of this approach is that you need different N1 (for example) mapping services for each transaction set type you handle. I have found this to be a price worth paying for the simplification it offers in the outer service.
It looks like you are getting the qualifier out of N103 ok.
What do you mean when you say creating a new FFS? Are you referring to the pre-built document types webMethods supplies and that you import with the Install TN Document Types link from the Doc Exchange section of the EDI Module’s administration menu?
When you perform this process, webMethods will create a flat file schema for you. It will be located in the WmEDIforTN package under the EDIFFSchema folder. When you open this flat file schema in the editor, you can generate an Integration Server document type from it. The IS document type will be named T850DT.
This is the IS document type you should be getting when you invoke wm.b2b.edi.convertToValues.
When you examine this document type, you should see a document list named N1. This is the outer list to loop over. Within the N1 document list, you will see N2 and N3 are also document lists, so you will want to loop over those within the N1 loop. N4 is a singe document so you should be able to map values out of it from within the outer N1 loop.
With this as your flow structure, the next thing to do is take a look at EDIValues immediately after stepping past the converToValues service. Is all of the data present in the source EDIValues document?
If this still doesn’t get you to a resolution, we will need to take a closer look at how you are mapping from EDIVallues to the target document type, and how you are converting it to XML.
As mark says the mapping solution said above definetly resolves your problem,the trick is with the N1 loop(nested)and outarray is address then grab N1/N2,and N1/N3 individual inside loops of N1 and since N4 is a document you can directly map the N4 data to target fields.
This situation comes for every new EDI mapper,so just keep on trying and check the pipeline results you will notice the defect and solves the problem by own.
Let me try explaining what actually happens.
Suppose the the structure of the N1 segment is say:
N1>SU>A>>1
N2>A2
N3>A3
N1>BT>B>>2
N2>B2
N3>B3
N1>ST>C>>3
N2>C2
N3>C3
The o/p side has a structure:
Address(Doc list)
-N1
-N2
-N3
ie the Address has three fields which gets values from N1,N2 and N3 resp.
As mentioned by you I have looped over N1 first , then two more loops in the same level under the first loop (ie the loop over N1) for N2 and N3.Just above the N2 loop , in the same level I have one map step that maps N101 to N1 of o/p.
Inside the N2 loop I have a map step that maps N201 to N2 in o/p and similarly within N3 loop I have a map step that maps N301 to N3 in o/p.
But in the o/p I am getting only one Address doc which contains only the last set of N1,N2 and N3 segments ie ST,C2 and C3.
Moreover the EDIValues has all the N1 sets.
Shouldnt the o/p repeat three times containing the data of all the three N1 sets.
When you debug-step through your loops 1 flow step at a time, do you see the input values being accessed in the correct sequence, i.e.:
N1, then the N2 associated with the first N1, etc. followed by
The next N1, then the N2 associated with the second N1, etc…
When you are stepping through the flow, if you do not see the green box highlight the map steps under each loop in this sequence, it’s a loop problem.
If the green box steps through the loops in the manner we expect, it is a problem with how you are mapping the output side.
Please follow the Mark’s suggestion as mentioned above,just step thru step by step and check the pipeline resutls something might be missing in your mapping logic,you will find the bug.InArray/OutArray Loops are very crazy to handle.
