Working with Applications

As an Application Developer, you manage Applications and their dynamic properties. You can also create Application Packs to export/import Applications and work with them in other systems.

Important! The actions that you can perform depend on your folder permissions. See: Assigning Release Automation Permissions.

This page includes the following:

Viewing Applications

Applications are managed within the Applications main section of the Release Automation perspective.

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

Applications List

From this list you can:

Application Dashboard

To open it, click Applications on the navigation pane and double-click an Application. The dashboard is divided into several panes that provide the following information:

Note: Right-click an entity to see the list of actions available.

Information Icons

The state of Deployment Profiles and Installations is indicated by icons. If more than one state applies, the icon with the highest rank (the lowest number) is shown.

The following icons are available:

Rank Information icon Description
1 Green square with white triangle At least one installation on a Target in this Deployment Profile is running.
2 Red square with white x At least one current installation on a Target in this Deployment Profile has failed.
3 Red square with white exclamation mark At least one snapshot validation failed for a Target included in this Deployment Profile.
4 Target icon with red exclamation mark At least one target included in this Profile has an Agent offline.
5 Gray square with white tick All current installations on this Profile were successfully installed.

For execution status, see Viewing Workflow Executions and Queue Runs

Viewing Application Installations

The Installations list helps developers and release managers track the installation status of an Application by providing an overview of the Components that are installed on the Deployment Targets, the Artifacts deployed (if any), and other entities used for the deployment.

Note: As an Operator, you access the Comparisons view to compare the installations of an Application on two Environments, for example, Test compared to Production Environment.

To View Application Installations

  1. Open the Release Automation perspective.
  2. Select the Applications tab.
  3. Right-click an Application and select Go to details > History > Installations.

Installations List

The view presents the following columns:

Creating Applications

Applications can be created from the Applications list or with the Application Wizard.

Creating Applications from the List

  1. Click the Create button in the toolbar. The Create Application dialog is displayed.
  2. Enter the name of the new Application, which has to be unique and may only contain alphanumeric characters, blanks, ".", "-", "_", "@", "$", "#".
  3. Enter the Application type. All types on which you have create permissions can be selected.

    Important! The selected Application type cannot be changed after creation.

  4. Enter the name of the folder where you want to store your Application.

    Note: Avoid folder names containing a period character. Period characters may cause ambiguity in Application Workflows.

  5. Enter the owner of the Application. The current user is selected by default.
  6. Click Create.

Creating Applications Using the Wizard

The Application wizard guides you through the necessary steps and speeds up the creation of an entire application stack from scratch including extra required objects.

Note: Avoid folder names containing a period character. Period characters may cause ambiguity in Application Workflows.

When creating an Application, consider the following:

To Create an Application with the Application Wizard

  1. Click the Run Wizard button in the toolbar. The Application Wizard is displayed.

    Note: Select the Show only mandatory properties checkbox that is displayed for every step if you want to define only the minimum properties required to create the entities. Mandatory properties are defined according to the custom type configuration.

  2. On the Application page of the wizard, you can define the basics of the Application.

  3. Add the Components to be deployed.

    Two Components are included by default, one for the back-end and another one for the frontend. You can use them as they are or edit them according to your needs.

    You need one Component per application artifact. Components should be defined so that they typically reflect the tiers of a distributed application.

    Note: You can add up to ten components.

  4. Define a new Application Workflow to deploy/undeploy the Components. You have to fine-tune the workflow later.

    As a Workflow is part of an Application, it is not necessary for the Workflow to contain the Application name. Workflow names should only contain its purpose (for example, install, deploy-simple, deploy-complete, uninstall).

    Select a type depending on the purpose: install, uninstall

  5. Select or create one or more Environments to store the targets where the Components are deployed.

    Generic environments are typically used if all application teams work with the same Environments and if the properties on the Environments, if existing, apply to all Applications. In this case, a Development Environment would contain Deployment Targets for multiple Applications. Therefore, if no physical separation is required between Application Environments, Generic environments can be used. Examples of generic environments which could be implemented are: TEST, QA, or PRODUCTION.

    If a physical separation is required, Application Environments have to be created. This is the case if different properties are required on the Environments for each Application or if there are different infrastructure teams managing the Environments.

    The default type is non-Production.

  6. Define the Deployment Targets for each Environment.

    You can assign the Agent to be referenced by the target now or you can do it later, after finishing the wizard.

    Note: You can define a maximum of 30 Deployment Targets for each Environment.

  7. Define the Profile, which is the connecting map between Components and Targets.

    In the lower section of the Profile page, map the components to the targets where you want them to be deployed.

  8. Define the Package, which is dynamic and contains all Application Components.

    A Package represents an instance (a version, a revision, a tag, …) of your deployable application by pointing to the related deployment artifacts.

    Pointers can be full URIs to the source location of artifacts or simply the revision or tag uniquely identifying this version in a repository.

  9. The Summary page displays all entities that are created via the Application Wizard. Review them and click Finish to complete the creation process.

Creating Application Packs

As an Application Developer, you can easily export/import Applications and their related entities via Plug-in Manager/Package Manager. To do this, you must create Application Packs containing the serialized content of an Application first.

To Create an Application Pack

