Overview

In this blog post, I share an example of you can bring GitOps principals to a team that administers and manages Sterling B2Bi environments with focus on how it can integrate with IBM DevOps Deploy as a CI/CD pipeline to bring automation.   The goal is to allow for a single source of truth for configurations that are checked into a git repository.    When the committed changes make it to the main branch following a pull request or peer review, a process is initiated that will push the configuration changes into the Sterling B2Bi system automatically using IBM DevOps Deploy.

Benefits

The benefits of using this type of approach include:

·      You can lock down the Sterling B2Bi system as to avoid accidental configuration updates that could bring down a critical business system.

·      With a single source of truth, you can avoid multiple users accidentally updating configurations that can conflict with others.

·      Leveraging a git flow, you can easily track configuration changes in git and you have a great trail of audit for updates in IBM DevOps Deploy.

Let’s look at the prototype that we built in a proof of value to unlock these benefits.

Architecture of what we setup in the GitOps Prototype – Commit to Git Repository

The following diagram helps to describe the setup of the prototype we built for bringing GitOps to Sterling B2Bi:

For the prototype, we added support for two types of Sterling B2Bi objects:

·      Codelists

·      Business Processes

      NOTE: we can support other object types as well but we selected these two items for our prototype.

The configuration for the codelist or business process would be checked into a git repository.    You could setup the branching strategy of your choice with code reviews, pull requests, and more.   When the commit ultimately is merged back into the main branch, this is where the GitOps process then begins.

Here is an example of a codelist checked into a git repository (randy-code-list.csv):

ReceiverCode,SenderCode,Description,Text1,Text2,Text3,Text4,Text5,Text6,Text7,Text8,Text9

F0_01,9003,Partner 9003,xyz,,,,,,,,

F0_02,9005,Partner 9004,xwy,,,,,,,,

Here is an example of a business process checked into a git repository (randy.bpml):

<process name="CEDemo">

  <sequence name="MainSequence">

    <operation name="SampleOperation">

      <participant name="SampleParticipant"/>

      <participant name="SampleParticipant2"/>

      <participant name="SampleParticipant3"/>

      <participant name="SampleParticipant4"/>

      <output message="SampleOutputMessage"/>

      <input message="SampleInputMessage"/>

    </operation>

  </sequence>

</process>

In our prototype, we configured a GitHub Action that would collect the configuration and push the update of the business process or codelist to IBM DevOps Deploy using our IBM DevOps Deploy composite action available for GitHub.

The result of the GitHub Action that is run is that a new Component Version in IBM DevOps Deploy will be created that looks similar to this:

The version link that is created for you automatically (shown above) will allow you to see the differences or updates made to a business process in your Git repository:

Architecture of what we setup in the GitOps Prototype – Deployment Trigger and Process Types

Once the new component version comes in for a business process or a codelist, we configured an automatic trigger to deploy the updates to our DEV target environment as shown below:

NOTE: a similar approach can be used for upper environments as well using this strategy.

We setup processes that will allow you to:

·      Create a business process

·      Update an existing business process

·      Delete an existing business process

·      Create a codelist

·      Update an existing codelist

·      Delete an existing codelist

The process that is invoked can be configured to process the file and automatically determine the operation needed based on the git commit.

Architecture of what we setup in the GitOps Prototype – Example Sterling B2Bi Component Process in IBM DevOps Deploy

As we configure the automated process in IBM DevOps Deploy, I wanted to share an example of what a process looks like:

In this example, we download the codelist that was checked into the git repository.   We then check to see if the codelist already exists in the Sterling B2Bi system using a helper program our IBM Client Engineering team developed for the prototype which makes REST API calls to Sterling.   If the codelist does not exist, we then use the same helper program to make REST API calls to Sterling to create the new codelist from a CSV file.

To help with the verification of whether the codelist exists or not, we leverage a ‘Post Processing Script’ in IBM DevOps Deploy that will allow us to search for string patterns.   Here is an example:

NOTE: the same post processing script is used to verify the new codelist is created as well.

Architecture of what we setup in the GitOps Prototype – Example Results of a Deployment of Sterling B2Bi Configuration

Here is an example of what a deployment of the Sterling B2Bi configuration looks like when using this GitOps approach:

Notice in step 3, our check to see if the codelist already exists comes back and tells us that the codelist does not exist.   Therefore, we move the next step to create the new Sterling B2Bi codelist from the CSV file.

What is great about IBM DevOps Deploy is that you have excellent trail of audit for every deployment including the what, where, who, and how details of the deployment at the top and you can view the step logs for any steps to see the stdout or stderr of that step for triage or validation of the step working as expected.

Having automation like this allows our customers to lock down the Sterling B2Bi web console to help eliminate manual errors, mistakes in configurations that could impact the business, and bring consistency and automation to these configuration updates.   It also allows you to better track your changes to these configurations to ensure the system is working as you would expect.

After an update is made, you can always login to the Sterling B2Bi web console to validate the changes are pushed to the system as you expect:

Summary

Leveraging a GitOps approach for Sterling B2Bi configuration alongside a git repository of your choice with IBM DevOps Deploy brings many benefits to our customers including:

·      Version control and auditability – all configuration changes are stored in a git repository

·      Declarative Configuration – configurations are defined declaratively in git meaning the desired state of the system is explicity described.

·      Enhanced Collaboration – Git-based workflows, such as pull requests and peer reviews, enable seamless collaboration among development and operations teams fostering a shared understanding and ownership

·      Automation and Continous Deployment using IBM DevOps Deploy – GitOps integrates with CI/CD pipelines to automate the deployment of configuration changes and IBM DevOps Deploy is a leader in this space with customers using the solution all across the globe.

     I hope you found this blog helpful as an introduction.   If you would like to learn more, you can click here to book a live demo and see IBM DevOps Deploy in action.

    Special thanks to @Ed Ludke, @Roger Snook, and the IBM Client Engineering team for their assistance with this prototype.