I’m experiencing a bit of a problem with where a certain value gets populated from in the EDI 01B Document.
The UNH01 segment of my EDI document doesn’t have any mapping, however when i do a wm.b2b.edi.convertToString, it populates that segment with a random number.
This is fine in my Dev environment (which is Windows), however when the code is run in a HP-UX environment, the UNH01 = “MSG_ID”
Does the convertToString service automatically populate that segment? And if so, could a difference in environments cause this problem?
UNH is similar to the ST segment in X12. It is not managed by a control number table. When you call wm.b2b.edi:convertToString, it will assign a (random) value for UNH01 (or ST01 for X12) if that field is null in your document.
Though convertToString provides a generated control number, you usually want to set it. A common practice is to assign a sequential number to each transaction set within the group/interchange that starts at 1 (often 0001) and increments by 1 for each transaction set within the group (though EDIFACT docs don’t normally have groups).
If your process is such that just one transaction set per interchange, setting UHN01 to 1 (or 0001) should be fine. If you’re managing putting multiple transactions sets into a single interchange, then you’ll want to assign incrementing control numbers. If you use the built-in batching service (wm.b2b.editn.batch:batchProcess) then you can control how the control number is managed with the contentControlNumber input variable.
Refer to the EDI Module BIS Reference for more information. Specifically, the descriptions for wm.b2b.edi:convertToString, wm.b2b.editn.batch:batchProcess and wem.b2b.edi.util:addICEnvelopeEDIFACT.
I’ve gone with your method of assigning the value 0001, which is also what the client requested.
Would you know if the environment webMethods is run on can cause the convertToString to not generate a number as a random value for the UNH01 segment if that is null?
In Windows, UNH01 is a number
In HP UX, UNH01 is “MSG_ID”
Thank you once again for your help as well as RMG.
The handler service that invokes the mapping service, set the value of the UNH01 segment manually after the mapping service completed. This is what was setting the value of UNH01 to MSG_ID.
I did a quick patch to resolve this issue.
Good thing it wasn’t an environmental problem