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.

Vendor Replication from ECC to SRM

 To replicate vendors from ECC to your SRM system so that no vendor issues arise.

How to replicate material master from R/3 to SRM

I am going to present a quick guide to replicate material master from backend system to SRM 5.0, including all the BASIS(BC) activities, I would like to highlight that the system has the latest patch level and support packages installed, so here we go:

Technical details about CLL layer & PDO layer.

PDO Layer

PDO is short form for Procurement Document Layer. PDO layer is available in all SRM versions.  PDO layer helps developer highly to write clear and very specific SRM document level coding. PDO Layer is wrapper of BBP Functions for each SRM business transaction type like PO, Shopping Cart, etc. Each PDO layer uses specific Header, Item and other structures for the SRM business transaction.    The PDO layer level function modules execute the base associated BBP function module and map into PDO specific structure.

For each PDO object type, SRM provides a set of data structures and function modules.   These data structures are very specific to the PDO object type.  For example, PO header detail uses specific structure BBP_PDS_PO_HEADER_D for display purpose and BBP_PDS_PO_HEADER_U for update purpose.  The BBP function module uses common header detail structure BBP_PDS_HEADER for both display and update purposes.

The PDO get detail FM is not using i_read_flag structure instead the flag is set based on the FM parameters are supplied. The Most of PDO GET detail FMs defaults its parameter i_with_itemdata as ‘X’.  That means it will fetch the item level even the item data is requested in the function module.  If the item data is not required then explicitly defines the parameter i_with_itemdata as blank. It is very useful tips of SRM performance tuning.  Also, try to set the parameter  I_WITHOUT_HEADER_TOTALS as blank when header total is not required.   The header total may not be part of all PDO get detail function modules.

Performance Tips

Pass i_with_itemdata as blank in BBP_PD_<BO>_GETDETAIL FM when there is no item data required.  Also, pass parameter i_without_header_totals as empty (Default is true) when there is no total at header is not required.

The PDO level function modules are listed in below table with BBP function module and PDO level function modules.   The PDO layer function module for each object types are defined in the following section.  There are a lot of PDO function modules and the table lists only important function modules.

Action	Function Module	PDO Layer
Check	BBP_PROCDOC_CHECK	BBP_PD_<BO>_CHECK
Create	BBP_PROCDOC_CREATE	BBP_PD_<BO>_CREATE
Get Detail	BBP_PROCDOC_GETDETAIL	BBP_ PD_<BO>_GETDETAIL
Get List	BBP_PROCDOC_GETLIST	BBP_ PD_<BO>_GETLIST
Item Get Detail	BBP_PROCDOC_ITEM_GETDETAIL	BBP_ PD_<BO>_ITEM_GETDETAIL
Lock	BBP_PROCDOC_LOCK	BBP_ PD_<BO>_LOCK
Save	BBP_PROCDOC_SAVE	BBP_ PD_<BO>_SAVE
Unlock	BBP_PROCDOC_UNLOCK	BBP_ PD_<BO>_UNLOCK

The standard naming convention is used for PDO Function and it is defined as follows:

BBP_PD_<BO>_GETDETAIL.  Possible <BO>s

BO	Description
AUC	Auction
AVL	Supplier List
BID	Bid Invitation (RFx)
CONF	Confirmation
CTR	Contract
INV	Invoice
PCO	PO Confirmation
PO	Purchase Order
QUOT	Quotation
SC	Shopping Cart
SUSASN	SUS Advance Notification
SUSCF	SUS Confirmation
SUSINV	SUS Invoice
SUSPCO	SUS PO Confirmation
SUSPO	SUS Purchase Order

Note for performance tuning, support package (give package info) uses BORF concept to get detail instead of BBP function. SAP recommends uses PDO layer instead of BBP get details information.

Channel Logic Layer

