Working with Application Components

As an Application Developer, you manage Application Components and their dynamic properties. You can also assign Artifacts to Package Components to allow traceability.

Important! The actions that you can perform depend on your folder permissions, see: Folder Permissions.

This page includes the following:

Viewing Components

Components can be accessed:

The list displays all the Components of the selected application, ordered by name.

Tip: For more information about how to search for entities and narrow down the results, see: Global Search

Creating Components

  1. Click the Create button in the toolbar. The Create Component dialog is displayed.

    Consider the following:

    • The Component Name must be unique within the Application and can only contain alphanumeric characters, blanks, ., -, _, @, $, #
    • The Type list displays all types for which you have permissions
    • The type cannot be changed after creating the Component
    • You can select the current user or one of the user groups the user belongs to as owner (or one of all active user groups for administrators). To assign a different user, edit the entity after creating it.
  2. Click Create.

Changing the Properties of a Component

To change the properties of a Component, you can use:

You can change the following Component properties:

Defining Dynamic Properties

Components allow you to define dynamic properties that can be used in deployments. See About Properties for details.

The following system defined dynamic properties are available in addition to the custom dynamic properties and the custom properties (in the /custom namespace):

Note: You can also search for dynamic properties using the Global Search.

Duplicating Components

You can duplicate Components within the same Application or between two different Applications.

To Duplicate a Component

  1. Select the Component that you want to duplicate and click the Duplicate button in the toolbar.
  2. Optionally, enter a new name for the Component. It can only contain alphanumeric characters, blanks, ., -, _, @, $, #.
  3. Select the Application where the new Component will be saved. You can leave the default value as is (to duplicate the Component within the same Application) or select a different one.
  4. Select a destination folder.
  5. Assign an owner for the new Component. By default, the owner of the original one is selected.

The following information is copied to the new Component:

The following information is NOT copied to the new Component:

Notes:

Deleting Components

Note: You may only delete the entity when you have the appropriate permission on the containing folder (see Security Concept) and all of the listed conditions are met.

Conditions to delete entities of type Component

Important! The DB-Cleanup tool deletes Executions and Installation records, regardless of the installation status. To verify that all Executions have been deleted, select the following parameters when running the tool:

Installation Records can be also deleted by executing a Workflow of type Uninstall. You cannot delete single Installation records.

Tip: Execute the DB-Cleanup tool and delete the component-related Packages before deleting a Component. Alternatively, you can remove the Component from the Package.

Assigning Components to Deployment Packages

  1. Open a Package and click the Components tab.
  2. Click the Assign button in the toolbar.
  3. Select the Application Components you want to assign to the Package.
  4. Click OK.

Note: To unassign Components, click Assign, clear the Components that you want to remove from the Package and save your changes.

Assigning Artifacts to Components

  1. Open the Release Automation perspective.
  2. Click the Applications tab.
  3. Double-click an Application to open it and select a Component.
  4. Click the Artifacts tab at the top of the view.
  5. Click the Assign button in the toolbar. The Assign Artifact dialog is displayed.
  6. Select an Artifact.
  7. Click Select.

Note: An Artifact that is assigned to a Package cannot be removed from the Component.

Component Best Practices

Naming Conventions

The naming conventions applied for components are as follows:

If further granularity is necessary, describe the specific functionality with a suffix:

Examples:

Single Components per Tier – Database and so on

Some instances do not require multiple CDA components. Generally speaking, if all the Deployment Targets per Environment are equal for all artifacts of a tier and the deployment logic is the same for all artifacts of that tier, it is sufficient to create one CDA component for the tier and include all artifacts. For example, all database scripts that are required for a DB migration can be linked under one component if they are executed against the same DB instance within a specific Environment.

Multiple Components per Tier

Sometimes the Targets (nodes) and deployment logic differ for different artifacts of the same tier of an application. For example: WebSphere and WebLogic deployments may require multiple components per tier, because of the following specifics:

Two components are required in this example: WEBLOGIC_DEPLOY and WEBLOGIC_CONFIG, because the config file is distributed to different Deployment Targets and requires a different deployment procedure than the rest of the activities.

A third Component - WEBLOGIC_START_STOP - could be created in addition to the two previous components. This component would start and stop servers. This is required if, for example, you want to have the flexibility to deploy the following scenarios:

In the last scenario, you can control the components that have to be deployed through the package by assigning only the components that are required for a Minor or Hotfix deployment.

Note: If the database requires Weblogic Server Stop and Start, the database can be deployed individually without deploying the Ear file or Weblogic config files.

Multiple Components per Tier – Different Properties

You may want to split, for example, the Java (Middleware) Component into two different CDA Components when the Java component is deployed to two different types of endpoints and therefore different properties are required. This makes it easier to set up the deployment model, as different properties have to be referenced from the Deployment Targets. It also makes the separation of Targets easier.

Pre- and Post-Components

Sometimes, it is recommended to create Pre and Post Components. These tasks could include, but are not limited to:

See also: