Automic SaaS Basic Terms and Concepts

Non-Production and Production Environments

An Automic SaaS subscription includes two environments:

• Non-production environments

  A non-production environment is your development and testing system.

  Here is where you can plan and create the objects and Workflows that you want to implement and then test them under productive conditions without putting your business processes at risk.

• Production environments

  A production environment is your live system where you execute your daily business processes.

  Important! Never introduce changes that you have not tested thoroughly in a non-production environment to your production environment.

System Name

Each environment provided in an Automic SaaS subscription has its own unique system name. The system names have been provided to your system administrator in the Welcome to Automic SaaS letter.

The Automation Engine, the Agents and the TLS Gateway in an environment must use the same system name in their configuration (INI) files. The server processes names are build dynamically and also include the system name, so that they are easily recognizable.

Automation Engine

All throughout the documentation you will read references to the Automation Engine (AE). The AE is Automic Automation's backend. As an Automic SaaS customer, you do not need to worry about it as Broadcom takes care of all AE maintenance and configuration activities.

Server Processes: JCP and REST

A JCP is a communication process (CP) implemented in Java and is used to establish the connection between different components of an Automic Automation system, such as the Automation Engine, the Automic Web Interface, and the Agents.

A REST Process provides a REST endpoint for the Automation Engine which is relevant for the AE REST API and the Java API. Several important functions in Automic Automation, such as triggering and monitoring executions and the advanced object search, depend on the REST process being up and running.

Since Automic SaaS runs in containers, an ingress exposes the relevant endpoints so that the JCP and REST processes can be reached.

For more information, see:

• Java Communication Process.

• REST Process

• JCP_ENDPOINT

• REST_ENDPOINT

UC_SYSTEM_SETTINGS

The UC_SYSTEM_SETTINGS is a predefined Client variable (VARA) object and contains settings that apply throughout an entire Automic Automation system. This variable is supplied in Client 0 and can only be changed there by a system administrator.

The Automation Engine monitors all the values that are included in this variable and notifies system administrators when a user attempts to store invalid values in this variable. For more information, see UC_SYSTEM_SETTINGS - Systemwide Settings.

Note: Client 0 in Automic SaaS has a restricted functionality because many of the usual Client 0 activities are performed by Broadcom. That is the reason why they are not available to you. For more information on the Client 0 in Automic SaaS, see Client 0 in Automic SaaS.

Automic Web Interface (AWI)

The Automic Web Interface is a browser-based application that gives users access to all the program areas and functions that they are entitled to. The interface provides all standard web browser functions plus multiple proprietary navigation features. The following topics describe the AWI:

• Understanding the Automic Web Interface

• AWI: Role-Oriented User Interface

• Preparing Your Browser

• Walkthrough of the Dashboards

• Walkthrough of the Administration Perspective

• Walkthrough of the Process Assembly Perspective

• Walkthrough of the Process Monitoring Perspective

• Walkthrough of the My Catalog Perspective

• Keyboard Navigation

• Keyboard Shortcuts

• Tips and Tricks in AWI

Clients

In Automic Automation, tenants are called Clients, which are the largest organizational units in an Automic Automation system. They define self-contained environments that are configured to depict your business. As an Automic SaaS administrator, implementing the authorization policy already begins when planning and creating the Clients, which is where you allocate your Users, User Groups, objects, etc. How you define your Client landscape depends on the structure of your company and how you decide to depict it.

Users within a Client can open and work with all the folders and objects in that Client unless you restrict their authorizations and privileges.

An Automic SaaS subscription includes two environments. Each environment serves two tenants (called Clients):

• Client 0

  This is the administration Client, that is, a non-production Client where no processing happens. Automic SaaS administrators install Agents, assign them to Client 100 and customize the centralized configuration of the environment here.

• Client 100

  This is the production Client provided by default. Production Clients is where users design automation and operators monitor processes.

For more information, see Clients and Users in Automic SaaS.

UC_CLIENT_SETTINGS

The UC_CLIENT_SETTINGS is a predefined Client variable (VARA) object that allows you to store settings specific to a Client, such as its be behavior when started, access control, user passwords, logs and so on.

