Skip to Content

BOBF: io_modify->create( "node B" ) seems not to trigger node B "CREATE" determinations

Hello BOPF devs,

as @oliverjaegle suggested in his great posts, we split up business code in small pieces and put stateless calls in node determinations.

My scenario is:

- in determination code A, a new transient node instance for node B is created. For node B, there's a AFTER_MODIFY on create (det_B). If I use BOBT to create a B instance, the insert works fine and calls my EXECUTE. But the io_modify->create( "node B") in det_A code does not.

In END_MODIFY (/BOBF/CL_FRW_INT_ACCESS), iv_internal_modify is true, which prevents the do_detval(...) call in DO_MODIFY (/BOBF/CL_FRW) .

That's sad, because I do not like to put the code of det_B in det_A

Any suggestions to avoid that "internal modify" and get all the determinations called ?
I tried to call end_modify() at end of det_A w/o luck ...


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Sep 15, 2017 at 06:26 AM

    Hi Matthias,

    calling end_modify( iv_process_immediately = abap_true ) does not only apply the changes to the buffer, but also calls any determinations and validation. Otherwise, the determinations and validations will be called only after BOPF has finished processing your action.

    Kind Regards,


    Add comment
    10|10000 characters needed characters exceeded

    • Hi Matthias,

      I understand that you create instances of a transient node by a determination of pattern “derive instances of transient nodes”. Your determination uses io_modify->create() to create those instances during a retrieve-by-association (RBA) call. This does not lead to the execution of another determination which is triggered on “create”.

      To understand this phenomenon, it is important to note that an implicit creation of a transient instance during RBA does not count as a creation of a new instance. It is rather interpreted as the retrieval of an instance which is stored somewhere outside the direct reach of BOPF. Therefore, BOPF intentionally does not execute “create” determinations for this node.

      The explanation for your second observation (“set_application_error”) is similar: BOPF generally does not allow any data modification during read-only operations (such as RBA). This is the reason why you cannot create instances of non-transient nodes.

      If you were able to create persistent instances during RETRIEVE calls, you would probably confuse most consumers (note that there might be generic frameworks consuming BOPF BOs which you might not have under control). It would be strange if repeated read accesses would have the side effect of manipulating data. Therefore, I think you should reconsider your design.

      Kind Regards,