Adding an Exception to EXIT_SAPLV56U_004

[Former Member]

We have a requirement to exit out of EXIT_SAPLV56U_004 without saving under certain circumstances.  However, there is not an exception defined for FM EXIT_SAPLV56U_004.  We have tested out adding an exception to the FM and it does give us the functionality we need, but has anyone else tried to do this and encountered any issues we should be aware of before we adopt this as our final solution?   We have simply modified EXIT_SAPLV56U_004 to have the exception OTHERS and then added the RAISE OTHERS command in the userexit code. 

We tried other options, such as generating an error message from within the userexit logic, but none of our attempts resulted in the changes not being saved and the processing being terminated cleanly.  We also tried to manipulate SY-SUBRC in the userexit code, but the changed value was not retained once processing exited the customer function, so that also did not work. The only solution that fit our needs was adding and raising the new exception.

We appreciate any feedback from anyone who has either successfully implemented this same modification, or who has encountered issues after doing so.

We are fine with having made the modification to enable the exception, we were just concerned about any potential negative impacts to doing so. But it does appear to be working for our requirements, so if no one responds saying they encountered issues attempting to do the same, then we are happy.

[custodio_deoliveira]

Hi Erin,

You don't need to modify the FM. Just raise the exception and it will be caught in the calling program (assuming the calling program has the EXCEPTIONS OTHERS = 1 on its call ).

One problem I see is that the calling program for this FM is LV56UF03 and after catching the exception it raises an message type 'A' (hardcoded). This will abort the program. Maybe you want to create an enhancement for this subroutine (TABELLEN_ERGAENZEN) to avoid this A message being displayed.

Regards,

Custodio

[Former Member]

Hi Custodio,

Thank you for your response.  We did try to just raise the exception, thinking the very same thing that you mentioned, but the source code would not even compile without us actually adding the exception to the function module.

Once we added the exception to the FM, it did immediately back all the way out of the transaction, but that is acceptable.  Before, with the userexit logic we had in place, it just short dumped.  So we are fine with it just taking them completely out of the transaction - we are generating a message that tells them the reason just prior to raising the exception. But I will look into the TABELLEN_ERGAENZEN subroutine you mention.  Thank you.

Erin

[custodio_deoliveira]

Hi Erin,

This is weird, my code gives a warning but compiles... anyway, happy you have your solution.

Cheers,

Custodio

[Former Member]

We are on ECC6.0 EHP5 - are you on a different version perhaps?  That is strange. 

[Sougata]

Erin,

I have not implemented this User-Exit before but I had a look at the Function Module in the context of your question/concern.

As per the Function Module documemtation:

This function is called up when shipments are saved and the shipment table has been prepared for the update in the database (for example, number assignment, person who last made changes, the time changes were made).
In this function, you can make changes to the shipment tables.
If you want to update your own objects together with the shipment tables, you have to prepare them here for the update.

I see that the design of this User-Exit/Function Module is that for every attribute of a Shipment there are two table parameters provided - A "Current" (or "New") where customers can prepare their updates and an "Old" (or "Before Change") where data is provided before the database change.

Table Xtttt is most current after the change. Table Ytttt stays the same as it was on the database before the changes were made.

Every X table has also been provided with Update Indicators for customers to indicate/confirm their own changes (or not).

The content of the indicator UPDKZ show the change status. In INCLUDE RVDIREKT the constants are defined for the indicator:
updkz_old(1)      value ' '   -   No change
updkz_new(1)      value 'I'   -   New entry
updkz_update(1)   value 'U'   -   Changed entry
updkz_delete(1)   value 'D'   -   Delete entry

To me, putting all the above information together, sounds very much like SAP's intention is to only allow customers to change/update values and not perform any data checks to interrupt the database updates etc. - in other words, "Change" not "Check" as far as this User-Exit is concerned. It also looks very likely that is the reason why no Exceptions are provided in this User-Exit by SAP.

What you enhanced, by adding an exception and handling it, works fine (because its being forced) but it is against the original design and intention of the SAP application(s) who call it. Although the solution might work to suit your business requirement, in my opinion, it is not recommended to implement it this way simply because it violates the purpose of this User Exit.

In the light of the above evidence, I would look at other suitable Exits/BAdIs/Enhancement Spots etc. to be able to perform the intended checks then raise exceptions to interrupt the work process as per the interface provided within those exits.

Cheers,

Sougata.

[Former Member]

Hi Sougata,

Thank you for your response. We did try to manipulate things using the "new" vs "old" working areas, as well as the UPDKZ variables, but it did not work. And you are correct, we realize it is working because we are forcing it to do so.  Which was a bit of a concern to us, hence this post.  But we did investigate several other userexits and such and none were triggered at the right point for us to be able to check the condition we needed to check and throw the exception.  We tried very hard to not do the FM modification, for the same concerns you noted.  So we are in agreement on your points.

Erin

[Sougata]

In that case, I would much rather do an implicit enhancement at end of the form TABELLEN_ERGAENZEN to check my data then throw an exception right there if required rather than implementing the solution via a wrong model (as explained in my first post)

If the checks required are of a low complexity/business logic, I would implement it in a custom FM then call it here.

If the checks required are of medium-high complexity/business logic, I would create and implement a custom Kernel BAdI then call it from here (at end of form TABELLEN_ERGAENZEN).

Cheers,

Sougata.

[Former Member]

Excellent information Sougata.  Thank you - I will try that out and see if it will meet all our requirements.

[Sougata]

You might also consider assigning a Switch to this enhancement so that the check can be turned ON or OFF as/when required. The Switch functionality usually adds a lot of value to the business in the long run.

Depending on the complexity of your check:

• If you are implementing your own Kernel BAdI and calling it here -> Assign the Package of the BAdI Implementation to your Switch so that it automatically becomes switchable (See image below)
  • If you require multiple implementations on your BAdI, it is recommended to assign a separate Switch for each implementation as it provides the flexibility to turn these functionalities ON/OFF for each implementation/business logic which you may or may not require in the future.

• If you are implementing a Function Module (or a Static Method of a Helper Class) and calling it here -> See source code below to levarage the benefits of the Switch Framework as Function Modules & Classes are not Switchable by themselves unlike the New BAdIs.

"at end of Form TABELLEN_ERGAENZEN
CHECK cl_abap_switch=>get_switch_state( |MY_SWITCH| ) = cl_abap_switch=>c_on.
CALL FUNCTION 'MY_Z_FUNCTION'
  EXPORTING ....

Cheers,

Sougata.