Working with Custom Types

As an Application Developer you activate, create and edit Custom Types to define CDA Entities.

This page includes the following:

About Properties

What are Properties?

Every entity has properties. However, the notion of property is particularly relevant for Components and Deployment Targets, because they carry technical references that must be interpreted on the system. Properties flow to Workflow actions using PromptSets, and from there they are passed to agents as parameters.

Types of Properties

Sequence of Events

  1. The Components pass the values to the action workflow (third-level workflow). Because an action deploys a component and nothing else, other entities never talk to the workflow directly. The Component, however, is able to source values from other entities (targets, applications, environments...). For example, if a weather application component is being deployed to a Tomcat Server with a given URL, you can source that URL from the deployment target in the dynamic properties of the component.
  2. In actions, PromptSet values flow from the components being deployed.
  3. The artifacts defining properties are passed to the agents as parameters.
  4. For an artifact to be deployed to a system, you need an AE agent installed on that system. The agent performs the deployment work via system process submits called AE.

Understanding Custom Types and Properties

CDA has a flexible domain model that allows you to configure the entities according to your needs. You can create custom types for many entities (deployment packages, environments, components, applications, and so on) and define custom property groups and properties for each type. When you create an entity, you have to select the type. You can then work with the properties and templates that are attached to this type.

Note: You get more custom types with other packs.

The following figure displays the concepts that are related to types and properties:

Example

The following example shows the relationship between custom types and properties:

Example:

  1. A Tomcat property stores the URL, which is made up of other properties, such as Protocol, Host, Port and so on. These values are stored in the Tomcat custom properties (you know that they are custom properties because there are fields). The URL is constructed from these properties.

    This is what is defined in the Custom Types of the Tomcat Deployment Target:

    Image displaying Custom Types view

    This is how this information looks like in the Properties view:

    Image displaying Properties view

  2. These values are passed to the dynamic properties of the web application Component:

    Image displaying Dynamic Properties view

  3. Then, the values are passed on to the action promptsets:

    Image displaying action promptsets

    The promptsets have the same name as the dynamic property, but are preceded by an EXT: term.

  4. When the Deploy Workflow action is executed, the URL is passed to the action and stored in the Promptset.
  5. The action executes a task on the Agent - the URL is a parameter.

    Graphic depicting properties workflow

Viewing Custom Types

Custom types are displayed:

The custom type definition consists of the following sections:

Click the Add Filter button above the list to filter the custom type by one of its properties. The Component, Package and Workflow types can be also filtered by Application.

Creating Custom Types

  1. Open the Release Automation perspective.
  2. Hover over one of the main types (for example, Application, Component...) and click the green cross displayed to the right. The Create Custom Type dialog is displayed.
  3. Do one of the following:
    • Select the Create from existing option and follow the steps below to create a custom type based on an existing one:

      1. Enter the name of the new custom type.
      2. Enter the version number.
      3. Select the type, custom type and version upon which you want to base the new custom type.
    • Select the Import xml option, enter a version number and select the file containing the custom type definition you want to import.

Activating Custom Types

Before you can use imported custom types, you must activate them.

Perform the following steps in CDA after installing a new pack:

  1. Log in as an Administrator and wait for 60 seconds.

    Note: The Start page opens and a request shows up in the AWI Message area (top right corner), informing you that new custom types have been added.

  2. Activate the new custom types manually and - if applicable - move the old instances forward.

Editing Custom Types

Note: Unsaved changes are indicated in the editor with a silver background and a small edit icon to the right.

Toolbar

The toolbar provides all functions to administrate a custom type:

Quick Actions

Quick actions are shown below the toolbar and allow the user to immediately access the most likely function directly.

Context Menu for Structural Changes

Upgrading Custom Types

  1. Select the type and click the Type Upgrade tab.
  2. Click the Upgrade button at the top.
  3. In the dialog, select the custom type, the type, and the base and target versions:
    • Custom Type

      The custom type whose entities should be upgraded.

    • Type

      The base type of the custom type.

    • From version

      The type version from which the entities should be upgraded.

    • To version

      Lists all non-draft type versions except the From version in descending order by their creation date.

  4. Select the new version and click Show Preview to perform a dry run. The result of the dry run is the Type Upgrade Preview, in which you see which entities could be safely converted to the new type.
  5. Select the entities you want to upgrade and click Upgrade.
  6. A detailed report about the upgrade results is displayed.

    Notes:

    • The custom type upgrade is stored in the log file.
    • The sort order of the prompts is persisted. For more information, see Creating Dynamic Properties.

Best Practices for Custom Types

Deployment Package Custom Types

For deployment packages, new custom types are created as different properties are required based on the release version. Each individual deployment package may have a different package stateflow which would require more package types.

For example, in this case a bug and feature custom type was created. Both types require different properties.

Other common package custom types are: Major and Minor.

Note: default custom types may not meet the requirements in most scenarios or contain too many properties which are not used. If you use default custom types and update their properties, those properties should be set up for all applications.

It is also important to copy the deployment custom type (as this custom type allows a package to relate to an application) when creating application deployment package types.

Naming Conventions

Following examples can be used as standard naming conventions for package custom types:

Component and Deployment Target Custom Types

For an application that only deploys an Ear file, no new custom types might be required as the out-of-the-box deploy Ear file and start and stop server actions can be used. However, if this component also has to perform customized steps which require properties to be set up on the component, on the deployment target or both, individual custom types for components should be used.

Usually, the creation of custom types of components and deployment targets goes hand in hand, which means if a new component custom type is created, a new deployment target custom type should be also created.

Another use case that requires the creation of more custom types is when duplication of custom types is required.

For example, two Weblogic endpoints have been defined: Batch and Online. The Weblogic custom type has to be duplicated for both, because the target assignment on the profile is easier if two different custom types exist, as Weblogic_Online deployment target types are automatically assigned to Weblogic_Online component types. If only one Weblogic type existed, you would have to decide manually which deployment target has to be deployed against the component Weblogic_Online and Weblogic_Batch. Also, it makes it easier for the user to filter quickly on Custom Types.

In summary, creation of customized custom types highly depends on the use case. If a high number of customizations are required, customization of custom types should be considered. If out-of-the-box actions and properties are being used, it should be considered to use out-of-the-box custom types.

Naming Conventions

Following examples can be used as standard naming conventions for components and deployment targets custom types:

Other Entities

No customization is required for other entities.