The Channel Logic Layer is a wrapper on PDO Layer based on the ABAP objects.  CLL layer is not available at SRM 5 versions. CLL Layer prepares the business data for UI Layer and do specific operation of the SRM business object.   The following are type of objects is available in CLL.

• Business Object (BO) - Business object represents business contents, for example, PO or Shopping Cart. It has all basic operations on the SRM document.
• Dependent Object (DO) - Dependent Object is associated business contents like Account Assignment and Exchange Rate.
• Mapper Object – Mapper object is used to map between UI screens and business data.

Business Objects

The business object is based on ABAP class object. The business object implements the interface classes like /SAPSRM/IF_PDO_BASE and its PDO business object level interfaces.  The methods of PDO_BASE interface refers to basic business operations on the SRM document. The table lists the interface classes for each SRM business object. Note that objects suffixed with _ADV refer the object with workflow.

SRM BO	Interface Class
Auction	/SAPSRM/IF_PDO_BO_AUC
Contract	/SAPSRM/IF_PDO_BO_CTR_ADV
PO	/SAPSRM/IF_PDO_BO_PO_ADV
Quote	/SAPSRM/IF_PDO_BO_QTE_ADV
Bid Invitation	/SAPSRM/IF_PDO_BO_RFQ_ADV
Shopping Cart	/SAPSRM/IF_PDO_BO_SC_ADV

The following table lists the implemented ABAP class for the SRM business objects.  

SRM BO	Implemented Class
Auction	/SAPSRM/CL_PDO_BO_AUC
Contract	/SAPSRM/CL_PDO_BO_CTR_ADV
PO	/SAPSRM/CL_PDO_BO_PO_ADV
Quote	/SAPSRM/CL_PDO_BO_QTE_ADV
Bid Invitation	/SAPSRM/CL_PDO_BO_RFQ_ADV
Shopping Cart	/SAPSRM/CL_PDO_BO_SC

Note that PO object has two implemented classes with and without workflow viz., /SAPSRM/CL_PDO_BO_PO_ADV and /SAPSRM/CL_PDO_BO_PO.

Factory Objects for SRM BO

Factory Objects are static objects where the object instances are stored in the buffer.  This is very useful ABAP Objects. Object instances are buffered and reduce the database accesses.  It increases performance.  All the factory objects have three major methods: get_instance, get_buffered_instance and create_new_instance. 

Method	Description
GET_INSTANCE	Get instance from buffer.  If not, get instance from database.  It will add to buffered instance.
GET_BUFFERED_INSTANCE	Get instance from buffer.  If not, return nothing.
GET_NEW_INSTANCE	Destroy instance from buffer if any and create new instance and add it to buffered instance.
CREATE_NEW_INSTANCE	Create new instance.

The following factor classes are listed in the following table.

Business Object	Factory Class
Auction	/SAPSRM/CL_PDO_FACTORY_AUC
Contract	/SAPSRM/CL_PDO_FACTORY_CTR_ADV
PO	/SAPSRM/CL_PDO_FACTORY_PO_ADV
Quote	/SAPSRM/CL_PDO_FACTORY_QTE_ADV
Bid Invitation	/SAPSRM/CL_PDO_FACTORY_RFQ
Shopping Cart	/SAPSRM/CL_PDO_FACTORY_SC_ADV

The following is sample code to using the Factory class to get instance.

DATA lo_pdo_qte       TYPE REF TO /sapsrm/if_pdo_bo_qte.  CALL METHOD/sapsrm/cl_pdo_factory_qte_adv=>get_instance    EXPORTING      iv_header_guid = is_header-guid    RECEIVING      ro_instance    = lo_pdo_qte.

The get instance will get the instance from factory instance table.  If there is no entry then it will fetch data from database and insert the instance into instance table. 

Based on GUID, model access object returns base record.  The following simple example is a wrapper for BBP_PROC_GETDETAIL function module.

