Sizing Memory and Disk for SAP Process Orchestration 7.

40
and 7.50

INTRODUCTION

This document is intended to support initial sizing and uses basic assumptions with regard to process
complexity, data context objects, and message sizes. The document is not intended to provide exact sizing of
scenarios which involve complex processes (with perhaps tens or hundreds of artifacts) nor scenarios which rely
on large messages (larger than 100KB).

Sizing memory and disk for SAP Process Orchestration is an important part of system landscape planning.
If the transactional data of the process orchestration system is not managed it may grow so large that
performance is negatively impacted. A process orchestration system needs proactive data management to
ensure that business data is kept at optimal levels.

Expert sizing can be provided for scenarios which have greater complexity or require large data and message
sizes. Such sizing is highly scenario dependent and the simple method described in this document may not
adequately size the landscape. Please understand the limitations of the described simple sizing method and use
it accordingly.

Applicability: This document refers to SAP Process Orchestration, which is the combined offering of SAP
Process Integration - Advanced Adapter Engine (SAP PI-AEX) and SAP Business Process Management (SAP
BPM). The method for sizing described herein may also be used for systems consisting of only SAP PI-AEX or
SAP BPM. The sizing examples are applicable for all platforms and databases. For all databases (including SAP
HANA) you need to consider the ‘Size in File System’ for the data files. For SAP HANA you must also consider
‘Size in Database / DB Memory’ as with SAP HANA the database is in-memory. The in-memory requirement
determined for SAP HANA is only for the application schema data (i.e. business data). This is in addition to the
basic memory requirement for other data in the HANA system.

Assumptions

The amount of data related to a process is dependent on complexity of the process, the types of data artifacts in
the process context, and the amount of messaging within the process. For initial sizing, as described in this
document we assume a basic process with the following artifacts:

• Two Human Tasks

• Four Stateful Mediated Messages
• Four Context Objects
• Six Context Object Mappings
• The context objects are all 2 KB and the messages are all 10KB or less

Basic System Configuration

The BPM Business Log are set to ‘Standard’ (see Configuring Business Log Levels)
The PI message retention is set at 7 days (see PI Message Logging)
The PI message logging is maintained as standard, only asynchronous messages are logged. (see PI Message
Logging)
The schedule of once daily is kept for the PI message delete job (see PI Background Jobs)
The standard ‘as installed’ settings for log level, and background job schedule are kept. The message retention
is assumed to be 7 days to allow for messages related to in-progress process instances to be retained for a
longer duration. By default, PI message retention is set to 1 day and this retention period is recommended for
pure messaging scenarios. Longer retention periods directly impact the sizing as a longer retention period
means more messages are stored in the system.

Process Data Lifecycle

Process data consists of process and task metadata, state data, and context data. The data is stored in a small
set of tables within the database. Business logs contain a detailed history of the process and task state, as well
as process context history. Depending on the state of a process the data may reside in different tables, but for
the purpose of sizing we assume the amount of process data held in the database remains constant regardless
of which tables hold the data.

As a generalization, process data for process instances which have not yet been archived is held entirely in the
database tables. Process data for archived process instances is held almost entirely on the file system, although
1KB of metadata will stay in the database to provide access to the data from the running system. When a
process instance is archived the total amount of data isn’t changed, the data is simply moved from the database
to the file system.

Active
BPM PI-AEX
Process Messaging

INSERT & UPDATE INSERT & UPDATE INSERT & UPDATE INSERT

STATE DATA CONTEXT DATA HISTORY DATA MESSAGE DATA

Active processes with associated messaging will have data written to state, context, and history tables in BPM
and message tables in PI.

Completed

UPDATE DELETE INSERT & UPDATE

STATE DATA CONTEXT DATA HISTORY DATA

On completion most of the process data is deleted from the State and Context tables of BPM. Completed
process data is available in business logs.

Copyright/Trademark
 Archived
BPM Archiving

DELETE DELETE DELETE

STATE DATA CONTEXT DATA HISTORY DATA

To File System archive store

When a process is archived the remaining data in State and Context tables is deleted and only history data in
the business logs remains. A small amount of metadata also remains in the XMLDAS tables to provide
continuing access to the archived business process instances.

Message Data Lifecycle

