Scenario
I came across a nice little one with multi-part maps the other day. I had an orchestration where I needed to combine 4 input messages into one output message like in the below table:
| Input Messages | Output Messages |
|
Company Details Member Details Event Message Member Search |
Member Import |
I thought my orchestration was working fine but for some reason when I was trying to send my message it had no content under the root node like below
<ns0:ImportMemberChange xmlns:ns0=”http://—————/”></ns0:ImportMemberChange>
My map is displayed in the below picture.
I knew that the member search message may not have any elements under it but its root element would always exist. The rest of the messages were expected to be fully populated.
I tried a number of different things and testing my map outside of the orchestration it always worked fine.
The Eureka Moment
The eureka moment came when I was looking at the xslt produced by the map. Even though I’d tried swapping the order of the messages in the input of the map you can see in the below picture that the first part of the processing of the message (with the red circle around it) is doing a for-each over the GetCompanyDetailsResult element within the GetCompanyDetailsResponse message.
This is because the processing is driven by the output message format and the first element to output is the OrganisationID which comes from the GetCompanyDetailsResponse message.
At this point I could focus my attention on this message as the xslt shows that if this xpath statement doesn’t return the an element from the GetCompanyDetailsResponse message then the whole body of the output message will not be produced and the output from the map would look like the message I was getting.
<ns0:ImportMemberChange xmlns:ns0=”http://—————/”></ns0:ImportMemberChange>
I was quickly able to prove this in my map test which proved this was a likely candidate for the problem.
I revisited the orchestration focusing on the creation of the GetCompanyDetailsResponse message and there was actually a bug in the orchestration which resulted in the message being incorrectly created, once this was fixed everything worked as expected.
Conclusion
Originally I thought it was a problem with the map itself, and looking online there wasn’t really much in the way of content around troubleshooting for multi-part map problems so I thought I’d write this up.
I guess technically it isn’t a multi-part map problem, but I spend a good couple of hours the other day thinking it was.