In Part 2, we produced the MDS-00054 error. In this final part of the blog, we will find a way to fix the error and recover all running instances from previous deployments.
Based on the knowledge from Part 1, we can divide the procedure of fixing our problem into four steps.
-- Deploy the composite
-- Fix running instances
-- Fix human workflow
-- Fix instance audit trails
Because of the MDS-00054 error, any attempt of redeploying the composite over the same version 1.0 will fail. We cannot underploy the composite either in EM (cannot see the composite anyway) or with WLST script because in doing so all running instances will be marked as aborted. The good news is that in Part 1, we have a back door access to MDS "deployed-composites.xml" file. If we remove the entry for our test composite from this file, SOAINFRA will treat our composite as if never existed. Then we can deploy our composte application as a brand new composite with version 1.0.
Here are the steps:
-- Change the user task implementation in our test composite back to Human Task 1 in JDeveloper. So that the composite is compatible with the running instances.
-- Download deployed-composites.xml file via MDS Explorer.
-- Record the SCA label as the bad label and scaEntityId as the bad sca entity ID from the deployed-composites.xml file. We will need them later in our steps. In our case:
Bad-Label = soa_8ac4edfb-ae15-4e93-a6e2-f62852460064
Bad-SCA-Entity-ID = 6
-- Remove the entry for our composite from the deployed-composites.xml file. In our case, it will become an empty xml file.
-- Delete the deployed-composites.xml file in MDS via MDS Explorer.
-- Upload the modified deployed-composites.xml file from our local drive to MDS. Your MDS should look like this:
-- Restart the server
The server should start up without the MDS-00054 error.
-- If your BPM project does not uses Proected Flex Fields, you can skip this step. Otherwise, you need to remove all rows related to your composite from WFATTRIBUTELABELUSAGE table.
-- Deploy our test composite as version 1.0. This time, the deployment should be successful.
-- Check out the deployed-composites.xml file again. There should be a new entry with a new SCA label created in this file. Record this label as the good label and the new scaEntityId as the good sca entity id. They will be used in later steps. In our case, the good label is
Good-Label = soa_be66f4a7-0142-477a-a653-b1c1c4f19bb6
Good-SCA-Entity-ID = 10001
-- Check in EM and you will be able to see our composite. But searching for instances of this composite yields no result.
-- Check in BPM Workspace and you will see there is no human tasks displayed either.
Now that we have our composite successfully deployed again. Let's see what we can do about our running instances.
From Part 1, we know that instance data is stored in SOAINFRA schema while the deployed composite meta data is stored in MDS. The only link between these two stores is the SCA label. In our situation, our instances are associated with an old SCA label (the Bad-Label) and our newly deployed composite has a new SCA label (the Good-Label). So it seems obvious that if we manage to change the Bad-Label in SOAINFRA into the Good-Label, we should be able to link the running instances to our newly deployed composite. So the following are the tables that we need to change.
-- BPM_CUBE_PROCESS table
This is the only table relevant to our concern that is changed due to our new deployment. It should look like this,
As you can see, there is a new row added to this table with the Good-Label from the latest deployment. It has the MIGRATIONSTATUS of LATEST. There is also a row with the LATEST as its MIGRATTIONSTATUS but with the Bad-Label. This is the row that is associated with our running instances (probably via PROCESSID column). We need to replace its Bad-Label with our Good-Label so that it is associated with our latest deployment. To do that, we can execute the following SQL statements
-- delete from BPM_CUBE_PROCESS where SCALABEL = 'Good-Label'
-- update bpm_cube_process set SCALABEL = 'Good_Label', compositedn = 'default/TestBpmProject4!1.0*good_label' where scalabel = 'Bad-Label'
-- Other instance tables
Now we need to fix a few other instance related tables in SOAINFRA.
-- update sca_flow_instance set composite_sca_entity_id = Good-SCA-Entity-ID where composite_sca_entity_id = Bad-SCA-Entity-ID
-- update SCA_FLOW_TO_CPST set composite_sca_entity_id = Good-SCA-Entity-ID where composite_sca_entity_id = Bad-SCA-Entity-ID
-- update cube_instance set composite_label='Good-Label' where composite_label='Bad-Label'
Now restart the server and you should be able to see your composite and the two instances. To complete our repair, we need to do the following steps.
-- Human Workflow table
-- update wftask set compositedn = 'default/TestBpmProject4!1.0*Good-Label' where compositedn = 'default/TestBpmProject4!1.0*Bad-Label'
-- Audit trail table
-- update bpm_audit_query set composite_dn = 'default/TestBpmProject4!1.0*Good_Label' where composite_dn like '%Bad_Label'
-- Other table
The table MDS_ATTRIBUTES also contains the Bad-Label. I am not certain at this point how this table is used. Even if we leave the Bad-Label as is, it does not seem to have any impact to our runtime. But for completeness, we will make the following change as well.
-- update mds_attributes set att_value = 'dc/Good-Label' where att_value = 'dc/Bad-Label'
-- update mds_attributes set att_value = 'default/TestBpmProject4!1.0*Good-Label' where att_value = 'default/TestBpmProject4!1.0*Bad-Label'
At this point, all running instances should have been restored. They are accessible in EM and in BPM Workspace.