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.
