AppWorx 7 0 Basic Oper and Dev Student Guide Content

AppWorx 7.
0
Basic Operations and Development
Student Guide
AppWorx Corporation
AppWorx Basic Training

Document No. 70OD-S-042006
Copyright 2002 - 2006 AppWorx Corporation
All Rights Reserved. Printed in USA.
This document may not be copied, photocopied, reproduced, translated or reduced
to any electronic medium or machine readable form, in whole or in part, without
the express written consent of AppWorx Corporation. The information contained
in this document is subject to change without notice and does not represent a
commitment on the part of AppWorx Corporation. The software described in this
document is distributed under a license agreement or nondisclosure agreement.
The software may be used and/or copied only in accordance with the terms of the
agreement.
AppWorx is a registered trademark of AppWorx Corporation. All other product
names and services identified throughout this book are trademarks or registered
trademarks of their respective companies.
AppWorx Corporation
2475 - 140th Avenue NE

Bellevue, WA 98005 United States
Phone: 877-APPWORX (877-277-9679)
Fax: 425-644-2266
support@appworx.com
www.appworx.com
AppWorx Europe Ltd.
Basepoint Business & Innovation Centre, Unit 1

Metcalf Way, Crawley
West Sussex RH11 7XX United Kingdom
Main Telephone Number : +44 (0) 1293 813900
Fax Number: +44 (0) 1293 813901
uk@appworx.com
AppWorx 7.0 Basic Operations and Development Student Guide
iii
Contents
Lesson 1 Introduction ............................................................................................................. 1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
Course Overview................................................................................................................................ 2
Introduction to AppWorx..................................................................................................................... 4
AppWorx Is Object-Oriented .............................................................................................................. 6
AppWorx Architecture ........................................................................................................................ 8
Using the AppWorx Desktop ............................................................................................................ 10
Using Explorer.................................................................................................................................. 12
Adding, Editing, and Deleting AppWorx Objects.............................................................................. 14
Running Reports .............................................................................................................................. 16
Editing User Settings........................................................................................................................ 18
Exercise 1A: Modifying Your User Settings ................................................................................. 20
1.10 Review Questions .......................................................................................................................... 22
Lesson 2 Requesting Jobs ................................................................................................... 25

2.1 Introduction to Requesting Jobs....................................................................................................... 26
2.2 Requesting and Submitting Modules and Chains ............................................................................ 28
2.3 Viewing Output with the File Viewer................................................................................................. 30
Exercise 2A: Running a Module from the Requests Window....................................................... 32
2.4 Review Questions ............................................................................................................................ 34
Lesson 3 Monitoring and Managing Agents and Queues .................................................. 37

3.1 Introduction to Monitoring and Managing Agents and Queues ........................................................ 38
3.2 Managing Agents ............................................................................................................................. 40
3.3 Managing Queues............................................................................................................................ 42
Exercise 3A: Creating a Queue and Running a Job Through It ................................................... 44
3.4 Review Questions ............................................................................................................................ 46
Lesson 4 Viewing Forecasts and Production Schedules................................................... 49

4.1
4.2
4.3
4.4
Introduction to Viewing Forecasts and Production Schedules ......................................................... 50

Generating and Viewing a Forecast................................................................................................. 52
Generating a Production Schedule .................................................................................................. 54
Review Questions ............................................................................................................................ 56
Lesson 5 Monitoring and Managing Jobs ........................................................................... 59

5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
Introduction to Monitoring and Managing Jobs ................................................................................ 60

Viewing and Editing Job Details....................................................................................................... 62
Taking Action on Jobs in the Backlog .............................................................................................. 64
Removing Jobs as Predecessors in History..................................................................................... 66
Working with Operator Logs............................................................................................................. 68
Exercise 5A: Performing Operations ............................................................................................ 70
Filtering the Backlog and History ..................................................................................................... 74
Querying for Jobs in History............................................................................................................. 76
Exercise 5B: Finding a Job in the History .................................................................................... 78
Staging Jobs .................................................................................................................................... 80
Exercise 5C: Staging a Chain ...................................................................................................... 82
Review Questions ............................................................................................................................ 84
Lesson 6 Graphical Analysis Package (optional) ............................................................... 87

6.1
6.2
6.3
6.4
6.5
Introduction to the Graphical Analysis Package............................................................................... 88

Monitoring and Managing Jobs with the Gantt View ........................................................................ 90
Reading the Gantt View ................................................................................................................... 92
Setting the Gantt View Preferences ................................................................................................. 94
Viewing a Graphical Forecast .......................................................................................................... 96
iv
Contents
6.6 Viewing an Historical Gantt Chart.................................................................................................... 98

6.7 Monitoring System Performance with the Dashboard ................................................................... 100
6.8 Viewing a Gantt Chart of a Chain .................................................................................................. 102
6.9 History and Custom Reports.......................................................................................................... 104
6.10 Review Questions........................................................................................................................ 106
Lesson 7 Creating Modules.................................................................................................109

7.1 Introduction to Creating Modules................................................................................................... 110
7.2 Defining Modules ........................................................................................................................... 112
7.3 Specifying Output and Login Options for Modules ........................................................................ 114
Exercise 7A: Creating a Module ................................................................................................ 116
7.4 Adding Prompts to Modules........................................................................................................... 118
Exercise 7B: Creating a Module with a Prompt ......................................................................... 120
7.5 Adding a List of Values Prompt ..................................................................................................... 122
Exercise 7C: Add an LOV Prompt to a Module.......................................................................... 124
7.6 Adding Notes ................................................................................................................................. 126
Exercise 7D: Adding Notes to a Module .................................................................................... 128
7.7 Output Scanning ............................................................................................................................ 130
Exercise 7E: Scanning Output ................................................................................................... 132
7.8 Notifications ................................................................................................................................... 134
Exercise 7F: Sending a Notification (optional) ........................................................................... 136
7.9 Review Questions.......................................................................................................................... 138
Lesson 8 Creating Chains ...................................................................................................141

8.1
8.2
8.3
8.4
Introduction to Creating Chains ..................................................................................................... 142

Defining Chains and Selecting Execution Options ........................................................................ 144
Adding Components to a Chain..................................................................................................... 146
Setting Component Options........................................................................................................... 148
Exercise 8A: Creating a Basic Chain ......................................................................................... 150
8.5 Adding Components Using the Add Buttons ................................................................................. 152
Exercise 8B: Creating a Chain with Parallel Components ......................................................... 154
8.6 Creating Component Groups......................................................................................................... 156
Exercise 8C: Creating Component Groups................................................................................ 158
Lesson 9 Adding Dependencies with Predecessors ........................................................163

9.1 Introduction to Predecessors ......................................................................................................... 164
9.2 Predecessor Types........................................................................................................................ 166
9.3 Adding Predecessor Links with the Predecessor Definer .............................................................. 168
Exercise 9A: Adding Predecessors with the Pred Definer Window ........................................... 170
9.4 Adding and Editing External Predecessor Links............................................................................ 172
Exercise 9B: Adding External Predecessors ............................................................................. 174
9.5 Testing Internal Predecessors Links with a Chain Simulation in GAP........................................... 176
Exercise 9C: Creating a Branching Chain ................................................................................. 178
Lesson 10 Scheduling Modules and Chains......................................................................183

10.1 Introduction to Scheduling Modules and Chains ......................................................................... 184
10.2 Scheduling Basics ....................................................................................................................... 186
10.3 Fiscal Calendar Schedules (optional) .......................................................................................... 188
10.4 Setting Chain Component Eligibility............................................................................................. 190
10.5 Special Scheduling Features ....................................................................................................... 192
Exercise 10A: Creating Schedules ............................................................................................ 194
10.6 Review Questions........................................................................................................................ 196
Lesson 11 Defining Substitution Variables........................................................................199

11.1 Introduction to Substitution Variables .......................................................................................... 200
11.2 Defining Substitution Variables.................................................................................................... 202
Exercise 11A: Using Substitution Variables in Prompts............................................................. 204
11.3 Passing Values Through a Chain with Prompts........................................................................... 206

Exercise 11B: Passing Values through a Chain......................................................................... 208
11.4 Review Questions ........................................................................................................................ 210
Lesson 12 Working with Conditions .................................................................................. 213

12.1 Introduction to Conditions ............................................................................................................ 214
12.2 How AppWorx Processes Conditions .......................................................................................... 216
12.3 Adding, Editing, and Deleting Conditions..................................................................................... 218
12.4 Condition Types ........................................................................................................................... 220
12.5 Condition Actions ......................................................................................................................... 222
12.6 Condition Action Timings ............................................................................................................. 224
Exercise 12A: Checking the Time Since a Request................................................................... 226
Exercise 12B: Killing a Component that is Taking too Long to Execute .................................... 228
Exercise 12C: Checking the Number of Records in a Database Table ..................................... 230
Exercise 12D: Creating a Menu Using Prompts......................................................................... 232
Exercise 12E: Checking for a File .............................................................................................. 234
Exercise 12F: Spanning Midnight .............................................................................................. 236
12.7 Review Questions ........................................................................................................................ 238
AppWorx 7.0 Basic Training Evaluation Form ................................................................... 241
vi
Contents
Lesson 1
Introduction
1.1 Course Overview ....................................................................................................................... 2
1.2 Introduction to AppWorx ............................................................................................................ 4
1.3 AppWorx Is Object-Oriented ...................................................................................................... 6
1.4 AppWorx Architecture ................................................................................................................ 8
1.5 Using the AppWorx Desktop ................................................................................................... 10
1.6 Using Explorer ......................................................................................................................... 12
1.7 Adding, Editing, and Deleting AppWorx Objects ..................................................................... 14
1.8 Running Reports ...................................................................................................................... 16
1.9 Editing User Settings ............................................................................................................... 18
Exercise 1A: Modifying Your User Settings ............................................................................... 20
1.10 Review Questions .................................................................................................................. 22
Lesson 1: Introduction
Slides
1.1 Course Overview

The course covers the basic functions of AppWorx. It is organized to teach the
skills required by end users, operators, programmer/analysts, and system
administrators.
The AppWorx training course teaches you the basic skills required to use
AppWorx. It covers topics useful to:
End users
Operators
Programmer/analysts
System administrators
The course begins with operations, and ends with development.
Course Objectives
At the end of the course, you will be able to:
Run jobs
Manage and monitor jobs as they are processed through AppWorx
View output online
Create modules to run programs
Add prompts to modules to accommodate parameters in programs
Create chains using predecessors
Schedule modules and chains
Pass prompt values through a chain
Define substitution variables to query a database and use the values in
prompts and condition statements
Use condition statements to control the execution of modules and chains
Online Manuals
Complete online versions of the AppWorx manuals are accessible by selecting
the Help button in AppWorx. If you select Help while defining an object,
AppWorx opens the corresponding help topic.
You can register for a user name and password to download PDF manuals at:
http://support.appworx.com.
Knowledge Base
The knowledge base provides write-ups to address problems and frequently
asked questions. It is searchable by error message, category, and text. The
knowledge base is located on the AppWorx Support Site.
http://support.appworx.com
AppWorx User Forum

The AppWorx User Forum is a place where you can network with other
AppWorx users to trade tricks, tips and best practices. Check on the latest
product developments, find out about new service offerings and make new
friends and connections.
To register, visit http://forum.appworx.com and fill out a short registration form.
The forum content is available only to current AppWorx customers.
Notes
Slides
1.2 Introduction to AppWorx

AppWorx is an application management tool that lets you submit jobs on an ad
hoc basis, create sophisticated batch schedules, and view and print output from
jobs online.
What is AppWorx?
AppWorx is a powerful application job scheduling tool that meets the needs of
operators, programmers, and system administrators throughout the life cycle
of an application. AppWorx lets operators submit jobs on an ad hoc basis, view
the output online, and print the output to a system printer or a local Windows
printer. But it also lets programmers set up sophisticated job scheduling
without writing scripts. Instead, users can create logical conditional
statements with a few mouse clicks. System administrators will find AppWorx
roles and security powerful tools for managing access to AppWorx.
Why Use AppWorx?

There are a number of benefits to automating your complex business
processes with AppWorx, including the following:
Creating sophisticated job streams without writing complex scripts.
SSccrip
riptsts
Pinpointing problems in a job stream, and restarting a job stream at any

point of failure.
Balancing system load using AppWorx schedules, queues, and agent

groups.
Running AppWorx on UNIX and Windows platforms
U N IX
W in d o w s
Controlling job stream execution based on the state of your corporate

database with dynamic substitution variables
Slides
1.3 AppWorx Is Object-Oriented

You use a variety of objects to accomplish your work in AppWorx. Once defined,
AppWorx objects can be combined in an infinite number of combinations to
accomplish operational tasks.
In a traditional operations environment, systems personnel created shell
scripts to control batch processing of background tasks. If system
administrators were somewhat sophisticated, they could create structured
scripts that reused some standard information. Structured scripts however,
could only be taken so far, and required significant time to maintain.
Chains
Modules
Agents
Applications
Libraries
Program
types
Queues
Logins
Printers
Figure A. Objects are combined to define modules and chains.

AppWorx takes the structured approach to its logical conclusion:
object-oriented operations. Each element in the system is defined as an object.
Once defined, AppWorx objects can be combined in an infinite number of
combinations to accomplish operational tasks.
Objects are combined to define modules. Modules are combined with other
objects (such as queues, as shown in Figure A) to create chains that run batch
processes. All of this is accomplished without writing scripts.
Modules (Jobs)
For AppWorx to run a program or execute a script, you must create a module.
A module includes the information required for AppWorx to run a program or
script on the server. You create a module and specify the program location,
input, and output parameters. The information includes such items as the
program directory, name, and parameters. Modules are run both individually
and as components of AppWorx chains. Furthermore, a module can be a
component of as many chains as you wish. If you change a module definition,
the change is applied to every chain that includes it.
Chains (Job Streams)

Modules are combined to create chains. Chains are equivalent to job streams.
They run any number of programs and serve the same purpose as a
traditional script. Instead of running a script, you run an AppWorx chain.
Chains include scheduling and exception handling information. You assign
modules (and other chains) to a chain and can create a schedule for the chain.
When modules and chains are added to a chain, they are referred to as chain
components.
Queues
You control the flow of jobs to servers by using AppWorx queues. All jobs pass
through an AppWorx queue to get to a server. You control queue throughput
by setting the number of concurrent jobs or threads that can be processed. You
can define an unlimited number of queues.
Roles
In a traditional system, you create groups of users, printers, and applications.
In AppWorx, roles replace groups. Roles control access to all areas of
AppWorx. You can define roles for users, printers, and applications, as well as
any other set of objects. Roles can contain any combination of objects, and
objects can be assigned to any number of roles.
Notes
Slides
1.4 AppWorx Architecture

Masters reside on a server and are the execution brain of AppWorx. Agents
receive commands via the master and run programs or execute scripts. Clients
provides the graphical user interface for AppWorx. Object definitions are stored in
the AppWorx relational database.
The AppWorx architecture is illustrated in Figure A.
AppWorx Master
And Local Agent
Java
Client
UNIX Remote
Agent
TCP/IP
TCP/IP
Java
Client
TCP/IP
Windows Remote
Agent
AppWorx
Database
Figure A. AppWorx architecture
Master
The master resides on a server and is the execution logic or brain of AppWorx.
It monitors the schedule and, at the appropriate time, sends jobs to the
designated agent for execution. The master connects to the AppWorx database
where all object definitions are stored.
Agent
The local agent runs programs or executes scripts on the master. It receives
commands via the master.
A remote agent resides on another server. An agent must be installed on each
machine where jobs are executed.
The master will schedule and control job execution on all the agents assigned
to it. The agent monitors jobs until they complete.
Client
The AppWorx Java-based client can run on any Java compliant device such as
a PC, Apple Macintosh, or Sun workstation. The client provides access to all
AppWorx functions and features. The clients communicate with the AppWorx
master.
Object Storage
AppWorx uses object definitions stored in a database to give it an advantage
over all other schedulers. Module and chain definitions, along with all other
object definitions, are stored in the AppWorx relational database. This makes
it easy to update an object's definition, and have AppWorx apply the updates
everywhere you use the object.
Notes
10
Slides
1.5 Using the AppWorx Desktop

You access AppWorx features from the AppWorx desktop.
From the AppWorx desktop you can access all AppWorx operations,
administration windows, and options.
Toolbar
Taskbar
Figure A. The AppWorx desktop.

From the desktop you can:
Define AppWorx objects such as modules and chains
Run jobs
Monitor operations
View output
ToolTips
ToolTips provide a brief description of AppWorx buttons, icons, and fields. To
see a ToolTip, rest the mouse pointer over the button, icon, or field. A ToolTip
appears after the mouse pointer has remained motionless for a second or two.
In Figure A, the mouse pointer is resting on the Library icon in the toolbar.
Toolbar
The toolbar consists of a row of icons on the top of the screen. When these
icons are clicked, AppWorx opens a corresponding window. You can view or
hide the toolbar by opening the View menu and checking the toolbar option.
You can add to or edit the icons displayed on the toolbar with the Options
menu by selecting Settings.
Taskbar
The taskbar is a graphic bar on the desktop used to select active AppWorx
windows.
From the taskbar, you can right-click to:
Restore a window to the desktop or minimize it to the taskbar.
Maximize a window to fill the desktop.
Move a window to the front of the desktop.
Close a window.
Selector windows are special windows used when defining AppWorx objects.
They are not displayed on the taskbar because they do not contain unique
information and are represented by icons on the toolbar.
Closing All Windows or Selector Windows

To close all windows, go to the View menu and select Close all. To only close
the selector windows, select Close selectors.
Status Bar
The status bar is displayed across the bottom of the Explorer window. Its color
alerts you to the status of the AppWorx master, agents, and jobs running in
the Backlog. When the Explorer window is minimized it uses the same color
scheme on the taskbar.
Customizing Tables in AppWorx Windows

Many of the AppWorx windows display information in tables. You can
customize these tables by selecting the columns displayed and the order in
which they are displayed. To edit the tables, open the Options menu and
select Tables.
Customizing Job Status Colors

In the Backlog and History on the Explorer window, AppWorx displays job
status in the Status column. To provide visual cues, AppWorx uses colors for
the statuses. For example, green is RUNNING, yellow is HOLD, and red is
ABORTED. If you wish, you can change the colors used for groups of statuses.
To change the colors, open the Options menu and select Status colors.
Notes
11
12
Slides
1.6 Using Explorer

If you have the Explorer add-on product, you can select an icon from the tree to
limit the jobs listed in the Backlog.
Using Explorer, you can select an icon to limit the jobs listed in the Backlog.
An example Explorer screen is shown in Figure A.
Figure A. Object keys can be opened on the Explorer window to focus on

jobs in the Backlog.
The icon you select in the object tree determines the jobs listed in the Backlog.
To list:
Select this icon:
All jobs in the Backlog.

Jobs that have been submitted using the Requests
window.
Jobs that are set to run on a particular agent, or agent
group.
Jobs that are set to run on a particular queue.
Jobs that are part of a particular chain.
Jobs with a particular job status (WAITING, RUNNING,
ABORTED, or HOLD).
Backlog
Ad Hoc
Agents
Queues
Chains
Status
Note: You can also filter the display of agents and/or queues by going to the
Filter menu and selecting Filter Backlog and History.
Notes
13
14
Slides
1.7 Adding, Editing, and Deleting AppWorx Objects

Add, edit, and delete objects using the selector windows. Modules and Chains
selector windows include an Application box and a Copy function.
You add, edit, and delete objects using the selector windows. The Modules
selector window is shown in Figure A.
Figure A. Selector window

To open a selector window, do one of the following:
Select an icon from the toolbar on the desktop (see Figure B).
Select an item from the Objects Admin menu on the desktop.
Select the icon next to an objects field when defining another object.
Note: AppWorx roles control access to the selector windows. If you do not have
access to one, see your AppWorx administrator.
Figure B. You can open selector windows with the

toolbar icons.
Searching for Objects

You can type the first few letters of an objects name in the Search field, and
AppWorx will find it. The Search field accepts valid UNIX regular expressions.
For example, to search for all modules starting with the letters A and T, you would
enter ^a|^t in the Search field.
Filtering Modules and Chains by Application

The Modules and Chains selector windows include an Application box.
Applications specify a group of modules and chains. The application you select
determines which modules and chains are listed in the table.
Adding, Editing, and Deleting Objects

To add, edit, or delete an AppWorx object, open the appropriate selector
window and do one of the following:
To:
Do this:
Add an object
Edit an object
Delete an object
Click New.
Select the object and click Edit.
Select the object and click Delete.
If an object you are deleting is referenced (used) by one or more objects, you
must remove the references before it can be deleted. If you try to delete an
object without first removing the references, AppWorx will display a message
saying it is in use. To find out where the object is being used, click the Usage
button in the Selector window.
If modules or chains are in the Backlog, you cannot delete their definitions.
You will need to wait until they complete executing.
Viewing Object References

If you wish to delete an object, you must remove its references first. You can
view all the references of an object by selecting an object and clicking the
Usage button (see Figure C).
Figure C. To view all references for an object, click Usage

on any object selector window.
Copying Objects
To copy an AppWorx object, choose Copy on the objects selector window (see
Figure D). AppWorx a window for the new object. When copying modules and
chains, you can decide whether to copy the conditions, notes, and schedules.
Figure D. To copy any AppWorx object, select the object

and click copy.
Notes
15
16
Slides
1.8 Running Reports

To view reports for an object type, open that objects selector window and click
Reports.
AppWorx comes with an extensive set of predefined reports that you can use
to review how jobs were processed through AppWorx over a given period of
time. A report that audits schedule changes is shown in Figure A. Additional
reports may be created to by AppWorx users if they have the necessary role
access.
Figure A. A sample report.
Viewing Reports
You can view reports for each of the operations windows and selector
windows.
To view reports for:
An object type
Do this:
An operations window
Open the operations window and choose

the report type from the Reports menu.
Open that objects selector window and

click Reports.
This opens the Reports window and selects the report type (role type)
corresponding to the window you opened it from. In Figure B, the Reports
button is selected on the Modules selector window, opening the Reports
window and with the Modules role type highlighted.
You can type the first few letters of a reports name in the Search field, and
AppWorx will find it. The Search field accepts valid UNIX regular
expressions.
To view reports for another object type, select that object type from the Role
Type box. If an object is not listed in the Role Type box, there are no reports
for it.
Notes
Figure B. Select a report on the Reports window.

Once you select a report, click the Show button.
Prompt Values.
Some reports require you to enter prompt
values. If the report you select requires
prompt values, you must respond to them in
the Report Parameters window shown in
Figure C. Once prompts are provided (if
necessary), AppWorx displays the report in Figure C. Enter prompt values
its own window as shown in Figure A
Changing the Lines per Page

You can specify the number of lines displayed on each page using the Lines
per Page field. The new setting will go into affect when you click the
Redisplay button. Doing so will update the time and date in the report header.
It will not recompile the SQL.
How Job History Report Data is Generated

Data relating to job history used in reports is generated and loaded into
AppWorx by running the AW_CALC_HISTORY_STATISTICS module. If a job
history report data does not seem current, it could be because this module has
not recently run.
17
18
Slides
1.9 Editing User Settings

To set the AppWorx user settings, select Settings from the Options menu.
To set the AppWorx user settings, select Settings from the Options menu.
You can apply these settings to the current session, or save them for future
sessions.
Figure A. The General tab of the Settings window.
Figure B. The Toolbar tab of the Settings window.
Figure C. The Alerts tab of the Settings window.
Notes
19
20
Slides
Exercise 1A: Modifying Your User Settings

For this exercise you will select several user options and toolbar settings.
Use the Settings window to modify your user settings. Use the Help button on
the Settings window to bring up a context-sensitive help topic.
Setting User Options

Modify your user settings to do the following:
Have AppWorx display jobs in History for 60 minutes.
Customize your toolbar by selecting icons. Include only the following
icons in your toolbar:
Explorer
Requests
Modules
Chains
As you go through the training class you may wish to add or remove icons on
your toolbar.
Notes
21
22
Notes
1.10 Review Questions

These review questions highlight the key points covered in the lesson.
1.
Where are the definitions for AppWorx objects such as queues, agents,
printers, and database logins stored?
______________________________________________________
2.
Which actually executes the program or script: the AppWorx master or

agent?
______________________________________________________
3.
List one advantage of the object-oriented approach used in AppWorx.

______________________________________________________
4.
How can you limit how long records are displayed in the History?
______________________________________________________
______________________________________________________
5.
What is the minimum number of seconds you can set AppWorx to

refresh the Explorer window with the Continuous Monitoring user
setting?
______________________________________________________
Notes
23
24
Lesson 2
Requesting Jobs
2.1 Introduction to Requesting Jobs ..............................................................................................
2.2 Requesting and Submitting Modules and Chains ....................................................................
2.3 Viewing Output with the File Viewer ........................................................................................
Exercise 2A: Running a Module from the Requests Window ..............................................
2.4 Review Questions ....................................................................................................................
26
28
30
32
34
26
Lesson 2: Requesting Jobs
Slides
2.1 Introduction to Requesting Jobs

You can submit modules and/or chains on an ad hoc basis. After submitting one
or more modules/chains, you can view their status from the Explorer window.
There may be times when you want to run jobs outside of a set schedule. You
can submit modules and chains on an ad hoc basis with the Requests window.
Figure A. Select one or more modules or chains and click Request,

or simply double-click a single module or chain to request.
Requesting and Submitting Modules and Chains

The ability to request modules and chain on an ad hoc basis offers a useful
method for developers to test individual modules and chains, and end users to
request reports that have not been scheduled ahead of time.
When requesting modules and chains, you use the following two windows:
The Requests window shown in Figure A is used to select one or more
modules/chains.
The Submit window shown in Figure B is used to complete prompts,
select options, and submit the requested modules/chains to the Backlog.
When you request jobs, you can set the start date and time, queue, designated
printer, printer option, number of copies, and, print function (LOG, PRINT, or
STORE). You can add a suffix to the job name, and enter values to customize
reports when prompts are defined for the module or chain.
Notes
Figure B. The Submit window
Viewing Output
After a module executes, you can view and print output online using the
AppWorx File Viewer shown in Figure C. The File Viewer is accessible from
both the Explorer and Output windows.
Figure C. The AppWorx File Viewer
27
28
Slides
2.2 Requesting and Submitting Modules and Chains

To request modules or chains, open the Requests window, select one or more
modules and/or chains, and click Request, or simply double-click a single module
or chain. The selected modules and chains are displayed in the Submit window
where you can set options and parameters.
To request modules or chains, open the Requests window (see Figure A), select
one or more modules and/or chains, and click Request, or simply double-click
a single module or chain. The selected modules and chains are displayed in
the Submit window where you can set options and parameters and click
Submit to submit them.
Figure A. The Requests and Submit windows
Limiting the Display with the Application and Search Options

Applications specify a group of modules and chains. In the Requests window,
the application you select from the Application list determines which
modules and chains are listed in the table. Only the applications and modules
assigned to you via roles will be displayed.
When selecting modules and chains, you can type the first few letters of a
module/chains name in the Search field, and AppWorx will find it. The
Search field accepts valid UNIX regular expressions.
To select more than one object, use the Shift+click and Ctrl+click
combinations.
Responding to Prompts
If prompts were defined for the module or chain, they are displayed in the
Prompts box in the Submit window.
There are several ways to respond to a prompt:
Accept the default value if one is displayed. 200.1.1.58 is the default
value for the first prompt in Figure A. If you change the default value,
you can select the Default button to bring it back.
Enter a value in the default column.
Click the LOV or MS button (if enabled) to pick a value from a list.
The LOV button lets you select a single value.
The MS button lets you select multiple values. The LOV and MS buttons
will be enabled only if a list of values or multiple select prompt has been
defined for the module.
Output Function
The output function determines how output is handled. This field will be
editable only if a printer has been assigned to the module or chain.
There are three choices:
LOG: The application output or report files will be listed by default in
the Output window. AppWorx loads all application output or report files
for viewing in the Output window for jobs with a LOG output function
every time you log into the client. This can take several seconds or
minutes. If more than 500 files are loaded, an alert will be displayed.
Therefore, if you are not using the Output window (that is, you view
output from the History instead of the Output window), you should use
the STORE setting.
PRINT: The output is printed according to the print settings specified
on this tab.
STORE: This is the default setting. The output is not printed and is not
listed in the Output window.
If PRINT or STORE are selected, you can view all output files from the
Output window by running an output query.
With any of these settings, the application output and the system output files
can be viewed from the Explorer window.
After Submitting a Module or Chain

After submitting a module or chain,
you can follow AppWorx as it
processes the job by watching the
Figure B. The job Id is displayed on the
status messages displayed in the
bottom left corner of the window.
lower left corner of the Submit
window. AppWorx also displays the JOBID assigned to the job. In Figure B
the status and JOBID (Job was Successfully submitted: JOBID = 26042) are
displayed.
To remove a tab from the Submit window, click Close. Clicking the X button
on the title bar closes the window.
Notes
29
30
Slides
2.3 Viewing Output with the File Viewer

Using the File Viewer, you can view output and print it to a local or system printer.
After you submit a job and it executes, you can view the output as plain text,
HTML, or rich text format output using the File Viewer shown in Figure A.
You can also use an alternate viewer, using AppWorx file associations.
Figure A. You can view reports using the AppWorx File Viewer or another
designated viewer.
Opening the File Viewer Window

You can access the File Viewer from the:
Explorer window
Output window
The Explorer window is used to monitor and manage AppWorx jobs, as well as
agents and queues. To open the File Viewer from the Explorer window, rightclick a job in the History or Backlog and select Output from the pop-up menu.
The Output window provides access to job output to users that do not have
access to the Explorer window. To open the File Viewer from the Output
window, select a job and click the View button.
System and Output Files

AppWorx lists the system and output files for the job on the Output tab of the
job details window. Standard output and error file names begin with an o.
Body output files begin with a b.
Viewing Output Files

After a job has completed, you can view the output in the File Viewer as
shown in Figure A.
Printing an Output File

After viewing a report, you can preview your print job and print it to a local
Windows printer or to a system printer. These options are available on the
File Viewers File menu.
FTPing an Output File

You can send an output file to your client machine or a network location using
the FTP function. You cannot FTP files if the Deny FTP Option option was
assigned to you by your AppWorx administrator.
Emailing an Output File

You can email output files without having to define an email output device. To
email output files to one or more addressees, go to the Print menu and select
Email, or click the Email icon. AppWorx opens an Email window shown in
Figure B.
Figure B. Email window

Separate multiple email addresses with a space or semicolon. To select from
emails assigned to AppWorx users, click the Select button. AppWorx opens a
window where you can select the email addresses. You can decide whether to
add the output file as an attachment and include additional text using the box
at the bottom of the screen.
In order to send emails, you must specify email settings for the AppWorx master/local
agent.
Querying for Jobs

You can query the History in Explorer, and you can query the Output window
specific jobs using search criteria such as module name, chain, agent,
requestor, etc.
File Associations
You can also associate types of files with other viewers. For example, if you
are generating an .xls file, you can have AppWorx automatically launch
Microsofts Excel as the viewer. To do this you must have the type association
selected in the File Association window (see Figure C).
Figure C. File Association window
Notes
31
32
Slides
Exercise 2A: Running a Module from the Requests

Window
In this exercise, you submit a module from the Requests window and view the
output using the AppWorx File Viewer.
AppWorx users can submit jobs on an ad hoc basis using the Requests
window. In this exercise, you take on the role of an end user submitting a
module with the Requests window and viewing the output with Explorer. The
module runs a program that creates a list of employees from a department you
select. The data is pulled from the DEPT table in the AppWorx database.
Figure A. You can submit modules and chains on an ad hoc

basis with the Requests window.
What to Do
To request the EMPLOYEE_REPORT module and view its output:
1.
Select Requests from the Operations menu to open the Requests window
and request the EMPLOYEE_REPORT module as shown in Figure A.
2.
Click on the LOV button.

AppWorx displays the List of Values dialog box shown in Figure B.
3.
Select a department and double-click it.
4.
Add your two-digit nn suffix (e.g.: 01, 02, etc.) to the module name.
5.
Submit the module by clicking the Submit button.
6.
Open the Explorer window and wait for the job to complete and move to
History.
7.
Right-click the EMPLOYEE_REPORTnn module in History.
Notes
Figure B. The List of Values dialog box.

8.
Select Output from the pop-up menu and double-click the b file.
9.
Please answer the following questions:

How many output files are there? _________
List the name of the output file that contains the department report
generated by the module executing the program.
_____________________________
List the name of the output file that contains the value of the prompt,
login information, and any error messages that may have been
generated. _____________________________
33
34
Notes

1.
What is the difference between the print functions LOG, PRINT, and
STORE?
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
2.
How can you limit the modules displayed on the Requests window?
______________________________________________________
______________________________________________________
3.
What part of an AppWorx module do you use to pass values to your

program or shell scripts?
______________________________________________________
4.
What are LOV and MS prompts?

______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
5.
Can you change the date and time a module runs from the Submit
window? For example: run five minutes from now?
(Yes/No) ________________
6.
What's the difference between the o and b output files?

______________________________________________________
______________________________________________________
______________________________________________________
Notes
35
36
Lesson 3
Monitoring and Managing Agents and Queues
3.1 Introduction to Monitoring and Managing Agents and Queues ...............................................
3.2 Managing Agents .....................................................................................................................
3.3 Managing Queues ...................................................................................................................
Exercise 3A: Creating a Queue and Running a Job Through It ...........................................
3.4 Review Questions ....................................................................................................................
38
40
42
44
46
38
Lesson 3: Monitoring and Managing Agents and Queues
Slides
3.1 Introduction to Monitoring and Managing Agents

and Queues
You can monitor and manage agents and queues with the Explorer window.
In AppWorx, each instance of AppWorx is referred to as an agent. The agents
can be on the same machine, or on different machines. Each master has one
local agent and can control numerous remote agents. Two remote agents
(PROD2 and SAP1) have been defined in Figure A.
Figure A. The Agent Summary

AppWorx queues control the flow of jobs. All jobs must pass through a queue
to get to be executed. You control queue throughput by assigning a queue to a
thread schedule.
From Explorer, you can check the status of queues, change queue settings,
and assign queues to schedules to control the number of threads assigned to a
queue.
Viewing Agent and Queue Summaries

To view a summary of agents or queues, select the appropriate entry in the
Explorer tree. An Agent Summary is shown in Figure A. A Queue Summary is
shown in Figure B.
Notes
Figure B. The Queue Summary
39
40
Slides
3.2 Managing Agents

You can start, stop, idle, resume, and reset agents. You can also edit the threads
assigned to an agent.
You manage the master and its agents in several ways. From the Explorer
window you can:
Take an action on a single agent or master by right-clicking an agents
icon in the object tree or by right-clicking a listing in the Agent
Summary.
Take an action on one or more agents or the master by highlighting
them in the Agent Summary and right-clicking.
Take an action on all agents and the master by right-clicking the Agents
icon in the object tree.
Change an agent or masters thread schedule by right-clicking the agent
or master.
Figure A. Right-click to work with an agent.

Note: To manage agents, you must have the Manage all Agents user option
assigned to you by your AppWorx administrator.
Idling and Resuming Agents or the Master

If you want to stop processing newly submitted jobs through an agent you can
idle it. The agent will go to an Idled status and the icon for the agent will be
displayed with a yellow triangle over it in the Explorer tree. Jobs in the
Backlog set to run on an agent in an Idled status will have a job status of
AGENT WAIT. To take the agent out of the idle status, you resume it.
Starting Agents or the Master

Starting an agent will start processes on that agent if they are stopped and
change the agents status to Running. The agent may change to an interim
Starting status before it moves to Running. Starting an agent is equivalent to
issuing the startso <agent name> command. It may take some time to update the
status when starting agents or the master.
Stopping Agents or the Master

You should generally idle agents rather than stop them if you want to stop
processing jobs on a particular machine. Stopping an agent will put it into a
Stopped status, but it will not stop any processes. If an OAE, PEOPLESOFT,
or SAP agent is stopped, AppWorx wont poll the application for job status
updates. Stopping an agent is equivalent to issuing the stopso <agent name>
command. It may take some time to update the status when stopping agents
or the master. When stopped, agents show a Stopped status and the icon for
the agent in the Explorer tree is gray. Jobs in the Backlog set to run on an
agent in a Stopped status will have a job status of AGENT WAIT.
Showing BUSY or TROUBLE Agents as Stopped by Resetting

There are times when the machine where an agent is installed is taken down
for maintenance. When this happens, the agent will go into a BUSY or
TROUBLE status in the AppWorx client. If you know why the agent is in one
of these statuses, and there is no need for action, you may not want the agents
status to affect the color of the status bar. You can right-click them and choose
Reset from the pop-up menu. Resetting an agent only changes its viewable
status to Stopped. The reset agent will have no effect on the status bar.
Changing Thread Schedules for the Master and its Agents

Master and agent thread schedules set the maximum number of concurrent
jobs that can run through any combination of queues. To change a master or
agents thread schedule, right-click the agent icon and select Threads from the
pop-up menu. AppWorx displays the Threads window shown in Figure B
where you select a thread schedule. Thread schedules are assigned to masters,
agents, and queues. You can also specify a local or remote agents thread
schedule in its definition.
Figure B. To change an agents thread

schedule, right-click on the agent.
Viewing Agent Logs

To view the process logs for a master or agent, right-click on the agent and
select View Log from the pop-up menu. The log will be displayed in the File
Viewer. The process log files are stored in the AppWorx log directory.
Rolling Over AgentService.log and RmiServer.log Files

You can switch to current file to a new log file for AgentService.log files for agents
or the RmiServer.log file for the master. To rollover one of these logs, right-click on
an agent or master and select Agent Log Rollover. You might want to rollover a
log file when debug is turned on and you want to isolate what is written in a log.
You may also need to rollover the AgentService.log file to view current information
for a VMS agent. You cannot read from the current AgentService.log file for a VMS
agent without doing this because it is constantly being written to and VMS does
not allow you to read and write to the log at the same time.
Notes
41
42
Slides
3.3 Managing Queues

You can control the flow of jobs submitted to your system by assigning different
thread schedules and priorities to your queues. You can also inactivate one or
more queues.
Controlling the load on your system is critical. In AppWorx, you control the
workload by setting the number of concurrent jobs that can pass through a
queue.
Figure A. You can monitor and manage queues from Explorer.

All jobs submitted to your system from AppWorx must pass through an
AppWorx queue. You can control the number of jobs that flow through a queue
in several ways:
Select a thread schedule for the queue based on its Min thread and Max
thread values.
Minimum threads ensure that you always have a specified number of
standby threads available for priority rush jobs. Maximum threads
control the maximum number of jobs that can run concurrently in the
queue.
Set a priority for each queue.
Use the single and multiple thread settings for modules and chains.
Changing Queue Settings

To change a queues settings select the queue, right-click, and select Change
from the pop-up menu (see Figure A). You can also activate/inactivate one or
more queues in the Queue Summary by highlighting the queues,
right-clicking, and selecting the appropriate option.
Defining Queues
To define a queue, you must name the queue, assign it to a thread schedule,
set its priority, and make the queue active or inactive (see Figure B).
Figure B. The Queues window
Defining Thread Schedules

A thread schedule defines the number of concurrent jobs that can run through
a queue during a specified period of time. You can select multiple stop times
for a thread schedule to control the minimum reserved and maximum thread
limits allowed throughout the day (see Figure C).
Figure C. The Thread Schedules window
Notes
43
44
Slides
Exercise 3A: Creating a Queue and Running a Job

Through It
In this exercise, you create a queue and submit a module through it using the
Requests window.
When all jobs run through the same queue, it can be difficult to locate your
jobs. In this exercise, you will create your own queue. You can then assign this
queue to the modules you create in later exercises. This should make it easy
for you to track your jobs.
Creating a Queue
To create a queue and assign a predefined schedule to it:
1.
From the Queues selector window, click New.

AppWorx opens the Queues window shown in Figure A.
Figure A. Fill in the fields to add the

queue.
2.
Complete the fields using the information in the table below.

Field
Description
Name
The name may be up to 10 characters long.

Name your queue QUEUEnn.
A schedule has to be defined in the Thread Schedules
window. The schedule controls the maximum number of
concurrent jobs that can run through the queue at any
given time.
AppWorx comes with a number of predefined schedules, 2
all Day, 3 all Day, , 9 all Day. You should select a
schedule that allows at least three jobs to run
concurrently.
Defines the order in which queues are scanned for job
initiation. Queues are scanned starting with the number 1.
You can leave your queue at the default setting of 50.
Schedule
Priority
Active
3.
Activates the queue. Active queues apply the thread settings.

When you inactivate a queue, no jobs will be processed
through it. The jobs will remain in the Backlog with a NULL
status until the queue is activated.
To accept the settings, click OK.
The active queue will now accept module requests.
Submitting a Module Through Your Queue

To submit modules through your queue:
1.
Request the TEST_MODULE module on the Requests window.
2.
From the Submit window, change the prompt value to 30 so the module
will run for 30 seconds and you will be able to see it running in the
Backlog.
3.
Select the queue you just created from the Queue drop-down list as
shown in Figure B.
Figure B. Set the sleep prompt value to 30, and the Queue to
4.
Submit the module.
5.
Open the Explorer window.
6.
Select QUEUEnn from the queues in the object tree.

You will see the TEST_MODULE module running in the QUEUEnn
Backlog as shown in Figure C.
Figure C. The TEST_MODULE module runs on QUEUEnn.
Notes
45
46
Notes

1.
What object controls the number of concurrent jobs that can run
through a queue at a particular time? ___________________________.
2.
If the maximum number of threads for an agent has been reached, will
jobs waiting to run through a queue with a priority of 40 run before or
after jobs waiting in a queue with a priority of 60?
_____________________
3.
How do you view agent logs from the AppWorx client?

______________________________________________________
4.
If you do not want to stop an agent, but you want to stop processing jobs
through the agent, what option can you pick? _____________________
5.
An agent is showing a BUSY or TROUBLE status. How can you change

its viewable status to STOPPED?
______________________________________________________
______________________________________________________
Notes
47
48
Lesson 4
Viewing Forecasts and Production Schedules
4.1
4.2
4.3
4.4
Introduction to Viewing Forecasts and Production Schedules ................................................

Generating and Viewing a Forecast ........................................................................................
Generating a Production Schedule ..........................................................................................
Review Questions ....................................................................................................................
50
52
54
56
50
Lesson 4: Viewing Forecasts and Production Schedules
Slides
4.1 Introduction to Viewing Forecasts and Production

Schedules
The Forecast displays a high-level list of scheduled modules and chains. The
Production Schedule gives a detailed listing of scheduled modules and chains.
Forecast
Using the Forecast feature, you can view a list of scheduled modules and
chains. An example forecast is shown in Figure A.
Figure A. The Forecast window.

The data displayed in forecasts is generated and loaded into AppWorx by
running the FORECAST module. When you create a schedule for the
FORECAST module, you determine the time frame of the forecast and how
often it is run.
Production Schedule
You can get a more detailed look at jobs that are scheduled to run by
generating a production schedule. An example production schedule is shown
in Figure B.
Skip {Chain}Report Name
---- ---------------------------------------------------Saturday Feb 23 2004 00:00
{SYSTEM}Saturday Feb 23 2004 00:00
{SYSTEM}DELDEFAULT
NDOW {SYSTEM}HISTORY_PURGE
Monday Feb 25 2004 00:00
{SALES_REPORTS}Monday FEB 25 2004 00:30
{SALES_REPORTS}REGION_A
B If CURRENT TIME > 06:00:00 then SKIP TASK
{SALES_REPORTS}REGION_B
B If CHECK FILE NO /reports/region_b.dat
{SALES_REPORTS}REGION_C
Graphical Forecast (optional)

If you have the Graphical Management Package option installed, you can view
the forecast in a Gantt view as shown in Figure B. The advantage of the Gantt
view is that it displays the jobs against a time line.
Figure B. Optional Graphical Forecast window

The Graphical Management Package is covered in the next lesson.
Notes
51
52
Slides
4.2 Generating and Viewing a Forecast

To generate a forecast, you run the FORECAST module. To view a forecast after
its been generated, open the Operations menu and select Forecast.
The forecast shows all modules and chains scheduled to run in the future that
are not currently in the Backlog. This includes staged jobs.
The data displayed in a forecast (see Figure A) is generated and loaded into
AppWorx by running the FORECAST module. When you create a schedule for
the FORECAST module, you determine the time frame of the forecast and
how often it is run.
Figure A. The Forecast window
Generating a Forecast
To generate a forecast, you run the FORECAST module shown in Figure B.
Figure B. To generate a forecast, you run the FORECAST module.

You can run the module from the REQUEST window, or schedule it to run at
set times during the day.
The FORECAST module includes the following prompts.

Prompt
Description
Start Date Time
The start date and time for the forecast. The default
value for the prompt is a series of numbers created
using the #aw_now substitution variable. They
represent the current date and time. In Figure B the
default value is 20020219090643, this translates to:
Year: 2002
Month: February (02)
Day of month: 19th
Time: 9:06:43 A.M.
End Date Time

(default is 1 day
past start date)
The end date and time for the forecast.
Max Depth
The levels of nested chains you wish to show in the

forecast.
Minimum Schedule
Units
Select whether you want to limit the forecast to list only

one job per day, hour, or minute.
Viewing a Forecast
To open the Forecast window shown in Figure A, do one of the following:
Open the Operations menu and select Forecast.
Select the Forecast icon from the toolbar.
AppWorx displays the printable list of modules and chains that are scheduled
to run through the end of the next day (see Figure A). Each scheduled module/
chain includes the start date and time and the module or chains name.
Chains also include a key icon used to expand/collapse them.
To view the modules within a chain, click the chains key. To expand all keys
for a chain and its children, select the chain, go to the View menu and select
Expand Chains. To expand the keys in all chains, choose Expand All.
Data displayed in forecasts is generated and loaded into AppWorx by running
the FORECAST module. When you create a schedule for the FORECAST
module, you determine the time frame of the forecast and how often it is run.
For more information on running the FORECAST module, see topic 7.4
Setting the FORECAST Module Start Time(s).
Notes
53
54
Slides
4.3 Generating a Production Schedule

To generate a production schedule report, run the PRODSCH chain and view
output for the SCHPRINT job.
If you want to see a schedule of all modules and chains that are scheduled to
run between specified dates, you can run the PRODSCH chain. The chain
runs two modules SCHCREATE and SCHPRINT.
Figure A. The PRODSCH chain in the Submit window.

The output for the SCHPRINT module reports the jobs by date and time. It
includes the following information:
The date and time each chain is scheduled to run.
The name of each module in each chain.
The conditions associated with each module.
The report can show only the jobs that will run, or all jobs that will run and all
jobs that are eligible to run but will not run due to conditions set on the
module. The sample production schedule report shown in this topic displays
two chains: SYSTEM and SALES_REPORTS. The Skip column in the
analysts report displays an abbreviation indicating why the module will not
be run. Notice that NDOW displays for HISTORY_PURGE. Chain names are
in {brackets}. Module names follow the chain names. The SALES_REPORTS
chain runs three modules: REGION_A, REGION_B, and REGION_C. The
first two modules each have a BEFORE condition.
Generating a Production Schedule

