Debugging Deployer's Workbench errors while exporting to server

Resolving The Problem

If Deployer's Workbench fails to export the promotion scope to the server, analyze the .log file located in the DeployersWorkbench\DeployersWorkbench\<workspace>\.metadata directory to understand the reason for the failure.

If it's an Out Of Memory exception from the Deployer's Workbench environment (heap dump or java core dump files found in the DeployersWorkbench directory)
you can increase the maximum java heap size in the DeployersWorkbench.ini file. ( -Xmx1024m for example. )
Then try exporting again. If you continue to receive Out Of Memory exceptions even after increasing as high as possible, (Deployer's Workbench ships with a 32 bit JRE so the heap will be limited to under 2g) then try modifying just one promotion scope at a time prior to exporting.
A smaller amount of changes will require less memory to export.


When debugging Deployer's Workbench, it is helpful to set the Logging property.
Window-->Preference-->Deployer's Workbench-->Logging check the "Log all information logging calls." box.


Also check the SCCD WebSphere logs for clues.

The promotion scope resides in the SCCD database table CITEMPLATE. The following SQL can be used to show the promotion scope as it exists on the server:

select c1.classificationid as actciclassid, c2.classificationid as ciclassid,
c3.classificationid as topactciclassid, c4.classificationid as topciclassid
from maximo.citemplate t, maximo.classstructure c1, maximo.classstructure c2, maximo.classstructure c3, maximo.classstructure c4
where t.actciclassid=c1.classstructureid and t.ciclassid=c2.classstructureid
and t.topactciclassid=c3.classstructureid and t.topciclassid=c4.classstructureid
order by c1.classificationid

View the SQL output, look for things such as Authorized CI classes mapped to unexpected Actual CI classes or multiple Authorized CI classes mapped to the same Actual CI classification (this is valid but make sure it's what you expected), or multiple Actual CI classes mapped to one Authorized CI classification (again, valid to do so but make sure it's as you want.)
If you find unexpected issues on the server you may have to fix them from the server side but validate that the scope being exported by Deployer's Workbench was not the cause of this. If so, fix the Deployer's Workbench promotion scope.

Although Deployer's Workbench validates the model prior to exporting that is not a guarantee of success.
Model constraints and making sure the classes residing within a promotion scope can be reached via relationship rules are checked but the promotion scope is not compared with the state of the server. The server may be missing attributes or even classes from the Actual metadata which would cause exceptions when trying to create the Authorized metadata.