1. No category

How-to Guide
SAP NetWeaver 7.0
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
2
3
4
5
6
7
Contents .................................................................................................................... 1
Business Scenario..................................................................................................... 2
Introduction................................................................................................................ 2
3.1
Design ............................................................................................................... 2
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
SAP ECC posts the documents .............................................................................. 34
5.1.1
Configure ECC Parameters for IDoc Postings ........................................ 35
Checking Results .................................................................................................... 39
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
Replication
mode
Objectives
- Enable loose system
coupling
Decision
Asynchronous
Solution
- If SAP application systems are
involved, use ALE, TRFC or
-2-
Message size
Posting
method
Parallelization
- Avoid busy-waiting
- Make sure that the
server is the
responsible of the
business level error
administration
- Optimize
performance
- Improve
performance
- Avoid memory
overflow
- Increase stability
- Reduce impact on
garbage collection
(J2EE)
- Minimize application
system resource
usage
- Minimize impact on
interactive users.
- Maximize monitoring
and administration
capabilities.
- Provide capabilities
to work in parallel with
high volumes
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
Use IDOC
packaging on
sender and
receiver side
Use XSD IDoc
mapping
manipulation
as explained
in SAP Note
709400
ALE
BPM
- Bear in mind this consideration at
design time
- 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
- Apply this recommendation
- Plan to work with IDocs views
(WE32)
- Implement an ALE scenario
- Avoid immediate posting
- Use three-tier system architecture to
improve resource balancing.
- 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-
DBMS
1
SAP NetWeaver
Process
Integration
SAP ECC
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
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).
DBMS
SAP NetWeaver
Process
Integration
Select count * as count
from SalesOrderHeader
where ReplicationStatus = ‘N’
count > ‘0’ ?
Read pending
replications on
regular basis
Determine
receiver based
on pending
documents
yes
Integration Process
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/co
unt ≠ 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
SAP NetWeaver
Process Integration
DBMS
Select headers
+
Select items
+
Update headers
SAP ECC
Read and
update a set of
documents
Mapping documents set
Call the receiver
interface
Call mapping to
transform the
group of
documents
Call receiver IDoc
channel
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_gro
up
•
select_salesorderitem_by_group
•
update_salesorderheader_by_gr
oup
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.
IDOC
package
IDoc
Package
Send
Business Process Engine
Send
IDoc Package
IDoc
Package
Replication
Rules
Container
SAP ECC
tRFC
Map
Receive
Replication Rules
Response
Map
Integration Engine
Select &
Update
Interface Mapping
Adapter Engine
DBMS
JDBC
Replication
Rules
- 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_t
o_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.
SAP
ECC
SAP NetWeaver Process Integration
Integration Server
ABAP Stack
Inbound
Queues
Outbound
Queues
ABAP
Stack
tRFC
Transactions
(BPE + IDoc)
PLSRV_...
PLSRV_...
PLSRV_...
PLSRV_...
EC5_800
EC5_800
inactive
inactive
inactive
inactive
Workflow_local_100
Workflow_local_100
DIA0 DIA1 DIA2 DIA3
tRFC
…
DIA4
Work Processes
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_OUTB
OUND = 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_PARALL
EL.
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.
SAP ECC
Save the IDocs
Execute Posting Daemon
Save IDocs to
database without
posting
Posting Daemon:
- Select Pending IDocs
- Group Transactions
- Analyze servers load
- Call Inbound process
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 -
7 References
How To Configure the IDoc Adapter:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/d19fe210-0d010010-4094-a6fba344e098
How To Sample IDoc-XI Scenarios:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c09b775e-e56e-29101187-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-ba88fd38caee02f7
SAP NetWeaver Process Integration Tuning Guide:
https://service.sap.com/~sapidb/011000358700000592892005E/XI30-Tuning-10.pdf
- 42 -
www.sdn.sap.com/irj/sdn/howtoguides