85DSR2008 STD G1

CA Workload Automation DE
r11.3: Foundations 200
Student Guide
85DSR2008S
85DSR2008SG1

Student Guide — CA Workload Automation DE r11.3: Foundations 200 Page — i

‐ PROPRIETARY AND CONFIDENTIAL INFORMATION ‐

© 2016 CA. All rights reserved. CA confidential & proprietary information. For CA, CA Partner
and CA Customer use only. No unauthorized use, copying or distribution. All names of
individuals or of companies referenced herein are fictitious names used for instructional
purposes only. Any similarity to any real persons or businesses is purely coincidental. All
trademarks, trade names, service marks and logos referenced herein belong to their respective
companies. These Materials are for your informational purposes only, and do not form any type
of warranty. The use of any software or product referenced in the Materials is governed by the
end user’s applicable license agreement. CA is the manufacturer of these Materials. Provided
with “Restricted Rights.”

Student Guide — CA Workload Automation DE r11.3: Foundations 200 Page — ii

Table of Contents

Course Objectives ................................................................................................................................................. 5

1. Describe the CA Workload Installation ............................................................................................................. 6
Describe the Product Architecture .................................................................................................................... 7
Case Study ....................................................................................................................................................... 20
Best Practices .................................................................................................................................................. 21
Module Summary ............................................................................................................................................. 22

2. Manage the Desktop Client ............................................................................................................................. 24
Install the Desktop Client ................................................................................................................................ 25
Navigate Perspectives and Views .................................................................................................................... 33
Module Summary ............................................................................................................................................ 46

3. Manage the Server .......................................................................................................................................... 48
Describe Topology ........................................................................................................................................... 49
Manage the Server .......................................................................................................................................... 64
Case Study ....................................................................................................................................................... 81
Best Practices .................................................................................................................................................. 82
Module Summary ............................................................................................................................................ 83

4. Create Applications ......................................................................................................................................... 85
Define an Application ...................................................................................................................................... 86
Create Applications ......................................................................................................................................... 89
Module Summary .......................................................................................................................................... 122

5. Create CA Workload Automation DE Events ................................................................................................. 125
Define CA Workload Automation DE Events ................................................................................................. 126
Create a CA Workload Automation DE Event ................................................................................................ 129
Module Summary .......................................................................................................................................... 160

6. Monitor and Control Active Workload .......................................................................................................... 163
Monitor and Control Active Workload .......................................................................................................... 164
Module Summary .......................................................................................................................................... 192

7. Manage Agents and Agent Groups ............................................................................................................... 194
Define CA Workload Automation DE Agents ................................................................................................. 195
Define Agent Groups ..................................................................................................................................... 206
Best Practices ................................................................................................................................................ 214
Module Summary .......................................................................................................................................... 215

8. Define Calendars ........................................................................................................................................... 217
Define Calendars ........................................................................................................................................... 218
Module Summary .......................................................................................................................................... 229

9. Manage Variables and Resources ................................................................................................................. 231
Manage Variables .......................................................................................................................................... 232
Work with CA Workload Automation DE Resources ..................................................................................... 246
Module Summary .......................................................................................................................................... 258

Student Guide — CA Workload Automation DE r11.3: Foundations 200 Page — iii

10. Describe CA Workload Automation DE JavaScripts .................................................................................... 260
Identify JavaScript Components .................................................................................................................. 261
Module Summary ........................................................................................................................................ 280

11. Employ Other Features ............................................................................................................................... 282
Define Notifications ..................................................................................................................................... 283
Create CA Workload Automation DE Alerts................................................................................................. 291
Generate Forecast Reports .......................................................................................................................... 298
Best Practices ............................................................................................................................................... 305
Module Summary ........................................................................................................................................ 306

12. Manage Users using LDAP ........................................................................................................................... 309
Define the LDAP Server................................................................................................................................ 310
Module Summary ........................................................................................................................................ 321

13. Manage CA Workload Automation DE with Web Services ......................................................................... 323
Define Web Services .................................................................................................................................... 324
Module Summary ........................................................................................................................................ 330

Course Summary ............................................................................................................................................... 332

Student Guide — CA Workload Automation DE r11.3: Foundations 200 Page — iv

Click (above) to accept all the below terms and begin the course. If you are resuming the
course, click .
© 2016 CA. All rights reserved. CA confidential & proprietary information.

For CA, CA Partner and CA Customer use only.
No unauthorized use, copying or distribution.
All names of individuals or of companies referenced herein are fictitious names used for
instructional purposes only. Any similarity to any real persons or businesses is purely
coincidental.
All trademarks, trade names, service marks and logos referenced herein belong to their respective
companies.
These Materials are for your informational purposes only, and do not form any type of warranty.
The use of any software or product referenced in the Materials is governed by the end user’s
applicable license agreement.
CA is the manufacturer of these Materials.
Provided with “Restricted Rights.”

Student Guide — CA Workload Automation DE r11.3: Foundations 200 Page — 1

CA Workload Automation DE r11.3: Foundations 200


The course outline is shown on the left of the page.
 You use the Expand and Collapse buttons to open and close the sections of the course.
 The sections will include topics which will either be conceptual topics or lab topics.
 A section might also include review questions.
When a conceptual topic or lab topic is selected, click the Try It! button to launch the topic.
 When a Review Questions entry is selected, this will change to be a Start button.
When you have opened a topic, each frame has a text box containing explanations of the
current frame content and how to advance to the next frame.
 You will also have access to the Actions list which includes options for navigating. The
following screenshot shows the Actions list:
Selecting a topic will highlight it and audio will automatically play if it exists.

There are indicators to the left of each topic to show the status:
 Completed (fully filled box)
 Partially completed (half‐filled box)
 Not Started (empty box)

In order to complete a course, a student will need to complete all topics within the course,
including review questions.
 A section will only show as completed when you have clicked the section and run
through all the topics and review questions.


Course Objectives
After completing this course, you will be able to:
 Identify the product architecture and the relationship between each component in CA
Workload Automation DE.
 Work with the Desktop Client to more efficiently define, monitor, and control enterprise
workload from a single point of control.
 Identify the server administration and maintenance settings to enable you to achieve
better server performance.
 Create applications to logically group processes.
 Create CA Workload Automation DE events to control applications.
 Monitor and control active workload to regulate your workload.
 Automate workload on different servers and distribute workload between similar
platforms and operating systems by identifying the components, features, and functions
of agents and agent groups.
 Work with calendars to meet your business needs.
 Manage variables to streamline and simplify applications to decrease overhead.
 Work with scripts to learn how to extend the capabilities of CA Workload Automation
DE.
 Create CA Workload Automation DE alerts and generate forecasting reports so you can
better automate and control workload using CA Workload Automation DE.
 Define an LDAP server to enable you to retrieve and permit a set of users to log in to CA
 Manage CA Workload Automation DE with Web Services so you can create, update,
invoke, monitor, and control workload.


Describe CA Workload
Automation DE Installation
To help ensure a return on your investment in CA Workload Automation DE, you
must have foundational knowledge of the product architecture. This knowledge
will enable you to conceptualize implementation as it applies to your enterprise
so you can take advantage of the full functionality of the product.

After completing this module, you will be able to:
 Describe the product architecture

Why you need to know:

 Being familiar with the CA Workload Automation DE product architecture
will enable you to plan for and execute your business solution
implementation to suit the needs of your enterprise.


Describe the Product Architecture


CA Workload Automation DE Single‐
Server Architecture

This diagram shows the primary components in a single‐server CA Workload Automation DE
installation.

Being familiar with the CA Workload Automation DE product architecture will enable you to
plan for and execute your business solution implementation to suit the needs of your
enterprise.

The three components pictured are:
 CA Workload Automation DE Server
 Agents
 CA Workload Automation DE Desktop Client
RDBMS stands for relational database management system.


CA Workload Automation DE Single‐
Server Overview

The CA Workload Automation DE architecture comprises several components. In the following
slides, you will examine them in more detail.

CA Workload Automation DE Server
Agents
CA Workload Automation DE Desktop Client
Web Client
Web Services


CA Workload Automation DE Server

The server is the core of the CA Workload Automation DE system.

The server processes and directs all incoming communication from the Desktop Client, agents,
and database.

The server requires a relational database for:
 Message processing
 CA Workload Automation DE High Availability
 Storing server configuration files, resource definition
files, and historical reporting data
The relational database types permitted are:
 Oracle
 Microsoft SQL Server (SQL Server)
 DB2 (AIX and zLinux only)

The server supports Linux, zLinux, UNIX, and Windows platforms.

See the Release Notes Guide for the most current operating systems, product versions, JRE
release, and database versions.


Agents

Agents are applications that extend
batch workloads across multiple
operating systems.

Agents automatically run batch
workloads and monitor its
progress.

Agents communicate with the CA Workload Automation DE Server through TCP/IP using
encrypted messaging. The available agent platforms are:
 UNIX (Sun, AIX, HP, HP Itanium)
 Linux (Red Hat, SuSE, z/OS)
 Windows
 AS/400
See the individual Agent Release Notes for current operating system requirements. Other
platforms are available; see the Product Release Notes.


CA Workload Automation DE Desktop
Client

The Desktop Client is the GUI
for defining, monitoring, and
controlling enterprise
workloads.

The Desktop Client enables you
to drag and drop workload
definitions, manage calendars,
and monitor and control
workloads.

The Desktop Client runs on
Windows platforms.

The Desktop Client includes the administrator’s tools for:
 Defining roles and privileges
 Defining topology
 Diagnosing problems with CA Workload Automation DE


Web Client

The Web Client enables you to connect directly to the server using a standard web browser.

The Web Client enables you to monitor and control workloads in your production environment
and quickly respond to exceptional situations.

The Web Client consists of two components:
 Workload Director
 Workload Views

The Web Client is not created to be a full interface but is meant to be used to monitor and
control applications. In addition, it is only intended for users who do not need to monitor all
jobs but a subset of jobs.

The CA Workload Automation DE Web Client Workload Views are similar to Custom Views in
the CA Workload Automation DE Desktop Client Monitor perspective.

The components of CA Workload Automation DE architecture must communicate and share
information to automate your workloads successfully.


Web Services

By using Web Services, you do not need proprietary software to integrate the server with other
services in a business process.

You can program any software application that is configured to work with Web Services to
create, update, invoke, monitor, and control CA Workload Automation DE workloads.

For example, you can install CA Workload Automation DE Web Services and program a
customized internal web interface to integrate with CA Workload Automation DE.


Communication

Communication between each component is performed through messaging.
 All connections are through TCP/IP.
 Messages contain information needed by each component to process work.
There is IPv4 and IPv6 support for the CA Workload Automation DE Server, agents, CA
Workload Automation DE Desktop Client, CLI, and Web Services.
 With the support for IPv6 configuration and communication, your CA Workload
Automation DE implementation will be able to employ 128‐bit addresses and leverage a
larger address space.

All messages are encrypted.

The server, client applications, and installers for these applications support IPv6
configuration and communication.

The communication between the server and connecting agents also supports IPv6
communication because the agent definition permits IPv6 addresses. Currently, the IP fields
do not have any input limitations because they have to support free‐form text for DNS
names.

In the event that the active server fails, CA Workload Automation DE is equipped with failure
detection and recovery capabilities by a process named failover.


Failover and High Availability

Failover is the process by which a Shadow Server takes over for the primary server in the event
of a detected server failure.

CA Workload Automation DE High Availability is the CA Workload Automation DE failure
detection and recovery process.

CA Workload Automation DE High Availability requires a primary server, a Shadow Server, and a
common RDBMS.

Configuring and implementing failover will save you time and resources by helping ensure
that communication between components is not lost due to a primary server failure. You will
be able to avoid unnecessary downtime and troubleshoot as necessary without interrupting
essential business processes.


Failover and High Availability Continued

When the Shadow Server takes control:

1. Agents are automatically notified
2. The Desktop Client automatically switches to the Shadow Server
3. New connections automatically go to the Shadow Server

When both servers are running:
 Primary:
 Controls the workload
 Interacts with agents
 Shadow:
 Monitors the active server
If the active server fails, workload processing switches from the active server to the
monitoring server (failover).


Patches
CA Workload Automation DE and Agents

Two types of patches are available for CA Workload Automation DE and its agents:
 Service packs (SP) – Major updates
 Are platform dependent
 Usually include a JRE update
 Can be applied on top of any base version or previous update

 Incremental patches – Minor updates
 Are released after an SP
 Require the previous SP as a prerequisite
 Include all updates since the last SP

When applying patches, consider the following:
 SP3 can be applied to any previous build, for example, to SP1 or SP2.
 SP3 incremental 1 can only be applied to SP3.
 SP3 incremental 3 will apply to all updates since SP3


Review Question

Question

Which component in a CA Workload Automation DE installation
extends batch workloads across multiple operating systems?

Response

A. Agents
B. Web Client
C. Web Services
D. CA Workload Automation DE Server
E. CA Workload Automation DE Desktop Client

The answer is: Agents

Agents are applications that extend batch workloads across
multiple operating systems.


Case Study

SCENARIO Nordole Industries wants to manage its growing workload volumes. Operations
wants to reduce the cost and complexity of managing workloads. Management
wants to meet service‐level objectives of mission‐critical workloads and satisfy
compliance and audit requirements.
PROBLEM The solution must efficiently be able to run 50,000 to 100,000 jobs a day. The
scheduling application must be able to work with PeopleSoft and Oracle
databases, and run batch operations on various UNIX, Linux, and Windows
platforms.
SOLUTION CA Workload Automation DE can run a high volume of jobs across several
platforms and business applications. The CA Workload Automation DE agent
provides integration with several ERP, business, and database applications.


Best Practices

When you plan to install CA Workload Automation DE, the
64‐bit version is always recommended.
 One advantage with the 64‐bit version is that it
permits a larger (greater than 2 GB) heap size.
CA Workload Automation DE supports several database
types.
 The database connection must be reliable and
constant.


Module Summary
This module showed you how to:
 Gain a basic understanding of the product architecture

 Install a CA Workload Automation DE Server
on Linux

In the next module, you will:
 Manage the Desktop Client


Assessment Question

Question

Which component is the core of the CA Workload Automation DE
system?

Response

A. Agent
B. Server
C. RDBMS
D. Desktop Client
E. High Availability

The answer is: Server

The correct answer can be found in task 1, page 5.


Manage the Desktop Client
To gain a better understanding of how to use CA Workload Automation DE, you
will install the Desktop Client and explore the GUI. You will also become familiar
with product‐specific terms and functionality of this business solution.

 Install the Desktop Client
 Navigate perspectives and views


 Installing the Desktop Client enables you to communicate with the server.
 Understanding how to use perspectives and views will enable you to
customize CA Workload Automation DE to the needs of your enterprise.


Installing the Desktop Client

Installing the Desktop Client enables you to communicate with the server.

To install the CA Workload Automation DE Desktop Client, you need to fulfill the following
prerequisites:
 Host running a Microsoft Windows operating system

 Administrator access to install the client

 Network connectivity to the CA Workload Automation DE Server


Connecting to the Desktop Client

To perform tasks with CA Workload Automation DE, the Desktop Client must be started.
 The Desktop Client:
 Uses views and perspectives to schedule, monitor, and control workloads
 Provides the interface to create user roles and privileges for login

 Each user has distinct
roles and privileges:
 The ADMIN role
cannot create
workloads.
 The
SCHEDMASTER
role cannot
perform
administration
functions

If the Connection window does not open, click Connect. You will be prompted for the server
to connect to and then asked to provide a user name and a password.

Certain functions can be performed offline. Offline functions are primarily used to create
workflows.

Best practice is to create new users and change the password of the default user names.


Managing Multiple User Environments

You can manage different user
environments through the
Application Workspace tab.
 After connecting to the
user environment, the
server tree turns green,
indicating that the
Desktop Client is
connected.

