404handler PDF
404handler PDF
Bonn Boston
321_Book.indb 3
10/5/09 2:22:30 PM
Contents
Introduction ...............................................................................................
13
14
18
20
23
24
24
24
30
32
34
37
46
51
52
52
53
53
54
56
59
59
321_Book.indb 5
10/5/09 2:22:30 PM
Contents
131
131
134
137
137
138
139
144
321_Book.indb 6
10/5/09 2:22:30 PM
Contents
147
147
149
153
153
155
156
161
164
165
171
172
178
182
186
188
195
197
203
203
215
219
321_Book.indb 7
10/5/09 2:22:30 PM
Within SAP NetWeaver PI, there are many ways to improve the performance of
individual interfaces, or even of the whole system. Of course, the available measures depend on the specific hardware used and the corresponding operating system of your application server, as well as on the installed patch levels. In this
chapter, well share tips and tricks that are platform-independent and are therefore
applicable in most architectures. The topic structure is based on the existing SAP
documents (especially the SAP NetWeaver Process Integration Tuning Guide from the
SAP Developer Network, sdn.sap.com), which we enhanced with examples from
our own experience. Here we address only those topics that are most relevant to
the subject matter.
5.1
Because SAP NetWeaver PI uses remote function call (RFC) connectivity extensively, well focus on the optimization of RFC settings on both the SAP ERP side
and the J2EE side. Thereafter, well discuss the individual parameter settings for
the RFC and the gateway parameterization on the SAP ERP side.
Because configuring the RFC quota and the JCo service provider requires specific
configuration steps, well deal with these individually in the following two sections before we specifically describe each parameter setting in detail.
5.1.1
Depending on the number of existing CPUs and the main memory, the ABAP side
of the SAP NetWeaver PI server can be optimized as usual by different parameterizations. Examples include the number of work processes that are available in
the SAP ERP basis stack for processing the queues. You should note that the J2EE
stack logs on to the SAP ERP basis stack per RFC dialog user. This means you dont
131
321_Book.indb 131
10/5/09 2:23:38 PM
PerformanceOptimizationMeasures
need to increase the number of batch processes, as you might expect just the
dialog processes. You can control the number of dialog processes using the rdisp/
wp_no_dia profile parameter.
One important configuration factor is the RFC quota. This defines the maximum
number of dialog processes that can be occupied by RFC users on a system. The
purpose of this quota is to prevent all dialog processes from being occupied by RFC
users from other systems so that the actual dialog users can no longer log on to the
system. You can retrieve the RFC quota using Transaction RZ12 (see Figure 5.1).
Figure 5.1 SettingsComputer Center Management System (CCMS) RFC Server Group
Maintenance
We recommend that you use a maximum value for the Max. Number of Work
Processes Used field depending on the available work processes. You need to consider the associated system parameter rdisp/rfc_max_own_used_wp. The default
value is 75%. This parameter value indicates the maximum percentage of dialog
work processes that an RFC user can occupy. Because SAP NetWeaver PI logs on
to the SAP ERP system with a service user, this value needs to be set accordingly.
For most of our projects, we increased this value to 90%. Transaction RZ10 sets
this parameter in the instance profile. If the parameter is not set, a default value
of 75% is used automatically. After setting the parameter, you must restart the
application server.
132
321_Book.indb 132
10/5/09 2:23:39 PM
CustomizingtheSAPNetWeaverApplicationServerforSAPNetWeaverPI7.1
5.1
Additionally, if you really want to operate the SAP NetWeaver PI server as an integration platform only, we recommend that you set the Minimum Number of Free
WPs field to a value between 1 and 2 to optimally use the set dialog processes for
batch operation.
You should also consider that every work process that is additionally set and cannot be used effectively reserves a certain amount of main memory on the server.
The settings within the instances are just as important as planning the number of
actual instances, depending on the CPUs and the main memory.
You can set the number of available work processes via Transaction RZ04, as shown
in Figure 5.2. Note that the maximum is defined in the profile parameters. If it is
necessary to change this maximum, a restart is required.
Figure 5.2
133
321_Book.indb 133
10/5/09 2:23:39 PM
Now that youve looked at the number of instances and the number of processes
per instance, dont forget to check the number of existing queues per basis instance
as well. The number of queues that accept incoming data in parallel and then send
it simultaneously (qRFC queues) is hard to configure and depends largely on the
average parallel requests and on the size of the messages to be processed, which
must be dealt with by the SAP NetWeaver PI system. Later well discuss in detail
the necessary parameterizations and some recommended values based on our project experience.
5.1.2
Now that weve looked at the settings within the ABAP instances and at the number of ABAP instances, we should also consider the J2EE instances.
The first item to clarify is the number of J2EE instances to be installed. A good initial value is two instances, but the actual number of J2EE instances depends largely
on the number of activities to be carried out simultaneously (e.g., mappings) and
the used adapters on your J2EE stack. In our implementations, we did quite well
with two initial instances, even for high-performing interfaces. However, for more
intense activities and parallel operations on the J2EE stack, a scaling according to
the J2EE instances is recommended. Because this is a very singular characteristic
that depends on the used interfaces and systems, there is no general formula that
we can recommend you apply.
As we did for the for the ABAP stack, here also, we must consider the number of
processes running within a single instance on the J2EE side as well. You should
note the number of processes required for the individual RFC destinations of the
JCo RFC Provider service. In our experience, values are between 15 and 20 processes for this service per instance.
Conversely, if youre using multiple J2EE server nodes and find that there is no
effective load distribution, the reason might be that the number of RfcEngine
threads per server is set too high. In this case, reduce the number of threads for
the RFC destination AI_RUNTIME_* depending on the number of parallel mapping
requests. This problem exists because the SAP gateway does not know the J2EE
configuration. To achieve an effective load distribution, you should observe this
information and configure your system accordingly.
134
321_Book.indb 134
10/5/09 2:23:39 PM
CustomizingtheSAPNetWeaverApplicationServerforSAPNetWeaverPI7.1
5.1
In contrast to previous versions, the settings on the J2EE side are no longer managed via the Visual Administrator, but in SAP NetWeaver Administrator. You can
call the SAP NetWeaver Administrator by entering the basic URL of your SAP
NetWeaver PI system in your browser: http://<SERVERNAME>:5<SYSTEMNUMB
ER>00. Then select SAP NetWeaver Administrator in the upper-right area of the
screen.
Figure 5.3
Once you have opened this tool, the system displays the user interface of SAP
NetWeaver Administrator (see Figure 5.4), where you can view and edit the individual parameters according to your requirements.
Figure 5.4
Based on our example system P71, the following sections describe how you can
increase the number of available processes. Call the Configuration Management
item in the upper menu bar, and then select Infrastructure from the menu items
that display (Figure 5.5). Then select Jco RFC Provider.
135
321_Book.indb 135
10/5/09 2:23:40 PM
PerformanceOptimizationMeasures
Figure 5.5
Figure 5.6
On the left-hand side, there is a list of individual available RFC connections in use.
By selecting these RFC connections, you can change the corresponding parameters
136
321_Book.indb 136
10/5/09 2:23:42 PM
5.2
in the lower area of the screen. You can tell from the example in Figure 5.6 that
within this instance 10 processes for this RFC connection are available for the runtime. If this parameter is set to the same value on the second instance, 20 processes
will be available. You must always take into account that on the SAP ERP side of
the SAP NetWeaver PI system, the RFC quotas and the work processes need to
be set accordingly. If enough work processes are available on the SAP ERP part of
your SAP NetWeaver PI system, we recommend that you set a value of 20 threads
here for the runtime.
5.2
This section describes the parameters on the SAP ERP side (ABAP stack) that allow
you to control the performance of your SAP NetWeaver PI system.
5.2.1
As mentioned previously, the optimum configuration of the system for a high RFC
load is of special significance. Therefore, well now describe the most important
SAP ERP profile parameters for the optimum configuration of the SAP ERP stack
for SAP NetWeaver PI 7.1. First, well focus on the settings of the gateway parameters (see Table 5.1).
Name
Value
Description
gw/max_conn
2000
gw/max_overflow_size
10000000
gw/max_sys
2000
gw/max_shm_req
400
137
321_Book.indb 137
10/5/09 2:23:42 PM
5.2.2
This section also focuses on the configuration of the system for an increased
amount of parallel communication. Therefore, in combination with the gateway
parameters described above, you should set or change the following values:
Name
Value
Description
rdisp/force_sched_after_
commit
No
rdisp/max_comm_entries
2000
rdisp/rfc_max_own_login
90
rdisp/rfc_max_own_used_wp
90
rdisp/rfc_max_wait_time
rdisp/wp_ca_blk_no
2000
rdisp/tm_max_no
2000
rdisp/max_arg
2000
rdisp/appc_ca_blk_no
2000
zta/max_memreq_MB
2048
Table 5.2 Recommended Parameter Settings for RFC, Communications, or Other Areas
138
321_Book.indb 138
10/5/09 2:23:42 PM
Name
Value
Description
Abap/arfcrstate_col_delete
Icm/http/max_request_size_
KB
2097152
5.2
Table 5.2 Recommended Parameter Settings for RFC, Communications, or Other Areas (Cont.)
Note
Because the ABAP side of the SAP NetWeaver Application Server in particular will be exposed to massive parallel RFC requests, you should place the highest priority in your optimization measures on the configuration of gateway and communication parameters.
5.2.3
You can set the number and type of queues available in SAP NetWeaver AS for
processing the messages via Transaction SXMB_ADM (menu item Configure Integration Engine) using various parameters. Within this transaction, select the Tuning category. This category allows you to add or change various parameters. We
should point out, however, that the number of queues depends on the number of
work processes on the instance, as well as the parallelization required, the threads
available on the J2EE stack, and the message size of the individual messages to be
processed by the queues.
Additionally, note that the principle the more, the faster is definitely not applicable here. The qRFC scheduler algorithm works more effectively with fewer queues
and with a greater amount of data per queue than it does with a high number of
queues containing a very low number of messages, because the scheduler can process a queue only every 60 seconds. Fortunately, this parameter (60 seconds) can
be manipulated, if necessary, to have the queues processed faster and to effectively
increase the number of queues and thus the amount of parallelization. The ideal
value is very hard to find because it depends on extremely different factors. Within
our processes, we calculated an initial value using the existing CPUs to start with
the fine-tuning described above. We recommend that you set two queues per CPU
as an initial value, but you should also take into account the simultaneous adaptation of work processes on the SAP ERP side.
139
321_Book.indb 139
10/5/09 2:23:42 PM
PerformanceOptimizationMeasures
The optimum configuration of the queues requires a certain flair. This configuration clearly influences the system performance. In fact, the performance for some
interfaces can be improved by up to 50%. Therefore, you should focus primarily
on a setting that is customized to reflect your environment. We suggest that you
carefully document every change of the settings and their individual impacts on
system performance.
Transaction SXMB_ADM takes you to the administration dialog of the SAP
NetWeaver PI parameters (see Figure 5.7).
Figure 5.7
Here you can adjust the parameter settings of your SAP NetWeaver PI system in
different areas. Well start with the Tuning category and describe how you can
increase the speed of your SAP NetWeaver PI system. In the Category field, select
the Tuning value and click on the change mode. This takes you to the menu shown
in Figure 5.8.
As you can see in Figure 5.8, you can configure the queues with the following
parameters:
EE
EO_INBOUND_PARALLEL
This parameter determines the extent of parallelization for processing messages
in the inbound and outbound areas with the quality of service Exactly Once.
The queues affected have the namespace XBTI (I = Central). For the value of this
parameter, n queues are created in the system by attaching the prefix n to the
name of the queue. Therefore, if the parameter is set to four queues, the following queues are created: XBTI0, XBT1, XBT2, XBT3. If in a system both the
central integration server and the local sender and receiver client are installed
on different clients, the degree of parallelization can be set individually for
each queue type (S = Sender, I = Central, R = Receiver, B = Sender and Receiver
140
321_Book.indb 140
10/5/09 2:23:42 PM
ParameterSettingsontheSAPERPSide
5.2
Figure 5.8
EE
EO_INBOUND_PARALLEL_SENDER
This is a more detailed version of the previous parameter. The meaning is the
same, with the addition that we can explicitly indicate the sender for which we
want to specify the setting. Thus, we can override the general previous settings
for individual interfaces and redirect the data in separate prioritized queues. To
be able to do so, however, we must define a sender-receiver ID via Transaction
SXMSIF, which specifies the identification schema, the partner, and the service
of the sender (normalized to the integration server). This sender ID will be
attached to the main parameter as a subparameter.
EE
EO_INBOUND_TO_OUTBOUND
This parameter explains how to place messages received with the quality of
service Exactly Once directly after there is receiver determination in dedicated
141
321_Book.indb 141
10/5/09 2:23:43 PM
outbound queues for output processing. You can force this behavior by setting this parameter to 1. If you keep the default parameter value of 0, these
messages are processed during inbound processing. Depending on the type of
messages to be processed, you can increase the performance by having the messages processed in separate queues.
EE
EO_OUTBOUND_PARALLEL
This parameter is very significant for the sending speed of your messages with
the quality of service Exactly Once, because it defines the degree of parallelization of outbound processing for the messages on the integration server. The
integration server places an outbound message with this attribute in a separate internal queue called XBTO+<Receiver ID>+<Number> or XBTB+<Receiver
ID>+<Number> for the confirmation of receipt. The number is a four-digit
value generated at runtime. To fine-tune individual interfaces, you can define
an individual degree of parallelization specifically for this key using a subparameter by combining the values of an identification schema, the partner, and
the service. However, we recommend that you dont set this degree of parallelization too high (even if your SAP NetWeaver PI system could handle it),
because you might cause problems on your target system. The processing speed
of your target system should therefore determine the degree of parallelization
that is defined. The default value is 3. On average, we increased this value to
10 and did quite well with this setting in our SAP landscape. Possible values for
this parameter are between 1 and 10,000.
EE
IS_RETRY_LIMIT
This parameter defines the maximum total number of retries when the asynchronous processing finds a repeatable error and the integration server sets the
retry status during queue processing. This parameter will only be effective if a
bigger retry value was set within the affected qRFC queue. If not, the value of
this parameter will be ignored and overridden by the queue parameter. Possible values for this parameter are between 0 and 100. We recommend a value
between 10 and 15.
EE
EO_MSG_SIZE_LIMIT
This parameter defines a threshold for the size of a message. If a message exceeds
this threshold, the message is processed serially in its own special queue called
XBTL. If the integration server must process several larger messages simultaneously, you can increase performance considerably with this parameter, because
there might not be enough main memory for processing several bigger mes-
142
321_Book.indb 142
10/5/09 2:23:43 PM
5.2
sages concurrently. Furthermore, your system produces a higher I/O rate owing
to paging, for example, which might affect the whole system. Serial processing
within this special queue ensures that only one bigger message can impact the
main memory at a time. The integration server can then continue to process
the smaller messages in parallel. If this situation occurs in your integration scenarios, we recommend you that you enable this parameter and set it to reflect
the size of your messages.
EE
EO_MSG_SIZE_LIMIT_PARALLEL
This parameter enables you to adjust the parameter described above even further to fine-tune the main memory load. All messages exceeding the threshold value of the EO_MSG_SIZE_LIMIT parameter are edited serially. Via this
parameter, you can still determine a user-defined parallelization. The messages
are processed in the special queue XBTL with a counter. Possible values for this
parameter are between 1 and 10,000. Depending on the main memory of your
integration server and the size of your messages, you should choose this value
very carefully so as not to achieve the opposite effect for your performance.
EE
B_EO_IN_PARALLEL
This parameter is dependent on the EO_INBOUND_PARALLEL parameter
described previously. It ensures an even distribution of the individual messages
to the queues defined in the EO_INBOUND_PARALLEL parameter. The value of
this parameter represents the maximum number of messages per queue. Activate this parameter if you previously increased the number of parallelizations
in the EO_INBOUND_PARALLEL parameter to force a redistribution of messages to the individual queues. Thus, a quicker processing of these queues can
be achieved. However, please note that the value of the EO_INBOUND_PARALLEL parameter multiplied by the value of the B_EO_IN_PARALLEL parameter should be bigger than the number of entries in the corresponding queues
because otherwise a sensible redistribution of messages is not possible. Possible
values for this parameter are between 1 and 100,000. The parameter can be
activated only via the BALANCING parameter. If this parameter is not active,
these settings will not take effect.
EE
B_EO_OUT_PARALLEL
This parameter is the counterpart of the B_EO_IN_PARALLEL parameter. It
defines the message distribution for the sender process, that is, for outbound
queues. The definitions are identical to the parameter described above. Note
that this parameter is activated only by setting the BALANCING parameter. Possible values for this parameter are between 1 and 100,000.
143
321_Book.indb 143
10/5/09 2:23:43 PM
EE
B_EO_IN_PARALLEL_SENDER
Like the two parameters described above, this parameter refers to a redistribution or equal distribution of messages to specific queues. In this case, equal
distribution refers to the queues defined in the B_EO_IN_PARALLEL_SENDER
parameter. This parameter can take values between 1 and 100,000 and is dependent on the BALANCING parameter
EE
BALANCING
The BALANCING parameter activates the parameters described above and
ensures an equal distribution of messages to the individual queues, which were
described in their respective parameters. If the redistribution of queues was
successful, the parameter is disabled automatically so that the messages are
processed normally again. Because the customizing table is locked by the transaction in which you set the parameter, we recommend that you leave the transaction immediately after setting this value so that the integration server can
change the value accordingly after a successful redistribution of queues.
ENGINE_TYPE
With this parameter, you define the type of your SAP NetWeaver PI server
depending on the current client. If you do not set the parameter, the client
is configured as a nonSAP NetWeaver PI engine by default. The HUB value
causes the client to be configured as an integration server. If you enter the value
LOC, the client is configured as a sender-receiver system.
EE
HTTP_TIMEOUT
This parameter defines the timeout for an HTTP connection between two data
packages in your network. Note that when you set this parameter, the icm/
server_port_n profile parameter is overridden. If you want to prevent this from
occurring, you should set its value to 0 to use the profile setting. If the network
connection of your company is slow, we recommend that you increase the
value accordingly. Otherwise, a timeout between 700 and 1000 should suffice
in most instances. If a faster termination is needed, you can reduce this value to
improve your systems response time.
144
321_Book.indb 144
10/5/09 2:23:43 PM
EE
ERROR_ON_NO_RECV_FOUND
This parameter determines the two qualities of service Exactly Once and
Exactly Once in Order if the queue is stopped when an error occurs and
no receiver can be detected or if the processing is finished and considered to
be accurate. If you want to mark the processing as faulty in this situation and
stop the entire qRFC queue, you must set this parameter to 1. Otherwise, you
need to set this parameter to 0. With regard to performance, the respective
queue is stopped, and error-free messages are not processed until you manually
intervene.
EE
ACK_SYSTEM_FAILURE
This parameter defines whether your system should report system errors for
asynchronous messages expecting an acknowledgment. Enabling this parameter results in a slight overhead on your system. The value 1 enables the reporting of system errors. The value 0 disables the reporting of errors.
EE
CACHE_DIRTY_READ
SAP NetWeaver PI uses a cache to optimize message processing. This cache
needs to be updated on a regular basis. You can do this either manually or automatically. If messages are being processed at the time, the system can choose
between two options:
EE
It can interrupt processing messages and wait for the cache refresh
EE
5.2
This parameter controls these two options. If you set it to 0, the system waits
until the cache has been refreshed. If the parameter is set to 1, processing is not
interrupted, and the old cache contents are used. This parameter thus influences
the performance during data processing. You should understand that messages
are not necessarily affected by a change in the cache. If, for example, a target
system that was not involved in processing current messages was changed,
the old contents of the cache can be used free of problems. Therefore, if you
can implement changes that do not affect interfaces in productive operation or
that are currently being processed, you can set this parameter to 1 to improve
performance. If you cannot ensure that the interfaces will not be adversely
affected, we recommend that you use a value of 0.
EE
CACHE_REFRESH_PACKAGES_SIZE
When setting this parameter, you should reduce the default value of 10 MB to a
value of 7 MB. SAP NetWeaver PI copies the configuration files per HTTP from
the Integration Directory into the SAP NetWeaver PI cache. This parameter
145
321_Book.indb 145
10/5/09 2:23:43 PM
defines the package size that is used to transfer this data. Our test series showed
an increased transfer speed for a smaller package size. Possible parameter settings are between 1 and 500 MB. You should consider the dependency on the
speed and usage of your network connection, as well as the configuration size
in your Integration Directory.
EE
ENTRY_LOCK
Although this parameter does not impact the performance of your Integration
Engine, we must mention it briefly here. By setting a value of 1, you can lock
the entire inbound processing of your SAP NetWeaver PI system. This is recommended especially for extensive changes to or updates of your system. A value
of 0 reactivates data reception in your inbound queues.
EE
LOGGING
To enable the logging function for asynchronous messages, set this parameter
to a value of 1. Logging leads to a reduced performance. Note that deactivated
logging is automatically reactivated whenever the logging tag in the diagnostics
header of a message is set to 1. Therefore, we recommend that you deactivate
the logging function because you can activate it, if necessary, via the diagnostics
header and therefore ease up on the average I/O rate of your system.
EE
LOGGING_SYNC
This parameter is identical to the LOGGING parameter described above, except
that this parameter affects synchronous messages. Here, too, we recommend
that you deactivate logging by default and enable logging only individually
through the diagnostics header of the relevant messages, if necessary. Valid values are 1 for enabling and 0 for disabling the logging function.
EE
TRACE_LEVEL
As the name of this parameter implies, it enables you to define the trace level
for message processing. The higher the setting of the trace level, the lower the
system performance when processing messages. You can set the values listed
in Table 5.3.
Values
Meaning
Tracing is deactivated.
146
321_Book.indb 146
10/5/09 2:23:43 PM
ArchivingandDeletionProceduresinSAPNetWeaverPI7.1
5.3
5.3
5.3.1
Archiving
Figure 5.9
Note that you can specify the number of parallelizations. Archiving jobs do not
use dialog processes, which used to be the norm in SAP XI, but instead use batch
processes. Therefore, you should select a number between 1 and 99 based on the
available batch processes. With a number of x available batch processes, we recommend that you dont choose the x, but choose a maximum of x 1. After you
147
321_Book.indb 147
10/5/09 2:23:44 PM
PerformanceOptimizationMeasures
PERSIST_DURATION
With this parameter, you define the maximum retention time of your XML
messages in your system. SAP defines the retention time as the time during
which an asynchronous message is kept in the database after it has been successfully processed. If this time is exceeded, this message is archived during the
archiving session described above. Via the sending or receiving interface, you
can define the messages to be archived. However, please note that all messages
that are not marked for archiving will be removed by the deletion job described
in the next section.
Possible values can be between 1 and 999 days. Our experience has shown that
with sufficient hard disk space, 14 days is a reasonable value. This value enables
you to reproduce problems (for example, in mappings) even after a few days.
EE
ARCHIVE_PARALLEL
This parameter controls the number of archiving sessions to be started simultaneously. As described above, you can override this value in the dialog. It is
advisable, though, to properly store this value in the parameter. Note that the
parameter also controls the number of archives that are written to in parallel.
The messages marked for archiving are then distributed among these archives
according to this parameter. With regard to performance, this leads to signifi-
148
321_Book.indb 148
10/5/09 2:23:44 PM
ArchivingandDeletionProceduresinSAPNetWeaverPI7.1
5.3
cant improvements the more messages you process with your SAP NetWeaver
PI system. As described above, we recommend that you dont use all available
batch processes for archiving jobs, because no other batch activities can run on
your system during this time. Possible values can be between 1 and 99.
EE
PERSIST_ARCH_MANUAL_CHANGES
This parameter is interesting for optimizing the archiving behavior for your
development or quality assurance system. If, in a productive system, the processing of a message is terminated for a specific reason or a message is edited
manually, this parameter can be used to control the respective behavior. However, this is not really necessary in a test or quality assurance system and would
only compromise performance. Therefore, you can influence the behavior of
archiving by using this parameter. It can take a value of 0 (no) or 1 (yes). A value
of 0 means that messages changed manually in a nonproductive system will be
archived or deleted according to the settings described previously. A value of 1
causes messages that were changed manually, that is, also messages the processing of which was terminated, to be archived.
In a test and quality assurance system, we recommend a value of 0 and, naturally, a value of 1 for your productive environment.
5.3.2
Deletion Procedures
Similar to scheduling archiving jobs, you can schedule a deletion job (as shown in
Figure 5.11), which is controlled using the parameters of Transaction SXM_ADM
as well.
149
321_Book.indb 149
10/5/09 2:23:44 PM
PerformanceOptimizationMeasures
After selecting the Schedule Delete Jobs node, you can specify the relevant settings
for the deletion job as shown in Figure 5.12.
As in normal job scheduling, you determine the start date, the start time, and a
periodic limit that specifies the interval in which the deletion job is to be run on
your system. This can be days, hours, or even minutes. The default setting is 10
days.
Using the parameter settings of Transaction SXMB_ADM (Integration Engine Configuration category), you can set various parameters (like for archiving) in the Deletion subcategory to control the deletion behavior. For most of those parameters,
the ideal value depends on the size of the system and the number of messages to
be processed per day. The parameters are used as follows:
EE
Possible values are 1 to 999 days for asynchronous messages and 0 to 999 days
for synchronous messages. For asynchronous messages, we recommend that
150
321_Book.indb 150
10/5/09 2:23:45 PM
5.3
you set a value of 14 days, whereas you should use a much lower value for
synchronous messages (0 to 2 days) if the number of messages to be processed
is high.
EE
PERSIST_DURATION (HISTORY)
This parameter defines the retention time of history entries until the data is
eventually deleted. This retention time includes the time during which a history entry of a deleted or archived message is kept in the database after the
message has been deleted. The history entry will then be removed by the next
session of the history deletion job. Note that history entries are only needed for
the EO log (Exactly Once). Possible values can be between 7 and 999 days.
EE
PERSIST_DURATION_ERROR
This parameter defines the maximum retention time for messages that were
not properly processed until they are deleted from the system by the scheduled
deletion job. In this case, the retention time is defined as the time during which
a message that was processed synchronously is kept in the database after it was
incorrectly processed. Possible values are between 1 and 999 days.
EE
DROP_MAX_TABLE_LOAD
This parameter must be seen in the context of the switch procedure. If you have
a lot of data to be deleted or archived, SAP allows you to use the switch procedure that affords an improved performance. For every database table involved,
SAP delivers an identical table in the standard version. At first, the original
tables are the sources of data storing. If messages are scheduled for deletion or
archiving, the entry is not deleted from the original table. Instead, an indicator
is set that marks this message for deletion or archiving. After a certain fill level
defined by the DROP_MAX_TABLE_LOAD parameter is reached, the deletion
or archiving job determines that a reorganization (switch) is necessary. The
table copies are then made the active tables. New data is now written directly to
these table copies. Subsequently, the original table is used to determine which
data is not marked with a deletion indicator. This data is then taken over into
the table copy. After this copy process is finished, the original tables are permanently deleted from the database and then immediately recreated on the
system.
The maximum fill level defined in this parameter refers to the SXMSPMAST
table. In the standard version, the normal deletion procedure is enabled. This
means the messages are always deleted directly in the original table, which can
significantly impact the performance for very high data volumes. To activate the
151
321_Book.indb 151
10/5/09 2:23:45 PM
PerformanceOptimizationMeasures
To enable the switch procedure, it is sufficient to simply select the option Switch
Procedure Activated. However, note that the deletion or archiving of messages
depends on the clients, which means you must specify archiving and deletion
settings individually for each client. In the switch procedure, however, this is a
cross-client parameter. Additionally, although the switch procedure can easily
be activated, to disable it you must ensure that the counter for the number of
deleted records in the original table is set to 0 if the original tables are active.
If this is not the case at that time, the SAP NetWeaver PI system adheres to the
administrators request and will not carry out the changes until the next copy
procedure.
The DROP_MAX_TABLE_LOAD parameter controls this process by defining
the maximum fill level for the master table as a percentage. This behavior can
be calculated by multiplying the expected number of entries with the DROP_
MAX_TABLE_LOAD parameter and dividing it by 100. If this value is smaller
than the actual number, a table switch is carried out with a subsequent drop of
the original tables. For example, if we expect 1000 entries, and the parameter
is set to 50%, a table switch would be carried out as soon as the table reaches
500 entries. Possible values are between 0 and 100.
EE
152
321_Book.indb 152
10/5/09 2:23:45 PM
ApplicationTuning
5.4
5.5
The adapter framework running on the J2EE stack requires a fixed number of
threads on the J2EE side. The effective number of threads required depends on
the configuration in your Integration Builder or Directory. The RFC sender channels and the file adapter channel, for example, need their own threads on the
J2EE stack. Therefore, you should proactively increase the number of application
threads to a minimum of 250. For this purpose, you can use the ConfigTool, which
you can access in your SAP NetWeaver system via <SAP_install_dir>/<system_
name>/<instance_name>/j2ee/configtool directory. As shown in Figure 5.14, you must
then change the ApplicationThreadManager parameter value accordingly.
5.5
Application Tuning
We recommend that you package the messages youre sending to the SAP
NetWeaver PI system in chunks of approximately 7 MB, if possible. The package size, however, depends on the hardware and the configuration of your SAP
NetWeaver PI system. Therefore, you should carry out performance measurements
to find your ideal package size.
153
321_Book.indb 153
10/5/09 2:23:46 PM
As of SAP NetWeaver PI 7.0 SPS 13, you can also package the processing of
received asynchronous messages in SAP NetWeaver PI. This function enables the
SAP NetWeaver PI system to group multiple messages into packages and to run
these packages through the individual processing steps of the Integration Engine
and Adapter Engine. This function does not depend on the packaging of the IDocs
of a sender system. Especially with regard to the mapping step, this function can
increase your system performance, because it ensures that a mapping for 500
messages, for example, is instantiated only once. The packaging function does not
affect the displays of the monitoring programs of SAP NetWeaver PI, because there
all messages continue to be displayed as single messages. Similarly, the communication channels of the Adapter Engine process only single messages.
You can activate the message packaging function in the parameter settings of Transaction SXMB_ADM (Runtime category) by setting the PACKAGING parameter to 1.
By setting the LOGGING_AMF_ERR parameter to 1, you can enable the logging of
errors during package processing. Based on our experience, we recommend that
you enable the logging parameter only in your development system.
SAP uses the following default package configuration:
EE
Wait time = 0
EE
Number = 100
EE
You can create your own package configurations using Transaction SXMS_BCM
and map these configurations to the individual steps within the Integration Server
via Transaction SXMS_BCONF. This transaction also allows you to map your own
package configurations to individual sender systems and sender-interface combinations. SAP Note 1037176 contains detailed information about this.
154
321_Book.indb 154
10/5/09 2:23:46 PM
Index
A
Abap/arfcrstate_col_delete, 139
Acknowledgment, 159
Adapter Framework, 153, 203
Adapters, 10
Administration of the SLD namespace, 59
Advanced Adapter Engine, 9, 111
Alert category, 177
Alert configuration, 161
Alert inbox, 161
Alert management, 173
Alert monitoring, 156, 157, 172
Alert server, 156, 214
Application platform, 13
Archiving, 147
Authorization check, 118
data-dependent, 114, 123
Authorization rule editor, 119
Cache contents, 74
CACHE_DIRTY_READ, 145
Cache monitoring, 161, 182, 183
CACHE_REFRESH_PACKAGES_SIZE, 145
Cache types, 182
CCMS, 156
CCMS monitor, 156
CCMS_MONITORING , 163
CCMS RFC Server Group Maintenance, 132
Central information provider, 20
Change Management Service (CMS), 21, 73,
77, 110
Change Management Service (CTS), 113
CIM dependencies, 58
CMS architecture, 73
Collaboration, 13
Communication parameters, 138
Component Build Server (CBS), 113
Component monitoring, 156, 160, 161
Component repository server, 203
Computing Center Management System
(CCMS), 156
ConfigTool, 153
Configuring SLD profiles, 54
Configuring the system landscape, 51
Configuring the system parameters, 24
Create group, 108
Creating a software component version, 188
Creating software components, 186
CTS+, 21
Customizing the System Landscape Directory,
61
B
BALANCING, 143, 144
BAM infrastructure, 15
Basic administration of the SLD, 51
Batch processes
number, 132
B_EO_IN_PARALLEL, 143
B_EO_IN_PARALLEL_SENDER, 144
B_EO_OUT_PARALLEL, 143
BPEL, 16
Business activity monitoring infrastructure, 15
Business intelligence, 13
Business Process Execution Language (BPEL),
16
Business system, 68
D
Data supplier bridge, 20
Deletion procedure, 147, 149
221
321_Book.indb 221
10/5/09 2:24:14 PM
Index
E
EAI software, 9
em/global_area_MB, 157
End-to-end monitoring, 156, 157, 160, 165
ENGINE_TYPE, 144
Enhanced Change and Transport System
(CTS+), 21
Enterprise Services Builder, 188
authorizations, 114
Enterprise Services Builder , 19
Enterprise Services Registry, 15, 185
Enterprise Services Repository, 15, 18, 19,
110, 185, 207
ENTRY_LOCK, 146
EO_INBOUND_PARALLEL, 140
EO_INBOUND_PARALLEL_SENDER, 141
EO_INBOUND_TO_OUTBOUND, 141
EO_MSG_SIZE_LIMIT, 142
EO_MSG_SIZE_LIMIT_PARALLEL, 143
EO_OUTBOUND_PARALLEL, 142
ERROR_ON_NO_RECV_FOUND, 145
Exchange Profile, 123
F
FastRFC, 212
File adapter channel, 153
Full automatic content synchronization, 22
G
Gateway parameterization, 131
Gateway parameters, 137
H
HTTP_TIMEOUT, 144
I
Icm/http/max_request_size_KB, 139
Identity Management, 107
Index administration, 161
Information integration, 13
Integration Builder
authorizations, 114
Integration Directory, 19, 110, 212
Integration Repository, 19, 213
Integration server, 19, 110, 204, 214
Internet Communication Framework (ICF),
204
Internet Communication Manager (ICM), 180
Internet Transaction Server (ITS), 162
IS_RETRY_LIMIT, 142
ITS, 162
ITS plug-in , 157
J
J2EE ApplicationThreadManager, 153
J2EE instances
number, 134
J2EE security roles, 106
Java Monitoring, 178
JCo service provider, 131
JCo service provider on the J2EE side, 134
JEE5, 16
Job scheduling, 59
222
321_Book.indb 222
10/5/09 2:24:14 PM
Index
K
Knowledge management, 13
L
Landscape Configurator, 78
Landscape directory server, 205
Lifecycle management, 13
Local processing , 9
Locks on objects, 74
LOGGING, 146
LOGGING_AMF_ERR, 154
LOGGING_SYNC, 146
LRU map-based cache, 208
M
Mapping editor, 183
Mapping types, 210
Master data management, 13
Message monitoring, 156, 160, 164
Message packaging, 9
Message sequence flow, 160
Message-server, 204
Message type, 193
Minimum configuration of the transport
system, 101
Mobile infrastructure, 13
Monitoring, 155
Monitoring server, 214
N
Namespace, 59, 189
NetWeaver Administrator, 19, 113
P
Packaging, 153
PACKAGING, 154
People integration, 13
Q
qRFC queues, 134
Qualities of service, 16
Queues
number, 134, 139
R
rdisp/appc_ca_blk_no, 138
rdisp/force_sched_after_commit, 138
rdisp/max_arg, 138
rdisp/max_comm_entries, 138
rdisp/rfc_max_own_login, 138
rdisp/rfc_max_own_used_wp, 132, 138
rdisp/rfc_max_wait_time, 138
rdisp/tm_max_no, 138
rdisp/wp_ca_blk_no, 138
rdisp/wp_no_dia, 132
Reliable messaging, 16
Repository server, 204, 205
RFC connectivity, 131
RFC parameterization, 131
223
321_Book.indb 223
10/5/09 2:24:14 PM
Index
S
SAML, 16
SAP_BC_XMB_ARCHIVE, 148
SAP NetWeaver, 13
SAP NetWeaver Administrator, 135
SAP NetWeaver Application Server, 16
SAP NetWeaver Java Development
Infrastructure, 113
SAP NetWeaver Process Integration, 9, 14
architecture, 18
Landscape Topology, 20
roles, 104, 105, 106
runtime parameters, 144
tuning parameters, 139
SAP roles, 106
Security Assertion Markup Language (SAML),
16
Security role, 107, 108
Server log, 52
Service consumption, 15
Service implementation, 195
Service interface, 190
Service model, 188
Service-oriented architecture (SOA), 9, 185
Service publication, 197
Service user, 110
Set up data persistence, 53
Single sign-on (SSO), 126
Sizing SAP Exchange Infrastructure 3.0, 24
SLD, 20, 113, 186
SLD bridge setup, 56
SLD data bridge, 21
SLD profiles, 54
SOA Management, 197
Software catalog
SLD, 62, 186
Software component versions, 62
Support package, 23
System data and sizing, 23
System landscape, 51
System Landscape Directory (SLD), 20, 110,
113, 186
System parameter, 203
T
Technical system, 65
Threads
number, 153
TRACE_LEVEL, 146
Transaction
ALRTCATDEF, 176
ALRTINBOX, 173, 178
GRMG, 178
IDX5, 160
PFCG, 174
RZ04, 133
RZ10, 132
RZ12, 132
RZ20, 156, 171
RZ21, 173
RZ70, 21
SA38, 157, 177
SALRT1, 174, 175
S_B6A_52000011, 160
SE38, 157
SE80, 157
SICF, 162, 166
SLDCHECK, 158
SM30, 172
SM59, 174, 180
SOAMANAGER , 197
SPROXY, 195
SU01, 103, 113, 114, 174
SWE2, 176
SXI_MONITOR, 158, 164
SXM_ADM, 147, 149
SXMB_ADM, 139, 148, 162
SXMB_MONI, 158, 164
SXMB_MONI_BPE, 160
224
321_Book.indb 224
10/5/09 2:24:14 PM
Index
SXMSALRT, 176
SXMS_BCM, 154
SXMS_BCONF, 154
SXMSIF, 141
Transaction
PFCG, 103, 111
Transaction SCOT, 174
Transaktion
ALRTCATDEF , 175
Transport groups, 70
Transport system, 74
U
UDDI directory service, 15
UME, 103
Universal Description, Discovery, and
Integration (UDDI), 16
User group, 107
User Management Engine (UME), 103, 114
W
Web Service Administration, 198
Web Service Navigator, 199
Web Services Reliable Messaging (WS-RM), 16
Web Services Security (WS Security), 16
Work processes
number, 131
WS-RM, 16
WS Security, 16
X
XML data transfer, 164
XML validation, 19
Z
zta/max_memreq_MB, 138
V
Value mapping, 182
Visual Administrator, 19, 113, 135
225
321_Book.indb 225
10/5/09 2:24:14 PM