I followed all the Design steps as told by Mike. I sum up the design steps again
Fine! All these design in the IR were done. The Message Mapping, Interface Mapping and the Test Configuration were executed successfully without any error. But surprisingly the scenario ended up with an error while doing an end-to-end testing. Upon Monitoring I found that the multiple IDoc were generated however XI was not able to deliver the IDoc to the receiver system landing up with an error ATTRIBUTE_HEAD_MAPPING.
While I was breaking my heads on finding out the cause for this error, my colleague raised this Problem in File to Idoc scenario, which never gave any hint for resolving it rather was driving the scenario in a different way. This was the reason why I am Blogging this solution which would be useful for the newbie's.
This error baffled me because the same scenario was successful when the actual IDoc was used and only one IDoc was generated for each message. After a couple of days I found out the cause for this error was bcz of the XPATH in Receiver Agreement.
We were using the Header Mapping in the Receiver Agreement. The XPath of the Sender Party and the Receiver Party was logically wrong even though it sounds physically correct. The following XPATH expressions would define what I exactly mean.
XPATHS that resulted in error:
/ZISU_XXXXX_BRD_T64/IDOC/EDI_DC40/SNDPRN
/ZISU_XXXXX_BRD_T64/IDOC/EDI_DC40/SCVPRN
This XPATH physically looks correct referring to the correct path however the trick was with the occurrence of the IDoc i.e. for the multiple occurrences the IDoc was indexed with its occurrence. So Indexing the IDoc in the XPATH resolved the error..!
Correct XPATH:
/ZISU_XXXXX_BRD_T64/IDOC[1]/EDI_DC40/SNDPRN
/ZISU_XXXXX_BRD_T64/IDOC[1]/EDI_DC40/SCVPRN
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
37 | |
10 | |
7 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 |