To disconnect:
1. On the Application Workspace view, right‐click the connection.
2. Click Disconnect.
After disconnection, you can log in as a new user.


Roles
Roles are assigned to users.
 Security is maintained through a set of security profiles.
 Security profiles represent a user or a group, which is a collection of users.
 Security profiles have associated permissions.
This screenshot shows the privileges for the SCHEDGRP group:
Permissions define the level of access available to a user. Examples include:
 Which applications the user can define or control
 Which agents jobs can be scheduled on
 Calendar and resource access
The default group definitions are:
 ADMINGRP is defined to permit full access to administrative functions.
 Add or update agents to the topology.
 Add or update users and group permissions.
 Control and troubleshoot problems with CA Workload Automation DE.
 EVERYONE is a group that every user is automatically assigned to. Users associated to
this group can view topology information, view global variables in default context,
and read the system calendar.
 OPERGRP is defined to only monitor and control workloads.
 SCHEDGRP is defined to permit full access to scheduling and monitoring functions.
 Define or update applications, resources, and calendars.
 Monitor or control workloads.


Patches and Upgrades

Patches are available for the CA Workload Automation DE Desktop Client.
 The CA Workload Automation DE Desktop Client can:
 Be configured to update automatically
 Access the remote file share for patches

 Updates and patches can include JRE updates.


Labs: Guided Practices

In the following Guided Practice labs, you
will:

See lab 2‐1 Install the Desktop Client.

 Manage connections for different
roles and privileges
See lab 2‐2 Manage Connections for
Different Roles and Privileges.

Note: If you are having an issue with a lab,
see the corresponding See It! Guided
Practice lab video that follows this slide.


See It! Guided Practice Lab Video

In this See It! Guided Practice lab video,
you will see how to:

To open the lab video, in the left pane,
double‐click Lab 2‐1 Install the Desktop
Client.

Note: To advance to the next frame in the video,
press Enter. To move to any frame, use the
navigation bar along the bottom of the window.



 Manage Connections for Different
Roles and Privileges

double‐click Lab 2‐2 Manage Connections
for Different Roles and Privileges.



Navigate Perspectives and Views


Navigating Perspectives and Views

Understanding how to use perspectives and views will enable you to customize CA Workload
Automation DE
to the needs of your enterprise.

 Perspectives are visual containers for a set of views and editors controlling what
appears on certain menus and toolbars.

 Perspectives:
 Can be changed by adding views, changing size and position, and so on
 Define visible action sets, which you can change to customize a perspective

 You can save a perspective to make your own custom perspective for later use.

Views support editors and provide alternative presentations and ways to navigate the
information in your workbench.

Editors are meant for the primary focus of attention and show the main content of your
application.

The seven default perspectives are:
 Define: Add or update application definitions.
 Monitor: Monitor or control active workloads.
 Services: Maintain events, calendars, resources, and alerts.
 CLI: Enter commands at the CLI.
 Admin: Maintain users, groups, and topology.
 Report: Create and run reports in the Desktop Client interface.
 SAP Tools: Dynamically interact with SAP.


Perspectives

Define
Monitor
Services
CLI
Admin
Reports


Define

The Define perspective is also known as the Editor perspective and is visible in Editor view.

The Define perspective in Editor view enables you to:
 Work with applications that contain one or more jobs and workload objects
 Download an existing application, create a new application, or open an application
from a file
 Rearrange jobs and dependencies


Monitor

You can monitor perspectives with custom views.

The Monitor perspective enables you to:
 Monitor and control active workloads
 Create and add custom view windows
To perform an action on a job, right‐click the job and click the appropriate action.


Monitor Continued

You can monitor perspectives with flowchart views.

From the Monitor perspective, you can see selected objects in a flowchart view or at the
application level. You can also view selected objects in a custom row and column‐based view.

In the flowchart view, jobs are monitored in a flowchart. You can use the same right‐click
commands available as with custom views.


Services

The Services perspective enables you to create and maintain calendars, resources, events, and
alerts.

The Services perspective also enables you to:
 Schedule forecasts
 Create and maintain global variables
 Create a repository for JavaScript
The Services perspective views and editors are:
 Alerts: Defines and maintains alerts
 Calendars: Defines and maintains calendars
 Events: Defines and maintains events
 Forecasts: Defines and maintains the forecast editor
 Global Variables: Defines and maintains the global variable editor
 JavaScripts: Defines and maintains JavaScript
 Resources: Defines, maintains, and controls CA Workload Automation DE resources
The security rights you are assigned will determine which services are present


CLI

The CLI perspective enables users to issue commands against CA Workload Automation DE.

The CLI perspective is interactive, meaning that commands can also be performed in batch
mode.


Admin

In the Admin perspective, you can administer security for users and groups, and maintain a
topology of servers and agents.

The Admin perspective enables you to manage user rights using internal security features
and the external authentication features of Lightweight Directory Access Protocol (LDAP).

The Admin perspective also has a built‐in Simple Network Management Protocol (SNMP)
manager.


Reports

CA Workload Automation DE stores information regarding job execution in a database.
 This enhancement lets you create and run reports in the Desktop Client interface.

 From the Desktop Client, you can:
 Run predefined or canned reports
 Design custom reports using Business Intelligence and Reporting Tools (BIRT)

CA Workload Automation DE includes the following predefined reports:
 Failed_Jobs are jobs that failed over a specified time period. These include the states
FAILED, SUBERROR, SYSERROR, and DBERROR and show summary data in a bar chart
and detailed data in a table.
 Jobs_by_Application are jobs that ran in an application over a specified time period
and show a table of jobs grouped by application and generation.
 Jobs_by_State are jobs in specified states over a specified time period and show
summary data in a pie chart and detailed data in a table.
 Jobs_Run_for_Time_Period are jobs that ran over a specified time period and show
detailed data in a table.
 Jobs_Run_on_Agent are jobs that ran on specified agents over a specified time
period and show summary data in a bar chart, summary data in a table, and detailed
data in a table.
 Summary_Jobs_Run are jobs that ran over a specified month and show summary
data in a bar chart and detailed data in a table.

The Security report is used to list groups and users, with associated permissions, in a table. It
requires no input parameters but does require update access to ADMIN.Security files.


Report Design Tool

With the Report perspective, administrators can:
 Design reports

 Create a new BIRT project, which contains report design files, report libraries, or images
 BIRT is an open source software project that provides the BIRT technology
platform to create data visualizations and reports that can be embedded in rich‐
client and web applications, especially those based on Java and Java EE.
 To effectively create BIRT projects, you need to learn how to use BIRT.
 BIRT works with different data sources, for example, databases or XML files.
Note: It is not restricted to the dseries database.

 After the project is uploaded to the Desktop Client, you can run a custom report from
Services ► Reports.


Lab: Guided Practice

In the following Guided Practice lab, you
will:

See lab 2‐3 Navigate Perspectives
and Views.




 Navigate Perspectives and Views

double‐click Lab 2‐3 Navigate Perspectives
and Views.



Module Summary


 Manage the server


Assessment Question 1

Question

Which component of CA Workload Automation DE provides the
interface to create user roles and privileges for login?

Response

A. CLI
B. Desktop Client
C. Welcome Screen
D. Define Perspective

The answer is: Desktop Client



Question

Which perspective enables you to maintain events, calendars,
resources, and alerts?

Response

A. CLI
B. Admin
C. Monitor
D. Services

The answer is: Services



Manage the Server
To understand how to effectively manage the server, you will identify the
different security profiles and the permissions you can assign to them. You will
also examine the topology view and be shown how to configure server
parameters and define agents. In addition, you will learn about the CLI
perspective and the commands that can be issued from it. In the Administrator
role, you will see the features of the SNMP message viewer that help you
handle SNMP messages.

 Describe topology



 Being able to describe the various external connections that communicate
with the CA Workload Automation DE and explore internal components
and settings enables you to understand the different protocols that work.

 Understanding server administration and maintenance settings enables
you to achieve better server performance.


Describe Topology


Topology

Being able to describe the various external connections that communicate with the CA
Workload Automation DE and explore internal components and settings enables you to
understand the different protocols that work.

The Topology view provides status updates for administrators and a read‐only view for other
users.
 The Topology view is used to:
 Configure server parameters
 Define agents

 To add new agents to the Topology view, use the information in the agentparm.txt file.

 Default values for the server and local agent are set at installation and you can change
these values in the topology.

The Topology view is found in the Admin perspective.


Topology
Configure Server Parameters

You can configure server parameters for:
 Shared and instance parameters
 Configuring shared and instance parameters might require a server restart for
the changes to take effect.

 The email server


Topology
Configure Server Parameters Continued

You can also configure server parameters for:
 Failover parameters

 The SNMP Manager

Additional server parameters can be modified in the file named server.properties, located on
the server.


Topology View

To add agents to the topology:
 Select the agent platform

 Complete the agent information


Topology View Continued

To run workloads on a specific agent, you must define the user in the agent topology.
 If the user is not defined, an error message appears when the job is in the Monitor
perspective.


Server Quiesce and Unquiesce

Quiesce enables you to pause the server so that no new workload can enter the server.
 The quiesce and unquiesce capability enables you to prevent:

 The server from temporarily submitting new jobs or triggering workloads
 An agent from temporarily receiving messages from the server or running jobs

 Jobs that are running when the server is quiesced continue to run to completion, but all
active applications will pause and no new jobs are submitted.

 When you are ready to resume submitting jobs and triggering workloads, you can
unquiesce the server or specific applications or events on the server, which gives you
more control over what runs.

You can also quiesce and unquiesce agents.


Quiesce Servers and Agents
Quiesce Commands

The following quiesce CLI commands You can also access quiesce commands in the GUI.
are available:
 To quiesce a server, issue the
following command:
quiesce

 To quiesce an agent, issue the
following command:
quiesceagent agent("agent")

 To determine whether the
server is quiesced, issue the
following command:
listquiescestate

When you issue the command to quiesce an agent, you must specify the agent name in the
agent parameter. This prevents the server from temporarily sending messages or submitting
jobs to the agent.

When the agent is in the quiesced state, you cannot submit jobs to the agent. However, jobs
that are running on the agent when it is quiesced continue to run to completion.

You can quiesce and unquiesce servers and agents from the CLI perspective of the Desktop
Client or from the Desktop Client Topology view.


Quiesce Startup Mode

You can start a server in quiesce mode to temporarily prevent the server from submitting new
jobs or triggering workloads.
 For example, instead of warm starting the server, you can start the server in quiesce
mode to prevent jobs from being submitted and events from being triggered.

 When you are ready to resume submitting jobs and triggering workloads, you can
unquiesce the server or specific applications or events on the server.

To start the server in quiesce mode on a Windows platform:
1. Stop the server.
2. Open the following file in a text editor
<install_dir>\conf\runonce.properties.bak
3. Update the start.type parameter as follows:
start.type=QUIESCE
4. Save the file as runonce.properties and close the file.
5. Start the server.
The server starts in quiesce mode.

After a restart, the server automatically renames the runonce.properties file to
runonce.properties.bak. The next time the server restarts, it starts with a warm start.


Unquiesce Servers and Agents
Unquiesce Commands

The following unquiesce CLI commands are available:
 To unquiesce a quiesced server, issue the following command:
unquiesce [appl("application.generation")] [event("eventprefix.eventname")]

 To unquiesce a quiesced agent, issue the following command:
unquiesceagent agent("agent")

When you issue the command to unquiesce a quiesced server, the server is released. The
server can then resume submitting jobs and triggering workloads. You can also use this
command to unquiesce specific application generations or events.

When you issue the command to unquiesce a quiesced agent, the agent is released. The
server can then resume sending messages and submitting jobs to the agent.


Unquiesce Servers and Agents
Unquiesce Commands Continued

You can also unquiesce a scheduled quiesced event, all applications at once, or specific
applications.


High Availability Administration

In a CA Workload Automation DE high availability configuration, you can change the server, the
primary or the standby, that processes workload.
 You must switch these roles during a manual failback recovery to resume processing on
the preferred server.
 Issue the changerole CLI command to move active workload between servers.
 This command is usually issued during system maintenance to move
workload and prevent service disruptions.

 Compared to changerole, failover refers to the process of switching workload processing
from the active server to the monitoring server when the active server fails.
 This is usually an automatic switching when failure occurs if the active server
goes down or if it terminates.
 Network connection failure between primary and standby can also result
in failure.


SNMP Messages Viewer

The SNMP Messages Viewer helps you manage SNMP messages.
 These messages inform you of server startups and shutdowns.

 You can use the viewer to track and test SNMP messages being sent to other SNMP
Managers.

The SNMP Messages Viewer is located in the Admin perspective.



will:

 Change the role of servers
See lab 3‐1 Change the Role of
Servers.




 Change the Role of Servers

double‐click Lab 3‐1 Change the Role of
Servers.



Manage the Server


Server Administration
Maintenance

Understanding server administration and maintenance settings enables you to achieve

The CA Workload Automation DE Server comes with several user commands that permit easy
server and database administration.
You can use CLI commands to:
 Clear server logs and database tables

 Move data in database tables


CLI

You use the CLI perspective to issue commands against the server and agents to perform
various tasks such as managing agents and agent groups, server quiesce and unquiesce, and
more.
 The CLI is a perspective of the Desktop Client.

 The CLI perspective can be:
 Used to issue common scheduling operations and programming commands
 The commands issued depend on the security permissions assigned to
users.
 You can use the commands in JavaScript.

 Installed as a stand‐alone utility on your computer
 To use the CLI, you must be connected to the server.

You can use the CLI commands in user‐generated scripts and programs. When running a
command outside the Desktop Client, you must include a valid user name and password.

The commands that you can issue depend on your security permissions.


Using CLI

The help command displays all available commands or details on a specific command.
 To list all available commands, enter help.

 To display detailed information about a specific command, enter:
help <command>

Note: CLI commands are case‐insensitive.


Using CLI Continued

The about command displays server details such as ID, version number, and the number of
connected clients.
 To display server details, enter about.


CLI Command
Agents and Agent Groups, Events, and Quiesce and
Unquiesce

There are CLI commands for managing agents, agent groups, and events, and for conducting
quiesce and unquiesce operations.

Agents and Agent Groups Events and DB Quiesce and Unquiesce
 LISTAGENTGROUP  BYPASSEVENT  LISTQUIESCESTATE

 CREATEAGENTGROUP  UNBYPASSEVENT  QUIESCE
 UPDATEAGENTGROUP  DBINFO  UNQUIESCE
 DELETEAGENTGROUP  UNQUIESCEAGENT
 UPDATEAGENT  QUIESCEAGENT
 DELETEAGENT

In the CLI field, type help. Click Send and a list of possible commands will appear in the
Response window.


CLI Commands
AET Data and History Data

There are CLI commands for managing average execution time (AET) data and history data.

AET Data History Data
 LISTAETDATA  DELETESTATUSMESSAGES
 PURGEAETDATA  MOVEHISTORYDATA
 PURGEHOMELESSJOBAETDATA

Remember that typing help, followed by the command name, displays the required syntax.


CLI Commands
Resources and Logging

There are CLI commands for managing resources and logging.

Resources Logging
 ADJUSTRESOURCEPROPERTY  LOGINFO
 RESOURCEMANAGERDUMP  GETLOGTHRESHOLD
 SETLOGTHRESHOLD
 GETLOGPROFILE
 APPLYLOGPROFILE
 PURGELOG
 SPINLOG

For more information about these commands and to view examples, see the CA Workload
Automation DE r11.3 CLI Perspective Help guide.


Review Question

Question

Which CLI command provides server version and build
information?

Response

A. help
B. about
C. uptime
D. getproperties

The answer is: about

The about CLI command provides server version and build
information.


Security

CA Workload Automation DE Server security is maintained by a set of security profiles.
 A security profile can represent a user or group of users.
 Security profiles have permissions associated with them. For example, they
determine access levels to applications and topology information.

 Permissions determine the type of access a user or group has to a particular element of
the CA Workload Automation DE Server.
 Permissions can be used to restrict access. For example, you can restrict access
to a specific application.

 Permissions contain the following types of access:
 Alter, Update, or Read
 Allow or Deny

You define security profiles in the Admin perspective.


Security Continued

CA Workload Automation DE includes four predefined groups:
 ADMINGRP
 Provides administrative privileges

 SCHEDGRP
 Provides scheduling privileges

 OPERGRP
 Monitors and controls workflow

 EVERYONE
 Gives read access to admin, system calendar, and default global variables

An explanation about each predefined group was provided in the previous module.


Security Continued

This screenshot is an example of a security profile for
SCHEDMASTER.

The SCHEDMASTER profile:
 Schedules and runs workloads for any
application

 Can only read data in the ADMIN profile
Multiple groups can be assigned to a single ID.
 If the SCHEDGRP profile is assigned, the
OPERGRP profile is not needed.


Reporting

CA Workload Automation DE stores information regarding job execution in its database. You
use reports to view the stored information.
 Create and run reports in the CA Workload Automation DE Desktop Client.
 The application comes with predefined reports.

 Design your own reports using BIRT.

 Display your custom history reports in the Reports view.

The Reporting perspective enables you to design your own history reports by defining
reporting projects.


Reporting Continued

The following diagram displays the relational database tables and the primary keys:

Only users with administrator privileges can design, upload, and download custom reports.



will:

 Add a user and grant agent and
report permissions
See lab 3‐2 Add a User and Grant
Agent and Report Permissions.

 Run CLI commands
See lab 3‐3 Run CLI Commands.




 Add a User and Grant Agent and
Report Permissions

double‐click Lab 3‐2 Add a User and Grant
Agent and Report Permissions.




 Run CLI Commands

double‐click Lab 3‐3 Run CLI Commands.



Case Study

SCENARIO Nordole Industries wants to get a daily report on all UNIX jobs. Management
wants a report on jobs executing specific business servers. Operations want a
daily report on all failed jobs.
PROBLEM Nordole Industries wants to get a daily report on all UNIX jobs. Management
wants a report on jobs executing specific business servers. Operations want a
daily report on all failed jobs.
SOLUTION CA Workload Automation DE comes prepackaged with various reports. Users
can also create their own reports and upload them to the server. The Jobs By
Application report can provide information on specific application. The reports
can be scheduled and the CA Workload Automation DE Manager will run and e‐
mail the required reports to users.


Best Practices

 Use the MOVEHISTORYDATA,
DELETESTATUSMESSAGES, and
PURGECOMPLETEDJOBS CLI commands to keep the
database lean and manageable.

 The database maintenance commands can be
scheduled as UNIX or Windows jobs, and run with the
following command:
cli.bat/cli.sh

 To keep the topology updated and clean, remove any
disabled or inactive agents.


Module Summary
 Gain an understanding of the different protocols in the topology


 Create applications


Assessment Question

Question

Which function does the queisce command perform?

Response

A. Pushes system updates to the server
B. Resumes sending messages and submitting jobs to the
agent
C. Pauses the server so that no new workloads can enter
the server
D. Restarts the server, which enables new workloads to
enter the server

The answer is: Pauses the server so that no new workloads can
enter the server



Create Applications
Applications are the foundation of CA Workload Automation DE and you must
create applications as part of your implementation. Understanding what an
application is and how it works in CA Workload Automation DE is necessary if
you are to optimize the functions of the applications you create. Creating
customized applications enables you to logically group processes to meet your
business needs, helping ensure that you maximize the impact of your
investment by taking advantage of the full functionality of CA Workload
Automation DE.

 Define applications
 Create an application

 Understanding the role of an application in CA Workload Automation DE
will help you create custom applications suited to your workloads.
 To implement CA Workload Automation DE, you must be able to create
applications that logically group processes.


Define an Application


Define Applications

Understanding the role of an application in CA Workload Automation DE will help you create
custom applications suited to your workloads.

An application:

 Consists of one or more jobs and other workload objects
 Enables you to group related jobs and define their dependencies
 Is a container that holds all objects needed for a job stream to be executed
 Can also be named a business process
 Can have a scheduled or dynamic trigger

In this task, you will examine the definition of an application. Knowing what an application is,
what function it serves, and the capabilities it has will enable you to better plan and execute
a successful implementation of the CA Workload Automation DE business solution.


VERIFY Application

CA Workload Automation DE has a default application named VERIFY.

You can use the VERIFY application to test the installation of the server. VERIFY uses the
default scripts installed with the product.

Now that you have an understanding of how the applications function in CA Workload
Automation DE, you are ready to begin building the foundation for your workloads
automation by creating applications.


Create Applications


Create an Application

To implement CA Workload Automation DE, you must be able to create applications that
logically group processes.

Workloads are created in the Application Workspace.


To create an application that best suits your workload automation needs, you must specify:
 Application properties
 Job types
 Job values
 Job dependencies
 Job requirements
You begin this process in the Application Workspace.

The Application Workspace in the Define perspective has a Workload Objects palette
containing an icon for each job type you can define in an application. Another feature of the
Application Workspace is that you can create a workflow diagram, which is a graphical
representation of the jobs in your application. You can customize the Palette view to show
only the workload objects you need.

The Application Workspace can be used offline to create job streams and flows for uploading
to the server later. When using the Application Workspace offline, you can save the output
to an XML file for storage and retrieval.
In the Application Workspace, you begin the process of creating a custom application by
defining application properties.


Application Properties

Application properties determine the behavior of the application and the jobs associated with
it.

One of the first steps in creating an application is to define application properties. Certain
properties are specifically for the application. These include the name, trigger behaviors, and
default notification of an application.

The Name field is the only required field when defining application properties. The value you
add determines the default application name and the event name associated with the
application. The Runtime name is typically used when an application is defined as generic.
You can use symbolic variables to create the Runtime name.

There are also defaults for jobs. Defaults include a default agent to run on and the default
run statement. Next, we will examine default application properties more closely.


Default Application Properties

Property Function
Wait for previous Waits for the previous generation of the application to complete
generation before releasing the next generation
Propagate dueout time Is required to calculate the critical path
Do not inherit Turns the inherit dependency off for this application
dependencies
Require reason for job Requires a comment in the Reason field or the state change will
commands not take affect

Default application properties determine how the application performs at trigger time.

Propagate dueout time takes the dueout time from a critical job and gives dynamic dueout
times to every job in the workflow.


Default Application Properties Continued

Property Function
Estimate end time Is necessary for the critical path and creating the anticipated
end time
Hold on submission Automatically holds the application when it is triggered
Do not trigger if active Will not trigger the application again if a previous generation
of the application is not complete
Suppress notification when no Will not send error messages if no workload is selected when
work selected the application is triggered

After supplying values for the appropriate application properties, you are ready to begin
defining which job types from the Workload Objects palette you want to run in your
application.


Workload Objects

The Desktop Client uses object‐
oriented, flowchart‐based
representations of defined
workloads, which are named
workload objects.
 Workload objects are
represented by icons in
the Workload Objects
palette.

Every workload object has an iconic reference that you can connect to other objects using
dependency lines. Any workload object can be a predecessor or successor to any other
workload object type.

The Workload Objects palette contains all the job types available to run in your application.
Next, you will examine the available job types in detail.


Available Job Types

You select the job types to run in your application from the Workload Objects palette.

Available job types include:

Job Type Specifics
Platform‐specific Windows, i5/OS, Tandem, UNIX, z/OS, and OpenVMS
OS jobs
Monitor objects Windows Service, Text File Monitor, UNIX Service, Windows EventLog,
CPU Monitor, IP Monitor, and Disk Monitor
Database objects Database Trigger, SQL Statement, Database Monitor, and Stored
Procedure
ERP objects PeopleSoft, Oracle Applications, and SAP

Oracle applications include Oracle Single Request and Oracle Request Set.

SAP jobs include R3, Batch Input Session, BW, Job Copy, Event, and Process Monitor.

Each platform‐specific job requires an agent to be licensed and installed on the platform.
Monitor objects are included with the installation of an R7 agent.

The Database objects require an optional Database Agent to be licensed and installed. Each
ERP package —PeopleSoft, Oracle, and SAP— requires an agent to be licensed and installed.


Available Job Types Continued

Available job types also include:

Job Type Specifics
File objects File triggers, FTP, and z/OS data set triggers
Enhancement Links, tasks, and external dependencies
objects
Interface objects Web Services and MicroFocus
Application Entity Bean, HTTP, JMS Publish, JMS Subscribe, JMX‐Subscribe, JMX‐
Services objects MBean Attribute Get, JMX‐MBean Operation, JMX‐MBean Attribute Set,
POJO, RMI, and Session Bean

The z/OS data set triggers, Web Services, and MicroFocus objects require an optional agent
to be purchased and installed. All other objects are included with the R7 agent.

The Application Services objects require the optional application services agent to have been
purchased and installed.

For each job type you choose to use in your application, there are associated values. There
are required, default, and optional values that enable you to further customize your
application to the needs of your enterprise.


Available Job Types Continued

Available job types also include:

Job Type Specifics
SNMP jobs Network monitoring and management
Secure Copy and Secure FTP File transfer
JMX‐MBean Create Instance and JMX‐MBean Java management
Remove Instance
Wake on LAN (WOL) Remote network management
Oracle Copy Single Request Oracle applications E‐Business Suite jobs
support

We will now look at how you can use these values to customize your workflow further.


Default Job Values

For every application you create, you can add job default
properties.
 Job default properties override application properties.

 To access job default properties:
1. Right‐click the job type in the Workload Objects
palette.
2. Click Job Defaults.

After a job default is updated, that type of job is dropped in to the palette and defaults are
added.
Here are some practical uses for default job values:
 You can add an agent for that job type.
 A default run statement is available.
 Default notification statements are available. Windows jobs might notify different
support than UNIX or i5/OS.
 There is a default command path for specific platforms. If all scripts are located in the
same directory, you can use the directory structure as the default.

The editor window looks like the job editor window with the same tabs and fields.


Required Job Values

Each object has required fields,
which are indicated with an
asterisk.
 Every object requires a
name for tracking, an
agent to process the
workload on, and a run
frequency to know
which days the job
should run.

Other required fields are dependent on the type of object being run. The job in the
screenshot is for Windows and therefore requires a command to be executed. A UNIX job
also requires a command, while a file trigger requires the name of the file to be monitored.

Consult the online help for information about how to complete the required job values. To
access the online help, click the required tab and then press F1 on your keyboard. An online
help panel will appear.


Required Job Values
Monitoring Jobs

You must choose from three possible wait modes for monitoring jobs:
 Return immediately
 Return at first occurrence
 Continuous monitoring, using alert
When you define a monitoring job, the available wait modes depend on the type of monitoring
job you are defining.

All three possible wait modes are available for the CPU Monitoring, Disk Monitoring, Text File
Reading and Monitoring, and Windows Event Log Monitoring jobs. Only the Return
immediately and Return at first occurrence wait modes are available for the IP Monitoring,
Process Monitoring, and Windows Service Monitoring jobs.

The Return immediately wait mode is where the job verifies the available values, returns the
characteristics that are being monitored, and then terminates the subscription.

The Return at first occurrence wait mode is where the job requires some input values from
the user for monitoring the values. If the job meets the conditions, the agent returns the
characteristics that are being monitored and then terminates the subscription.

The Continuous monitoring, using alert wait mode is where the alert is mandatory and the
job expects some input values from the user for monitoring. If the job meets the conditions,
it will trigger an alert and continuously monitor the values.


Optional Job Values

Optional job values are found on unique or generic object tabs.
 Each object type will have tabs that are unique.

 Platform‐specific jobs will have an environment variable and exit code tab.
 File triggers will have a user‐ or group‐specific tab.

 Every job will have the following generic object tabs:

 Basic
 Comments
 General
 Notifications
 Resources
 Time Dependencies
 Variable Dependencies

A wide range of optional job values are available that you can use when creating an
application. These optional job values are grouped and accessed in different ways, which we
will examine next.


Optional Job Values Continued

General
Notification
Resources
Time Dependencies
Variable Dependencies


General

General options enable you to set up
the behavior of a job.
 By default, all jobs are
scheduled with holds or
manual intervention.

 The default duration is equal
to the average run time of a
job based on its history.

Here is what some of the characteristics represent:
 On request: You only run this job if requested.
 Conditionally: If this job has not run but everything else is complete, complete the
job.
 JavaScript: You can run a JavaScript for this object when the applications event is
triggered or right before the job runs.
 Duration: You can use the If and Then logic to change to the average duration of a job
for calculation in the critical path.
 Retry Count: You can schedule the number of retries for submitting this job on
certain exit codes.
 Predecessors Remain: This is used if a job does not require every predecessor to run.


Notifications

Notifications options enable you
to control the sharing of job‐
specific information.
 Job‐level notifications
override application
property levels.
 If job‐level notifications are
used, application‐level
notifications are ignored.
 You can create multiple
notifications based on
need.

There are three types of notifications:
 Email: Set up email notifications based on the job state. This can be done with an
email group and can use multiple states.
 Alerts: This is an internal alert. It will kick off an alert defined in CA Workload
Automation DE. This can represent another application, JavaScript, or both. CA
Workload Automation DE passes run‐time variables to the alert.
 SNMP Traps: Send an SNMP trap to an SNMP manager. This is how you link to a third‐
party automation tool and help desk packages.


Resources

Resources are used to control
the workloads.
 The job panel is used to
determine which
resource will be used
and the count associated
with it.

Resources are defined in the Services perspective, Resource view.


Time Dependencies

Time Dependencies options control all time
states associated with a job.
 Time Dependencies options
determine:
 When jobs start
 Overdue times
 When to abandon times
 How long to wait when eligible

The overdue keywords can be made dynamic by adding a realnow term. REALNOW PLUS 2
HOURS causes the overdue time to be set to the time the application is triggered plus two
hours.

Abandon is very useful when controlling workloads. If a job cannot run after a certain time,
use Abandon Submission. If, at a certain point in time, the job must run regardless of
whether all the predecessors are done, use Abandon Predecessor.


Variable Dependencies

Variable Dependencies options
control all variable dependencies
associated with a job.
 Each variable dependency
will add a hold count to the
job. While a job is waiting to
become eligible, the value
can change multiple times.
 If the value is true when all
other dependencies are
satisfied, the job will be
released.

Setting the value after the job is released does not affect the active job.

You are now able to access general, notification, resource, time dependency, and variable
dependency optional job values, enabling you to further customize the applications you
create.


Review Question

Question

Which options are generic object tabs that every job in an
application will have? (Choose three.)

Response

(Select all that apply)

 Basic
 Exit Codes
 Notifications
 Environment Variables
 Variable Dependencies

The answers are:
‐ Basic
‐ Notifications
‐ Variable Dependencies

After you specify application values, determine which job types you
want to run in your application, and assign job values to your
application, you can take another step and create relationships
between jobs. Next, you will look at how defining job dependencies
and requirements affects the way your applications run.


Job Dependencies

Dependencies describe relationships between objects.
 The default relationship is based on the predecessor object returning a successful state.

 Relationships can be based on the following scenarios:
 Success of predecessor
 Failure of predecessor
 Any completion of predecessor
 Exit codes from predecessor
 Global variable value

After defining application properties, you can set dependencies using the:
 Drag‐and‐drop technique
 Tabular form object in the Application Workspace
 Tabular form object definition
We will now examine the different ways to set dependencies using some of these
techniques.


Drag‐and‐Drop Technique

To set a job dependency using the drag‐and‐drop
technique:
1. In the Application Workspace, click Dependencies.

2. Position your cursor on the first job. Click and drag
the line to the next job in the flow. A line will be
drawn for you.

3. To change the release conditions for the
dependency, right‐click the dependency line and
click Release Conditions.

4. Select the condition you need and click OK.


Application Workspace

