How-to Guide SAP NetWeaver 7.0

How To…How To… Implement a High Volume Process Integration Scenario Version 1.00 – August 2007 Applicable Releases: SAP NetWeaver 7.0 SP10 End-to-End Process Integration Enabling Application-to-Application Processes SAP ECC 5.0

© Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data

contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

1 Contents 1 Contents .................................................................................................................... 1 2 Business Scenario..................................................................................................... 2 3 Introduction................................................................................................................ 2

3.1 Design ............................................................................................................... 2 4 The Step By Step Solution ........................................................................................ 6

4.1 Database Polling ............................................................................................... 6 4.1.1 Design the Database Interfaces Objects ................................................... 7 4.1.2 Design the Replication Rules Objects ....................................................... 8 4.1.3 Design the Database Mapping Objects ..................................................... 9 4.1.4 Configure the Database Polling Scenario................................................ 10

4.2 Integration Process Replicates the Documents............................................... 12 4.2.1 Design the IDoc interfaces ...................................................................... 12 4.2.2 Design the Replication Rules Interface ................................................... 13 4.2.3 Design of Receiver JDBC Interface to Retrieve and Update the Documents .............................................................................................................. 14 4.2.4 Design of Mapping Program for the Receiver JDBC Interface ................ 16 4.2.5 Design of Mapping Program for the Receiver IDoc Interface .................. 18 4.2.6 Design Interface Mapping........................................................................ 18 4.2.7 Design the Integration Process ............................................................... 19 4.2.8 Configure the Integration Process and SAP ECC System ...................... 21 4.2.9 Configure the Integration Process Execution .......................................... 21 4.2.10 Configure the JDBC Receiver Interface .................................................. 23 4.2.11 Configure the IDoc Receiver Interface .................................................... 24 4.2.12 Configure the Basic tRFC/qRFC and Integration Engine Resources ...... 26 4.2.13 Configure IDoc Packaging....................................................................... 31

5 SAP ECC posts the documents .............................................................................. 34 5.1.1 Configure ECC Parameters for IDoc Postings ........................................ 35

6 Checking Results .................................................................................................... 39 7 References.............................................................................................................. 42

- 1 -

2 Business Scenario Your customer creates sales orders in a legacy system. These orders are to be sent to SAP ECC for sales execution. The systems have to be synchronized constantly, the volume of information during certain periods of time is very high and delays can have an impact on business.

3 Introduction The most relevant steps required to implement the example scenario are described in this guide. Note that steps have to be performed in the involved Process Integration components (these are the SAP system of the Integration Server, the Integration Repository and the Integration Directory) as well as in the SAP ECC application system. Although the connectivity with JDBC and IDocs is applied in the example scenario that is described, the basic ideas can be reused for use cases including other technologies. This guide considers only the most basic steps required to explain the concepts. Note that in a real life scenario many additional considerations are required. Note that the configuration steps described in this guide constitute only a sample configuration. In order to obtain the most appropriate tuning, you should take into account all processes that run on each server, analyzing the design of the integration and the real productive systems resources. It is assumed that the reader is familiar with the technologies and applications involved. Since configuring the example scenario implies some configuration steps on a very detailed level, SAP recommends that you read the referenced documentation to obtain a better understanding of each step.

3.1 Design In order to obtain the best performance and to minimize resource consumption, the different items and techniques that will help us reach these objectives will be analyzed first. The following table lists and evaluates the possible options. Item Objectives Decision Solution Replication mode

- Enable loose system coupling

Asynchronous - If SAP application systems are involved, use ALE, TRFC or

- 2 -

- Avoid busy-waiting - Make sure that the server is the responsible of the business level error administration - Optimize performance

asynchronous proxies instead of direct sRFC, BAPI or synchronous proxies. - If available in the Process Integration installation of the partner, exploit existing replication layers.

Configurable message size

- Bear in mind this consideration at design time

Use IDOC packaging on sender and receiver side

- Work with IDoc packages - Also: Do not post immediately at receiver site. Always prefer to post in groups to minimize ABAP processing and reduce the number of database commit operations

Message size - Improve performance - Avoid memory overflow - Increase stability - Reduce impact on garbage collection (J2EE)

Use XSD IDoc mapping manipulation as explained in SAP Note 709400

- Apply this recommendation - Plan to work with IDocs views (WE32)

Posting method

- Minimize application system resource usage - Minimize impact on interactive users. - Maximize monitoring and administration capabilities.

