A process, also known as a stepped-edit process, is the procedure for viewing and/or editing something by a sequence of pages that have next and previous buttons on them so that you can step through the pages. Each page can have a number of buttons, not just next and previous. Each time a button is presssed, the data being displayed is sent to the server to be saved, and a Process Workflow Event is generated. The workflow then has the opportunity to modify which page will be displayed next. See Processes for details on the stepped-edit processes.

Event Properties

As well as the standard properties that can be set on all events, the following properties can be set on this type of event:

 

Property

Description

Target Type

The BiskitDef of the biskit edited by the process.

Finish events

true if this event should be triggered by the user clicking the Finish button.

Next events

true if this event should be triggered by the user clicking the Next button.

Previous events

true if this event should be triggered by the user clicking the Previous button.

Reset Event

true if this event should be triggered by the user clicking the Reset button.

Help Events

true if this event should be triggered by the user clicking the Help button.

Initial Events

true if this event should be triggered by the initialisation of a stepped edit process.

 

Properties Available for Child Actions To Use

Property

Type

Description

new

old

Biskit whose type will be determined at run time

When a button is pressed, we are sent the details of the biskit displayed. When the display allowed the user to change information, then the values provided by the user will be stored in the new property and the values before the change will be stored in the old property. If this is the first step or the step wasn't an update, then new and old will be identical.

AuditLog

Biskit of type AuditLog

Information stored in the AuditLog for this change.

UserMakingTheChange

ExprodoUser

The user who performed the step, or null if it wasn't a real person.

EntityMakingTheChange

PermissionsUser

The user who performed the step. This might be a real user or a system user. When this is a real user, then EntityMakingTheChange is identical to UserMakingTheChange and it would actually be of type ExprodoUser.

Button

JavaEnum of Next, Previous, Reset, Help, Finish

The type of button pressed that caused this event to be triggered.

Response

Biskit of whose type is described below

The response to send. Modify this to change the next step and possibly add a message to be given to the user.

StepPerformed

Biskit of type Step

The step just performed by the user.

 

The Response property is a biskit with the following properties:

Property

Type

Description

nextStep

Biskit of type Step

The next step to be taken

message

String

A message to display to the user after this step

nextPageToken

String

The page to switch to. This should be the URL of the page that follows the '#'. For example, use 'about' to go to the 'About' page.

biskitToEdit

Biskit

The biskit that should be edited (only used for an initial event when starting the edit process)

messageType

Java Enum of ERROR, WARNING, INFO

Specifies whether the message being displayed is an error, a warning or just information.

 

A typical reason to use a Process Workflow Event is because you want an opportunity to modify some data between steps, or to display a message to a user between steps, or to choose which should be the next step to take. The default course of action is that the next step is decided by the definition of the process (see Processes), but you can have the choice of the next step be conditional using this event.

 

To do any of these things, you would use a Biskit Update Workflow Action to modify the biskit in the response property on the event.