Use Extensions to deploy your process to different environments
The Boomi documentation states, “Use extensions to define configuration settings within a single process but specify different settings for each location when deploying that process to multiple environments”. Stated another way, you can use extensions to create one process that can be deployed to multiple environments like Development, Test, Stage, and Production. Extensions are the technique for defining the elements that vary from environment to environment like URLs, usernames, passwords, etc.
This article is intended for individuals who have a Boomi Associate Integration Developer Certification. If you do not know how to complete an action like “add a message shape,” please complete the recommended trainings.
The instructions below will walk you through how to use extensions to get user account information in UConn’s Kuali Build environments (stage, sandbox and production) based on the URL and an API token that varies by environment.
Creating the Process
Create a folder to keep the learning process organized. On the Start tab, click Build an Integration.
Configure the Start Shape with the No Data option and click Ok.
Connect it to a new HTTP Client Connection. Name it “UConn Kuali Build Client Connection”, and for the URL, type “***Set by Extension***” as a placeholder. Click Save and Close.
Create a new GET Operation named “Kuali Build Get a Single User Client Connector Operation”. Using the green plus sign in the Request Headers section, add a new header with the name of “Authorization” and the value of “***Set by Extension***”, and check “Is Replacement variable?”. In the Resource Path, add “api/v1/users/?username=” and “netid” on separate lines. In the netid object, check “Is Replacement variable?”. Click Save and Close.
On the build palette, click Extensions.
In the Connection drop down, select the UConn Kuali Build Client Connection. Click the checkmark for URL.
Click the Dynamic Process Properties tab at the top of the Extensions window, and add a new Extensible Dynamic Process Properties named “KB Token”. Click OK.
On the build palette, click Parameters in the HTTP Client Connector (yours may say 0 of 2 set).
Configure the netid to be a static value of a known netid. Set the Authorization parameter to the value of the ‘KB Token’ dynamic process property.
Make sure you add a Stop shape to the end of your process. It should look like this:
Click Test.
Select the Atom where you will test, then expand Test Extensions. Select the UConn Kuali Build Client Connector. Fill in the URL with one of the Kuali Build URLs.
Click the Dynamic Process Properties tab and enter the value of the Kuali Build Authorization token for the environment corresponding to the URL set in the previous step.
Confirm that the Stop shape’s Shape Source data contains a valid response with the specified user's information.
You are now ready to deploy the process and set the extensions at the environment level.
Deploying the Process
On the build pallet, click Create Packaged Component. Add a version and notes, then click Create Packaged Component.
Click Deploy.
Click Next: Select Versions.
Complete the deployment, then go to the Atom Management menu and select the environment where you just deployed the process. In the Administration section, click Environment Extensions.
On the Connection Settings, select the UConn Kuali Build Client Connection and fill in the URL for the Stage environment.
Go to Dynamic Process Properties and enter the value of the KB Token.
Execute a test run. After confirming the run is successful, return to the Packaged Components and deploy to a different environment.
Follow the steps to deploy to Production.
Once deployed, go to the Atom Management menu item again and select the Production attachment. Then, click Environment Extensions.
Repeat the steps to define extensions, but this time, use production values.
Execute a test in the Production environment, and then look at the process logs to confirm the call worked successfully against Product.