Important!

  1. Go to the Release Automation perspective.
  2. Do one of the following:
    • Right-click an Application and select one of the following options:

      • Add to Application Pack

        Click it to create a new Application Pack.

      • Application Pack > Save

        If a Pack for this Application already exists, this option is shown instead. Click it to update the information that is contained in the Pack.

    • Double-click an Application to open it and click the Properties tab.

      Click the Application Pack drop-down in the toolbar and select Save.

  3. Enter a new title (name) for the Application Pack or edit the existing one:

    • The recommended naming convention is PCK.APP.[Application Pack Name]
    • Name/Title fields can contain up to 255 characters
    • The name must be unique and may only contain alphanumeric characters, ".", "-", "_", "@", "$", "#"
    • Special characters and space characters are not supported. They are replaced by underscores.
  4. Click Add/Save.
    • Saving your changes creates a new minor version of the Pack. For example: 1.0.0 > 1.1.0
    • If the Application uses objects that are stored outside the Application folder or that are not related to any Action Pack, you are prompted to confirm the creation of the Application Pack without the objects. Alternatively, you can cancel the creation process, add the objects to the Application folder, and start again.
    • The new Application Pack is created in the PACKAGES folder of the Process Assembly perspective

Notes:

New Application Folder Structure

As of version 12.2, Applications have a new folder structure in the Process Assembly:

[FOLD] ARA.APPLICATIONS
           [FOLD] {ARA Folder}
                      [FOLD] {Application_01.Name}.{Application_01.Version}
                                 [FOLD] {Application_01.GUID}
                                            [JOBP|JOBS|...] {Legacy objects}-{Application_01.GUID}.{Application_01.Version}
                                 [JOBP] RM.{ARA Folder}.{Application_Workflow_01.Name}.{Application_Workflow_01.GUID}
                                 [JOBP] RM.{ARA Folder}.{Application_Workflow_02.Name}.{Application_Workflow_02.GUID}
                                 [FOLD] {Application_Workflow_01.GUID} 
                                            [JOBP] RM.{ARA Folder}.{Component_01.Name}.{Component_01.GUID}.{Application.Version}.{Component_01.Version1}
                                            [JOBP] RM.{ARA Folder}.{Component_02.Name}.{Component_02.GUID}.{Application.Version}.{Component_02.Version1}
                                            [JOBP] RM.{ARA Folder}.{Component_02.Name}.{Component_02.GUID}.{Application.Version}.{Component_02.Version2}.1
                                 [FOLD] {Application_Workflow_02.GUID}
                                            [JOBP] RM.{ARA Folder}.{Component_01.Name}.{Component_01.GUID}.{Application.Version}.{Component_01.Version1}
                                            [JOBP] RM.{ARA Folder}.{Component_01.Name}.{Component_01.GUID}.{Application.Version}.{Component_01.Version2}
                                            [JOBP] RM.{ARA Folder}.{Component_02.Name}.{Component_02.GUID}.{Application.Version}.{Component_02.Version1}

Important! The Component and Workflow names are also different.

Editing the Properties of Applications

To change the properties of an Application, you can use one of the following:

You can see/change the following Application properties:

Defining Dynamic Properties

Applications allow you to define dynamic properties that can be used in deployments in the Dynamic Properties section. You may also overwrite/add dynamic properties of the Components that belong to the Application. See About Properties.

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

Property

Description

/system/name

The Application name

/system/type

The Application type

/system/owner

The display name of the owner to which the Application belongs.

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

Duplicating Applications

Important! You need read and write permissions on the Application sub-entities to perform this action. See: Required Folder Authorizations

  1. Click the Duplicate button in the toolbar.

  2. Optionally, enter a new name for the Application.

    An Application name can only contain alphanumeric characters, blanks, ".", "-", "_", "@", "$", "#"".

  3. Select a destination folder.
  4. Select an owner for the new Application.

    The owner of the original Application is selected by default.

The following information is NOT copied to the new Application:

Note: After creation, you are redirected to the properties page of the new Application.

Deleting Applications

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

Conditions to delete entities of type Application

Important! When you delete an Application in the Release Automation perspective, the corresponding Application Pack and Package that are displayed in the Process Assembly are deleted too.

Application Best Practices

Naming Conventions

Tip: Create all entities in capitals. Entity names should not contain any spaces. If necessary, use "_" instead of spaces.

Application names should refer to the overall Application, not to any individual components. The naming conventions that are applied for Applications are as follows:

If further granularity is needed, the specific functionality is described after a suffix:

Attributes

The following attributes should be considered when defining an Application:

Attribute

Description

Deployment Frequency

When breaking down the Application and defining the Components, the deployment frequency has to be planned for each Component. If, for example, Components x,y,z are deployed on a weekly basis but Components a,b,c are deployed on a three-month basis, it could be useful to split the Components into different Applications.

Component Relationship & Dependencies

You should define whether two ear files (each assigned to an own Component) can be deployed independently or not. If they can be deployed without the existence of the other one, the Components could be split into two different Applications. This does not mean that each deployment always contains both Components. If a Component exists on the target Environment and it has not been changed, it can be excluded from a deployment and still belong to the same Application. Components should belong to the same Application if:

  • Are developed by the same team

  • Have some deployment-time dependency

    Example: one Component has to be deployed before another one.

Mini & Generic Applications
  • Generic Application: same Components are used for different Applications where Application-specific input data is changed but using the same deployment steps.
  • One Application: standard Components are copied for each mini Application, this makes it easier if changes are required.
  • Multiple Applications: a standard Application with standard Components are created, which are used as the template for all other Applications (Copy & Paste).

See also:

Security Concept in CDA