Top 5 things about IBM BPM on Cloud

Introduction

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.

Topology

The IBM BPM on Cloud default configuration comes with the following three IBM BPM environments, all using one database server:

Ø  One node with an IBM BPM Advanced Process Center

Ø  One node with an IBM BPM Advanced online connected test Process Server

Ø  Two nodes with an IBM BPM Advanced online connected production Process Server

Ø  One IBM DB2 server, which hosts all databases for all environments

More environments can be provided on request from the IBM BPM on Cloud operational support team.

Environment specification

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 are migrating in-flight process instances to IBM BPM on Cloud.

ü  You are migrating artifacts to IBM BPM on Cloud that use the user_name attribute for external references like keys of external tables or LDAP lookups.

ü  You need one or more extra Process Servers for your IBM BPM on Cloud environment.

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 Bluemix network. This backup ensures that if a data center loses service, an instance can be recovered to a point at least 24 hours old.

Physical network implications (distance, bandwidth, speed, latency)

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:

ü  A complex coach requires retrieving a lot of data from an application database located in the corporate network. Then the response for a process app user request in the user interface is delayed until all the data is retrieved.

ü  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.

ü  FTP communications from IBM BPM on Cloud to the corporate network might have performance issues.

ü  An external IBM ECM server that is located in a remote data center might have performance issues.

Security

For security on IBM BPM on Cloud, you need to consider user authentication and authorization, user and group management, and VPN access.

User authentication and authorization

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:

ü  Use a shared LDAP.

ü  Use a dedicated LDAP.

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.

User and group management

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.

Consider the following limitations of using the user administrative console for onboarding user accounts:

ü  The feature for inviting users currently does not work for dedicated LDAP.

ü  Until a user accepts the invitation to IBM BPM on Cloud, no additional configuration for the user is possible (for example, adding the user to a role). An administrator does not get notified when the user accepts the invitation.

ü  The user name of a user from the Dedicated LDAP is not visible in the IBM BPM on Cloud user administrative console.

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:

ü  User updates are not supported. Instead, you must use Delete and Create.

ü  The password cannot be set for users that are not configured with SSO.

ü  User creation is not supported for a dedicated LDAP configuration.

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:

ü  Users that are created with the SCIM API are not synchronized with IBM BPM on Cloud. If you need to add users to a group or modify user attributes, use the IBM BPM REST API to synchronize the user. For example, adding a user to a group through the IBM BPM REST API works. But adding a user to a group through the JavaScript API does not work.

ü  By default, users that are created with the SCIM API are granted a non-admin access to RUN only (the production environment). Because the same dedicated LDAP is used for all environments, you can still affect the user account through the API. However, before the user can log in to a non-production environment, you must manually modify the user access permissions in the IBM BPM on Cloud user administrative console.

The following capabilities are not available in IBM BPM on Cloud V8.5.7:

ü  For users that are not configured with SSO, the password cannot be set or changed by using the REST API.

ü  There are no tools for the bulk import of user and groups.

ü  There are no tools to migrate user attributes.

ü  There are no tools to migrate saved searches.

ü  There are no tools to synchronize users and groups between on-premises IBM BPM and IBM BPM on Cloud.

Assets and tools might be available with services engagements.

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:

ü  An application has services that are exposed to tw_allusers.

ü  An application uses external groups that change frequently.

ü  An application uses custom user registries.

ü  An application has a very large user pool.

VPN access

VPN access is required for any communication from IBM BPM on Cloud to a corporate network. If you plan to host data on IBM Bluemix or a private cloud, use a VPN for security, between IBM BPM on Cloud and IBM Bluemix (the private cloud).

Administration and operations

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.

WebSphere Application Server administration

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 IBM BPM 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:

ü  You can't use the Data Sources option to specify connection pool properties.

ü  The Certificates option imports the certificate from a URL. If the certificate is chained, only the top certificate is imported.

Contact IBM BPM on Cloud operational support team if you are requesting any additional environment configuration change requests.

DevOps processes

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.

Deployment

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.

IT and application monitoring

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.

Process monitoring

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.

User environments (client-managed and IBM-managed)

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.

Platform health management

IBM BPM on Cloud capabilities for platform health management are increasing, with enhancements added in cumulative fix packs.

Application design

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.

Access to the local file system

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?

Access to local operating system services

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.

A headless or external UI pattern

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.

Cloud application design patterns

Consider the following cloud application design patterns with IBM BPM on Cloud.

UI chattiness

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.

Claim check and process data variables

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.

General considerations

If you use a shared LDAP, you refactor any application code that directly accesses user_id, user_name, or user custom attributes.

Application data and integration

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.

Third-party systems

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 Bluemix, send the calls over SSL or VPN. VPN is mandatory to access any resources in your company network.

Client systems

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).

Web services and Application Integration services

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:

ü  For inter-module communications, use a Service Component Architecture (SCA) import instead of web services.

ü  To call modules that run on the same server in the cloud, use Advanced Integration services instead of web services.

Pay attention to the following implications for migrating to IBM BPM on Cloud:

ü  You might need to change existing web services and REST clients.

ü  You must plan a major redesign or even consider not moving apps (especially IBM BPM Advanced apps) that have external clients that use non-HTTP or non-HTTPS protocols.

ü  You might need to refactor existing external REST/SOAP clients.

IBM BPM database options

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:

ü  Before you move to IBM BPM on Cloud, put your custom tables into a separate database (system of record).

ü  Before you move to IBM BPM on Cloud, remove queries to IBM BPM database tables. Use IBM BPM APIs to retrieve information about IBM BPM objects. If there are no APIs available for a specific purpose, contact the IBM BPM on Cloud operational support team for assistance.

These considerations also apply when the source IBM BPM database is not DB2.

System of record

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 Bluemix:

Purchase an IBM Bluemix 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 Bluemix offering in the Cloud on bare metal.

ü  IBM DB2 on Cloud:

ü  NoSQL databases service on IBM Bluemix:

ü  IBM WebSphere Application Server on Cloud:

ü  DevOps:

Application migration

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. You can use the IBM BPM Project Analyzer tool at https://wombat.mybluemix.net.

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:

ü  SQL access to internal IBM BPM tables.

ü  Collocation of application objects and the IBM BPM database.

ü  Modification of enterprise archive files that are included with the IBM BPM product.

ü  Altered content of internal IBM BPM tables, such as tables related to saved searches.

ü  Direct use of an internal object's attributes, such as user. (Instead, access the object's attributes through IBM BPM APIs.)

ü  Hardcoded service end-points.

Artifact-only migration

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.

Artifact and data migration

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.

Conclusion

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 IBM BPM on Cloud. Provide feedback about your findings and experiences by adding comments to this article.

Download

S. No	File Name	Size	Download
1	Top 5 things about IBM BPM on Cloud.pdf	600 KB	Download