These settings are displayed in the respective Client object, where they can be edited, see UC_CLIENT_SETTINGS - Various Client Settings.

User Groups

User Groups are the basis of an efficient authorization system. You assign them CRUD rights to specific folders and objects and privileges to functions.

For example, if you set up your Clients to represent the departments at your company, the User Groups within a Client could then depict groups of Users that share the same roles and who must therefore access the same folders and objects with the same (or very similar) rights and privileges.

If you apply this structure to your Clients/User Groups, we strongly recommend to also define and apply naming conventions and patterns to your folders and object names. This helps you easily recognize to which User group an object or a Folder belongs. For example, you could define that objects and folders that are relevant for the developers in your company should start with the DEV_ prefix.

For more information, see:

• User Groups (USRG)

• Example: Defining Authorizations at User Group Level.

Users

You can create Users directly in your production Clients. All Users defined in your business Clients are also visible in Client 0.

When configuring the User objects, you can assign them authorizations to specific folders and objects, CRUD rights and privileges to functions in exactly the same way as you do for User Groups. However, we strongly advice against it. Doing it at User Group level considerably reduces maintenance activities (you define the rights and privileges only once and simply assign Users to the User Group) and improves the transparency of your authorization policy.

For more information, see Assigning Users to User Groups.

My Catalog

To further facilitate the access of Users to the folders and objects to which they have been granted rights, you can create User Catalogs based on the User Group definitions.

When you add a User Group to your system, it is automatically available on the User Catalog list of the Process Assembly perspective. You add the folders and objects that this particular User Catalog will have access to; the authorizations and rights are already specified in the User Group definition.

This determines which Folders and objects the users will see and what they can do with them when they open their My Catalog perspective.

For more information, see:

• Configuring the User Catalog

• Example: Defining User Catalogs

• Walkthrough of the My Catalog Perspective

Agents

Agents are programs that run on the target system, which can be either an Operating System or an application. They establish the connection between the Automation Engine and those target systems, start the execution of tasks and make both their monitoring and the corresponding reporting possible. Agents create log files that record what occurs.

As an Automic SaaS administrator, you are responsible for installing, configuring and maintaining the Agents. You also assign Agents to the Clients that they should have access to and you define the authorizations that they should have in each Client.

For more information, see:

• Installing and Configuring Agents for Container-Based Systems

• Agents (HOST)

• Assigning Clients to Agents

• Agent Groups (HOSTG)

Agent Authentication

Authenticating the Agents allows you to confirm the authenticity of the communication partners. This is an essential step to avoid unauthorized access to your system. System administrators apply the level of security that is appropriate for your company.

The authentication method used in Automic SaaS is LOCAL (Server). Once the method is defined, the Agents are authenticated manually in the Administration perspective to guarantee that the Agent is not a program of a potential hacker.

For more information, see:

• Agent Authentication

• Agent Authentication: Watch the Videos

• Setting the Authentication Method

• Authenticating Agents and Withdrawing the Authentication

Objects

Automic SaaS has an object-oriented design. Objects are entities that work together to form coherent automated sequences. Processes in Automic SaaS are combinations of those objects.

You define an object once and you can reuse it across your system. Suppose you have a backup process that must run on all database servers, which can be located on-premise, in a private cloud or a mix of both. A full backup runs once a week and an incremental backup runs every second day. Instead of having to create hundreds of individual tasks, Automic SaaS lets you create and run a single object and reuse it (and, if necessary, customize each usage) in as many processes as needed.

For more information, see:

• Object Types

• Defining Objects

Tasks

Tasks are objects that are being or that have been executed. A task has a runID that uniquely identifies it. You work with tasks in the Process Monitoring perspective. For more information, see Tasks.

Jobs

A Job is a unit of work that is Agent-specific. A Job executes commands on computers or in enterprise business solutions (SAP, PeopleSoft, Oracle Applications, etc.). These solutions differ from each other, therefore specific Job templates are available for each of them. This means that there are SAP Jobs, PeopleSoft Jobs, Windows Jobs, and so forth, depending on the target system that they address. Jobs are always assigned to Agents. They always need a Login object that submits the necessary credentials to the target system (Agent).

For more information, see Jobs (JOBS).

Workflows

Workflows are key players in process automation. They are also objects and they orchestrate the automatic processing of other objects. You assemble processes (objects) in a Workflow and connect them. This way, you determine the sequence with which they will be processed (executed in Automic Automation terminology). By defining specific configuration settings per object in a Workflow, you determine the conditions under which the objects are executed.

For example, a Workflow could do the following: stop an application, update, restart and run reports. These four Jobs must execute in a certain sequence. You insert the Jobs in the Workflow and link them with a line. It is possible to embed a Workflow into another.

For more information about Workflows, see Workflows (JOBP).

Schedules

Schedules are core automation objects too. Through Schedules, you design event and time-driven task management. You collect tasks in a Schedule object and define the scheduling parameters that will govern regular intervals at which they should be executed.

For more information about Schedules, see:

• Schedules (JSCH)
• Example: Scheduling Tasks with Time and Calendar Conditions

File Transfers

File Transfers are similar to Jobs but they allow automated Agent-to-Agent processes without an FTP server. They ensure that the right data is sent automatically and securely to the right location at the right time. File Transfers are accurate, consistent and can be fully encrypted along every step of the process. Comprehensive reports guarantee auditing and transparency.

For more information about Automic Automation's file transfer capabilities, see:

• File Transfers (JOBF)
• Secure File Transfer Protocol

Automation Engine Scripting

Automic SaaS has its own proprietary scripting language to help you code workload processes. For more information about the Automation Engine scripting language, see:

• Scripting and the Automation Engine Scripting Language

• Automation Engine Script Reference

Automatic Processing (Executing)

Once automated processes are designed and scheduled, you execute them. Object execution can be triggered manually or automatically.

For more information, see:

• Executing Objects

• Execution Options

Monitoring and Auditing

Automic SaaS provides full reporting and auditing capabilities. When executing objects, the system writes comprehensive output files and reports that track all processes. The reports are organized to show what is happening across the enterprise. The can be easily accessed from the AWI.

For more information about Automic SaaS auditing capabilities, see:

• Walkthrough of the Process Monitoring Perspective
• Monitoring Tasks
• Understanding the Reports
• Execution Data

Execution Data

Every execution run performed in your system is recorded and stored in various forms, one of them being the lists of Executions. They provide detailed information about what happened during each execution of each task. They are a key audit feature that guarantees full audit capability. The Executions lists help you monitor and troubleshoot your processes.

For more information, see Execution Data.

Reports

When objects are executed, your system generates output files and reports that you open from the user interface. Combined with the Execution Data, these reports provide comprehensive information about the status and the history of your executions. This information tracks all processes and allows you to control and monitor tasks, ensuring full auditing capability.

Broadcom stores this data for the period of time stipulated in the Data Retention, Archiving and Backup section of the SaaS Listing document that your company has access to. Once this period of time has elapsed, the data are deleted.

Messages

Your system continuously delivers messages that provide information about the execution of tasks and about the status of processes. You can see these messages in the Messages console that you open by clicking the message icon in the menu bar. You need a specific right to open it.

Administrator and security messages behave a bit differently. These messages remain in the list as long as they remain unread. Unread means that you have not opened the Messages pane since the message was created.

For more information, see Understanding the Messages Console.

Analytics

Analytics is an Automic Web Interface plugin that uses objects in dynamic dashboards to provide a detailed representation of the status quo of your business processes. You access the Analytics dashboards through the home button at the top left corner of your screen.

For more information, see:

• Analytics and Reporting

• Walkthrough of the Dashboards

Telemetry

Automic Automation collects and securely sends telemetry data to Broadcom. For Automic SaaS instances, the system sends the number of successful job executions for each Client in both the non-production and production environments.

No Personally Identifiable Information (PII, as legally defined) covered under GDPR is transmitted. For more information about how your information is collected and used, read our Privacy Policy.

For more information, see Usage Data (Telemetry) Configuration.