BPM, Workflow, and Case

IBM BAW provides a comprehensive source control ability using Workflow center. Using Workflow center and process admin, this provides the ability to manage and govern a process during its lifecycle from development, deploying to staging environments and production. As well, they provides the ability to manage and maintains the environment at production.

Using REST APIs the same operations can be performed. Those APIs can be used by different CI/CD tools to provide the ability to increase the automation and adoption of the platform across an organization.

The intention of this blog is to provide an example of how to use the APIs. As well, an explore the different APIs and possible scenarios where they can be used.

The lifecycle of a process:

A typical process application lifecycle usually goes through key step:

• A developer creating a process and developing key components
• A developer creates a snapshot once a component is developed
• The process is tested locally on Process Center
• Promoting the process app to a higher environment for testing purposes
• Promoting to production once testing is performed. This can be online or offline. Online is when the production environment is listed as one of the environments managed by the Workflow Center. The offline deployment is when process app is required to be exported to be installed on a remote production environment.

As the adoption of IBM BAW matures and more process apps are developed, it becomes important to automate the administrative operations of managing the processes. Using the REST APIs provides the ability to achieve the automation required.

In the sample below, 2 methods were used to go through the example, Using SoapUI and Swagger UI. This demonstrates different options for the DevOps teams to explore the REST APIs.

To be able to interact with the Workflow engine using the REST API, it is required to log in to the environment. This retrieves a token that would be used in all consecutive calls.

• Login to the system using an authorized user and obtain the BPMCSRFToken
  • Using SOAP UI, create a new project and provide a URI to your environment. For example: https://localhost:9443
  • Use the following Resource path, /ops/system/login
  • In the Request properties section, provide the username and password. The user should have administrative privileges to be able to perform the required operations
  • Use the POST method
  • Login_request parameter is required. This provides the number of seconds the token is valid for
  • Below is an example

• The operation returns the BPMCSRFToken. This token will be used by the rest of the operations.
• List all the applications deployed to validate the token and interact with the APIs
  • Create another method to call /ops/std/bpm/containers
  • There is no need to provide a username and password for this call
  • Use the token from the previous step as a header parameter called BPMCSRFToken
  • Use a GET method as shown in the example below

• Create a new snapshot
  • We can create a new snapshot or use an old snapshot to be exported
  • In this example, we created a sample process to demonstrate the ability to create a snapshot. The process initially doesn’t have any snapshots created

• Using the version APIs, we can create a new snapshot using the example below
• The CSRF Token should be provided as part of the header
• A version details parameter is required
• One point to keep in mind, is that the URI includes the acronym of the process. In this example its ‘SP’ as shown in the example below.

• You can validate that a new snapshot is created using the Process Center as shown below

At this stage, we have a process and a snapshot that are ready to be installed. In the second part of the example, we will be using the Swagger UI to demonstrate another approach to interact and test the REST APIs.

The product provides a list of all the available REST API using the Swagger UI which can be accessed using the following URL:

            https://<server_IP>:<port_Number>/bpm/explorer

Once logged in using a user with tw_admins right, this will display the bpm/docs URI. This will show the operations allowed to be performed to a process. Since we are looking to perform changes at an operational level then change that to ops/docs. This is shown in the example below

Changing to ops/docs URI

This lists all the operations allowed for this user to perform on the platform. As shown, it represents all the operational aspects of the platform.

Continuing with the scenario, we can demonstrate exporting the deployable package of the process. This would support the process for installing the application offline.

• Exporting installation package
  • Go to the version section, and select the GET method called /std/bpm/containers/{container}/versions/{version}/install_package
  • This function would require the acronyms of the process application and the snapshot. Once the parameters are provided, click ‘try it out’ as shown below

• Swagger UI provides the Curl command that can be used to execute this operation. This can be useful to build the CI/CD pipelines and any automation around that.
• The response provides the .zip file with the installation packages

• Install the package to an offline server
  • This can be performed using the install REST API of the offline server
  • After logging in to the new server and capturing the token
  • Call the install REST API under ‘Container’ section as shown in the example below
  • The install REST API can be used to import a process to Workflow Center or install a deployable package to a Process Server.

• The install method is asynchronous. The response to the POST method provides you with a queue ID to check the status of the installation. The queue ID can be shown in the response below.

• To validate the process is installed successfully

 under ‘System’ a REST API called /system/queue/{id}

• Using the REST API and providing the queue id as highlighted in the previous step. It should return the status of the application

This scenario demonstrated the ability to interact with the REST API through different tools to implement a typical lifecycle of the process. There are other APIs and other process application lifecycles that can be explored.

 

One of the most important elements of a DevOps project is making sure exceptions are handled. Every REST API provides the different possible outcomes and errors. It is imperative that an exception handling mechanism is implemented to recover an environment to a maintainable state. For example, installing a process application and then an error occurs during activation. The operator needs to decide on the nature of the error and whether it would require trying to activate or uninstall the entire process. The example below shows the error code 500 during activation. These errors would need inspection and determining the next best action to recover the environment.

 

The real benefit to deliver value on IBM BAW and improve the adoption of the platform is to combine both DevOps and automated testing capabilities at the same time. This provides the ability to accelerate the adoption and delivery of process applications.

Every organization that acquires IBM BAW goes through a journey to adopt the technology. During this journey there is always an expectation of continuous improvement on the key parameters of the delivery aspect of a process. This represents a key strain to the technical teams. It becomes a need to move the organization through a maturity model that responds to those challenges. CI/CD and automated testing are corner stones in responding to those challenges.