DATA: lo_pd_model TYPE REF TO /sapsrm/if_pdo_model_access,       lt_status          TYPE bbpt_pds_status,       ls_header          TYPE BBP_PDS_HEADER.   lo_pd_model = /sapsrm/cl_pdo_model_factory=>get_instance( ).  lo_pd_model-get_detail(EXPORTING iv_guid = iv_header_guid                          IMPORTING es_header   = ls_header                                    et_status = lt_status ).

Dependent Object

CLL objects support a wide list of dependent objects to get associated section of the data.  The dependent class objects interfaces a number of interface classes.  The following table lists few of Dependent Object Classes.  Each DO object interfaces the corresponding DO interface /SAPSRM/IF_PDO_DO_ <DO>, /SAPSRM/IF_PDO_BO_BASE and /SAPSRM/IF_PDO_XO.  The dependent object uses basic BBP function.  The DO objects are invoked by the business object. Theses dependent objects are part of attributes in the business object.

SRM DO	Implemented Class
Condition	/SAPSRM/CL_PDO_DO_CND
Dynamic Attributes	/SAPSRM/CL_PDO_DO_DYNATTRI
Exchange Rate	/SAPSRM/CL_PDO_DO_EXR
Freight	/SAPSRM/CL_PDO_DO_FREIGHT
History	/SAPSRM/CL_PDO_DO_HISTORY
Limit	/SAPSRM/CL_PDO_DO_LIMIT
Long Text	/SAPSRM/CL_PDO_DO_LONGTEXT
Org data	/SAPSRM/CL_PDO_DO_ORGDATA
Partner	/SAPSRM/CL_PDO_DO_PARTNER
SOS	/SAPSRM/CL_PDO_DO_SOS
Status	/SAPSRM/CL_PDO_DO_STATUS
Tax	/SAPSRM/CL_PDO_DO_TAX
Version	/SAPSRM/CL_PDO_DO_VERSION
Weight	/SAPSRM/CL_PDO_DO_WEIGHT

Mapper Object

The mapper object creates connection between the UI and Business object.   SRM provides a list of BOM (business object mapper) and each object type refers to a BOM.    The BOM has been instantiated in the web Dynpro application using the object /SAPSRM/CL_CH_WD_TASKCONTAINER.  The BOM mapper instance is created using the ABAP object /SAPSRM/CL_CH_WD_MAP_FACTORY.    The factory class has a separate method for each SRM object type.

Object	SRM BO Mapper
Auction	/SAPSRM/CL_CH_WD_BOM_AUC
Confirmation	/SAPSRM/CL_CH_WD_BOM_CONF
Contract	/SAPSRM/CL_CH_WD_BOM_CTR
Invoice	/SAPSRM/CL_CH_WD_BOM_INV
Purchase confirmation	/SAPSRM/CL_CH_WD_BOM_PC
Purchase Order	/SAPSRM/CL_CH_WD_BOM_PO
Quota Arrangement	/SAPSRM/CL_CH_WD_BOM_QTA
Quote	/SAPSRM/CL_CH_WD_BOM_QTE
Bid Invitation	/SAPSRM/CL_CH_WD_BOM_RFQ
Shopping Cart	/SAPSRM/CL_CH_WD_BOM_SC
SUS ASN	/SAPSRM/CL_CH_WD_BOM_SUSASN
SUS Confirmation	/SAPSRM/CL_CH_WD_BOM_SUSCONF
SUS Invoice	/SAPSRM/CL_CH_WD_BOM_SUSINV
SUS PO	/SAPSRM/CL_CH_WD_BOM_SUSPO

Note that above objects implements interfaces /SAPSRM/IF_CLL_MAPPER and other mapper interfaces. 

Dependent Object Mapper (DOM) refers a particular section of the document.  For example, PO has header overview screen and it refers to DOM mapper /SAPSRM/CL_CH_WD_DODM_PO_OV_H.   The DOM classes are instantiated using its own BOM object.  The BOM has separate method for each DOM used by SAP.