BBP_BACKEND_DEST settings in SRM

Purpose

This page describes the correct settings for table BBP_BACKEND_DEST in a SUS client.

Overview

• Logical System name
• System type
• SLD system name

Logical System name

The logical sytem name (field LOG_SYS) in table BBP_BACKEND_DEST needs to be unique for each client and it must match the value from field LOGSYS in table T000. Example:

• Your system ID is SRM and client 330 is your SUS client.
• In T000 you have defined SRMCLNT330 in field LOGSYS for client 330.
• In client 330 BBP_BACKEND_DEST field LOG_SYS the value must be maintained as SRMCLNT330 as well.

In the delivered customizing of a freshly installed SRM system there will be an entry maintained in table BBP_BACKEND_DEST for logical system E7SCLNT300. This entry needs to be removed, with the exception if your system ID is E7S and your SUS client is 300.

It is also recommended to use the same name for Logical system and RFC destination.

System type

According to your scenario in your BBP_BACKEND_DEST table you will have several entries, one for the local system and one or more for the connected backend system. The system type value (field SYS_TYPE) of these entries must be set as follows:

• For your local SUS client maintain the value SUS_1.0. Please do not use the value LOCAL as it is wrong. Instead you must set the flag for field LOC_SYS. (Only one entry may be flagged this way)
• For an EBP/SRM client maintan the value EBP_5.0. Please do not use the values like SRM_7.0, SRM_7.01 even if this matches your SRM systems version level. These values are wrong, an SRM clients system type in a SUS client must be always set to EBP_5.0.
• For an ECC backend logical system please set the system type according to your backend release either as R/3_... or ERP_...

SLD system name

Under SLD system name you need to configure the Business System name of the corresponding system/client as you have maintained it in your System Landscape Directory configuration on your PI system. The SLD system name can differ from the logical system name, but it needs to uniquely identify the logical system and client, thus the same SLD system name may not be added to different entries in the table.

SAP Note :1846783

Monitoring of Processed XML messages

Purpose

This page describe the usage of the tool SXI_MONITOR for monitoring of processed XML messages in SUS.

Overview

• Starting the Tool
• Searching for XML messages
• Displaying results

Starting the Tool

The XML monitor tool can be started directly by transaction code SXI_MONITOR. It is also possible to use transaction code SXMB_MONI and select the entry „Monitor for Processed XML Messages” in the displayed list. The monitor will be started with this starting screen:

Searching for XML messages

There are several possibilities to search for XML message in SXI_MONITOR.

• You can use the date and time, as well as Sender and Receiver information to search on the main screen of SXI_MONITOR. This will give you a list of all XML messages corresponding to the search criteria regardless of what status the message is in.
• In case you are only looking for XML message that are in error status, you can use the selection criteria for ’Status Group’ and specify the value ’Errors’ here
  
• If you already know the XML message ID of a particular XML message please select the ’Advanced Selection Criteria’ tab and and specify the ID in the field ’Message ID’
  
• As of SRM 7.0 you can use the report /SAPSRM/PUR_SELECT_MESSAGES in SE38 for finding XML messages for a specific purchase order.

 Please make sure to set the ’Length of Output List’ parameter depending on your search criteria

Displaying results

  

The found XML message will be displayed in an ALV result list. You can change the layout and specify the displayed fields and sort order as it is common for an ALV list. To view the details of a specific message, please select it and use the ’Details’  button, or double click on an XML message.

To identify an error in the processed message in many cases you can refer to the content of ’Window 2’ after opening the XML message.

Otherwise you will find more information on the kind of error in the Trace section, which can be accessed from the left side navigation tree. In case of SUS application errors there will be a section called <FAULT_TEXT> containing the error message encountered during application processing of the XML message.

  

This is possible only for non ESOA type XML interfaces that are not using the Forward Error Handling (FEH). Following interfaces in SUS will use the FEH, if activated and configured:

