Sometimes, when deploying a BPM composite, the deployment times out. When a BPM composite deployment fails in this way, it does not clean up after itself. It leaves several records in the database. If one attempts to deploy the same revision, it will also fail. A common workaround is to restart the managed servers, increment the version number, and attempt the deploy again.
While the workaround does work, the remnants of the bad deploy will result in the flex field headers not displaying correctly in the workspace.
When the headers display incorrectly, one can find an error similar to the following in the log files:
exception.name: Could not locate composite.
exception.description: Could not locate composite for workflow component
exception.fix: Ensure composite has been successfully deployed, and that the
SOA server has completed loading composites.
The log message indicates the partition, composite, revision, and task is causing the issue.
Correcting the Problem
To correct the issue, execute the following SQL statements in the SOAINFRA schema for the affected domain. Be sure you enter the correct partition, composite name, and revision number:
delete from wftaskmetadata where id like '%compositeName!revisionNumber/%';
delete from wfattributelabelusage where workflowid like 'partition/compositeName!revisionNumber/%';
update bpm_cube_process set status = -1, undeploydate=sysdate where compositedn like 'partition/compositeName!revisionNumber*%';
An example usage [partition: default, compositeName: SampleProcess, revisionNumber: 4]:
delete from wftaskmetadata where id like '%SampleProcess!4/%';
delete from wfattributelabelusage where workflowid like 'default/SampleProcess!4/%';
update bpm_cube_process set status = -1, undeploydate=sysdate where compositedn like 'default/SampleProcess!4*%';
After executing the SQL statements, restart the servers, and the issue will be corrected.