Recently I had look on how to handle AIF error message inside the source code and enable them in the logging.

Because not all end users were comfortable with /AIF/ERR to check AIF message status. However, I couldn’t find a blog where it is explained in detail, so I decided to post how I handled error messages technically in my case.

Before dive in, I would like to share two interesting and useful information how to monitor errors with dedicated AIF transactions:

1. Monitoring and error handling for interfaces in AIF
2. Error Handling in SAP Application Interface Framework (SAP AIF)

Now let’s have a look to the case that I encountered and how I solved. I used AIF automatic reprocessing. ( Please find the steps in my previous blog: AIF Automatic Reprocessing makes life easier )

I have defined FM ZAKB_FM_INSERTITEMOBD to handle the actions during the automatic re-processing.

Here is the logic where I am triggering the AIF automatic re-processing. But the point is here that call is not returning any success or error message:

" Call AIF automatic re-processing
TRY.
    /aif/cl_enabler_xml=>transfer_to_aif( is_any_structure = ls_new_itemobd " Persistence structure type to keep payload
                                          iv_queue_ns      = 'ZIFTST' " AIF Namespace
                                          iv_queue_name    = 'ZRC' ). " Runtime group configuration ID

  CATCH /aif/cx_aif_engine_not_found INTO DATA(lx_engine_not_found).
  CATCH /aif/cx_enabler_base INTO DATA(lx_enabler_base).
  CATCH /aif/cx_aif_engine_base INTO DATA(lx_engine_base).
  CATCH /aif/cx_error_handling_general INTO DATA(lx_error_handling).
  CATCH /aif/cx_inf_det_base INTO DATA(lx_inf_det_base).
ENDTRY.

So, as a solution let’s do the following steps.

Initially, generate persistence table for the payload via the transaction /AIF/PERS_TBL_GEN. After table generation, you see it contains all the fields from your persistence structure, plus to that some key fields like below:   

So, when you trigger a call to AIF, new entry will be created with respect to your namespce, interface name and interface version.

Secondly, we need to get an entry that is created during the AIF call, so we should make a small change while calling /aif/cl_enabler_xml=>transfer_to_aif, from the class signature we can see that it has one exporting parameter – EV_MSGGUUID.

It will return generated message GUID, that we will use to find generated messages.

As final step, we need to get AIF generated messages and they are stored in the table – /AIF/MMSG_VARS AIF Message Variables. Here I am getting the messages via select statement with respect to message GUID, namespace and interface name.

" Get the log messages from AIF Framework
  SELECT * FROM /aif/mmsg_vars INTO TABLE @lt_aif_messages
    WHERE msgguid = @lv_aif_message_id
      AND ns      = 'ZIFTEST'
      AND ifname  = 'ZIF_OBDINS'.

  " Add messages to log
  LOOP AT lt_aif_messages ASSIGNING FIELD-SYMBOL(<fs_aif_messages>).
    " Map the exception error messages
    INSERT VALUE #( id         = <fs_aif_messages>-msgid  number     = <fs_aif_messages>-msgno
                    message_v1 = <fs_aif_messages>-msgv1  message_v2 = <fs_aif_messages>-msgv2
                    message_v3 = <fs_aif_messages>-msgv3  message_v4 = <fs_aif_messages>-msgv4 
                    type       = <fs_aif_messages>-msgty ) INTO TABLE return.
  ENDLOOP.

To sum up, now you can map selected messages appropriately to your log and end user can check AIF related messages in the log as well.