To generate a production schedule report:
1.
Request and submit the PRODSCH chain.

The chain runs two modules SCHCREATE and SCHPRINT.
2.
Enter the start and end dates for the report.
3.
Choose Yes or No for the analysts status values.

Choose Y to show all jobs including those that will not run due to the
days of the week settings and conditions. This is useful for analysts that
are reviewing schedules to make sure they will do what was intended.
Choose N to display only those jobs that will run. This report is most
useful for operators who are monitoring the system.
4.
Enter the minimum schedule number.

To display
Use this value
Jobs scheduled to run daily
-3
Jobs scheduled to run hourly
-4
Jobs scheduled to run on minute intervals
-5
Note: If selecting an interval other than -3, you should review your start
and end dates, because the shorter interval settings will produce larger
reports.
5.
Submit the module and view the output for the SCHPRINT module.
Sample Production Schedule

Skip {Chain}Report Name
---- ---------------------------------------------------Saturday Feb 23 2004 00:00
{SYSTEM}Saturday Feb 23 2004 00:00
{SYSTEM}DELDEFAULT
NDOW {SYSTEM}HISTORY_PURGE
Monday Feb 25 2004 00:00
{SALES_REPORTS}Monday FEB 25 2004 00:30
{SALES_REPORTS}REGION_A
B If CURRENT TIME > 06:00:00 then SKIP TASK
{SALES_REPORTS}REGION_B
B If CHECK FILE NO /reports/region_b.dat
{SALES_REPORTS}REGION_C
Production Schedule Output Abbreviations

The five abbreviations used in the production schedule are described below.
Abbreviation
Definition
NACT
NDOW
SONNHD
Not active
Not run, day of week
Skip, not in calendar (being run with a calendar and it's not in
the calendar)
Run, in calendar (being run with a calendar and it's in the
calendar)
Skip, in calendar (skip using a skip calendar)
RONHD
SONHD
Notes
55
56
Notes

1.
Name two ways you can display scheduled jobs?

______________________________________________________
______________________________________________________
______________________________________________________
2.
If you want a detailed schedule of what jobs will be running over the
next day, what chain would you run?
______________________________________________________
3.
How do you load data for Forecasts (and Graphical Forecasts)?

______________________________________________________
4.
If you edit a chain's schedule and immediately view a Forecast, will the
changes be displayed?
(Yes or No) ________
Notes
57
58
Lesson 5
Monitoring and Managing Jobs
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
Introduction to Monitoring and Managing Jobs ........................................................................

Viewing and Editing Job Details ..............................................................................................
Taking Action on Jobs in the Backlog ......................................................................................
Removing Jobs as Predecessors in History ............................................................................
Working with Operator Logs ....................................................................................................
Exercise 5A: Performing Operations ...................................................................................
Filtering the Backlog and History .............................................................................................
Querying for Jobs in History ....................................................................................................
Exercise 5B: Finding a Job in the History ............................................................................
Staging Jobs ............................................................................................................................
Exercise 5C: Staging a Chain ..............................................................................................
Review Questions ....................................................................................................................
60
62
64
66
68
70
74
76
78
80
82
84
60
Lesson 5: Monitoring and Managing Jobs
Slides
5.1 Introduction to Monitoring and Managing Jobs

You can monitor and manage jobs, queues, and agents with the Explorer window.
From the Explorer window, you can monitor and manage queues, agents, and
jobs. In this lesson we will focus on monitoring and managing jobs. A sample
Explorer screen showing the Backlog and History is shown in Figure A.
Figure A. The Explorer window
The Backlog and History

When a job is submitted to an AppWorx queue, it is sent to the Backlog. Each
job in the Backlog is assigned a unique job ID. The Backlog is a list of jobs
that:
Are waiting to run
Are running
Have run and failed, and have stayed in the Backlog for operator
intervention
Whether a job remains in the Backlog when it fails is determined by the Stay
in queue on abort setting in its module definition.
Jobs sometimes fail by aborting, timing out, being killed, etc. When jobs fail, a
record is written to the History under the current job ID number. If a failed
job remains in the Backlog, its Job ID is incriminated by .01. For example,
assume a job with the job ID 2045 aborts and remains in the Backlog. A record
of the job aborting is written to the History, and the job remains in the
Backlog with the job ID 2045.01.
Before a job executes, you can view and change its details. When a job leaves
the Backlog, AppWorx writes a record for it in the History. The History is an
audit trail of all failed and completed jobs.
Numbers to the right of the label for the Backlog and History indicate the
number of rows currently displayed in each. Every row is counted regardless
of whether it represents a module, chain, or historical record. Some jobs may
include multiple records in History. For example, a module that aborts and is
reset will include two History records.
Viewing Output and Job Details

You can view output as well as job details for any job in the Backlog or
History. You view the job details for a job by right-clicking it, and selecting an
option from the pop-up menu.
Monitoring with the Status Bar and Object Icons

The status bar is displayed across the bottom of the Explorer window. Its color
alerts you to the status of the AppWorx master, agents, and jobs running in
the Backlog. When the Explorer window is minimized it uses the same color
scheme on the taskbar.
The status bar colors and descriptions are described in the table below.
Color
Description
Green
Yellow
All jobs, masters, and agents are running satisfactorily.

One or more jobs are on hold.
Note: If there are aborted jobs and jobs on hold, the
aborted jobs take precedence and the status bar will be red.
One or more jobs have aborted, or otherwise not completed
with a status of FINISHED. Or a master or agent has a
BUSY or TROUBLE status.
Red
The status bar displays the time that the display was last refreshed.
The virtual workday start time is displayed to the left of the status bar. It is
used to establish reset times for predecessor statements.
The current date and time of the database are displayed to the right of the
status bar.
Notes
61
62
Slides
5.2 Viewing and Editing Job Details

Before jobs run, or when they abort or are killed, you can change their parameters
in the Backlog. To change a job's parameters, right-click the job and choose Job
Details from the pop-up menu. When you change a module or chain's parameters
in the Backlog, the changes are applied only to that instance of the job. They do
not affect the definition of the module/chain.
When a job is in the Backlog or History, you can right-click it to view the job
details. You can select the tabs to view the prompts, predecessors, conditions,
notes, and output for the job. If the job is in Backlog and has not run yet, you
can change the details.
Figure A. Right-click and select Job Details to view the parameters for a job.
Any changes you make apply only to the current instance of the job, and will
not affect the job the next time it is submitted.
Viewing and Editing Prompts

Prompts pass user input to the program run by a job. Prompts for a job can be
viewed and edited from the Backlog and viewed from the History. A bad
prompt value can cause a job to abort.
Viewing and Removing Predecessor Links

If a job in the Backlog has several predecessors, you can view the predecessors
by right-clicking the job and choosing the Predecessors option from the pop-up
menu. AppWorx displays the Predecessors tab in the Job Details window.
The External Scheduled Predecessors pane in the upper part of the tab lists
the jobs which are predecessors of the selected job and are not in the Backlog.
The Predecessors in Backlog pane in the lower part of the tab lists the jobs
which are predecessors of the selected job and are currently in the Backlog.
If jobs are not in the Backlog, but are scheduled to run in the current virtual
day, their scheduled start time will be shown in the Schedule column.
To remove a predecessor link, place a check mark in the Remove column and
click Apply.
Viewing Successors
If a job in the Background has one or more successors, you can view the
successors by right-clicking the job and choosing the Successors option from
the pop-up menu.
Reviewing Chain Structure with the Flow Diagram

The flow diagram shows the chain graphically, making it easy to review the
structure of the chain.
Viewing and Editing Conditions

Conditions control the execution of jobs. They can be evaluated before, during,
and after a job executes, or after a job is deleted. Conditions for a job can be
viewed from the Backlog and History. Conditions can be added, edited, or
deleted from jobs in the Backlog. Condition may cause a job to go into several
statuses including HOLD, ABORTED, and CONDITN WAIT. For a list of Job
Status values see the Operations Guides Appendices in the online help.
Viewing Notes
Notes are written by the person who created the module or chain, they provide
relevant information about the processing of a job. You can access these
comments, suggestions, or instructions from the Backlog or History when they
have been included.
Viewing and Adding Job Logs

You can view logs that have been created for jobs by selecting the Log Query
tab. You can view logs for a specific module or chain, as well as entering
keywords displayed in the text of the logs.
You can enter a new log for a job by selecting the Log tab. When you make an
entry, AppWorx automatically adds a date and time stamp.
Notes
63
64
Slides
5.3 Taking Action on Jobs in the Backlog

The Backlog shows the jobs being processed in each queue. You can change the
status of a job and delete jobs from the Backlog by right-clicking and selecting a
status option.
You can select one or more jobs in the Backlog (shown in Figure A) and
right-click to:
Put jobs on hold
Kill jobs
Resubmit aborted, killed, or on hold jobs
Delete jobs
Remove all predecessors
Figure A. Right-click to change the status of a job in the Backlog.
Putting Jobs On Hold

If a job is in the Backlog but has not yet started, you can put it on hold. The
job will remain in the Backlog with a status of HOLD until you reset it or
delete it from the queue. If a job has started running, you cannot put it on
hold. However, you can kill a running job.
Killing Jobs
If a job is running, you can kill it by selecting the job and using the Kill
command. When you kill a job, it stays in the Backlog until you delete it, or
reset it. When you kill a job, AppWorx makes an entry in the History showing
the job was killed.
Resetting Aborted, Killed and On Hold Jobs

If a job aborts and remains in the Backlog, is killed, or is put on hold, you can
reset it directly from the Explorer window. Before restarting a job, you can
review its parameters, prompts, and conditions, and correct any problems.
When you restart an aborted job, its status changes to NULL. As soon as a
thread becomes available in the queue, the status changes to STARTING.
An aborted job stays in the Backlog if the Stay in queue on abort option was
set when the module was created. If this option was not set, the job is cleared
from the Backlog and an entry is displayed in the History. You cannot restart
a job from the Explorer window once it has been removed from the Backlog.
However, you can resubmit the job by going to the Requests window.
Deleting Jobs
If a job in the Backlog has a status other than STARTING or RUNNING, you
can delete it. For example, jobs with a status of THREAD WAIT, ABORTED
or KILLED can be deleted. When you have deleted a job, you cannot resubmit
it directly from the Explorer window.
Removing All Predecessor Links

If a job in the Backlog is waiting for one or more predecessors before it can
run, you can force it to run by removing the predecessor links. To remove all
predecessor links from a job, select the job and right-click. Choose the Remove
All Predecessors option from the pop-up menu.
Notes
65
66
Slides
5.4 Removing Jobs as Predecessors in History

To remove a job as a predecessor for all potential predecessor links, right-click
the job listing in the History and select Remove as Predecessor. The predecessor
links of other jobs need to be satisfied by another running of this job.
There may be times when you run a job that serves as a predecessor to one or
more other jobs, and you need to rerun the job. This may happen when the job
completes successfully, but is run with incomplete data.
To disallow predecessor links to this job, you must remove it as a predecessor.
Once a job is removed as a predecessor, it is as if it did not run. All predecessor
links to it will not be satisfied until the module, chain, or chain component
runs again.
Figure A. You can remove this run of a job as a predecessor for all potential
predecessor links from the History.
Procedure
To remove a job as a predecessor for all potential predecessor links, right-click
the job listing in the History and select Remove as Predecessor from the popup menu as shown in Figure A. AppWorx removes this running of the job as a
predecessor for all predecessor links which reference it. The predecessor links
of other jobs will now need to be satisfied by another instance of this module,
chain, or chain component.
Example
Assume you are running two nightly processing chains: Chain A and Chain B.
Both chains have external predecessors to each others components.
Mid-way through processing, both chains abort. You want to rerun the chains,
but the external predecessors up to the point of failure have already been met
because their jobs have completed successfully and passed into History. If you
rerun the chains, all cross-dependencies up to the point of failure will already
have been met and the chains may run out of sync.
However, by using the Remove as Predecessor feature on the completed jobs
in History, you can effectively reset all the external predecessors.
Notes
67
68
Slides
5.5 Working with Operator Logs

To view or add logs for jobs in the Backlog or History, right-click the job and
choose Operator Log from the pop-up menu. You can search for logs from
previous runs of a job or for other modules and chains using the Operator Log
Query tab on the Job Details window.
Job operator logs provide information about the running of a job. AppWorx
automatically creates logs that:
Detail actions taken by an AppWorx user
Tell about condition actions that affect the running of a job
Give output scan details when rules are met
Give details on jobs with a LAUNCH ERR status
Additionally, you can include your own logs to provide relevant information
about the processing of a job. You access, add, and query logs from the Backlog
or History.
Figure A. View or add current operator logs for a job.
Viewing and Adding Logs for a Job

To view operator logs and add an operator log to a job:
1.
Right-click the job and choose Operator Log from the pop-up menu.
AppWorx opens the Job Details window with the Operator Log tab
selected (see Figure A). If there are any entries for the job, they are
displayed in the Log box. Each entry includes the user name of the
person who wrote the operator log, and the date and time it was
submitted. In Figure A, there are two entries associated with this job.
2.
To add an entry to the job, enter text in the New Entry box at the top of
the window and click Add.
3.
AppWorx adds the entry to the Log box.
4.
To save the entry and keep the window open, click Apply.
5.
To save the entry and close the window, click OK.

After you have added an operator log entry, you cannot change it. It
becomes a permanent part of the jobs history.
Querying Logs for Other Jobs

To view logs for another job:
1.
From the Job Details window, select the Operator Log Query tab.
The table on the top of the screen displays all previous logs for the
selected module or chain (Figure B).
2.
Select an operator log from the table to view its text below.
3.
To view logs for other modules/chains, select the module/chain from the
Module drop-down box. You can also query by keywords in the text.
Figure B. View logs for other instances of the job or query by name or keyword to view
other jobs operator logs.
Viewing an Operator Log Report

To view a report of operator logs from the History, select Explorer Reports from
the Reports menu on the Explorer window. This will open the Reports window
with the Explorer reports selected. Select the AW_OPERATOR_LOGS report and
click Show.
Notes
69
70
Slides
Exercise 5A: Performing Operations

In this exercise, you submit a chain that lets you test several AppWorx operator
features.
In this exercise, you run a chain called OPERATIONS through the queue you
created (QUEUEnn). The chain contains the components described in the
table below.
Module
Description
HOLD_TASK
This job is immediately put on hold by a condition

statement. All of the modules in the chain are set to
run sequentially, so this job prevents the other
components from running.
This job is in the chain so you can practice deleting
a non-running job.
This job has an incorrect value entered for a prompt
that causes it to abort.
This job is used to show what happens when you
remove all predecessor links from a component.
DELETE_TASK
ABORT_TASK
REMOVE_PRED
After running the chain from the Requests window, you will switch to
Explorer to:
Remove the predecessor link from the DELETE_PRED_TASK job.
Delete the DELETE_TASK job.
Change the status of the HOLD_TASK job.
Change the prompt value for the ABORT_TASK job, reset it, kill it, and
finally delete it.
This exercise illustrates the flexibility of job control in AppWorx.
Running the OPERATIONS Chain

To run the OPERATIONS chain:
1.
Request the chain OPERATIONS from the Requests window.

AppWorx displays the Submit window shown in Figure A.
Figure A. Select your queue to view only the modules you have submitted.
2.
Enter your nn number in the Task Name Suffix field.
Notes
This will enable you to find your specific chain in the Backlog.
3.
Click Submit.
This runs the OPERATIONS_nn chain.
4.
Open the Explorer window.
5.
Expand the Chains listing in the Explorer tree and select the
OPERATIONS_nn chain as shown in Figure B.
Figure B. Select your chain to view only the chain you submitted and its
modules.
Notice that the OPERATIONS_nn chain has an INITIATED status, the
HOLD_TASK module is on hold, and the other three jobs are PRED
WAIT (not running).
Removing Predecessor Links

If for some reason, you want a job that is in a PRED WAIT status to run, you
can remove its predecessor links.
To delete the predecessor links on the REMOVE_PRED:
1.
Right-click the REMOVE_PRED job in the Backlog.
2.
Select Remove All Predecessors from the pop-up menu.
Deleting a Job
You can delete a job if it is in the Backlog but has not yet started.
To delete the DELETE_TASK job:
1.
Right-click the DELETE_TASK job in the Backlog.
2.
Select Delete from the pop-up menu.
71
72
Notes
Resetting the Job On Hold

To reset HOLD_TASK:
1.
Right-click HOLD_TASK in the Backlog.
2.
Select Notes to read the chain detail notes for the module.
3.
Select RESET from the pop-up menu shown in Figure C.
4.
Click OK on the confirmation dialog box.
Figure C. Select Reset from the pop-up menu to reset a module on hold.
5.
Note whether the module runs.

If the module runs, the ABORT_TASK module should begin and
abruptly abort.
Editing Prompts in the Backlog

If a job aborts, you can change its parameters from the Backlog and reset it.
1.
Right-click the ABORT_TASK module and select Output and/or Notes

from the pop-up menu to determine why the module aborted.
2.
Select the Prompts tab shown in Figure D, and change the prompt from
three hundred to 300.
Figure D. You can edit prompts in the Backlog and reset modules.
This will cause the module to run for 5 minutes when it is reset.
3.
Reset the module.
Killing and Deleting a Running Job

You can delete a job if it is in the Backlog but has not yet started. If a job is
running, you must kill it before you can delete it.
To kill and delete the ABORT_TASK job:
1.
Right-click the ABORT_TASK job in the Backlog.
2.
View the Output and Notes for the job,
3.
Kill the job.
4.
Delete the job.
5.
Note the entry in the History (be sure to refresh the display).
When the ABORT_TASK module is deleted, go into the History and
enter an operator log to explain that you killed and deleted it.
Notes
73
74
Slides
5.6 Filtering the Backlog and History

You can limit the jobs shown in the Backlog and History by opening the Filter
menu and choosing Filter Backlog and History.
You can filter the Backlog and History using the criteria available on the
Filters window shown in Figure A. When you filter a view, you limit the jobs
displayed based on the jobs currently available in the Backlog and History.
The jobs displayed in the History are determined by the Job History Limits
set in the Settings window.
Figure A. You can select any combination of filters.

To filter Backlog and History, open the Filter menu and choose Filter Backlog
and History. Enter values in the fields by doing one or more of the following:
Type in names of the objects separated by commas.
Select from a list of objects by clicking on the object icon at the end of the
field.
Selecting Sort Order

You may select a default sort order for the filter by selecting a Sort option.
You can override the sort order in the Backlog/History by selecting a different
column name.
Saving a Filter
You can save a filter to use later by entering a name in the Filter name dropdown box. The filter will be saved when you click OK. Saved Filters can be
recalled from the Filter name drop-down box for History queries, Output
queries, and filters of the Backlog and History.
Using the Object Assignment Windows

When you click on an icon at the end of one of the applicable fields, AppWorx
displays the object assignment window where you can pick one or more objects
to use in a filter. The windows will list only the objects to which you have role
access. Use the arrow buttons to move objects between the Unassigned and
Assigned tables.
Notes
Figure B. Object assignment window for modules

Use the Other filters field to enter text-based filters.
You can enter several letters, and all objects beginning with those
letters will be included.
You can use wildcards in the text. You can use the _ wildcard to represent a
single character, and the % wildcard to represent an unlimited number of
characters.
Use the Search field to query the Unassigned table. You can apply the search
criteria to the Assigned column as well by selecting the Show all assigned
option.
Viewing Filter Results

When you click OK in the Select Filters window, AppWorx runs the search
and displays the filtered results. The Apply Filter check box will be selected.
To view the unfiltered Backlog and History, uncheck the Apply Filter box.
75
76
Slides
5.7 Querying for Jobs in History

To search for specific jobs in the History, go to the Filter menu and select History
Query. You can query by queues, modules, chains, job statuses, agents,
requestors, start times, and job IDs.
If the number of jobs listed in the History is overwhelming, or you wish to
view output from jobs which exceed the settings for the Job History Limits,
you can go to the Filter menu and run a history query (see Figure A).
Figure A. You can limit the jobs listed in the History using
the History Query window.
This window works the same way the Filter window works.
Notes
77
78
Slides
Exercise 5B: Finding a Job in the History

In this exercise, you search for a job in the History.
You have run several chains today. In this exercise, you filter the History for
the EMPLOYEE_REPORT_nn module.
What to Do
1.
Open Explorer.
2.
Open the Filter menu and select History Query.

AppWorx displays the History Query window shown in Figure A.
Figure A. History query window

3.
In the Modules field, type EMPLOYEE_REPORT_nn, where nn is your

student number.
You cannot select this job using the icons, because it ran with a task
name suffix.
4.
Click OK and check if the results are what you expected.
Notes
79
80
Slides
5.8 Staging Jobs

Staging jobs in the Backlog gives you the opportunity to alter a jobs details before
it runs.
Scheduled jobs appear in the Backlog when they are ready to run.
Additionally, you can stage jobs in any number of hours into the future.
Staging jobs in the Backlog gives you the opportunity to alter a jobs details
before it runs.
Figure A. Staged jobs in the Backlog
Statuses
Staged jobs in the Backlog will have a DATE PENDING status as shown in
Figure A.
Components of a chain in DATE PENDING status will have a STAGED or
STAGED_PW status (depending on the components predecessor
requirements).
Working with Exceptions

Operators often have to deal with exceptions to production schedules. Four of
the most common schedules are described below along with how you handle
them in AppWorx.
Exception
What to Do
Run a non-scheduled job.

Run a non-scheduled job at
a later date.
Do not run a scheduled job.
Run a scheduled job with
changes.
Request the job from the Request window.

Request the job from the Request window and
change the start date.
Stage the job, then delete it from the Backlog.
Stage the job and make the changes in the
Backlog.
Filtering
You can filter staged jobs in the Backlog using the Future Hours field in a
Backlog and History filter.
Running the APPWORX_STAGING Module

You stage jobs running the APPWORX_STAGING module. The
APPWORX_STAGING module can be scheduled or requested on an ad hoc
basis:
If you want to:
Then run the APPWORX_STAGING

module with:
Stage jobs for an operations shift

Edit the job details for one or more
particular jobs.
A schedule.
An ad hoc request.
The APPWORX_STAGING module includes the following prompts.

Prompt
Instruction
Applications to
be Staged
Use the MS button to select all modules and chains that are
assigned to one or more AppWorx applications.
Chains/Modules
Use the MS button to select individual modules and chains

from the application(s) selected in the first prompt. If one or
more applications are selected, but not any chains or
modules, then all chains/modules of the selected
applications will be staged. Any scheduled chains or
modules not staged will be inserted in the Backlog at the
time they are eligible to run.
Include Hour/
Minute
Schedules
Determine whether you wish to include chains/modules

with Hours or Minutes selected in their schedules Units
box.
Hours ahead to
be staged
Determine the number of hours you want to stage jobs.
Multiple Schedules
You can create multiple schedules for the APPWORX_STAGING module that
use different prompt values. For example, if you wanted to stage jobs for the
next eight hours, and wanted to update the staging every hour, you might
create the following schedules:
WORKDAY: Runs Monday through Friday at 8:00 A.M. and lists all
chains and modules for 8 hours without including hour/minute
schedules.
EVERY_HOUR: Runs every hour and lists all chains and modules
including hour/minute schedules.
Notes
81
82
Slides
Exercise 5C: Staging a Chain

