WF_ITEM_TYPES:
The wf_item_types table
contains one record for each item_type created. The eight character name of the
item_type represents the “Internal Name” of the item. It also functions as the
primary key for this table. Some key columns are:
§ NAME: It is a mandatory field. It represents the
internal name of the item type.
§ PROTECT_LEVEL: Level at which the data is
protected. A mandatory field.
§ CUSTOM_LEVEL: Level of user who last updated the
row. Again a mandatory field.
§ WF_SELECTOR: It stores the name of the PL/SQL
procedure which implements selector function. This is an optional field.
§ PERSISTENCE_TYPE: Indicates whether item type is
temporary or permanent.
§ PERSISTENCE_DAYS: Number of days until purge if
persistence is temporary.
Workflow Item Type
Display Name and description can be found in WF_ITEM_TYPES _TL table.
WF_ITEM_ATTRIBUTES:
This table stores
definitions of attributes associated with a process. The entries in this table
correspond to the “Attributes” subheading in the Workflow Builder. An item
attribute works like a variable which can hold values that are specific to the
process instance or which may change at run time. Some key columns are:
§ ITEM_TYPE: Internal name for the item type that
owns the attribute. A mandatory field.
§ NAME: Internal name of the attribute. A
mandatory field.
§ SEQUENCE: Order of the attribute within the
message
§ TYPE: Each item attribute is assigned a
datatype, such as “Character”, “Number”, or “Date”.
There are three fields
to hold a default value, but only one of them will be populated for any item
attribute, depending upon the datatype. For example, if you create an item
attribute with a datatype of “Number”, and then supply a default value, that
value would be stored in the “number_default” field.
The “format” field
stores information about a format mask that should be applied to number or date
values, and the “subtype” field contains “SEND” or “RECEIVE”. The Translation
table is WF_ITEM_ATTRIBUTES_TL and the related view is WF_ITEM_ATTRIBUTES_VL.
WF_ACTIVITIES:
This table stores the
definition of an activity. Activities can be processes, notifications,
functions or folders. A process activity is a modeled workflow process, which
can be included as an activity in other processes to represent a sub-process. A
notification activity sends a message to a performer. A functions activity
performs an automated function that is written as a PL/SQL stored procedure. A
folder activity is not part of a process, but it provides a means of grouping
activities. Some key columns are:
§ ITEM_TYPE: Internal name for the Item Type that
owns the message.
§ NAME: Internal name for the activity.
§ VERSION: It is used to support multiple versions
of the same process running at the same time. The version number works in
concert with the “begin_date” and “end_date” fields, to ensure that only one
version of any activity is active at any given time. By versioning, the
previously launched processes retain the process definition that was in force
at the time they were launched.
§ TYPE: The “type” field is the way that the
individual types of activities can be distinguished. There are five valid
values found in the “type” field: “FUNCTION”, “NOTICE”, “EVENT”, “PROCESS”, and
“FOLDER”.
§ RERUN: Determines if activity is rerun during
looping.
§ EXPAND_ROLE: Determines how many roles are
required to respond to a notification activity.
§ FUNCTION: For function activities only, the
field is used to store the name of the PLSQL procedure that the Workflow Engine
should call to implement the function.
§ RESULT_TYPE: If you intend to model transitions
in a process based upon values returned by an activity node, then the expected
results must be predefined by supplying a lookup type, which is stored in this
field.
§ ICON_NAME: Name of activity icon used in process
window.
§ MESSAGE: For notification activities only, the
field called “message” will be populated. In these cases, it will contain the
internal name of the message that the notification will deliver.
§ ERROR_PROCESS: Workflow process to run in case
of an error.
§ ERROR_ITEM_TYPE: Name of item type to execute in
case of error.
§ RUNNABLE_FLAG: Flag (Y or N) to indicate if
activity is runnable.
§ FUNCTION_TYPE: Indicates whether function type
is pl/sql or internal.
WF_ACTIVITY_ATTRIBUTES:
This table defines attributes
which behave as parameters for an activity. Activity attributes are only used
by function activities. Each row includes the associated activity, type of
attribute, and the format used by the activity. Examples of valid attribute
types are DATE, DOCUMENT, FORM, ITEMATTR, LOOKUP, and VARCHAR2. Notice that the
table requires three fields just to identify to which activity the attribute is
attached: the item_type, name, and version of the activity. To join this table
to the wf_activities tables you must join all three of these fields to their
corresponding fields in that table. Some key columns are:
§ ACTIVITY_ITEM_TYPE: Item type the activity is
associated with
§ ACTIVITY_NAME: Internal name of the activity
§ ACTIVITY_VERSION: Version of the activity
§ NAME: Internal name of the attribute
§ SEQUENCE: Order of the attribute within the
message
§ TYPE: This field refers to the datatype of the
values that the attribute will contain.
§ VALUE_TYPE: Defines if the default is a constant
or a reference to an item attribute.
WF_ACTIVITY_ATTR_VALUES:
This table used to track
values contained in activity attributes. This table is identical in purpose to
wf_item_attribute_values except it holds values for activity attributes instead
of item attributes. Each row includes the process activity id and the
associated value for the attribute. The interesting thing about this table is
that it uses the process_activity_id to identify the activity to which the
attribute is attached. The same activity can be inserted into a process more
than one time, so the only way to uniquely identify the node to which this
attribute is attached is to use the process_activity_id.
WF_MESSAGES:
The messages that are
associated with notifications are stored in this table. Each message, which is
uniquely identified by the combination of item_type and message_name (stored in
the fields “type” and “name”) receives a single record in the wf_messages
table. The actual text of the message is stored only in its localization table
(wf_messages_tl). They can found in the “body” and “html_body” fields.
WF_MESSAGE_ATTRIBUTES:
This table contains
message attribute definitions. Each message may have zero or more message
attributes. Message attributes define additional information that is to be sent
to, or received from the user. These attributes can be used as tokens in the
subject or body of a message template to place variables values into the
message at runtime.
WF_PROCESS_ACTIVITIES:
A process is a sequence
of activities performed in a pre-determined order. When you create a process
definition in the Workflow Builder by dragging various notifications and
functions into the process window, the records created by the Builder are
stored into this table.
WF_ACTIVITY_TRANSITIONS:
The flow of a process
from node to node as indicated by the transition arrows is not saved in the
wf_process_activities table. Instead this information is stored in this table.
A transition is defined
by three discrete pieces of information: the node where the arrow begins, the
node toward which the arrow points, and the result which, when returned by the
beginning node, causes the transition to be followed. Not surprisingly, it is
those three fields which are the most important fields in this table:
“from_process_activity”, “to_process_activity”, and “result_code”. The values
stored in “from_process_activity” and “to_process_activity” are numbers which
represent the instance_id of the records from wf_process_activities from which
and to which the transition is moving.
WF_LOOKUP_TYPES_TL &
WF_LOOKUPS_TL:
Wf_lookup_types_tl is
the table used to set up the types of results expected from Workflow activities
like functions and notifications. This table does not contain
the actual result values, it holds the groupings of the result_codes – the
names you see in the Workflow Builder as the names of the Lookups.
Wf_lookups_tl is the table that stores the component values that comprise a
lookup_type.
