RAP : Number range generation using cl_numberrange_runtime=>number_get() is dumping with Strict(2)

[Ramjee_korada]

Hi Community,

Number range generation using cl_numberrange_runtime=>number_get() is dumping with Strict(2) but it works with Strict .

Is there any alternative to achieve with Strict 2 or this feature is not supported any more in Strict 2 ?

Below method is used to generate new key.

        cl_numberrange_runtime=>number_get(
          EXPORTING
*            ignore_buffer     =
            nr_range_nr       = '01'
            object            = 'ZRK_NR_PR'
            quantity          = CONV #( lines( lt_entities_to_gen ) )
*        subobject         =
*        toyear            =
          IMPORTING
            number            = DATA(number_range_key)
            returncode        = DATA(number_range_return_code)
            returned_quantity = DATA(number_range_returned_quantity)
        ).<br>

Behavior Definition

managed implementation in class zbp_rk_i_pur_req_h unique;
strict ( 2 ) ; // it works fine for strict
with draft;


define behavior for ZRK_I_PUR_REQ_H alias _PRHead
persistent table zrk_t_pur_req_h
draft table zrk_dt_pur_req_h
lock master
total etag LastChangedAt
authorization master ( instance )
etag master LastChangedAt
early numbering
{
  create;
  update;
  delete;<br>}<br>

Dump details :

Best wishes,

Ramjee Korada

[Ramjee_korada · Accepted solution]

It looks like , documentation is updated now that it is an exception to use strict(2) for number ranges.

https://help.sap.com/docs/btp/sap-abap-restful-application-programming-model/strict-mode?locale=en-U...

BW,

Ramjee

[sdig89 · Accepted solution]

Hello @Ramjee_korada, I am facing the same issue and I am not able to open your link, can you share it again please?

[ivanr93]

You can solve this by changing the buffering option of your Number Range Object. In that case the update of NRIV table is done via different DB connection. The only downside is that you risk the generation of Numbers that are not in sequence but this shouldn't be an issue.

For Managed this works without Early Numbering as well.

Another approach is separate table that will hold the GUID and ID values and then you can maintain this table in SAVE_MODIFIED implementation and on VDM you can expose it via association since the cardinality is basically 1..1.

Best Regards,

Ivan