Integration of SAP Sourcing with SAP ERP allows for seamless transactions with replication of master data and transfer of Business Document's between the two systems. The following document outlines the Good Business Practices that can be employed while considering the integration during the planning phase of the Implementation cycle.
Standard Solution –Publishing Process (ES/PI/ERP):
The standard solution is designed to allow the publishing of Awards or Master Agreements as Purchase Orders and Outline Agreements to the ERP system. This is a synchronous process; meaning that the end user will have to wait after clicking the ‘Publish to ERP’ for a valid response before initiating any other action in the User Interface. Following is the sequence of events that occur during the Publish process:
- Validate the Business Document in SAP Sourcing
- Generate the XML payload that will be sent to the SAP PI system
- The Integrated Document Configuration is considered to determine the content of the XML payload
- Connect to the SAP PI system and submit the XML payload
- In SAP PI, the XML payload is mapped to the Function ‘BBP_ES_UPDATE’
- SAP PI then invokes the call to SAP ERP system with the transformed Payload
- In the SAP ERP system, the Business Document is validated for completeness and consistency and then created
- At this step, the SAP ERP configuration is read and interpreted
- The SAP ERP system, upon successfully creating the document, will return the Document Number that was generated as well as any success and other messages (warning and error)
- The return call from SAP ERP is mapped back in SAP PI to the SAP Sourcing call and the values returned to SAP Sourcing
- In SAP Sourcing, the process completes upon the following occurring:
- Updating the document number from SAP ERP on the header and line item
- In the case of an error – a pop-up message displaying the reason for the error
NOTE: In the case of success, a pop-up window is not displayed. You can reference the document number on the Header of the Business Document in SAP Sourcing as confirmation of a successful publish.
As can be seen above, the entire process is ‘Synchronous‘ by design to provide immediate feedback to the end user with regards to the completeness of the transaction.
It has been found that for most business needs this standard behavior will enable good end user response times and user interaction.
Implications due to Extending/enhancing the standard process:
When the standard solution does not support the required Business demands, it is necessary to extend the standard functionality which procedurally involves:
- Extension fields or elements on the business documents
- Scripts to support the validations or other business needs
- SAP PI Mapping related changes (to message types and mapping) to support the new fields
- Enhancements to the ‘receiving’ function modules (BBP_ES_OA_UPDATE, BBP_ES_PO_CREATE) to support these new fields
Depending on the complexity of such enhancements, the behavior of the standard solution will be impacted and will result in a differing end user experience. The effect will be more pronounced if enhancements or extensive scripting is used for validations etc. at the line item level or a sub-Object level that has collections.
Performance of the standard system under normal designed loads:
With Integration and also as an outcome of the synchronous nature of the calls to SAP ERP, the end user experience and thereby the performance of the system will be determined by several parameters:
- Sizing of the system to support the concurrent users and the business use cases
- Number of users currently logged in and actions being performed
- Batch jobs that may be running
- Current SAP Sourcing system load in terms of the memory consumption
- If detailed Logging or Tracing is enabled
- Network latency (since data needs to be sent to SAP PI and SAP ERP systems)
- SAP PI system load
- SAP ERP system load
- Size of the Business Document – not necessarily limited to the number of line items but including all collections and sub collections
- .. several others
The performance could be different under differing conditions since it will not always be able to predict what the load on the SAP PI and SAP ERP systems are even though SAP Sourcing could have been sized and managed well.
As an example, under standard behavior and in the SAP test landscape with few users or just the performance test user logged in and with nothing but a very basic document containing the bare line items, the following metrics have been observed relating to the publishing of Business Documents from SAP Sourcing to SAP ERP.
1. Publish Master Agreements to SAP ERP
| Number of Line Items | MA Publish to ERP: (secs) *time as derived from log files |
|---|
| 50 | 2.446 |
| 100 | 24.821 |
| 250 | 62.201 |
| 500 | 138.56 |
| 1000 | 322.725 |
2. Publish RFX Award to SAP ERP
| Number of Line Items | Publish RFX Award to ERP: (secs) *time as derived from log files |
|---|
| 50 | 7.944 |
| 100 | 14.651 |
| 250 | 37.951 |
| 500 | 83.428 |
| 1000 | 218.768 |
As is observed from the times above, the publish times will increase with the number of line items (considering this alone and no other variations). As can be noticed,the end user will experience lengthy wait times as we reach the 1000 line item mark. This not only impacts the user trying to publish the document to SAP ERP but all other users logged into the system.
Best Business Practice suggestion:
Because the Sourcing to ERP integration scenario uses synchronous HTTP calls to transfer data, and all HTTP requests are expected to respond within reasonable network limits (i.e. ~ 5 minutes) to ensure a real-time, responsive user experience for all users on that network – it is not recommended to attempt publishing more than ~1000 line items at any one time. We expect that significantly raising or removing such limits as a long-term solution will have a negative impact on the behavior of the network as a whole - including the applications and users within it.
Alternative ideas to publish large number of line items:
There have been various approaches suggested depending on the business needs but a common approach proposed and used by many customers at this time is to split the business document into multiple documents with fewer line items. This way the end user experience while navigating the document in sourcing or even while publishing will be within acceptable norms.
One approach might be to publish a “parent” agreement with no line items that serves as the “umbrella” agreement with “child” agreements for all of the line items ensuring that each child agreement included no more than ~1000 line items. This would enable you to manage the “child” agreements together under the “parent” but ensure that no “child” has more than ~1000 line items. There may be some logical groupings that would allow you to group the line items onto a “child” agreement by, for example:
- Product
- Category
- Organizational Unit
- Geography
- Plant
In the case that the need arises to publish documents larger than the suggested line items (~1000), some of the symptoms the system will exhibit are:
- Frequent and inconsistent timeouts experienced by the user publishing the document to ERP.
- In some situations inconsistent transaction states due to the timeout (meaning the document may have been created in ERP but due to the timeout occurring in SAP Sourcing, the document references will not be updated in SAP Sourcing)
Both of the above issues can be addressed by changing the timeout parameters (on some but most likely) on all systems (SAP Netweaver, SAP Sourcing, SAP PI, SAP ERP).
Timeout parameters of interest:
SAP Netweaver: (Refer to NW documentation)
- icm/conn_timeout
- icm/keep_alive_timeout
- icm/server_port<_n>/PROCTIMEOUT
SAP Sourcing: (Refer to the SAP sourcing configuration guide for additional details)
- upp.metering.login_inactivity_timeout
- upp.metering.cleanup_interval
- transactionTimeout.millis
SAP PI System: ( Refer to the PI documentation for the details)
- HTTP_TIMEOUT
- xiadapter.inbound.timeout.default
SAP ERP:
Note: Increasing the timeouts will lead to successful publish of documents to ERP but will not guarantee good end user experience for all the users logged into SAPSourcing (i.e.,the users may experience slow response times as much of the system resources would be locked up processing the Publish event).
