RAP event - Additional save > Raise Event > INSERT generates shortdump

[EgbertVenema]

Whenever the user calls an OData service, I need to save the data to a table and immediately trigger additional actions. In my case, the preparing and printing of a custom form based on the saved data. In the current setup this generates a shortdump.

To get this to work, I'm using the "with additional save" option within the behavior definition. This provides me with the 'save_modified' method to handle my additional save. If I simply perform an INSERT there, the record is inserted into the database without issue.

However, to properly decouple the process, I raise an entity event 'created', which is defined in the behavior definition.

METHOD save_modified.
    data lt_header type table for event zlp_os_i_del_hdr\\Header~created.
    lt_header = corresponding #( create-header ).
    RAISE ENTITY EVENT ZLP_OS_I_DEL_Hdr\\Header~created from lt_header.
ENDMETHOD.

This event is handled by a separate class.

METHODS:
  consume_created FOR ENTITY EVENT created_instances FOR Header~created.

method consume_created.
  " INSERT here results in shortdump

  loop at created_instances into data(ls_created).
    zlp_os_cl_delivery=>print_label( ls_created-HeaderGuid ).
  endloop.
endmethod.

Normally, in this method, the label is prepared and placed in a print queue. That last step is done using a standard SAP class, which eventually performs an INSERT.

cl_print_queue_utils=>create_queue_item_by_data(
  iv_qname            = lv_printer
  iv_print_data       = lv_pdf
  iv_name_of_main_doc = |Label date/time|
  iv_number_of_copies = 1
).

In case I perform my INSERT there, the system dumps. 

Execution takes place in a transactional context: A "PHASE <modify>" call is
active with "ZLP_OS_BROKER_DELIVERY". The current statement "INSERT <dbtab>" is therefore forbidden.

I was under the impression that the additional save would prevent this from happening. But it seems the event creates a new RAP phase, in which I still can't INSERT anything.

Am I going about this the wrong way? Thanks in advance for the help 🙂

---

Apologies for the Label, the 'Labels' box only accepts the proposed 'GenAI Assisted Content' although this has nothing to do with the subject 🤔 won't let me post without labels, so it is what it is.

[Tayane]

We helped you to accept the answer as solution. You can un-accept it anytime if you have further questions.

[wridgeu]

Hi, 

I believe what you might be missing is the cl_abap_tx=>save( ) to tell the runtime that this execution is happening within the SAVE-phase? In case you understand german, this part or maybe the entire webinar might be helpful: https://youtu.be/K8YctiZ0LNI

I didn't do that much with the event-ing yet myself so I might be wrong. 🙂

But it sounds about right, quoting the docs: 

• The transactional phases are implicitly set when RAP business events are consumed locally. This means that RAP event handler methods are started in the modify phase when called. If you want to implement database modifications in RAP event handler method implementations, you must explicitly activate the save phase to avoid causing errors detected by the controlled SAP LUW.

hth.

~Marco

[EgbertVenema]

Thanks for the quick reply! I do understand German, so let's give the webinar a go 🙂

Setting the phase to SAVE manually right before the method that performs the INSERT, does fix that specific command. Unfortunately, a little further down the line (still in the standard SAP method) a WAIT command is issued, which is apparently not allowed in the SAVE phase. *sigh* 

A "CALL <save>" call is active with "CL_PRINT_QUEUE_UTILS". The current statement "WAIT" is therefore forbidden.

But good to know we can (and probably should) set the phase manually, thanks for that insight!

[EgbertVenema]

Although the answer by Marco got us a further in understanding the process, it did not solve the issue of not being able to add an item to the print queue. We have raised the issue with SAP support and will update the post when we have an official response.