Skip to main content

Overview

The UserActionDTO dynamically generates actions on the UI and submits them to the server. The actions can be either form actions or workflow actions. Form actions relate to product-specific actions, while workflow actions are used to move the workflow. Form actions have UI elements, such as buttons connected to them. For these to be rendered correctly, form actions can’t be removed or added. However, workflow actions are dynamically rendered, so they can be customized. This section refers only to workflow actions. The UserActionDTO looks as follows:
The WorkflowTaskActionDTO inherits all the fields of UserActionDTO and looks as follows:
The UserActionInputFieldDTO tells the UI which kind of component to render and looks as follows:
where UserActionInputFieldInputType can be one of:
We have added lombok builder methods to quickly create instances of this class.

Define the beans

Depending on the type of WorkflowTaskActionDTO supplied to the UI, it will render a button that on clicking will either:
  • Execute an action
  • Show a popup for submission and then execute an action

1. Execution only action

The simplest instance of a WorkflowTaskActionDTO looks as follows:
In this case, a button will appear on the UI with the label Approve and when clicked, it will submit a response to the server to execute the task specified by the task key “Approve”. For more information on how the task is executed, see Executing the Java Task.

2. Popup with execution action

A more complex instance of a WorkflowTaskActionDTO will specify input fields to be rendered in the UI, updated and submitted to the server. It can also provide a defaultValue for fields, which will pre-populate the input field in the UI. Example:
In this example, we define two input fields: Classification and Risk Comment, with the following properties:
  • Classification is required, so the form may not be submitted until its value is filled. Risk Comment is not specified as required, so it defaults to false.
  • Classification has input type SELECT, so the options listed will be available in a dropdown.
  • Risk Comment has input type TEXT, so a text field will appear requesting input.

Import the beans

Once defined, the beans can then be imported into the Atoti Sign-Off project. A nice convention is to have one @Configuration file per workflow, and to import these into a parent @Configuration. Then, this one parent @Configuration can be imported to the project. For example, the out-of-the-box workflow actions are included in WorkflowTaskActionsConfig:
  • and the ProcessDefinitionWorkflowActionsConfig class contains the actions related to the process definition workflow: