Skip to Content

Errors happening in XI may be due to various reasons – Null pointer exception, Array Index out of bounds, some mandatory field not populated etc.

In certain cases, an error condition is encountered and the probability of this occuring is very low -Once in a month or once in 3 months. This condition is known at design time and normally an SLA would be noted for manual cancellation of this message, since no action is required and this message is not required to be reprocessed.

Failed messages can be cancelled manually through SXMB_MONI or using a standard report.  SAP provides a standard report to cancel XI Messages – RSXMB_CANCEL_MESSAGES. This report gives a pop up to confirm deletion of the message/messages.

This blog describes how we can automate cancellation of a failed message at the end of interface execution itself. There is no need of manual intervention.

Here is the step by step solution:

In a message mapping(graphical), we have some pre-defined condition for failure. This will result in failure of the XI message. 

  1. Copy sandard report RSXMB_CANCEL_MESSAGES into a custom report. Lets call it ZRSXMB_CANCEL_MESSAGES.
  2. Create an ABAP mapping which would check if an exception was set in the message mapping(Graphical). 
  3. If the above is true, it would call a custom RFC (ZPI_CANCEL_MESSAGES) which invokes ZRSXMB_CANCEL_MESSAGES  with the XML message id of the failed message.
  4. There is a catch here. Since standard report RSXMB_CANCEL_MESSAGES puts a dialogue before the user during online excecution, it is required to comment out the portion of the code where it puts a dialogue to the user.This enables the report to be executed in the background
  5. This cancels the message after a time lag which can be provided inside the RFC(ZPI_CANCEL_MESSAGES).

Lets consider a file to IDoc sceanrio as an example: 

File has a structure like below:

Header (Occurs only once)

    – FileType, Date, NumberOfRecords.

Detail (Occurs multiple times)

  – MaterialNumber, PlantCode, BatchCode, Quantity 

So our approach will be as follows:

  • We will create a message mapping File to Idoc (Message Mapping name – ThirdPartyFileStructure_To_WMMBXY_WMMBID02) . Say source file is  valid only if Header-FileType = F. If this is not the condition, interface execution should fail. As a result this would be visible as an error message in SXMB_MONI and should be cancelled later.

image

 

  • We will check if Field Header-FileType is F. If no, set an exception message along with message id which would be caught by ABAP mapping executed after graphical mapping. UDF validateFile contains the code for this functionality.

Source code for UDF – validateFile.

 