To create a job dependency from the
Application Workspace:
1. Right‐click the job and click Edit Job
Dependencies.

2. In the table, select the jobs you want
for predecessor and successor.

3. Under Release conditions, select the
condition you need and click Set.


Job Definition

To create a job dependency from
the job definition:
1. Right‐click the job and click
Edit.

2. Click Variable
Dependencies.

3. In the table, define
variables.

4. Click OK.

Only the global variable and time dependencies can be set from the job definition.

When defining variables, any number of variables can be used, separated by the logical
operations of AND or OR.

After setting job dependencies with one of the three techniques, you will move on to set job
requirements, which you will do next.


Job Requirement

A main job requirement is run frequency, which:
 Is used to determine which days a job should run
 Can be overwritten at the job default level or individual job level
 Can be created using the generated or free‐format statement options in the Run dialog
File trigger jobs require one of the following file trigger types:
 Created or Updated
 Expand or Shrunk
 Exist or Non‐Existing
 Deleted

By default, jobs are set to run daily in the application properties. Application properties are
the default for every job. Do not specify a time in the run frequency; instead, use the Time
Dependencies option.

Next, you will examine run frequency and file trigger in detail.


Run Frequency

To open the Run dialog, on the Basic tab, click
the ellipses (…).
 To specify the scheduling terms:
 Select an occurrence:
 Every
 1st, 2nd, and so on
 Nth last
 Date

 If an occurrence other than Date is
selected:
 Select a type of day
 Select a period

 If necessary, under On holiday, select
an option.

On the Basic tab, you have the option to show a run statement in a calendar format.
Statements can be used as Run or Do Not Run.
 Run a job every day except holidays:
 Run daily
 Do not run holidays
 Run a job only on holidays.
 Run holidays
 Run workdays does not need a Do Not Run Holidays statement because a holiday is
not considered a workday:
 Run workdays
 Run last workday of month


Run Frequency Continued

To see the results of the generated statement,
click Test.
 Click OK and the generated statement
will be put in the Run Frequency field

Jobs can have multiple “run” or “do not run” statements. For example, the job you create to
cut payroll checks runs twice a month, on the last working day and on the 15th day of the
month. If the 15th day falls on a Saturday, Sunday, or holiday, the job will execute on the
previous workday.
 Run last workday of month
 Run 15th day of month less 0 workdays
 Less 0 workdays means move to the previous workday.
Adding multiple “run” or “do not run” statements means few jobs need to be defined.

If Monday, September 1 is a holiday, the job will be selected to run on Wednesday,
September 3.


File Trigger

A file trigger requires a name and file name.

Remember that Name is a required field. You can include wildcards in the file name only, not
in the directory.

Selecting the Recursive check box means the search for the file will be done from the current
directory to every subdirectory.

An alert can be useful if a file came in multiple times and kicked off the same workloads.


File Trigger Continued

The file trigger types are:
 Created: This file trigger type looks for a file to be created. If the file already exists, the
file trigger considers it complete.

 Updated: This file trigger type looks for a file to be updated. If the file does not exist, the
job fails with a File not detected error.

 Expand or Shrunk: These file trigger types monitor files for expanding or shrinking and
can be used continuously to automatically kick off a clean‐up job. If the file does not
exist, the job will fail with a File not detected error.

 Exist or Non‐Existing: These file trigger types check for the existence or nonexistence of
a file. A failure will occur if Exist is used and there is no file or if Non‐Existing is used and
there is a file.

 Deleted: This file trigger type waits for a file to be deleted. If the file does not exist at
the start time, the job will complete successfully.

Now that you have defined job requirements, you have completed the process of creating an
application. The values you supplied for application properties, job values, job types, and job
dependencies, together with the job requirements you just learned about, provide you with
an application that suits the needs of your enterprise.


Application Templates

Application templates are ready‐to‐use application definitions that third‐party users can run at
any time by passing required parameters.
 For example, you can define a single application template for the payroll processes of
two companies so that each company runs the application template with their own
parameters.
Application templates must be defined with parameters as symbolic variables, for example:
%EVAR.parameter_name
 To define the lifecycle of the application, use the following web service functions:
 runApplicationCreate
 runApplicationRead



will:

See lab 4‐1 Create an Application.




 Create an Application

double‐click Lab 4‐1 Create an Application.



Module Summary
 Define applications


 Create CA Workload Automation DE events



Question

Which options are available job types? (Choose three.)

Response


 File objects
 Default options
 Workload objects
 Enhancement objects
 Platform‐specific OS objects

The answers are:
‐ File objects
‐ Enhancement objects
‐ Platform‐specific OS objects

The correct answer can be found in task 2, pages 10 and 11.



Question

Which options are job requirements when creating an application?
(Choose two.)

Response


 Job value
 File Trigger
 Run Frequency
 Default options

The answers are:
‐ File Trigger
‐ Run Frequency



Create CA Workload Automation
DE Events
CA Workload Automation DE events enable you to control the applications you
create to suit your business requirements. When you understand the function
of an event, types of events, and how they are triggered, you can customize
your CA Workload Automation DE implementation by creating the events you
need to run your applications.

 Define CA Workload Automation DE events

 Create a CA Workload Automation DE event

 Understanding the function of CA Workload Automation DE events
enables you to effectively plan your implementation.

 Creating CA Workload Automation DE events is a crucial aspect of
automating workload processes with CA Workload Automation DE.


Define CA Workload Automation DE
Events


Define a CA Workload Automation DE
Event

Events are used to schedule applications.
 When an event is triggered, the application runs.

 An event can be triggered in the following ways:

EVENT TYPE DESCRIPTION
Date and Time The event is scheduled to trigger on specific days at specific times.
File Trigger The creation of a file will trigger an event.
Database Trigger and Changes in a database table can automatically trigger an event.
Monitor
JMS Subscribe A message coming across a Java Message Service (JMS) pipe can
trigger an event.
z/OS Data Set If using the z/OS agent, the creation of a data set on z/OS will
trigger an event.
SAP Event A specific event in SAP can trigger an event.
Variable Dependencies Trigger workload based on global variable expressions.
Reporting Events Schedule forecast and other report types to run during specified
times.

Understanding the function of CA Workload Automation DE events enables you to effectively
plan your implementation.

An event takes the application and moves a copy to the server to begin the loading process.
The loading of an event is called a generation.

An application can have multiple events and event types.


Verify Event

The Verify event is the default event included with the Verify application.
 This event:
 Uses the default System calendar
 Has no schedule statement; it is dynamic
 Uses SCHEDMASTER security for triggering
 Runs the Verify application

Now that you have an understanding of the event functions, you can start creating events for
your applications. Event properties must be given values that suit your needs. After this is
accomplished, you will be able to trigger, simulate, and control events that manage your
workflow.


Create a CA Workload Automation DE
Event


Event Properties

Event property values dictate the behavior
of your applications.
 Mandatory fields include:
 Event prefix
 Used to differentiate
between groups
 Event name
 Used to enter a
descriptive name to
identify the event
 Specify Application to run
The value in the:
 Execution user field determines the
security permissions associated
with the application
 Specify Calendars section
determines the schedule and run
dates

Creating CA Workload Automation DE events is a crucial aspect of automating workload
processes with CA Workload Automation DE.

When you create an event, you must first specify these values to suit the business
requirements.


Event Values

 Event prefix
 This is used to
group events
such as PROD or
TEST.
 By default, CA
Workload
Automation DE
Server uses the
login user name
as the Event
prefix.

 Event name
 By default, the
server uses a
variation of the
application name
as the event
name.

 Execution user
 –The execution
user requires the
appropriate
permissions to
alter the
application.


Event prefix:
 Remember that it is mandatory to specify the Event prefix.
 After the event is uploaded, the only way to change the prefix is to delete the event
and create a new one.
 The prefix can be up to 32 characters.
Event name:
 Remember that Event name is a required field.
 After the event is uploaded, the event name can only be changed by deleting the
event and creating a new one.
 The event name can be up to 128 characters.
Execution user:
 To override this behavior for events triggered manually, select Inherit trigger user.
 The execution user can be changed at any time.


Event Values
Calendar

You can specify up to two calendars for events.
 For example, you might need two calendars for European and U.S. holidays or bank and
other holidays.
 If no calendar is specified, the CA Workload Automation DE Server uses the SYSTEM
calendar, which many people find adequate for their requirements.

Calendars are optional.


Event Values
Application

You must specify which application will run when the event is triggered.
 An application can be used in multiple events and event types.
In the Define perspective, the application that was created on the Properties tab is
automatically used.

In the Services perspective, any application can be manually entered.


Event Values
Schedule

Schedule determines when the
event should be triggered.
 If no schedule statement
exists, the event is
considered manual.

In Schedule, time can be added to the statement.
 DAILY 5AM
 DAILY EVERY 1 HOUR
 SUSPEND 8PM
 RESUME 8AM
 WORKDAYS
Suspend at stops the event from triggering.
 This can be scheduled manually or from a CLI command.
 While in SUSPEND MODE, an event cannot be triggered.
Resume at schedules the event to automatically resume triggering.
 This can be scheduled manually or from a CLI command.


Event Values
JavaScript

You can add JavaScripts to be
executed at event trigger time.
 You can only use
JavaScripts stored in the
repository.

JavaScripts are read‐only in an Event definition. You can create JavaScripts through the
Services perspective using the JavaScript dialog for the repository.

Now that you have specified event property values, you are ready to test the event.


Review Question

Question

Which event values can only be changed by deleting the event and
re‐creating it? (Choose two.)

Response


 Event prefix
 Event name
 Execution user
 JavaScript Name
 Specify Application to run

The answers are:
‐ Event prefix
‐ Event name

If you need to change the event prefix or event name, you must
delete the event and re‐create it.


Available Event Types

File Trigger
Database Trigger
Database Monitor
Variable Dependency Monitor
Forecast Reporting
History Reporting
Other Event Trigger Types

When you create an event, you need to consider what type of activity will trigger it. There
are a number of different types from which you can choose.


File Trigger

The File Trigger event type continuously triggers workload based on file activity.

 This event type:
 Triggers the application on successful creation of a file
 Can be scheduled with SUSPEND and RESUME to turn file triggering on and off
 Can be monitored and controlled in the Services perspective

After defining a File Trigger event and saving it to the server, the event becomes active and
the agent starts monitoring file activity.


Database Trigger

The Database Trigger event type continuously triggers an event based on database activity.
 Works on Oracle, SQL Server, and DB2
 Requires the database agent to be installed
 Can use SUSPEND and RESUME to stop and start
 Can monitor and control events in the Services perspective
 Can be inserted in the database table as a normal DB Trigger property
 Can look for table insertions, deletions, and updates


Database Monitor

The Database Monitor event type continuously monitors an event based on database activity.
 Works on Oracle, SQL Server, and DB2
 Requires the database agent to be installed
 Can use SUSPEND and RESUME to stop and start
 Can monitor and control events in the Services perspective
 Queries the database for the number of rows in its table and when an increase
or decrease occurs, the event triggers


Variable Dependency Monitor

The Variable Dependency Monitor event type enables you to trigger workload based on global
variable expressions.
 When you create a Variable Dependency Monitor event, the server:
1. Evaluates the variable expression
2. Runs the application referenced in the event whenever the variable expression is
satisfied
 The server reevaluates the expression when any of the variables in the expression
change.


Forecast Reporting

The Forecast Reporting event type enables you to schedule forecast reports using events.
 This event type saves the output on the server for viewing later.

 You can export the output in different formats, including:
 CSV
 HTML
 When scheduling forecast reports, you can specify a list of users to notify when the
forecast report execution is complete.

 You can also grant permissions to a list of users to view the report output.


History Reporting

The History Reporting event type enables you to schedule history reports using events.
 This event type also saves the output on the server for viewing later.

 You can export the output in different formats, including:
 CSV
 HTML

 When scheduling history reports, you can specify a list of users to notify when the
forecast report execution is complete.

 You can also grant permissions to a list of users to view the report output.

The predefined history reports have been updated to include new reports on long‐running
jobs and jobs grouped by job type.


Other Event Trigger Types

 Dataset Trigger
 The Dataset trigger requires a z/OS agent to be installed.

 JMS Subscribe
 The JMS Subscribe trigger requires the application agent to be installed.

 SAP Event
 The SAP Event trigger requires the SAP agent to be installed.

After event properties have been assigned values and you have determined activity that will
trigger your applications, you can simulate an event and ensure the event is running your
application as intended.


Simulate CA Workload Automation DE
Events

When you simulate an event, you
test the application for a given day.
 The result of the simulation
shows:
 Dependencies
 Symbolic and global
variables
 A flowchart

A best practice is to simulate the event after every upload. You can select any day or
calendar keyword and specify user parameters for the simulation. After you click OK, you will
be able to view the results of the simulation as output.


Simulate CA Workload Automation DE
Events Continued

The simulation output:

You can print the output for reference.

Assuming that the results of your event simulation are positive, you are ready to activate
your event and put your applications to work.



will:

 Simulate a CA Workload Automation
DE event
See lab 5‐1 Simulate a CA Workload
Automation DE Event.




 Simulate a CA Workload Automation
DE Event

double‐click Lab 5‐1 Simulate a CA
Workload Automation DE Event.



Trigger CA Workload Automation DE
Events

Triggering an event brings a new
generation of the application to the
active monitor.
 Triggering can be scheduled or
dynamic.


Events Continued

 Schedule criteria
 This field indicates the day the application is to be loaded.
 Past and present days are loaded immediately.
 Future days are loaded only on the exact day specified in the Schedule
criteria field.

 Root jobs to run
 This field is used to load only a subset of the application.
 ROOTJOB+ ‐ plus sign is to load this job plus dependencies.
 Any number of jobs can be selected.


Events Continued

 Add new scheduled Event
 Regardless of what is already active, a new generation will be built to run if this
option is selected.

 Replace next scheduled Event
 This will override the next scheduled run of the application.

 Submit Application on hold
 This option will trigger the application with an Application Hold (applhold) state.


Events Continued

 User Parameters to pass to Event
 Passed to the application as symbolic variables
 Used to give a generic application more flexibility
 Only used for dynamic triggering
 Used with scheduled events and symbolic variables in JavaScript

After events are triggered and applications are running, you can begin to monitor and control
the workload activity.


Control CA Workload Automation DE
Events

Events can be dynamically created and controlled from the Services perspective.
 They provide the same functionality as the Define perspective.

 Events can be monitored and controlled from the Services or Events perspectives.


Events
Toolbar

From left to right, the controls
are:
 Open an Event
 Delete an Event
 Suspend an Event
 Resume an Event
 Hold an Event
 Release an Event
 Trigger an Event
 Bypass an Event
 Simulate an Event
 List Scheduled Events


Events
Controls

 Hold an Event
 Puts an application into an applhold state ‐ all jobs are held

 Release an Event
 Releases at the application level
 List Scheduled Events

 Shows a list of all events scheduled during a specific time frame
 Lists all or filtered events

 Bypass an Event
 Bypasses the next or any future execution of an event to prevent it from
triggering at its scheduled time

 Unbypass an Event
 Unbypasses a bypassed event execution but only before the event has been
bypassed; only future bypassed events can be unbypassed


Event Priority Option

The Event Priority option enables you to order event executions in the case where multiple
events are scheduled to be executed at the same time.
 The event priority is a number between 1 and 10 and specified in the event definition.
 The number 1 indicates the lowest priority; 10 indicates the highest priority.

 The server uses the following rules when executing events:
 Events are executed in the descending order of their priority.
 If multiple events have the same priority, the event with the earliest execution
time is selected first.
 If multiple events have the same priority and execution time, the earliest trigger
request is executed first.

All events regardless of their type, be it manual, time‐based, file monitor, and so forth, have
a priority established by the user when the event is initially defined or when it is updated.



will:

 Create a CA Workload Automation
DE event
See lab 5‐2 Create a CA Workload




 Create a CA Workload Automation
DE Event

