Welcome to part 2 of the blog series covering the release of the FlexDeploy B2B Plugin. If you missed part 1 you can view it here.
In part 2 we are going to be taking a deep dive into the Agreement level build and deploy operations available in the B2B Plugin. The operations specific to Agreement level build and deploy within B2B environments are b2bExportAgreement and b2bImportAgreement. When the export/build of the Agreement is done, all of the dependencies for the exported Agreement will be bundled together to ensure you have one deployable object with no external dependencies. On the import/deploy step, the build artifact has an optional configuration file applied to it and it is then deployed to the target environment. In order to make use of these new operations a few things need to be configured first.
There are 3 environment instance properties required for each operation which are used to set the environment context as well as 1 project property which specifies the Agreement name to be built and deployed for the corresponding project.
- FDB2B_SERVER_HOST
- FDB2B_SERVER_PORT
- FD_ORACLE_SOA_HOME
- FDB2B_AGREEMENT_NAME
Let’s take a look at a few sample workflows of the operations. The b2bExportAgreement operation doesn’t require any inputs so it is as simple as dragging the operation into the workflow and you are good to go! As noted in part 1 of the series, a configuration file can be utilized to replace environment specific properties. As such, a configuration file is pulled in from Tortoise SVN, using our SVN plugin, on this build workflow as seen below.
Once this workflow is complete it will store the exported Agreement object and the configuration file into the Artifacts Repository. As mentioned above, the export will bring in the Agreement as well as all dependencies. One such dependency is the Listening Channel used by the Agreement. Below is a quick look at the Listening Channel that was exported.
Take note of the host name and folder name from the listening channel, as you will see in the configuration file below that those properties, along with the password, will be getting replaced on deploy.
Use:{Agreements}
AgreementsToUse:{MyCompany_To_GreenBayPackers_Custom}
ListsToUse:{PartnerProtocol}
MyCompanyName:MyCompany
MyCompany_To_GreenBayPackers_Custom:PartnerProtocol|ftp-param-host:prodserver
MyCompany_To_GreenBayPackers_Custom:PartnerProtocol|ftp-param-folder:prodfolder
MyCompany_To_GreenBayPackers_Custom:PartnerProtocol|ftp-param-password:welcome1
It should be noted that multiple configuration files would be more than likely be used for an Agreement due to the fact that the configuration files replace environment specific properties and multiple B2B environments would be deployment targets.
The Deploy workflow only has one activity, the b2bImportAgreement operation, but it has a few inputs that we have to define.
FDB2B_INP_CONFIG_FILE is the config file name to use, which at this point is assumed to exist in the Artifacts Repository, and it does because we brought it in from SVN on our build. The next input, FDB2B_INP_ACTIVATE_AGRMT is to determine if the Agreement should be activated on deployment or just remain inactive in the B2B repository. The last input, FDB2B_INP_OVERWRITE_DATA, is to determine if any conflicting data should be overwritten on this deployment.
After deployment we can see that the Agreement is now deployed in our new B2B environment and its Listening Channel properties are up to date with what we had specified in the configuration file.
What we saw in part 2 was the ability to build and deploy at the Agreement level within Oracle B2B, in part 3 we are going to take a look at the operations to be used when build and deployment at the Trading Partner level may be more desired. See you next time!
