Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Shabarish_Nair
Active Contributor


The Background Story:

 

The subject is of content conversion in the File Receiver Adapter. For those who have read the SAP help; it states that the adapter expects the XML to be of the below format;
<root>...
<nameA>
<value1>value</value1>
<value2>value</value2>
<value3>value</value3>
</nameA>
<nameB>
<value4>value</value4>
</nameB>
...
</root>...

So ideally, the adapter doesnt expect an XML with hierarchies???


The Scenario:


 


The expected output file format (taking a real time scenario from a utilities industry) needs to be as follows;


HEADER - Fields of Header (1-1)


(TRANSACTION -  Fields of Transaction


METERPOINT - Fields of Meter Point


ASSET - Fields of Asset


REGISTRATION -  Fields of Registration


READING - Fields of Reading)


TRAILER - Fields of Trailer (1-1)


A sample file output;


HEADR,H1,H2,H3


TRANS,T1,T11,T111


METER,M1,M11,M111


ASSET,A1,A11,A111


REGST,R1,R11,R111


READG,RD1,RD11,RD111


TRANS,T2,T22,T222


METER,M2,M22,M222


ASSET,A2,A22,A222


REGST,R2,R22,R222


READG,RD2,RD22,RD222


....


....


TRAIL, T1


NOTE: TRANS to READG segments will be a repeating set


The Design:


When we start the design, to suit the file content conversion the ideal Data Type would be as below;



The above exactly fits the expected XML format for the File adpater to perform content conversion.


Disaster strikes:


Using the above message structure in the mapping will reveal a glitch.



You would notice that all the TRANS, METER etc nodes are now collated together. But this is not what we want since we need first TRANS followed by the first METER and so on.


The above is due to a context issue. The truth is, I have never been able to figure out a context mapping to handle the above. Or maybe even if I might, would it prove to to be too much of an effort?


So this is what I propose;


Create your Data type as follows;



Carry on with your mapping. This time since we have introduced the BODY_NODE, it will ensure that the context is maintained.

The output of the mapping will now be;



Everything is as expected. Only thing pending is the File content conversion to create the output file.

NODECEPTION aka Node Deception:

To have the XML prepared as expected by the File adapter, we will use a simple trick I have come to call NODECEPTION = NODE + DECEPTION.

Why NODECEPTION?

Because, here we will trick (DECEPTION) the File adapter by removing the BODY_NODE node (NODE) from the XML and provide it with the structure as expected for content conversion.

Use the java code as per this link.

The Java code will remove all instances of the BODY_NODE tag from the XML.

Note: For PI 7.1, I have used parameterization to make the code dynamic and hence reusable. If using XI 3.0 or PI 7.0, you can remove the parameterization snippet from the code.

Add the java mapping in your operation mapping. You will have the java mapping executed after the original graphical mapping.



The output would be as below;



Now that we have the resulting XML as above, it's simple FCC parameters that can create the output file.


The Next Steps:


The above 'Nodeception' method is what I found to be the easiest solution in such a scenario. Do you have a better and easier way? Or do you know how to manipulate the FCC parameters to handle hierarchy?


If you do, I request you to document your solution in this Wiki.

12 Comments
Labels in this area