Process Modeling Principles for Interface Designers

This article is part of our Integration Cookbook.


  • Limit the process model to 25 – 50 steps to keep them manageable. This can be achieved by hiding complexity in sub-processes.

Interface Design

  • Use Service Interfaces based on Message Type and Data Type defined in ESR. Using External Definitions (XSD, WSDL) can lead to compatibility problems during import and runtime (also when anonymous types are used in the WSDL/XSD, the data structures might not be available for process context definition.
  • Service Interfaces used for communication between BPM and PI/AEX have to have the interface pattern Stateless (XI30-Compatible) in ESR.
  • The interfaces of a BPM process should be as lean as possible. Any mapping and conversion logic should be handled in PI already. Use a harmonized and lean data model for the process context and not to “pollute” the BPM with the specifics of the individual source/target systems. Instead use mappings in integration flows to perform conversions between the data model used for the process context and the specific requirements of the source/target interfaces.
  • XSD constraint violations, for example if a string field requires a minimum length of three characters but it is attempted to assign a value consisting of only two characters, can cause issues that are hard to track down. For example if starting a process instance fails because such a constraint is violated in the output mapping in the start event of a process the incoming message is considered to be successfully delivered to the BPM engine but despite that no corresponding process instance can be found in Manage Processes of NetWeaver Administrator, i.e. the only hints regarding that situation are exceptions in the Developer Trace. Due to that it is advisable to avoid using data types with XSD constraints when defining the data model for the process context.

Correlation Conditions

  • Use direct value comparisons (e.g. string-equals), i.e. avoid expensive operations

Connectivity BPM – PI

  • Using the XI protocol requires a service interfaces that is XI30 compliant as well as a specific BPM service group configuration and communication channels making use of the local proxy runtime.


  • BPM always locks whole context objects and not substructures of objects, so in case parallel process flows manipulate different substructures of the same context object, splitting up the object will reduce the number of access collisions.
  • If parallel process flows manipulate the same data structure, the access to the data structure is automatically serialized and might slow down the processing.
  • A data object can easily become a synchronization point, thus hamper the system performance, if it is modified from different artifacts of the process model concurrently. That is especially to be considered when using parallel split gateways or dynamic parallel loops (par-for-each) and trying to store the outcome of the parallel operation into a single/central data object.
  • The same issue can appear if you mark a single activity for dynamic parallel execution (par-for-each) and perform an output mapping to the same data object. Again, the execution would be serialized due to concurrent request for a write lock.
  • A real parallelization can be achieved by modeling an embedded sub-flow and execute this flow dynamically in parallel.
  • Additionally, in the sub-flow you have to separate the concrete activity from the mapping to the central DO. Use an intermediate DO to store the mapping result, i.e. to avoid a serialization by a write-lock on the central DO. Then map the intermediate DO content to the central DO. The system will serialize the execution at the mapping activity. But since mapping is typically a much less expensive operation than the ‘real’ activity, the lock won’t last long. This means the negative impact of the serialization at the DO is less than not using a sub-process.

Operation Mappings

  • In the process model Operation Mappings are consumed like any other service interface by assigning them to an automated activity. Unlike other calls to PI, a service reference of type WS is required here instead of XI as operation mappings are called via SOAP and not the XI protocol. Additionally, as the operation mapping is running on the local AEX of the Process Orchestration system, the service group has to point at the local system.
  • To ensure that calling the operation mapping works at runtime a BPM DC consuming an Operation Mapping needs a build-time dependency to the public part “def” of the framework DC “bie/sca/scdl/contributors/maas”. Usually that dependency is created automatically if an Operation Mapping is imported from ESR.
  • BPM does not support consuming Operation Mappings that contain the following characteristics:
    • Value Mappings
    • Parameters
    • Synchronous Interfaces Responses
    • Fault Messages
  • The combined length of application name and operation mapping service port name must not exceed 255 characters (SAP Note 1890617).

Context Size

  • Avoiding large process contexts (>1 MB) increases the number of concurrent processes that can be executed by the server. The count of mapped attributes (per activity) should be smaller than fifty.
  • Claim Check: Reducing the footprint of the process context can be achieved with the Claim Check Pattern.

Error Handling

  • The standard boundary event TechnicalError can be used to capture system errors during synchronous calls in BPM automated activities.
  • For the purpose of sending notifications or automated error handling activities details about the technical error are available as output fields and can be mapped to the process context.
  • Additionally, if interfaces consumed by BPM contain fault structures boundary events for catching those faults will be provided by BPM and can be added to the automated activity.
  • In case no boundary events are added to an automated activity the default behavior applies. In this case the process will be suspended into an error state. In NetWeaver Administrator such a process instance can be resumed manually and it will try to continue execution at the step where the error occurred. This can be automated by using the WHINT ProcessRestart Job.


  • Business rules which are meant to be reusable and not related to a specific process reside in a dedicated rules DC. Reusable business rules are called via web service by BPM and other consumers.
  • The web-service generation feature provided by BRM only works inside-out, i.e. it is not possible to directly use an ESR Service Interface as a web-service interface for a business rule.
  • Decision Table Maintenance
    • The content of BRM Decision Tables can be maintained in two basic ways, either by a developer using NetWeaver Developer or by authorized users in the web-based rules manager directly on the application server. A decision which method should be used for a specific scenario can be made based on the following aspects:
NWDS Rules Manager
Accessibility Developers only Authorized users, i.e. also business users if necessary
Software Logistics Content is transported through system landscape like all other development artifacts via NWDI, changes available to all developers Changes are applied directly on a single run time system, i.e. even changes directly on the production system are possible. No automatic transport of the content change to other systems of the landscape. No impact on the content defined by the developer in NWDS, developer would have to acquire and import the changed definition manually.

Further Recommendations

Naming Conventions for SAP BPM

This article is part of our Integration Cookbook.

Name Pattern  Example
Same as ESR SWC or
generic SWC “BPM” when
used in NWDI due to the
underlying components
  • BPM of
  • bpm/otc/edi
  • bpm/le/shipment/tracking/ups
Process Name <Action>
  • Download_ShipmentTracking
  • Query_FxRates
  • Process_EcomOrder

WHINT ProcessRestart Job


In case your BPM process is using an automated activity which can fail during processing (e.g. by calling an external service) and you did not set up any error handling (by managing boundary events), your process will fail and remains in status “Suspended”. Then you have to manually resume the process from the Process Monitoring. Or you use the following solution:

WHINT ProcessRestart Job is a solution that automatically looks for BPM Process Instances in error and resumes them automatically.


  • Works with SAP NetWeaver PO (BPM) version 7.3 EHP1 and higher (including 7.50)
  • Deploy the SCA/EAR file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet



  • Schedule the job from NWA -> Operations -> Jobs -> Java Scheduler or via quick link /nwa/jobs
  • Add Task with Job name ProcessRestartJob
  • Parameters (best is to look them in the Process Repository in PIMON -> Configuration -> Processes and Tasks):
    • Component: Name of the development component
    • Vendor: Name of the software vendor
    • ProcessName: Name of the BPM process
  • The scheduling should be done according to your business needs (e.g. hourly orMon-Fri between 8:00 and 18:00)





The job is executed and restarts a process in error by resuming it automatically:


The resume activity is shown in the process instance history (here the process becomes suspended again):


WHINT AggregateMessages byReceiver BPM Process



This BPM process collects (aggregates) messages for a system and then (after 5 minutes collecting) forwards them to a receiver (system/partner). It is a generic process that can collect any XML data (not only IDocs) and forward it to a receiver.


  • SAP Process Orchestration 7.3 EHP 1
  • SAP Process Orchestration 7.4
  • SAP Process Orchestration 7.5


  • Deploy the SCA file provided by Whitepaper InterfaceDesign using NWDS/JSPM/SUM/Telnet
  • Import the TPZ file provided by Whitepaper InterfaceDesign into ESR


  • ICO/iFlow 1 (Sender to BPM): Map your single message XML to the generic XML Structure and define the correlation under which the messages have to be aggregated (e.g. receiver partner id, vendor number, order number, …)
  • ICO/iFlow 2 (BPM to Receiver): Map the aggregated message XML to the final target structure before sending it to the receiver

Sync-Async Connectivity (SOAP 2 MAIL) with SAP PRO (w/out BPM)

Sync-Async Patterns with BPM on SAP NetWeaver Process Orchestration (PRO) are quite easy to implement.
However, when you want to design the integration flow as lean as possible, this document might be useful for you as the usage of the sync/async adapter modules is a bit tricky.


  • SOAP Sender (in our example WebShop) is calling SAP PRO synchronously
  • The request is forwarded asynchronously via E-Mail to the receiver (typically it would be e.g. IDoc to SAP ERP of course)

This is an example scenario of course. HTTP/SOAP on the (sync) sender side can be combined with any channel on receiver side (IDOC/SOAP/FILE/SFTP/MAIL/JMS/JDBC/…)

Adapter Modules used:

We are using the following (standard) adapter modules:

  • AF_Modules/RequestOnewayBean (to convert the synchronous message to an asynchronous one)
  • AF_Modules/DynamicConfigurationBean (to store the original message id in the ASMA of the sender channel and read it in the receiver channel to set the correlation)
  • AF_Modules/WaitResponseBean (to wait for the reply of the receiver channel)
  • AF_Modules/NotifyResponseBean (to send back the message to the waiting sender channel using correlation)

ESR Content (sender side):

  • Service Interface Sync Out
  • Service Interface Sync In (Dummy)
  • Operation Mapping (Service Interface Sync Out -> Sync In)
  • Message Mapping (Input Message Type -> Output Message Type)

DIR Configuration:

  • Sender System
    • SOAP Sender Channel
    • SOAP Receiver Channel
  • Receiver System
    • MAIL Receiver Channel


It is of course not necessary to do this in NWDS but I really started to like it…





Test & Monitoring:

  • Call WebService from WS Navigator
  • ASMA (DynamicConfiguration) with MessageId
  • E-Mail received from SAP PRO


SAP_Moni1 SAP_Moni2 SAP_Moni3 SAP_Moni4