In this exercise, you stage the SALES_REPORT chain.
Scenario
You are an operator working in ABC Companys operations group. ABC
Company has been running AppWorx for many months now, and operations is
automated except for special requests. As such, you do not stage jobs in
AppWorx unless there is a problem or special request.
The SALES_REPORTnn chain is scheduled to run everyday at 11:00 P.M. You
just received a call from one of the production analysts requesting that for
tonights run, the WESTERN_REGION module should not be run.
What to Do
1.
Stage the SALES_REPORTnn chain for the next 24 hours.
2.
Delete the WESTERN_REGION module from the chain for tonights

run.
3.
You receive another phone call from the production analyst saying they
want to cancel the entire chain. Delete the SALES_REPORTnn chain
from the Backlog.
Notes
83
84
Notes

1.
What do the colors green, yellow, and red displayed on the Status Bar
mean?
______________________________________________________
______________________________________________________
______________________________________________________
2.
Can you delete a RUNNING job? How would you stop processing a
RUNNING job?
______________________________________________________
______________________________________________________
3.
When you kill a job, the status of the job first goes to KILL, then
KILLED. What does this mean?
______________________________________________________
______________________________________________________
4.
Do the records for aborted modules in the History include output files?
(Yes or No) ________
5.
What determines if an aborted job stays in the Backlog or passes

directly to History?
______________________________________________________
______________________________________________________
6.
How would you make a one-time change to a chain before it runs?

______________________________________________________
______________________________________________________
______________________________________________________
Notes
85
86
Lesson 6
Graphical Analysis Package (optional)
6.1 Introduction to the Graphical Analysis Package ...................................................................... 88
6.2 Monitoring and Managing Jobs with the Gantt View ............................................................... 90
6.3 Reading the Gantt View ........................................................................................................... 92
6.4 Setting the Gantt View Preferences ........................................................................................ 94
6.5 Viewing a Graphical Forecast .................................................................................................. 96
6.6 Viewing an Historical Gantt Chart ............................................................................................ 98
6.7 Monitoring System Performance with the Dashboard ........................................................... 100
6.8 Viewing a Gantt Chart of a Chain .......................................................................................... 102
6.9 History and Custom Reports ................................................................................................. 104
6.10 Review Questions ................................................................................................................ 106
88
Lesson 6: Graphical Analysis Package (optional)
Slides
6.1 Introduction to the Graphical Analysis Package

The Graphical Analysis Package includes a Gantt View for operations, a Chain
Summary for production control analysis, and a Dashboard for monitoring system
performance.
The Graphical Analysis Package is an add-on package for AppWorx that
includes the following operations tools:
Backlog Gantt View for operations
History Gantt View
Dashboard for monitoring system performance
Graphical forecast
History and custom reports
Additionally, the Graphical Analysis Package includes a Chain Gantt View
and Chain Simulation for Development.
Backlog Gantt View

The Gantt view displays the contents of the Backlog in a Gantt chart format.
It is real-time, and updated based on the Continuous Monitoring setting.
All actions that can be taken against jobs in the Backlog can be taken against
jobs in the Gantt view.
Figure A. The Backlog Gantt view window
History Gantt View

The History Gantt view displays jobs in the History in a Gantt chart format.
The jobs displayed in the Gantt view are determined by the jobs you select in
History before opening the Gantt view.
Figure B. The History Gantt view window.
Dashboard
If you want to monitor system performance, you can use the Dashboard
included in the optional Graphical Analysis Package. Several Dashboard
windows are shown in Figure C.
Figure C. You can monitor system performance with the Dashboard.
Graphical Forecast
The Forecasted Gantt view window shows you a list of scheduled modules and
chains in a Gantt chart format. The Graphical Forecast is part of the Gantt
view, an add-on product to AppWorx.
Figure D. The Forecasted Gantt view window
Printing from GAP

You can print any of the displays included in the Graphical Analysis Package.
History and Custom Reports

The Graphical Analysis Package adds a number of history reports to the
standard set of reports that ships with AppWorx. It also adds a custom report
writer that you can use to create custom reports from any database in your
enterprise.
Notes
89
90
Slides
6.2 Monitoring and Managing Jobs with the Gantt

View
The Gantt view displays the contents of the Backlog in a Gantt chart format. All
actions that can be taken against jobs in the Backlog can be taken against jobs in
the Gantt view.
The Gantt view is an add-on product to AppWorx. It displays the contents of
the Backlog in a Gantt chart format. It is real-time, and updated based on the
Continuos Monitoring setting. All actions that can be taken against jobs in
the Backlog can be taken against jobs in the Gantt view.
Figure A. The Gantt view window

The Gantt view window displays an expandable job tree on the left, and the
Gantt chart on the right. Each job (module or chain) is displayed on its own
row.
You can change the size of the two panes by dragging the vertical splitter bar
that divides the panes.
Rectangles represent the expected run times of the jobs: black for chains and
blue for modules.
Arrows drawn between the rectangles indicate predecessor links.
Displaying the Gantt View

To display the Gantt view, open the Operations menu and select Backlog
Gantt view.
Gantt Legend
The Legend describes the graphics used in
the Gantt view. To display the legend, click
the Legend button in the menu bar. To
close the Gantt Legend window, click the X
in the upper right corner of the window.
Taking Actions on Jobs and

Viewing/Editing Job Details
You can right-click jobs in the Backlog
Gantt view window to take actions on them
or to view/edit their job details the same
way you would in the Explorer window.
Figure B. The Gantt legend window.
Displaying Gantt Job Summaries

When you are working in the Backlog Gantt window, a pop-up menu is
displayed when you hover over a job as shown in Figure C. You can customize
the information displayed in this menu by selecting Tables from the Options
menu and picking the Gantt job summary option.
Figure C. Hovering the mouse pointer over an object in the tree

displays information about the object in a pop-up window.
Notes
91
92
Slides
6.3 Reading the Gantt View

The Gantt view window displays jobs in chronological order with time displayed
horizontally.
The Gantt view provides a good deal of information about the jobs running in
the Backlog.
Figure A. The Backlog Gantt view window
Chains
Chains are represented by a rectangle with a black border. The rectangle
extends from the scheduled start time to the estimated completion time based
on the average run time for the chain. The average run time is based on the
sum of the average run times of all jobs in the chain.
When a chain is initiated, a green bar is displayed in the rectangle. The green
bar indicates the current run time for the chain. The green bar is displayed
until the chain is completes or is killed. When a chain completes, the run time
bar turns black.
If a job in a chain aborts, a red X is placed over the chain name in the job
tree. Note a chain never aborts, only the components in a chain.
From an operations standpoint, you can display only the unexpanded chains
in the Gantt chart and easily monitor the system. If a problem arises with a
chain, or you want to see more details about individual components in a chain,
you can expand the chain.
Modules
Modules are represented by a rectangle with a blue border. The rectangle
stretches from the scheduled start time to the completion time based on the
average run time for the module.
Actual run times for chains and modules are represented by solid bars in
running through the center of the rectangles. The color of the bar indicates the
status of the job.
Bar Color
Description
No color bar
Green
Yellow
Red
Black
Job is waiting to run.

Job is running
Job is on hold
Job has aborted
Job has completed successfully
Adjusted Start and End Times

Adjusted start and end times for chains and modules are represented by the
Start and End symbols. Before the time a job is scheduled to run, these
symbols will align with the start and end times of a chain or module. If a chain
or module starts earlier or later than scheduled, these symbols move to reflect
the difference in times.
Displaying Predecessor Links

You can display predecessor links for a job in the Gantt view by hovering the
mouse pointer over the jobs bar in the Gantt chart as shown in Figure B.
Figure B. To see the predecessor links for a job, hover the

mouse pointer over the jobs bar in the Gantt chart.
Examples
To help you interpret the start and end time symbols as they relate to chains
and modules, several examples are given below.
When a chain or module is:
Waiting to run and is still on

schedule
Waiting to run and is expected
to start ahead of schedule.
Waiting to run, but is behind
schedule
Running on schedule
Running ahead of schedule.
Running behind schedule
The bar looks like this:
Notes
93
94
Slides
6.4 Setting the Gantt View Preferences

Use the options under the Preferences menu to customize the Gantt chart.
You can customize the Gantt chart by selecting the options under the
Preferences menu.
Keep History
When selected, this option will keep completed chains in the Gantt view.
Normally, completed chains are not displayed in the view. The chains will
remain in the Gantt view until you close the Gantt view window.
Show Horizontal Lines

Displays horizontal lines across the Gantt view.
Figure A. Gantt view with horizontal lines displayed
Show All Predecessors

Predecessor links are shown at all times.
Show Only Selected Predecessors

You must select a job from the tree to show its predecessor links.
Show Predecessors When Dragged Over

You must drag the mouse over a jobs bar in the Gantt view to display its
predecessor links.
Notes
95
96
Slides
6.5 Viewing a Graphical Forecast

If you have purchased the Graphical Analysis Package, you can view a graphical
forecast.
The Forecasted Gantt view window shows you a list of scheduled modules and
chains in a Gantt chart format. The Graphical Forecast is part of the Gantt
view, an add-on product to AppWorx.
Figure A. The Forecasted Gantt view window
Opening the Forecasted Gantt View Window

To open the Forecasted Gantt view window shown in Figure A:
1.
Do one the following:

Open the Operations menu and select Graphical Forecast.
Select the Graphical Forecast icon
from the toolbar.
AppWorx displays the Forecast filter window shown in Figure B.
Figure B. The Forecasted dialog

window
2.
If you wish to filter the jobs displayed in the forecasted Gantt view
window, edit the options described in the table below.
Field
Limits the display of data from the FORECAST

module to:
Start date
End date
Sub levels
Jobs scheduled after this start date.

Jobs scheduled before this start date.
Chain components within a maximum nested
depth.
Include jobs that are scheduled by minutes or
hours (when unchecked).
Include minute and

hour schedules
What Controls the Data Displayed

Data displayed in the Forecasted Gantt window is generated and loaded into
AppWorx by running the FORECAST module. When you create a schedule for
the FORECAST module, you determine the time frame of the forecast and
how often it is run.
By entering information into the fields on the Forecast dialog window, you are
filtering the data generated by the FORECAST module, not adding to it.
For example, if the FORECAST modules end time is set to 24 hours past the
current time, and you enter a value for the Forecasted end date which is 48
hours from the current time, you would only see jobs in the graphical forecast
that are scheduled to run in the next 24 hours.
Notes
97
98
Slides
6.6 Viewing an Historical Gantt Chart

After a chain completes, you can view an historical Gantt chart that shows
expected and actual run times.
To view one or more jobs in the History in a Gantt chart format, select the
jobs, right-click and choose the History Gantt view option. If you select chains
or chain components, AppWorx displays all jobs in the corresponding chain(s).
Figure A. The History Gantt view window.
Procedure
To view one or more jobs in the History in a Gantt chart format:
1.
Select one or more the jobs in the History.
2.
Right-click and choose the History Gantt view option as shown in

Figure B.
AppWorx opens the History Gantt view window shown in Figure A.
If you select chains or chain components, AppWorx displays all jobs in
the corresponding chain(s).
3.
If you wish, you can right-click a job and select Flow Diagram to view its
predecessors in a flowchart view.
Figure B. To view one or more jobs in the History in a Gantt chart

format, select the jobs, right-click and choose the History Gantt view
option.
Comparing Run Times in a Gantt Chart

You can graphically compare run times of jobs in the History. To do this, run a
History query on a module or chain, then view the queried jobs in the History
Gantt view window. In the History Gantt view window, select Set start times
to midnight from the Actions menu.
Figure C. The History Gantt view window with six

chains displayed.
Notes
99
100
Slides
6.7 Monitoring System Performance with the

Dashboard
The Dashboard is a graphic display of performance information about jobs
running in AppWorx.
If you want to monitor system performance, you can use the Dashboard
included in the optional Graphical Analysis Package. The Dashboard at the
bottom of the screen in Figure A.
Figure A. The Dashboard displays system performance data.
Opening and Viewing the Dashboard

To open the Dashboard window shown in Figure A, do one of the following:
Open the Operations menu and select Dashboard.
Select the Dashboard icon
from the toolbar.
AppWorx opens the Dashboard across the bottom of the Explorer window. To
enlarge a gauge in the Dashboard, double-click the gauge. Enlarged gauges
can be moved and sized.
Information Available
The gauges displayed in the Dashboard window are described in the table
below.
Item
Description
Backlog Distribution
Percentage of jobs in the Backlog by status. Each

job status is color coded. ToolTips provide status
names, number of jobs per status and total jobs
when you rest the mouse pointer over a status.
Percentage of running jobs by agent. ToolTips
provide agent names, number of jobs per agent
and total jobs when you rest the mouse pointer
over an agent.
Workload Balancing

Item
Description
Progress of Day
Number of completed jobs for the day and the

number of jobs in the Backlog.
Total thread capacity and thread capacity used for
each agent. ToolTips provide max jobs allowed for
each agent when you rest the mouse pointer over
an agent.
Agent Loading
Queue Loading
Daily Activity
Total job count and thread capacity used for each

queue. ToolTips provide max jobs allowed for each
queue when you rest the mouse pointer over a

queue.
Graph of maximum number of jobs running each
hour of the day.
Green: Running jobs.
Blue: Running or waiting jobs.
Black: Running, waiting, or PRED WAIT jobs.
Editing Dashboard Properties

You can control the appearance of the Dashboard by editing the Dashboard
properties. To edit the properties, right-click the Dashboard or one of the
gauges.
Figure B. The four tabs of the Dashboard Properties window.
Notes
101
102
Slides
6.8 Viewing a Gantt Chart of a Chain

To view a Gantt chart of a chain, click the Gantt view icon in the Chain Builder
menu bar.
The Chain Builder pane shows a chain as a flow diagram. When you want to
look at the expected execution time for the chain as a whole, and the execution
times of the individual components in the chain, you can display the Gantt
view shown in Figure A. To view a Gantt chart of the chain, click the Gantt
view icon in the Chain Builder menu bar. Chain gantt charts are part of the
Graphical Analysis Package, an add-on product which can be purchased for
AppWorx.
Figure A. Gantt view of a chain

The Gantt view displays a tree view of the chain in the left pane, and the
Gantt chart in the right pane.
To view a Gantt chart of the chain, click the Tree view icon
Builder menu bar.
in the Chain
Actions
You can take the following actions on the Gantt view:
You can expand and collapse the elements in the tree by clicking the
toggle
icons.
You can scroll the Gantt chart using the scroll bar at the bottom of the
right pane.
You can change the hours displayed in the Gantt chart by selecting a
value from the Visible Hours field. The range is 1 to 24 hours.
You cannot add, edit, or delete components from the Gantt view.
Options
There are several options available from the Options menu. They are
described below.
Option
Print table
Print preview table
Print tree
Print preview tree
Expand
Collapse
Base time on external
references
Enter start time for
Gantt chart
Reset start time to

midnight
Description
These four options are used to preview and to
print the tree and the Gantt chart.
These two options are used to expand and collapse

a selected component in the tree.
If the chain has external references, you can set
the start times for the Gantt chart to them.
The default start time for a Gantt chart is
midnight of the current day. If the chain is
scheduled to start at a specific time of the day, you
can change the start time using this feature so it
matches the scheduled start time.
Resets the start time for the Gantt chart to
midnight.
Notes
103
104
Slides
6.9 History and Custom Reports

History reports and the custom report writer are part of the AppWorx Graphical
Analysis Package. Job history information used in reports is generated and
loaded into AppWorx by running the AW_CALC_HISTORY_STATISTICS module.
AppWorx comes with an extensive set of predefined reports that you can use
to review how jobs were processed through AppWorx over a given period of
time. If you have the AppWorx Graphical Analysis Package, you get
additional History reports and you can create custom reports from the
Reports edit window.
Figure A. Application Jobs Completed by Hour report
Viewing Reports
You can open reports from object selector windows and from several of the
object definition and operations windows. A sample report is shown in
Figure A.
Creating Reports
AppWorx reports are based on SQL statements. To create a report, you either
start with an existing SQL statement and customize it, or create a report from
scratch. You can add database tables and views to a report. Once database
tables and views are added to a report, you can add columns from them. Each
column can be customized in the report. The object definition for the report
above is shown in Figure B.
Notes
Figure B. The report definition that creates the Application Jobs

Completed by Hour report
Creating Modules from Reports

You may want to create AppWorx modules to run your reports. With modules,
you can schedule your reports, and add them to chains. To create a module
from a report, you select the report in the Report selector window and click
Modules.
Loading Data for History Reports

Data relating to job history used in reports is generated and loaded into
AppWorx by running the AW_CALC_HISTORY_STATISTICS module.
Depending on the amount of data in your History, the
AW_CALC_HISTORY_STATISTICS module may take a long time to execute.
The AW_CALC_HISTORY_STATISTICS module can be requested and
submitted on an ad hoc basis. However, we suggest you create a schedule to
run it daily during off hours, or as often as necessary.
Browsing the AppWorx Database

You can browse database tables, views, triggers, and procedures in the
AppWorx database by selecting AppWorx DB Browser from the View menu of
the AppWorx desktop.
105
106
Notes

1.
The start and end symbols for the adjusted start and end times of
modules and chains in the Backlog Gantt view window move to reflect
changes to actual start times.
(True or False) ________
2.
When selecting options on the Forecast filter window, how does this
impact the data displayed in the graphical FORECAST?
______________________________________________________
3.
Which Dashboard gauge shows the number of jobs in the Backlog and
the number of jobs that have completed?
______________________________________________________
Notes
107
108
Lesson 7
Creating Modules
7.1 Introduction to Creating Modules ...........................................................................................
7.2 Defining Modules ...................................................................................................................
7.3 Specifying Output and Login Options for Modules ................................................................
Exercise 7A: Creating a Module ........................................................................................
7.4 Adding Prompts to Modules ..................................................................................................
Exercise 7B: Creating a Module with a Prompt .................................................................
7.5 Adding a List of Values Prompt .............................................................................................
Exercise 7C: Add an LOV Prompt to a Module .................................................................
7.6 Adding Notes .........................................................................................................................
Exercise 7D: Adding Notes to a Module ............................................................................
7.7 Output Scanning ....................................................................................................................
Exercise 7E: Scanning Output ...........................................................................................
7.8 Notifications ...........................................................................................................................
Exercise 7F: Sending a Notification (optional) ...................................................................
7.9 Review Questions ..................................................................................................................
110
112
114
116
118
120
122
124
126
128
130
132
134
136
138
110
Lesson 7: Creating Modules
Slides
7.1 Introduction to Creating Modules

A module contains all the information required to execute a program and handle
its output. Modules can be run with a schedule or on an ad hoc basis. They can
also be included in an AppWorx chain. You can add a module to as many chains
as you wish. If you change a module definition, the change is applied to every
chain that includes the module.
A module is the basic building block in AppWorx. For each program you want
to run (for example: FTP, application, database load), you must create a
module. A module specifies all the information required to run a program
including:
General information: The task that will be run, its program information
and execution options.
Output and login source options.
Prompts: Information that is passed to the program as variables.
Modules can be run individually with a schedule or on an ad hoc basis by from
the Requests window. They also can be run as a component of an AppWorx
chain. The Modules window is shown in Figure A, with the CHAIN_REPORT
module displayed.
Figure A. The General tab for modules.
The Role of Modules in AppWorx

If you have been using scripts to run your operations, you have launched
programs from within a script. In AppWorx, you create a module to launch
each program. After creating a module, you can run the module by itself, or
add it to a chain. Figure B shows the relationship between scripts, modules,
and chains.
Keeping with the AppWorx object-oriented approach to operations, you can
use a module in as many different chains as you wish. If you change a module
definition, the change is applied to every chain that includes the module. You
do not have to change the definition in each chain. This saves you a great deal
of time maintaining your system.

Script
(Job Stream )
Program
:
:
Program
:
:
:
:
:
Program
:
:
:
Program
:
Program
:
M odules
Notes
M odules
in a Chain
Module A
Module A
Module B
Module B
Module C
Module C
Module D
Module D
Module E
Module E
D
E
Figure B. Create modules to run the programs associated with

scripts. Combine the modules to create chains.
Copying Modules
There may by times when you want to create several modules that are similar
except for a few minor changes. For example, you may want to create two
modules that run two different programs, but the information for the
programs is identical except for the program names. The Copy feature lets
you create one module, then copy it and change the program name (see
Figure C)
Figure C. To copy a module, highlight a module and
When you copy a module, the prompts also are copied. You have the option of
coping its conditions, notes, and schedules.
Upgrading Overwrites Standard Objects

If you upgrade AppWorx, any objects or scripts that ship with AppWorx will
be overwritten. Therefore, if you want to modify an object that ships with
AppWorx, for example a module or chain, make a copy of the object and
modify the copy. If you modify the original object, any changes will be lost
when you upgrade.
111
112
Slides
7.2 Defining Modules

To add a module to AppWorx, go to the Object Admin menu on the desktop and
select Modules. Click New and select a module type. In order for a module to
execute a program, you must define its program information including a library,
program type, and program name. To determine what happens when a module
runs, you set its execution options.
Use the Modules window shown in Figure A to define a module.
Figure A. The Modules window.
Selecting a Module Type

When defining modules, you must select a module type. The module type you
select will determine the default selections for certain fields, such as the
program type and login. The Standard module type is used to run scripts and
execute programs. It is the module type you will select most of the time.
Defining Objects
You can define certain objects by clicking the icon to the right of their field.
AppWorx will display an edit window where you can define the new object.
Fields marked with an * on their right are required.
Entering Program Information and Execution Options

In order for a module to execute a program, you must define its program
information including a library, program type, and program name. When the
program information has been assigned, AppWorx displays the path and file
name in the view-only Location field. To determine what happens when a
module runs, you set its execution options.
Defining Applications
Notes
You use applications to group modules

and chains. When defining or
requesting modules and chains, you can
select an application. To define an
application, you must give it a name
and description (see Figure B).
Defining Libraries
Figure B. The Applications window.
A library defines the path for the

program a module runs. To define a
library, you must name the library and
enter its path (see Figure C).
The path can be an actual path or an
environment variable. If you use an
environment variable other than
$AW_HOME, you must define the
Figure C. The Libraries window.
variable either in an AppWorx
environment variable object or in each
instance of AppWorx. For UNIX machines, define the variable at the end of
the $AW_HOME/site/sosite file in Bourne Shell format. To define a variable
called INVERTORY_APP, you would enter:
INVENTORY_APP=/inventory/programs; export INVENTORY_APP
For Windows instances, define the variable at the end of site/envvar.bat as

follows:
set INVENTORY_APP=\inventory\program
Defining Program Types

A program type
defines how a
program accepts
input and handles
output. To define a
program type, you
must enter a
name, description,
host command,
command path,
parameter format
(if appropriate),
and file extension
(see Figure D).
Each program
type is supported
by a program type Figure D. The Program Types window.
script located in
$AW_HOME/exec. The program type script defines the method for passing
input to the program and getting output from the program. The name of the
script is entered in the Host Command field.
Each program type can support UNIX, Windows, and VMS operating systems if
the corresponding fields in the OS portion of the General tab are completed. This
eliminates the need to define separate program types for each OS.
113
114
Slides
7.3 Specifying Output and Login Options for Modules

Using the Output tab, you can control what happens to the output of modules.
Using the Login tab, you can set the login the system will use when the module is
executed.
Output
Using the output tab shown in Figure A, you can control what happens to the
output of modules.
Figure A. The Output tab for a module

The Output function field determines how output is handled. There are
three choices:
LOG: The application output or report files will be listed by default in
the Output window. AppWorx loads all application output or report files
for viewing in the Output window for jobs with a LOG output function
every time you log into the client. This can take several seconds or
minutes. If more than 500 files are loaded, an alert will be displayed.
Therefore, if you are not using the Output window (that is, you view
output from the History instead of the Output window), you should use
the STORE setting.
PRINT: The output is printed according to the print settings specified
on this tab.
STORE: This is the default setting. The output is not printed and is not
listed in the Output window.
The Printer group, Printer, and Print option fields are valid only if you
choose PRINT as the output function.
With any of these settings, the application output and the system output files
can be viewed from the Explorer window.
Login
Using the Login tab shown in Figure B, you can set the login the system will
use when the module is executed (if necessary).
Notes
Figure B. You can select a primary and secondary login for a