ALE - Implement an ALE scenario - Avoid immediate posting - Use three-tier system architecture to improve resource balancing.

Parallelization - Provide capabilities to work in parallel with high volumes

BPM - ccBPM overhead is very low working with big block of documents - Better parallelization

Resulting from the analysis above, the general integration approach was designed as depicted in the graphics:

- 3 -

1 New Documents Inserted

2 New Documents Detected

3 Create Collection Process

4 Read and Update Block

5 Convert Documents to IDocs

6 Transfers IDocs Block

7 New IDocs Detected

8 Start Posting Process

DBMSSAP NetWeaver

Process Integration

SAP ECC

In a first step it is checked if new documents appear in the database. A sender interface is implemented to enable inbound processing of the data.. When a new document is found, a basic integration process is triggered. The integration process contains just one adapter call to retrieve a number of documents from the different tables, update the replication indicator and send the documents to SAP ECC. Mapping converts the message full of documents into a message full of IDocs (1:1 mapping, but several business documents involved).

Then the resulting message is routed to the destination. Once in the destination, the different IDocs are rearranged into new groups and posted as functional documents.

The sales orders in this example are arranged in two tables, one for the headers and one for the details. Even though the original source system design lacks some of the useful features of the replication interface design (since the source database has no replication administration and application link layers), the business application layer (the sales order table) is

- 4 -

updated in order to know what documents are waiting for replication. The ReplicationStatus field at header level indicates if the document has already been transmitted or not (N: Pending, F: Replicated). In order to understand the different layers and features involved in the replication, read the Process Integration Architecture documents on SDN: https://www.sdn.sap.com (search for Process Integration Architecture).

- 5 -

4 The Step By Step Solution The solution will be implemented in three different groups:

1. SAP NetWeaver Process Integration: polls the database for new documents and triggers the replication process if required.

2. SAP NetWeaver Process Integration: replicates the documents (by an integration process).

3. SAP ECC: posts the documents.

4.1 Database Polling First, a sender interface is implemented that regularly checks if new documents are created in the source system. If some documents are found, the integration process is called. The database will be represented by the business service Sys_PWebSaler and SAP ECC by the business service Sys_T90CLNT090 (System ID: EC5, Client: 800, ALE Logical system name: T90CLNT090).

DBMSSAP NetWeaver

Process Integration

count > ‘0’ ?

Select count * as countfrom SalesOrderHeaderwhere ReplicationStatus = ‘N’

Integration Process

yes

Read pending replications on regular basis

Determine receiver based on pending documents

Start replication

- 6 -

4.1.1 Design the Database Interfaces Objects Perform the following steps in the Integration Repository.

1. To receive the number of pending records, start by creating a generic data type to receive the sender interface.

2. Create a message type using the data type previously created. This message type will be later used in the channel configuration.

3. Create the database outbound asynchronous interface.

- 7 -

4.1.2 Design the Replication Rules Objects Perform the following steps in the Integration Repository.

4. To start the next replication process based on configuration and information retrieved from the sender interface results, create a data type to start the integration process. Note that in this particular example, the replication rules will not be based on the information retrieved from the database (sender interface).

5. Create a message type based on the previous data type.

6. Create an asynchronous abstract interface to store the information in the integration process container.

- 8 -

4.1.3 Design the Database Mapping Objects Perform the following steps in the Integration Repository.

7. To get information to start the integration process with runtime and configuration time information, create a mapping from the sender interface to the replication rules. The number of documents to retrieve each time the receiver interface is executed is the value to transfer to the replication rules. In this example, for simplicity, this information is hard coded (500 documents), but it is a better idea to retrieve it at runtime using lookup APIs, value mappings, or an additional interface. Using this technique it will be possible to reconfigure the value at runtime in order to find the best message size for your productive environment and the requirements of all the involved components (source database, Process Integration runtime component and SAP ECC). Especially in the Process Integration runtime component, the message size is very important regarding performance and the impact in the JVM garbage collection behavior.

8. Create the interface mapping for the previous message mapping.

- 9 -

4.1.4 Configure the Database Polling Scenario Perform the following steps in the Integration Directory.

9. To organize the different objects, create a new configuration scenario.

10. Assign the required services.

• Sys_PWebSaler for the source database.

• Bpr_Replicate_WebSalesOrder_to_ECC_High_Volume for the integration process (created later, but introduced here for teaching purposes).

11. To periodically poll the database for pending documents, create a sender JDBC channel with the following relevant information:

