Naming Conventions

Deciding upon and consistently applying naming conventions for your Automation Engine objects will help you in your daily work as well as in maintenance tasks, easy recognition and understanding of alerts, security issues, transporting objects and processes from one system to another, etc.

This topic 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 will not be 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 be able to smoothly 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:

The following object-specific restrictions must be taken into account:

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.

The table below is an example of how to divide up the number ranges for your different areas. The client numbers used for each department or customer are uniformly different in the testing, the development, and in the production systems. This type of numeric allocation is useful when it comes to defining tasks, as tasks are able to determine on which Client (that is, in which system) they are running. Given a logical numbering concept, tasks can therefore configure the required parameters automatically. This can eliminate the need for manually configuring the tasks for each separate environment.

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

Naming Conventions for Agents

When it comes to define a naming concept for Agents, take into account that there are two types: Agents for Operating Systems and Agents for Applications.

Agents for Operating Systems

Using the name of the system on which the Agent is installed is a good choice here. Alternatively, you can use the primary DNS name of the system, in case this is not the same as the system name

This way, you can immediately recognize on which Operating System a client is running; this helps a lot when allocation creating and allocating Operating System jobs.

One potential disadvantage of this approach is that should the system be 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 also be time-consuming. To prevent this from becoming a major issue, the Agent names should be stored centrally for each Client or Process (in Automation Engine 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 better distinguish Agents for applications from Agents for Operating Systems, these should be named with a prefix that uniquely identifies 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:

Object name

 Description
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, we recommend to use a prefix or suffix to distinguish these from non-cluster Agents. For example:

Object name

 Description
P01_UNX_CLUSTER_A UNIX Agent for SAP P01 instance in cluster "A".

P02_WIN_CLUSTER_X

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:

Example

Naming Concept for Individual Objects

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

Chunk of information in the object name

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

Object name

 Description
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 table provides examples of how to name and use global objects:

Object name

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

Object name (syntax)

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

Useful Links

This topic contains references to a number of functions you might want to know more about.