Objects in Client 0

Before reading this section, make sure you have read the basic information about objects. For more information, see Basics Before We Start.

This page includes the following:

Overview

Some objects are stored and maintained centrally in Client 0. These objects are typically managed by system administrators and are valid for the entire system. Developers and object designers can then select and use them while defining objects, provided they have at least Read rights to those objects. Login (LOGIN), Connection (CONN) and Time Zone (TZ) objects are examples of these objects.

Certain objects, such as Connection and Login objects, contain data that is required by executable objects and are necessary to set up the system. They contain the necessary credentials and logging data that Job objects need to communicate with the target system. For example, you cannot communicate with Agents without having Login objects.

Other objects, such as Calendar and Time Zone objects, provide time frames, thus allowing developers and object designers to build accurate schedules and time conditions. You do not have to create them for the purposes of this Getting Started, but it is important to know the role they play from the beginning.

Important!

Do not move the folders that contain the objects supplied with the Automation Engine. Objects of system Client 0000 will be deleted when you update your system regardless of where they are stored in the folder structure. A new folder structure will be created during the updating process that includes the supplied objects. This means that you cannot permanently change this part of the folder structure.
Note that searching and selecting Agent objects and Server objects will only be successful in the system client.
If you delete or rename an object in the system client, the system will not check whether the affected object is also used in other clients.

Read the following topics to learn more about defining objects and the Client 0:

Login objects store the login information that Agents need to execute the objects on the target systems. These objects allow you to enter and manage all the passwords centrally and safely.

You do not have to remember the passwords, but simply assign the executable objects the Login object that contains them. The passwords are typically stored in the database but you can use an external application or password vault to store them.

Read the following topics to learn more about Login objects and password vaults:

Connection Objects

Connection objects enable the communication between the Automation Engine and solutions such as Jobs, SAP agents, SQL agents, VARA objects, etc. As a system administrator, you create the Connection objects that developers and object designers use to define executable objects.

Read the following topics to learn more about Connection (CONN) objects:

Connection (CONN)

Time Zone Objects

Time definition is essential when an Automation Engine system is used in several time zones in which interconnected tasks must run. By default, all Automic Automation components use the standard UTC time zone This time zone is also used when creating an object, unless they have a Time Zone object assigned.

The default time zone of the system is defined in Client 0. As a system administrator, you can add further Time Zone objects either in Client 0 or in the individual Clients. Developers and object designers can then assign the available Time Zone objects to the objects they create.

Time Zone (TZ) objects take care of the following:

Translating UTC into the local time, which is displayed in the user interface and that can be used in tasks, script elements, etc.
Converting the time in which an operation has been performed into the internal UTC.
Calculating time changes due to switches to Daylight Saving Time or Standard Time. This is extremely important, as UTC does not consider Daylight Saving Time changes.

Important! The name of Time Zone objects cannot be longer than 8 characters.

Read the following topics to learn more about Timezone objects:

Calendar Objects

You define and maintain company-wide Calendar objects. Developers and object designers can then assign Calendars to objects to apply date conditions to them. These conditions determine when the objects are executed and when they are skipped.

Important! Calendars are only useful after you have assigned them Calendar Events

Calendar objects are containers for Calendar Events which are a set of rules that result in selecting certain days in the Calendar. You can reuse Calendar Events and add as many as you need in a Calendar object. However, a Calendar must contain at least one Calendar Event. Calendar Events cannot be accessed without opening one of the Calendars in which they are being used. Creating multiple simple Calendars that contain individual Calendar Events (non-recurring, weekly, monthly, yearly, group, offset) can be helpful.

Defining Calendar Objects can be compared to defining different date/time layers and can cover simple through highly complex scenarios, depending on the combinations you use.

Read the following topics to learn more about Calendar objects and Calendar Events: