Willems Workflow Scripting Language
WWSL is an abbreviation for Willems Workflow Scripting Language, published by the Willem Vermeer, and incorporating specifications to enable interoperability between different components of Liferays
applications.
WWSL includes:
* A range of API calls to support functions between a workflow engine and applications or other system components
* Interchange formats and protocols to support interoperability between different workflow engines
* Formats for the exchange of information such as process definitions and audit data between a workflow engine and other external repositories.
* Visualization of workflows to be embedded in online systems
History
WWSL was designed in 2013 mainly to improve the creation of workflow definitions for the Liferay Kaleo Workflow engine. Lacking a graphical editor, the manipulation of the standard workflow definition file is very cumbersome because of its verbose XML definition. In the first iteration of WWSL a parser was created which reads WWSL files and generates two output files:
# a valid Liferay workflow XML to be uploaded to the Liferay Workflow engine
# a javascript based definition of a graphical representation of the workflow. For visualization the jointJS javascript diagramming framework was used.
Features
A workflow definition consists of an begin and end state, tasks, transitions and actions. Take the following example of a very simple workflow:
<pre>workflow Simple Workflow
state created
initial true
transition submit @submit
task submit
assignment user
transition publish @publish
task publish
assignment Reviewer
onEntry #updateStatus("draft")
transition accept @finished
transition reject @submit
state finished</pre>
The first line of the file states the workflow name. Then the initial state is defined and its transition to the submit task. The submit task can only be assigned to the owning user. When the user submits this task somebody with the "Reviewer" role can then decide to either accept the submission, in which case the workflow finishes, or to reject it, which will pass the workflow back to the original submit task for the user to try again.
Workflows are used to manage the state of some object or asset in the underlying system. On entry into a task or exit out of it the status of the asset is changed and corresponding actions can be taken.
Synonyms
* Workflow APIs
* Workflow Management System APIs
applications.
WWSL includes:
* A range of API calls to support functions between a workflow engine and applications or other system components
* Interchange formats and protocols to support interoperability between different workflow engines
* Formats for the exchange of information such as process definitions and audit data between a workflow engine and other external repositories.
* Visualization of workflows to be embedded in online systems
History
WWSL was designed in 2013 mainly to improve the creation of workflow definitions for the Liferay Kaleo Workflow engine. Lacking a graphical editor, the manipulation of the standard workflow definition file is very cumbersome because of its verbose XML definition. In the first iteration of WWSL a parser was created which reads WWSL files and generates two output files:
# a valid Liferay workflow XML to be uploaded to the Liferay Workflow engine
# a javascript based definition of a graphical representation of the workflow. For visualization the jointJS javascript diagramming framework was used.
Features
A workflow definition consists of an begin and end state, tasks, transitions and actions. Take the following example of a very simple workflow:
<pre>workflow Simple Workflow
state created
initial true
transition submit @submit
task submit
assignment user
transition publish @publish
task publish
assignment Reviewer
onEntry #updateStatus("draft")
transition accept @finished
transition reject @submit
state finished</pre>
The first line of the file states the workflow name. Then the initial state is defined and its transition to the submit task. The submit task can only be assigned to the owning user. When the user submits this task somebody with the "Reviewer" role can then decide to either accept the submission, in which case the workflow finishes, or to reject it, which will pass the workflow back to the original submit task for the user to try again.
Workflows are used to manage the state of some object or asset in the underlying system. On entry into a task or exit out of it the status of the asset is changed and corresponding actions can be taken.
Synonyms
* Workflow APIs
* Workflow Management System APIs
Comments