double‐click Lab 5‐2 Create a CA Workload



Module Summary
 Define CA Workload Automation DE events

 Create a CA Workload Automation DE event

 Monitor and control active workload



Question

Which items are event triggers? (Choose three.)

Response


 SAP Event
 SNMP Trap
 Event Prefix
 Date and Time
 JMS Subscribe

The answers are:
‐ SAP Event
‐ Date and Time
‐ JMS Subscribe




Question

Which values are mandatory when creating an event? (Choose
three.)

Response


 Schedule
 Application
 Event name
 Event prefix
 Execution User

The answers are:
‐ Application
‐ Event name
‐ Event prefix



Monitor and Control Active
Workload
To effectively manage active workload, you must be able to monitor and control
the applications and events you have created. You will be able to determine if
workload is being managed in the most efficient way and troubleshoot
problems where necessary.



 Being able to monitor and control active workload will enable you to
regulate your workload.


Monitor and Control Active Workload


Monitor and Control Active Workload

Being able to monitor and control active workload will enable you to regulate your workload.

You monitor and control active workload in the Monitor perspective.

When you click Monitor, you will see the Monitor perspective as shown in the screenshot.

User roles and privileges determine what you can view in the Monitor perspective. You can
use filters and custom views to determine which jobs you want to monitor and control. This
enables you to define which events within jobs you will view on the Application Monitor
view.

The state priority determines the order of jobs in a custom view.

To receive information about workload, you must subscribe to the server. Subscription
options enable you to do this.


Subscription Options

Subscription options determine what
the server sends to the Desktop Client.
 After subscribing to the server,
job state changes are
automatically sent to the
Monitor perspective without
refreshing.

The subscription options are as follows:
 Subscribe with Filter creates multiple filters when subscribing to a server based on the
jobs you want to monitor.
 Subscribe All subscribes to all completed and active applications.
 Subscribe Active subscribes to only the generations of applications without a
Completed status.
 Unsubscribe instructs the server to stop sending status messages.
 Hide All Completed leaves only the active applications in the Monitor perspective


Subscription Options Continued

You can define filters to list specific applications to monitor.
 Users can define single or multiple applications.

 Default subscriptions can be defined for initial subscription.

After you specify the subscription options, you can view workload activity on the Application
Monitor view. You also have the option of creating custom views on the Custom View view.


Custom Views

Custom views are windows created to display
only the information you want, in the format
you want.
 Multiple custom views can be opened
simultaneously.

 Users can create any number of custom
views.

Actions against active workload can be done through the Custom View view or Application
Monitor view.

When initially opening custom views, they are full screen, divided into tabs. You can drag the
custom views to have them appear in separate windows. You also have the option to
monitor and control active workload graphically, as you will see next.

A custom view can span many different applications. For example, CA Workload Automation
DE provides a custom view named Failed that displays all failed jobs regardless of which
application they belong to.


Graphical Views

Triggered applications can be viewed graphically.
 All actions can be performed through the flowchart.

Graphical workflows can be detached by right‐clicking them. You can manipulate the
workflow layout in the window. You can also put graphical workflows into Fast View. Fast
View removes the workflow from the window and puts an icon on the bottom left of the
window. Clicking the icon will enlarge the application.

You can manipulate the view of the icons using the buttons on the bottom of the window:
 See an overview of a specific section.
 View the critical path flow.
 View subapplications.
 Zoom in and out.


Dashboards

The Monitor perspective contains a dashboard view that provides status and historical
information in predefined status message and system monitor custom views.
 You can view status messages about the following:
 Agent status
 Active applications count
 Desktop Client connections
 Memory usage
 Server start time and type (Primary and Standby)
 LDAP status
 Server quiesced status
 License status


Dashboards Continued

You can also create, edit, or delete views to display the information you need.


Application Actions

Actions against an application pertain to
every job in that generation.
 The actions list is produced by:
 Right‐clicking the application
 Right‐clicking an individual job
and clicking Application
commands
 Right‐clicking in the flowchart
view
 Make sure a job is not
highlighted.

Locate Job in Graph opens the application flowchart for that job.

When using the flowchart view, make sure that a job is not selected or the action will only
work against the individual job, not the application.


Application Actions Continued

To dynamically insert jobs into an active
workload:
1. Click Insert Job.

2. Select the type of job you want from the
list.

3. Complete the appropriate fields to
define the job, including predecessors
and successors.

4. Click OK.
 This will automatically insert the
job into the active workload.

You can view the Gantt chart of an application to monitor the progress of the application as
it runs relative to the current time.

From the Gantt chart, you can see when the jobs in the application will start and end and
how long the application will run, based on historical run times or a duration specified in the
job definition.

You can also view a Gantt chart of the jobs on the application critical path.



 Find Troubled Job opens the application
in the flowchart view.

 Complete forces every job in that
generation of the application to
complete.

 Details lists information about the status
of the application.

 Hold manually places every job in that
generation on hold. Jobs can be
manipulated before release.

 Refresh Estimated Runtime ensures that
the estimated run time of a job is
calculated at the end of every job that
runs.

Estimated run time can be manually updated by clicking Refresh Estimated Runtime. The
estimated run‐time value is shown in the options of a job‐level detail.



 Release releases a held application.

 Show Application Comments displays
comments defined in the Application
Properties.

 Unwait removes the WAIT status and
releases the application. Applications
are put into a WAIT status when
triggered; they must wait for the
previous generation to be complete
before starting.

 Trigger enables the same functionality
as when triggering from an event.

 Hide Selected Application(s) enables you
to hide a completed application.


Review Question

Question

Which are application options? (Choose three.)

Response


 Hold
 Bypass
 Complete
 Process Verify
 Refresh Estimated Runtime

The answers are:
‐ Hold
‐ Complete
‐ Refresh Estimated Runtime

Hold, Complete, and Refresh Estimated Runtime are application
options.


Job Actions

Actions are used to monitor and control jobs.
 Actions can be issued against jobs from
graphical or custom views.

 The action list is produced by right‐clicking
any job.
 The job will appear as selected.
 The action list will appear.

Next, we will examine the definition of each action available in the action list.


Job Actions Continued

 Details lists the current details of the job.

 Show Comments displays the Comments from the job
definition.

 Bypass gives the user the option to not execute a job,
but still keep it as a placeholder in the workload.

 Complete manually forces the job to complete.

 Drop Resources enables you to drop some or all of the
logical resources assigned to the job.

When you look at details after forcing a job to complete, you will see FORCED in the
conditions.

After a job is bypassed, the state will change.



 Drop Variable Dependencies enables you to drop some
or all of the variable dependencies associated with the
job.

 Hold manually places the job on hold.

 List Resource Usage displays resource usage for the
logical resources associated with the job.

 Process Verify verifies that the process started by the
job is still active.

When you place a job on hold, you must release it manually before the job can run.

When you click Process Verify, a message will appear with the result of the command.



 Ready enables you to put the job back in the READY
state.

 Release releases the job from the MANHOLD state.

 Request manually requests the job for execution when
all dependencies are satisfied.

 Reset Definition enables you to make changes to this
occurrence of the job.

When you click Release, the job will run if all other job dependencies are satisfied.

You must click Request or the job will be bypassed.

When you click Reset Definition, you can change all fields for this occurrence except
JOBNAME and QUALIFIER.



 Reset Times enables you to adjust the time
dependencies, overdue times, and abandon times for
this occurrence only.

 Unbypass reverses the Bypass command for a job.

 Unrequest reverses the Request command for a job.

 Update User Status enables you to manually update
the User Status field

The User Status field is a text‐only field that you can use when creating custom view
windows.

You use job actions to control jobs within your applications. As jobs run in your application,
you will want to monitor their status and CA Workload Automation DE provides you with this
capability through job states and application states.

Next, you will be shown job and application states and what they mean to your workflow.


Job States

When the server processes a job, the job passes through multiple processing stages named
states. Some states, such as job failure, require action.
 When multiple states apply to a job, the highest priority is listed first.

The job details display the job state and conditions.

Some states can appear as a state and a condition. The Details option will show the state and
condition.

Next, individual job states are defined in detail.


Job States Continued

Job states are described in the following table:

JOB STATE DESCRIPTION

BYPASSED Indicates that the job has been bypassed. It is a final state. Before the predecessor
dependencies of the job have been met, the job has a Bypassreq condition,
indicating that the job has been marked for bypassing.
COMPLETE Indicates that the job has completed successfully. It is a final state if the
application that contains the job completes. If the job was completed manually, it
has a Forced condition.
FAILED Indicates that the job has failed. The job must be resubmitted or manually
completed.
SUBERROR Indicates that the submission of the job resulted in an error. Usually, this results
from specifying an undefined agent or an invalid argument in the job definition. It
can also result from executing invalid JavaScript at run time. The job must be
resubmitted or manually completed.
EXEC Indicates that the job is currently running
MONITOR Indicates that the job is monitoring for a condition to occur. For continuous
monitoring, the server triggers an alert each time the monitor condition is met.
For non‐continuous monitoring, the job completes when the monitor condition is
met.


Job States Continued

More job states are described in the following table:

JOB STATE DESCRIPTION

AGENTDOWN Indicates that the agent referenced in the job definition is down
APPLHOLD Indicates that the application that contains the job is in a hold state. The job
cannot run until the application is released. Holding an application does not
affect jobs currently running but does prevent the server from submitting new
jobs.
VARWAIT Indicates that the job is waiting for one or more variable dependencies to be
met. The job cannot run until all the required variable dependencies are met,
dropped, or abandoned.
RESWAIT Indicates that the job is waiting to acquire resources. The job cannot run until
all the required resource dependencies are met, dropped, or abandoned.
READY Indicates that the job is ready to be submitted (all its dependencies have been
met). A workload object will not remain in this state.
UNKNOWN Indicates that the server cannot determine the state of the workload object

Next, you will learn about the relationship between job states and application states.


Application States

When the server manages an active application, the application passes through multiple
processing stages named states.
 The following table outlines the states that applications can fall into and the associated
job states:

APPLICATION STATE ASSOCIATED JOB STATES
Unknown (most UNKNOWN
severe)
Trouble AGENTDOWN, EXTSCHDOWN, FAILED, INACTIVE, Overdue condition,
SUBERROR
Manual Intervention MANHOLD, MANSUB, TASKWAIT
Applhold APPLHOLD
Applwait APPLWAIT
Waiting EXTWAIT, DEFINED, MONITOR, PREDWAIT, RESWAIT, SUBAPPLWAIT,
SUBDELAY, SUBMIT, VARWAIT, WAITING

An application state is determined by the job in the application with the most severe job
state.
Some states require action, such as job failure.

By default, the Desktop Client displays application generations in the trouble state in red.


Review Question

Question

What determines the order of jobs in a custom view?

Response

A. Run time
B. State priority
C. Time of failure
D. Overdue condition

The answer is: State priority

The state priority determines the order of jobs in a custom view.


Troubled Jobs

To find the troubled job within an application, right‐click the generation and click Find Troubled
Job.
 Jobs having the following states are considered in a troubled state:
 AGENTDOWN, EXTSCHDOWN, FAILED, INACTIVE, Overdue condition, and
SUBERROR

 In the Application Status view, troubled jobs are considered the highest state.

 Applications with a job in a troubled state appear in red.

 Troubled jobs are centered in the flowchart window and can be edited to make one‐
time changes.

When you edit a troubled job, changes apply to the current generation only; they do not
propagate to other generations. To make a change, right‐click the object and click Reset
Definition.
 If a time needs to be altered, right‐click and click Reset Times.
 To restart a failed job, right‐click and click Resubmit.
Troubled jobs that have executed can have the STDERR and STDOUT returned by right‐
clicking the object and clicking Retrieve Spool File. For large files, options can be used to:
 Look for specific words or phrases
 Only retrieve part of the file
 Retrieve the next portion of lines
The spool file is sent from the Agent directory to the Desktop Client for viewing.


Critical Path

Critical path is a tool to determine dueout times dynamically
for all jobs in an application.
 If a dueout time is not met, the application can send
notifications based on the definition.

 By default, the server calculates the critical path for an
application on the job that finishes last in the
application.

 If Critical Job has been enabled, the workflow for those
jobs will be highlighted when executed.

You can also identify a job in an application as critical in the job definition under the General
tab. The longest path to that job, based on historical execution time, is named critical path. A
default critical path custom view is defined on installation.

You can monitor the critical path in a flowchart view; the critical path shows up as a green
line in the flow.



will:

See lab 6‐1 Monitor and Control
Active Workload.

 Manage the dashboard
See lab 6‐2 Manage the Dashboard.




 Monitor and Control Active
Workload

double‐click Lab 6‐1 Monitor and Control
Active Workload.




 Manage the Dashboard

double‐click Lab 6‐2 Manage the
Dashboard.



Module Summary

 Manage agents and agent groups



Question

What is a feature of a custom view?

Response

A. It spans one application.
B. It opens an application in a flowchart.
C. Only one custom view can be opened at a time.
D. It looks like a table; it contains rows and columns of
information.

The answer is: It looks like a table; it contains rows and columns of
information.



Question

What is the role of a job action?

Response

A. It is used to monitor and control jobs.
B. It is a tool to determine dueout times dynamically for all
jobs within an application.
C. It is an action against an application pertaining to every
job in that generation.
D. It is when the CA Workload Automation DE server
processes a job; the job passes through multiple processing
stages named states.

The answer is: It is used to monitor and control jobs.



Manage Agents and Agent Groups
By identifying the components, features, and functions that constitute CA
Workload Automation DE agents and agent groups, you can automate workload
on different servers and distribute workload between similar platforms and
operating systems to meet your business needs. This will help ensure that you
maximize the impact of your investment by taking advantage of the full
functionality of CA Workload Automation DE.

 Define CA Workload Automation DE agents
 Define agent groups

 Defining CA Workload Automation DE agents enables you to automate
workload on different servers.
 Defining agent groups enables you to distribute workload between similar
platforms and operating systems.


Agents


CA Workload Automation DE Agents

Defining CA Workload Automation DE agents enables you to automate workload on different
servers.

The CA Workload Automation DE agent is a unique and powerful technology that forms the
core component of the various CA Workload Automation DE schedulers and managers.

 The agent permits the schedulers to execute jobs across a range of operating systems
and applications:

 i5/OS, OpenVMS, Linux, UNIX, and Windows
 Enterprise applications that include SAP, PeopleSoft, Oracle EBS, and more

 The agent may co‐exist with previous or existing versions as long as:
 Each instance has its own directory
 It is configured to listen or bind on a unique port


What Is a CA Workload Automation DE
Agent?

Agents provide the ability to manage distributed and mainframe workload from a single point
of control.

 Java‐based applications, most installers include the JRE
 z/Linux and i5/OS require the IBM JRE to be installed before agent setup.

 Small, non‐invasive processes, using approximately 150 MB of disk space

 TCP/IP communication using short data packets

 Encrypted communication between the CA Workload Automation DE managers
 Specify AES, default, or none.

 Data event sensors and integration points for your business applications

 Highly scalable; can easily deploy thousands of agents across the network


Add and Modify Agents

To work with the server, you add agents using the Topology view.


Control Agents

The Topology view also enables you to control agents with the following actions:

 Add and remove agents
 Delete Agent removes the agent from
the Topology view.
 You will be warned if existing
applications or jobs use the
agent.

 Change agent properties and delete agent logs

 Quiesce and unquiesce agents
 Quiesce will stop the scheduler from
submitting new workload.
 Agents will continue to run
existing jobs.

 Stop agents
 The Stop Agent command shuts the
agent down.


Plug‐ins
Business Agents

You can extend the functionality of the agent by installing one or more agent plug‐ins into the
agent installation directory.
 Plug‐ins represent a piece of agent functionality, they:
 Receive an Automated Framework Message (AFM) from the server
 Send replies back to the server

 Plug‐ins do not need to be installed on the same server as the application.

 Plug‐ins use a remote connection, for example, remote call, JDBC, RFC, and so on.