• Query SQL Statement: select count * as count from SalesOrderHeader where ReplicationStatus = 'N' (How many pending documents are in the database?).

• Document name: Select_Count_SalesOrders (message type previously created).

• Update SQL Statement: <TEST> (no update).

12. Create the sender agreement using the communication channel.

- 10 -

13. Create the receiver determination configuring the integration process as receiver and add the following condition: Select_Count_SalesOrders/rows/count ≠ 0. Under If No Receiver Is Found, Procees As Follows, select End Message Processing Without Error With this condition, the integration process is triggered only if required, if not, the message processing is stopped in the Integration Engine.

14. Create an interface determination to start the integration process using abstract asynchronous interface and the interface mapping previously created.

- 11 -

4.2 Integration Process Replicates the Documents

DBMSSAP NetWeaver

Process Integration

Select headers+Select items+Update headers

Call receiver IDoc channel

Read and update a set of documents

Call mapping to transform the group of documents

Call the receiver interface

Mapping documents set

SAP ECC

4.2.1 Design the IDoc interfaces Perform the following steps in the Integration Repository.

15. To design the receiver IDoc interface, import the IDoc definition from the target system.

- 12 -

16. Execute Tools Export Reduced XSD and save the file.

17. Change the minimum and maximum number of allowed IDoc element and import the XSD as an external definition.

18. Create an abstract asynchronous interface to store the IDoc inside the integration process container.

4.2.2 Design the Replication Rules Interface Perform the following steps in the Integration Directory.

- 13 -

19. To initiate the integration process, create the outbound asynchronous interface using the replication rules message.

4.2.3 Design of Receiver JDBC Interface to Retrieve and Update the Documents

Perform the following steps in the Integration Repository.

20. To implement the receiver JDBC that will retrieve and update the documents, create a canonic JDBC receiver with three instructions:

• select_salesorderheader_by_group

• select_salesorderitem_by_group

• update_salesorderheader_by_group

For more information, see the following document in the SAP library: Document Formats for the Receiver JDBC Adapter

- 14 -

21. Create a message type from the data type.

22. To receive the response from the database query, create a data type following the format requirements:

• Same root node name than with query, with the _response suffix (case sensitive)

• Repeat the second level (query names)

• Add the row element as third level for each query

• Add the requested fields as sub elements under each row element

- 15 -

23. Create a message type for the data type previously created.

24. Create the synchronous interface to call the database.

4.2.4 Design of Mapping Program for the Receiver JDBC Interface Perform the following steps in the Integration Repository.

25. To call the database using the replication rules, create a mapping, copying the number of documents to be retrieved from the target message. To select the header records map as follows: action: SQL_QUERY access: select top $numberofdocuments$ * from salesorderheader where replication status = ‘N' order by number To select the item records map as follows: action:

- 16 -

SQL_QUERY access: select salesorderitem.* from salesorderheader inner join salesorderitem on salesorderheader.number = salesorderitem.ordernumber where salesorderheader.number in ( select top $numberofdocuments$ salesorderheader.number from salesorderheader where replicationstatus = ‘N' order by salesorderheader.number ) To update the header records map as follows: action: SQL_DML access: update salesorderheader set replicationstatus = 'f' where number in ( select top $numberofdocuments$ number from salesorderheader where replicationstatus = ‘N' order by number ) This example is based on a Microsoft SQL Server query syntax to specify the maximum number of records to retrieve in each call. When you implement these queries using another DBMS, the syntax must be revised. For example, in an IBM DB2 environment, the header table query would be: select * from salesorderheader fetch first $numberofdocuments$ rows only where replication status = ‘N' order by number.

- 17 -

4.2.5 Design of Mapping Program for the Receiver IDoc Interface Perform the following steps in the Integration Repository.

26. Map the sales order IDocs from the response message, splitting the IDoc each time a new sales order number is read from the source message. To improve mapping performance, instead of using the imported IDoc as target message type, choose Import Reduced XSD and reference the previously modified XSD version of the IDoc definition.

4.2.6 Design Interface Mapping Perform the following steps in the Integration Repository.

27. Create the interface mapping for the request (rules) and response (IDoc) messages previously created.

- 18 -

28. To receive the call from the integration process, create an abstract synchronous interface for the request and response.

4.2.7 Design the Integration Process The following graphics shows the interplay of the designed interfaces and the integration process.

Business Process Engine

Container

Integration Engine

Adapter Engine

ReplicationRules R

eplication Rules

Receive

Send

ReplicationRules

Select & Update

