The

threshold
cost
is
a
PL/SQL
package
variable
with
a
default
value
of
50
hundredths
of
a
second.
Set
a
cost
above
this
threshold
for
all
activities
that
you
don't
want
the
user
to
wait
for.
At
runtime,
the
Workflow
Engine
defers
any
thread
to
the
background
as
soon
as
it
encounters
an
activity
with
a
cost
higher
than
the
threshold.
Then
the
background
engine
later
identifies
the
process
as
deferred
and
continues
its
execution.
Workflow
Access
Protection:
• Access
protection
is
a
feature
that
prevents
workflow
seed
data
created
by
a
'seed
data
provider'
from
being
modified
by
a
'seed
data
consumer'.
'seed
data
provider'
--‐--‐>
any
organization
that
creates
'seed
data'
for
other
organizations
('seed
data
consumers')
to
use
in
defining
and
customizing
a
workflow
process.
− Workflow
objects
definitions
that
can
be
customized.
− Workflow
object
definitions
protected
against
customization.
Scenario:
There
are
2
teams
in
my
organization
Global
Team
&
Regional
Team.
Global
Team
does
development
across
all
regions
where
as
regional
team
does
development
within
their
own
region
and
not
shared
by
other.
Consider
my
organization
Global
team
using
oracle
std.
item
type
in
my
workflow
in
a
custom
workflow
process.
Now
my
organization
wants
to
enable
below
protections,
Identify
certain
workflow
objects
in
its
custom
workflow
definition
as
corporate
standards
that
the
regional
teams
should
adhere
to
and
not
modify.
Designate
certain
objects
in
its
deployed
process
as
customizable
for
the
regional
offices
to
alter
to
their
offices'
needs.
How
this
can
be
achieved?
By
using
Access
Protection
Feature
in
Oracle
Workflow.
Access
Protection
Features:
1. Access
Level
2. Customization
Level
3. Protection
Level
− The
combination
of
protection,
customization,
and
access
levels
make
up
the
access
protection
feature
and
determines
whether
a
user
can
modify
a
given
workflow
object.
− The
level,
in
all
three
cases,
is
a
numeric
value
ranging
from
0
to
1000
that
indicates
the
relationship
between
different
organizations
as
providers
and
consumers
of
seed
data.
The
following
ranges
of
levels
are
presumed
by
Oracle
Workflow:
0--‐9
Oracle
Workflow
10--‐19
Oracle
Application
Object
Library
20--‐99
Oracle
Applications
development
100--‐999
Customer
organization.
You
can
determine
how
you
want
this
range
to
be
interpreted.
For
example,
100
can
represent
headquarters,
while
101
can
represent
a
regional
office,
and
so
on.
1000
Public
Access
Level:
A
"user
of
Oracle
Workflow"
in
this
case,
represents
someone
who
is
operating
Oracle
Workflow
Builder,
or
the
Workflow
Definitions
Loader
program,
which
loads
workflow
process
definitions
from
a
file
into
a
database.
As
a
seed
data
provider,
you
should
always
operate
Oracle
Workflow
Builder
at
the
same
consistent
access
level
because
the
level
you
work
at
affects
the
protection
level
of
the
seed
data
you
create.
You
can
view
your
access
level
as
follows:
• In
Oracle
Workflow
Builder,
select
About
Workflow
from
the
Help
menu.
• If
you
are
going
to
run
the
Workflow
Definitions
Loader
program
to
download
workflow
process
definitions
from
the
database
to
a
file,
check
the
value
for
the
environment
variable
WF_ACCESS_LEVEL
on
your
workflow
server.
Protection
Level:
Whenever
you
create
a
workflow
object
in
Oracle
Workflow
Builder,
you
have
the
option
of
protecting
the
object
at
a
certain
level.
An
object's
protection
level
helps
control
whether
other
users
can
modify
the
object
based
on
their
access
levels,
by
allowing
only
users
with
an
access
level
equal
to
or
lower
than
the
object's
protection
level
to
modify
the
object.
The
protection
level
that
you
set
for
an
object
is
dependent
on
the
setting
of
the
Lock
at
this
Access
Level
check
box
and
on
your
current
access
level.
• If
you
check
the
Lock
at
this
Access
Level
check
box,
the
protection
level
for
the
object
is
set
to
your
current
access
level.
Users
with
an
access
level
higher
than
your
current
access
level
will
not
be
able
to
modify
the
object.
These
users
will
see
a
small
lock
on
the
workflow
object's
icon,
indicating
that
the
object
can
be
used
but
not
modified.
For
users
with
an
access
level
equal
to
or
lower
than
your
current
access
level,
the
customization
level
for
the
object
will
determine
whether
they
can
modify
the
object.
• If
you
do
not
check
the
Lock
at
this
Access
Level
check
box,
the
protection
level
for
the
object
is
set
to
1000.
In
this
case
all
users
who
are
not
restricted
by
the
customization
level
can
modify
the
object.
Customization
Level:
• Every
workflow
object,
in
addition
to
having
a
protection
level,
also
records
a
customization
level
when
you
modify
the
object
and
save
it
to
a
database
or
file.
An
object's
customization
level
helps
control
whether
other
users
can
modify
the
object
based
on
their
access
levels,
by
allowing
only
users
with
an
access
level
equal
to
or
higher
than
the
object's
customization
level
to
modify
the
object.
• Setting
the
customization
level
ensures
that
a
customizable
object
that
has
been
customized
never
gets
overwritten
during
a
seed
data
upgrade,
because
the
upgrade
always
occurs
with
the
Workflow
Definitions
Loader
operating
at
an
access
level
below
the
customized
object's
customization
level.
Workflow
Definition
Loader
(WFLOAD):
We
use
the
Workflow
Definitions
Loader
to
save
or
load
process
definitions
from
a
database
or
flat
file.
We
can
also
define
as
it
is
a
utility
that
moves
workflow
data
between
a
file
and
a
database
and
it
is
also
used
to
upgrade,
upload
and
download
the
workflow
data.
Usage:
• Normally
when
we
upgrade
our
database,
we
use
the
Workflow
Definitions
Loader
to
preserve
and
back
up
our
process
definitions
to
a
flat
file.
When
the
database
upgrade
is
completed,
we
use
the
Loader
program
again
to
upload
the
definitions
back
into
your
database.
• We
can
also
use
the
Loader
program
to
upgrade
our
database
with
a
newer
version
of
a
process
definition
or
to
transfer
process
definitions
to
other
databases.
Modes:
The
Workflow
Definitions
Loader
automatically
validates
the
process
definition
to
ensure
that
it
conforms
to
specific
process
design
rules.
There
are
four
modes
available
with
WFLOAD.These
are
as
follows:
1) DOWNLOAD
--‐
Download
the
WF
definitions
into
Flat
file.
2) UPGRADE
–
Honors
both
protection
and
customization
levels
of
data
3) UPLOAD
–
Honors
only
protection
level
of
data
[No
respect
of
Customization
Level]
4) FORCE
–
Force
upload
regardless
of
protection
or
customization
level
WFLOAD
Username/password
<access_level>
Y
<Mode>
<File_name>.wft
<Item_Type>
For
Example,
WFLOAD
apps/apps
0
Y
DOWNLOAD
poxwfrqa.wft
POAPWF
Workflow
API’s:
Below
are
some
important
API’s
frequently
used
in
workflow
development
/
customizations.
WF_ENGINE
API’s
WF_ENGINE.
CreateProcess
CreateProcess
(itemtype
in
varchar2,itemkey
in
varchar2,process
in
varchar2
default
);
Creates
a
new
runtime
process
for
an
application
item.
For
example,
a
Requisition
item
type
may
havea
Requisition
Approval
Process
as
a
top
level
process.
When
a
particular
requisition
is
created,
an
application
calls
CreateProcess
to
set
up
the
information
needed
to
start
the
defined
process.
WF_ENGINE.
SetItemUserKey
SetItemUserKey
(itemtype
in
varchar2,itemkey
in
varchar2,
userkey
in
varchar2);
Lets
you
set
a
user–friendly
identifier
for
an
item
in
a
process,
which
is
initially
identified
by
an
item
type
and
item
key.
The
user
key
is
intended
to
be
a
user–
friendly
identifier
to
locate
items
in
the
Workflow
Monitor
and
other
user
interface
components
of
Oracle
Workflow.
WF_ENGINE.
GetItemUserKey
GetItemUserKey
(itemtype
in
varchar2,itemkey
in
varchar2)
return
varchar2;
Returns
the
user–friendly
key
assigned
to
an
item
in
a
process,
identified
by
an
item
type
and
item
key.
The
user
key
is
a
user–friendly
identifier
to
locate
items
in
the
Workflow
Monitor
and
other
user
interface
components
of
Oracle
Workflow.
WF_ENGINE.
SetItemOwner
SetItemOwner
(itemtype
in
varchar2,itemkey
in
varchar2,owner
in
varchar2);
A
procedure
to
set
the
owner
of
existing
items.
The
owner
must
be
a
valid
role.
Typically,
the
role
that
initiates
a
transaction
is
assigned
as
the
process
owner,
so
that
any
participant
in
that
role
can
find
and
view
the
status
of
that
process
instance
in
the
Workflow
Monitor.
WF_ENGINE.
StartProcess
StartProcess
(itemtype
in
varchar2,itemkey
in
varchar2);
Begins
execution
of
the
specified
process.
The
engine
locates
the
activity
marked
as
START
and
then
executes
it.
CreateProcess(
)
must
first
be
called
to
define
the
itemtype
and
itemkey
before
calling
StartProcess(
).
WF_ENGINE.
LaunchProcess
LaunchProcess
(itemtype
in
varchar2,itemkey
in
varchar2,process
in
varchar2
default'',userkey
in
varchar2
default
'',owner
in
varchar2
default
'');
Launches
a
specified
process
by
creating
the
new
runtime
process
and
beginning
its
execution.
This
is
a
wrapper
that
combines
CreateProcess
and
StartProcess.
WF_ENGINE.
SuspendProcess
SuspendProcess
(itemtype
in
varchar2,itemkey
in
varchar2,process
in
varchar2
default
'');
Suspends
process
execution
so
that
no
new
transitions
occur.
Outstanding
notifications
can
complete
by
calling
CompleteActivity(
),
but
the
workflow
does
not
transition
to
the
next
activity.
Restart
suspended
processes
by
calling
ResumeProcess(
).
ResumeProcess(itemtype
in
varchar2,itemkey
in
varchar2,process
in
varchar2
default
'');
Returns
a
suspended
process
to
normal
execution
status.
Any
activities
that
were
transitioned
to
while
the
process
was
suspended
are
now
executed.
WF_ENGINE.
AbortProcess
AbortProcess
(itemtype
in
varchar2,itemkey
in
varchar2,process
in
varchar2
default
'',result
in
varchar2
default
eng_force);
Aborts
process
execution
and
cancels
outstanding
notifications.
The
process
status
is
considered
COMPLETE,
with
a
result
specified
by
the
result
argument.
Also,
any
outstanding
notifications
or
subprocesses
are
set
to
a
status
of
COMPLETE
with
a
result
of
force,
regardless
of
the
result
argument.
WF_ENGINE.
AddItemAttr
AddItemAttr
(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2);
Adds
an
empty
item
type
attribute
variable
to
the
process.
Although
most
item
type
attributes
are
defined
at
design
time,
developers
can
create
new
attributes
at
runtime
for
a
specific
process.
WF_ENGINE.
SetItemAttrText
SetItemAttrText(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2,avalue
in
varchar2);
WF_ENGINE.
SetItemAttrNumber
SetItemAttrNumber(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2,avalue
in
number);
WF_ENGINE.
SetItemAttrDate
SetItemAttrDate
(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2,avalue
in
date);
WF_ENGINE.
GetItemAttrText
GetItemAttrText(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2)
return
varchar2;
WF_ENGINE.
GetItemAttrNumber
GetItemAttrNumber(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2)
return
number;
WF_ENGINE.
GetItemAttrDate
GetItemAttrDate(itemtype
in
varchar2,itemkey
in
varchar2,aname
in
varchar2)
return
date;
WF_ENGINE.
BeginActivity
BeginActivity
(itemtype
in
varchar2,itemkey
in
varchar2,activity
in
varchar2);
Determines
if
the
specified
activity
can
currently
be
performed
on
the
process
item
and
raises
an
exception
if
it
cannot.
The
CompleteActivity()
procedure
automatically
performs
this
function
as
part
of
its
validation.
However,
you
can
use
BeginActivity
to
verify
that
the
activity
you
intend
to
perform
is
currently
allowed
before
actually
calling
it.
WF_ENGINE.
CompleteActivity
CompleteActivity(itemtype
in
varchar2,itemkey
in
varchar2,activity
in
varchar2,result_code
in
varchar2);
Notifies
the
workflow
engine
that
the
specified
activity
has
been
completed
for
a
particular
item.
WF_ENGINE.
ItemStatus
ItemStatus(itemtype
in
varchar2,itemkey
in
varchar2,status
out
varchar2,result
out
varchar2);
Returns
the
status
and
result
for
the
root
process
of
the
specified
item
instance.
Possible
values
returned
for
the
status
are:
ACTIVE,
COMPLETE,
ERROR,
or
SUSPENDED.
If
the
root
process
does
not
exist,
then
the
item
key
does
not
exist
and
will
thus
cause
the
procedure
to
raise
an
exception.
Workflow
core
APIs:
PL/SQL
procedures
called
by
function
activities
can
use
a
set
of
core
Oracle
Workflow
APIs
to
raise
and
catch
errors.
When
a
PL/SQL
procedure
called
by
a
function
activity
either
raises
an
unhandled
exception,
or
returns
a
result
beginning
with
'ERROR:',
the
Workflow
Engine
sets
the
function
activity's
status
to
ERROR
and
sets
the
columns
ERROR_NAME,
ERROR_MESSAGE,
and
ERROR_STACK
in
the
table
WF_ITEM_ACTIVITY_STATUSES
to
reflect
the
error.
WF_CORE.
CLEAR
CLEAR
Clears
the
error
buffers.
WF_CORE.
GET_ERROR
GET_ERROR(err_name
out
varchar2,err_message
out
varchar2
err_stack
out
varchar2);
Returns
the
name
of
a
current
error
message
and
the
token
substituted
error
message.
Also
clears
the
error
stack.
Returns
null
if
there
is
no
current
error.
WF_CORE.
RAISE
RAISE
(name
in
varchar2);
Raises
an
exception
to
the
caller
by
supplying
a
correct
error
number
and
token
substituted
message
for
the
name
of
the
error
message
provided.
Workflow
Directory
Service
APIs:
WF_DIRECTORY.
GetRoleUsers
GetRoleUsers(role
in
varchar2,users
out
UserTable);
Returns
a
table
of
users
for
a
given
role.
WF_DIRECTORY.
GetUserRoles
GetUserRoles(user
in
varchar2,roles
out
RoleTable);
Returns
a
table
of
roles
that
a
given
user
is
assigned
to.
WF_DIRECTORY.
GetRoleInfo
GetRoleInfo(Role
in
varchar2,Display_Name
out
varchar2,Email_Address
out
varchar2,Notification_Preference
out
varchar2,Language
out
varchar2,Territory
out
varchar2);
Returns
the
following
information
about
a
role:
• Display
name
• Email
address
• Notification
Preference
('QUERY',
'MAILTEXT',
'MAILHTML','MAILATTH',
'SUMMARY')
• Language
• Territory
WF_DIRECTORY.
IsPerformer
IsPerformer
(user
in
varchar2,role
in
varchar2);
Returns
true
or
false
to
identify
whether
a
user
is
a
performer
of
a
role.
WF_DIRECTORY.
GetRoleName
GetRoleName
(p_orig_system
in
varchar2,p_orig_system_id
in
varchar2,p_name
out
varchar2,p_display_name
out
varchar2);
Returns
a
Workflow
display
name
and
role
name
for
a
role
given
the
system
information
from
the
original
user
and
roles
repository.
WF_DIRECTORY.
SetAdHocUserStatus
SetAdHocUserStatus
(user_name
in
varchar2,status
in
varchar2
default
'ACTIVE');
Sets
the
status
of
an
ad
hoc
user
as
'ACTIVE'
or
'INACTIVE'.
WF_DIRECTORY.
SetAdHocRoleStatus
SetAdHocRoleStatus
(role_name
in
varchar2,status
in
varchar2
default
'ACTIVE');
Sets
the
status
of
an
ad
hoc
role
as
'ACTIVE'
or
'INACTIVE'.
WF_DIRECTORY.
CreateAdHocUser
CreateAdHocUser
(name
in
out
varchar2,display_name
in
out
varchar2,
language
in
varchar2
default
null,
territory
in
varchar2
default
null,
description
in
varchar2
default
null,
notification_preference
in
varchar2
default
'MAILHTML',
email_address
in
varchar2
default
null,
fax
in
varchar2
default
null,
status
in
varchar2
default
'ACTIVE',
expiration_date
in
date
default
sysdate);
Creates
a
user
at
runtime
by
creating
a
value
in
the
WF_LOCAL_USERS
table.
This
is
referred
to
as
an
ad
hoc
user.
WF_DIRECTORY.
CreateAdHocRole
CreateAdHocRole
(role_name
in
out
varchar2,
role_display_name
in
out
varchar2,
language
in
varchar2
default
null,
territory
in
varchar2
default
null,
role_description
in
varchar2
default
null,
notification_preference
in
varchar2
default'MAILHTML',
role_users
in
varchar2
default
null,
email_address
in
varchar2
default
null,
fax
in
varchar2
default
null,
status
in
varchar2
default
'ACTIVE',expiration_date
in
date
default
sysdate);
Creates
a
role
at
runtime
by
creating
a
value
in
the
WF_LOCAL_ROLES
table.
This
is
referred
to
as
an
ad
hoc
role.
WF_DIRECTORY.
AddUsersToAdHocRole
AddUsersToAdHocRole
(role_name
in
varchar2,role_users
in
varchar2);
Adds
users
to
a
existing
ad
hoc
role.
WF_DIRECTORY.
RemoveUsersFromAdHocRole
RemoveUsersFromAdHocRole
(role_name
in
varchar2,role_users
in
varchar2
default
null);
Removes
users
from
an
existing
ad
hoc
role.