In this post I am going to highlight some of the possibilities and flexibility of FlexDeploy by showcasing a custom Oracle B2B workflow configured with the Ant Plugin. There are a couple different approaches we can take in configuring this workflow. The first option is to use a source code management tool to maintain versioning as well as provide visibility to existing exported agreements or partners. The second option is to make use of FlexDeploy’s artifact repository feature to maintain versioning. We are going to cover the second approach in this post.
Before we dive in let’s make sure we have our prerequisites completed. We will need a build instance, and development instance defined. An agreement will already need to be setup on your build instance. Lastly you will need to be sure that the ant-b2b-util.xml file exists on the servers where your b2b console resides. This file is part of the default soa installation and is located here: ORACLE_HOME/soa/bin.
Here is a quick look at our B2B environment before we deploy. As you can see there are no trading partners, other than the default MyCompany, and no agreements.
Using the approach of FlexDeploy’s artifact repository to maintain the versioning, we will need to create 2 workflows. Let’s take a look at the first workflow called ExportAgreement.
Step 1: ExportAgreement
The purpose of this step is to export the agreement from our build instance. The build file will be the same throughout this exercise for all Ant steps. The run target is b2bexport in this step and the arguments include the trading partner agreement we want to export and the filename resulting from the export.
Step 2: SaveAgreement
This step saves the exported agreement to FlexDeploy’s artifact repository. The subfolder should be the file location where you exported the document in the previous step. The input file filter in this case is FD_PROJECT_NAME.zip. After this workflow executes the zip export will be archived in FlexDeploy and will be available to deploy to other environments.
The second flow, as you might have guessed, is for deploying the agreement to your target server. Consistent with the other flow, we can accomplish this in 2 short steps.
Step 1: copyAgreement
This step copies the agreement from the FlexDeploy artifact repository, which the previous step had saved. Input File Filter must match the name we saved in the very first step as part of the ant build parameters. The directory will be your base FlexDeploy directory and then any subdirectories specified when saving the Agreement.
Step 2: ImportAgreement
The final step is the ant script to import the copied agreement from earlier to the target server. The Ant build file is the same as the export step. Our run target is b2bimport in this case and our argument is the filename of the copied agreement from the previous step.
Now let’s take a look at what our project looks like in the project tab.
In this current configuration we have the project name the same as the agreement name in B2B. Doing this allows us to make use of the FD_PROJECT_NAME variable when exporting the agreement which is what allows this workflow to be reused for multiple agreements. Our Build Workflow is set to ExportAgreement and Deploy Workflow is set to DeployAgreement. The SCM configurations can be ignored as we showcased option 2 which doesn’t use SCM.
Note that this workflow is customized to export and deploy agreements. When an agreement is deployed to a new environment in this fashion, all dependencies for the agreement are deployed along with it including any relative documents, listening channels, partners etc. This is really where the benefit of using FlexDeploy comes into play. Setting up agreements through the B2B UI can be extremely time consuming, especially when setting it up across multiple environments.
Lastly, let’s take a quick look at the b2b environment where we deployed the agreement.