The message data lifecycle is very simple. Logged messages are held in the system until they are deleted from
the system by a standard PI background job. Based on the configured logging level and message retention and
scheduling of message deletion job the message data footprint can be estimated. The standard retention period
is 24 hours. In the case where you have PI messages related to BPM processes you may wish to adjust the
retention period to a duration which reflects the typical process instance duration.

PI-AEX
Messaging
Deleted
PI Background
Delete Job
INSERT DELETE

MESSAGE DATA MESSAGE DATA

Data Retention

Data retention requirements are a key factor in the amount of database and file system space needed for your
Process Orchestration Landscape. For the examples below we assume that the BPM process data is kept in the
system for two months before archiving and that archived process instances are kept for two years on the file
system. For PI we assume that messages are held for 7 days when they are related to a BPM process and 1 day
when the scenario does not use orchestration.

Sizing Examples

Copyright/Trademark
The provided sizing example can be used as a basis for your own estimation. The assumed size of 50KB for
process data and 3 KB for message data should only be changed if you know your own requirements based on
testing. For BPM and Process Orchestration Process Data sizing the message size is assumed to be 10KB or
less. The sizing may not be accurate for larger messages. Message mapping also influences the sizing
calculation as messages are persisted both before and after the mapping step. The example below assumes the
trivial case of no message mapping.

The size is calculated using:

5000 (processes/day) x 60 (days) x 50(KB) = 15.0 GB

Archived Process Instances

Archive Process Retention Period 720 720 days, Two years
Retained Process Instances in Archive Store 3,600,000 Archived Processes in Archive Store

Size in Database Memory (HANA) 1 KB / Process Instance

Size in Database (data files) 51 KB / Process Instance

Size in Memory 3,600 MB

Size on Disk 183,600 MB

The size is calculated using:

5,000 (process/day) x 720 (days) x Size per process for MEM or DB

PI-AEX Messages
Daily Message Volume/Throughput 1,000,000 # of Messages
Message Retention Period 7 Days
Retained Messages 7,000,000 # of Messages

Size in Database / DB Memory 2 KB / Message

Size in File System (DB data files) 2 KB / Message

Size in Memory 14,000 MB

Size on Disk 14,000 MB

This estimation assumes only messages below 10KB and that all asynchronous messages are held in the
database. The estimate also assumes disk LOBS to store messages larger than 2KB on disk. This is
recommended for high-volume scenarios. It is also recommended for scenarios where the message size is
larger than 10KB. Message metadata is stored in two tables (1 row per table per message) and regardless of
message size the metadata is 1KB per row, or 2KB in total for each message.

For large messages it is possible to store the messages on disk directly using database specific functionality for
storage of LOB data types. This is configurable although the details are different per database, and you can set
threshold sizes which determine whether a message is stored in the database or directly on the file system. For
our estimations we store all messages over 2KB on disk. For larger messages you should contact SAP for

Copyright/Trademark
expert sizing. When using disk storage for LOBs you can use the average message size to determine the disk
storage requirement as the messages are not compressed. As an example, with a 100KB average message size
using HANA DB and the BC_MSG table column MSG_BYTES configured for disk storage as shown then you
will use 100KB of disk space for each asynchronous message passed through the system.

The SQL statement below is used on a SAP HANA database and alters the BC_MSG table to configure disk
storage for messages (stored in the column MSG_BYTES) which exceed 2048 bytes.

ALTER TABLE "SAPH74DB"."BC_MSG" alter (MSG_BYTES BLOB MEMORY THRESHOLD 2048);

Note that as of HANA SPS07 the use of Hybrid LOBs is by default.

Other Sizing Considerations

Message mapping is a typical requirement for customers. For each message mapping, the message processing
has at least two persistence steps – one before and one after mapping that is persisted in BC_MSG_LOG.
Furthermore you have to persist the IDocs going in and going out (BC_IDOC_* tables). As a general rule you
can increase the sizing result of PI-AEX messages by a factor of 2.5-3.0 in the typical case where a message
mapping is used. This is valid for basic sizing as explained in this document. For more complex scenarios, such
as complex or multiple mappings it is recommended to accurately simulate the message processes and then
evaluate the actual DB persistence based on the simulation.

There is additional data storage required for tables such as BC_SLD_CHANGELONG and for the performance
message overview views of the Netweaver Administrator monitoring. This adds approximately 2-4GB of data
storage.

Copyright/Trademark