A unit test script is automatically created when you compile a cartridge. The purpose of the unit test is to verify that the main transform stages of the cartridge (service model to device model and annotated device model to CLI) generate the output documents correctly.

Audit trail logging records the commands sent to devices by the base cartridge, and any service cartridges that extend the services of the base cartridge.

The audit trail log files for the Network Processor are located in the directory: Service_Activator_home\AuditTrails.

Audit trail logging properties are set up on a per-cartridge basis and include:

• The name of the audit logging file

• Audit trail logging level

• File rollover strategy

Any time an error is encountered while sending commands to a device, a rollback will be initiated. The rollback's purpose is to restore the device to the same state it was in before configuration changes were applied. This ensures the device is returned to a known state.

The rollback works by reversing the last and target device models before annotating. This will cause configuration that was created to instead be marked as deleted. Likewise, anything removed would instead be added. Also any modifications would be modified back to their original state.

Once this reverse annotation is completed, the DM to CLI is rerun. This result is a complete list of commands to undo the changes.

The remaining component to the rollback involves the device model IDs. DM IDs are used to correlate commands back to their corresponding device model elements. They must be implemented correctly for rollbacks to function properly. Incorrectly implemented DM IDs will not be detected or noticed during the successful running of the system. They will only cause problems after specific failures sending commands to a device.

DM IDs are used to track changes applied to the device, and provide a means for knowing which changes have been successfully applied before the error was encountered. These IDs remain the same for the reverse annotation, and are used to filter out configuration that was not applied. This is done as part of the annotations. Any configuration that did not get applied to the device will not be marked as changed.

Every device model element extending the base type of Changeable will be marked with a different DM ID by the framework before the DM to CLI transform. Every element marked as changed (changetype="ADD", “DELETE" or “MODIFY") will need to have its DM ID in a command to be sent to the device. The framework can then determine which configuration elements have been successfully applied to the device while sending commands. This is needed when a failure occurs, as the framework will redo the annotations but will exclude any configuration that was not successfully applied.

If any failure occurs during the rollback, the system is forced to put the device in the intervention required state. This is an indication that the system could not put the device into a known state and a user must investigate.

For more information on how to deal with a failed rollback, refer to the discussion of recovering from rollback failure in IP Service Activator System Administrator's Guide.

The rollback mechanism will remove all configuration changes if any failure is encountered while sending the commands to the device. There could be many different changes in a given transaction, not all of which could fail. Quarantine provides a means of separating the failed configuration so other changes can be applied to the device.

If any failure occurs where the association IDs are known (e.g. sending commands, DM validation XQuery faults), the system will quarantine that configuration after the rollback has been completed. This is done by restoring the failed parts of the service model to the last service model. Once this has been completed, the transforms are run again with the new service model. This effectively reverts the failed configuration and then retries any other configuration changes that could have occurred.