if (!FileType.equals(“F”)){

 String Error = “This file is not valid..hence this message should fail and subsequently get canceled..”;
 java.util.Map param = container.getTransformationParameters();
 String MessageID = (String) param.get (StreamTransformationConstants.MESSAGE_ID); 
 Error =  Error +  “#” + MessageID;   // Appending message id with error message
 
 DynamicConfiguration conf = (DynamicConfiguration)      container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
 DynamicConfigurationKey keyHeader1 = DynamicConfigurationKey.create( “http://sap.com/xi/XI/System/ERROR“, “ERROR”);
 conf.put(keyHeader1, Error);
}

return “”;

 

  • In interface mapping, an ABAP mapping is included. This ABAP mapping performs no business logic. It checks if there is any exception set in previous message mapping for cancelling the message.

 

image

Main purpose of ABAP mapping is to check if any exception was set. if Yes, it calls an RFC (ZPI_CANCEL_MESSAGES) passing the message id.

 

************************************************************************

* Short description :This ABAP mapping is usedfor cancelling XI messages*

* Message id of the message is passed from a udf in *

* message mapping. *

* If exception is not set in message mapping, it passes the message as *

* it is. In other words, it is used only to cancel the message *

* if no exception is set in message mapping, it does nothing

* and passes the data as it is ….Note the last lines of code (RESULT = SOURCE)..

************************************************************************

************************************************************************

 

 

method IF_MAPPING~EXECUTE.

 

DATA l_record type mpp_dynamic.

DATA: l_exception_raised type String,

task type char10,

l_msg_id type string, “variable to hold message id

l_msg type string. “exception message to be displayed

Constants: l_c_error_number type MPG_ERRCODE value ‘010’.

* getting dynamic configuration value

* filled in by any previous mapping (if an exception was set in message mapping)

CALL METHOD DYNAMIC_CONFIGURATION->GET_RECORD

EXPORTING

NAMESPACE = ‘http://sap.com/xi/XI/System/ERROR

NAME = ‘ERROR’

RECEIVING

RECORD = l_record

.

*if l_record is not initial.

l_exception_raised = l_record-value.

 

 

if l_exception_raised is not initial.

*& Exception message set in XI, would have a message and a message id.

*& message and message id are separated by #.

split l_exception_raised at ‘#’ into l_msg l_msg_id . ” separating message and message id here

*& Pass this message id to RFC to cancel it.

if l_msg_id is not initial.

CALL FUNCTION ‘ZPI_CANCEL_MESSAGES’ STARTING NEW TASK task

EXPORTING

MESSAGE_ID = l_msg_id. “Message id

endif.

RAISE EXCEPTION TYPE CX_MAPPING_FAULT

EXPORTING

* TEXTID =

* PREVIOUS =

ERROR_CODE = l_c_error_number

ERROR_TEXT = l_msg. ” Message to be passed to display in ERROR Segment of the failed message

endif.

*& if no exception message was set..passing the source data as it is

RESULT = SOURCE.   “If no exception message was set, pass the data as it is

                              “since it is a successful message.

endmethod.

 Code for RFC (ZPI_CANCEL_MESSAGES)

 

 FUNCTION ZPI_CANCEL_MESSAGES.
*”——————————————————————–
*”*”Local Interface:
*”  IMPORTING
*”     VALUE(MESSAGE_ID) TYPE  STRING
*”——————————————————————–

*”——————————————————————-*
*& Description: This FM takes input an xml message id and calls a    *
*               custom report which cancels this message             *
* This XML message id is passed from message mapping                 *
*——————————————————————–*

DATA: text       TYPE c LENGTH 100,
      rspar_tab  TYPE TABLE OF rsparams,
      rspar_line LIKE LINE OF rspar_tab,
      range_tab  LIKE RANGE OF text,
      range_line LIKE LINE OF range_tab,
      date1 like sy-datum,
      date2 like sy-datum,
      time1  TYPE sy-uzeit,
      time2  TYPE sy-uzeit.

      date1 = sy-datum – 1.   “Setting the date1 to yesterday
      time1 = ‘000000’.       ” variable Time1 from 000000

      date2 = sy-datum.       “putting today’s date.
      time2 = ‘235959’.       “Setting time for today’s date.

range_line-sign   = ‘E’.
range_line-option = ‘EQ’.
range_line-low    =  MESSAGE_ID.
APPEND range_line TO range_tab.

*–Wait for 30 seconds..

WAIT UP TO 30 SECONDS.

*–Calling the report to cancel the message.
submit ZRSXMB_CANCEL_MESSAGES with  exedate eq date1
                             with   exe2date eq date2
                             with   exetime eq time1
                             with   exe2time eq time2
                             with   msgguid in range_tab
                             with   test eq ‘ ‘
                             with   l_answer eq 1.

ENDFUNCTION.

 

  • Create a copy of standard report RSXMB_CANCEL_MESSAGES say ZRSXMB_CANCEL_MESSAGES and comment out the code where it callls the function module POPUP_TO_CONFIRM. Also set variable l_answer as 1. Setting l_answer means this function module POPUP_TO_CONFIRM confirms deletion of the message.

This code is around line 350 in standard report.

image

  • Do not forget to set l_answer to 1 in the initial part where data is declared (around line 43)

image

 

Requirement is met !!

Now execute the interface end to end. Test the interface with an invalid file which would have Field FielType! = F (it should be F for interface execution).

So Message mapping would execute and set exception which ABAP mapping would handle later as last execution step. ABAP mapping would check the exception and pass the message id to RFC which calls the custom report and cancels the message after 30 seconds (this can be as you like) and provides relevant message in Error segment.

Message monitoring would show something like this.

image

 

After 30 seconds..

 

image

 

Exception Message in Error Segment.

 

image

 

Some important points:

  • ABAP Mapping performs no business logic. It checks if exception was set (inside Message Mapping), if yes, raise the exception and call the RFC to cancel the message. If exception was not set, pass the data as it is (Note the last line of abap mapping code RESULT = SOURCE).
  • RFC ZPI_CANCEL_MESSAGES can be called from a UDF also. In that case there is no requirement of ABAP Mapping. I used ABAP mapping in order to display exception message in ERROR segment in SXMB_MONI. If we do not use ABAP mapping, exception message would be visible in TRACE only (not in ERROR segment)
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply