Safely undeploying unused asynchronous SOA CompositesPublished on: Author: Richard Velden Category: Oracle
When an Oracle SOA Suite application has been running for some time, it could get clogged up with many deployed composite revisions. Some might still be actively used, others could be undeployed. Undeploying all non-default SOA composite revisions might seem like a good idea. However, this does not take into account any long running, asynchronous processes. Image a new revision was made default a month ago, while previous versions are still actively running older requests. Plainly undeploying non-default revisions will not do.
In this blog, we will show you how to easily and safely clean up older composite revisions.
The problem with having many deployed composite revisions, is that it significantly increases server startup time. Starting WebLogic is rather quick compared to getting the SOA infrastructure ready. Especially when it contains 1000+ deployed composites. We have experienced startup times of more than an hour. To reduce the number of deployed composites, it is important to undeploy unused revisions. Whenever a new composite revision is deployed, we intend to run all new invocations of such a service using the new revision.
Some exceptions: for instance, when the new revision starts using a completely different async adapter to start the process. In this case, both revisions can and will be started independently.
In all other cases, we could in fact undeploy the older version, unless there are any running instances of course.
Hardly documented online, we have found an undeploy command in the WLST console which can help us:
- help('sca_undeployRetiredComposites')Undeploy all retired composites that don't have in-flight instances in a folder.
This command is able to undeploy retired composites and makes sure it only does so when there are no in-flight instances!
The solution is a three-step approach. First, we list all non-default composites. For this, we can use the WSLT command sca_listDeployedComposites
- sca_listDeployedComposites(host, port, user, password)
This command will give you a list of composite revisions, and whether they are active and default.
- XXComposite[3.0], partition=default, mode=active, state=on, isDefault=true, deployedTime=2019-02-02T00:00:00.000-00:00
- XXComposite[2.0], partition=default, mode=active, state=on, isDefault=false, deployedTime=2019-02-02T00:00:00.000-00:00
- XXComposite[1.0], partition=default, mode=active, state=on, isDefault=false, deployedTime=2019-02-02T00:00:00.000-00:00
- YYComposite[2.0], partition=default, mode=active, state=on, isDefault=true, deployedTime=2019-02-02T00:00:00.000-00:00
- YYComposite[1.0], partition=default, mode=active, state=on, isDefault=false, deployedTime=2019-02-02T00:00:00.000-00:00
Second, we only retire the composite revisions which are non-default (isDefault=false). For retiring, we can use the WSLT command: sca_retireComposite.
- sca_retireComposite(host, port, user, password, compositeName, revision, [label],[partition])
Finally, we can simply undeploy all retired composites. Please bear in mind the command needs to run for each partition that needs to be purged.
- sca_undeployRetiredComposites ( serverURL, user, password, folder)
sca_undeployRetiredComposites ( serverURL= "http://localhost:8001", user=”weblogic”, password=”welcome1”, folder=”default”)
It is very easy to use sca_undeployRetiredComposites to safely undeploy unused versions. If you use this command, no running instance will ever be lost, making it a safe way of getting rid of old SOA composites, even if you have a lot of long running processes.