2014 Jul 14 3:26 PM
I need some help pointing in the right direction to analyze and prevent a problem with a NON-BUFFERED custom number range object.
This process works well. Once or twice however, sequences have been created with an apparent delay and are out of order. I don't know why, or where to look to diagnose the timing, etc. It's very difficult to recreate.
We have a custom number range object; ZFSEQ in SNRO that is responsible for assigning a sequential number to a series of flat files produced by number of different interfaces. Those interfaces all use the FM 'NUMBER_GET_NEXT' and then they build a file name with that sequence number. That object is not buffered.
During heavy volume of updates (where lots of these sequences are being called and created by different interfaces, the table NRIV is locked and released by each interface. During this time of heavy updates, we have an infrequent problem that has occurred where a standard sales order create created a sequence number that is greater than the sequence number generated by the delivery create. (The delivery was created a couple of minutes later than the order, yet the order created a flat file sequence number greater than that of the delivery.
I hypothesize that the flat file call for the order (using the FM 'NUMBER_GET_NEXT') was somehow delayed(because of heavy lock/usage of NRIV). The actual order document and delivery document were created normally. I also am thinking that buffering on the object would prevent this. I cannot at this time implement buffering on the object, but we are working towards that.
The order create originates from our e-commerce system through a webserive, and in SAP, flows like this:
Main webservice RFC: Z_ORDER_CREATE
Call Z_create_order_bgd IN BACKGROUND TASK
Call BAPI_SALESORDER_CREATEFROMDAT2 )
MV45AFZZ--> userexit_save_document.
call Z_FUNCTION_TO_GET_SEQUENCE
CALL FM 'NUMBER_GET_NEXT' <---- order create sequential file created
commit work.
The delivery sequential file is created in
MV50AFZ1 (the Delivery User Exit)
Where can I look to conclusively see what happened to delay our sales order sequence? What could be done to prevent it?
Thanks
Jeremy H.
I need some help pointing in the right direction to analyze and prevent a problem with a NON-BUFFERED custom number range object.
This process works well. Once or twice however, sequences have been created with an apparent delay and are out of order. I don't know why, or where to look to diagnose the timing, etc. It's very difficult to recreate.
We have a custom number range object; ZFSEQ in SNRO that is responsible for assigning a sequential number to a series of flat files produced by number of different interfaces. Those interfaces all use the FM 'NUMBER_GET_NEXT' and then they build a file name with that sequence number. That object is not buffered.
During heavy volume of updates (where lots of these sequences are being called and created by different interfaces, the table NRIV is locked and released by each interface. During this time of heavy updates, we have an infrequent problem that has occurred where a standard sales order create created a sequence number that is greater than the sequence number generated by the delivery create. (The delivery was created a couple of minutes later than the order, yet the order created a flat file sequence number greater than that of the delivery.
I hypothesize that the flat file call for the order (using the FM 'NUMBER_GET_NEXT') was somehow delayed(because of heavy lock/usage of NRIV). The actual order document and delivery document were created normally. I also am thinking that buffering on the object would prevent this. I cannot at this time implement buffering on the object, but we are working towards that.
The order create originates from our e-commerce system through a webserive, and in SAP, flows like this:
Main webservice RFC: Z_ORDER_CREATE
Call Z_create_order_bgd IN BACKGROUND TASK
Call BAPI_SALESORDER_CREATEFROMDAT2 )
MV45AFZZ--> userexit_save_document.
call Z_FUNCTION_TO_GET_SEQUENCE
CALL FM 'NUMBER_GET_NEXT' <---- order create sequential file created
commit work.
The delivery sequential file is created in
MV50AFZ1 (the Delivery User Exit)
Where can I look to conclusively see what happened to delay our sales order sequence? What could be done to prevent it?
Thanks
Jeremy H.
2014 Sep 29 2:29 PM
Just want to post the answer that we found to this issue and close it, though more comments are always welcome!
We are going to move forward with buffering the Z object for the range as studies have shown and all other consulting input seems to be that buffering will solve this problem.
2014 Sep 29 2:36 PM
I have faced the same problem in the past and what was solved to me is call the FMs NUMBER_RANGE_ENQUEUE and NUMBER_RANGE_DEQUEUE before and after call the NUMBER_GET_NEXT function module respectively.
2014 Sep 30 3:06 PM
Hi, We considered that change to all of our interfaces that use the GET_NUMBER_NEXT routine and in the short-term decided that buffering offers increased performance and less risk since there were no code changes. Thank you. I appreciate your feedback on this!
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |