Defining Object Types

Object types define the technical steps required to deploy application changes for packaged applications, custom applications, legacy systems, and web content. Many types of objects are deployed through a workflow, such as files, SQL scripts, and data. Each object requires different information for proper processing. The information required to properly process an object is defined by the object type. For example, the object type for a file migration requires the following:

• The name of the file

• The type of file

• The location of the file

Additional information, such as file compilation after file migration, can also be specified by the object type. A single workflow can process many different object types, since the workflow specifies the process and the environments. The package specifies each object and the associated object type as a package line in the package. Information contained on a package line (defined in the object type) works with the workflow process to ensure that the object is correctly deployed.

For each object deployed through the process, you should collect the following information:

• Name of the object

• Object category (optional, used for reporting purposes)

• Parameters describing the object: Such as, what it is, where it is, its name, and what needs to be done to it. This information will translate into object type fields. For each object type field, define the following:

  • Field name

  • Validation and component type (dictated by the validation)

  • Field behavior: Such as whether it is displayed, required, and any default behavior.

• Commands required for the object being deployed. Object type commands often reference information stored in the parameters. These commands are run at specific points (execution steps) in the workflow. For example, you might shut down a database before inserting new data into the database. For more information, see Determining Commands Needed for Objects.

For an example of conceptual workflow steps using different object types, see Table 2-6. Example workflow. See Configuring Object Types for information on how to configure object types.

Table 2-6. Example workflow

Step Name	Workflow Step	Transition Values	Object Type Description
Migrate DEV to TEST	Decision	Approved Not Approved	Not applicable. Decision workflow step.
Stop the Server	Execution	Succeeded Failed	Connect to the server and stop the processes running on it.
Evaluate Object Type	Execution	Database File SQL Script	Evaluate the object type for each package line. Resolve the object type token.
Migrate to Database Environment	Execution	Succeeded Failed	Migrate the database changes to the TEST database environment. To do this, run commands located in the object type.
Migrate to Server Environment	Execution	Succeeded Failed	Migrate the changes to the TEST server environment. To do this, run commands located in the object type.
Sync	Condition	Success	Have all package lines provide this step before continuing to the next process step.
Compile Code	Execution	Succeeded Failed	Connect to the server and compile the code located on it.
Start the Server	Execution	Succeeded Failed	Connect to the server and start the processes on it.
Close FAILED	Execution	Succeeded	When a package line (object) provides this step, close the package.