Application Development and Automation 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: 
Read only

Nested perform on commit

brandongailey
Participant
0 Likes
4,235

How do I figure out where the program is being commited at?

Technical information about the message:

Message class....... 00

Number.............. 081

Variable 1.......... "NESTED_PERFORM_ON_COMMIT"

Variable 2.......... "caller: SAPLCRM_BUPA_CRMD_DIALOG"

Variable 3.......... "program: SAPLCRM_BUPA_CRMD_DIALOG"

Variable 4.......... "form: BAPI_SAVE_BUFFER"

1 ACCEPTED SOLUTION
Read only

Private_Member_7726
Active Contributor
0 Likes
2,847

Hi,

The way I understand it, somewhere in Form BAPI_SAVE_BUFFER, which is executed on commit, some logic tries to register another/same formroutine ON COMMIT.  You'd need to set breakpoint in Form BAPI_SAVE_BUFFER of SAPLCRM_BUPA_CRMD_DIALOG and enable Settings -> Update debugging in new debugger to debug that, I think.

Maybe OSS Note 1811416 - Dump NESTED_PERFORM_ON_COMMIT occurs while saving BP is relevant as well?

cheers,

Janis

11 REPLIES 11
Read only

Former Member
0 Likes
2,847

you mean where your program is running?

Try, for exemple, SM66.

Read only

0 Likes
2,847

Not exactly. This is the first time I have run into a NESTED_PERFORM_ON_COMMIT dump and I am not sure how to figure out where it is located at....

Read only

Private_Member_7726
Active Contributor
0 Likes
2,848

Hi,

The way I understand it, somewhere in Form BAPI_SAVE_BUFFER, which is executed on commit, some logic tries to register another/same formroutine ON COMMIT.  You'd need to set breakpoint in Form BAPI_SAVE_BUFFER of SAPLCRM_BUPA_CRMD_DIALOG and enable Settings -> Update debugging in new debugger to debug that, I think.

Maybe OSS Note 1811416 - Dump NESTED_PERFORM_ON_COMMIT occurs while saving BP is relevant as well?

cheers,

Janis

Read only

0 Likes
2,847

Here is what the code looks like in BAPI_SAVE_BUFFER   FORM bapi_save_buffer.
* Local data.
  DATA lv_global_memory TYPE REF TO lcl_fragment_global_memory.

* Save the content of the global memory.
  CALL METHOD lcl_fragment_global_memory=>get_instance
              IMPORTING ev_instance = lv_global_memory.
  CALL METHOD lv_global_memory->save_to_database
              EXPORTING iv_in_update_task = gc_x.

ENDFORM.

I do not think any OSS notes apply to my situation because I am getting this error only when using the MSA. Let me know if I am wrong in my assumptions.

Read only

0 Likes
2,847

I don't have access to CRM System, but my guess is the abort happens somewhere within CALL METHOD lv_global_memory->save_to_database chain. I'd try to do the following:


1) go to SE91 and do a where used list for message number 081 of message class 00; you should find two uses in program SAPMSSY0; it's the first one, in subroutine %_order_form_level, that is of interest;

2) set the break-point on the message x081(00) with mpar1 mpar2 mpar3 mpar4 statement or just before it (it's the line number 89 of program SAPMSSY0 in my system);

3) enable System Debugging and Update Debugging via Debugger menu Settings->Change Debugger Profile/Settings

4) run the logic that triggers shortdump; debugger should open just before shortdump and hopefully you should be able to figure out the call chain that leads to this error


What's MSA? Edit in: Ok, I found what's MSA Does that mean you will not be able to debug what's happening in CRM..? Then I'm out of ideas, unfortunately...


cheers,

Janis

Read only

0 Likes
2,847

I did figure out a way to debug. When debugging and setting a break point at the line you suggested (which makes sense) it skips from line 74 to 93

74     if sy-oncom = 'P'.

75 *     already in PERFORM ON COMMIT

76       call 'C_SAPGPARAM' id 'NAME'  field 'abap/allow_nested_poc'  "#EC CI_CCALL

77                          id 'VALUE' field allow_nested_poc.

78       if allow_nested_poc <> 'X'.

79 *       nested PERFORM ON COMMIT not allowed

80         call 'AB_GET_CALLER' id 'PROGRAM' field caller.  "#EC CI_CCALL

81         if caller <> 'SAPMSSY0'.

82           mpar1 = 'NESTED_PERFORM_ON_COMMIT'.

83           concatenate 'caller:'  caller into mpar2 separated by ' '.

84           concatenate 'program:' prog   into mpar3 separated by ' '.

85           concatenate 'form:'    rout   into mpar4 separated by ' '.

86 *         switch back kernel flag: just for sure.

87           call 'SET_SWITCH_TXEND' id 'STATE' field ' '.  "#EC CI_CCALL

88 *         issue short dump

89           message x081(00) with mpar1 mpar2 mpar3 mpar4.

90         endif.

91       endif.

92     endif.

93     read table orders

Continuing to debug to try to find something...

Read only

0 Likes
2,847

Found where the error is happening, trying to understand why.

Function /MSA/MD_BIPA_CREATE CALLS Funtion 'BAPI_TRANSACTION_COMMIT'

      CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

        EXPORTING

          wait   = lc_x

        IMPORTING

          return = ls_return.

My custom method calls    CALL FUNCTION 'BAPI_BUPA_FRG0040_CREATE'

  CALL FUNCTION 'CRM_BUPA_FRG0040_CREATE'

       EXPORTING

            IV_PARTNER_GUID       = GV_PARTNER_GUID

            IS_DATA               = GS_SALES_CLASS_DATA

       IMPORTING

            ET_RETURN             = RETURN[].

The above function performs the following:

*   Register the global buffer for saving.

    PERFORM bapi_save_buffer ON COMMIT.

Which does this:

    if sy-oncom = 'P'.

*     already in PERFORM ON COMMIT

      call 'C_SAPGPARAM' id 'NAME'  field 'abap/allow_nested_poc'  "#EC CI_CCALL

                         id 'VALUE' field allow_nested_poc.

      if allow_nested_poc <> 'X'.

*       nested PERFORM ON COMMIT not allowed

        call 'AB_GET_CALLER' id 'PROGRAM' field caller.  "#EC CI_CCALL

        if caller <> 'SAPMSSY0'.

          mpar1 = 'NESTED_PERFORM_ON_COMMIT'.

          concatenate 'caller:'  caller into mpar2 separated by ' '.

          concatenate 'program:' prog   into mpar3 separated by ' '.

          concatenate 'form:'    rout   into mpar4 separated by ' '.

*         switch back kernel flag: just for sure.

          call 'SET_SWITCH_TXEND' id 'STATE' field ' '.  "#EC CI_CCALL

*         issue short dump

          message x081(00) with mpar1 mpar2 mpar3 mpar4.

        endif.

      endif.

Read only

0 Likes
2,847

I believe that I need to either find a way for FUNCTION 'BAPI_BUPA_FRG0040_CREATE' to not commit or find another way to set the flag that does not make me commit.

Read only

0 Likes
2,847

Hi,

Congrats! Now the hard stuff continues - finding safe integration point for custom logic... I wouldn't try to force anything on BAPI_BUPA_FRG0040_CREATE (at least not until exploring other possibilities).

How (some BADI, user exit, something else?), and on what conditions, is your method getting triggered currently? Does it need to be integrated with MSA at all?

Does it need to be integrated with MSA only? If yes, I'd try to find (or even create by implementing some implicit enhancement point) an integration point so it gets called BEFORE MSA commits (calls 'BAPI_TRANSACTION_COMMIT'). That way your changes too would be in the MSA LUW.

If it is not absolutely necessary to have your changes within MSA LUW (merely doing them after MSA has committed is enough), you could wrap the logic of your method in an event handler method for CL_SYSTEM_TRANSACTION_STATE=>TRANSACTION_FINISHED event instead, and in the current method merely register the event handler. TRANSACTION_FINISHED is actually more suitable for "cleanup" (it gets trigerred on ROLLBACK as well!), but if it suits your requirements and there is some logic that would commit your updates - why not? Let me know if you need example how to create and register TRANSACTION_FINISHED handler.

If the logic needs to integrate with MSA and with some other SAP functionality then it get's even more complicated... If the changes must not necessarily be within SAP LUWs, I'd probably switch on BOR Event Trace in SWELS and look for appropriate event in SWEL in order to do the changes asynchronously via some "loose coupling" BOR event handler. If there are no suitable events, i'd try to program and trigger my own... If your changes must be within SAP LUWs, it's hard to suggest something without being able to explore SAP code you need to integrate with...

Exciting stuff...

cheers,

Janis

Read only

0 Likes
2,847

Found out that it is a problem with BAPI_BUPA_FRG0040_CREATE and BAPI_BUPA_FRG0040_CHANGE because both call a commit.

It currently works for the Web UI but not for MSA, so to answer your question about integrating with MSA only...that is a no. This seems to be getting more complicated.

Read only

0 Likes
2,847

Hi,

If by "both call a commit" you mean PERFORM <routine to save data> ON COMMIT, then yes - that's the way how SAP Business Partner BAPIs (or rather the BP API, which is wrapped by BAPI) often (if not always) builds the LUWs.

MSA uses CRM Business Partner BAPI to create business partner. The custom logic should get triggered upon creating CRM business partner and already works as intended when the partner is created over Web UI - do I get it right?

cheers

janis