The management of SOA composite revisions has been simplified to a check box and a number through FlexDeploy’s SOA plugin.  Managing composite revisions historically required someone to develop and maintain a secondary process to purge unwanted revisions. Not anymore.

Now just deploy your composite and let the FlexDeploy SOA plugin manage the revisions for you.  Simply check the “Activate Purge On Deploy” input on the deploy operation, set the “Composite Revisions To Keep” property by environment and deploy.  Once the composite is successfully deployed, the deploy operation will automatically purge any unwanted revisions based on the property value.

Candidate revisions for purge are determined based on the default revision and the environment property.  The default revision is found and then the next oldest revisions are kept until the property value is met (this includes the default revision).  For example, setting “Composite Revisions To Keep” to 3 in DEV and 2 in QA would have the following results (bold indicates the default revision):

Revison Ex. DEV Action Revision Ex. 2 QA Action
1.01 purged 1.01 purged
1.02 purged 1.02 kept due to revision count of 2 and property count of 2
1.03 kept due to revision count of 3 and property count of 3 1.03 kept due to revision count of 1 and property count of 2
1.04 kept due to revision count of 2 and property count of 3 1.04 kept due to newer revision than the default revision
1.05 kept due to revision count of 1 and property count of 3 1.05 kept due to newer revision than the default revision

If you want to see what revisions are candidates for purging without actually purging, there is check box “Preview Mode For Purge” input on the deploy operation.  In this mode, the composite name and all revisions that are candidates to be purged are placed in the FlexDeploy execution logs.  No purge of a revision occurs.

There is another option “Stop On Purge Failure” on the deploy operation that will fail the deploy workflow if checked.  Otherwise a purge failure is just logged.

For those that prefer to run purges at a scheduled interval, there is a new purge operation on the SOA plugin that can be scheduled through FlexDeploy and operates in the same manner as mentioned above.  The only exception is that all partitions/folders are checked and all composite revisions are evaluated for purge.  The purge operation is perfectly suited for use in a FlexDeploy utility project.

Purging of composite revisions will never remove all revisions from the server.  If you need to remove all revisions of a composite from a server, use the undeploy operation on the SOA plugin.  This operation will take a composite name and an optional partition name, in case the same composite is deployed to multiple partitions/folders.  The undeploy operation is perfectly suited for use in a FlexDeploy utility project.

Dan Reynebeau

I have been working with Oracle and IBM integration technologies, along with custom development, for over 20 years providing solutions to the customer. While working with the different platforms, I have developed deployment scripts along with utilizing 3rd party deployment products to automate the deployment process. As a Principal architect at Flexagon I work with customers to enable DevOps/CI solutions using FlexDeploy, as well as primary development of FlexDeploy.

More posts by Dan Reynebeau

Leave a Reply

Your email address will not be published. Required fields are marked *