module.
The primary and secondary logins make it possible to supply two logins to a
program. This is useful if the program accesses two different databases. For
example, a program might read from one database and write to another
database.
The Login Type field determines the logins available from the Login ID dropdown list. The entry in the Login Type field is determined by the program
type selected for the module. When a program type is defined, it can be
assigned a login. If a login was not assigned to the program type, the Login
Type field will display No selection.
115
116
Slides
Exercise 7A: Creating a Module

In this exercise, you create a module called SLEEP_FIFTEENnn that runs a script
that sleeps for 15 seconds.
In this exercise, you create a module called SLEEP_FIFTEENnn. The module
runs a SQL script called sleep15.sql. The program is located in the sql
directory of the AppWorx home directory. An example is shown in Figure B.
Before creating this module, you will need to know the name of the local agent
and the default database login used for your AppWorx training instance. You
will assign these objects to every module you create in this class. For help, see
your AppWorx Administrator or AppWorx Instructor.
Creating a Basic Module

To create a basic module:
1.
From the Modules selector window, select New and choose the
Standard module type.
2.
Enter the name SLEEP_FIFTEENnn, where nn is your student number

for your module.
If you wish, you can tab from the Name field to automatically give an
module the same description as its name.
3.
While building your module, create an application called TRAININGnn

and assign this module to it.
You will assign all the modules and chains you create in this class to
your application. This will keep them separate from the modules and
chains created by the other students.
To create the application, click the icon to the right of the Application
field. On the selector window, click New and enter the application name
TRAININGnn and description (see Figure A).
Figure A. Enter an application name and

description.
4.
In the Agent/Group field for the module, select the local agent on your
training AppWorx instance.
It will probably be different than the one shown in Figure B.
5.
Your module will be running a SQL*Plus job located in the sql directory
of the local agent. To point AppWorx to the correct script, select the
BATCH library and the AWSQLP type in the Program box.
6.
Select QUEUEnn that you created earlier in the Queue field.
7.
Uncheck the Single Run option, this will allow you to run two or more
instances of this module concurrently in later exercises.
Notes
Figure B. Use the Modules window to define a module.

8.
On the Login tab, select the database login for the AppWorx training
instance from the Login ID field in the Primary login box.
Your database login will probably be different than the one shown in
Figure C.
Figure C. The Login tab
Testing the Module

Test the module by submitting it from the Requests window. Open the
Explorer window to see the module in the Backlog/History. From the History
notice the value in the Elapsed Time column.
117
118
Slides
7.4 Adding Prompts to Modules

Prompts pass parameters to the program run by a module. They can be defined
for modules, chains, and chain components. When you create a prompt, you
assign it a data type. Data types define the format of the data that will be used in
the prompt.
If the program called by a module requires arguments, you can use prompts to
request data that will be passed to the program. An FTP module with seven
prompts defined is shown in Figure A. For example, if a module runs a report
program that accepts a start date and end date, you can create prompts that
let the user enter start and end dates for the report. If the module is
submitted on an ad hoc basic, the user enters values for the prompts at the
time they submit the module. If the module is run as part of a chain, values
for the prompts are entered at the time the module is added to the chain. You
can define up to 99 prompts per module.
Figure A. You define a prompt for a module on its Prompts tab.
Types of Prompts
There are four types of prompts you can create. The type of prompt
determines how the information is entered. The different types of prompts are
described below.
Prompt Type
Description
Default cannot change

Fill-in
The prompt has a default value that users

are not allowed to change.
The prompt may or may not have a default
value. Users are allowed to change the
value.
Users may select one (and only one) choice
from a predefined list of possible values.
Users may select one or more choices from
a predefined list of possible values.
Single selection
from a list
Multiple selection
from a list
Prompts Defined by Data Types

When you create a prompt, you assign it a data type. The data type enables
AppWorx to check the format of the data entered for a prompt, and reject it if
it is incorrect. A sample data type is shown in Figure B.
There are three basic formats that are commonly used in data types:
character, number, and dates. A data type can also incorporate a SQL
statement that searches the database and returns a set of values that can be
selected for a prompt.
Figure B. The data types window.
Working Smarter by Copying Prompts

If you have defined prompts for a module or chain, you can use them in
another module or chain using the Copy button.
Notes
119
120
Slides
Exercise 7B: Creating a Module with a Prompt

In this exercise, you create a module called SLEEPnn that includes a single fill-in
prompt.
In this exercise, you create a new module called SLEEPnn with a prompt. The
module runs a SQL script called test that has a variable called time. The
program is located in the sql directory of the AppWorx home directory. A copy
of the script is shown below:
rem Copyright (c) 1995 by ISA Corporation
REM $Date: 2003-12-20 11:27:43 -0800 (Sat, 20 Dec 2003) $
$Author: admin $ $Rev: 198 $
rem *********************************************************
rem *
rem * needs one prompt set up
rem *
time
- number format - number of seconds to sleep
rem *
rem *********************************************************
rem
whenever sqlerror exit sql.sqlcode
whenever sqlerror exit 1
prompt this is a test
set echo on
show user
spool &1
select 1 from dual where '&time' + 1 > 1;
host sleep &time
spool off
define
quit
Creating the SLEEPnn Module

Create a module named SLEEPnn. While creating the module do the
following:
1.
Select APPLICATIONnn you created in the last exercise.
2.
Select the local agent in the Agent/Group field.
3.
Select the BATCH library and the AWSQLP type in the Program box.
4.
Enter test in the Program name field.

To verify the script exists, it is a good idea to select it using the Select
button.
5.
Select QUEUEnn you created earlier.
6.
Uncheck the Single Run option.

This will allow you to run two or more instances of this module
concurrently in later exercises.
7.
Go to the Login tab and select the database login for the AppWorx
training instance for the primary login ID.
Adding a Fill-in Prompt

Prompts define parameters that are passed to the program run by a module.
The test script run by the SLEEPnn module you created sleeps for a number
of seconds. The program takes one variable: the number of seconds to run. The
variable in the program is called time. Add a fill-in prompt allowing the
requester to specify the number of seconds the script will run.
To add a fill-in prompt:

1.
Select the Prompts tab in the Modules window (see Figure A).
Figure A. Prompts tab

2.
Click New.
AppWorx displays the Edit Prompt window shown. A sample filled in
prompt for this exercise is displayed in Figure C.
Figure B. Enter prompt values and click OK.

3.
Select Character as the data type. This will allow you to enter either a
character or a number for the prompt value.
You will enter a character as a prompt value in a later exercise to force
this module to fail.
4.
Enter the question you want displayed for the prompt in the
Description field. For example:
Enter a number of sleep seconds:
5.
6.
Enter time as your variable name. Remember, time is the variable in the
modules script, so it must match here.
Give the prompt a default value of five seconds by entering 5 in the
Default value field.
7.
Check the Value required box, this will automatically also select Allow
changes as well.
8.
To save prompt and the module.
Testing the Module

Test the module by submitting it from the Requests window. Enter a high
enough number of seconds to give you time to open the Explorer window and
see the job in the Backlog. When the job completes a record is written to the
History, view the output of the job.
Notes
121
122
Slides
7.5 Adding a List of Values Prompt

List of values (LOV) prompts allow users to select a single value from a list of
values. The list is generated by a SQL statement defined for the data type and
selected for the prompt.
List of values (LOV) prompts allow users to select a single value from a list of
values. The list is generated by a SQL statement defined for the data type
selected for the prompt.
Figure A. The Multiple Select/List of Values options include a data

type with an appropriate SQL statement.
The value the user selects from the list is stored in a table, then passed to the
program run by the module at the time the module is executed. LOV prompts
are useful for letting a user select values from a predefined list such as
departments, part numbers, sales regions, states, or countries. If a user types
in a value for an LOV prompt, the value is checked against the list generated
by the SQL statement (see Figure A).
Notes
123
124
Slides
Exercise 7C: Add an LOV Prompt to a Module

In this exercise, you add a List of Values (LOV) prompt to a module.
In this exercise, you create a module called EMPLOYEESnn that calls the
employees SQL program, and add an LOV prompt to the module. The prompt
will let you select a department and get a list of employees for the department.
The prompt will use the Dept_Name data type to generate a list of
departments. A copy of the script is shown below:
set verify off
set feedback off
set termout off
spool &so_outfile
column ename heading 'Employee|Name'
column dname heading 'Dept|Name'
select emp.ename, dept.dname
from emp, dept
where dept.dname = '&dept_name'
and emp.deptno = dept.deptno;
spool off
Creating the EMPLOYEESnn Module

Create a module named EMPLOYEESnn. While creating the module do the
following:
1.
Select APPLICATIONnn you created earlier.
2.
Select the local agent in the Agent/Group field.
3.
Select the BATCH library and the AWSQLP type in the Program box.
4.
Enter employees in the Program name field.

To verify the script exists, it is a good idea to select it using the Select
button.
5.
Select QUEUEnn you created earlier.
6.
Uncheck the Single Run option.

This will allow you to run two or more instances of this module
concurrently in later exercises.
7.
Go to the Login tab and select the database login for the AppWorx
training instance for the primary login ID.
Creating an LOV Prompt

To create an LOV prompt for the EMPLOYEESnn module:
1.
From the Prompts tab for EMPLOYEESnn, click New.

AppWorx displays the Edit Prompt window shown. A sample filled in
prompt for this exercise is displayed in Figure A.
Figure A. Defining the Dept_Name prompt
2.
Select Dept_Name as the data type.

Notice that when you select Dept_Name, the List of Values and Multi
select radio buttons become active. This is because the Dept_Name data
type uses a SQL statement. In this case the SQL retrieves the names of
the departments from the dept database table.
The Dept_Name data type was pre-created for this exercise. If you want
to see its SQL statement, click the icon to the right of the Data type
field and view its definition.
3.
Enter the question you want displayed for the prompt in the
Description field. For example:
Select a department:
4.
5.
Enter dept_name as your variable name. Remember, dept_name is the

variable in the modules script, so it must match here.
Give the prompt a default value of ACCOUNTING by clicking the
Select button to the right of the Default value field.
6.
Check the Value required box.

This will automatically also select Allow changes as well.
7.
To save prompt and the module.
Testing the Module

To test the module and the prompt, run the module from the Requests
window twice. Run with the default prompt value the first time, and select a
different prompt value on the Submit window using the LOV button the
second time. View the output in the History to make sure it ran correctly both
times.
Notes
125
126
Slides
7.6 Adding Notes

You can enter customizable general and abort notes for modules, chains, and
chain components. By selecting an individual job and choosing Notes, operators
can access these comments, suggestions, or instructions.
Notes provide a location to enter relevant information about the processing of
jobs. Notes for a sample FTP module are shown in Figure A.
Figure A. The Notes tab for an FTP module.
Types of Notes
There are two types of customizable notes: General and Abort.
General notes can contain information on goals and requirements or
existing security and access issues.
Abort notes can contain information on what action to take if a module
aborts or fails, who to contact if a module aborts, or what considerations
exist when running a job.
Note Format
You can enter notes in plain text or in HTML code. If you enter HTML code
and select the HTML check box, the note will be displayed in HTML format.
Note Locations
There are three locations within AppWorx where you can enter notes.
Suggested uses for notes are described in the table below:
Note type
Description
Module
Useful when the module is going to be requested

ad hoc, or when the notes for the module would be
usefulregardless of how the module was invoked.
Can be used to provide information which is
relevant to the entire chain.
Can be used to provide specific information about
one component in a chain.
Chain
Chain component
Viewing Job Notes

Users can view module, chain, and chain component notes from the Backlog,
History, and Submit window. If a job aborts, an operator can view the specific
abort notes and make more effective operational decisions.
Notes
127
128
Slides
Exercise 7D: Adding Notes to a Module

In this exercise, you add Module and Abort Module notes to the EMPLOYEESnn
module created in the last exercise.
In this exercise, you add Module and Abort Module notes to the
EMPLOYEESnn module created in the last exercise.
Adding Module Notes

Select Module from the Note type drop-down box and enter notes in the box
(see Figure A). You can click Apply to save the modules definition.
Figure A. General module notes
Adding Abort Module Notes

Select Abort Module from the Note type drop-down box and enter notes in the
box (see Figure B).
Figure B. Abort module notes
Viewing Notes in the Backlog/History

To test the module, run the module from the Requests window. Go to Explorer
and right-click the job in the History or Backlog to view its notes.
Notes
129
130
Slides
7.7 Output Scanning

Output scans are AppWorx objects used to scan output for text strings that
indicate if a job has failed or succeeded. They are assigned to modules and
program types. Each output scan includes one or more rules.
Some programs can complete executing successfully, but not accomplish their
intended work. For example, an Oracle report may execute correctly, but
return bad data. The only way to tell if the report content is correct is to parse
the report text. Output scans are used for this purpose. Output scans are
AppWorx objects used to scan output for text strings that indicate if a job has
failed or succeeded. They are assigned to modules and program types. If a job
has output scans defined in both its module and program type definitions,
only the modules output scan will be used.
Each output scan includes one or more rules. To use an output scan, you:
Define the output scan object
Add rules to the output scan
Assign the output scan to a module or program type
Figure A. Add rules to create an output scan.
Notes
131
132
Slides
Exercise 7E: Scanning Output

In this exercise, you scan the output from the EMPLOYEESnn module to make
sure it ran correctly.
To test the output scanning function, you will modify your EMPLOYEESnn
module to check for a specific employee name, and abort the module if that
name is found.
What to Do
To test the scanning function:
1.
Create a new output scan object called EMPLOYEESnn.
Figure A. Create an output scan called EMPLOYEESnn.

2.
Create a rule that checks for the name BLAKE, and displays a status
of BAD_EMP if the text is found.
Figure B. Define a rule that searches for BLAKE.
3.
Assign the output scan to your EMPLOYEESnn module in the Output

scan field on the modules General tab.
4.
Employee BLAKE belongs to the SALES department. Run your

EMPLOYEESnn module, selecting SALES as the department.
The module should fail with a status of BAD_EMP.
5.
Now run the module again, this time selecting any department other
than SALES.
The module should complete satisfactorily.
Notes
133
134
Slides
7.8 Notifications
Use notifications to create message files based on job statuses and send those
files to any output device defined in AppWorx. You can use message templates to
create boiler text that can be used in many notifications.
When a job fails, especially in a lights-out operation, you want to be notified.
Using the Notifications feature in AppWorx, you can define notification
messages for a variety of statuses and have AppWorx send out the messages
automatically. The messages can be unique, or you can use message templates
to create boiler text that can be used in many notifications.
Modules, Program Types, and Applications

Notifications are objects you can assign to modules, program types, and
applications. For example, you might create a notification that is sent out
anytime job assigned to the Finance application fails. You can assign multiple
notifications to cover all possible job statuses, each with a unique message.
Figure A. Add Notification details to the notification object to sent message text
based on job status.
Message Templates
When you define a notification, you can enter custom text for that one
notification, or use a message template. A message template is an AppWorx
object that define boiler plate text that can be used with any number of
notifications. The advantage is that you define the text once, then use it
multiple times. Figure B shows the window where you define message
templates.
Notes
Figure A. Add Notification details to the notification object to sent message text
based on job status.
Sending Output
Generally you will want to email notifications. You can enter any number of
email addresses in the Email Recipients field. AppWorx supports the SMTP
email protocol.
You can attach system output files and report output files to the email. You
can also attach files whose names match a pattern that includes % and *
wildcards. For example, enter report% to specify all output file names
beginning with report.
To specify more than one pattern, create additional notifications.
135
136
Slides
Exercise 7F: Sending a Notification (optional)

In this exercise, you define a notification that sends out a message when the
EMPLOYEESnn module aborts.
In the previous exercise, you scanned the output from the EMPLOYEESnn
module and aborted the module if the report contained the employee name
BLAKE. In this exercise, you will set up a notification that is emailed to you if
the module aborts. You will also define a generic failure message template to
use with the notification that provides the name of the module, the job ID, and
the date.
What to Do
First, define the generic failure message template:
1.
On the Object Admin menu, point to Development and select Message

Templates.
2.
In the Message Templates window, click New.
3.
Enter the message text as shown in Figure A below. To enter the

substitution variables and replacement values, click the { } button.
Figure A. Enter the message text.

4.
Save the message template by clicking OK.
Next, set up the notification:

1.
On the Object Admin menu, point to Development and select

Notifications.
2.
In the Notifications selector window, click New.
3.
Set up the notification as shown in Figure B and click Apply.
Figure B. Enter the message text.

4.
Open the Notification Details window by clicking the New button to

the right of the empty table.
5.
Enter the information shown below.
Figure C. Enter the notification detail.

6.
Type your email address in the Email Recipients field.
7.
Save the notification detail by clicking OK.
8.
In the Notifications edit window, save the notification definition by

clicking Apply.
9.
Assign the FAILUREnn notification to the EMPLOYEESnn module.
10. Run the EMPLOYEESnn module using the SALES department.

When the module aborts, it should send you an email with the output
files attached.
11. Check your to see if you received the email.
Notes
137
138
Notes

1.
When a job aborts, what option allows the module to stay in the
Backlog?
___________________________________________________
2.
Must each module have a unique name?

(Yes or No) ________
3.
What information do you enter for a module to tell AppWorx where to

find the program or script to run for a module?
___________________________________________________
___________________________________________________
4.
When you type in a program name for a module, does AppWorx verify
the program exists?
(Yes or No) ________
5.
Modules must pass variables to scripts differently. For example, SQL

scripts pass a name and description, while shell scripts pass only a
description. How does AppWorx differentiate them?
___________________________________________________
___________________________________________________
___________________________________________________
6.
The SQL query for a data type used in an LOV prompt must retrieve
information in what format?
___________________________________________________
___________________________________________________
7.
When you upgrade AppWorx, all objects and scripts that ship with the
product get overwritten. How can you avoid losing any custom changes
you may have made before the upgrade?
___________________________________________________
___________________________________________________
___________________________________________________
8.
Describe one situation where you might want to use output scanning.
___________________________________________________
___________________________________________________
___________________________________________________
Notes
139
140
Lesson 8
Creating Chains
8.1
8.2
8.3
8.4
Introduction to Creating Chains .............................................................................................

Defining Chains and Selecting Execution Options ................................................................
Adding Components to a Chain .............................................................................................
Setting Component Options ..................................................................................................
Exercise 8A: Creating a Basic Chain .................................................................................
8.5 Adding Components Using the Add Buttons .........................................................................
Exercise 8B: Creating a Chain with Parallel Components .................................................
8.6 Creating Component Groups .................................................................................................
Exercise 8C: Creating Component Groups .......................................................................
142
144
146
148
150
152
154
156
158
160
142
Lesson 8: Creating Chains
Slides
8.1 Introduction to Creating Chains

Chains are used to schedule and execute one or more modules and other chains.
Chains transfer the chore of routine maintenance and scheduling from operations
personnel to AppWorx.
In many operations environments, shell scripts are used to run programs. A
shell script or job stream may run a series of programs in a specific order, on
certain days, and under certain conditions. In AppWorx, chains take the place
of shell scripts or job streams. A chain includes one or more chain components
(modules and chains assigned to the chain), general scheduling information
for the chain, specific scheduling information for each chain component, and
conditions that must be met for each component to run. Since a component
can be either a module or chain, AppWorx gives you a great deal of flexibility
in building chains. A chain is shown in Figure A.
Figure A. The Chains window.
Running Chains
There are two ways to run a chain:
Enter scheduling information using the Schedule tab on the Chains
window.
Submit the chain by opening to the Operations menu and selecting
Requests.
999 Components and 32 Levels in a Chain

A chain may contain up to 999 components. A chain can include a chain,
which in turn includes another chain. This is called nesting or sub-chaining.
You can sub-chain to 32 levels. As a rough guide, four levels of sub-chaining is
sufficient for most implementations.
Components in a Chain Point to Original

Chain components are modules and chains assigned to the chain. When you
add a component to a chain, AppWorx creates a pointer to the original module
or chain instead of making a copy. This is in keeping with the AppWorx
object-oriented approach. If you edit a module or chain definition, the update
is effective every where the component is used.
Steps for Creating a Chain

The basic steps for creating a chain are:
1.
Create the chain object.
2.
Set the general and execution options.
3.
Add components to the chain.
4.
Specify options for the components.
5.
Add scheduling information to the chain.
Adding Notes to Chains and Chain Components

Notes provide a place to enter relevant information about the processing of a
job. By selecting an individual job and choosing Notes, operators can access
these comments, suggestions, or instructions. There are two types of notes,
Abort and General. Notes can be formatted in plain text or HTML.
You can enter customizable general and abort notes for modules, chains, and
chain components.
Notes
143
144
Slides
8.2 Defining Chains and Selecting Execution Options

To create a new chain, complete the required fields on the General tab. The
execution options determine what happens when a component runs.
To create a new chain, complete the required fields on the General tab (see
Figure A). The execution options determine what happens when a component
runs.
Figure A. The Chains window.
Default agent
The Default agent field applies only to components in the chain that are
assigned to an agent group with this agent in it. Components assigned to an
agent group will only run on the agent specified in this field if they are not
assigned to an agent on the Components tab.
Queue
Specifies the default AppWorx queue the chain will be submitted to.
Components of this chain will run on their own queue rather than the queue
selected here.
If you want all chain components to run on the chains queue, you must select
the Insert components into chains queue option for the master/local
agent.
If the chain is run using a schedule and that schedule includes a queue, that
setting overrides the chains queue. If the chain is submitted on an ad hoc
basis, the user may have the option to change the queue on the Submit
window.
If you wish to override the queue for an individual component in a chain, you
can add a BEFORE condition using the CHANGE Q action.
Priority
Determines the priority for when this chain gets initiated. This setting
usually isnt crucial. Chains are initiated as soon as they are inserted into the
Backlog and their components priority is based on their module definition.
A chains priority specifies when this chain gets initiated in relation to:
When other chains submitted to this queue at the exact same time get
initiated.
When stand-alone modules waiting in this chains queue run.
The order that chains initiate does not affect the order that their components
run in. It does affect the order that their BEFORE conditions are evaluated (if
they have any).
The top priority setting is 1, and the bottom is 99. The default is 50.
Ave run time

This non-edit field specifies the average run time of the chain (DDD:HH:MI).
This time will be displayed in the Gantt chart.
Single run
When selected, two instances of the chain cannot run concurrently. The
second instance of the chain will wait in a SELF_WAIT job status until the
first completes.
If a module in the chain is defined as single-run, this can prevent the module
from executing in a chain. For example, assume you have chain ABC, and in
that chain you have module XYZ. Module XYZ is single-run. You request
module XYZ and it runs in the Backlog. You then request chain ABC. Module
XYZ in chain ABC will not execute until the first instance of the module
completes executing.
Keep history records

When selected, the system will store the system output from the chain for the
number of days defined in the HISTORY_PURGE module. The output is
useful for debugging jobs that have aborted.
If this option is not selected, AppWorx will not display a record in the History
as long as it completes successfully. If the chain aborts, a record will be
entered in the History.
Note: This applies to the chain record only, not to the components of the chain.
Active
When selected, the chain will run when scheduled and be available from the
Request window. If not selected, the chain will not run when scheduled, and
it cannot be run from the Requests window.
Notes
145
146
Slides
8.3 Adding Components to a Chain

You add components to a chain using the Chains/Modules object selector
window.
For a chain to accomplish work, you must assign one or more components to it.
To add components to a chain, you open the Chains/Modules window shown in
Figure A, select a component, and add it to the chain. AppWorx automatically
creates one or more default success predecessor and successor links depending
on your component selection or placement.
Figure A. Use the Chains/Modules selector window to add components to chains.

To display the Chains/Modules window, click the Chains/Modules selector
window icon
in the menu bar.
Using the Chains/Modules Window

There are several features in the Chains/Modules window that make adding
components easier.
You can select an application from the Application field to display only
components that belong to that application.
If you want more or less items displayed in the Chains/Modules window,
you can resize the widow by dragging the borders.
You can type letters into the Search field to filter the list.
You can select multiple components using the Shift+click and Ctrl+click
key-mouse combinations.
Two Ways to Add Components

There are two methods for adding components to a chain. You can either:
Drag-and-drop single modules and chains from the Chains/Modules
window into the Chain Builder.
Select one or more modules on the Chains/Modules window and add
them to the chain using the buttons at the bottom of the window.
Moving Components Left and Right

You can move components left and right within a row using the < and > buttons
for esthetic purposes.
Navigating Large Chains

To navigate large chains, use the Navigator window shown in Figure C. To
display the Navigator window, click the Navigator button in the menu bar.
From the Navigator window shown in Figure A, select the handle with your
mouse and move it to navigate through the chain. When you move the handle,
a cyan box represents the view of the Chain Builder pane over a silhouette of
the chain.
Figure B. To navigate large chains, use the Navigator window.

You can also use the Find Component function to jump to a specific
component in a chain. Activate this function by opening the Edit menu and
choosing Find Component. AppWorx displays the Find alias window shown
in Figure C where you can enter the name of the component you want to find.
Figure C. Find alias window
Notes
147
148
Slides
8.4 Setting Component Options

After creating a chain, you can set execution options for each component.
After adding components to a chain, you can use the execution options to
control how and where the component executes.
Figure A. The General sub-tab for a chain component.
Activating and Inactivating Chain Components

You can inactivate a chain component with the Component Active box.
Inactive components are displayed with a gray background.
Specifying Component Output Devices

You can specify output devices and options for a chain component on the
Output sub-tab (see Figure B).
Figure B. To specify a printer for a component, click the Output sub-tab.
Specifying Component Prompt Values

When you run a module or chain on an ad hoc basic, you can enter values for
the prompts in the Submit window. For the chain components, you must enter
the values for the prompts from the Prompts sub-tab (see Figure C).
The values for a prompt can be entered directly, or selected from lists. A list
will be available if the data type selected for the prompt includes a SQL
statement. You will be able to select a single value if it is a List-of-Values
(LOV) prompt, or multiple values if it is a multi select (MS) prompt.
Figure C. The chain components Prompts sub-tab.
Notes
149
150
Slides
Exercise 8A: Creating a Basic Chain

In this exercise, you create a basic chain and add two of the modules you created
in the previous lessons.
A chain is made up of one or more modules. In this exercise, you will create a
chain and add two modules:
SLEEPnn
EMPLOYEESnn
Creating the Chain

To create the chain:
1.
Create a chain called BASICnn that looks like the one shown in
Figure A.
Figure A. Creating the BASICnn chain

2.
On the Components tab, add the SLEEPnn and EMPLOYEESnn

modules shown in Figure B.
Figure B. Add the SLEEPnn and EMPLOYEESnn modules to

the chain.
3.
If you wish, enter values for the SLEEPnn and EMPLOYEESnn

modules prompts that are different than the default values.
When you add a module to a chain and the module has prompts, you
must enter the values for the prompts (see Figure C) if default values do
not exist.
Figure C. Enter values for the prompts

4.
Run the chain to make sure it works correctly.
Notes
151
152
Slides
8.5 Adding Components Using the Add Buttons

Adding components to a chain using the add buttons in the Chains/Modules
selector window gives you greater control over the initial predecessor links.
In the previous topic, you saw how to add components using drag-and-drop.
This is a fast way to add components, with AppWorx automatically creating
the predecessor links based on where you drop the components. If you need
greater control over the predecessor links, you will want to use the add
buttons at the bottom of the Chains/Modules selector window.
Figure A. Use the Add buttons for

greater control over predecessor links.
Multiple Selections
When you use drag-and-drop to add components to a chain, you can only add
one component at a time. An advantage to the add buttons is that you can add
many components at one time.
Add Buttons
The Chains/Modules selector window includes four buttons that determine the
predecessor links that AppWorx will create when you add a component to the
chain. Initially, AppWorx creates success predecessor links. You can change
these later if you wish.
Button
Successor
Clone
No preds
External
Description
AppWorx adds the component with predecessor links to all
selected components. If the components selected are in more
than one row, the new component will be placed below the
lowest row.
AppWorx adds the component using the predecessor links
defined for all selected components. If the components selected
are in more than one row, the new component will be placed in
the lowest row and parallel with the objects in that row.
AppWorx adds the components in the upper right corner of the
Chain Builder window in the top row, without any
predecessor links.
AppWorx adds the components to the External References
window with predecessor links to all selected components.
Procedure
To add one or more components to a chain using the add buttons:
1.Select one or more existing components in the chain. If an existing
component does not exist, skip this step.
2.Select one or more components in the Chains/Modules window.
For multiple selections, use the Shift+click and Ctrl+click key-mouse
combinations.
3.Enter the number of copies if more than one.

Multiple copies of a component are added in parallel.
4.Click the appropriate add button: Child, Clone, No preds, or External.

AppWorx adds the components to the chain with default success
predecessor links.
Notes
153
154
Slides
Exercise 8B: Creating a Chain with Parallel

Components
In this exercise, you create a chain with three parallel modules.
By placing components in a chain in parallel, the components can run
simultaneously. In this exercise, you will create a chain and add five instances
of the SLEEPnn module. The first module will run by itself, the next three
modules will run in parallel, and the last module will run by itself. The flow is
illustrated in Figure A.
Module 1
Module 2
Module 3
Module 4
Module 5
Figure A. Parallel chain flow
Creating the Chain

To create the chain:
1.
Create a chain called PARALLELnn.
2.
On the Components tab, add five instances of the SLEEPnn module.
3.
Give each module a unique alias name so you can tell them apart in the
Backlog.
4.
Enter the values for the SLEEPnn modules prompts so that they run
for 30 seconds each.
5.
Run the chain and check the flow.
Notes
155
156
Slides
8.6 Creating Component Groups

Use component groups to logically group components in a chain without creating
a sub-chain.
There may be times when you will want
to logically group components within a
chain without creating a sub-chain. For
example, suppose you wanted to create
the chain flow shown in Figure A.
Job A
Without component groups, the closest

you could come to creating this chain is
shown in Figure B. The predecessor
links are correct, but the arrangement of
the components is not ideal. Figure C
shows the same chain with component
groups. The arrangement is identical to
Figure A.
Component groups are logical groupings
that exist only within a chain. They can
be expanded and collapsed to simplify
diagrams.
Job B1
Job C1
Job B2
Job C2
Job B3
Job D
Figure A. Chain flow with two

parallel streams
Rules Governing Groups

Following are the key rules governing the behavior of groups:
Any number of groups can be added to a chain.
Groups cannot be nested, however you can add a chain that contains
groups to another chain.
You can add and delete components from groups using the same
procedures you use to add and delete components from a chain.
When you add a component to a group using the Chains/Modules
window, you must select a predecessor within the group. You cannot
select the group.
You can drag chain components into and out of a group.
Group position is determined by the predecessor links to components
outside the group.
You cannot assign predecessor links to groups, only to components
within groups.
Groups are saved with the chain.
Collecting Components into a Group

To collect components into a group:
1.
Select the components by doing one of the following:

Click and drag across the components.
Hold down the Ctrl key and click on each component.
Selected components are highlighted with blue borders.
2.
Select Group from the Edit menu.
Notes
Figure B. Parallel flow without

component groups.
Figure C. Parallel flow with component
157
158
Slides
Exercise 8C: Creating Component Groups

In this exercise, you use component groups to organize the components in a
chain.
You want to build a chain that begins with several components that run in
succession, then branches into two parallel streams. At the end of the chain,
there are several modules that once again run in succession. You want to
create this chain without using sub-chains.
The chain should look similar to the chain shown in Figure A, but it does not
have to be identical.
Figure A. Parallel flow with component
What to Do
Create the PARALLEL_FLOWnn chain shown in Figure A. Use the SLEEPnn
module for all components. When you have created the chain, test it to make
sure it runs correctly. Use the Flow Diagram to monitor the chain in Explorer.
Hint: Add the modules one at a time in succession. Then create the groups and
add in the appropriate predecessor links.
Notes
159
160
Notes

1.
If you change a module definition, are the changes automatically made

to that module in all chains?
(Yes or No) ________
2.
List the two ways you can run a chain from the AppWorx client.
______________________________________________________
______________________________________________________
3.
If a chain has the Single run option selected, all modules in the chain
must complete before the next instance of the chain can run.
(True/False) ________
4.
What is the function of component groups?

______________________________________________________
______________________________________________________
______________________________________________________
Notes
161
162
Lesson 9
Adding Dependencies with Predecessors
9.1 Introduction to Predecessors .................................................................................................
9.2 Predecessor Types ................................................................................................................
9.3 Adding Predecessor Links with the Predecessor Definer ......................................................
Exercise 9A: Adding Predecessors with the Pred Definer Window ...................................
9.4 Adding and Editing External Predecessor Links ....................................................................
Exercise 9B: Adding External Predecessors .....................................................................
9.5 Testing Internal Predecessors Links with a Chain Simulation in GAP ..................................
Exercise 9C: Creating a Branching Chain .........................................................................
164
166
168
170
172
174
176
178
180
164
Lesson 9: Adding Dependencies with Predecessors
Slides
9.1 Introduction to Predecessors

Predecessor links are dependencies you add to components in a chain, or to
standalone modules. The simplest and most common form of predecessor links
are automatically created when building chains. Additional predecessor features
allow for greater complexity and versatility.
Predecessor links are dependencies you add to components in a chain, or to
standalone modules. There are two types of predecessors:
Internal: links components within a chain
External: links a component in a chain or a standalone module with
another chain or module.
You can create predecessor links automatically by building chains, or
manually by adding internal or external dependencies for modules, chains,
and chain components.
Figure A. Predecessor links control execution order.

In a chain, predecessor links determine the execution order of the components
in the chain.When creating predecessor links, you determine the predecessor
link type, which specifies its requirement and how it integrates with the other
predecessor jobs.
Automatically Adding Internal Predecessors by Building

Chains
AppWorx relies on predecessor links to determine execution order. By default,
when you add a component to a chain, it is added with an internal success
predecessor link as shown in Figure A.
The components execute as you would expect from looking at the diagram:
execution starts at the top and works down to the bottom. Components in the
same row are eligible to execute at the same time. Internal predecessors that
are added by building chains are the most commonly used and easily
understood predecessors.
Manually Adding Internal Predecessors to Chain Components

After adding components to a chain, you may want to create additional
internal predecessor links within the chain. This is done by manually adding
the links.
Manually Adding External Predecessors to Modules and

Chains
You can also add predecessor links to modules, chains, and chain components
outside the chain. These are called external predecessor links. In Figure A,
there is an external predecessor link to the IMPEXP module. You can create
external predecessor links for a standalone module from the Modules window
and for non-running jobs in the Backlog. When you add external predecessor
links to jobs in the Backlog, the predecessors are only applied to that running
of the job. They do not affect the module or chain definition.
Specifying Predecessor Link Types

There are several types of predecessor links. The Success link is the default
and is acceptable in the majority of cases, but you may want to change the
type. For example, you may want to change the link type to Failure to run a
job when another job fails.
Depending on the predecessor link type, the predecessor link will:
Apply to jobs within a virtual day.
Have no regard for the virtual day.
The only predecessor type that does not take the virtual day into
consideration is the Since Last Run (SLR) type. Since internal predecessors
exist within the same chain, they are by definition, within the same virtual
day. For this reason, the SLR link type is not available for internal
predecessors.
Predecessors are Evaluated Based on the Virtual Day

The virtual workday is a point in time each day that limits how far back
AppWorx will search in the Backlog and History for an external predecessor.
A jobs virtual day is determined by the original start time of that job. The
virtual day is not affected by the following factors:
When the job is inserted into the Backlog.
When the job runs.
Since internal predecessors are always part of the same chain, they are by
definition within the same virtual day and their predecessor requirements are
based on their chain ID. Therefore, understanding the virtual day is only
important to external predecessors. External predecessors (other than SLR)
are constraints within the same virtual day. An external predecessor link is
considered met when the predecessor job is not scheduled to be run in that
virtual day as long as the predecessor has a schedule associated with it. When
jobs are staged, their start time is set to their scheduled start time.
Integrating Multiple Predecessors

When a module, chain, or chain component includes multiple predecessor
links, you decide how they work together using AND/OR logic.
Notes
165
166
Slides
9.2 Predecessor Types

AppWorx provides several different predecessor types that give you flexibility in
controlling how components in a chain are executed.
Predecessor links are critical to the execution of AppWorx chains. To become
proficient at creating chains and adding predecessor links, you will need to
understand how job status impacts the different types of predecessor links.
Predecessor Status Groups

In describing the different types of predecessors, we refer to the status of a job.
Jobs can have a number of different statuses:
The FINISHED status: A status of FINISHED may be displayed briefly in the
Backlog when a job successfully completes its operation. Assuming that the
master is up and running, FINISHED jobs in the Backlog will quickly move to
the History.
Ineligible statuses: Ineligible statuses signify that a job is no longer eligible to
run. Ineligible statuses include: PW-DELETE, PW-SKIP, STG-SKIP,

SKIPPED, CANCELED, DELETED, and INACTIVE. These statuses are
displayed in the Backlog. Some ineligible statuses are displayed in the History
as well.
Failure statuses: Failure statuses signify a job has failed. Failure statuses
include DIED, ABORTED, KILLED, TIMEDOUT, and LAUNCH ERROR.

They may be displayed in the Backlog or History.
Interim statuses: Interim statuses signify that a job has failed. Interim statuses
include: DEAD, ABORTD, KILL, KILL1, KILLING, TIMEOUT, LAUNCH

ERR. They are displayed in the Backlog. Assuming that the master is up and
running, these jobs will quickly move to the History in a Failure status.
Satisfying Each Predecessor Link Type

The requirements for each of a jobs predecessor links to be met are based on
the following link descriptions:
Link type:
Started
Satisfied when:
The predecessor starts or is skipped.
Since last
run (SLR)
The predecessor runs and goes into an ineligible execution status or

FINISHED status since the last time this job ran. This link type is
only available for external predecessors. SLR predecessors are used
when external predecessors need to be evaluated:
Across more than one virtual day.
Multiple times within a virtual day.
Success
(default)
The predecessor runs and goes into an ineligible execution status,

FINISHED status, or is removed from the Backlog (for example a job
aborts and moves from the Backlog because it does not have the Stay
in queue on abort setting selected or the job is deleted from the
Backlog).
The only difference between a Success and Skip on Failure predecessor
is what happens when a job fails.
Success
Only
The predecessor runs and goes into a FINISHED status. This

predecessor can only be used with external predecessors.
Skip on
Failure
The predecessor runs and goes into an ineligible execution status or

FINISHED status. This job is skipped when the predecessor runs and
goes into a failure status. Often used for branching logic.
Failure
The predecessor runs and goes into a failure status.

Link type:
Skip on
Success
Complete
Satisfied when:
The predecessor runs and goes into a failure status. This job is
skipped when the predecessor runs and goes into an ineligible
execution status or FINISHED status.
The only difference between a Failure and Skip on Success predecessor
is what happens when a job fails. Often used for branching logic.
The predecessor runs and goes into an ineligible execution status, a

failure status, or a FINISHED status.
Predecessor links will not be satisfied while the object is still in the Backlog
and the predecessors status goes to an interim failure status. This is because
interim statuses in the Backlog may be changed by conditions. Once a
FINISHED job moves to the History, the predecessor link will be satisfied.
Even after a jobs predecessor links are met, one or more conditions may also
need to be met before the job can run. Or perhaps a condition may take an
action that changes the way a job runs.
Selecting Link Types for External Predecessors to Chains

Success, Complete, and Since last run are the only link types you use when
creating a predecessor to a chain. Success and Complete predecessors are both
satisfied based on the chains completion (when the chain is no longer in an
INITATED status). In neither case does AppWorx take the status of the
components in the referenced chain into consideration. Since last run
predecessors are satisfied based on the chains completion since the last time
the job ran.
Notes
167
168
Slides
9.3 Adding Predecessor Links with the Predecessor

Definer
To define predecessors in large chains, or to add more than one predecessor link
at a time, use the Predecessor Definer window.
If you are working with a large chain, or you want to add more than one
predecessor link at a time, you can use the Predecessor Definer window
shown in Figure A.
Figure A. You can define more than one predecessor at a

time using the Predecessor Definer window.
In Figure A, the FTP module is selected as the From component, and modules
APP0003, APP0004, APP0014, and APP0015 are selected as the To
components. When you click Create predecessors, AppWorx will draw
predecessor links from the FTP module to the four APP modules. You can also
have multiple selections in the From list.
To display the Predecessor Definer window, click the Predecessor Definer
icon
in the menu bar.
To display only the component names in the To modules column as shown in

Figure A, select the Use short name option. When not selected, this column
shows the names of all parent chains for the component.
Notes
169
170
Slides
Exercise 9A: Adding Predecessors with the Pred

Definer Window
In this exercise, you use the Predecessor Definer window to add predecessor
links in a chain.
The development staff has completed creating a set of modules for an
accounting process. They want you to create a chain that executes the
modules in the correct sequence with the required predecessors. They have
given you a list of the modules and their predecessors as shown in the table
below. They did not give you a flow diagram.
Module
Predecessors
JOB_A
JOB_B
JOB_C
JOB_D
JOB_E
JOB_F
JOB_G
JOB_H
JOB_I
JOB_J
JOB_K
none
JOB_A
JOB_B
JOB_B
JOB_C
JOB_D
JOB_D
JOB_F, JOB_E
JOB_G
JOB_H, JOB_K
JOB_I
What to Do
To build the chain using the Predecessor Definer window:
1.
Create a new chain called PRED_DEFINERnn.
2.
Add 11 copies of your SLEEPnn module using the No Preds button in

the Chains/Modules selector window, then enter alias names as shown
in the Module column in the table above.
You can enter alias names as you add the components or after they are
all in the chain.
3.
Open the Predecessor Definer window and define the predecessor links.
Notes
171
172
Slides
9.4 Adding and Editing External Predecessor Links

External predecessor links create dependencies to modules or chains outside the
parent chain.
An external predecessor link connects a module, chain, or chain component to
an external module, chain, or chain component. If you are working with
chains and there is a nested chain in the parent chain, you can create an
external predecessor link for the nested chain, but not for components within
the nested chain. In Figure A, you could create an external predecessor link
for the SIMPLE_CHAIN, but not any of the components within the chain.
Figure A. External predecessor links can be made to stand-alone modules,

chains, or modules and chains within a chain.
Example Use
External predecessor links can be useful in many situations, including the
following: Two application groups in a company have created their own
nightly processing chains. Each groups chain depends on the successful
execution of modules within the other groups chain. To keep the chains in
sync, they create external predecessor links to the components in each others
chains.
External Predecessor Requirements

An external predecessor link for a job will be considered satisfied if neither the
referenced job nor its parent chain is in the Backlog or scheduled to be run
within the virtual workday.
Therefore, a job will wait on an external predecessor if the referenced job is
not currently in the Backlog and it is scheduled to be initiated in the current
virtual day, even if the predecessor had already run previously in the current
virtual day but before the job was eligible to start.
Additionally, the job will not wait to start if the referenced job is not currently
in the Backlog and is not scheduled to be initiated in the current virtual day.
Procedure
To add an external predecessor link:
1.
Open the Chains/Modules window.
2.
Select your module, chain, or one or more components (Shift+Click,

Ctrl+Click) and do one of the following:
Select the External option and click the Add button.
Drag the components into the External Predecessors box.
AppWorx adds the components to the External Predecessor box.
The predecessor requirement can only be satisfied for the referenced
module, chain, or chain component. When you add a predecessor link to
a chain component, it is based on that components lineage. Therefore, a
predecessor to TEST_MODULE in the SAMPLE_CHAIN will not be
resolved by:
TEST_MODULE when it is run in a different chain than
SAMPLE_CHAIN.
TEST_MODULE when it is run by itself outside of the
SAMPLE_CHAIN.
TEST_MODULE when it is run in the SAMPLE_CHAIN and the
SAMPLE _CHAIN is nested in SUPER_CHAIN.
3.
Select the predecessor link type by clicking on the parent component

and doing one of the following:
Open the Predecessor menu and select the type of predecessor.
Right-click and select the type of predecessor.
Press Ctrl+S (to add a Success predecessor).
Note: If you are creating a predecessor link to a chain, you must select
either the Complete or Success type predecessor link. Both of these

options will mean that all of the components in the chain must finish
with any status.
4.
Click on the predecessor component in the External Predecessors

window.
AppWorx draws the predecessor link between the two components.
Virtual Workday
External predecessor links are subject to the constraints of the AppWorx
virtual workday. The virtual workday is a point in time each day that limits
how far back AppWorx will search in the Backlog and History for an external
predecessor. The virtual workday is generally set at the time the product is
installed.
Notes
173
174
Slides
Exercise 9B: Adding External Predecessors

In this exercise, you add several external predecessors to a chain.
In the Data Hungry Company, the data group runs a data collection chain
called, appropriately enough, DATA_COLLECTION.
The Sales department runs a reports chain against the data collected called
STORE_REPORTS. They want to make sure the modules in the
DATA_COLLECTION chain have completed before they run the
corresponding STORE_REPORTS chain. The dependencies are shown in
Figure A.
Figure A. The STORE_REPORTS chain depends on data from the

DATA_COLLECTION chain.
What to Do
1.
Create the STORE _REPORTSnn and DATA_COLLECTIONnn chains

shown in Figure A using TEST_MODULEs.
2.
Open the STORE_REPORTSnn chain and add the

DATA_COLLECTIONnn chain as an external reference.
3.
Add the predecessor links from the STORE_REPORTSnn chain modules

to the appropriate modules in the DATA_COLLECTIONnn chain to
ensure the data modules have completed successfully before the
EASTERN, CENTRAL, and WESTERN modules run.
4.
Run the STORE_REPORTSnn chain first.

Do the modules in the chain show a PRED_WAIT status? ___________
5.
Now run the DATA_COLLECTIONnn chain.

Did all of the modules complete successfully? __________________
Notes
175
176
Slides
9.5 Testing Internal Predecessors Links with a Chain

Simulation in GAP
You can test your predecessors to see how a chain will execute by running a
chain simulation. Chain simulations are part of the Graphical Analysis Package,
an add-on product which can be purchased for AppWorx.
After you have created a chain, you can check to see if the components will
execute in the correct order by running a chain simulation. When you run a
simulation, AppWorx steps through the chain using the predecessor links.
You can run a simulation in Fast or Slow mode. To enhance the simulation,
you can set individual components to fail during the simulation. Chain
simulations are part of the Graphical Analysis Package, an add-on product
which can be purchased for AppWorx.
Figure A. To view a flow of components in a chain, run a

simulation.
Procedure
To run a chain simulation:
1.
If you want a component to fail during the simulation, select the

component, right-click, select Completion code for simulation, and
select Failure.
AppWorx draws a red box around the component.
2.
Open the Simulation menu and choose the speed for the simulation:
Fast or Slow.
The simulation speed can be saved for your workstation by selecting
Save Preferences from the File menu.
3.
To start the simulation, open the Simulation menu and choose Start.
Managing a Simulation
When AppWorx runs a simulation, it highlights each component as it
executes.
If the predecessor links to a failing component are success links, the
simulation will stop at that point in the chain. For the simulation to continue,
you must remove the fail code from the component. To remove the fail code:
1.
Select the failing component and right-click.
2.
Select Completion code for simulation, and select Reset completion

code.
AppWorx continues the simulation.
To end a simulation, open the Simulation menu and select Stop.

To pause a simulation, open the Simulation menu and select Suspend.
To continue a simulation, open the Simulation menu, and select Resume.
Notes
177
178
Slides
Exercise 9C: Creating a Branching Chain

In this exercise, you create a chain that runs one of two modules (programs)
based on the successful or unsuccessful completion of the first module (program).
Assume that you want the successful or unsuccessful completion of a program
to determine which of two other programs will run. For example, if a program
A completes successfully, you want only program B to run. However, if
program A fails, you want only program C to run. The logic is illustrated in
Figure A.
Run Program "A".
W as Program "A"
successful?
No
Run Program "C".
Yes
Run Program "B".
Figure A. Branching logic

To accomplish the branching, you will use predecessor links.
What to Do
Create a chain call BRANCHING_PREDnn with three modules:
PROGRAM_A, PROGRAM_B, and PROGRAM_C. We suggest using the
SLEEPnn module. That will allow you to abort the first module by entering an
alphabetical character for the prompt instead of a number of seconds.
Use the correct type of predecessor link to create the branching logic. Test
your solution.
Notes
179
180
Notes

1.
What is the difference between the Success and Skip on Failure

predecessor types?
______________________________________________________
______________________________________________________
______________________________________________________
2.
When would you use the Since Last Run predecessor link?
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
3.
Why is the virtual workday more important to external predecessors

than internal predecessors?
______________________________________________________
Notes
181
182
Lesson 10
Scheduling Modules and Chains
10.1 Introduction to Scheduling Modules and Chains .................................................................
10.2 Scheduling Basics ...............................................................................................................
10.3 Fiscal Calendar Schedules (optional) ..................................................................................
10.4 Setting Chain Component Eligibility ....................................................................................
10.5 Special Scheduling Features ...............................................................................................
Exercise 10A: Creating Schedules ....................................................................................
10.6 Review Questions ................................................................................................................
184
186
188
190
192
194
196
184
Lesson 10: Scheduling Modules and Chains
Slides
10.1 Introduction to Scheduling Modules and Chains

With AppWorx, you can create schedules to run modules and chains that account
for days of the week, specific days of the month, and days in a calendar.
With AppWorx, you can create schedules to run modules and chains that
account for days of the week, specific days of the month, and days in a
calendar, or hours and minutes in a day.
Figure A. The Schedule tab

A module or chain may have multiple schedules (see Figure A). Each schedule
has four tabs:
General
Frequency
Exceptions
Prompts
Note: Several example schedules are shown in the online help.
Scheduling Behavior After an Outage

AppWorx has built-in logic to recover quickly after a system crash or an
outage. By checking the values of the Start Times and Next Run Date fields
in each module and chain schedule, AppWorx determines when each job
should run next.
If a module or chain should have run during an outage, it will be eligible to
run immediately when the system comes back on line. If a module or chain
should have run several times during an outage, AppWorx runs it once and
returns to its current schedule. If a module or chain is not eligible to run on a
particular day after an outage, but it was scheduled to run on a day during the
outage, it will run immediately after the recovery.
If you do not want missed jobs to run, you can set the Defer schedules on
startup option for the master/local agent. All jobs that would have been
submitted to the master will be skipped without being written to the History.
Notes
185
186
Slides
10.2 Scheduling Basics

Use the General and Frequency tabs to create schedules.
Use the General and Frequency tabs to create schedules.
Entering General Information for Schedules

Use the Schedules General sub-tab to name a schedule and set its start date
and time and execution options (see Figure A).
Figure A. The General sub-tab
Entering Schedule Frequencies

Using the schedules Frequency sub-tab, you can select a unit of time, and
options. The unit you select determines the options that are available (See
Figure B).
Figure B. The General sub-tab
Defining Calendars
Sometimes there are days when information is handled in special ways. In
AppWorx, you can specify these days by creating calendars. You can schedule
modules and chains to run or not run on the days specified by a calendar.
Calendars are useful for specifying a set of dates such as holidays, end of
month processing dates, and end of fiscal quarter processing dates (see
Figure C).
Figure C. To define a calendar, select the days you wish to

include.
Notes
187
188
Slides
10.3 Fiscal Calendar Schedules (optional)

Use fiscal calendars when uniform accounting periods are required through the
year.
A fiscal calendar is a span of 365 days (366 in leap years) during which the
financial activities of an organization are calculated. A fiscal year is divided
into fiscal periods, typically defined as semesters, quarters, or months. A fiscal
calendar can start on any day of the year. Fiscal calendars result in more
uniform accounting periods throughout the year. To use the fiscal calendar
scheduling feature, you must first create a basic fiscal calendar by running
the AW_CREATE_FISCAL_CALENDAR module.
Figure A. Fiscal calendars create uniform accounting periods throughout

the year.
Examples
Fiscal calendar schedules are useful for the following types of scenarios:
Run job XYZ on the last Friday of each fiscal month.
Run job XYZ on the second and fourth Friday of each fiscal month.
Run job XYZ on the last Friday of each fiscal quarter. If Friday is a
holiday, run the job on the prior workday.
Run job XYZ on the last Friday of each fiscal month, except for the dates
included in a Holiday skip calendar. On skip days, run the job on the
prior weekday.
Fields
When you select Fiscal in the Units group box on the Frequency tab, AppWorx
displays the fields shown in Figure A. The fields are described below.
Field
Description
Name
The Name field is used to select the type of fiscal

calendar: 445, 454, 544, 444. This also specifies the
start information, date and day of the week, of the
calendar.
Run Days
The run days specify the days on which the job will
run.

Field
Description
Exception method
The method you select determines how AppWorx will

handle days in a skip calendar.
The options in the Exception method group box
consider Monday through Friday as eligible run days
regardless of the days of the week selected in the Run
days group box. The exception methods will run jobs
only Monday through Friday, never on Saturday or
Sunday.
The Exception method options are described below.
Prior: The job will run on the first week day before
the skip day.
Skip: The job will not run.
Next: The job will run on the next week day.
Closest Workday: The job will run on closest
weekday, either before or after, the skip day.
Period
The periods are the fiscal months. If the 444 fiscal

calendar is used, there will be a 13th period.
Week
The cycles are the weeks in a month. If there is a fifth

week, it is designated by the Last option. If you select
only the Last option, this designates the last week in
the month regardless if it is the fourth or fifth week.
Skip Calendar
The Skip Calendar defines dates on which the job will

not run.
Creating the Basic Fiscal Calendar Schedules

To use the Fiscal Calendar scheduling feature, you must first create the basic
fiscal calendars by running the AW_CREATE_FISCAL_CALENDAR module
shown in Figure B.
Figure B. To use the fiscal calendar scheduling feature, you must first
create a basic fiscal calendar by running the
AW_CREATE_FISCAL_CALENDAR module.
Notes
189
190
Slides
10.4 Setting Chain Component Eligibility

After you have scheduled a chain, you can specify eligibility for components within
the chain.
From the Components tab in the Chains window, you can set the days of the
week a component will be eligible to run. The chain component will be eligible
to run on these days when the chain is scheduled or requested ad hoc (see
Figure A). You can also set the component to run on or skip the days specified
in a calendar.
Figure A. The chain components schedule information
Notes
191
192
Slides
10.5 Special Scheduling Features

Use the Exceptions sub-tab to exclude a regularly scheduled running of a module
or chain. Use the Prompts tab to override the default value for prompts. Use the
Components tab on the Chains window to set the days of the week a component
will be eligible to run within the limits of the chains schedule.
Specifying Exceptions
Using the Exceptions tab, you can exclude a regularly scheduled running of a
module or chain or include additional times.
Figure A. The Exceptions tab
Specifying Prompt Values for Schedules

There may be times when you wish to override the default value for one or
more prompts when a module or chain is called by a schedule. To do this, enter
the new value in the Value column. Different prompt values can be entered for
each schedule.
Figure B. The Prompts tab
Viewing and Editing Days

When you display a calendar, you can add and delete run days and exceptions.
Color codes for the 12 Month Schedule window are described below.
Days displayed with:
Represent:
Gray backgrounds
Yellow backgrounds
Red numbers
Green backgrounds
Black numbers with white backgrounds
Single schedule days

Multiple schedule days
Exclude exception days
Include exception days
Non-scheduled days
To change a single schedule day to an excluded day, or to change a nonscheduled day to an included exception day, click that day. Double-clicking a
day will change all eligible days in that days week.
Notes
Figure C. Displaying a schedule
Generating Calendar Days from the Date Builder Tab

Days to include or exclude in an AppWorx calendar are usually selected by
clicking dates on the General tab of the calendar. However, there may be
times when you want to generate a list of dates for the calendar. You can
generate dates for a calendar from the Date Builder tab on the Calendars
window.
Once you generate a list of dates you can click select additional dates to add or
remove. You can even generate additional dates to include or exclude for the
same calendar. You may want to generate a calendar when:
Dates are not easily scheduled. For example, there are lots of exceptions
or non cyclical dates.
You want to use the same set of dates to as both a run and skip calendar
and you only want to define those dates once.
You create calendars to schedule cyclic jobs out of personal preference.
Figure D. Generate days for a calendar with the Date Builder tab.
193
194
Slides
Exercise 10A: Creating Schedules

In this exercise, you create several schedules.
Below are several schedules. Create a copy of the TEST_MODULE and name
it SCHEDULESnn. Then create the schedules below for the SCHEDULESnn
module. To check the schedules, view them in the 12-month display window.
The instructor may ask you to share your solutions with the class.
Schedule A
Run on Monday, Wednesday, and Friday at 6 A.M.
Schedule B
Run every day, except holidays, at 9:30 P.M.
Schedule C
Run on holidays only, at 11:59 P.M.
Schedule D
Run the first Wednesday after the fifteenth of each month at 11 P.M.
Schedule E
Run weekdays at 8 A.M., 9 A.M., noon, 5 P.M. and 11:45 P.M. Make this
schedule active starting the 1st of next month.
Schedule F
Run at 1:00 A.M. on the 5th workday before the end of each month. In this
case assume your workdays are Monday through Friday.
Schedule G
Run every Monday through Friday at 12:10 A.M, except one week from today.
Do not use a calendar. When run with this schedule, use a default prompt
value of 30.
Notes
195
196
Notes

1.
You can specify eligible run days for a component in a chain.

2.
Calendars can be used for run dates or skip dates in chains, and in chain
components.
3.
How does scheduling information applied to a module definition affect

the module's schedule in chains?
______________________________________________________
4.
If you run a chain from the Requests window, how does that impact the
Next run date set for its schedule?
______________________________________________________
5.
How would you schedule a module to run the last day of every month?
______________________________________________________
______________________________________________________
6.
How would you schedule a chain to run every Monday, Wednesday, and
Friday, and also run every other Tuesday?
______________________________________________________
______________________________________________________
Notes
197
198
Lesson 11
Defining Substitution Variables
11.1 Introduction to Substitution Variables ..................................................................................
11.2 Defining Substitution Variables ............................................................................................
Exercise 11A: Using Substitution Variables in Prompts ....................................................
11.3 Passing Values Through a Chain with Prompts ..................................................................
Exercise 11B: Passing Values through a Chain ................................................................
200
202
204
206
208
210
200
Lesson 11: Defining Substitution Variables
Slides
11.1 Introduction to Substitution Variables

Substitution variables store values that can be used in modules and chains.
Substitution variables let you store values that can be referenced in modules
and chains. The values can be stored in a database table or generated by a
SQL statement at the time a job is submitted. Substitution variables give you
the ability to control operations based on the state of your corporate database.
The Substitution Variable window is shown in Figure A.
Figure A. The Substitution Variables

window.
The ability to include dynamic substitution variables in conditions lets you
control operations based on the state of your corporate database.
Static and Dynamic Substitution Variables

There are two types of substitution variables: static and dynamic. Values for
static substitution variables are entered and stored in a database table before
the module is executed. Values for dynamic substitution variables are
generated by a SQL statement at the time the module is executed. This is the
only difference between static and dynamic substitution variables.
Substitution Variables That Ship with AppWorx

AppWorx ships with a number of substitution variables already defined.
Several examples are listed below.
#current_year
#last_of_month
#day_of_week
#next_monday
#first_of_month
#today
#first_of_last
#tomorrow
#last_of_last
#yesterday
Substitution Variables Evaluate as Strings or Numbers

AppWorx evaluates substitution variables as strings or as numbers based on
the qualifiers you specify within your conditions. Dates can be evaluated as
strings or numbers, but the data type selected in the Type field will affect its
usage. To ensure proper evaluation of dates as numbers, use Julian dates
(dates expressed as the number of days elapsed since January 1, 4713 B.C.) or
a YYYYMMDD format. The maximum return size for a substitution variable
is 512 characters.
Using the { } Brackets

The { } brackets are used to evaluate:
Environmental variables.
Replacement values within a substitution variable.
For example: #job_number={jobid}
Warning! The { } brackets cannot be substituted with [ ] brackets.
Substitution variables written with [ ] brackets will not be evaluated.
Using the Subvar Replacement Values Window

To add a substitution variable or replacement variable to a field that includes
an ... or { } button, click the button next to a field and select a value from the
Subvar Replacement Values window shown in Figure B.
Figure B. The Subvar

Replacement Values
window
Using Numeric Substitution Variables to Pass Values Through

