I’m in the process of migrating from 6.0.1 to 6.1. I noticed while testing a flow for compatability that some fields were missing from my output file after a doing a map–>map–>convertToString. I’m mapping to a Document Reference. Let’s say there are 4 fields total and I map fields 1 and 3 in the first map. Then I map fields 2 and 4 in the second map. When I check the document in the pipeline before doing the convertToString Fields 2 and 4 are out of order for some reason (only in 6.1). This causes the convertToString to ignore the fields that are out of order. Has anyone experienced this behaviour or something similar? I was able to fix it by initializing every field in my document individually before mapping but I’m afraid that’s not a good solution because of the number of mappings in all of my code. The problem doesn’t happen consistently to similar maps (or in the same flow in 6.0.1) which makes me think the flow is corrupted or something.
I think happened to me before - you have to set the input parameters to the documentToXMLString service correctly. The order won’t be guaranteed unless you set to the documentTypeName to the record reference you have (the record structure that represents the XML structure). It usually has the correct order but occasionally it won’t . You may not have noticed this before - or I could be wrong…
I did experience the same problem and you can actually set the parameter "sortInput" to "true" when calling your convertToString. I'm not sure it's the best way to do this cause like you were saying, there was no problem doing something like this with the earlier versions!
Like you said, if we do a map that doesn't affect all of the fields, we get that kind of "bug"...cause for me this should be treated as a bug, I don't see why it should be like this now.
Did you opened a ticket on this one? Did you find your answer? If yes, could you please tell me what it is?
Yes, I opened a ticket and did a webex with them to demonstrate the behaviour. They seemed to consider it a bug which was reassuring. They have their experts working on it. I’ll update the thread when it’s resolved and they either have a fix or better workaround.
Mapping to fields in a document would in some cases result in
fields that at runtime were in an order different than the model
document.
Example:
Given a document with child fields a, b, c
If a map was done to a and c then the order of the fields would
be a, c.
If a map was done in a subsequent step to b then the order of
fields would in some case become be b, a, c.
With this fix the order of the original document is retained
after the map, i.e. a, b, c.