Common step elements
It is possible for each step in the workflow to also contain some or all of the following:
- Enter and exit scripts in workflows
- Asserts in workflows
- Events in workflows
- Notifications in workflows
- Branch IDs in workflows
The PolicyCenter Administration tab displays the current step for each given workflow instance.
Enter and exit scripts in workflows
A workflow step can have any amount of Gosu
code in the Enter and
Exit blocks to define
what to do within that step. (Enter scripts are far more common.) To
access the enter and exit scripts block, select a workflow step and view
the Properties tab at the bottom
of the screen.
Enter Script |
Gosu code that the
workflow runs just after it evaluates any |
Exit Script |
Gosu code that the workflow runs as the final action on leaving this step. |
For example, you could enter the following Gosu code for the enter script:
var msg = "Workflow " + Workflow.DisplayName + "started at " + Workflow.EnteredStep
print(msg)
ParseResultsException.
This is the intended behavior. You must reload the workflow engine to
correct the error ().Asserts in workflows
A step can have any number of Assert condition statements. An
Assert executes just before
the Enter block. If an
Assert fails, the workflow
throws an exception and handles it like any other kind of runtime exception.
To access the Assert
tab, select a workflow step.
Condition |
Each condition must evaluate to a Boolean value. |
Error message |
If a condition evaluates to false, then the workflow logs the supplied error message. |
For example, you could add the following assert condition and error message to log if the assertion fails:
Condition
Workflow.currentAction == “start”
Error message to log if assertion fails
“Some error message if condition is false”
Events in workflows
A step can have any number of Event elements associated with
it. An Event runs right
after the Enter block,
and generates an event with the given name and the business object. To
access the Events tab,
select a workflow step.
Entity Name |
Entity on which to generate the event. This must be a valid symbol name. |
See also: |
Event Name |
Name of the event to generate. This must be a valid event name. |
See also: |
For example:
Entity Name |
|
Event Name |
|
Notifications in workflows
A step can have any number of non-blocking
Notification activities.
A notification in workflow terms
is an activity that PolicyCenter
sends out, but which does not block the workflow from continuing. PolicyCenter only uses it to notify
you of something. The workflow generates any notifications immediately
after it executes the Enter
code, if any. See ActivityStep workflow step for more information on activity
generation.
Name |
Name of the activity. |
Pattern |
Activity pattern code. This must be a valid activity pattern as defined through Guidewire PolicyCenter. |
Init |
Optional Gosu code that the workflow executes immediately after it creates the activity. Typically, you use this code to assign the activity. If you do not explicitly assign the activity, the workflow auto-assigns the activity. |
For example:
Name |
|
Pattern |
|
Branch IDs in workflows
A branch is a transition from one step to another.
Every branch has an ID, which is its reference name. An ID is necessary
because the Workflow instance sometimes needs to persist to the database
which branch it is trying to execute. (This can happen, for example,
if an error occurs in the branch and the workflow drops into the Error state). A branch ID must
be unique within a given step.
Generally, as you enter information in a dialog to define a step, you also need to enter branch information as well.