Whenever possible, plug‐ins offer a certified interface to third‐party solutions that have a
built‐in scheduler. For example:
 SAP Computing Center Management System (CCMS)
 Oracle E Business Suite, Concurrent Manager


Plug‐ins
Plug‐in Installer Utility

 Plug‐ins are installed into an existing systems agent on UNIX, Linux, or Windows.

 Example of a database plug‐in installation:
C:\AgentR11.3>PluginInstaller.exe
Usage:
plugininstaller <packed file> <agent directory> [<stdin path> [<force
override flag>]]

C:\AgentR11.3>PluginInstaller.exe C:\Temp\database.pak C:\AgentR11.3

Please enter the database type:
1: Oracle
2: SQL Server
3: DB2
4: Sybase



will:

 Add an agent
See lab 7‐1 Add an Agent.

 Add the DB plug‐in
See lab 7‐2 Add the DB Plug‐in.

 Run an SQL job with the DB plug‐in
See lab 7‐3 Run an SQL Job with the
DB Plug‐in.




 Add an Agent

double‐click Lab 7‐1 Add an Agent.




 Add the DB Plug‐in

double‐click Lab 7‐2 Add the DB Plug‐in.




 Run an SQL Job with the DB Plug‐in

double‐click Lab 7‐3 Run an SQL Job with
the DB Plug‐in.



Define Agent Groups


CA Workload Automation DE Agent
Groups

Defining agent groups enables you to distribute workload between similar platforms and
operating systems.

An agent group is a logical grouping of agents that can be used for workload assignments.
 Agent groups can be used for load balancing or to run all the agents of the given agent
group task.

 The agent group defined on a job for load balancing supports three algorithms:
 CPU
 RANDOM
 ROUND ROBIN

An agent group is an explicitly defined logical group of agents. It provides load balancing and
runs on all agents.

When an agent group is used for load balancing, it supports three criteria or algorithms to
decide which agent should be picked from the given agent group.
 CPU is used to select the agent that has more CPU available.
 RANDOM is used to pick an agent randomly from the group.
 ROUND ROBIN is used to pick agents in round‐robin fashion or one after the other.
When an agent group is used with the Run on all agents option, the given job is cloned for
each agent in the agent group so that the job is executed on all the agents of the agent
group.


CA Workload Automation DE Agent
Groups Continued

Permissions need to be granted to a user to work with the agent group artifact.

The ADMIN.Network Topology is used to alter, update, or read permissions for a user.


Define Agent Groups

To create a new agent group,
specify the following:
 Group name
 Type of agents
 Selection criteria for
load balancing
 Agents

An agent group can be created from the Topology view of the ADMIN perspective. The
screenshot shows the option to create an agent group.

To create a new agent group, specify the following:
 The group name, which designates the name of the agent group
 The type of agents, for example, Windows or UNIX
 The selection criteria for load balancing, such as CPU, RANDOM, or ROUND ROBIN.
Note that the selection criteria is neglected for the Run on all agents option.
 The agents to be included in the agent group
For an agent group deletion, connect to the server as an administrator using the Desktop
Client and open the Admin perspective. Right‐click Topology in the Admin view, open the
Topology view, right‐click the agent group name you want to remove, and click Delete Agent
Group.
If the agent group being deleted is associated with any applications, the Affected Artifacts
dialog opens and lists the applications that are affected by the deletion. Otherwise, a
confirmation dialog appears and you can skip the next step.


Define an Agent Group
Examples

The screenshots show an agent group with Random load‐balancing criteria and with
Windows‐only agents, an agent group with Round Robin load‐balancing criteria and with
Windows‐only agents, and an agent group with CPU load‐balancing criteria and with
Windows‐only agents.

In case of CPU load balancing, optionally, the load‐factor parameter can be updated for an
agent to provide more weightage to that agent. A distribution chart shows the potential load
on each agent.


Agent Group Usage in Workload
Application Definition

When defining an application, select an agent or an agent group as a default for the jobs. You
can also select an agent group for Load Balancing or Run on all agents.

Only Windows and UNIX jobs can use an agent group as default; all other job types will have
no agent.
Load balancing is a job run‐time feature. An agent group is resolved to the actual agent only
when the job is eligible to run.

Run on all agents is an event trigger time feature. The job definition will be cloned for each
agent in the agent group.
The job qualifier of the cloned job is updated to the target agent name. Job predecessors and
successors are adjusted accordingly.



will:

 Add an agent group
See lab 7‐4 Add an Agent Group.




 Add an Agent Group

double‐click Lab 7‐4 Add an Agent Group.



Best Practices

 Agent group creation supports Windows‐only and
UNIX‐only agents.

 An agent defined in the Topology view can be part of
multiple agent groups.

 Agent groups must be created explicitly.

 Agent groups specified at the application level as
default become the default agent group for all job
types that support agent groups.

 When performing the agent selection process during
load balancing:
 Filter the agents that are not running,
quiesced, and accessible to the execution or
trigger user
 Apply agent group criteria to select one agent
out of the filtered agent


Module Summary
 Define CA Workload Automation DE agents

 Define agent groups

 Define calendars


Assessment Question

Question

Which algorithms support agent group load balancing? (Choose
three.)

Response


 CPU
 RESET
 FAILOVER
 RANDOM
 ROUND ROBIN

The answers are:
‐ CPU
‐ RANDOM
‐ ROUND ROBIN



Define Calendars
By defining calendars, you can use them to meet your scheduling and business
requirements.


 You can use calendars to create scheduling terms that are specific to your
scheduling needs.


Define Calendars


Scheduling Terms

You can use calendars to create scheduling terms that are specific to your scheduling needs.

CA Workload Automation DE comes with many defined scheduling terms or keywords.

You can use calendars to create user‐defined scheduling terms such as:
 Holidays
 Special days
 Processing periods
 Days of week

You can define more than one calendar based on user requirements.


System Calendar

The CA Workload Automation DE default calendar is called the System Calendar.
 Calendar definitions are under the Services view in the Calendar perspective.

 Double‐click the calendar name to display stored definitions.

The System Calendar has the following features:
 It defaults to Monday through Friday for workdays.
 Scheduling terms such as holidays, which are generic to all calendars, are stored in
the System Calendar.
 You can use multiple calendars to determine a specific day on which to select a job


User‐defined Calendars

Use user‐defined calendars to create unique scheduling terms.
 You can assign different groups of users their own unique holidays, special days, and
time periods.

 After you set up calendars that meet your needs, you can use these calendars to
schedule workload.


Default Scheduling Terms

CA Workload Automation DE has nearly 50 default scheduling terms that can be used in
multiple combinations to create scheduling scenarios.
 The following terms can only be used in the Event Schedule statement and not in a Job
Run statement:
 Starting, Ending, Until, Every

 You can use default scheduling terms to perform the following actions:
 Schedule, trigger, and simulate events.
 Schedule the suspending and resuming of events.
 Indicate the run frequency of a job.
 Create forecast reports.
 Generate time and date variables using the genTime JavaScript function.

Examples of default scheduling terms include:
 LAST WORKDAY OF MONTH LESS 2 WORKDAYS
 FIRSTDAY OF MONTH PLUS 2 DAYS
 15TH DAY OF MONTH LESS 0 WORKDAYS (go to last workday)
 FRIDAY OF 1ST COMPLETE WEEK OF MONTH
 1ST WORKDAY OF APRIL JULY OCT JAN
 EACH MONDAY OF OCTOBER
 2ND WORKDAY OF WEEK (if Mon is holiday, will run Wed)


Holidays

A holiday is a non‐workday with
a special significance for
scheduling.
 If a holiday coincides
with a workday in the
calendar you are using,
the CA Workload
Automation DE Server
no longer considers the
day to be a workday for
scheduling purposes.

 You can only have user‐
defined labels for holidays.

 Use algorithms to define holidays.
 For MEMORIAL_DAY, select:
 Last
 Monday of May
 Repeat for next 10 years

Holiday scheduling terms can be used in Run or Do Not Run statements, such as:
 Run DAILY
 Do not run HOLIDAYS
You can use the EXCEPT term to exclude a holiday. For example:
Do not run HOLIDAYS EXCEPT MEMORIAL_DAY

The duration can be set to extend a holiday beyond one day.


Special Days

A special day is a user‐defined day with special significance for scheduling.
 You can only use user‐defined labels for special days.

 Adding more than one special day with the same name creates a time period.
 For example, if you create a special day named PAYROLL every 2 weeks, you
create a PAYROLL period.

Accounting periods are defined in the calendar.

After you define a special day, you can use it in scheduling criteria using the normal
scheduling terms:
 PAYROLL LESS 1 WORKDAY
 FIRST MONDAY OF PAYROLL


Special Days Continued

 PAYROLL has a start date and a frequency to occur 26 times every 2 weeks.

 NO_RHYME_REASON_DAY shows a single entry in the calendar for a specific day, so the
job definition would show a run frequency of:
Run NO_RHYME_REASON_DAY

You can define a special day to occur on one specific day only or to recur over a period of
time.



will:

 Define a calendar
See lab 8‐1 Define a Calendar.

 Define a special day
See lab 8‐2 Define a Special Day.




 Define a Calendar

double‐click Lab 8‐1 Define a Calendar.




 Define a Special Day

double‐click Lab 8‐2 Define a Special Day.



Module Summary
 Manage variables and resources



Question

Which predefined scheduling term or terms do CA Workload
Automation DE calendars have?

Response

A. Days of week
B. Daily, workdays
C. Processing periods
D. Holidays, special days

The answer is: Daily, workdays



Question

Which feature applies to holidays?

Response

A. You cannot use default labels for holidays.
B. You can use algorithms to define holidays.
C. You can set the duration of a holiday to extend beyond
one month.
D. A holiday that coincides with a workday in the calendar
you are using is considered to be a workday for scheduling
purposes.

The answer is: You can use algorithms to define holidays.



Manage Variables and Resources
By managing variables, you can reuse information across applications, which
helps streamline applications. Resources enable you to better manage and
regulate workload across your organization.

 Manage variables
 Work with CA Workload Automation DE resources

 By managing variables, you can streamline and simplify applications.
 Working with CA Workload Automation DE resources enables you to
automatically control and regulate workload.


Manage Variables


Manage Variables

By managing variables, you can streamline and simplify applications.

CA Workload Automation DE uses two types of variables:
 Symbolic variables
 Built‐in variables are provided by the CA Workload Automation DE Server to use
as needed.
 User‐defined variables are created in JavaScripts that can be run at event trigger
time or at job and application run time.
 Global variables
 %VAR enables you to specify a global variable name in supported job definition
fields.


Symbolic Variables

Symbolic variables provide powerful substitution capabilities.
 You can define your own symbolic variables or use one of the CA Workload Automation
DE Server built‐in symbolic variables.

 When the server encounters a symbolic variable in an application, job, or alert, it
substitutes the current value of that variable.

 You can use symbolic variables to perform different functions, such as define date
parameters, specify job names, and pass arguments to scripts.

 You can export the value of a symbolic variable to one or more jobs in an application or
to the application itself.

Within an application or job, symbolic variables are identified by their symbol introducer
character. A symbolic variable begins with the percent sign (%) and ends with:
 A space
 Another symbolic variable introducer character
 A character that is not valid in a symbolic variable such as an asterisk (*)
 Any character that is not alphanumeric or an underscore

Each symbolic variable must have a prefix—ESP, APPL, or WOB—that identifies the host
object it belongs to. Symbolic variables can use:
 Concatenation
 Compounding
 Substrings


Built‐in Symbolic Variables

 The server built‐in symbolic variables consist of two parts:
 A prefix that identifies the scope of the symbolic variable
 A symbolic variable name, separated by a period

 To use a built‐in symbolic variable:
 Ensure the value for the symbolic variable will be set before the time when you
need it resolved
 Specify the symbolic variable in the appropriate input field where you want the
symbolic variable to be resolved

The CA Workload Automation DE Server provides several built‐in date and time symbolic
variables that you can use for scheduled, actual, or run‐time dates or times. The first
character after the period determines if it is:
 Scheduled (S): Scheduled time of the event
 Actual (A): Actual time the generation was built
 Runtime (R): Time the generation was ready to run
 APPL._RDATE refers to application ready or run time.
 WOB._RDATE refers to job ready or run time.
 Run‐time variables cannot be used at Event trigger time.
