This article is part of our Integration Cookbook.
Modularization
- 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.
Parallelism
- 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.
BRM
- 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
