Ready to set your BPM process into production?

Based on experience from customer projects, here are some important things to consider for a “healthy” Go-Live:

 

272750_l_srgb_s_gl (2).jpg

1) Handle errors in the process model

A typical case for a process error is when an external web service is called via automated activity, and the external system is not available.

By default, the process will be suspended with an error. Starting with 7.31 SP10, you can define a boundary event to automatically handle such errors.

Other reasons for suspended processes could be mapping errors. Check your mappings and make sure that all fields which are marked as mandatory will actually be filled.

 

2) Set all log levels to “Error”

Logging too much information can have a serious impact on performance. In production, the global log level should be “Error”. In case a specific issue needs to be investigated, only the log levels of the relevant locations should be increased. After the investigation is finished, set the log level back to “Error”.

For more information on how to change log levels, see Log Configuration with SAP NetWeaver Administrator – Monitoring – SAP Library

 

3) Define Administrator roles

SAP BPM has a fine-grained authorization concept: Authorizations and Roles – Business Process Management Security Guide – SAP Library

In general, there are two types of administrator users: technical and “business”.

Technical administrators have full access to NWA, can modify system configuration and manage all processes/tasks. They would have the role “SAP_BPM_SuperAdmin” assigned.

Business administrators have access to NWA but can only manage processes and tasks for which they have been authorized. This happens by defining a respective role or group as “Process Administrator” and “Task Administrator” in the Process Composer.

 

4) Run performance tests

This becomes more important the more volume and users you expect. Use tools such as JMeter to simulate load on the system.

Identify bottlenecks and check the system configuration. Performance tests should be performed on a hardware similar to the production system.

Also see the official BPM sizing guide.

 

5) Set up archiving

Without archiving, the system database will continue to grow and queries will take longer over time.

The best option is to set up an archiving job to regularly clean out old processes.

For more on archiving, see Process Data Archiving – Monitoring and Managing BPM Systems, Processes, and Tasks – SAP Library

 

Obviously, the points I mentioned do not cover all pre-requisites for a successful go-live. There are many more aspects such as NWDI transport, optimal system configuration, user management etc.

For customers having a support contract with SAP, consider to schedule a full health check service for SAP BPM.
Please contact your support contract representative for more details.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Jorge Huedo

    Hi Christian,

    Excellent article.

    About the performance test with jmeter, would it be possible to simulate human actions? For example, simulating a user receiving a webdynpro java task in their UWL, filling some information and approving it.

    Best regards.

    Jorge

    (0) 
    1. Christian Loos Post author

      Yes – you can call the task OData services (available from 7.31 SP09) via http in jmeter and thereby complete the task.

      If you have an older release you need to wrap the Java API as web service yourself and then call that from jmeter.

      (0) 

Leave a Reply