Rolling Back Target Servers
If deployment to a target server fails and the target environment is in an inconsistent state, or a deployment is successful but the deployed assets are not working as expected, you can use
Deployer's roll back feature to undo the deployment. When you roll back a deployment,
Deployer rolls back the target server to the last checkpoint generated for the project. For more information about generating checkpoints, see
Generating a Checkpoint.
You can set Deployer to roll back target servers automatically or you can roll back target servers manually after deployment.
Deployer automatically rolls back target servers for runtime-based projects in these cases:
Deployment failed to a target group whose
Rollback All on Failure setting is
Yes (see
Creating Target Groups). If deployment to any server in such a target group fails,
Deployer automatically rolls back all servers in the target group.
Deployer automatically rolls back the target servers for repository-based projects when transactional deployment is enabled for the project and deployment fails. For more information about enabling transactional deployment, see
Creating a Project.
For runtime-based projects, you can roll back target servers manually at any time after deployment if you performed both of the following:
You set the
Rollback on Error project setting to
Manual.
You did not deploy to a target group whose
Rollback All on Failure setting is
Yes.
For repository-based projects, you can roll back target servers manually if you performed either of the following:
You enabled transactional deployment to create an automatic checkpoint through the
Enable Transactional Deployment parameter.
You generated a manual checkpoint for the project.
To roll back target servers manually
1. In the Deployment Candidates list, click 
in the Rollback column. Deployer displays the rollback report in the right-hand pane in the Deployment History area.
2. To display the rollback report, click 
next to Rollback in the Report Type column. The report is also available under the name project_name_auditReport_reportID.xml in the Integration Server_directory \instances\instance_name\packages\ WmDeployer\pub\projects\project_name\targets\deployment_map\reports folder, where project_name is the name of the project and deployment_map is the name of the deployment map. If you rolled back an IS & TN deployment set, the following apply:
If the
Activate After Deployment option for a package was set to
Inbound Only, the report will warn that the package is not present on the target
Integration Servers. You can ignore this warning.
If the deployment set included
webMethods files, the directory structure for those files remains in the
webMethods installation directory on the target servers. You can delete the directories manually.
If you deployed
Trading Networks document attributes, field definitions, binary types, or profile security data,
Deployer does not roll them back.
If you rolled back a ProcessModel deployment set, the rollback behavior varies, as follows:
For process models you deployed that were versions of existing process models on the target servers,
Deployer rolled back the deployed versions from the target servers.
For deployed process models that were new on the target servers,
Deployer disables the deployed process models but does not remove them from the target servers. However, Deployer removes the Integration Server assets from the target servers on rolling back a project with deployment sets that include IS assets for the process models. If a process instance for the rolled-back process model exists on a target server, this behavior could result in issues.
If you rolled back Universal Messaging assets, the rollback behavior is as follows:
Deployer will not roll back the assets if the port is already being used by another existing interface.
Deployer does not roll back nested security groups. For example, if group1 contains group2, the rollback will not restore the nested group2.