Notes on changing DTDbs after you have already completed mapping

On several of my past projects, I was given a DTD to load in wM and told it was the final version. I would load the DTD and use it for creating records and mapping. Usually when I was finished, I would find out that the DTD’s were in fact changed. I learned a few tips that shortened my time in redoing the mapping. First, always specify the record structure in the “input” and “output” tabs of the mapping service. Second, check to see what the changes were in the DTD. I have found that if no elements were moved from one record to another, than it will be alright to just reload the DTD and call it exactly what it was called before. Also, as long as the changes to the DTD only include adding and removing elements, than the mapping that was already completed will be okay. Just remember to replace the record structure you created from the old DTD is completely removed and the new record structure created from the new DTD is called EXACTLY the same and placed EXACTLY where the old record structure was.

That is a good point; thanks for the tip. I’d also like to add another note on changing field names within records.

PPatel says that “as long as the changes to the DTD only include adding and removing elements, than the mapping that was already completed will be okay”. But, what happens if the actual name of the node in the record changes? This is an interesting problem because it is not intuitive.

If, as PPatel says, you specify a “Record Reference…” in the Input/Output tabs for a flow, you are referencing the record structure that exists in the namespace you select from the “Select…” window. If you make a change to that referenced record, the change will show up in your new flow as expected. For example, if you use record “DEAL” as the input to a flow and later change the node “referenceNumber” to “dealReferenceNumber”, the record “DEAL” will reflect this change.

HOWEVER (and this is my tip to the gallery!), if you have mapped from the node “referenceNumber” and then rename the node “dealReferenceNumber”, in every flow in which this mapping has been made, the B2B Server will interpret your input record “DEAL” as having both “ReferenceNumber” and “dealReferenceNumber” and will map from the original name.

To recap that point: As the record “DEAL” enters a flow as an input, the field “dealReferenceNumber” will have its proper value. The flow’s code, however, will map from “referenceNumber” to your target field instead of using the renamed node “dealReferenceNumber”. Therefore, because “referenceNumber” is null as the record enters the flow, the target field will receive a nulled value instead of the value of “dealReferenceNumber”.

(This issue does not arise in services in which the renamed node is not used.)

Just remember that when you are renaming nodes in a record that have already been used in mapping (or pipeline variable substitution, etc.), you must redraw the maps using the GUI developer.