Even though ERROR / 'E' type message, still program is executing normally!!

[former_member194142]

Hello,

We have a custom workflow, z_workflow.

In this z_workflow, its calling a custom FM, z_fm.

In this z_fm, I'm updating a custom tbale, z_table.

Before writing UPDATE z_table, I am locking this z_table by using 'ENQUEUE_E_TABLE', as below,

Pls. note this workflow is triggering in BACK GROUND by WF-BATCH user

                CALL FUNCTION 'ENQUEUE_E_TABLE'
                  EXPORTING
                    mode_rstable   = 'E'
                    tabname        = 'Z_TABLE'
                  EXCEPTIONS
                    foreign_lock   = 1
                    system_failure = 2
                    OTHERS         = 3.
                IF sy-subrc = 0.
                   UPDATE z_table
                   SET matnr = ls_mara-matnr
                          descr = lv_text
                    WHERE ref_id = ref_id.
                   CALL FUNCTION 'DEQUEUE_E_TABLE'
                    EXPORTING
                      mode_rstable = 'E'
                      tabname      = 'Z_TABLE'.
                 ELSE.
                     MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno 
                         WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. =====>
 ==> If the lock is failing an an ERROR / 'E' type message is occuring, but still the 'Rest of the code blocks' are executing normally (where in 2nd_z_table is updating), but the workflow is ending up in 'Error state' in SWI1 (workflow log) transaction, our users who are monitoring this workflow thinking that the transaction went bad, but again they noticed that the 2nd_z_table is updating as usual!!                          
                ENDIF.
 
                Rest of the code blocks ==> here another custom tbl, 2nd_z_table is updating

Our workflow expert said that, the error is occuring, well, but as its (z_fm) calling from / by back ground workflow user, hence the 'Rest of the code blocks' are triggering normally and the 2nd_z_table is updating as usual, but overall the workflow ends up in error state!

To avoide this confusing situation (workflow in error, but rest of the code blocks are executing normally), workflow expert suggested the below approach (raising of EXCEPTION in z_fm instead of ERROR message), pls. suggest me is it OK / safe / works good for me?

                DO 10 TIMES. => Workflow expert asking me to add all these blue lines to my code
                CALL FUNCTION 'ENQUEUE_E_TABLE'
                  EXPORTING
                    mode_rstable   = 'E'
                    tabname        = 'Z_TABLE'
                  EXCEPTIONS
                    foreign_lock   = 1
                    system_failure = 2
                    OTHERS         = 3.
                IF sy-subrc = 0.

                   UPDATE z_table
                   SET matnr = ls_mara-matnr
                          descr = lv_text
                    WHERE ref_id = ref_id.
                   CALL FUNCTION 'DEQUEUE_E_TABLE'
                    EXPORTING
                      mode_rstable = 'E'
                      tabname      = 'Z_TABLE'.
                  CLEAR lv_locking_failed_on_z_table. 
                  EXIT. 
                ELSE.
                  WAIT UP TO 1 SECONDS. 
                  lv_locking_failed_on_z_table = abap_true. 
                ENDIF.
              ENDDO. 
 
              IF lv_locking_failed_on_z_table IS NOT INITIAL.
                RAISE exception_lock_failed.  ===> Does the Raising EXCEPTION is solve my problem? pls. suggest me
                RETURN. 
              ENDIF. 

 

workflow expert said with this raising of exception will not trigger 'Rest of the code blocks' so that user will be not confused

Thank you

[Florian]

And why don't you believe your workflow-expert?

Maybe you should trust people.

And on the other hand you can read/learn a lot about workflow programming by using the search...

~Florian

[former_member194142]

Here, not the question of trusting!

I am the owner/responsible for z_fm and now these changes/fix is planned to do in my z_fm, hence if something goes wrong I need to answer, hence I want to make sure

Bcz of some reasons, we don't have a chance to test/reproduce this issue in DEV/ACC environments, hence we are planning to migrate the fix ASAP to PRD, therefore my responsibility is more intense

Now, at this point (migtate fix ASAP to PRD) I don't want to go thru all the workflow books and learn workflow and fix the issue and send it to PRD

[arindam_m]

Hi,

I cannot see the whole code block, but if the workflow is still registering the error as mentioned by you and the only concern is to avoid the 2nd table update. Then why don't you put the 2nd table update under the IF condition if you do not want to use the RAISE exception.

As workflows are event triggered thus a RAISE is required as the its not like a normal report or code.

Cheers,

Arindam

[Nawanandana]

Hi,

Can you check your FM working peopwely first? iF its work kindly check the parameter which you pass to FM correct. Some time you have to used 'CONVERSION_EXIT_ALPHA_INPUT. And you have to clear FM parameter as well .

Regard,

Nawa.

[Former Member]

Hello!

This SAP Help Content is suggestive about this issue:

Messages in Function Modules and Methods (SAP Library - SAP NetWeaver by Key Capability)

If you want the following code blocks to be ignored, as your WF colleague and others have suggested, i recommend you to use the raise statement. It forces the current processing to retreat, and report the caller that something went wrong, similar as what we can do with methods, that raise an exception class which have to be handled by the catch statement, that is set by the caller.

If you want to minimize the development effort, you can add the "raising" complement to the end of the message statement, just like this:

======================================================================

MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno

                         WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4  RAISING exception_lock_failed.

======================================================================

I have used this way of exception handling and it did work, maybe the right way could be a variation of it, i wish but i can´t set a test right now.

I am not sure if there are other factors that could affect the raise, from workflow of anything else, despite of it, i believe the raise should do the work.

Hope it helps!

Regards,

Renan