• PurchaseOrderERPRequest_In_V1
• ServiceAcknowledgementERPConfirmation_In
• ServiceAcknowledgementERPNotification_In

For XML messages processed via these interfaces please use transaction code /SAPPO/PPO2 to identify application error message issued during XML processing.

To display the actual content, called as playload, of the XML message please use the left side navigation tree and double lick on the entry Inbound Message -> Payloads -> MainDocument. The payload is displayed in 'Window 2' of the content area. To save the payload in XML format in a file, you can use the save file icon for 'Window 2'.

XML message not generated

Symptom

You have created a SUS (or SRM) document for which an XML message should be generated and sent to the connected system. The document is created but there is no XML message generated, in transaction SXMB_MONI  no corresponding XML is found. This happens for a specific document type or for all document types in SUS.

Resolution

To resolve this issue please go through the following steps and check for correctness in your SUS system.

1. Please check if the BBP_BACKEND_DEST settings in your system are correct.
2. In some of the SRM releases there are missing settings in the delivered Event customizing. Please check Note1818390 and 1997137 
3. Please start transaction SLDCHECK and verify if there are any issues with the SLD connection
   SLDCHECK should return a couple of green entries with the following information:
1. RFC ping was successful
2. Function call terminated sucessfully
3. Summary: Connection to SLD works correctly
4. If there are any issues, SLDCHECK will return some information what to check. Please check and correct the settings until everything is indicated with green status.

After all of the above steps were performed and there is still no XML output message generated.

Debugging tool for incoming XML messages

Purpose

This page describe the usage of the tool SPROXY to debug incoming XML messages in SUS.

Overview

• Selecting XML message
• Starting the Tool
• Debugging
• Debugging tips

Selecting XML message

To debug the incoming XML processing, you will need a failed or successful XML message. To identify such a message you can use transaction SXI_MONTIOR. Often the failed XML message will contain already some information about an error as described on this page, so that debugging will not be even necessary. If debugging is not avoidable please save the payload of the XML message as an XML file, as described on the referred Wiki page. Please also mark the receiver namespace and interface.

Starting the Tool

The tool you need for debugging the XML processing can be started with transaction SPROXY, which will display an Object Navigator similar to SE80 transaction:

Under Enterprise Service Repository you will be presented an object list for all the relevant software component versions installed on your system. Open the node for your version of SRM SERVER and search for the namespace and interface of your XML message. Once you find it please double-click the interface name which should bring up a screen similar as this:

Debugging

To be able to debug the XML message processing first you need to execute the proxy, by pressing the  button. On the Test Service Provider screen please chose the 'Debug Method' options and press the 'Execute' button.

This will bring up the XML Display/Editor window pre-filled with a dummy XML content. To be able to debug your XML message first you will need to load the previously saved XML file by using the 'Load file' button.

To start debugging now press the 'Execute' (F8) button.

Debugging tips

It is not always straight forward to find out during debugging where a particular error is issued. Different kind of errors will be handled in different ways. The following program elements could be used to set a breakpoint to identify an error:

• Function Module
  BBP_PD_ABORT
  BBP_PD_MSG_ADD
  BBP_MESSAGE_APPEND
• Class
  CX_BBP_PD_ABORT
• Statement
  CATCH
  RAISE

You can use the built in editor in SPROXY transaction before executing an XML message debugging to change data in the XML. To simulate the behavior you could for example change, delivery date, prise, unit of measure, etc. for a Purchase Order XML. It will be necessary for example to change the backend PO number in the XML message if you want to debug the creation of a PO and the XML message has already been processed successfully, which means the SUS PO document has been already created on database level. In this case you can change the PO number to a fictional number in order a new PO can be created during XML debugging.

Monitoring and Debugging XML Messages in SAP SRM 7.0 System

The article describes the procedure to monitor as well as debug the failed XML messages in SAP SRM system. In this scenario, data migration is from SAP R/3 (ECC 6.0) to SAP SRM 7.0 via SAP XI.