ResponseIDOC

package

Send

IDoc Package

IDocPackage

SAP EC

C

IDocPackage

Interface Mapping

Map

Map

DB

MS JDBC

tRFC

- 19 -

Perform the following steps in the Integration Repository.

29. To be able to call both the receiver JDBC and IDoc interfaces, create an integration process.

30. The starting point will receive the replication rules.

31. Then to call receiver JDBC adapter, invoke the associated abstract synchronous interface.

32. Finally, to send the IDocs to ECC, configure the call to the asynchronous inbound interface.

- 20 -

4.2.8 Configure the Integration Process and SAP ECC System Perform the following steps in the Integration Directory.

33. Add the required services.

• Sys_T90CLNT090_IDoc_Client for the target SAP ECC System.

• Bpr_Replicate_WebSalesOrder_to_ECC_High_Volume for the integration process (already done).

34. To assign a logical system name to the integration process, edit the adapter specific identifiers.

4.2.9 Configure the Integration Process Execution Perform the following steps in the SAP system of the Integration Server.

35. To find the task name for your integration process, check the integration processes in transaction SXI_CACHE.

36. To configure integration processes queues to run in parallel (that is, the same integration process is allowed to run in parallel) run transaction SWF_INB_CONF. In our example, we are able to run

- 21 -

integration processes in parallel, the receiver JDBC adapter will serialize the request to avoid duplicates (applies to installations with one adapter and no additional server nodes). This configuration introduces additional synchronization issues (the quality of service changes from EOIO to EO), but on the other hand, performance is boosted.

37. To allow multiple queues select:

• Delivery Mode: Without Buffering

• Queue Handling: Multiple Queues per Process Type (Always Start)

• Number of Queues: considering our resources, we will be using 4 queues

38. Save and select the option Process Receives EO Messages Only.

39. To configure the parallel inbound queues for BPE in the scheduler, access transaction SMQR and execute Registration to adjust the entry for queue name XBPE*.

- 22 -

4.2.10 Configure the JDBC Receiver Interface Perform the following steps in the Integration Directory.

40. To determine the database service, create a receiver determination to be called from the integration process.

41. Create the interface determination using the interface mapping to convert from replication rules to IDoc format.

42. To access the database, create a receiver JDBC channel.

- 23 -

43. Create the receiver agreement using the receiver JDBC channel.

4.2.11 Configure the IDoc Receiver Interface Perform the following steps in the SAP system of the Integration Server.

44. Create an RFC destination from the Integration Server to SAP ECC (type 3). You can either use load balancing or send the IDocs directly to a specific application server. Using load balancing allows you to change the server in case of server problems. If you plan to send the replication directly to the central instance, load balancing makes no sense. Bear in mind that, since IDocs are not configured to be posted immediately, there is no application level processing, just the technical tables are updated.

45. Specify the gateway you want to use in the SAP ECC installation. If you are using load balancing, it is preferable to use the central instance gateway since it is the one with greater availability.

46. Check and adjust your asynchronous RFC settings as required.

47. Suppress the automatic retry for transactional RFC and create a job using the program RSARFCEX to retry failed tRFC calls on a regular basis.

- 24 -

48. Update the port for the IDoc adapter and specify the RFC destination (previously created) in transaction IDX1.

49. Create a receiver IDoc communication channel to connect your SAP ECC system. Specify the port and RFC destination previously created.

50. To route the IDoc to SAP ECC, create a receiver determination and a receiver agreement using the communication channel previously created. If no records were found in the database, and no IDoc generated, just stop processing.

- 25 -

4.2.12 Configure the Basic tRFC/qRFC and Integration Engine Resources Every queue or tRFC entry requires a dialog work process to run ABAP programs. We are going to briefly analyze how resources are used so as to provide a basic configuration example and show how to control distributed system resources for the different consumers.

Work Processes

Integration Server

SAP NetWeaver Process Integration SAP ECC

ABAP Stack

InboundQueues

OutboundQueues

tRFCTransactions(BPE + IDoc)

ABAPStacktRFC

…PLSRV_...PLSRV_... PLSRV_...PLSRV_... EC5_800EC5_800

inactiveinactive inactiveinactive Workflow_local_100Workflow_local_100

DIA0 DIA1 DIA2 DIA3 DIA4

51. To be aware of the dialog resources, check the operation modes you are using and instances available in transaction RZ04. Also, check time dependent configurations as the operation modes can be changed dynamically.

