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: Folder 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 to search for entities and narrow down the results, see: Global Search

Applications List

To open the list, click Applications on the navigation pane.

From this list you can:

  • See a list of Applications you have read access to
  • Edit the properties of an Application from the sidebar
  • Trigger the most common Actions from the toolbar
  • Click the left icon or hover over the Application name on the column header to access its full functionality

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:

  • All its Components sorted by name
  • All its Packages sorted by date of creation, the most recent being the first of the list
  • All its Profiles sorted by status, then by name
  • The Environment to which each Profile links the Application
  • All its Workflows sorted by name

  • All its current Executions with their (planned) start time, Profile and Package.

    Note: For executions in queue runs the name of the queue is shown (instead of the start time).

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

Information Icons

The state of 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 (listed by importance):

  1. Green square with white triangle

    At least one installation on a Target in this Profile is running.

  2. Red square with white x

    At least one current installation on a Target in this Profile has failed.

  3. Red square with white exclamation mark

    At least one snapshot validation failed for a Target included in this 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.

Notes:

Viewing Application Installations

See Application Installations

Viewing Application Executions

See Executing Application Deployments

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. Select the Application type. All custom types on which you have create permissions can be selected.

    Important! The selected Application type cannot be changed after creation. See: Working with CDA Custom Types.

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

  • Names must be unique
  • The recommended naming convention is [APPLICATION]_[Specific Process], [COMPONENT]_[Specific Process] and so on
  • Space characters are replaced by underscores in the folder name
  • Special characters are not supported
  • Name fields can contain up to 255 characters
  • Where applicable, you can select an existing folder or you can create a new one

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 backend 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 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 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 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/Updating 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.

Important!

  • AE objects stored outside the Application folder or not related to any Action Pack cannot be included in the Application Pack. Consider adding them to the Application folder in the Process Assembly Explorer before creating the Pack.
  • The override properties of the entities are ignored.

To Create Application Packs (GUI)

  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 an 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. Enter a new version number or leave the default value.

    Notes:

    • If the default value remains unchanged, saving your changes creates a new minor version of the Pack.
    • For manually defined versions, only semantic versioning is supported. Example: 1.0.0+HF.1
  5. Click Add/Save.
    • 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.
    • If the Application contains Proxy Components, references to the Shared Components will be saved as well. For more information, see: Working with Shared and Proxy Components
    • The new Application Pack is created in the PACKAGES folder of the Process Assembly perspective

Notes:

  • Dependencies on the custom type versions that are installed by Action Packs and used by the Application are also included in the Application Pack.
  • The Application you want to create an Application Pack from may use custom types and custom type versions which do not belong to any Action Pack. In this case, the corresponding custom types are included in the Pack and installed on the target system while importing the Application.
    • Custom types on the target system with the same name and version number as the custom types that are included in the Pack are not overwritten and are used by the imported Application.
    • The new custom type version that is imported into the target system will be in state IN USE. See: Quick Actions
    • The custom type version with status ACTIVE is not changed on the target system. That is, every new Component that is created after installing an Action Pack will use the active custom type version (and not necessarily the new version that is imported with the Application Pack).
  • Creating an Application Pack may take a while. The process runs in the background. You are notified when the process is complete.
  • Non-existing Application Pack folders are created automatically on the target system by the background user.
  • If the owner of the entity does not exist on the target system, the admin user is used instead. If an admin user is not available, the sync fails.
  • An imported Application Pack is only compatible with the exact same version of the Action Packs used in the origin system.
  • The sort order of Components and prompts is persisted. For more information, see Creating Dynamic Properties.
  • Application Packs can only be replaced with a higher version of the same Application Pack. If you want to install a lower version, you must remove the current Application Pack first.
  • Installing an Application Pack with one or more Proxy Components might require the installation of Shared Component Packs. The minimum supported versions of the Shared Component Packs are listed in the VARA metadata of the Application Pack. A message will be displayed if the required Shared Component Packs are missing or if a newer version must be installed. For more information, see: Working with Shared and Proxy Components

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:

  • The Application Sidebar next to the Application list
  • The Properties section of an Application

You can see/change the following Application properties:

  • General

    Basic attributes of the Application. You can edit the Name, Folder, and Owner.

  • Application Pack

    Version, name, and folder of the Application Pack created from this Application.

  • Description

    The description is limited to 4000 characters.

  • Recent Installations

    This panel displays the latest five Components deployed and the related Application Package and Artifact assigned (if any). Click on Show all Installations to open the Installations view.

  • Actions

    Actions are located in the toolbar. They can be also triggered from the context menu that is displayed after right-clicking the entity. You can trigger the following actions (depending on your permissions):

  • Errors and Warnings

    This panel shows errors and warnings in the context of the current Application. If there are no errors or warnings, the panel is not displayed.

  • Custom Properties

    The selected object may have more properties and property groups, that are defined by the administrator. If defined, these properties are shown in the sidebar as separate panels and you can edit them.

  • Statistics & History

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 Working with Dynamic Properties.

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

  • /system/name

    Application name

  • /system/type

    Application type

  • /system/owner

    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:

  • Package Relations
  • History Records
  • Component Related Packages
  • Component History Records
  • Value of properties of type Identity

Notes:

  • The sort order of Components and prompts is copied to the new Application. For more information, see: Creating Dynamic Properties
  • After creation, you are redirected to the properties page of the new Application.
  • You can also duplicate Applications from the search results view. For more information, see: Global Search

  • When duplicating an Application that uses one or more Shared Components, bear in mind that:

    • Proxy Components are also duplicated
    • Component Workflows are not duplicated
    • The reference to the Shared Components remains unchanged

Deleting Applications

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

Conditions to delete entities of type Application

  • Not referenced by any Package
  • Not referenced by any environment Snapshot
  • All assigned Components can be deleted - that is the case when the conditions to delete the Components are fulfilled for all Components assigned to the application
  • All assigned Profiles can be deleted - that is the case when the conditions to delete the Profiles are fulfilled for all Profiles assigned to the 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.

Note: You can also delete Applications from the search results view. For more information, see: Global Search

To Delete an Application

  • Right-click the entity and select Delete.

To Delete an Application Deployment

Follow the steps below to delete the executions of an Application, its installations and related entities.

  1. Run the DBCleanup tool to delete all executions: Cleaning Up the CDA Database. Deleting the executions also deletes the Application installations. See:Application Installations.
  2. Delete the Package, Profile, Component, and Workflow related to the Application.

    Important! Workflows in status active cannot be deleted. You can deactivate them from the Process Monitoring perspective.

  3. Delete the Application.

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:

  • [APPLICATION]

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

  • [APPLICATION]_[Specific Process]

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 and System Hardening