Share this page

# 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.

https://admhelp.microfocus.com PPM 8942
Tips to improve your search results... OpenText™ Project and Portfolio Management Help Center PPM Help 26.2-26.3 All View Local Help Center View Online Help Center Version: