IBM and Red Hat — the next chapter of open innovation. Learn more ›
Slava Zheltonogov, Werner Tod, Mike Zilbergleyt, Jean Pommier | Published April 25, 2017
Moving your business process management solutions to IBM® Business Process Manager (BPM) on Cloud introduces some special considerations. For a successful transition, pay attention to five areas when you plan and implement a move to IBM BPM on Cloud: topology, security, administration and operations, application design, and application data and integration.
IBM BPM on Cloud is a software-as-a-service offering that is still undergoing enhancements and development changes. This article is updated regularly as new capabilities are added and existing capabilities are improved.
This article is not an exhaustive list of all the details you need to consider when you implement and deploy process applications on IBM BPM on Cloud. Use it as a checklist of important topics for IBM BPM on Cloud, based on implementations and deployments and experience from the authors.
If you are new to IBM BPM on Cloud, watch the following video for a brief introduction: Welcome to IBM Business Process Manager on Cloud.
The IBM BPM on Cloud default configuration comes with the following three IBM BPM environments, all using one database server:
More environments can be provided on request from the IBM BPM on Cloud operational support team.
The following illustration shows a logical component architecture diagram of the topology of IBM BPM on Cloud:
Use a dedicated Lightweight Directory Access Protocol (LDAP) only in the following scenarios:
You can download the Process Designer and Integration Designer components from the IBM BPM on Cloud user portal at www.bpm.ibmcloud.com. The default configuration of IBM BPM on Cloud prevents the Process Designer Inspector component from connecting to test and production environments. The IBM BPM on Cloud operational support team can change this configuration if you request it.
The TWUser.name default configuration for IBM BPM on Cloud returns users email addresses. See the Security section for a detailed discussion of IBM BPM on Cloud user management.
Each instance of IBM BPM on Cloud is backed up every 24 hours to an encrypted EVault that is at a different data center on the IBM Cloud network. This backup ensures that if a data center loses service, an instance can be recovered to a point at least 24 hours old.
Moving your business application to the cloud means that it is no longer running inside your corporate network. IBM IBM BPM on Cloud has several data centers to choose from when you create your environment. All IBM BPM servers for a single environment are located in the same data center.
When you select your data center, consider the distance between the IBM BPM on Cloud data center, your largest user base, your developer base, and any other resources that your application uses.
The following high-level architecture diagram shows the connectivity types between parts of an IBM BPM on Cloud environment:
Evaluate application performance based on the new network topology. Keep in mind that all HTTP traffic between web browsers and Process Designer must go over Secure Sockets Layer (SSL) and a wide area network (WAN). All communications from IBM BPM on Cloud to your corporate network must go over a virtual private network (VPN). The network latency that is introduced by communication between data centers might significantly slow overall application performance.
Depending on your network set up, traffic over the inbound VPN connections might require specific routing and more network hops. For example, you might need all VPN communications to go through a specific data center in the corporate network. The calls from the process app users web browsers that are running inside the corporate network into IBM BPM on Cloud and the calls from IBM BPM on Cloud into the corporate network over VPN then take different routes, affecting end-to-end application performance.
Consider the following known application patterns that can suffer from performance degradation when running on IBM BPM on Cloud:
If you extend the approach of collecting all data necessary to support the coaches, the same delay might become significant when a series of sequential calls to the back-end systems are made inside the human service.
This issue might affect heritage coaches that retrieve data on the server side and responsive coaches that use Ajax services to retrieve data. Although Ajax services are run in parallel, the request and response round trip must travel the WAN multiple times: from the web browser to IBM BPM on Cloud, from IBM BPM on Cloud to the corporate network, and from IBM BPM on Cloud back to the web browser.
For security on IBM BPM on Cloud, you need to consider user authentication and authorization, user and group management, and VPN access.
IBM BPM on Cloud uses an internal user registry for authentication and authorization. You can configure the user registry in one of the following ways:
In both cases, the shared LDAP (shared between all IBM BPM on Cloud users) authenticates and authorizes an IBM BPM on Cloud environment. The email address, or the SAML token if you enable single sign-on (SSO), is the identity for authentication and authorization. From an SSO perspective, IBM BPM on Cloud integrates with third-party SSO services, such as Okta, through Security Assertion Markup Language (SAML).
If you use the dedicated LDAP configuration, the identity is mapped from the shared to the dedicated LDAP. Without the dedicated LDAP configuration, the user ID (mapped to TWUser.name) is the email address of the registered user. With the dedicated LDAP setup, you can preserve user IDs from your IBM BPM on-premises environment.
Neither the shared or the dedicated LDAP allow creating user groups in the IBM BPM on Cloud LDAP. You manage groups on the Process Admin Console of the Process Center of IBM BPM on Cloud.
Consider the following implications for application architecture and design:
Therefore, for example, a “headless” IBM BPM pattern cannot rely on SSO if you use REST API calls to IBM BPM on Cloud.
In the shared LDAP environment, you can manage user accounts with both the IBM BPM on Cloud user administrative console and the user-provisioning REST API.
You open the IBM BPM on Cloud user administrative console by clicking Admin > User Management.
For information on inviting and managing users through the user administrative console, see the Getting started with IBM BPM on Cloud topic in the IBM BPM documentation.
Consider the following limitations of using the user administrative console for onboarding user accounts:
In addition to the IBM BPM on Cloud user administrative console, you can manage users with REST APIs. See IBM Business Process Manager on Cloud user provisioning REST API in the IBM BPM on Cloud documentation.
For the shared LDAP configuration, you can use SCIM and user provisioning REST APIs.
As of IBM BPM on Cloud V8.5.7, the user provisioning API has more features.
Consider the following limitations of the user provisioning REST API:
You can use the SCIM REST API v1.1 to create, modify, and delete users in IBM BPM on Cloud.
Consider the following limitations of the SCIM REST API v.1.1 implementation:
The following capabilities are not available in IBM BPM on Cloud V8.5.7:
If you need pivot tables to implement complex saved searches, IBM BPM on Cloud operational support team must create them.
The following application patterns are affected the most by the previously described limitations:
VPN access is required for any communication from IBM BPM on Cloud to a corporate network. If you plan to host data on IBM Cloud or a private cloud, use a VPN for security, between IBM BPM on Cloud and IBM Cloud (the private cloud).
Think about how administration and operations tasks work with IBM BPM on Cloud, including WebSphere Application Server administration and DevOps processes, such as deployment, monitoring, adding and configuring environments for the process app users, and platform health. Depending on the issue, you can get help from either IBM BPM on Cloud operational support team or the IBM BPM on Cloud technical support team.
Because IBM BPM on Cloud is a software-as-a-service offering, the administration features are limited to capabilities in the Operating Environment Management option of the Admin section of the Digital Business Automation on Cloud portal at www.bpm.ibmcloud.com. For the list of latest features, see the Managing operating environments topic in the IBM BPM on Cloud documentation.
Consider the following limitations:
Contact IBM BPM on Cloud operational support team if you are requesting any additional environment configuration change requests.
DevOps is an approach that promotes closer collaboration between lines of business, development, and IT operations teams. It enables the continuous delivery, continuous deployment, and continuous monitoring of applications. It reduces the time that is needed to address customer feedback. In the past, development, operations, and even test teams, often operated in silos. A DevOps approach brings the teams together to improve agility.
With IBM BPM on Cloud, you might be interested in the following DevOps processes.
The production Process Server environment is configured as an online connected Process Server.
Because your process application users cannot access the wsadmin tools, online deployment is the only option for IBM BPM on Cloud.
The default IBM BPM Process Designer and Inspector capabilities cannot connect to the test and production environments. Contact the IBM BPM on Cloud operational support team if you need to change the default behavior.
The IBM BPM on Cloud operational support team is responsible for IT-level monitoring for IBM BPM on Cloud.
Email alerts about critical system events are automatically sent to the users who are defined as administrators in the IBM BPM on Cloud user administrative console for an environment.
Business Process Model and Notation (BPMN) process monitoring through the IBM BPM Process Admin Console is no different from the on-premises IBM BPM.
However, external reporting is not supported in IBM BPM on Cloud. For example, you cannot use Cognos reports that read data from the IBM BPM Performance Data Warehouse database or the default IBM BPM capability that publishes events to IBM Business Monitor.
When you need instrumentation log recording to the file system, involve the IBM BPM on Cloud operational support team.
The Business Space capability does not work completely in IBM BPM on Cloud. Some of the monitoring features are limited.
Operating environment self-service management capabilities that available to administrator users of IBM BPM on Cloud process apps are rapidly expanding.
All other operations are completed by the IBM BPM on Cloud operational support team.
In general, when compared to on-premises IBM BPM, the experience for IBM BPM application developers and process participants is not different for IBM BPM on Cloud.
For more information, see Adding and configuring environments for users.
IBM BPM on Cloud capabilities for platform health management are increasing, with enhancements added in cumulative fix packs.
For the most recent information about health management, see Administering the health of databases in the IBM BPM documentation.
The IBM BPM on Cloud operational support team is a different organization than the IBM BPM on Cloud technical support team.
Because IBM BPM on Cloud is a software-as-a-service environment, the IBM BPM on Cloud operational support team handles the roles of WebSphere Application Server administrators, operating system administrators, and database administrators.
The IBM BPM on Cloud technical support team handles product defects. The technical support team does not have access to the IBM BPM on Cloud environment.
Ask the technical support team to copy the IBM BPM on Cloud operational support team on all communications that are related to IBM BPM on Cloud. Work with the operational support team: Gather information that is requested by the technical support team that is not exposed to the IBM BPM on Cloud users (for example, the version info output from an IBM BPM on Cloud environment).
Click How do I request support? on the Digital Business Automation on Cloud page FAQs.
When you design a process application, consider access to the local file system, access to local operating system services, headless and external IBM BPM patterns, and cloud application design patterns.
IBM BPM on Cloud supports storing temporary files only in the designated directories. Optionally, your environment can be configured with a dedicated mount point for large file storage.
If your applications rely on “permanent” files that are on the file system (for example, templates, property files or java libraries), consider storing them as IBM BPM application-managed files or WebSphere Application Server shared libraries. The IBM BPM on Cloud operational support team can help you set up shared libraries.
Do not attach large files like Java library files as IBM BPM application-managed files. These files can negatively affect the database input/output and the size and use of managed asset caches.
Also, consider the distributed nature of the IBM BPM topology that is related to application design. Does the topology rely on files that are permanently stored on the file system of the local server?
With IBM BPM on Cloud, you don’t have access to the operating system services for the IBM BPM server.
For example, you can’t use operating system scheduling, network communication, and security services.
If you move to IBM BPM on Cloud, you need to redesign any existing application functions that rely on those services.
The headless IBM BPM pattern uses REST services to communicate with IBM BPM applications, instead of a user interface. The REST service is authenticated with basic authentication.
Only your process app users whose passwords are managed by IBM BPM on Cloud can be authenticated with IBM BPM.
Because SSO in IBM BPM on Cloud is implemented through SAML federation, if you want to implement the REST client without the user interface, you have the following implementation choice: Use an admin user pattern where all REST API calls are made by the same system users.
Consider the following cloud application design patterns with IBM BPM on Cloud.
Consider the VPN tunnel as a mandatory requirement for integration from and to the Cloud hosted solution. It is essential to keep an eye on the traffic payload.
Keep number of outbound calls from any IBM BPM coach to a minimum. You can refactor the coach design or use a facade pattern or another relevant pattern for the services design.
A claim check pattern is highly encouraged for on-premises IBM BPM process applications to limit the amount of data (the execution context) passed through the various steps of the process. This pattern does not always deliver optimal process performance for IBM BPM on Cloud.
In IBM BPM on Cloud, every integration with system of record goes through the VPN tunnel. Each retrieval of the business process content affects performance.
Neither approach is ideal for a business situation. Make sure that solution architects carefully evaluate each option. Weigh the cost of retrieving content from a system of record on every step against the cost of carrying over the full execution context through the steps. Some prototyping and performance measuring can help you make the best choice for your situation.
If you use a shared LDAP, you refactor any application code that directly accesses user_id, user_name, or user custom attributes.
Finally, pay attention to application data and integration when you move to IBM BPM on Cloud. Consider third-party systems, client systems, web services and Advanced Integration services, IBM BPM database options, a system of record, and application migration.
You can integrate third-party systems with IBM BPM on Cloud.
However, consider network latency and security in your design. Keep in mind that all traffic from and to the cloud must be secured. When calls access other public resources, like services on IBM Cloud, send the calls over SSL or VPN. VPN is mandatory to access any resources in your company network.
With IBM BPM on Cloud V8.5.7, only REST and web services inbound protocols are available. You must use pre-emptive basic authentication for the requests.
Therefore, connections that use other protocols are not possible. For example, external clients cannot connect to IBM BPM SIBus through JMS or to IBM BPM databases through JDBC. Keep in mind that each IBM BPM on Cloud environment has a different URL context: /dev For the Process Center, /test for a test environment and /run for a production environment. You need to update clients that do not allow configuring the full URL (for example, if only host:port are configurable).
Outbound web services behavior is no different for IBM BPM onCloud. Depending on the target location, you might need the VPN connection information to establish the connection.
Inbound web services require a pre-emptive authentication if a user name is an email address outside of the SSO scheme.
Pay attention to the following considerations when you design with web services and Advanced Integration services:
Pay attention to the following implications for migrating to IBM BPM on Cloud:
IBM DB2 is the only option for the IBM BPM database in IBM BPM on Cloud. IBM BPM on Cloud applications must not access IBM BPM database tables.
Validate and refactor the following types of queries for IBM BPM on Cloud:
These considerations also apply when the source IBM BPM database is not DB2.
IBM BPM was never meant to be a system of record. In fact, creating application objects in the IBM BPM databases, for example by using stored procedures, custom data tables or views, is not permitted in the IBM BPM on Cloud environment.
You can choose from the following alternatives as a system of record to use with IBM BPM on Cloud:
A system of record in the corporate network:
Use a VPN. Analyze the effect on network latency. Use caching whenever possible.
A system of record on IBM Cloud:
Purchase an IBM Cloud server in the same data center as your IBM BPM on Cloud environment. Use a VPN. If the required provider is not available, you can implement it using an IBM Cloud offering on bare metal.
IBM Db2 Hosted:
Follow guidance at IBM DB2 on Cloud.
Databases on IBM Cloud:
Follow guidance for Cloudant on IBM Cloud.
IBM WebSphere Application Server on Cloud:
Follow guidance at IBM WebSphere Application Server on Cloud.
Follow guidance at DevOps with the IBM Cloud: From idea to production in minutes.
IBM BPM on Cloud uses the same code base as the on-premises IBM BPM.
Analyze the migrated applications for compliance with all IBM BPM on Cloud limitations and policies that are mentioned in this article.
Several unsupported practices that are implemented by organizations that use IBM BPM customers are not portable to IBM BPM on Cloud.
Avoid the following practices:
Artifact-only migration is a less risky migration option because you avoid moving runtime data from the source environment. For an artifact-only migration, thoroughly examine your process application code, based on the previously described specialties of IBM BPM on Cloud.
Look for any non-recommended practices in your organization’s code. In most cases, to ensure that the code continues to run on the cloud, you need to refactor (or potentially redesign) the components of the process applications.
This effort requires close examination of the existing application code and typically involves an IBM services team.
While the IBM BPM on Cloud development teams are diligently working on support for data migration, complete tools are not available for data migration to IBM BPM on Cloud V8.5.6 and V8.5.7. To implement this type of migration, you contact IBM Cloud Services.
The limitations for on-boarding IBM BPM on Cloud users significantly affect data migrations to IBM BPM on Cloud. Reach out to IBM Cloud Services to address this challenge.
To a large extent, IBM IBM BPM on Cloud is the same product as IBM BPM on-premises. As you consider hosting new process applications on IBM BPM on Cloud, and moving existing process applications to IBM BPM on Cloud, use this information to consider options and ensure the best possible process application performance and user experience.
Now you can start your own journey with Digital Business Automation on Cloud.
The authors would like to thank Erich Fussi, Feifan Chen, Gabriel Dermler, Jens Engelke, Monika-Lydia Dreiucker, Roland Peisl, Andreas Fried, Torsten Wilms, Brian Petrini, Jian Feng Cai, Bill Lawton, and Chris Richardson for their review and comments.
August 1, 2019
This article is an inspiration for DevOps teams looking to automate Kubernetes pod dependencies.
There are unique performance and resiliency engineering concerns for hybrid cloud software solutions that can lead to serious SLA issues,…
Back to top