does anyone know where the control number value stored generated from wm.b2b.edi.util:controlNumber ?

Example: lets say first time run, if the control number is 136340315, Next time run in the same minute, it will be 137340315.

does anyone know how does it remembers the last generated control number to generate new one?

Please share your thoughts

Thanks

It’s retrieved from the EDITracking table.

Please check your envelope services settings and how you are retrieving it from table:

Also refer the EDI Module user guide for more information on Control number handling.

HTH,
RMG

No, its not retrieved from EDITracking table for sure. That table is for 997’s. Envelope services are getting control numbers from EDI Control number table which we’ve configured from Admin page.

Here is the scenario my question for:

I’m running service “wm.b2b.edi.util:controlNumber” independently. first time when I ran I get 136340315 , second time when I ran I get 137340315.

where exactly did it store that first number so that it can generate the next number when I ran second time?

Any Ideas?

Sorry you are right I was in different mind set…you are almost there:

Next number retrieves from the table:

Obtaining Control Numbers for Outbound Processing (ANSI X12 and
UN/EDIFACT):
The EDI Module maintains information about control numbers in the
EDIControlNumber table, which is an EDI Module‐specific table in the Trading
Networks database.

Defining Control Number Settings covers the topic:

You can review the user guide for more basic information

HTH,
RMG

No Problem.
EDI ControlNumber table will have control numbers defined for specific sender, receiver and group type from Admin page.

Service “wm.b2b.edi.util:controlNumber” isn’t related to that table since this doesn’t take any defined sender or receiver as inputs. This service is to generate a unique number every time irrespective of any situation. It works totally independently.

but, when it generates it caches the value somewhere so that it can use it for next time.

I’m missing the point where it stores? Please anybody help

Thanks!

Here is the more info how this svc works:

wm.b2b.edi.util:controlNumber

WmEDI. Creates a control number.

The control number is a nine-digit number, based on a two-digit day, two-digit hours,
two-digit minutes, and a random three-digit system count (100-999).

HTH,
RMG

“This service is to generate a unique number every time irrespective of any situation.”

No, it really doesn’t do this. IME, this service is all but useless. As rmg notes, it does not track which control numbers it has handed out. It does not cache any value.

Thanks for Jumping in Rob:

HAPPY NEW YEAR:

Reamon and rmg, thanks for your replies!

If you run this service twice, you’ll see the second number is subsequent number to the first one.
I was trying to figure out where exactly it stores the first number to create the second. Of course that idea is turned out to be a dud. I figured better to avoid using this service rather use DB sequence number stuff.

But anyways, you are right. this service is useless. from my testing, it is generating unique numbers when running as multiple threads on one server. but when I run this service, from multiple servers in one cluster with multiple threads which share same database, its surely generating duplicates since its not synchronized across cluster.

Thanks for all your time. Really appreciate it!

Thanks.

In memory it keeps what the service description refers to as the “random system number.” So it keeps only that portion, not the entire the string. On restart, the “random” number sequence will restart. And as you’ve noted, multiple IS instances can and will create the same number.

I’ve found it best to use the EDIControlNumber table. Doing so follows the common practice of using sequential control numbers for group and interchange envelopes to support tracking and control number gap detection. (If you’re not already aware, the common practice for tx sets is to always start at 1 and do +1 for each tx set within a single group.)

As previously stated nothing stored in memory and theory of that service is:

The control number is a nine-digit number, based on a two-digit day, two-digit hours,
two-digit minutes, and a random three-digit system count (100-999)

Yes I seen the issue about dup cntrl number issues in the IS cluster environment:

HTH,
RMG

Thanks a lot to both of you for suggestions. they helped me to figure out what to do. Really appreciate it

Thanks

you bet: