Where does the UNH01 segment of a 01B EDI document get populated from?

Hi there,

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?

If you require any of the code let me know.

Thanks in advance


UNH01 is a Message reference number(control number) convertToString generates it automatically extracting it from the control number table.

Can you elaborate bit more on the issue you are facing??



Thanks for the information regarding where the UNH01 gets generated from.

The issue i’m facing is that in my DEV environment, this is working successfully and the number is getting generated.

In the QA environment, a HP UX box, the number isn’t getting generated at all and only MSG_ID is being printed.

I’ve done a diff on the code in QA and my DEV and there are no differences at all.

Could the environment cause the differences? or is there something else that could cause this?

Could the environment cause the differences? or is there something else that could cause this?

could be…i have no clue…

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.

Hi Rob,

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.

I do not know what causes the difference in the behavior you observed.

Hi Rob/All,

I figured out what was causing the problem.

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

See…here you go…Glad to hear you resolved the issue by yourself.