IBM BPM DevOps practices
Applying CI/CD to BPM projects using Azure pipeline
Co-Author: M.Fadin
Continuous Delivery is a well-known DevOps practice to build, test, deploy application changes in an incremental fashion to multiple environments all the way to production, at any point of time. Having said that, Organizations usually tends to unify their application deployment processes to achieve that. However, when it comes to IBM BPM — the famous business process management platform for enterprises by IBM — Organizations often think that it’s not integrate-able with the available DevOps solutions like Jenkins, UrbanCode Deploy, Azure DevOps, etc. This might be due to the fact that IBM BPM/BAW has its own built-in tools to support the BPM development lifecycle like:
- Source Code Management
- Version control and team management
- Automatic Build
- Automatic deployment through online deployment or offline
- Release management by activating the governance process
In this tutorial we will demonstrate how you can automate your IBM BPM integration and deployment activities into Microsoft Azure DevOps Pipeline.
Continuous Integration:
During a typical IBM BPM project, developers spend most of their time in the Process Designer authoring environments against a current version of an application which is contained in the tip (for example, the “head” revision).
To implement a continuous integration effectively, the development team must adopt an automated practice of pulling multiple snapshots (for example, the “label” revision) then installing or deploying those snapshots to the Process Server, and run tests against them.
When testing from the “tip” while a development is in-progress, which often result in an unstable version; full of missing and unstitched pieces — not to mention, uncaught bugs as well. A common solution to this problem would be to cut a snapshot at a specific time manually or automatically using DevOps tools, then pushed to the Dev/Test Process Server environment.
In the end, Continuous Delivery can sometimes be seen as a challenge for many organizations, due to the much changes it brings, and the “will” to accept. This is why we always advise clients to jump into the DevOps journey with a parachute by thoroughly understanding your challenges and slowly adopting automation and DevOps practices.
A more regular cadence of bi-weekly or monthly can be established. However, even this approach can be a challenge in some organizations.
Triggering BPM Commands using Azure DevOps Pipeline:
Despite not having an out-of-the-box integration between Azure DevOps and IBM BPM, we can still achieve an acceptable automation leveraging the power of scripting and Jython language. “WSAdmin” command line tool, allows you to trigger an external bash script file using the flag “-f”. From past experience, having an atomic job/script for a specific purpose works best when it comes to scripts maintainability and pipeline view. E.g. Create Snapshot, Install Offline Snapshot, etc
Does this applies for other DevOps tools as well?
Definitely! we usually recommend clients to establish their automation workflows using IBM UrbanCode Deploy due to the fact that UrbanCode Deploy offers out-of-the box plugins to integrate with IBM BPM. Nonetheless, automation can be achieved as long as the solution you’re trying to automate offers APIs for integration (API First Design).
Command Line:
wsadmin.sh -conntype SOAP -f /azure-scripts/createSnapshot.py -port 8880 -host ${BPMDevServer} -user $(bpmUsername) -password $(bpmPassword) -lang jython $(snapshotName)As you can see from the command line above, once the “wsadmin” connection via SOAP is established with the ProcessCenter Server, the “CreateSnapshot.py” script will gets triggered.
Script file content example:
Once you have successfully built your Jython scripts, the next step is to start to populate the commands and the environment properties in Azure DevOps Pipeline as depicted below image:
Notice in our example above, that we have a Job called “CP4Automation” (you can call it “Passport Renew Flow App” for example) , which was created in our Azure Pipeline, along with the list of steps related to the job, like “Create a Snapshot” and its respective commands that will only trigger the “CreateSnapshot.py” script.
Once the job is triggered either manually or via code commit, Azure Pipeline will trigger the job as depicted in the image below:
Finally, today we have demonstrated a single job automation to create a workflow snapshot and install it on an Online Process Server. However, IBM BPM offers a list of tasks that will allow you to fully automate and promote your BPM deployments:
- Create Generic Install Package
- Deactivate Snapshot
- Deploy Offline Package
- Deploy Process Application Snapshot
- Export Process Application
- Extract Migration Policy
- Generate Offline Package
- Import Process Application
- Install Process Application Snapshot
- Migrate Instances
- Set Default Snapshot
- Stop Snapshot
- Sync Values, Variables, and Team Bindings
- Update Installation Information
Sample tasks commands
- Use the BPMCreateSnapshot command in connected mode from Workflow Center to create snapshots for process applications or toolkits. You can run this command only on Workflow Center
wsadmin -conntype SOAP -port 8880 -host ProcessCenterServer01.mycompany.com -user admin -password admin -lang jythonwsadmin>AdminTask.BPMCreateSnapshot(“[-containerAcronym TPA -containerSnapshotName SS1 -containerSnapshotDescription ‘0824snapshot’]”)
- Use the BPMInstall command in connected mode from a Workflow Center server to install a process application snapshot on an online workflow server.
wsadmin -conntype SOAP -port 8880 -host ProcessCenterServer01.mycompany.com -user admin -password admin -lang jythonwsadmin>AdminTask.BPMInstall(‘[-containerAcronym BILLDISP -containerSnapshotAcronym SS2.0.1 -containerTrackAcronym Main -serverName ProcessServer01 -skipGovernance false]’)
- If you want to install a snapshot on an offline Workflow Server, use the BPMExtractOfflinePackage command in connected mode from a Workflow Center server to extract the installation package to a file. The extracted file can then be installed on the offline Workflow Server.
- Use this command to create an installation package for a process application snapshot on the Workflow Center server.
wsadmin -conntype SOAP -port 8880 -host ProcessCenterServer01.mycompany.com -user admin -password admin -lang jythonwsadmin>AdminTask.BPMCreateOfflinePackage(‘[-containerAcronym BILLDISP -containerSnapshotAcronym SS2.0.1 -containerTrackAcronym Main -serverName processServer315 -skipGovernance false]’)wsadmin>AdminTask.BPMExtractOfflinePackage(‘[-containerAcronym BILLDISP -containerSnapshotAcronym SS2.0.1 -containerTrackAcronym Main -serverName processServer315 -outputFile C:/myProcessApps/BILLDISP201.zip]’)
- Use the BPMInstallOfflinePackage command in connected mode from a workflow server to install a snapshot from a custom installation package on the workflow server.
wsadmin -conntype SOAP -port 8880 -host ProcessServer.mycompany.com -user admin -password admin -lang jythonwsadmin>AdminTask.BPMInstallOfflinePackage(‘[-inputFile C:/myProcessApps/BillingDispute.zip]’)
- Use the BPMExport command to exchange a process application or toolkit between Workflow Center servers. You must run the command in connected mode from a Workflow Center serve
wsadmin -conntype SOAP -port 8880 -host ProcessCenterServer01.mycompany.com -user admin -password admin -lang jythonwsadmin>AdminTask.BPMExport(‘[-containerAcronym BILLDISP -containerSnapshotAcronym SS2.0.1 -containerTrackAcronym Main -outputFile C:\processApps\BILLDISP201.twx]’)
