Siebel Application Deployment Manager Guide > ADM Support for Additional Data Types >

About Data Type Attributes for Adding New ADM Data Types

This topic describes the data type attribute categories in Data Type Attributes for Adding New ADM Data Types that provide data type information to consider when adding new Application Deployment Manager (ADM) data types. The following terms are used in Data Type Attributes for Adding New ADM Data Types:

• Parent Data Type
• Registry Parameters
• Enterprise Profile Parameters
• Backup Method
• Deploy Method
• Deploy Validation Method
• Activate Method
• Activate Validation Method
• Steps Automated by Activate or Restore Activate Methods
• Restore Method
• Delete New Objects Parameter
• Restore Activate Method
• Restore Activate Validation Method
• Max Units Per Package
• Manual Steps
• Additional Downtime Impact
• Deployment Prerequisites
• Notes

Parent Data Type

Name of the parent data type for hierarchical database types.

Registry Parameters

Parameters used to provide additional information about a data type. The information is provided in a name-value pair in the registry file; for example, TargetServerType=ReportServer for <parameter name="TargetServerType" value="ReportServer"/>. Each data type can have any number of parameters defined.

NOTE:  The parameters are read by the code and used according to the data type's requirement. You cannot add a new parameter and expect the ADM framework to consider it without code changes.

Enterprise Profile Parameters

Name of parameters specified in the entprofile.xml file for a particular data type.

Backup Method

A backup method is used to back up data in the target environment, which will be affected during the copy operation of the package. The backed up data can later be used in the restore operation to revert the changes. There are four possible values:

• Not Applicable. There is no way to back up this data type. In this case, deployment will copy new data without backing up the old data, and there would be no way to restore the original data after deployment is executed. However, there are a few exceptions in which the restore operation can revert the changes to a version in the target environment without having performed a backup operation prior to deployment.
• Business Service. The specified custom Siebel Business service will be called, and the method in the Method attribute will be invoked.
• EAI. The default implementation for database types.
• Mbean. The default implementation for file types.

Deploy Method

The method that performs the copy operation. There are four possible values:

• Business Service. The specified custom Siebel Business service will be called, and the method in the Method attribute will be invoked.
• EAI. The default implementation for database types.
• Mbean. The default implementation for file types.
• JavaAPI. A custom java implementation, with the class and method as arguments.

NOTE:  The way the target data is affected for database items depends on the deployment mode used during export.

Deploy Validation Method

Validation performed before executing the copy operation. The following methods can be invoked:

• CheckSchemaVersion. The method called to check the database schema version of the source database, present in the exported XML file, against the database schema version of the target database. The validation is successful if the versions match. The validation fails if the versions do not match.
• ServerComponentStatus. The method called to check the state of a specified Siebel Server component on the target server against a given state (running, offline, or online), for example,

  <component>

  <name>ADMObjMgr</name>

  <status>Online</status>

  </component>

  where name is the component name, and status is the status of the component. If the states match, the validation is successful. If the states do not match, the validation fails. In this example, if ADMObjMgr is online on the target server, then the validation is successful.

Activate Method

The method that makes the deployed data available to users in the target environment. There are two possible values:

• Not Applicable. Either there is no activation step, or the activation step is not automated.
• Business Service. The specified custom Siebel Business service will be called, and the method in the Method attribute will be invoked.

NOTE:  Not all data types need activation. Some data types are immediately available to the users after deployment.

Activate Validation Method

Validation performed before executing the activate operation. The following methods can be invoked:

• Not Applicable.
• ServerComponentStatus. The method called to check the state of a specified Siebel Server component on the target server against a given state (running, offline, or online), for example,

  <component>

  <name>ADMObjMgr</name>

  <status>Online</status>

  </component>

  where name is the component name, and status is the status of the component. If the states match, the validation is successful. If the states do not match, the validation fails. In this example, if ADMObjMgr is online on the target server, then the validation is successful.

Steps Automated by Activate or Restore Activate Methods

Steps that are automatically executed with the activate or restore activate methods. Necessary steps that are not automated must be manually performed.

Restore Method

The method used to restore the target system to the same functional level as before the deployment operations were invoked. There are four possible values:

• Business Service. The specified custom Siebel Business service will be called, and the method in the Method attribute will be invoked.
• EAI. The default implementation for database types.
• Mbean. The default implementation for file types.
• JavaAPI. A custom java implementation, with the class and method as arguments.

NOTE:  The restore implementation is not necessarily an "undo" mechanism, even though it restores the original data to the target system. For example, the version of versioned objects may increment. Additional actions may be required to fully restore the target system to its original state prior to deployment.

Delete New Objects Parameter

If this ADM registry parameter is set to Yes during a restore operation, then all top-level objects newly created by the deployment operation are deleted from the target system. If this parameter is set to No, then the new objects are not deleted, but remain in the target system.

If delete is not appropriate for a specific object type, it may be necessary to modify the objects to render it inactive. For example, you may need to mark an object as inactive to, in effect, achieve the functional state before deployment.

If an object is created during deployment, and is activated after deployment, then a custom restore method must be performed to implement the additional steps needed for completely deactivating the object.

If the newly created top-level objects should not or cannot be deleted during a restore operation, then the value of the parameter must be set to "No", and a comment should be entered in the registry to clearly describe why.

Restore Activate Method

The method that makes the restored data available to users in the target environment. There are two possible values:

• Not Applicable. Either there is no restore activate step, or the restore activate step is not automated.
• Business Service. The specified custom Siebel Business service will be called, and the method in the Method attribute will be invoked.

NOTE:  Not all data types need activation. Some data types are immediately available to the users after restore.

Restore Activate Validation Method

The validation method performed before executing the restore activate operation. The following methods can be invoked:

• Not Applicable.
• ServerComponentStatus. The method called to check the state of a specified Siebel Server component on the target server against a given state (running, offline, or online), for example,

  <component>

  <name>ADMObjMgr</name>

  <status>Online</status>

  </component>

  where name is the component name, and status is the status of the component. If the states match, the validation is successful. If the states do not match, the validation fails. In this example, if ADMObjMgr is online on the target server, then the validation is successful.

Max Units Per Package

The maximum number of units allowed in an ADM package due to limitations with the product. The ADM Package Utility enforces the limit.

Manual Steps

Manual steps required for deploying the data type. These steps include clicking buttons, restarting a service, clearing the cache, and so on.

Additional Downtime Impact

Other impacts to system availability or downtime during deployment, in addition to those listed in Table 12.

Deployment Prerequisites

Prerequisites for successful deployment of the data type.

Notes

Special considerations, limitations, and comments for the deployment of the data type.