52. Configure the RFC server group you are going to use to process the queues and transfer the IDocs. (RZ12). If you have several application servers, you can define more than one combination. Several application servers will also allow you to manage these resources better as you will, for example, be able to execute normal pipeline steps on one server and business process steps on another application server, configuring different quotas for each

- 26 -

one.

53. Adjust the tRFC quotas in the XI dispatcher. There are the following important parameters: • Activated = 1 • Minimum Number of Free

WPs ≥ 1 • Max. No. of Logons = 90% • Maximum No. Separarte

Logons =90% • Max. Number of WPs Used =

90%

For more information, see SAP Note 74141. These parameters are general and should be revised for every particular installation. You can either maintain these values dynamically using transaction RZ12 (but these lost after server restart) or maintain the corresponding entries in the profile parameters.

54. Adjust your QOUT scheduler for destination EC5_800 Configure the AS Group, choosing one of the RFC server groups previously defined, or leave it as DEFAULT to allow to run on every application server available. Specify also the maximum number of connections (Max. Conn.) The number of maximum connections is associated with the number of available dialog work processes in the server group and also in the target system. Remember to subtract the Minimum Number of Free WPs configured in the RFC server group.

- 27 -

Consider this example: If your source system has nine dialog work processes, your target system has five and one is configured to be free in both systems, the maximum number of connections should be set to four (if they are not going to be shared with another connections).

If the resources in your target system are infinite then we could not configure more than eight, since we have just nine, and one is reserved. In our real Process Integration installation we have five dialog work processes. We will allow just two to be used to send information to SAP ECC (EC5 has six available). Note that it is always possible to configure more than one destination to the same system with different number of resources to help you set business priorities when transmitting information using tRFC.

55. Suppress the automatic retry for transactional RFC and create a job using the program RSARFCEX to retry failed tRFC calls on a regular basis.

- 28 -

56. Configure the QOUT scheduler for destination WORKFLOW_LOCAL_100 used for integration process execution (automatically configured by the workflow infrastructure, but you can change it if you want). The number of maximum connections should be calculated as in the previous step, but now there is no connection to a remote system. We will configure a maximum of three integration processes to run in parallel. If you can redirect a business process execution to another application server, then the administration would be simplified. It is also possible to redirect specific integration processes to another destination using the task name and by changing the configuration in transaction SWE2). For more details on this step, see SAP Note 888279.

57. Configure the number of inbound queues in parallel execution considering the number of dialog work processes and quotas restriction (as previously checked in the outbound scheduler) in transaction SXMB_ADM. If you have five dialog work processes and plan to use a maximum of two for inbound processing, configure the parameter TUNING/EO_INBOUND_PARALLEL = 2. Follow the following recommendations:

• You can obtain detailed documentation by clicking the documentation icon on the grid.

• You can also use transaction SARFC to check these resources at runtime.

- 29 -

58. In general, to allow the receiver interface call to run in parallel and in separate queues, configure the parameter TUNING/EO_INBOUND_TO_OUTBOUND = 1.

59. To determine the number of concurrent outbound queues for SAP ECC, create a receiver ID for the service Sys_T90CLNT090 using transaction SXMSIF. Specify the service name and “*” for the interface name and namespace.

60. Then create the configuration parameter TUNING/EO_OUTBOUND_PARALLEL. Specify as sub parameter, the receiver ID previously created (T90CLNT090) and allow two queues to run in parallel. The number of queues running in parallel will require a corresponding number of resources for mapping processing.

61. Finally the tRFC/qRFC dialog resources distribution for execution in our example is as follows:

Total dialog work processes:

5

Maximum usable for tRFC/qRFC:

4

Maximum connections in parallel to ECC:

2

Max. integration processes running in parallel (tRFC):

2

Maximum inbound queues running in parallel:

2

Maximum outbound queues running in parallel for ECC:

2

- 30 -

4.2.13 Configure IDoc Packaging Perform the following steps in the SAP system of the Integration Server.

62. To activate the functionality for our message, we get a template message. Run the scenario first, after that, run transaction SXI_MONITOR (or IDX5) and copy a message ID of a sample IDoc message.

63. Even though you can do this automatically using the wizard (transaction IDXPW, shown in the screenshot), in the following steps we are going to configure the steps manually.

64. To configure manually, start transaction SXMSIFILTER and select Sender/Receiver ID.

65. Create a specific sender ID for your

request and service. To make sure you are using the appropriate info, check the information contained in your template message.

- 31 -

66. Repeat the steps for the receiver.