Use the genTime built‐in function to customize date and time symbolic variables outside of
built‐in dates:
genTime('NW', ‘TODAY PLUS 1 WORKDAY')

In this example, genTime is creating a variable named NW with the value of ‘TODAY PLUS 1
WORKDAY’, in any format.


Built‐in Symbolic Variables Continued

 The server provides the following types of built‐in symbolic variables:
 ESP‐prefixed
 APPL‐prefixed
 WOB‐prefixed
 Date and time
 ESP‐level variables can be used in any application.
 APPL‐level variables can be used anywhere within an application.
 WOB‐level variables can be used within job definitions.
The following screenshot shows an example of a job arguments statement to get the date value
in MMDDYY format:

These are examples of application built‐in symbolic variables:
 APPL._event: Full name of the event, SCHEDMASTER.TEST
 APPL._eventname: Event part of the name only, TEST
 APPL._eventprefix: Prefix portion of the name, SCHEDMASTER
 APPL._ftfile: File name passed from the File Trigger object
 APPL._name: Name of the application
 APPL._gen: Generation of the application

These are examples of job (WOB) built‐in symbolic variables:
 WOB._name: Name of the job
 WOB._agent: Name of the agent where the job is running
 WOB._avgruntime: Average run time of the job
 WOB._cmpc: Completion code from the job
 WOB._retrycount: Number of retries for a failed job
 WOB._state: State of the job


User‐defined Symbolic Variables

You can define your own symbolic variables and use them to substitute values in an application,
job, or alert.

 Depending on where you want to use a symbolic variable, define it at the job,
application, or system level.

 Do not define a symbolic variable with an underscore after the prefix and period. This
format is reserved for CA Workload Automation DE Server built‐in symbolic variables.

 You cannot use symbolic variables in event definitions.

You can create symbolic variables in all lowercase, all uppercase, or mixed case. However,
symbolic variables are case‐sensitive. You must specify the variable exactly as it is defined.


Using Symbolic Variables

Use symbolic variables to:
 Pass variables to job arguments

 Pass variables to alerts and notifications

 Create generic job definitions that can be reused

 Create application run‐time names

 Automate the creation of date and time variables in job definitions

After the JavaScript has executed, the user‐defined variable in the definitions will be
substituted. Uses for user‐defined variables include:
 Path names
 Agent names
 Substrings for other fields
 Counters


Global Variables

Global variables enable you to store information that you can reuse across applications.
 Global variables do not need APPL or WOB prefixes to determine where they can be
used.

 To create, modify, and delete global variables, you can use the Services perspective in
the Desktop Client, the CLI, or JavaScript functions.

 Global variables are stored in the relational database for CA Workload Automation DE.

Each global variable belongs to a context, similar to a prefix, which is a group of related
variables. Contexts help you avoid naming conflicts. For example, you can create two
variables named deptname, each in a different context (EAST.deptname and
WEST.deptname).

By default, all global variables are defined in the DEFAULT context.


Global Variables Continued

 Global variables are created in the Services perspective under the Global Variable view.

 The same variable name can be used for multiple contexts.

 Changes to the value of a variable are dynamic.


Variable Differences

Global and symbolic variables have the following differences:

Global Variables Symbolic Variables

 Are not dependent on JavaScript
 Are JavaScript variables whose value can
 Are stored in the relational be accessed outside the context of the
database for CA Workload JavaScript
Automation DE
 Are stored in built‐in JavaScript host
 Support variable dependencies objects

 Are more manageable because
they are not dependent on
JavaScript


% VAR

When an event is triggered, the CA Workload Automation DE Server tries to substitute the
current value of a global variable specified in the %VAR statement.
 If the variable is not defined at that time, the statement remains unresolved until the
job run time.

 If the variable is still undefined at run time, the server submits the job with an
unresolved variable.

The %VAR function is a JavaScript that has been built into a command. The %VAR statement
follows JavaScript rules. The syntax is case‐sensitive.

Note: You must have the appropriate security permissions to read global variables to run this
script. Without the appropriate permissions, the job goes into a SUBERROR state.


% VAR Continued

 VAR('name')
 This statement goes to the DEFAULT context.

 %VAR('name'[,'context'])
 The variable name goes in quotes.
 The context goes in quotes.

 %VAR('agentname',APPL._eventname)
 You can use global variables and symbolic variables within a variable.
 If using a symbolic variable, do not place it in quotes.
 A symbolic variable does not use %.
 This statement allows for the reuse of definitions. This example gets the name of
the event and uses it as the context:
 EVENT PROD.SACTO would use the variable 'agentname' under the
Context of 'SACTO.'

This slide displays the syntax for using the %VAR function.



will:

 Define a variable
See lab 9‐1 Define a Variable.




 Define a Variable

double‐click Lab 9‐1 Define a Variable.



Work with CA Workload Automation DE
Resources


Resources

Working with CA Workload Automation DE resources enables you to automatically control
and regulate workload.

A resource is a job dependency that can be quantified by specifying its availability count.
 Resource dependencies affect the ability of a job to run successfully.

 The CA Workload Automation DE Server only submits jobs that have met all resource
requirements.
 For example, if a job needs three resource units and only two units are available,
the job cannot run (RESWAIT) until all three resource units are available.

CA Workload Automation DE has three resource types:
 Renewable
 Threshold
 Depletable


Resource Types

Renewable
Threshold
Depletable

When you create an event, you need to consider what type of activity will trigger it. There
are a number of different types from which you can choose.


Resource Types
Renewable

A renewable resource is a borrowed resource.
 When the server submits a job, the job removes the borrowed units of the renewable
resource from the resource pool.

 The resource units are not permanently used up.

 The resource units return to the resource pool when the job completes or fails.

 The job borrows the resource units so it can run successfully.
 For example, you can use a renewable resource to control concurrent write
access to a database.

Jobs use renewable resources to borrow units from a resource pool to complete a job
successfully.


Resource Types
Threshold

A threshold resource is a sizing resource and works more like a switch.
 A job does not consume or borrow resource units from the resource pool while it runs.
 For example, if the resource quantity is set to two, the server submits all jobs
that require two or fewer units.

 The server does not submit any job requiring three or more units. It sizes the job against
the current level of the threshold resource.
 For example, you can use a threshold resource to represent a period when you
run low‐priority jobs.

A threshold resource is used by jobs that use a specific number of resource units to run.


Resource Types
Depletable

A depletable resource is a consumed resource.
 When the server submits a job, the job permanently removes the consumed units of the
depletable resource from the resource pool.

 When the resource depletes, it can be replenished for other jobs to use.
 For example, you can use a depletable resource to represent disk space.

A depletable resource uses units from the resource pool to run jobs but it can then be
replenished for reuse.


Controlling Active Workload

Resources are defined in the Services perspective, on the Resources tab.

The availability number is different for each resource type:
 For renewable resources, it is the number of units of the resource now available.
 For threshold resources, it is the number of units needed to submit all jobs requiring
less than a certain number of units.
 For depletable resources, it is the number of units available.


Controlling Active Workload Continued

After a resource is defined, use the Resources tab of the job definition to define how many
units will be consumed.

You can control workload by defining the number of units that a resource consumes. This
enables you to prioritize jobs.


Modifying Resource Values

 There are three ways to modify resources:
 Monitor perspective
 Services perspective, on the Resources tab
 CLI

 For renewable resources, the maximum available field is not changed because it is the
upper limit for the field.

 You can change availability for:
 Renewable resources
 This can be changed to any number equal or less than the maximum
available.

 Threshold resources
 This is usually 0 or 1, but it can be any number.

 Depletable resources
 This is set to a number greater than 0 to start decrementing against.

Resources can be modified, but maximum availability cannot be modified for renewable
resources because they need to use the upper limit of maximum availability.


Modifying Resource Values Continued

To change resource values in the Monitor perspective:



will:

 Define CA Workload Automation DE
resources
See lab 9‐2 Define CA Workload
Automation DE Resources.




 Define CA Workload Automation DE
Resources

double‐click Lab 9‐2 Define CA Workload
Automation DE Resources.



Module Summary
 Manage variables

 Work with CA Workload Automation DE
resources

 Describe CA Workload Automation DE
JavaScripts



Question

What is a group of related variables?

Response

A. A context
B. Symbolic variables
C. Built‐in symbolic variables
D. User‐defined symbolic variables

The answer is: A context



Question

What is a renewable resource?

Response

A. It is a sizing resource and it works like a switch.
B. It is a consumed resource that can be replenished for
other jobs to use.
C. It is a borrowed resource and the resource units are not
permanently used up.
D. It helps ensure a job does not consume or borrow
resource units from the resource pool while it runs.

The answer is: It is a borrowed resource and the resource units are
not permanently used up.



Describe CA Workload
Automation DE JavaScripts
Working with scripts enables you to extend the capabilities of CA Workload
Automation DE. Acquiring JavaScript skills enables you to use advanced
scheduling features to suit your business needs.

 Identify JavaScript components

 To extend the capabilities of CA Workload Automation DE, you need to
gain a basic understanding of the JavaScript components.


Identify JavaScript Components


Extended Capabilities Using JavaScript

To extend the capabilities of CA Workload Automation DE, you need to gain a basic
understanding of
the JavaScript components.

You can use JavaScript within an application or alert to perform many types of operations.
 Some common uses for a script include the following:
 Using conditional logic to specify a variation in the schedule
 Defining symbolic variables
 Using built‐in server functions


CA Workload Automation DE JavaScript

By using JavaScript within your applications, you can take advantage of advanced scheduling
features.
 With CA Workload Automation DE, JavaScript supports many functions that are
unavailable from the CA Workload Automation DE Desktop Client interface. For
example, you can use JavaScript to:
 Create and manipulate symbolic variables
 Use CA Workload Automation DE built‐in functions
 Perform comparison, arithmetic, and logical operations
 Prepare program input and parameters
 Build decisions into schedules

JavaScripts can be:
 Created within and used only by a single application definition
 Stored in a central repository for use by any application


User‐defined Variables

You can use JavaScript to create and update user‐defined variables, for example:
var home = "c:\\home";
Note: This is a sample JavaScript statement. In addition to user‐defined variables, CA
Workload Automation DE also uses conditional logic.

Many existing customers have multiple JavaScripts defined. A previous release of CA
Workload Automation DE introduced global variables. Because JavaScripts can be stored in
the database, they can be pointed to from within the definitions. Before this release, all user‐
defined variables had to be created using JavaScript and all JavaScripts were stored with an
application. The JavaScripts were created and stored in a directory, but they still had to be
brought in and saved within the application.

User‐defined variables were covered in the “Manage Variables and Resources” module.


Conditional Logic Statements

A conditional statement is a set of commands that runs if a specified condition is true.
 JavaScript supports two conditional statements:
 In an if…else statement, when a specified condition is true, the if statement
performs the block of code defined within the if portion.
 If the specified condition is false and the else statement is present, the
code in the else statement will be performed.

 A switch statement enables a script to evaluate an expression and then compare
it to the values for each case within the structure.
 If a match is found, the program runs the block of code associated with
that case.


Conditional Logic Statements Continued

 if statement
 This specifies actions when a condition is true.

 if…else statement
 This specifies actions for true and false conditions.
if (MyNumber%2 == 0) MyType = 'Even';
else MyType = 'Odd';

 You must use { } to group multiple actions:
if (LateJob == "PAYROLL" && Hour > 10)
{
Notify = ‘cliffwarner@mycompany.com';
Severity = 2;
}

 Switch statement
 This evaluates an expression and matches value to case.

A sample switch statement is:
switch (PAYROLL){
case "Thursday":
alert("Pay day")
break;
case "Wednesday":
alert("Pay day is tomorrow")
break;
case "Friday":
alert("Pay day was yesterday")
break;
default : alert("Pay day is Thursday");
}


Conditional Logic Statements Continued

 You can use the if…else statement to define variables.
 This example defines the WOB.earlysub variable, which is the time the job must
start before it is marked as overdue:
if (today('last workday of month'))
{ WOB.earlysub = "6pm"; }
else
{ WOB.earlysub = "8pm"; }
In the job definition, the result shows as:

Variables can be defined using conditional statements such as if…else.


%IF

The %IF statement:
 Is supported in the Application or Job fields in which you use a variable
 This reduces the need to use JavaScript.

 Can replace an if or if…else statement
 For example, if today is a weekday, a job has a submit time of 4:00 p.m., else it
has a submit time of 1:00 p.m.

 Can evaluate a JavaScript logical expression and use the true value or the false value
based on the result
Note: The default value is null.

You can use the %IF statement instead of JavaScript in an application where you define a
variable.


%IF Continued

You can use the %IF statement to:
 Set a time dependency to 7:00 p.m. on the first workday of the month

 Run a different command file after a holiday

 Set an agent name based on the last Sunday of the month and when the actual month
number is even

The %IF statement can be used in a variety of conditional statements, such as setting an
agent name based on specific conditions.


Built‐in Functions

The CA Workload Automation DE Server provides built‐in functions to meet your scheduling
needs.
 A function is a set of instructions that can receive data, process that data, and return a
value.

 Built‐in functions do not have a symbol introducer character.
 They are JavaScript constructs that are automatically recognized by the server.

You can use built‐in functions, for example, if you want to check if a variable is defined. They
enable you to test different criteria.


Built‐in Functions Continued

 A built‐in function has the following format:

function_name(arguments)
Where function_name must be a valid function name and arguments is a list of values
specific to that function

Note: Function names are case‐sensitive and must be typed exactly as shown.

Examples of built‐in functions include:
 daysTo: Calculate the days to date
 daysFrom: Calculate the days from date
 daysBetween: Calculate the days between dates
 Today: Test if today matches criteria
 yesterday: Test if yesterday matches criteria
 tomorrow: Test if tomorrow matches criteria
 genTime: Generate date and time variables
 execCommand: Control job, subApplication, or Application
 resetResourceProperty: Reset the resource count
 execTrigger: Trigger an event
 Defined: Check if a variable is defined


genTime Function

You can use the genTime function to generate date and time variables in JavaScript and indicate
the script should run at run time:
APPL.genTime('pwd','today less 1 workday');
APPL.genTime('fwd','1st workday of this month');
APPL.genTime('ldpay','last day of pay_period');
 You can pass variables as arguments to jobs.

The genTime function enables you to define date and time variables that you can use in
statements.


Local and Global Scripts

You can create JavaScripts within applications or in the central repository.
 Within applications
 Use the JavaScript tab under Application Properties to define, import, or export
scripts.
Note: You must identify the JavaScript to run, the location, the specific jobs, and
when to run it.

 Central repository
 Use the JavaScripts tab under the Services perspective.
Note: This enables you to reuse the same script in different applications and
minimizes maintenance.

The JavaScripts in the central repository can be reused in various applications.


Local and Global Scripts Continued

 Specify the script and job to run:
 At the application level:
 Use Application Properties.
 The script runs for every job.

 At the job level:
 Use the General tab for the job.
 The script runs for specific jobs.

 The drop‐down list contains the scripts defined within the application and the central
repository, which you can access.
 You can view the actual script contents regardless of where it is defined.

Depending on whether you create a JavaScript in an application or a job, you can specify the
script to run for a specific job or for every job.


Alerts

An Alert notification can trigger additional workload automatically.
 When a job reaches the state specified in the alert notification, the server automatically
triggers the event defined in the alert.

 Alerts can:
 Use built‐in variables
 Run JavaScript to execute commands such as the following:
 Resubmit a job.
 Complete a job or application.
 Drop dependencies and resource dependencies.
 Reset time dependencies and resources.
 Bypass a job.
 Hold and release jobs or applications.


Alerts
Example

To execute an alert to force
complete a failed job with an
exit code of 1 or more, in the
Services perspective, create and
define the alert to run JavaScript
as follows:
 Click the Run this
JavaScript option.

 Enter the following
script:

if (WOB._cmpc==1) {
execCommand('ALL',’
%(APPL._name).%APPL._
gen',
'ACTION COMPLETE');
}


Review Question

Question

Which statement evaluates an expression and matches value to
case?

Response

A. if
B. %IF
C. if...else
D. Switch

The answer is: Switch

The switch statement evaluates an expression and matches values
to case.



will:

 Define a JavaScript
See lab 10‐1 Define a JavaScript.




 Define a JavaScript

double‐click Lab 10‐1 Define a JavaScript.



Module Summary
 Identify JavaScript components

 Employ other features


Assessment Question

Question

Which feature does a built‐in function have?

Response

A. It has a symbol introducer character.
B. It has a format of (arguments) function name.
C. It is a JavaScript construct that is recognized by the
server sometimes.
D. It is a set of instructions that can receive data, process
that data, and return a value.

The answer is: It is a set of instructions that can receive data,
process that data, and return a value.



Employ Other Features
By employing other features, such as defining notifications, creating CA
Workload Automation DE alerts, and generating forecast reports, you can better
automate and control workload using CA Workload Automation DE.

 Define notifications
 Create CA Workload Automation DE alerts
 Generate forecast reports

 You can define notifications based on your business requirements,
enabling you to respond properly to workload outages.
 Creating CA Workload Automation DE alerts based on your business needs
helps ensure you have a good workload process.
 By generating forecast reports, you are prepared for outages and can plan
ahead.


Define Notifications


Define Notifications

You can define notifications based on your business requirements, enabling you to respond
properly
to workload outages.

Notifications enable you to monitor job progress automatically. Then, you can notify users or
take action when the job reaches a certain state or condition.
 Notifications can be defined at the application or job level.
 Job‐level definitions override the application level for that notification type.
 Applications or jobs can have multiple notifications defined for more than one
monitor state.

 CA Workload Automation DE has three default notification types:
 Alert
 Email
 SNMP

You can set up notifications for different job‐processing monitor states, such as when a job
completes, fails, or becomes overdue, or for specific exit codes.

Notification defaults for any new application can be defined with the Desktop Client under:
Windows\Preferences\Desktop Client\Define‐Application defaults\Notifications


Alert Notification

You can set up an alert notification to trigger additional workload automatically.

For example, when a job reaches the state specified in the alert notification, the CA
Workload Automation DE Server automatically triggers the event defined in the alert.


Email Notification

You can set up an alert in the form of an email notification so that if an alert occurs, an email is
sent to notify users.

For the message text, you can use the default message, append text to the default message,
or override the default to use your own message.

When overriding the default subject or message, you can insert application‐ and job‐level
built‐in symbolic variables using a menu. Your administrator can edit the default subject and
message by modifying the default email template defined in the Topology.


SNMP Notification

You can set up an SNMP notification, which enables you to create a message to be sent to the
SNMP Manager when an alert occurs.

The Complete state is only applicable for z/OS jobs and available at the Application level.


SMTP Server

The server can send different types of job‐, application‐, and server‐level notifications.
 Specify the server host name or IP address with an email address.
 The server cannot authenticate against the messaging server; it has to relay the
mail.



will:

See lab 11‐1 Define Notifications.




 Define Notifications

double‐click Lab 11‐1 Define Notifications.



Create CA Workload Automation DE
Alerts


CA Workload Automation DE Alerts

Creating CA Workload Automation DE alerts based on your business needs helps ensure you
have a
good workload process.

An alert is one of three notification types in CA Workload Automation DE.
 Alerts are internal.

 Alerts can start additional workload, run a JavaScript, or take action against jobs using a
JavaScript.

 Application and job information is passed to the alert when triggered.

 An alert notification can trigger additional workload automatically.
 You can trigger an event for all jobs or specific jobs in an application.

When a job reaches the state specified in the alert notification, the CA Workload Automation
DE Server automatically triggers the event defined in the alert. For example, when the last
job of an application completes, an alert can trigger an event to run another application.


Alert Processing

An alert executes a JavaScript to run commands, such as the following:
 Resubmit a job

 Complete a job or application

 Drop job dependencies

 Drop resource dependencies

 Reset time dependencies

 Bypass a job

 Hold and release jobs or applications

 Reset resource availability counts

Alerts can run JavaScript to execute commands that run on jobs and applications.


Alert Processing Continued

Alerts are defined in the Services perspective on the Alerts tab.

Alerts can run a JavaScript to execute commands that run on jobs and applications.

When you define an alert, you need to be clear on what the alert does so this is obvious to
the user.



will:

 Add an alert to an application
See lab 11‐2 Add an Alert to an
Application.

 Create a JavaScript alert
See lab 11‐3 Create a
JavaScript Alert.




 Add an Alert to an Application

double‐click Lab 11‐2 Add an Alert to an
Application.




 Create a JavaScript Alert

double‐click Lab 11‐3 Create a JavaScript
Alert.



Generate Forecast Reports


Generate Forecast Reports

By generating forecast reports, you are prepared for outages and can plan ahead.

Generating forecast reports is very beneficial because the report enables you to plan your
workload.
 You can create and generate forecast reports about jobs scheduled to run during a
specific period and use these reports to plan your workload.

 Forecasts reports can also be scheduled as an event and be run during non‐peak hours.
 To display the new event type options, in the Events window, right‐click under
Services.


CA Workload Automation DE
Forecasting

You can generate forecast reports and run forecasts at any time that suits you.
 You can limit the events, applications, and jobs that appear in your forecast reports.

 Nonscheduled events do not appear in the forecast report unless they have an expect
time coded.

Reports are run and created within the Forecast View and by using Generate Forecast
Report. Reports can also be printed and forecasts can be saved to run again later.

Each report contains information about:
 Scheduled jobs, including job name and qualifier
 The event submission date and time
 The estimated execution time based on historical information
 The agent name
 The application name
 The event name
 Predecessor and successor names


Forecasting Specifications

You can create forecast reports
based on combinations of:
 Event names

 Application names

 SubApplication names

 Job names

 Threshold frequency

An event execution is excluded from the forecast report if the time between its scheduled
execution and its next scheduled execution is less than the threshold frequency.


Gantt Charts

You can use Gantt charts to display information from a forecast report.
 Gantt charts:
 Show a forecast by an anticipated end time based on an average run time
 Can be printed and the information in them is based on information in the
forecast report



will:

See lab 11‐4 Generate Forecast
Reports.




 Generate Forecast Reports

double‐click Lab 11‐4 Generate Forecast
Reports.



Best Practices

 Forecast reports can now be scheduled.

 You can add forecast and report events.

 Schedule the non‐critical reporting events to run
during non‐peak hours.


Module Summary

 Create CA Workload Automation DE alerts


 Manage users using LDAP



Question

What does an alert notification do?

Response

A. It enables you to set up an alert for jobs only.
B. It creates a message to send to the SNMP Manager.
C. It enables you to set up an alert for applications only.
D. It triggers an additional workload automatically.

The answer is: It triggers an additional workload automatically.



Question

Which option is a feature of an alert?

Response

A. Alerts are external.
B. Alerts are internal.
C. Alerts are defined in the Monitor perspective.
D. Alerts run JavaScript scripts to prevent commands from
running.

The answer is: Alerts are internal.




Question

Which feature does a forecast report have?

Response

A. It shows a forecast by an anticipated end time based on
an average run time.
B. You need an unlimited amount of events, applications,
and jobs in your forecast report.
C. Scheduled events do not appear in the forecast report
unless they have an expect time coded.
D. It contains information about jobs scheduled to run
during a specific period, which can be used to plan your
workload.

The answer is: It contains information about jobs scheduled to run
during a specific period, which can be used to plan your workload.



Manage Users Using LDAP
CA Workload Automation DE permits LDAP authentication. LDAP is a powerful
protocol for accessing directory services because it offers simple means for
searching, retrieving, and manipulating directory content.

After completing this module, you will be able to::
 Define the LDAP server

 Defining an LDAP server enables you to retrieve and permit a set of users
to log in to CA Workload Automation DE.


Define the LDAP Server


LDAP Integration Overview

Defining an LDAP server enables you to retrieve and permit a set of users to log in to CA

If you run an LDAP server, you can use the LDAP services to authenticate your CA Workload
Automation DE users.
 CA Workload Automation DE r11.3 supports the following LDAP servers:
 Microsoft Active Directory
 Novell eDirectory
 Sun One Directory

 CA Workload Automation DE r11.3 supports version 2 and 3 of the standard LDAP API.
 Uses version 3 as the default version

If you have an LDAP server, you can import LDAP users into CA Workload Automation DE and
activate them.


LDAP Integration Overview Continued

To use LDAP authentication, you must configure the LDAP server to work with the product.
 Multiple LDAP servers can be added and configured.
 Define the server usage priority for each server; 1 being the highest priority.
 Based on availability, CA Workload Automation DE will contact the
highest priority server.

 They must be of the same server vendor type.

 Imported LDAP users need to be activated before using them.

 Email and SNMP notifications are sent when the LDAP connection is lost or established.

To use LDAP authentication, you must configure the LDAP server to work with the product.
The server needs to be restarted for the LDAP configuration to take effect.

Multiple LDAP servers can be added and configured in the Topology under the
Authentication Systems node. The CA Workload Automation DE Server uses the LDAP server
based on the priority value you specify, with the lowest value indicating the highest priority
level. Multiple LDAP servers are used for failover.

Imported LDAP users are inactive until you activate and assign them the required
permissions. The CA Workload Automation DE Server synchronizes the list of users on the
LDAP server every 30 minutes by default. You can change this frequency by configuring the
shared parameters for the authentication systems.

In the case of a lost LDAP connection, you can shut down the CA Workload Automation DE
server automatically by configuring the shared parameters for the authentication systems.


Security Considerations

 Non‐SSL LDAP server communication
 User names and passwords sent in plain‐text format

 SSL‐based LDAP server communication
 Simple authentication used
 Requires the trust certificate of the LDAP server

 Account suspension due to multiple login failures
 Handled by the LDAP server

To establish SSL communication between the CA Workload Automation DE Server and the
LDAP server, the trust certificate that the LDAP server uses must be added to the CA
Workload Automation DE trust store. The LDAP server can use a self‐signed certificate or a
certificate signed by a Certification Authority (CA).

Account suspension due to multiple login failures is handled by the LDAP server, not by the
CA Workload Automation DE Server.


Permissions

LDAP configuration is controlled by the ADMIN.Network Topology resource.
 Creation and deletion configuration requires ALTER permissions.

 Update configuration requires UPDATE permissions.

 Read configuration requires READ permissions.

The ADMIN.Network Topology resource grants ALTER, UPDATE, or READ permissions to a
user to work with the LDAP configuration.


Working with LDAP Users
Initial Security View User Definition

When LDAP authentication is successful after server restart, on opening the Security view of the
Admin perspective, you will see all LDAP users and users internal to the server.

Initially, all users with a Remote only Authentication mode value will have an Activation
status value of New, which means they still cannot be used for authentication. The
respective action required is to import the user from the authentication system.

Users can have the following Activation status:
 Active, which indicates the user is active in LDAP and defined in CA Workload
Automation DE and can be used to log in
 New, which indicates the user is active in LDAP but not defined in CA Workload
Automation DE. To log in, the user needs a valid definition in the CA Workload
Automation DE Server.
 Inactive, which indicates the user has been deactivated from LDAP. This is the case
when an LDAP user is activated earlier but is now deleted from LDAP.
If the Authentication mode value is Remote only, the password field is disabled. At login, this
user is required to provide the LDAP password. Then, it will be passed to the server and then
to LDAP for authentication.


Activate an LDAP User

For an LDAP user to be used in workload, the respective user needs to be activated in the
server.


Link a Local User

Link a local user to the authentication system.

There is an instance where you might need to link a local user to the authentication system.
This happens when there is a local user defined in the CA Workload Automation DE Server
and another user with the same identifier in the LDAP server, but the local definition is using
Local only as the authentication mode.


Use Filters

You can view users based on authentication types and active status.
 By default, all users, local and remote, are shown in the Security window.


Update Authentication to Local Only or Delete the User


Review Question

Question

Which authentication options are available when linking a local
user to LDAP? (Choose two.)

Response


 Local only
 Active only
 Remote only
 Remote and Local
 Against Active Directory forest

The answers are:
‐ Remote only
‐ Remote and Local

When linking a local user to LDAP, the authentication options are
remote only and remote and local.


Module Summary
 Define the LDAP server

 Manage CA Workload Automation DE with Web Services


Assessment Question

Question

Which component handles account suspensions due to multiple
login failures?

Response

A. LDAP server
B. Microsoft Active Directory
C. CA Workload Automation DE agent
D. CA Workload Automation DE server

The answer is: LDAP server



Manage CA Workload Automation
DE with Web Services
With CA Workload Automation DE Web Services, you can integrate the server in
a Service Oriented Architecture (SOA) using Simple Object Access Protocol
(SOAP) over HTTP or HTTPS to create, update, invoke, monitor, and control
workload.

 Define Web Services

 By using Web Services, you do not need proprietary software to integrate
the server with other services in a business process.


Define Web Services


Web Services

By using Web Services, you do not need proprietary software to integrate the server with
other services
in a business process.

Web Services API calls enable third‐party solutions to create, update, invoke, monitor, and
control workload.
 Prerequisites to access CA Workload Automation DE Web Services:
 The Web Services component must be installed.
 Apache Tomcat 6.0 comes pre‐packaged with the Web Services
installation.

 Implementation details:
 Web Services have been re‐implemented using Axis2.
 The web service name is EspDSeriesService.
 Communication is protected by enabling SSL at the web server.
 User credentials are passed using the basic authentication scheme.
 Web Services use the document style format.

The Web Services component is installed from the CA Workload Automation DE DVD, and
can be installed on Linux or Windows OS.


API Calls
Artifacts, Resources, and Applications

You can use Web Services to call artifact‐, resource‐, or application‐specific functions.

Artifacts Resources Applications

 deleteArtifact  dropResourceDependency
 deleteVersion  getResourceUsage  completeApplication
 listArtifact  setResourceAvailability  getApplicationStatus
 listVersion  setResourceMaxAvailability  holdApplication
 releaseApplication
 unwaitApplication

The deleteArtifact function deletes an artifact definition.
The deleteVersion function deletes a version of an artifact definition.
The listArtifact function lists defined artifacts.
The listVersion function lists artifact versions.

The dropResourceDependency function drops the resource dependencies of a job.
The getResourceUsage function returns the usage status of a resource.
The setResourceAvailability function sets the availability of a resource.
The setResourceMaxAvailability function sets the maximum availability of a renewable
resource.

The completeApplication function completes an application.
The getApplicationStatus function returns the status of one or more applications.
The holdApplication function holds an application.
The releaseApplication function releases a held application.
The unwaitApplication function unwaits an application.


API Calls
General, Jobs, and Global Variables

You can use Web Services to call general and job‐ or global variable‐specific functions.

General Jobs Global Variables
 executeCLICommand  bypassjob  createVariable

 getServerTimeZone  cancelActiveJob  decrementVariable
 testScheduleCriteria  completeJob  deleteVariable
 getJobComments  deleteVariableContext
 getJobStatus  dropVarDependency
 holdJob  evalVarDependency
 readyJob  incrementVariable
 requestJob  listVariable
 resubmitJob  listVariableContext
 unrequestJob  setVariable
 unwaitJob
 updateJobUserStatus

The executeCLICommand function executes a CLI command.
The getServerTimeZone function returns the server time zone information.
The testScheduleCriteria function tests schedule criteria.

The job‐specific functions include completing a running job, getting the status of a job,
holding a job, releasing a hold job, bypassing or unbypassing a job, and resubmitting a job
after modifying its definition.

The global variable‐specific functions include creating or deleting a global variable,
incrementing and decrementing a value of a global variable, and evaluating the variable
dependency on a job.


API Calls
Events

You can use Web Services to call event‐specific functions.

Events Events
 bypassEvent  runApplicationList
 holdEvent  runApplicationRead
 listActiveApplicationsForEvent  runApplicationUpdate
 listEventSchedule  suspendEvent
 releaseEvent  triggerAddEvent
 resumeEvent  triggerReplaceEvent
 runApplicationCreate  unbypassEvent
 runApplicationDelete

Some event‐specific functions include:
 bypassEvent: Bypass a scheduled event execution.
 holdEvent: Hold (postpone) an event to prevent the event from triggering until you
release it.
 releaseEvent: Release a held event.
 resumeEvent: Resume a suspended event.
 suspendEvent: Prevent an event from triggering.
 triggerAddEvent: Trigger an event in addition to its usual schedule.
 triggerReplaceEvent: Replace the next scheduled execution of an event with a new
time.


Review Question

Question

Which web server is used to deploy CA Workload Automation DE
Web Services?

Response

A. Tomcat 7.0
B. Microsoft IIS
C. Apache HTTP
D. Apache Tomcat 6.0

The answer is: Apache Tomcat 6.0

The Apache Tomcat 6.0 web server is used to deploy CA Workload
Automation DE Web Services.


Module Summary
 Define Web Services


Assessment Question

Question

Which prerequisites are required to access CA Workload
Automation DE Web Services? (Choose two.)

Response


 The Apache server must be running.
 The Web Services component must be installed.
 The Web Services agent must be installed on the server.
 The Tomcat server must be running with the Web
Services component deployed.
 The Tomcat server must be running, but the Web
Services component does not have to be installed at this
time.

The answers are:
‐ The Web Services component must be installed.
‐ The Tomcat server must be running with the Web Services
component deployed.



Course Summary
You are now able to do the following:
 Identify the product architecture and the relationship between each component in CA
 Work with the Desktop Client to more efficiently define, monitor, and control enterprise
workload from a single point of control.
 Identify the server administration and maintenance settings to enable you to achieve
 Create applications to logically group processes.
 Create CA Workload Automation DE events to control applications.
 Monitor and control active workload to regulate your workload.
 Automate workload on different servers and distribute workload between similar
platforms and operating systems by identifying the components, features, and functions
of agents and agent groups.
 Work with calendars to meet your business needs.
 Manage variables to streamline and simplify applications to decrease overhead.
 Work with scripts to learn how to extend the capabilities of CA Workload Automation
DE.
 Create CA Workload Automation DE alerts and generate forecasting reports so you can
better automate and control workload using CA Workload Automation DE.
 Define an LDAP server to enable you to retrieve and permit a set of users to log in to CA
 Manage CA Workload Automation DE with Web Services so you can create, update,
invoke, monitor, and control workload.

Thank You

Congratulations, you have completed this course. You will receive an email with a link to a
survey requesting your feedback on this learning experience. Please take a few moments to
complete the survey.

To learn more about this product, connect with other users, and share your own expertise, visit
the CA Workload Automation community at the following URL:
https://communities.ca.com/community/ca‐workload‐automation
(https://communities.ca.com/community/ca‐workload‐automation)

Also, visit the CA Workload Automation DE wiki at the following URL:
https://wiki.ca.com/display/WLADE133 (https://wiki.ca.com/display/WLADE133)



85DSR2008 STD G1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

85DSR2008 STD G1

Uploaded by

Copyright:

Available Formats

© 2016 CA. All rights reserved. CA confidential & proprietary information.

No unauthorized use, copying or distribution.

CA is the manufacturer of these Materials.

Provided with “Restricted Rights.”

 LISTAGENTGROUP  BYPASSEVENT  LISTQUIESCESTATE

 executeCLICommand  bypassjob  createVariable

You might also like