a Chain
You can pass prompt values from a chain to its components. As you add
prompts to a chain, AppWorx numbers them sequentially. You can then add
numeric substitution variables to your chain components that reference the
chains prompts. The values can be used in one or more of the components:
prompts
conditions
aliases
Using chain prompts and numeric substitution variables, you enter values in
one place and automatically use them in one, several, or all of the components
of a chain.
The numeric substitution variables are written with a pound sign followed by
the chains prompt number (for example, #1, #2, #3......#99). They are specific
to their chain and not defined on the Substitution Variables window.
Notes
201
202
Slides
11.2 Defining Substitution Variables

To define a substitution variable, select New on the Substitution Variables
selector window.
Values for static substitution variables are entered and stored in a database
table before the module is executed. Values for dynamic substitution variables
are generated by a SQL statement at the time the module is executed. This is
the only difference between static and dynamic substitution variables.
Defining Static Substitution Variables

Static substitution variables are stored in a database table and retrieved at
the time a job is executed. Static variables are generally used for sending
information between modules. The information is usually about module status
(for example: successful completion, aborted) or information about a module
(for example: file name). A static substitution variable is shown in Figure A.
Figure A. Static variables are stored in a

database and retrieved at the time a job is
executed.
Defining Dynamic Substitution Variables

Dynamic substitution variables (DSVs) are evaluated at the time a job is
executed. A SQL statement generates the value for the DSV. You use DSVs in
conditions to evaluate the state of your corporate database and to control
execution of a module in a chain. For example, you can check for the number
of rows in a table, and delay the module if the count is less than 50. A dynamic
substitution variable that returns the date of the first day of the month is
shown in Figure B.
Figure B. Dynamic substitution variables

use SQL statements to generate values.
Notes
203
204
Slides
Exercise 11A: Using Substitution Variables in

Prompts
In this exercise, create modules that use substitution variables to add values to
the default fields in their prompts.
In this exercise, you will create three modules that run reports against the
AppWorx job history table. The reports and their matching program names
are shown in the table below.
Module Name
Description
Program Name
REPORT_BATCHnn
REPORT_MODULEnn
REPORT_REQUESTORnn
Lists all jobs by queue

Lists all jobs by module
Lists all jobs by requestor
report_batch.sql
report_module.sql
report_requestor.sql
Each report has been written to accept start date and end date values. When
you create the modules, you will define prompts that let users enter the start
and end dates. You will use substitution variables to provide default values
for the dates.
Creating the Modules

To create the report modules:
1.
Create a module called REPORT_BATCHnn to run the report_batch.sql

program.
2.
Select a database login ID for the module.
3.
From the Prompts tab, create two prompts for the start and end dates
using the values shown below.
Field
Start Date Prompt Values
End Date Prompt Values
Data type
Description
Variable name
Default value
Dates
Enter start date:
job_start_date
#yesterday
Dates
Enter end date:
job_end_date
#today
4.
Submit the module from the Requests window to make sure the report
runs correctly.
5.
Create the other two reports and define their prompts.

Note: You can use the Copy button on the Modules selector window
copy the REPORT_BATCHnn module to create the other two modules.
Alternately, you can copy prompts from another module from the
Prompts tab.
Creating the Chain

To create the chain that runs the three reports you just created:
1.
Create a chain and name it REPORTSnn.
2.
Add the three report modules to the chain in parallel so they will be
processed faster.
3.
Run the REPORTSnn chain.
Notes
205
206
Slides
11.3 Passing Values Through a Chain with Prompts

To pass values through a chain, add prompts to the chain and enter numeric
substitution variables in its modules
You can pass values from a chain to its modules. The values passed to a chain
come from prompts added to the chain. You can define up to 99 values. The
values can be used in prompts, conditions, and aliases. By using prompts, the
user can enter values in one place and have them automatically used in one,
several, or all of the modules in a chain.
The numeric substitution variables #1, #2, #3......#99 are the link between the
chain and its components. As you add prompts to the chain, AppWorx
numbers them sequentially. When you add modules to the chain, you use the
numbers assigned to the prompts in the chain in the module prompt fields and
conditions.
Figure A shows an example of a chain called ACCOUNTING_CHAIN. The five
prompts in the chain allow the user to enter an accounting period, the first
and last days of the accounting period, and a region and department.
AppWorx stores these values in substitution variables #1, #2, #3, #4, and #5.
These values are passed to the modules REPORT_A, REPORT_B, and
REPORT_C in the ACCOUNTING_CHAIN by entering the appropriate
substitution variable. In the module REPORT_A, the value for the last day of
the period is also used in a condition. The statement checks to make sure the
current day is after the last day of the period. If it is not, the report is aborted.
REPORT_A also uses the date substitution variable from the First day of
period prompt as its alias.
Prompt values can be used in any combination in any number of modules. For
example, REPORT_C uses only prompts #4 and #5. You also can mix
numbered prompts with other types of prompts.
Note: You can also use this method to pass values from a chain to additional
chains nested within it.
Notes
Figure A. You can pass values to modules in a chain using numbered

substitution variables.
207
208
Slides
Exercise 11B: Passing Values through a Chain

In this exercise, you edit the REPORTSnn chain and its components to accept
start and end dates passed through the chain.
Adding Prompts to the REPORTSnn Chain

To add prompts to the REPORTSnn chain:
1.
Create prompts for the start date and end date using the values shown
below.
Field
Start Date Prompt Value
End Date Prompt Value
Data type
Description
Variable name
Default value
Dates
Enter start date:
(leave blank)
#yesterday
Dates
Enter end date:
(leave blank)
#today
A variable name is not needed because the prompt values are passed to
an AppWorx module, not to a program.
2.
Check the Value required and Allow changes fields.
Modifying the Components

For each of the components in the REPORTSnn chain (REPORT_BATCHnn,
REPORT_MODULEnn, and REPORT_REQUESTORnn), enter the following
values for the prompts:
Prompt
Enter start date:

Enter end date:
Value
#1
#2
#1 and #2 tell AppWorx to use the values from the first and second prompt of
the chain.
Testing the Numbered Substitution Variables

To test the numbered substitution variables:
1.
Open the Requests window and call up the REPORTSnn chain.
2.
Accept the default values for the prompts, or enter different dates.
3.
Submit the module.
4.
Monitor the status of the jobs in Explorer.
5.
When the jobs complete, view the output from the three reports and
verify the correct dates were passed to each of the modules.
Notes
209
210
Notes

1.
What AppWorx object can you use in a condition statement to query a

database?
______________________________________________________
2.
Dynamic substitution variables must return a single value from a

database.
3.
Why might a module's default prompt value using a dynamic

substitution variable be different each time the module is run?
______________________________________________________
______________________________________________________
______________________________________________________
4.
When numeric substitution variables (#1, #2, etc.) are entered as

prompt values for chain components, what are they referencing?
______________________________________________________
______________________________________________________
______________________________________________________
5.
What is the difference between a substitution variable and a

replacement value?
______________________________________________________
______________________________________________________
Notes
211
212
Lesson 12
Working with Conditions
12.1 Introduction to Conditions ....................................................................................................
12.2 How AppWorx Processes Conditions ..................................................................................
12.3 Adding, Editing, and Deleting Conditions ............................................................................
12.4 Condition Types ...................................................................................................................
12.5 Condition Actions .................................................................................................................
12.6 Condition Action Timings .....................................................................................................
Exercise 12A: Checking the Time Since a Request ..........................................................
Exercise 12B: Killing a Component that is Taking too Long to Execute ............................
Exercise 12C: Checking the Number of Records in a Database Table .............................
Exercise 12D: Creating a Menu Using Prompts ................................................................
Exercise 12E: Checking for a File ......................................................................................
Exercise 12F: Spanning Midnight ......................................................................................
214
216
218
220
222
224
226
228
230
232
234
236
238
214
Lesson 12: Working with Conditions
Slides
12.1 Introduction to Conditions

Conditions control the execution of modules and chains. They can apply to
modules, chains, or chain components. Conditions can be evaluated before,
during, and after a job executes, or after a job is deleted. You can add, update, or
delete conditions for the particular running of a job from the Backlog.
Conditions are a powerful tool for controlling the execution of jobs. A module
with several conditions is shown in Figure A.
Figure A. Conditions are a powerful tool for controlling job execution.

Using conditions, you can do such things as:
Check the current time and put a job on hold if it is later than 5 A.M.
Check if a file exists, and if it does not, wait 15 minutes and check again.
Run the second module if the first module in a chain completes
successfully. Run the third module if the first module aborts.
Conditions can apply to modules, chains, or chain components. By adding
conditions to chain components, you can use a module differently in several
chains, or even the same chain. You can also add, edit, or delete conditions for
non-running jobs in the Backlog. When you do this, the changes are particular
only to that running of the job.
AppWorx can evaluate the conditions assigned to a module before, during, and
after the module executes, and after a module is deleted, depending on the
timing in the conditions definition. Conditions are not evaluated until the
module is submitted and displayed in the Backlog. This includes conditions
that are evaluated before a module executes. This means all components in a
chain are displayed in the Backlog regardless of the conditions assigned to
them.
When a test defined in a condition is met, AppWorx takes the action defined in
the condition. AppWorx includes a number of actions. If you want to take more
than one action based on an event, you create multiple conditions, each with
the same test but different actions.
Using Your Corporate Database to Control Operations

One of the more powerful features of AppWorx is the ability to control
operations based on the content of your corporate database. By using dynamic
substitution variables in conditions, you can make decisions based on such
data as:
The number of records in a table
The total dollars represented by receivables
The date a database was last updated
Using Module/Chain Conditions for Chain Components

You can use the conditions defined for modules or chains when adding them to
a chain. To do this, select the Use module conditions option for the chain
components.
The USER DEFINED Condition

To enter a text string, substitution variable, or replacement value as your
condition values, select the USER DEFINED condition. You can use the
USER DEFINED condition to take an action every time a module is run by
entering 1=1 in the Test box as shown in Figure B.
Figure B. The USER DEFINED condition.
Bad Conditions
If AppWorx evaluates a bad condition (for example a condition with a bad SQL
statement) it will ignore the condition and report it to the masters log file.
The modules status will be set to BAD CONDITN.
Notes
215
216
Slides
12.2 How AppWorx Processes Conditions

AppWorx processes conditions before, during, and after a module runs, and after
a job is deleted.
The flowchart in Figure A shows the evaluation cycle AppWorx applies to each
jobs BEFORE conditions. An evaluation cycle consists of working through the
flowchart in Figure A until the Run job or End processing step is reached.
AppWorx runs through the evaluation cycle for a job until it completes
executing and is moved to the History, or until it aborts. AppWorx evaluates
all conditions in the order they are listed with the following exceptions:
If a condition runs a job, AppWorx ignores the remaining BEFORE
conditions for that job.
If a condition stops the evaluation cycle, all remaining conditions are
ignored for the current cycle. For example if a condition puts a module
on hold, all remaining conditions will be ignored until the next cycle.
If you use the GOTO CONDITION action, the destination condition
must come after the condition containing the GOTO action.
Running BEFORE Conditions

When AppWorx is ready to execute a job, it evaluates its BEFORE conditions.
By default, a job will run unless one of the BEFORE conditions modifies its
eligibility.
Running DURING Conditions

While a job is running, AppWorx evaluates its DURING conditions. The
frequency that AppWorx evaluates DURING conditions is based on The
DURING_WAIT variable setting.
When the master has no processing to do, it sleeps for the number of seconds
entered in the Sleep time field for its local agent. At the end of each sleep
cycle, the master evaluates the DURING conditions.
When the master is processing, it checks the DURING conditions. The
frequency that it checks them is based on the setting for the DURING_WAIT
variable in your awenv.ini file, located in the site folder. You can modify the
setting; the default is 60 seconds.
Setting a low DURING_WAIT value may impede performance without
evaluating conditions more frequently.
If a job completes executing in a shorter amount of time than the setting for
the DURING_WAIT variable, its DURING conditions may not execute.
Running AFTER Conditions

After a job completes executing successfully or unsuccessfully, AppWorx
evaluates all AFTER conditions. If a job is killed, AFTER conditions are still
evaluated.
Running DELETED Conditions

If a job is deleted by a user, AppWorx processes DELETED conditions and
skips any AFTER conditions associated with the given module.
Notes
Start
Is there a condition that

has not been evaluated?
No
Run job
Yes
No
Is the condition true?
Yes
Take action and set

'action taken' flag.
Yes
No
Does the action

stop processing?
Yes
End processing
Figure A. How AppWorx processes conditions
217
218
Slides
12.3 Adding, Editing, and Deleting Conditions

To add, edit, or delete conditions for a module, chain, or chain component, select
that objects Conditions tab and click New, Edit, or Delete.
You can include conditions for modules, chains, or chain components. The
Conditions tab for a module is shown in Figure A.
Figure A. The Conditions tab displays the conditions for a module.
Taking More Than One Action for an Event

You can define only one action for each condition. If you want to take more
than one action based on the same event, create multiple conditions with
different actions and set the condition order on the Condition tab. If one
condition takes an action that cancels the task or chain, be sure it is the last
one in the related group.
Killing All Components in a Chain

Selecting a KILL TASK action for a DURING condition on a chain will kill all
running components of the chain.
Defining a Substitution Variable with a Condition

To define a substitution variable with a condition, choose the SET SUBVAR
action as shown in Figure B. Enter the name of the substitution variable, an
= sign, and the value to be assigned to the variable. The name must start
with a # sign, cannot contain blanks, and can be up to 20 characters long. Do
not put spaces around the = sign.
Notes
Figure B. Static substitution variables can be defined in a

condition.
Timing
Use the Timing field in the Condition Details window to control when
AppWorx checks for a condition, and which conditions are available. The
timing options are described below.
Option
Description
BEFORE
The condition is evaluated before the module/chain executes.
DURING
The condition is evaluated every time the master checks the

Backlog queue (about once a minute) while the module/chain
is executing.
AFTER
The condition is evaluated after the module/chain executes,

even if it aborts or is killed.
DELETED
If a module/chain is DELETED, the conditions on the

DELETED module will be evaluated. This differs from an
AFTER condition. AFTER conditions are not evaluated for a
DELETED job.
219
220
Slides
12.4 Condition Types

The values available for the Condition field are described below.
The values available for the Select Condition field are determined by the
Timing option you select. The condition you select determines the fields
displayed in the Test box based on. The values available for the Select
Condition field are described in the table below. The letters in the Timing
column stand for the following: BBefore, DDuring, AAfter, and RDelete.
Condition
USER DEFINED
Timing
BDAR
Description
Provides two Test fields, separated by a qualifier.
You define the condition by entering text strings or
numeral substitution variables, or use the ... button
to select substitution variables/replacement values.
You can use the USER DEFINED condition to

take an action every time a module is run by
entering 1=1 in the Test box.
CHECK FILE*
BDA
Checks if the file named in the File Name field does

or does not exist based on maximum file age,
minimum unchanged time (stability), and/or
minimum file size on the agent where the module is
running. Wildcards and environment variables are
allowed if the file name is enclosed in double quotes.
The first line of the last file found by CHECK

FILE is stored in the replacement value {file-line}.
You might use the {file-line} replacement value in
a later condition to check whether the file included
a text based error code and set the jobs status
accordingly if it did.
Important! You must put quotes around the file
name.
CHECK
HISTORY*
(two options)
Success
Failure
BDA
Checks for the status of a module in the History

within the last days, hours, and minutes. Use the
Alias when referring to chain components. The
condition is evaluated as true if:
Success is selected and the module has a status of
FINISHED.
-or Failure is selected and the module has a status of
DIED, ABORTED, KILLED, or TIMEDOUT.
If the module is not found, the condition is evaluated
as false.
CHECK
PROCESS
BDA
Checks if another process is running on the agent

where the module is running.
CURRENT
QUEUE*
BR
Provides the value for the current queue definition.
CURRENT
TIME*
BDAR
The current time in the format HH:MM:SS.
MODULE
REQUESTED*
Checks if a module has been requested and is in the

Backlog.
MODULE
RUNNING*
Checks if a module is in a running state in the

Backlog.
RETURN
CODE*
Reads the return code generated by the program.
RUN TIME*
The wall clock time since the module started

running.

Condition
STATUS*
Timing
A
Description
Usually used to check whether a jobs status is equal
to FINISHED. This allows you to check if the current
module completed successfully.
TIME SINCE
REQUEST*
BDAR
Elapsed wall clock time between the time the module

was requested and the current time. Useful for
checking how long a job has been waiting in the
Backlog.
*System function.
Notes
221
222
Slides
12.5 Condition Actions

When a condition is true, AppWorx can take a variety of actions. Some of the
actions require that you enter additional information.
The values available for the Action field are listed in the table below. The
action values are determined by the selected Timing option. In the table the
letters in the Timing column stand for the following: BBefore, DDuring,
AAfter, and RDelete.
Action
ABORT TASK*
Timing
BA
Description
Aborts the current module. Also see the SET ABORT
STATUS action.
CANCEL
CHAIN*
BDA
Cancels all remaining non-running components in the

chain, plus any components in its parent and child
chains.
Note: This action should only be assigned to chain
components. Do not assign it to modules or chains
that run outside of a chain.
CANCEL
SUBCHAIN*
BDA
Cancels all remaining non-running components in the

chain that this chain component is a member of. It
does not cancel components assigned to chains which
are the parent of this components chain.
Note: This action should only be assigned to chain
components. Do not assign it to modules or a top level
chain.
CHANGE Q*
BD
Changes the queue for this job. Changing queues does

not affect the chain execution order. The The first
time the condition is true radio button must be
selected for this action or the job will never start.
Switching the queue in the Backlog will not disengage
a component from its chain.
DELAY TASK*
Delays for a number of hours, minutes, and seconds

before the job is run. HH:MM:SS format. The time
delay begins when the condition is checked.
DELETE
SUBVAR
BDAR
Deletes a substitution variable (or substitution

variables when wildcards are used).
EXTRACT
VALUE
BDAR
Scans text and sets a subvar based on the results.
GOTO
CONDITION
BDA
Skips to a condition by number. Destination condition

must follow the condition containing the GOTO
action.
Note: The GOTO number is not re-sequenced when a
condition is moved.
HOLD TASK*
Changes the modules status to HOLD. Also see the

SET HOLD STATUS action.
KILL TASK*
Changes the modules status to KILL.
REQUEST
MODULE
BDAR
Select the Details button to select a module and set

its options.
RESCHEDULE
TASK*
The time of day to reschedule the task today.

HH:MM:SS format. If a time earlier than current is
entered, the module will run as soon as possible.
RESTART ON
ABORT
BDA
Set or reset the modules restart on abort attribute.

This action does not alter the module definitionit
affects the particular module in the particular chain.

Action
RUN HOST
COMMAND
Timing
DAR
Description
Runs an operating system host command with
arguments on the agent of the module (for example cp
file1 file2). For more information, see your OS
documentation.
RUN TASK*
Runs the task. Any remaining Before conditions are

ignored.
SEND JMS
MESSAGE
BDA
Select the Details button to specify a JMS message to

send.
SEND
NOTIFICATION
BDA
Sends a notification via email or output device using

an AppWorx notification object.
SET ABORT
STATUS*
Sets module status to ABORTED and displays custom

text as status name. Allows for a maximum of 12
characters.
SET FINISHED
STATUS*
Set module status to FINISHED and display custom

characters.
SET HOLD
STATUS*
Sets module status to HOLD and displays custom text

as status name. Allows for a maximum of 12
characters.
SET SKIP
STATUS*
Sets module status to SKIPPED and displays custom

characters.
SET SUBVAR
BDAR
Creates a static substitution variable. To create a

unique substitution variable for a chain, include the
{chain_id} or {chain_seq} replacement value. To create
a unique substitution variable for a module, include
the {jobid} replacement value.
SKIP TASK*
Sets the modules status to SKIPPED. Also see the

SET SKIP STATUS action.
STAY IN
QUEUE ON
ABORT
BDA
Sets or resets the modules Stay in queue on abort

attribute. This action does not alter the module
definitionit affects the run of the particular module
in the particular chain.
WAIT UNTIL
MET*
Causes the job to pause until the condition is met. In

other words, the wait action is taken each time the
condition is FALSE.
*Stops processing module conditions for the current evaluation cycle and will
not start the job this evaluation cycle.
223
224
Slides
12.6 Condition Action Timings

You determine if the action will be taken the first time the condition is true, every
time the condition is true, or if the condition should be disabled.
AppWorx evaluates conditions for a module at least every 59 seconds.
However, you select how often the action for each condition should be taken by
selecting a radio button from the Action Timing box as shown in Figure A. So,
even though a condition may be evaluated multiple times, the action may be
taken only the first time the condition is true.
Figure A. Select an action timing for a condition.

The action timing radio buttons are described in the table below.
Option
The first time the
condition is true
Description
AppWorx only initiates the specified action the first time the
condition is true and changes its action timing to Disabled.
After that, AppWorx skips the condition.
You might use this option for a condition that notifies an
operator when a module has failed. If there are events that
cause the condition to be evaluated as true a number of times,
AppWorx wont send out a new message every time.
Every time the

condition is true
AppWorx initiates the specified action every time the

condition is true.
This setting is used often with the DELAY TASK action. For
example, you might use this option if you want module Y to
execute only after another module X has completed. You
could check for the status of module X, and if it has not
completed, use the DELAY TASK action to delay module Y by
15 minutes. You would want to use the delay each time the
condition is true.
Disabled
AppWorx will skip the condition.

You might use this option if you write a condition, but do not
want to activate it.
Note: The action timing for conditions with The first time
the condition is true selected will change to Disabled in the
Backlog/History for the running of a job when the action is
taken.
Notes
225
226
Slides
Exercise 12A: Checking the Time Since a Request

In this exercise, you create a condition that checks how long a job has been
waiting in the Backlog.
You may want to cancel a module if it does not run within a certain amount of
time after it was submitted. For example, if you have scheduled a job to run at
a specific time, and other jobs depend on successful execution of the job, you
may want to set up conditions that cancel the dependent jobs.
What to Do
1.
Create a chain called TIME_SINCEnn with two SLEEPnn modules that

run one after the other.
2.
Set the first module to run for 60 seconds.

Use the Alias field to give each module a unique name. For example
60_SECONDS_TESTnn.
3.
Use a condition to skip the second module if it has been waiting in the
Backlog for more than 30 seconds.
4.
Run the chain to see if the second module skipped.
5.
Change the run time of the first module to 5 seconds and test the chain
again. This time, the second module should run.
Notes
227
228
Slides
Exercise 12B: Killing a Component that is Taking

too Long to Execute
In this exercise, use condition statements to cancel a chain if a module in the
chain runs for longer than 60 seconds.
You generally know how long it should take a module to complete executing.
Some modules may take only a few minutes, while others may take several
hours. If a module has been executing for longer than expected, it usually
indicates a problem that requires operator attention.
You can use condition statements to check how long a component has been
running. If the component runs too long, you can cancel the remaining
components in the chain, and kill the module.
What to Do
1.
Copy the chain TIME_SINCEnn that you created in the previous

exercise. Rename the new chain ABORTnn.
2.
Modify the new chain so the first module runs for 300 seconds, and
change the modules alias.
3.
Use a condition on the first module to cancel the remaining module in

the chain if the first module runs longer than one minute.
4.
Use another condition statement on the first module to kill the first
module if it runs longer than one minute.
5.
The second module in the chain has a condition statement that is no

longer needed. Remove it.
6.
Check to see that the condition statements work, and that the second
module ends up in History without running.
After a minute or two, the first module should go into a KILLED status
and remain in the Backlog. The second module should go be canceled.
Notes
229
230
Slides
Exercise 12C: Checking the Number of Records in a

Database Table
AppWorx gives you the ability to control job execution based on the information in
your database.
Assume you have written a program called employees that runs statistics on
the employees in your company. You want to make sure the employees
program runs only if there are 18 or more employees listed in the company
database. If there are less than 18 employees, skip the task. The list of
employees is stored in the EMP table.
What to Do
To check the number of employees and take an action:
1.
Add conditions to the EMPLOYEESnn module you created earlier so

that it runs only if there are 18 or more employees listed in the EMP
table. You will want to use the #count_employees substitution variable
which has already been defined for you. The variable includes a SQL
statement that counts the records in the EMP table for all departments.
Note: It does not matter how many employees are in the department you
select. The substitution variable counts the number of employees in all
departments.
2.
Check the condition by running the module.
3.
After running the module, open the #count_employees substitution

variable (see Figure A). Select the Check SQL button to see how many
employees are listed in the EMP table. Did the module run the way you
would expect it to?
Figure A. Substitution variable used to count the

number of rows in a database table.
Notes
231
232
Slides
Exercise 12D: Creating a Menu Using Prompts

Let end users select the reports they would like to run.
What to Do
In an earlier exercise, you created a chain called REPORTSnn that lets end
users enter start and end dates for a series of reports.
In this exercise, your challenge is to use what youve learned about prompts,
substitution variables, and conditions to enhance the REPORTSnn chain to
let end users choose any combination of the three reports they want to run.
Requirements
Your chain must meet the following requirements:
Keep the start and end date prompts in the REPORTSnn chain.
Add prompts to the REPORTSnn chain that let end users choose the
reports they want to run.
Test Your Solution

After you have worked out a solution, test the solution to make sure it works.
Notes
233
234
Slides
Exercise 12E: Checking for a File

In this exercise, you use a condition to check for the exist of a file before running a
module
Before running a certain module, you want to check for the existence of a file.
You cannot do this with a predecessor. Instead, you must use a CHECK FILE
condition.
What to Do
1.
Make a copy of your SLEEPnn module and call it CHECKFILEnn.
2.
Add a BEFORE condition to the module that checks for the XYZ file in
the sql subdirectory in the AppWorx home directory before it runs. The
XYZ file does not exist.
Use the DELAY TASK action instead of the WAIT UNTIL MET action
to conserve computing resources. Why does the DELAY TASK action
conserve resources?
____________________________________________________________
____________________________________________________________
3.
Test your module. Did it run?

____________________________________________________________
4.
In AppWorx Explorer, edit the BEFORE condition, changing the file

name to employees.sql. This is a standard file that ships with AppWorx.
5.
Check to see if your module runs.
Notes
235
236
Slides
Exercise 12F: Spanning Midnight

In this exercise, you schedule a chain so the modules span midnight
You are working for Company ABC. You have to create a chain that collects
sales data just before midnight, then posts the data to a ledger just after
midnight. For financial reasons, the posting must take place after midnight.
The chain will consist of two modules: the first module collects the data, the
second module posts the data. You will simulate these modules using the
TEST_MODULE.
What to Do
1.
Create a chain called SALESnn.
2.
Add two SLEEPnn components to the chain and change their view
names to DATA_COLLECTnn and DATA_POSTnn. Create a
predecessor from DATA_POSTnn to DATA_COLLECTnn.
3.
Schedule the chain to run at 11:30 P.M. each evening including

Saturday and Sunday.
4.
Figure out how to ensure that the DATA_POST module runs as close to
midnight as possible.
Notes
237
238
Slides

1.
What happens to conditions you define for a module when you add the
module to a chain?
______________________________________________________
______________________________________________________
2.
At what stages in the life cycle of an executing job can the condition
statements be checked?
______________________________________________________
______________________________________________________
3.
Say you have a chain that runs several times a day. In that chain you
have a component that should only run before 2:00 A.M. To set this up,
you only need to define a single condition. Why wouldnt you need to
define a condition to run the job before 2:00 A.M. and a second condition
to skip it after 2:00 A.M.?
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
4.
You are using a condition to kill a job if it runs longer than 10 minutes.
You've selected the First time... action option. What will happen if the
job runs longer than 10 minutes, is killed, and you reset the job and it
runs longer than 10 minutes again?
______________________________________________________
______________________________________________________
______________________________________________________
5.
If you kill a running job, the AFTER conditions are still processed.
6.
In terms of computing resources, which is more efficient: a WAIT

UNTIL MET action or a DELAY TASK action? Why?
______________________________________________________
______________________________________________________
______________________________________________________
7.
When using the STATUS condition to check for failed jobs, why is it
usually better to check for STATUS != FINISHED than STATUS =
ABORTD?
______________________________________________________
______________________________________________________
______________________________________________________
Notes
239
240
AppWorx 7.0 Basic Training Evaluation Form

Please indicate your level of confidence in performing the following tasks.
Task
Very
Confident
Confident
Not
Confident
N/A
Request and submit a module.
_____
5
_____
4
_____
3
_____
2
_____
1
____
View the output from a job online.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Monitor a job and reset it if it aborts.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Stage jobs for the next 24 hours.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Create a module that runs a program.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Add a fill-in prompt to a module.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Add a list-of-values (LOV) prompt to a module.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Create a chain and add several modules to it.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Combine several modules in a chain into a group.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Schedule a chain to run every Monday, Wednesday,

and Friday at 5:00 P.M.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Define a calendar and run a chain based on the days

in the calendar.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Use substitution variables to control the execution of

modules in a chain.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Pass prompt values from a chain to the modules in

the chain.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Add a predecessor to a module in chain so the module

begins execution only after another job outside the
chain has finished successfully.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Add a condition to a module in a chain that requires a

specific file to exist before the module will execute.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Add a condition to a module that aborts the module if

it has not run 30 minutes after being submitted.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Send an email notification if a module aborts.
_____
5
_____
4
_____
3
_____
2
_____
1
____
Please indicate the extent to which you agree or disagree with the following statements describing the course.
Statement
Very
Confident
Confident
Not
Confident
The course was well organized.
_____
5
_____
4
_____
3
_____
2
_____
1
The instructor knew the subject matter.
_____
5
_____
4
_____
3
_____
2
_____
1
The instructor gave clear and concise answers to questions.
_____
5
_____
4
_____
3
_____
2
_____
1
The classroom facilities were satisfactory.
_____
5
_____
4
_____
3
_____
2
_____
1
The Student Guide was well written and easy to use.
_____
5
_____
4
_____
3
_____
2
_____
1
The exercises were useful and reinforced the concepts

covered in class.
_____
5
_____
4
_____
3
_____
2
_____
1
Comments/Suggestions
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
Other Information
Your name (optional): __________________________________
Company name: __________________________________
Date: __________________________________

AppWorx 7 0 Basic Oper and Dev Student Guide Content

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

AppWorx 7 0 Basic Oper and Dev Student Guide Content

Încărcat de

Drepturi de autor:

Formate disponibile

AppWorx 7.

AppWorx Basic Training

2475 - 140th Avenue NE

Basepoint Business & Innovation Centre, Unit 1

AppWorx 7.0 Basic Operations and Development Student Guide

Lesson 2 Requesting Jobs ................................................................................................... 25

Lesson 3 Monitoring and Managing Agents and Queues .................................................. 37

Lesson 4 Viewing Forecasts and Production Schedules................................................... 49

Introduction to Viewing Forecasts and Production Schedules ......................................................... 50

Lesson 5 Monitoring and Managing Jobs ........................................................................... 59

Introduction to Monitoring and Managing Jobs ................................................................................ 60

Lesson 6 Graphical Analysis Package (optional) ............................................................... 87

Introduction to the Graphical Analysis Package............................................................................... 88

6.6 Viewing an Historical Gantt Chart.................................................................................................... 98

Lesson 7 Creating Modules.................................................................................................109

Lesson 8 Creating Chains ...................................................................................................141

Introduction to Creating Chains ..................................................................................................... 142

Lesson 9 Adding Dependencies with Predecessors ........................................................163

Lesson 10 Scheduling Modules and Chains......................................................................183

Lesson 11 Defining Substitution Variables........................................................................199

AppWorx 7.0 Basic Operations and Development Student Guide

11.3 Passing Values Through a Chain with Prompts........................................................................... 206

Lesson 12 Working with Conditions .................................................................................. 213

AppWorx 7.0 Basic Training Evaluation Form ................................................................... 241

1.1 Course Overview

AppWorx User Forum

AppWorx 7.0 Basic Operations and Development Student Guide

1.2 Introduction to AppWorx

Why Use AppWorx?

Pinpointing problems in a job stream, and restarting a job stream at any

AppWorx 7.0 Basic Operations and Development Student Guide

Balancing system load using AppWorx schedules, queues, and agent

Running AppWorx on UNIX and Windows platforms

Controlling job stream execution based on the state of your corporate

1.3 AppWorx Is Object-Oriented

Figure A. Objects are combined to define modules and chains.

Chains (Job Streams)

AppWorx 7.0 Basic Operations and Development Student Guide

1.4 AppWorx Architecture

Figure A. AppWorx architecture

AppWorx 7.0 Basic Operations and Development Student Guide

1.5 Using the AppWorx Desktop

Figure A. The AppWorx desktop.

AppWorx 7.0 Basic Operations and Development Student Guide

Closing All Windows or Selector Windows

Customizing Tables in AppWorx Windows

Customizing Job Status Colors

1.6 Using Explorer

Figure A. Object keys can be opened on the Explorer window to focus on

Select this icon:

All jobs in the Backlog.

Filter menu and selecting Filter Backlog and History.

AppWorx 7.0 Basic Operations and Development Student Guide

1.7 Adding, Editing, and Deleting AppWorx Objects

Figure A. Selector window

Figure B. You can open selector windows with the

Searching for Objects

Filtering Modules and Chains by Application

Adding, Editing, and Deleting Objects

AppWorx 7.0 Basic Operations and Development Student Guide

Viewing Object References

Figure C. To view all references for an object, click Usage

Figure D. To copy any AppWorx object, select the object

Exercise 1A: Modifying Your User Settings

Exercise 2A: Running a Module from the Requests