67. Go back to the initial screen. To specify the background job, select Jobs.

68. Add a new job with the desired frequency, accept the screen, save the information, and activate the job.

69. To specify the filtering condition, select Message Filter.

- 32 -

70. Create a new filter for outbound IDoc packaging and specify, for example, the maximum desired package size. Then save the information and activate the filter.

71. Make sure the scheduler is running, if not, select Schedule Scheduler to plan the jobs.

- 33 -

5 SAP ECC Posts the Documents The overall process steps are illustrated in the following graphics.

Save the IDocsSave IDocs to database without posting

Posting Daemon:- Select Pending IDocs- Group Transactions- Analyze servers load- Call Inbound process

Execute Posting Daemon

SAP ECC

72. Maintain the distribution model view (transaction BD64) to accept sales orders from the logical system represented by the integration process.

- 34 -

73. Maintain the partner profiles and add an inbound message for the sales orders.

74. Configure the sales orders IDocs to be processed by a background program. Immediate triggering would have the following disadvantages in this scenario:

• It consumes more resources.

• It is harder to balance priorities with online users.

• It is much slower.

If the inbound ALE process code for a determined message allows packages, performance will be improved.

5.1.1 Configure ECC Parameters for IDoc Postings

75. Check the operation modes configured in your installation and bear in mind the number of dialog work processes for the following configuration steps.

- 35 -

76. According to your previous Process Integration configuration steps, configure your RFC server groups for the IDoc postings.

77. Configure the tRFC quotas for every application server.

78. Access the internal RFC destination

NONE. This destination is used internally and should also be configured.

- 36 -

79. Configure the asynchronous RFC parameters for the destination NONE.

80. Also configure the transactional RFC parameters, suppress the retries and run report RSARFCEX on a regular basis to retry failed transactions.

81. Configure the QOUT scheduler in transaction SMQS for destination NONE as previously configured in SAP NetWeaver Process Integration, considering the local resources.

- 37 -

82. Create a periodic batch job to post the IDocs in the background. The package size is a very important parameter and should be maximized taking the following into consideration::

• Memory consumption

• Database rollback area configured

• Parallelism

The bigger the package size, the lower the number of database commits and roll-in/roll-out operations – which will improve posting performance enormously. Consider that there is a number of other programs to run as periodic batch jobs to retry failed postings, retry failed tRFCs, archive old IDocs, send acknowledgements, etc. There are also another IDoc posting programs for specific industry solutions.

83. Configure the parallel processing and select one of the RFC server groups previously defined. If you want to measure runtime, you can set the Wait for End of Processing flag and the job will end once the last IDoc is posted.

- 38 -

6 Checking Results With the following steps, we are going to measure time consumption on a sample set of 3000 sales orders awaiting replication. The polling JDBC channel is supposed to be stopped.

84. To start the channel, access the communication channel monitoring tool. Select and start the sender JDBC channel.

85. Checking Integration Engine processing times. In the SAP system of the Integration Server, start transaction SXI_MONITOR and select all the messages involved. Check the time difference between the start of the first and the finish of the last messages: 26 seconds.

- 39 -

86. Check IDoc replication times. In SAP ECC, access transaction WE05 and select all the documents involved. Check the time difference: 92 seconds (32 IDocs per second).

87. Check IDoc posting times. In SAP ECC, run report RBDAPP01 in background using parallel resources and waiting for end of processing Check runtime in jobs overview (SM37): 950 seconds (3 sales orders per second).

- 40 -

88. To check that the sales orders have been successfully posted, run transaction BD87.

- 41 -

- 42 -

7 References How To Configure the IDoc Adapter: https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/d19fe210-0d01-0010-4094-a6fba344e098 How To Sample IDoc-XI Scenarios: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c09b775e-e56e-2910-1187-d8eba09c7a4a RFC in general: http://help.sap.com/saphelp_nw04s/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/frameset.htm IDoc mapping performance: https://service.sap.com/sap/support/notes/709400 SAP NetWeaver Process Integration Performance check: https://service.sap.com/sap/support/notes/894509 SAP NetWeaver Process Integration Performance (Message sizes): https://www.sdn.sap.com/irj/sdn/webinar?rid=/library/uuid/defd5544-0c01-0010-ba88-fd38caee02f7 SAP NetWeaver Process Integration Tuning Guide: https://service.sap.com/~sapidb/011000358700000592892005E/XI30-Tuning-10.pdf

www.sdn.sap.com/irj/sdn/howtoguides