Managing integration artifacts across environments in WSO2 Micro Integrator

Chanaka Fernando
WSO2 Best Practices
3 min readJan 31, 2023

--

How to move integrations across Dev, UAT, and Production environments with WSO2 Micro Integrator

WSO2 Micro Integrator is the successor of WSO2’s open-source enterprise integration product stack which was called WSO2 ESB and WSO2 Enterprise Integrator (EI) in the past. It can be used to implement integrations across different applications and systems without modifying those applications for interoperability.

One of the common requirements in managing WSO2 Micro Integrator in an enterprise ecosystem is to manage multiple deployment environments such as development, testing, UAT, and production for various testing purposes. When we have several environments to manage, moving the implementations (called artifacts) across different environments is an important aspect of the overall software delivery process.

Micro integrator uses synapse DSL (XML based) to develop integrations. Synapse artifacts are deployed to the server as CAR (Composite Archive) files. When migrating these synapse artifacts through environments, we can use a parameter-based approach to define the dynamic variables that may change across environments. The figure below depicts how you can use parameterized values inside MI artifacts such as proxy services, APIs, data services and scheduled tasks and passing the environment specific values to these parameters via a properties file or via environment variables.

Figure: Migrate WSO2 MI artifacts across environments

The environment-specific values to these parameters can be injected through the below-mentioned approaches.

  • Using an environment variable
  • Using a file

More details on using these options can be found in the below-mentioned documentation link.

Using variables to inject parameters to synapse artifacts

In addition to these integrations, there are separate configuration files to store the product-specific configurations such as usernames, passwords, and URLs. These parameters can also be configured in an environment-specific manner. More details on this approach can be found in the below link.

Managing configurations across environments

Once the integrations are deployed to a given environment, you need to interact with these integrations to perform various tasks such as

  • User management
  • Role management
  • Monitor CAR files
  • List APIs, Proxies, and other artifacts

These management tasks can be done using the API Controller (apictl) tool that comes with the micro integrator product. You can find more details on using apictl from the link below.

Managing integrations with apictl

If you need to automate the entire process of deployment along with the testing and development, you can build a CICD pipeline using the capabilities provided by the WSO2 platform. The figure below depicts the flow of a typical CICD pipeline that you can build with the WSO2 Micro Integrator.

Figure: WSO2 Micro Integrator CICD pipeline flow

As depicted in the preceding figure, the integration developers will develop the integration code using a tool such as the Integration Studio (IDE) or VSCode plug-in. Then this code is committed to an SCM repository such as GitHub. The environment-specific configurations can be stored in a separate repository to inject dynamic values into the artifacts. Then there will be a deployment server such as Jenkins or CircleCI which will checkout the code and build the CAR files to deploy into the environments (MI servers). It can copy the required CAR files to the MI server along with any deployment configurations related to the environment. In addition to providing dynamic values through a configuration file, you can also provide these values through environment variables as well. After that, the Jenkins server will execute the test scripts to validate the deployed artifacts. These test scripts can also be stored in GitHub. If the testing is successful only, the CAR files will be deployed to the subsequent environment until the flow reaches the production environment. Running the test scripts in the production environment is optional.

More information on building a CICD pipeline for Micro Integrator can be found in the following link.

Building a CICD pipeline for Micro Integrator

That’s all for this tutorial.

--

--

Chanaka Fernando
WSO2 Best Practices

Writes about Microservices, APIs, and Integration. Author of “Designing Microservices Platforms with NATS” and "Solution Architecture Patterns for Enterprise"