In Part 1, we looked into MDS and SOAINFRA tables to gain an understanding of data structure related to composite deployment and instance creation. At the end of Part 1, we can summarize, in the following, the key data pieces created in MDS and SOAINFRA due to deploying, redeploying our test composite and creating two composite instances.
-- SCA label: soa_8ac4edfb-ae15-4e93-a6e2-f62852460064, created for redeployment
-- Composite source under default folder
-- Two SCA labels:
-- soa_3663225e-43a8-4ded-bd58-7d3a95915c91, created for the first composite deployment, with a value of MIGRATED in MIGRATIONSTATUS column of the BPM_CUBE_PROCESS table
-- soa_8ac4edfb-ae15-4e93-a6e2-f62852460064, created for the redeployment, with a value of LATEST in MIGRATIONSTATUS column of the BPM_CUBE_PROCESS table
-- Two sets of data in the runtime tables for the two BPM instances created. Data set for instance 1 has the first SCA label and that for instance 2 has the second label.
With this background knowledge, we will try to trigger Bug# 20517579 and thus the MDS 00054 error. We will then check for any changes in MDS and SOAINFRA tables.
Bug# 20517579 exists in the SOAINFRA layer of the Oracle SOA Suite products. It is triggered in 12.1.3 (or earlier version) by a composite deployment failure. Let's say the current active version of your composite is 1.0. For some reason (bug fix for example), you have to redeploy the same composite with the same verion 1.0 (rather than 1.1). If the redeployment fails, Bug# 20517579 causes all MDS artifacts related to version 1.0 to be deleted. As a result, after you restart server, you will get an MDS 00054 error and the previously active composite version 1.0 disappears from the server along with all of its human tasks.
There are many ways to cause the redeployment failure. In BPM, we have seen for a few times this failure caused by incompatible changes made in BPM processes. It is quite easy to make this error when you modify a BPM process. So we will make an incompatible change in our test process to trigger the bug.
To do that, we will change the implementation of our user task from Human Task 1 to Human Task 2 as the following,
Now let's redeploy the composite. This time the deployment fails with the expected error:
Restart the server and you will get the MDS 00054 error:
By looking into the MDS data using the MDS Explorer, you will see the SCA label is still in the deployed-composite.xml file. As a result, the composite is still deployed from the SOAINFRA point of view. When it tries to start up the composite, the SOAINFRA needs to access source files of the composite (composite.xml being one of the source files). But if you check the folder "default", you will see the source folder of the composite has disappeared as it is deleted mistakenly due to the bug.
As this point, you won't be able to see our test composite in EM and its related human tasks in Workspace.
If you check the tables mentioned in Part 1, you will see nothing has changed in any of the tables. This indicates to us that even though we can access our running instances in EM and Workspace, they are still intact in the DB store.
In Part 3 (last part) of this blog, we will look at a way to restore the composite and its existing instances.