Best Practices: Naming Conventions

Apply consistent naming conventions to your objects. Naming conventions help you recognize alerts, identify potential security issues and differentiate objects and processes. They are particularly useful when you export and import objects and when you transport them.

This page includes the following:

Introduction

Renaming objects is always possible. However, giving objects consistent names from scratch helps you in many ways:

Tip: Use different servers and databases to separate production environments from testing and development environments. This way, production is not affected by test runs or updates to the testing environment. If needed, however, all three environments can be run within a single Automation Engine system. To transport objects and processes from one environment to another, using consistent object names is extremely important.

Character Conventions

Object names may consist of up to 200 characters. The following characters are allowed:

Object-specific restrictions

Naming Conventions for Clients

Clients act as self-contained environments. They are represented by Client objects.

If there are no dependencies between tasks in individual subject areas, departments or customers, you may want to run separate Clients for each area. This has the advantage that setting up a user authorization concept is easy. On the other hand, merging Clients later on can be a very time-consuming process.

Example: Different Client Number Ranges in Different Environments

The table below illustrates how to divide up the number ranges used for Clients in three different areas (systems). The Client numbers used for each department or customer are uniformly different in the testing, the development, and in the production systems.

Test system Development system

Production system
0001 training    

0100 internal maintenance

 0200 internal maintenance 0300 internal maintenance
1000 FA Finance 1100 FA Finance 1200 FA Finance
2000 FA Insurance 2100 FA Insurance 2200 FA Insurance
3000 FA Warehousing 3100 FA Warehousing 3200 FA Warehousing

This type of numeric allocation is useful when defining tasks because tasks can determine on which Client (system) they are running. Given a logical numbering concept, tasks can configure the required parameters automatically. This eliminates the need for manually configuring the tasks for each separate environment.

Naming Conventions for Agents

When you define a naming concept for Agents, take into account that there are two types:

Agents for Operating Systems

Using the name of the system on which the Agent is installed is a good choice. Alternatively, you can use the primary DNS name of the system, in case this is not the same as the system name. Either way you can immediately recognize on which Operating System a client is running.

Warnings:

Agents for Applications

To distinguish Agents for applications from Agents for Operating Systems, use prefixes that identify the application followed by the name of the application instance. The structure of such Agent names would be as follows:

<APP-PREFIX>_<APP_INSTANCE>

For example, SAP_P01.

Naming Conventions for Agent Groups

Agent Groups encapsulate Agents that use the same Operating System or application. In Jobs, Agents Groups can be specified instead of individual Agents for the purposes of load balancing, process parallelization or to ensure high availability. In consequence, their naming should be based on the shared traits of the Agents encapsulated by the group. To help distinguish them and to aid searches of Agent Groups, you may wish to use a prefix such as 'AG_'. For example:

Clustered Agents

If Agents are being run as part of a cluster, use a prefix or suffix to distinguish these from non-cluster Agents. For example:

Naming Conventions for Objects - General Considerations

Objects used for designing processes are either executable or global objects. Login, Include, Variable, Notification, and Calendar objects are examples of global objects. These can be used by all the processes within a Client. On the other hand, Jobs, File Transfers and Workflows are examples of executable objects.

When choosing object names, it is very important to have your access authorization concept in mind. An authorizations concept that is both effective and easy to maintain relies on a logically structured naming concept. When assigning names, make sure that you take into consideration the transport paths that will be used. For example, should two Clients be merged into a single Client in the future, objects with identical names will cause issues.

If you intend to transport Processes between Automation Engine Clients, such as between the testing and the production Client, all of the Client-dependent parameters for each self-enclosed process (transport unit) should be stored at a central process location (for example in an Automation Engine Variable object). This includes Agents and paths for processing that may vary between testing and production.

This central configuration object contains either the configuration for all the Clients running the process, in which case it is always included in the transport, or only the configuration of the Client currently running the process, in which case it may not be part of the transport. The first of these two approaches is more time-consuming in terms of maintenance, but it is also more reliable for operation.

In the Automation Engine, authorizations can only be controlled via object names and object types; they cannot be controlled via user-defined folder structures. Because of this, global objects that are only accessible for modification by a restricted User Group should be identified accordingly in their names.

Therefore, object names should consist of the following:

Example

Naming Concept for Individual Objects

The following convention lets names consist of 6 chunks of information, and defines which separators are consistently used:

According to the schema, you could have the following object names:

Naming Conventions for Global Objects

To simplify the maintenance of processes, the use of global objects should be instated right at the beginning, that is, before any of the processes are transferred to the production system. Central objects, for example, can already be planned for as part of the object templates when creating new processes.

Examples for this are global Includes (script components) for all the objects' available script cards, which later on permit fast updating multiple objects, or the definition of at least one central Notification object for terminations within a process. Both examples would require not only the corresponding objects to be defined but also for the object template(s) to be updated in order for the central objects to be available for all new processes. Any existing process tasks still based on the old templates would need to be adapted manually. As a result, it makes sense to plan out the use of global objects as early as possible.

This list provides examples of how to name and use global objects:

Naming Conventions for Executable Objects

Executable objects can determine their name when launched. Any useful information contained in their names can then be used to configure the object parameters.

Example: The following naming conventions let users include the name of the SAP report and its associated variant in the object name, and distinguishes SAP jobs from other jobs:

The Automation Engine script commands for dissecting the name are again stored in central Include objects. These Includes are added to the (SAP) Job templates right at the beginning of constructing the Automation Engine system. This way, every newly created Job already has the Include required for it.

See also: