Workflow Developers Guide
55
Workflow Developer’s Guide
-
Upload
jay-saji-kulathakal -
Category
Documents
-
view
244 -
download
4
description
SAP WORKFLOW
Transcript of Workflow Developers Guide
-
Workflow
Developers
Guide
-
ii
Workflow
Developers
Guide
-
Contents
Chapter
1.
Preparing
to
write
a
workflow
1
Chapter
2.
Tutorial:
Creating
a
new
workflow
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
Sample
workflow:
Cisco
Turn
Port
ON
.
.
.
.
. 6
Workflow
development
standards
.
.
.
.
.
.
. 7
Workflow
naming
conventions
.
.
.
.
.
.
. 8
Variable
naming
conventions
.
.
.
.
.
.
.
. 8
Describing
transitions
and
variables
.
.
.
.
. 8
Chapter
3.
Creating
a
workflow
using
a
text
editor
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
Chapter
4.
Querying
the
data
center
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Retrieving
data
from
the
dcm
.
.
.
.
.
.
.
. 13
Inserting
data
in
the
dcm
.
.
.
.
.
.
.
.
.
. 14
Updating
data
in
the
dcm
.
.
.
.
.
.
.
.
. 15
Deleting
data
from
the
dcm
.
.
.
.
.
.
.
.
. 15
Retrieving
properties
of
a
dcm
object
.
.
.
.
.
. 15
Inserting
properties
into
the
dcm
.
.
.
.
.
.
. 16
Updating
the
properties
of
a
dcm
object
.
.
.
.
. 16
Deleting
the
properties
of
a
dcm
object
.
.
.
.
. 16
Data
center
model
query
language
syntax
.
.
.
. 17
Reading
dcm
query
language
expressions
.
.
. 17
Chapter
5.
Conditional
and
looping
statements
.
.
.
.
.
.
.
.
.
.
.
.
. 21
if...then
statements
.
.
.
.
.
.
.
.
.
.
.
. 21
if...then...else
statements
.
.
.
.
.
.
.
.
.
. 21
foreach
statements
.
.
.
.
.
.
.
.
.
.
.
. 22
while
statements
.
.
.
.
.
.
.
.
.
.
.
.
. 22
Chapter
6.
Error
handling
.
.
.
.
.
.
. 23
try...catch...catchall...finally
statements
.
.
.
.
. 23
throw
statements
.
.
.
.
.
.
.
.
.
.
.
. 24
Chapter
7.
Creating
scripts
.
.
.
.
.
. 25
Chapter
8.
Displaying
workflow
references
.
.
.
.
.
.
.
.
.
.
.
.
. 27
Chapter
9.
Editing
workflow
properties
29
Chapter
10.
Adding
and
managing
workflow
transitions
.
.
.
.
.
.
.
.
. 31
Adding
a
new
transition
to
the
workflow
.
.
.
. 31
Editing
transition
properties
.
.
.
.
.
.
.
.
. 31
Mapping
a
command
variable
.
.
.
.
.
.
.
. 31
Removing
a
transition
.
.
.
.
.
.
.
.
.
.
. 31
Chapter
11.
Adding
and
managing
workflow
variables
and
parameters
.
. 33
Adding
a
new
variable
.
.
.
.
.
.
.
.
.
. 33
Mapping
a
variable
.
.
.
.
.
.
.
.
.
.
.
. 33
Removing
a
variable
mapping
.
.
.
.
.
.
.
. 33
Deleting
a
variable
.
.
.
.
.
.
.
.
.
.
.
. 34
Chapter
12.
Running
workflows
.
.
.
. 35
Stopping
a
workflow
that
is
running
.
.
.
.
.
. 35
Chapter
13.
Importing
workflows
.
.
. 37
Chapter
14.
Exporting
workflows
.
.
. 39
Chapter
15.
Displaying
workflow
run
history
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Exporting
workflow
run
history
logs
.
.
.
.
.
. 41
Chapter
16.
Displaying
the
run
history
for
an
individual
workflow
.
.
.
.
.
. 43
Chapter
17.
Troubleshooting
workflows
45
Chapter
18.
Creating
an
automation
package
.
.
.
.
.
.
.
.
.
.
.
.
.
. 47
Step
1:
Create
the
appropriate
directory
structure
.
. 47
Step
2:
Export
the
Oracle
9i
workflow
XML
file
.
. 47
Step
3:
Export
the
shell
scripts
.
.
.
.
.
.
.
. 47
Step
4:
Create
the
tc-driver.xml
file
.
.
.
.
.
. 47
Step
5:
Copy
and
install
the
driver
.
.
.
.
.
. 48
Automation
package
development
standards
.
.
. 48
Naming
your
automation
package
.
.
.
.
.
. 48
Creating
your
tc-driver.xml
file
.
.
.
.
.
.
. 49
Creating
automation
package
documentation
.
. 50
iii
-
iv
Workflow
Developers
Guide
-
Chapter
1.
Preparing
to
write
a
workflow
A
workflow
template
can
be
used
as
a
starting
place
in
building
the
workflows
needed
for
your
data
center.
Using
your
workflow
template
you
can
define
the
order
sequence,
any
pre-requisites
that
should
be
reviewed,
determine
the
exact
intent
of
the
workflow
and
understand
any
limitations
that
are
inherent
with
it,
and
define
any
input
and
output
variables
that
you
may
require.
Templates
save
time
and
increase
the
precision
of
your
design.
Your
workflow
template
should
detail
the
order
of
operation,
but
also
highlight
the
potential
limitations
that
are
involved
with
this
action.
A
sample
workflow
template
may
look
like
this:
Table
1.
Sample
workflow
template
Step
Description
Determine
order
sequence
Determine
the
sequence
of
events
to
gather
the
inputs
required
to
run
the
workflow.
This
includes
calls
for
data
from
the
Data
Center
Model
(DCM).
For
each
workflow,
it
is
necessary
to
determine
the
variables
(and
their
order)
that
will
be
passed
from
the
user
interface.
You
must
then
derive
any
associated
inputs
from
this
initial
set
of
inputs.
For
an
example
of
how
this
is
done,
see
the
Cluster.Remove
Server
template
below.
Pre-requisite
checks
Determine
if
all
the
key
inputs
and
target
resources
for
a
given
workflow
are
correct
and
available
before
proceeding.
For
example,
if
the
workflow
requires
the
use
of
a
software
installation
server,
first
check
to
see
if
that
server
is
available.
This
step
is
necessary
because
it
is
difficult
to
run
a
workflow
to
a
point
of
failure
and
try
and
recover
at
that
stage.
Make
sure
that
targets
are
available
after
you
run
a
workflow.
For
example:
v
If
you
install
an
operating
system
on
a
server,
create
a
superuser,
password,
and
a
default
route
so
Tivoli
Intelligent
ThinkDynamic
Orchestrator
can
still
connect
to
the
new
system.
v
If
you
move
a
port
to
another
VLAN,
then
you
will
want
a
recovery
transition
that
moves
the
port
back
in
case
a
transition
fails
in
the
middle
of
a
workflow.
1
-
Table
1.
Sample
workflow
template
(continued)
Standard
template
for
recovery
Determine
an
appropriate
recovery
method
for
your
new
workflow.
Currently,
Tivoli
Intelligent
ThinkDynamic
Orchestrator
uses
a
recovery
method
workflow.
To
use
a
recovery
method
at
the
parent
workflow
level:
1.
Set
a
servers
state
to
maintenance.
2.
Move
the
server
out
of
a
associated
cluster
and
back
to
the
its
resource
pool.
3.
Notify
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
administrator.
Although
this
is
a
standard
operation,
it
does
not
apply
to
all
situations,
for
example,
recovery
actions
in
workflows
against
a
network
device.
Network
devices
are
typically
shared
so
any
recovery
action
will
typically
be
an
undo
of
what
was
performed.
Another
example
is
a
recovery
action
against
a
free
pool.
In
this
case,
the
resource
should
be
flagged
and
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
administrator
should
be
notified.
Template
example:
Cluster.Remove
Server
Logical
Operation.
Outlines
the
operations
required
to
remove
server
resources
from
a
cluster.
Table
2.
Template
example:
Cluster.Remove
Server
Logical
Operation
Transition
Description
Get
Current
Deployment
Request
Id
Data
gathering
phase
Get
Cluster
Attributes
Data
gathering
phase
Get
Pool
Attributes
Data
gathering
phase
Get
VLAN
Attributes
Data
gathering
phase
Pre-requisite
checking
Using
information
from
the
data
gathering
phase,
validate
that
the
key
components
in
the
workflow
are
available
for
use.
In
this
workflow,
an
example
would
be
the
software
server
responsible
for
uninstalling
the
software
products
defined
in
the
stack,
and
the
existence
of
the
ACL
IDs
to
enable
on
the
target
firewall.
RM
Choose
Server
for
Removal
Resource
Manager
to
select
a
random
allocated
server
from
application
cluster
(dedicated
servers
will
not
be
affected).
Get
Server
Attributes
Get
the
server
attributes,
such
as
NICID,
to
use
in
subsequent
transitions.
Get
NIC
Attributes
Get
the
properties
of
the
NIC.
Get
Real
IP
Attr
by
Network
Interface
Get
the
IP
address
of
the
Network
Interface
Get
Software
Stack
for
Device
Determine
the
software
stack
associated
with
the
server
LoadBalancer.Rmv
Real
IP
from
Virtual
IP
Remove
the
servers
real
IP
address
from
the
VIP.
SoftwareStack.Uninstall
Remove
the
software
products
associated
with
the
stack.
RM
Allocate
Ip
Address
Get
next
available
IP
address
for
subnet
of
VLAN.
IPSystem.Add
IP
Address
Add
IP
to
DCM.
IPSystem.Apply
Routing
Table
Update
the
routing
table.
Switch.Move
Port
to
VLAN
Move
server
from
resource
VLAN
to
production
VLAN.
SNMP
Ping
Verify
that
unmanaged
interface
can
still
be
reached.
2
Workflow
Developers
Guide
-
Table
2.
Template
example:
Cluster.Remove
Server
Logical
Operation
(continued)
Update
SAPs
for
Group
of
Servers
Update
the
service
access
points
for
the
server.
Related
information
Workflows
Workflow
composer
Chapter
8,
Displaying
workflow
references,
on
page
27Workflow
references
include
all
the
data
center
objects
associated
with
the
selected
workflow,
as
well
as
any
other
workflows
that
reference
it.
Chapter
9,
Editing
workflow
properties,
on
page
29
Chapter
10,
Adding
and
managing
workflow
transitions,
on
page
31
Chapter
12,
Running
workflows,
on
page
35
Chapter
11,
Adding
and
managing
workflow
variables
and
parameters,
on
page
33
Chapter
13,
Importing
workflows,
on
page
37
Chapter
15,
Displaying
workflow
run
history,
on
page
41
Chapter
16,
Displaying
the
run
history
for
an
individual
workflow,
on
page
43
Chapter
17,
Troubleshooting
workflows,
on
page
45
Chapter
1.
Preparing
to
write
a
workflow
3
-
4
Workflow
Developers
Guide
-
Chapter
2.
Tutorial:
Creating
a
new
workflow
The
objective
of
this
tutorial
is
to
create
a
simple
workflow
that
will
display
the
contents
of
a
current
working
directory
using
the
ls
-l
command.
Prerequisites:
1.
Create
a
server
representing
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
server.
The
server
name
must
be
the
same
as
the
return
value
from
hostname.
2.
This
server
must
be
configured
for
an
execute-command
service
access
point
(SAP).
Note:
The
above
requirements
should
have
already
been
done
as
part
of
your
Tivoli
Intelligent
ThinkDynamic
Orchestrator
installation.
To
add
a
new
workflow:
Important:
It
is
very
important
during
workflow
development
that
you
compile
your
workflow
consistently
to
save
it
in
the
database.
To
compile
your
workflow,
select
Compile
Compile
.
Step
1:
Create
a
new
workflow
1.
Click
System
configuration
and
workflow
management
Workflows.
2.
On
the
All
Workflows
page,
click
Edit
Add
Workflow.
The
Workflow
Composer
is
displayed.
3.
Click
Edit
Properties
and
type
a
new
name
for
your
workflow.
4.
Click
Locale
Insensitive
if
you
do
not
want
to
specify
a
particular
locale.
If
a
locale
has
been
specified,
a
workflow
will
fail
if
the
target
device
for
the
workflow
does
not
match
the
locale.
5.
Click
Edit
Save.
Step
2:
Retrieve
the
device
ID
of
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
host
server.
This
workflow
will
run
a
command
on
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
host.
For
that
to
happen,
the
Deployment
Engine
will
search
for
the
name
of
the
host
on
which
it
is
running
and
will
search
for
a
server
device
ID
of
that
same
name.
To
configure
a
transition
to
do
this,
click
Java
Plug-ins.
1.
Select
the
Get
Deployment
Engine
Device
ID
and
drag-and-drop
the
plug-in
to
your
workflow.
2.
Next
to
the
No
operation
transition,
click
Delete
transition.
3.
Click
EditSave.
Step
3:
Create
a
local
variable
for
the
servers
device
ID.
When
we
retrieve
the
device
ID
from
the
deployment
engine,
we
need
a
variable
to
hold
that
value.
To
do
this:
1.
Drag-and-drop
the
variable
element
to
your
workflow
space.
2.
Click
Edit
Properties.
3.
Create
a
new
variable
called
DeviceID
and
click
Save.
4.
Expand
the
Get
Deployment
Engine
Device
ID
Java
plug-in.
5.
Drag
the
DeviceID
variable
and
drop
it
in
the
Value
field.
Step
4:
Create
a
transition
to
run
the
ls
-l
command
1.
Expand
Logical
Devices.
2.
Expand
Device
3.
Select
Execute
Command
and
drag-and-drop
the
logical
device
operation
to
your
workflow.
5
-
4.
You
now
need
to
create
local
variables
for
the
ls
-l
command
and
the
working
directory.
The
ExecuteCommand
and
WorkingDirectory
variables
are
required
variables
in
the
Device.Execute
Command
transition,
so
local
variables
must
be
created
for
them.
To
do
this,
drag-and-drop
the
variable
element
to
your
workflow
space.
5.
Click
Edit
Properties.
Sample
workflow:
Cisco
Turn
Port
ON
Lets
examine
an
existing
workflow
in
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
product
for
a
better
understanding
of
how
a
workflow
is
constructed
and
runs.
We
will
assume,
for
this
example,
that
a
workflow
for
this
operation
does
not
exist
and
we
will
need
to
create
it.
The
Cisco
Turn
Port
ON
workflow
when
run
will
turn
a
port
associated
with
a
Cisco
switch
on.
To
do
this,
we
need
to
follow
five
basic
steps:
1.
Acquire
the
switch
ID
associated
with
the
Cisco
switch
and
the
port
number
that
we
want
to
turn
on.
2.
Lock
the
switch.
When
you
turn
a
port
on,
the
switch
should
not
be
accessible
so
that
it
is
not
interfered
with
while
you
are
changing
its
status.
3.
Change
the
port
status
from
OFF
(shutdown)
to
ON
(active).
4.
Save
the
current
configuration.
5.
Unlock
the
switch.
Step
1:
Create
a
new
workflow
1.
Click
System
configuration
and
workflow
management
Workflows.
The
Workflow
Composer
is
displayed.
2.
Click
Edit
Properties
and
type
a
new
name
for
your
workflow.
3.
Click
Edit
Save.
When
prompted,
click
Save.
Step
2:
Define
parameters
for
the
switch
ID
associated
with
the
Cisco
switch
and
the
port
number
that
we
want
to
turn
on.
At
this
point,
we
can
start
to
build
our
workflow
using
the
workflow
build
components
of
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator.
1.
Expand
your
new
workflow
and
drag-and-drop
two
parameter
elements
to
your
workflow
build
space.
2.
Click
Edit
Properties.
3.
Rename
the
first
parameter
SwitchID.
4.
Rename
the
second
parameter
PortNumber.
5.
Click
Edit
Save.
When
prompted,
click
Save,
Step
3:
Lock
the
switch.
The
switch
should
not
be
accessible
while
its
status
is
changing.
To
do
this:
1.
Expand
Java
plug-ins.
2.
Drag-and-drop
the
Lock
DCM
Object
and
Unlock
DCM
Object
Java
plug-ins
to
your
new
workflow.
Note:
The
optimal
method
to
work
with
other
workflows,
while
still
having
your
new
workflow
in
view,
is
to
open
your
new
workflow
first
in
the
right-hand
pane,
and
use
the
navigation
tree
to
find
and
work
with
other
workflows
and
Java
plug-ins.
3.
Expand
the
Lock
DCM
Object
transition
and
drag-and-drop
the
SwitchID
parameter
to
the
Value
field
in
the
DCM
Object
ID
parameter
row.
4.
Expand
the
Unlock
DCM
Object
transition
and
drag-and-drop
the
SwitchID
parameter
to
the
Value
field
in
the
DCM
Object
ID
parameter
row.
5.
Delete
the
No
operation
transition.
6.
Click
Edit
Save.
When
prompted,
click
Save,
6
Workflow
Developers
Guide
-
Step
4:
Add
a
transition
to
change
the
port
status
from
OFF
to
ON
1.
Expand
Java
plug-ins.
2.
Locate
the
Cisco
Change
Port
Status
Java
plug-in.
3.
Drag-and-drop
this
plug-in
to
your
new
workflow
so
that
it
appears
as
the
second
transition
in
your
workflow.
4.
Expand
the
Cisco.ChangePortStatus
transition.
5.
Drag-and-drop
the
SwitchID
parameter
to
the
Value
field
in
the
Device
ID
parameter
row.
6.
Drag-and-drop
the
PortNumber
parameter
to
the
Value
field
in
the
Port
Number
parameter
row.
7.
Click
Edit
Properties
in
the
New
Port
Status
row.
8.
Type
On
as
the
new
value
and
click
Save.
9.
Click
Edit
Save.
When
prompted,
click
Save,
Step
4:
Add
a
transition
to
save
your
new
port
configuration
1.
Expand
Java
plug-ins.
2.
Locate
the
Cisco
Save
Configuration
Java
plug-in.
3.
Drag-and-drop
this
plug-in
to
your
new
workflow.
4.
Expand
theCisco.SaveConfiguration
transition.
5.
Click
Edit
Properties
in
the
Device
ID
row.
6.
Drag-and-drop
the
SwitchID
parameter
to
the
Value
field
in
the
Device
ID
parameter
row.
7.
Click
Edit
Save.
When
prompted,
click
Save,
To
run
this
workflow,
click
Build
Compile.
Related
information
Workflows
Workflow
components
Chapter
1,
Preparing
to
write
a
workflow,
on
page
1
Chapter
3,
Creating
a
workflow
using
a
text
editor,
on
page
9
Chapter
4,
Querying
the
data
center
model,
on
page
13
Chapter
8,
Displaying
workflow
references,
on
page
27Workflow
references
include
all
the
data
center
objects
associated
with
the
selected
workflow,
as
well
as
any
other
workflows
that
reference
it.
Chapter
9,
Editing
workflow
properties,
on
page
29
Chapter
10,
Adding
and
managing
workflow
transitions,
on
page
31
Chapter
12,
Running
workflows,
on
page
35
Chapter
11,
Adding
and
managing
workflow
variables
and
parameters,
on
page
33
Chapter
13,
Importing
workflows,
on
page
37
Chapter
15,
Displaying
workflow
run
history,
on
page
41
Chapter
16,
Displaying
the
run
history
for
an
individual
workflow,
on
page
43
Chapter
17,
Troubleshooting
workflows,
on
page
45
Data
center
model
query
language
syntax
on
page
17
Workflow
development
standards
The
following
development
standards
are
recommended
when
creating
workflows:
Chapter
2.
Tutorial:
Creating
a
new
workflow
7
-
Workflow
naming
conventions
Tivoli
Intelligent
ThinkDynamic
Orchestrator
has
two
fields
that
identify
individual
workflows:
v
A
name
field
that
is
a
maximum
of
40
characters
in
length
v
A
description
field
that
is
a
maximum
of
2000
characters
in
length1.
It
is
recommended
that
workflows
are
named
using
a
common
syntax.
The
following
syntax
is
suggested:
__on/at/in/from/to/using_
Note:
For
example:
Add_IP_address_to_virtual_server.
If
your
transition
does
not
fit
this
template,
ensure
that
it
is
descriptive
enough
to
explain
the
intention
of
the
transition,
such
as
Concatenate_the_source_path_and_
operating_system_strings.
2.
The
words
that
are
used
should
be
short
and
use
terminology
that
is
commonly
applied
in
that
specific
domain.
3.
Use
consistent
terminology.
For
example,
copy,
get,
acquire,
retrieve
could
all
potentially
apply
to
the
same
action.
Use
only
one
of
these
terms
across
all
similar
workflows.
Variable
naming
conventions
Use
the
following
convention
when
naming
variables:
v
The
first
character
is
lowercase.
For
example,
destination
v
Use
a
continuous
string
without
punctuation
or
white
space.
v
Concatenate
and
capitalize
all
component
words
within
variable
names.
Do
not
connect
the
component
words
with
an
underscore.
For
example,
DeviceName.
Describing
transitions
and
variables
All
transitions
and
variables
need
to
be
described
appropriately
in
their
respective
Description
fields
so
that
the
intention
of
the
transition,
variable,
and
workflow
as
a
whole,
can
be
understood.
Related
information
Workflows
Workflow
composer
Chapter
8,
Displaying
workflow
references,
on
page
27Workflow
references
include
all
the
data
center
objects
associated
with
the
selected
workflow,
as
well
as
any
other
workflows
that
reference
it.
Chapter
9,
Editing
workflow
properties,
on
page
29
Chapter
10,
Adding
and
managing
workflow
transitions,
on
page
31
Chapter
12,
Running
workflows,
on
page
35
Chapter
11,
Adding
and
managing
workflow
variables
and
parameters,
on
page
33
Chapter
13,
Importing
workflows,
on
page
37
Chapter
15,
Displaying
workflow
run
history,
on
page
41
Chapter
16,
Displaying
the
run
history
for
an
individual
workflow,
on
page
43
8
Workflow
Developers
Guide
-
Chapter
3.
Creating
a
workflow
using
a
text
editor
There
are
two
options
that
you
can
use
to
create
a
new
workflow.
You
can
use
the
web-based
user
interface,
or
you
can
write
your
workflow
in
any
text-based
editor
and
import
the
workflow
into
Tivoli
Intelligent
ThinkDynamic
Orchestrator.
Important:
It
is
very
important
during
workflow
development
that
you
compile
your
workflow
consistently
to
save
it
in
the
database.
To
compile
your
workflow,
select
Compile
Compile
.
1.
Open
a
text-based
editor
and
write
your
workflow.
2.
Type
a
name
for
the
workflow
with
the
following
naming
convention:
workflow
3.
Type
LocaleInsensitive
if
you
are
not
concerned
with
a
particular
locale.
If
a
locale
has
been
specified,
a
workflow
will
fail
if
the
target
device
for
the
workflow
does
not
match
the
locale.
To
check
a
device
locale,
refer
to
the
following
example:
workflow
test
var
v
=
Jython("en_US")
var
deviceId
=
Jython(5)
CheckDeviceLocale
deviceId
v
CheckDeviceLocale
deviceId
"fr_FR"
4.
Type
the
contents
of
your
new
workflow.
Refer
to
the
example
below
and
the
looping
and
conditional
statements,
and
dcm
queries
for
more
information.
workflow
DCM_Insert
LocaleInsensitive
var
server_id
=
"1018"
var
vlan1
=
"222"
var
vlan2
=
"700"
#1084
1086
DCMInsert
EOINSERT
DCMInsert
EOINSERT
DCMInsert
9
-
EOINSERT
DCMInsert
-
Chapter
17,
Troubleshooting
workflows,
on
page
45
Data
center
model
query
language
syntax
on
page
17
Chapter
3.
Creating
a
workflow
using
a
text
editor
11
-
12
Workflow
Developers
Guide
-
Chapter
4.
Querying
the
data
center
model
Using
the
dcm
query
language,
you
can
query
the
dcm
database
and
have
a
result
set
returned.
To
query
the
dcm
and
obtain
attributes
associated
with
a
physical
or
logical
asset:
1.
On
the
Workflows
page,
select
DCM
Query.
2.
Drag-and-drop
the
Variable
element
to
your
workflow
build
space.
This
variable
will
hold
the
value
that
will
be
returned
from
your
dcm
query.
3.
Click
Edit
Properties
and
rename
the
variable.
Click
Save.
4.
Drag-and-drop
the
DCM
Query
element
to
the
row
that
contains
your
new
variable
in
the
workflow
build
space.
5.
Click
the
DCM
Query
element
in
your
workflow.
6.
In
the
Value
field,
type
your
dcm
query.
7.
Click
Save.
A
dcm
query
supports
select,
insert,
update,
and
delete
actions.
When
a
workflow
that
contains
a
dcm
query
successfully
completes
a
requested
change
to
the
data
center,
the
data
center
model
is
updated
to
reflect
the
current
data
center
infrastructure.
Note:
Only
one
attribute
of
a
dcm
object
can
be
retrieved
at
a
time.
Refer
to
the
following
topics
for
more
information
on
the
proper
syntax
to
use
when
creating
your
query.
Retrieving
data
from
the
dcm
To
retrieve
data
from
the
dcm,
use
the
DCMQuery
command
as
shown
in
the
examples
below:
v
To
retrieve
all
NIC
IDs
that
have
a
server
name
of
Nile
and
that
are
not
managed:
DCMQuery
(/server[@name="Nile"]/nic[@managed="N"])
v
To
retrieve
all
the
server
names,
ordered
alphabetically
by
name,
in
the
RiversEdge
cluster:
DCMQuery
(/cluster[@name="RiversEdge
Web"]/server/@name[orderBy@name])
v
To
retrieve
the
server
name
in
the
RiversEdge
cluster
using
a
variable
($serverName)
that
had
been
previously
defined
in
a
workflow:
DCMQuery
(/cluster[@name="RiversEdge
Web"]/server[@name=$serverName])
Note:
v
Some
objects
have
two
fields
that
link
to
another
object.
For
example,
accessRule
has
sourceSubnetwork
and
destinationSubnetwork
attributes.
To
navigate
from
accessRule
to
a
subnetwork
use:
accessRule/sourceSubnetwork,
or
accessRule/destinationSubnetwork
instead
of
accessRule/subnetwork.
For
example:
DCMQuery(/acl[@name="acl-1
New1"]/accessRule/sourceSubnetwork/@ipaddress)
v
A
relationship
between
two
dcm
objects
can
be
navigated
using
a
dcm
query
in
two
directions.
For
example:
/server[@name=\"Server1\"]/bladeadminserver
or,
bladeadminserver
[@name=\"Blade1\"]/server
13
-
Aliases
are
used
to
differentiate
between
relationships.
For
example,
in
the
query
below,
accessRule
has
two
fields
connecting
to
a
subnetwork:
sourceSubnetwork
and
destinationSubnetwork.
Two
relationships
were
generated
for
this
scenario,
one
for
each
relation
field:
/acl[@name="acl-1
New1"]/accessRule/sourceSubnetwork/@ipaddress
/acl[@name="acl-1
New1"]/accessRule/destinationSubnetwork/@ipaddress
In
order
to
navigate
in
the
opposite
direction,
you
must
use
an
alias
object
to
differentiate
between
the
relationships.
For
example:
/subnetwork[@ipaddress="10.1.8.0"]/AclRuleSource/acl/@name:
Will
link
the
subnetwork
to
the
sourceSubnetwork
field
from
the
accessRule.
subnetwork[@ipaddress="10.1.8.0"]/AclRuleDestination/acl/@name:
Will
link
the
subnetwork
to
the
destinationSubnetwork
field
from
the
accessRule.
Inserting
data
in
the
dcm
When
you
insert
data
into
the
dcm,
it
is
assumed
that
the
object
does
not
already
exist
and
you
are
creating
it
for
the
first
time.
Your
XML
data
consists
of
top-level
and
embedded
elements
and,
consequently,
there
are
two
methods
for
inserting
data
into
the
dcm.
To
insert
data
into
the
dcm,
use
the
DCMInsert
command
as
shown
in
the
examples
below:
Inserting
a
top-level
object:
If
a
top-level
object
is
being
added
to
the
dcm,
the
only
requirement
is
the
DCMInsert
command
and
the
XML
data.
For
example,
to
insert
a
new
blade
server
chassis
that
is
not
managed,
has
a
network
interface
name
of
Management
network,
and
an
IP
address
of
10.1.8.77:
DCMInsert
EOF
Note:
When
you
insert
a
top-level
object
(parent)
into
the
dcm
using
the
web-based
user
interface,
you
do
not
have
to
specify
a
parent
element
in
the
Parent
field.
Inserting
an
embedded
element:
If
a
child
element
is
being
added
to
the
dcm,
you
must
first
retrieve
the
parent
elements
ID
to
determine
the
location
in
the
dcm
where
the
new
data
should
be
added.
In
the
following
example,
the
parent
element
is
Customer,
and
the
DCMInsert
parent
=
DCMQuery(/customer[@name="Rivers
Edge
Retail"])
expression
will
retrieve
the
Customer
ID,
and
using
this
ID,
can
determine
the
precise
location
in
the
XML
that
will
contain
the
new
data.
DCMInsert
parent
=
DCMQuery(/customer[@name="Rivers
Edge
Retail"])
EOF
The
remaining
details
associated
with
this
example:
v
A
new
application
is
added
to
the
Rivers
Edge
Retail
customer
called
Online
Store
New.
v
Together
with
a
new
application,
a
new
cluster
is
being
added
called
RiversEdge
Web,
that
has
a
virtual
IP
of
10.1.1.132,
and
a
virtual
IP
port
of
80,
a
vlan
of
510,
and
belongs
to
the
Apache-RedHat
resource
pool
and
Default
Fabric
switch
fabric.
This
cluster
must
have
a
minimum
of
2
servers
and
a
maximum
of
10.
Note:
You
cannot
define
a
new
service
access
point
without
defining
proper
credentials
(password,
SNMP,
RSA).
This
credential
makes
sense
only
in
the
context
of
a
service
access
point,
as
shown
in
the
following
example:
14
Workflow
Developers
Guide
-
DCMInsert
parent
=
DCMQuery(/terminalServer[@name=\"Console
Server
New1\"])
EOF
Updating
data
in
the
dcm
To
update
data
in
the
dcm,
use
the
DCMUpdate
command
as
shown
in
the
example
below:
DCMUpdate
(/cluster[@name=\"RiversEdge
Web1\"])
EOF
Note:
You
can
only
update
one
object
at
a
time,
so
embedded
objects
cannot
be
updated
at
the
same
time
you
update
a
top-level
object.
Deleting
data
from
the
dcm
To
delete
data
from
the
dcm,
use
the
DCMDelete
command,
as
shown
in
the
example
below:
v
To
delete
a
customer
application
with
a
name
of
Online
Store:
DCMDelete
(/application[@name="Online
Store"])
v
To
delete
a
customer
application
with
an
ID
of
123:
DCMDelete
(/application[@id="123"])
Note:
v
You
cannot
delete
an
object
that
cannot
be
identified
through
a
single
ID
(the
primary
key
is
composed
from
several
fields).
v
You
can
delete
all
properties
for
a
specific
object,
but
you
cannot
delete
a
specific
property
for
an
object.
v
Cascading
delete
is
not
supported
in
the
dcm
query
language.
If
a
dcm
object
that
you
want
to
delete
has
a
relationship
to
other
dcm
objects,
those
objects
must
be
deleted
first.
For
example,
to
delete
a
router
switch,
you
have
to
delete
the
router
first
and
then
the
corresponding
switch.
Retrieving
properties
of
a
dcm
object
The
properties
associated
with
dcm
objects
can
also
be
managed
using
dcm
queries
in
the
workflow
composer.
The
DCMQuery,
DCMInsert,
DCMDelete,
and
DCMUpdate
commands
are
all
supported
when
working
with
the
properties
of
dcm
objects.
To
retrieve
the
properties
of
an
object,
you
must
specify
the
ID
of
the
object
whose
properties
you
want
to
retrieve.
You
can
do
this
using
the
DCMQuery
command
as
shown
in
the
example
below.
COMPONENT_ID
KEY
ID
VALUE
0
snmp.community.read
1234
public
0
snmp.community.write
3333
public
0
tcdriver-version
4444
public
If
your
properties
table
has
the
elements
shown
above,
you
can
retrieve
a
property
value
for
a
given
key:
DCMQuery
(/softwareStack[@id="1234"]/property[@componentId="0"]/@snmp.community.read)
Chapter
4.
Querying
the
data
center
model
15
-
Note:
You
do
not
have
to
specify
the
component
ID.
The
system
assumes
that
the
value
is
0
if
it
has
not
been
explicitly
defined
in
the
query.
For
more
information
on
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
components
and
IDs,
refer
to:
Numeric
representation
of
dcm
components
Inserting
properties
into
the
dcm
Using
the
DCMInsert
command,
you
can
insert
new
properties
by
doing
the
following
steps:
1.
Retrieve
the
ID
of
the
object
that
will
obtain
new
property
values.
For
example,
to
start
building
the
query
to
insert
new
properties
for
a
Windows
2000
Server
software
stack,
type:
DCMInsert
parent
=
DCMQuery(/softwareStack[@name="Windows
2000
Server"])
-
Related
information
Data
center
model
query
language
syntax
Data
center
model
Workflow
composer
Creating
and
managing
workflows
Numeric
representation
of
dcm
components
Data
center
model
query
language
syntax
The
dcm
query
language
uses
an
XPath-like
syntax
to
select
elements
from
the
dcm
database
that
match
the
path.
The
following
is
a
syntactically
valid
dcm
query
language
input:
DCMQuery(/server[@name="Nile"]/nic[@managed="N"])
This
particular
expression
retrieves
the
NIC
IDs
of
a
server
with
a
name
of
Nile
and
whose
network
interface
cards
are
not
managed.
The
ID
value
will
always
be
returned
by
default
unless
another
return
attribute
has
been
explicitly
declared.
Refer
to
Chapter
4,
Querying
the
data
center
model,
on
page
13
for
more
information.
When
you
work
with
the
Workflow
Composer
and
drag-and-drop
the
DCM
Query
element
to
the
workflow
build
space,
you
can
create
a
dcm
query
to
use
with
your
workflow.
All
dcm
queries
must
begin
with
a
command
such
as
DCMQuery,
DCMInsert,
DCMDelete,
or
DCMUpdate.
In
the
expression
above,
server
and
nic
are
examples
of
elements,
while
name
and
managed
are
examples
of
attributes.
They
identify
names
of
tables
and
columns
from
the
database.
Reading
dcm
query
language
expressions
A
dcm
query
language
expression
is
a
slash-separated
list
of
element
names
that
describe
a
path
through
a
relational
database.
It
uses
elements,
attributes,
operators,
and
conditions
that
describe
a
path
through
a
relational
database.
When
you
read
a
dcm
query
expression,
the
far
most
element
on
the
right-hand
side
of
the
expression
is
the
data
that
the
query
expects
to
retrieve.
For
example,
in
the
following
expression:
DCMQuery(/server[@name="Nile"]/nic[@managed="N"])
the
query
will
retrieve
all
of
the
NICs
that
are
not
managed,
and
belong
to
a
server
with
the
name
Nile.
Grammar
notation
The
dcm
query
language
uses
the
Extended
Backus-Naur
Form
(EBNF)
for
grammar
notation.
EBNF
is
a
set
of
rules
that
describe
a
specific
fragment
of
syntax
If
you
can
reduce
a
document
to
a
single
rule
with
no
further
input,
it
is
considered
valid.
The
following
table
describes
the
dcm
query
language
using
EBNF
grammar:
dcmQuery
::=
/step
(xQuery)?
xQuery
::=
(
/
step
)*(
/
finalExpr
)?
|
/
finalExpr
step
::=
object
(
[
condExpr
]
)?
finalExpr
::=
attribute
([
orderByExpr
]
)?
condExpr
::=
equalExpr
(and
equalExpr)*
equalExpr
::=
attribute
=
(value
|
variable)
orderByExpr
::=
orderBy
attribute
object
::=
letter
(letter
|
digit
)*
attribute
::=
@letter
(letter
|
digit
|
-|
.|_)*
variable
::=
$letter(letter
|
digit
|.|_)*
Chapter
4.
Querying
the
data
center
model
17
-
value
::=
(any
character
except
)*
v
The
|
operator
builds
the
union
of
two
types.
For
example,
the
expression:
(letter
|
digit
)
means
that
an
element
of
type
letter
or
type
digit.
v
An
asterisk
(*)
symbol
at
the
end
of
a
syntax
rule
corresponds
to
zero
or
more
instances
of
that
type.
v
A
question
mark
(?)
symbol
at
the
end
of
a
syntax
rule
corresponds
to
zero
or
one
instance
of
that
type.
Dcm
query
language
parts
and
expressions
Part
Syntax
rule
Value
(any
character
except
)*
Object
letter
(letter
|
digit
)*
This
expression
should
be
read
as
follows:
An
object
consists
of
a
letter
followed
by
zero
or
more
instances
of
a
letter
or
a
digit.
Example:
DCMQuery(/server[@name="Nile"]/nic[@managed="N"]).
An
object
in
this
query
is
server.
Attribute
@letter
(letter
|
digit
|
-|
.|_)*
This
expression
should
be
read
as
follows:
An
attribute
consists
of
an
@
symbol
followed
by
a
letter,
followed
by
zero
or
more
instances
of
a
letter,
digit,
hyphen,
period,
or
underscore.
Example:
DCMQuery(/cluster[@name="RiversEdge
Web"]/server/@name[orderBy@name]).
The
attribute
in
this
query
is
@name.
Variable
$letter(letter
|
digit
|.|_)*
This
expression
should
be
read
as
follows:
A
variable
consists
of
a
$
symbol
followed
by
a
letter,
followed
by
zero
or
more
instances
of
a
letter,
or
digit,
or
period,
or
underscore.
Example:
DCMQuery(/deploymentPlan[@id=$dpId]/servers/server).
The
variable
in
this
query
is:
$dpId.
Order
by
expression
(orderByExpr)
orderBy
attribute
This
expression
should
be
read
as
follows:
An
order
by
operand
consists
of
an
orderBy
expression
followed
by
an
attribute.
Example:
DCMQuery(/cluster[@name="RiversEdge
Web"]/server/@name[orderBy@name]).
The
order
by
expression
in
this
query
is
orderBy@name.
Equal
expression
(equalExpr)
attribute
=
(value|variable)
This
expression
should
be
read
as
follows:
An
equal
expression
consists
of
an
attribute
followed
by
an
equal
sign,
and
followed
by
a
value
or
a
variable.
Example:
DCMQuery(/cluster[@name="RiversEdge
Web"]/server/@name[orderBy@name]).
The
equal
expression
in
this
query
is:
@name="RiversEdge
Web".
Conditional
expression
(condExpr)
equalExpr(
and
equalExpr)*
This
expression
should
be
read
as
follows:
A
conditional
expression
consists
of
an
equal
expression
followed
by
zero
or
more
instances
of
an
AND
operator
and
an
equal
expression.
Example:
@managed="N"
AND
@name="NIC01"
AND
@netbootEnabled="N"
AND
@macaddress=""
18
Workflow
Developers
Guide
-
Final
expression
(finalExpr)
attribute
(
[
orderByExpr
]
)?
This
expression
should
be
read
as
follows:
A
final
expression
consists
of
a
an
attribute
followed
by
an
open
square
bracket,
followed
zero
or
one
instance
of
an
order
by
expression,
followed
by
a
closed
square
bracket.
Example:
DCMQuery(/cluster[@name="RiversEdge
Web"]/server/@name[orderBy@name]).
The
final
expression
in
this
query
is:
@name[orderBy@name].
Step
object
(
[
condExpr
]
)?
This
expression
should
be
read
as
follows:
A
step
expression
consists
of
a
an
object
followed
by
an
open
square
bracket,
followed
by
zero
or
one
instance
of
an
conditional
expression,
followed
by
a
closed
square
bracket.
Example:
DCMQuery(/server[@name="Nile"])
xQuery
(
/
step
)*
(
/
finalExpr
)
?
|
/finalExpr
This
expression
should
be
read
as
follows:
An
xQuery
expression
consists
of
zero
or
more
instances
of
a
step
followed
by
zero
or
one
instance
of
a
final
expression
or
only
a
final
expression
.
Example:
DCMQuery(/server[@name="Nile"]/nic[@managed="N"
AND
@name="NIC01"
AND
@netbootEnabled="N"
AND
@macaddress=""]/@name[orderBy@name])
dcmQuery
/step
(xQuery)?
This
expression
should
be
read
as
follows:
A
dcmQuery
expression
consists
of
a
step,
followed
zero
or
more
instances
of
an
xQuery.
Example:
DCMQuery(/server[@name="Nile"]/nic[@managed="N"
AND
@name="NIC01"
AND
@netbootEnabled="N"
AND
@macaddress=""]/@name[orderBy@name])
Note:
v
A
dollar
sign
($)
in
a
dcm
query
expression
followed
by
letters
or
digits
is
used
to
represent
a
variable
in
a
dcm
query.
v
Brackets
([])
in
a
dcm
query
expression
are
used
to
group
conditional
and
order
by
expressions.
v
A
back
slash
(/)
in
a
dcm
query
expression
represents
an
absolute
path
to
the
required
element.
v
Attributes
are
specified
by
a
@
prefix
and
are
separated
from
values
by
an
equal
(=)
sign
in
a
dcm
query
expression.
v
Values
are
enclosed
in
double
quotes
(
)
in
a
dcm
query
expression.
v
To
use
a
value
that
contains
a
double
quote,
you
can
define
a
variable
that
has
that
value
and
use
the
variable
instead
in
the
query.
v
To
define
a
null
value,
use
"".
For
example,
@name=""
Related
information
Data
center
model
queries
Data
center
model
Chapter
4,
Querying
the
data
center
model,
on
page
13
Workflow
composer
Creating
and
managing
workflows
Numeric
representation
of
dcm
components
Chapter
4.
Querying
the
data
center
model
19
-
20
Workflow
Developers
Guide
-
Chapter
5.
Conditional
and
looping
statements
A
loop
is
used
in
programming
to
allow
you
to
perform
one
or
more
actions
repeatedly.
As
long
as
a
statement
evaluates
to
true,
the
loop
will
repeat
and
will
run
an
indefinite
number
of
times
until
the
expression
evaluates
to
false.
A
conditional
tests
an
expression
using
an
if
statement,
and
uses
a
then
statement
to
show
alternative
actions
to
run
if
the
expression
is
false.
If
the
expression
is
never
true,
the
action
is
not
performed
Related
information
if...then
statements
if...then...else
statements
foreach
statements
on
page
22
while
statements
on
page
22
if...then
statements
Purpose
The
if...then
statement
is
a
basic
conditional
statement.
To
perform
an
operation
if
an
expression
is
true,
use
an
if
statement
to
test
an
expression
and
use
a
then
statement
to
show
alternative
actions
to
run
if
the
expression
is
false
Sample
The
following
example
shows
how
the
if...then
conditional
statement
works:
workflow
test
if
Jython(mycondition)
then
statement
endif
Related
information
if...then...else
statements
foreach
statements
on
page
22
while
statements
on
page
22
if...then...else
statements
Purpose
The
if...then...else
statement
is
a
basic
conditional
statement.
To
perform
an
operation
if
an
expression
is
true,
use
an
if
statement
to
test
an
expression
and
use
a
then
statement
to
show
alternative
actions
to
run
if
the
expression
is
false,
and
optionally,
an
else
statement
for
other
alternative
actions.
Sample
The
following
example
shows
how
the
if...then...else
conditional
statement
works:
workflow
test
if
Jython(mycondition)
then
statements
else
statements
endif
Related
information
21
-
if...then
statements
on
page
21
foreach
statements
while
statements
foreach
statements
Purpose
A
foreach
statement
loops
as
long
as
a
condition
evaluates
to
true.
This
loop
will
repeat
while
the
condition
is
true
and
statements
following
do
will
run
an
indefinite
number
of
times
until
the
conditional
expression
evaluates
to
false.
Typically,
you
would
use
a
while...do
loop
when
the
number
of
times
that
you
will
run
through
a
conditional
is
unknown.
When
you
anticipate
that
your
loop
will
repeat
a
specific
number
of
times,
a
foreach
statement
is
a
better
choice
and
will
repeat
until
a
specified
condition
is
false.
Sample
The
following
example
shows
how
the
foreach
loop
statement
works:
workflow
workflow1
foreach
iteratorVar
in
DCMQuery(a
DCM
query)
do
statement
done
Related
information
if...then
statements
on
page
21
if...then...else
statements
on
page
21
while
statements
while
statements
Purpose
A
while
statement
loops
as
long
as
a
condition
evaluates
to
true.
This
loop
will
repeat
while
the
condition
is
true
and
statements
following
do
will
run
an
indefinite
number
of
times
until
the
conditional
expression
evaluates
to
false.
Sample
The
following
example
shows
how
the
while
conditional
statement
works:
workflow
workflow1
while
Jython(condition)
do
statement
done
Related
information
if...then
statements
on
page
21
if...then...else
statements
on
page
21
foreach
statements
22
Workflow
Developers
Guide
-
Chapter
6.
Error
handling
Error
handling
allows
you
to
recover
from
unexpected
errors.
An
error
is
a
condition
which,
if
not
handled,
will
cause
the
workflow
to
fail.
When
an
error
occurs
in
a
workflow,
you
can
use
error
handling
techniques
to
allow
the
workflow
to
recover
on
its
own
and
shift
the
error
to
other
less
obtrusive
areas
of
the
workflow.
Within
the
Tivoli
Intelligent
ThinkDynamic
Orchestrator
workflow
design,
all
error
handling
is
done
by
throwing
and
catching
errors.
Using
this
method,
you
can
protect
the
entire
workflow
from
failing.
The
following
error
handling
techniques
are
supported
in
the
workflow
language:
Related
information
try...catch...catchall...finally
statements
throw
statements
on
page
24
try...catch...catchall...finally
statements
Purpose
Implements
error
handling
for
workflow
development.
Try
statements
are
used
with
the
intention
of
catching
errors
in
your
workflow.
If
an
error
is
thrown
from
the
try
statement,
the
catch
statement
is
used
to
catch
a
given
class
of
errors
and
must
be
prepared
to
handle
the
errors
that
are
thrown.
When
try
statements
are
run
and
errors
have
been
handled,
all
finally
statements
are
run.
Sample
The
following
example
shows
how
the
try...catch...catchall...finally
exception
handling
works:
workflow
TryCatchCatchAllFinally(in
LString,
in
RString,
out
Output)
LocaleInsensitive
try
Output=Jython(LString+RString)
catch
MyException
ex1
Output=Jython(LString+"catch
MyException")
catch
OtherException
Output=Jython(LString+"catch
OtherException")
catchall
ex3
Output=Jython(LString+"catchall")
finally
Output=Jython(LString+"finally")
endtry
Arguments
try
Required.
Statements
where
an
error
can
occur.
catch
Optional.
Statements
to
handle
errors
that
occur
in
a
try
statement.
catchall
Optional.
Statements
to
catch
exceptions
of
any
type
that
occur
in
a
try
statement.
finally
Optional.
Statements
that
are
run
after
all
error
processing
has
completed.
Related
information
throw
statements
on
page
24
23
-
throw
statements
Purpose
The
throw
statement
generates
an
error
condition
that
can
be
handled
by
the
try...catch...catchall...finally
statement.
Sample
The
following
example
shows
how
the
throw
exception
handling
works:
workflow
ThrowExplicitMessage
LocaleInsensitive
throw
AnException
"A
message"
Arguments
throw
Optional.
Statements
that
are
passed
to
another
area
of
the
workflow.
Related
information
try...catch...catchall...finally
statements
on
page
23
24
Workflow
Developers
Guide
-
Chapter
7.
Creating
scripts
The
workflow
composer
works
with
the
Jython
programming
language
to
support
embedded
scripting
in
Bash,
Perl,
and
Expect.
To
add
a
script
to
your
workflow:
1.
In
Tivoli
Intelligent
ThinkDynamic
Orchestrator,
click
System
configuration
and
workflow
management
Workflows.
2.
Drag-and-drop
the
Scriptlet
element
to
your
workflow
build
space.
3.
Click
the
scriptlet
language
link.
4.
Type
the
name
of
the
scripting
language
that
was
used
to
write
the
script.
5.
Type
the
target
for
the
script.
The
target
is
a
dcm
query
that
resolves
to
a
device
ID.
6.
Type
the
credentials
key
for
the
script.
7.
In
the
Scriptlet
Code
field,
type
the
script
for
your
workflow.
8.
Click
Save.
A
workflow
with
a
sample
script
is
shown
below:
workflow
test
scriptlet
language
=
jython
-
26
Workflow
Developers
Guide
-
Chapter
8.
Displaying
workflow
references
Workflow
references
include
all
the
data
center
objects
associated
with
the
selected
workflow,
as
well
as
any
other
workflows
that
reference
it.
To
display
workflow
references:
1.
Click
System
configuration
and
workflow
management
Workflows.
The
Workflows
tab
is
displayed.
2.
In
the
list,
select
the
workflow
whose
data
you
want
to
display.
3.
Click
the
References
tab.
All
workflows
using
the
current
workflow,
as
well
as
all
data
center
objects
that
are
associated
with
this
workflow,
are
displayed.
Related
information
Workflows
Workflow
components
Workflow
composer
Preparing
to
write
a
workflow
Tutorial:
Creating
a
new
workflow
Chapter
9,
Editing
workflow
properties,
on
page
29
Chapter
10,
Adding
and
managing
workflow
transitions,
on
page
31
Chapter
12,
Running
workflows,
on
page
35
Chapter
11,
Adding
and
managing
workflow
variables
and
parameters,
on
page
33
Chapter
13,
Importing
workflows,
on
page
37
Chapter
15,
Displaying
workflow
run
history,
on
page
41
Chapter
16,
Displaying
the
run
history
for
an
individual
workflow,
on
page
43
Displaying
the
run
details
of
a
workflow
Deleting
the
run
history
of
a
workflow
Troubleshooting
workflows
27
-
28
Workflow
Developers
Guide
-
Chapter
9.
Editing
workflow
properties
To
edit
the
properties
of
an
existing
workflow:
1.
Click
System
configuration
and
workflow
management
Workflows.
The
Workflows
tab
displays
all
the
workflows
that
are
currently
defined
in
the
system.
2.
In
the
workflow
list,
find
the
workflow
whose
properties
you
want
to
edit
and
click
.
3.
Click
Edit.
4.
Edit
the
workflow
properties
as
required.
5.
Click
Save.
Related
information
Workflows
Workflow
components
Workflow
composer
Preparing
to
write
a
workflow
Tutorial:
Creating
a
new
workflow
Chapter
9,
Editing
workflow
properties
Chapter
10,
Adding
and
managing
workflow
transitions,
on
page
31
Chapter
12,
Running
workflows,
on
page
35
Chapter
11,
Adding
and
managing
workflow
variables
and
parameters,
on
page
33
Chapter
13,
Importing
workflows,
on
page
37
Chapter
15,
Displaying
workflow
run
history,
on
page
41
Chapter
16,
Displaying
the
run
history
for
an
individual
workflow,
on
page
43
Troubleshooting
workflows
29
-
30
Workflow
Developers
Guide
-
Chapter
10.
Adding
and
managing
workflow
transitions
Transitions
are
steps
within
a
workflow
that
are
needed
to
run
in
sequential
order
to
complete
the
larger
workflow.
You
can
add,
edit,
and
delete
transitions
as
well
as
map
the
variables
for
your
workflow.
Adding
a
new
transition
to
the
workflow
To
add
a
new
transition:
1.
Click
System
configuration
and
workflow
management
Workflowsand
select
the
workflow
that
you
want
to
work
with.
The
Workflow
tab
is
displayed.
2.
In
the
navigation
tree,
identify
the
workflow,
command,
Java
plug-in,
or
logical
operation
you
want
to
add
as
a
new
transition
to
your
workflow,
and
then
drag
it
onto
your
workflows
editing
area,
in
the
right
frame.
You
can
also
copy
transitions
from
already
existing
workflows,
by
dragging
them
either
from
the
navigation
tree
or
from
another
browser
window
onto
your
workflow
transition
area.
In
this
case,
a
copy
of
the
selected
transition
is
created
in
your
workflow.
3.
If
necessary,
use
the
same
drag-and-drop
functionality
to
rearrange
the
transitions
within
your
workflow.
Related
information
Creating
and
managing
workflows
Editing
transition
properties
To
edit
the
properties
of
a
transition:
1.
Click
System
configuration
and
workflow
management
Workflowsand
select
the
workflow
that
you
want
to
work
with.
2.
In
the
transition
list,
identify
the
transition
to
edit,
and
then
click
.
3.
Click
Properties.
4.
Edit
the
transition
properties
as
required.
5.
Click
Save.
Mapping
a
command
variable
To
map
a
command
variable
to
a
workflow
parameter:
1.
Click
System
configuration
and
workflow
management
Workflowsand
select
the
workflow
that
you
want
to
work
with.
The
Workflow
tab
is
displayed.
2.
Select
an
output
variable
and
drag
it
to
the
Value
field
associated
with
the
appropriate
input
parameter.
3.
Repeat
step
2
and
3
for
every
transition
that
requires
variable
mapping.
Removing
a
transition
To
remove
a
transition
from
![The ]po[ Workflow Introduction Frank Bergmann, 2006-11-15 This guide contains ]po[ workflow overview information for developers with experience with PostgreSQL.](https://static.fdocuments.in/doc/165x107/551b6a82550346d31b8b5d1b/the-po-workflow-introduction-frank-bergmann-2006-11-15-this-guide-contains-po-workflow-overview-information-for-developers-with-experience-with-postgresql.jpg)
