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:

Maintain your systems
Produce, understand and react to alerts
Define a security concept
Transport objects and processes from one Client to another
Transport objects and processes from one system to another
Train new staff

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

Client: 4 numeric digits between 0001 and 9999
Agent: 32 characters
Agent Group: 32 characters
Time Zone: 8 characters

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
Agents for applications

Agents for Operating Systems

system name,agent naming conventions with system name,best practices for agent naming coventions,best practices for system name

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:

If the system is migrated to a new hardware system, the system name may also change. If the naming concept is to be preserved, this would require all the affected Agent names to be updated, and with them the Job object names.
For dynamically generated Jobs where the Agent is only determined at runtime and then set by a script, renaming the Agent object later on can be time-consuming.

To avoid major issues, store the Agent names centrally for each Client or Process, for example in variables or Include objects). This approach makes sense if you want to transport objects from one Client to another later on.

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:

AG_UNX_ALL

Group consisting of all UNIX Agents
AG_UNX_ORA

Group consisting of all UNIX Agents running on Oracle database servers
AG_WIN_SQL

Group consisting of all Windows Agents running on MS SQL database servers
AG_SAP_BASIS

Group consisting of all SAP Agents to be used for running SAP Basis jobs

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:

Object name: P01_UNX_CLUSTER_A

Descriptions: UNIX Agent for SAP P01 instance in cluster A
Object name: P02_WIN_CLUSTER_X

Description: Windows Agent for SAP P02 instance in cluster X

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:

A static part that can consist of one or more chunks. They could be:
- Branch
- Department
- Special identifier for a Client's global objects
- Automation Engine object type
The individual identifiers of the static part of the name should have a uniform structure and length for each object type. This improves readability and makes it easier for you to find objects. It also simplifies the automatic evaluation of object names in the case of dynamic objects. Make sure that the static part of the name is not too long; this also improves readability, for example, in process schedules that only display the start of the object names.
A dynamic part that describes the task.
Unique separators consistently used to identify the different parts of the object name.

Example

Naming Concept for Individual Objects

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

SYS

Prefix that identifies objects that can be used globally across the Client. Modifying them is restricted to a specific User Group
AA

Country code consisting of two digits, ISO 3166-compliant.
BBBB

Department (four digits).
CCCC

Standard object type abbreviation (OBP, JOBS, JSCH, etc.).
DDD

Platform (three digits).
DESCRIPTION

User-defined text that describes the task
. _ #

Separators

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

SYS.LOGIN#WINDOWS

Global Login object for all Windows Agents
SYS.CALE#PRODUCTION

Global calendar for production
UK.FIAC.JOBS_UNX#MONTH_END_CLOSE$STEP1

Unix job step 1 for monthly settlement of the Financial Accounting Department in the UK
UK.FIAC.JOBP#MONTH_END_CLOSE$MASTER

Master Workflow for monthly settlement of the Financial Accounting Department in the UK
UK.FIAC.SCRI#MONTH_END_CLOSE$CHECK_FILES

File checking script for monthly settlement of the Financial Accounting Department in the UK

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:

SYS.INC#JOBS_UNX.PRE

Include for the pre-script card of the UNIX Job template
SYS.INC#JOBS_UNX.SCRI

Include for the script card of the UNIX Job template
SYS.INC#JOBS_UNX.POST

Include for the post-script card of the UNIX Job template
SYS.CALL#OPERATING

Include for the attribute card of the Workflow template (‚Result evaluation per single task‘)

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:

<AA>.<BBBB.CCCC_DDD>#DESCRIPTION

General jobs
<AA>.<BBBB.CCCC>_DDD>#<report>@<variant>#DESCRIPTION

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