As previously noted, it is sometimes desirable to customize the content of a revert Change Set.
To illustrate a scenario in which this would be necessary, assume that there can only be one active User entity in the system. This means that when a new User is applied to the system, the previously active User entity will become inactive and the current one will become active.
As an example, consider a Change Set containing a new Business Object User/X. Also, assume that in the database, there is already an active User Business Object instance, User/A. While applying the Change Set, the infrastructure creates a corresponding revert Change Set. This revert Change Set will contain a Delete instruction for the newly added User. Once the original Change Set is applied, User/X will be active, and User/A will be inactive.
Now, when applied, the revert Change Set should ideally de-activate User/X (as this was newly created through the Change Set) and re-activate User/A (as this was previously active). However, this will only be possible if the revert Change Set contains the following instructions:
While the revert Change Set will automatically contain the instruction User/X-Delete (as it has been newly created by applying the original Change Set), it will not contain the instruction User/A-Add. This is because this Business Object was not in the original Change Set, and is not directly related to the User/X Business Object in the original Change Set. So, the implementer of the BOMs for User has to identify the unrelated Business Object(s) (i.e. User-A in this case), and ensure that it is placed in the revert Change Set.
In order to provide this functionality, an implementation of curam.util.ctm.bom.RevertChangeSetConstructionHandlerBOM must be developed. This BOM requires an implementation of the constructBusinessObjectIdentifiers() method that returns the identifiers of unrelated Business Object that are required for revert purposes.
Note that there is no need for the implementation to specify the instruction type of the unrelated Business Object(s), because the infrastructure knows how to identify the instruction type for a given Business Object identifier
The code snippet below illustrates the implementation of the curam.util.ctm.bom.RevertChangeSetConstructionHandlerBOM 's constructBusinessObjectIdentifiers() for the User Business Object Type:
public final Set<BusinessObjectIdentifier>
constructBusinessObjectIdentifiers(
BusinessObjectIdentifier boIdentifier,
Document boDocument) {
Set<BusinessObjectIdentifier> boIdentifiers
= new HashSet<BusinessObjectIdentifier>();
BusinessObjectIdentifier activeBO
= getActiveBusinessObjectIdentifier();
if (activeBO!= null) {
// If the identified active Business Object is equal
// to the incoming Business Object identifier, then
// we should not have to include it, because this
// Business Object identifier would have
// already undergone processing by the framework.
if (!activeBO.equals(boIdentifier)) {
// Active Business Object exists in the
// database. This needs to be included
// in the revert Change Set XML.
boIdentifiers.add(activeBO);
}
}
return boIdentifiers;
}