Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Former Member
0 Kudos

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 ...

Thanks,
Matthias

3 REPLIES 3

ivo_vollrath
Active Participant

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,

Ivo

0 Kudos

Hi Ivo,

thanks for the hint. Unfortunately my scenario description was not excatly to what I'd tried (my fault).

node B ist transient with pattern "derive instances of transient nodes", so each read acces will create a new node by io_modify->create("node B"). Instances of node B could also be created in BOBT with (+).

The "after Modify" trigger on "node B" is not triggered by io_modify->create() (internal=true) but from (+) out of BOBT. The goal is to harmonize this. end_modify(immediate) did not solve this "internal" to get "official" after_modify determination called by a transient node creation.

Another thing that is somehow logical that it is not working in this way due to transaction handling ...

in the node B "before retreive" determination from above, I'd like to create a persistend node entry in same BO. The first try was just to use io_modify->create("node C") but this leads to a exception ...

IF mo_conf->ms_last_node-transient = abap_false.
* No changes to persistent nodes allowed in the current call context
mo_bopf->set_application_error( ).
ENDIF.

Do I need a separate session/transaction for this ?

Thanks & regards,
Matthias


0 Kudos

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,

Ivo