| Product Version |
|
|---|
| Report Note |
|
|---|
| Assignee |
|
|---|
Resources & Remarks Modification History | Name | Date | Product Version | Action |
|---|
| Antje | 23 JUL 2021 | 2021 Autumn | created | | Martin | 26 JUL 2021 | 2021 Autumn | draft | | Bratislav | 29 JUL 2021 | 2021 Autumn | draft | | Antje | 29 JUL 2021 | 2021 Autumn | formatting, published | | Agnieszka | 25 AUG 2021 | 2021 Autumn | rLANG | | Martin | 24 SEP 2021 | 2021 Winter | Added the section for starting processes with a startform |
Hallo Antje, ich würde gerne noch eine Sektion einbauen, die Client-spezifische Flowable Variablen listet und beschreibt. Task parameter
(Web-API Gateway GET tasks) | Example format | Flowable variable name | Example format | Description |
|---|
subject | "subject": "My subject" | appClientsystem_subject |
| Code Block |
|---|
{
"action": "save",
"variables": [
{
"name": "appClientsystem_subject",
"type": "string",
"value": "My subject"
} |
| Process subject The client-specific task parameter subject is presented in the Inbox column Subject. The parameter can be set using the Web-API Gateway GET/PUT endpoints for tasks or the corresponding BPM-API endpoints for saving the variable appClientsystem_subject. | attachments | "attachments": ["GUID1","GUID2", "GUID2"] | appClientsystem_attachments |
| Code Block |
|---|
{
"action": "save",
"variables": [
{
"name": "appClientsystem_attachments",
"type": "json",
"value": [
"GUID1",
"GUID2"
]
} |
| Process attachments The client-specific task parameter attachment is used for the task aspect Attachments in the Inbox. This parameter contains an array of object GUIDs. The user sees the title of the corresponding objects in the list of attachments. The parameter can be set using the Web-API Gateway GET/PUT endpoints for tasks or the corresponding BPM-API endpoints for saving the variable appClientsystem_attachment. | taskMessages | Example code for the GET tasks response of the Web-API Gateway: | Code Block |
|---|
"taskMessages": [
{
"message": "messageWithoutColor"
},
{
"level": "error",
"message": "messageError",
"type": "ul"
},
{
"level": "warning",
"message": "messageWarning",
"type": "ul"
},
{
"level": "info",
"message": "messageError"
},
{
"message": "Not translated message"
}
] |
| appClientsystem_taskMessages | Example code for saving the Flowable variable appClientsystem_taskMessages via BPM-API PUT tasks: | Code Block |
|---|
{
"action": "save",
"variables": [
{
"name": "appClientsystem_taskForm",
"type": "json",
"value": {
"schemaProperties": [
"tenKolibri:strsingle",
"tenKolibri:datesingle"
]
}
},
{
"name": "appClientsystem_taskMessages",
"type": "json",
"value": [
{
"message": "messageWithoutColor"
},
{
"level": "error",
"message": "messageError",
"type": "ul"
},
{
"level": "warning",
"message": "messageWarning",
"type": "ul"
},
{
"level": "info",
"message": "messageError"
},
{
"message": "Not translated message"
}
]
}
]
} |
| Dynamic Task Messages This client-specific task parameter can be used to present necessary information for working on this particular task. The messages are presented on the top of the task aspect area in the inbox. The parameter level differentiates 4 types of formating the messages: | level | description |
|---|
| without level | The message is rendered in the normal format | | info | The text is rendered in the accent color | | error | Text is rendered in Red | | warning | Text is rendered in Orange |
In this case, the message is a localization key the key will be translated (see "messageError" in the example). The keys need not '_lalbe' as it is for the name for a form field. '"Type": "ul" can be used to render messages with this setting in a list. The task parameter taskMessages is responded in the GET tasks endpoint of the Web-API Gateway and can only be set by saving the Flowable variable appClientsystem_taskMessages. 
| taskForm | Example code for the GET tasks response of the Web-API Gateway using schemaProperties: | Code Block |
|---|
"taskForm": {
"schemaProperties": [
"tenKolibri:strsingle",
"tenKolibri:datesingle"
] |
Example code for the GET tasks response of the Web-API Gateway using a form model:
| Code Block |
|---|
"taskForm": {
"model": {
"name": "twosteptest_proc:2nd_task",
"situation": "EDIT",
"script": "",
"elements": [
{
"name": "core",
"type": "o2mGroup",
"elements": [
{
"type": "o2mGroup",
"layout": {
"align": "row"
},
"elements": [
{
"type": "o2mGroup",
"name": "twosteptest_proc:simplefields",
"layout": {
"align": "column"
},
"elements": [
{
"name": "twosteptest_proc:date",
"labelkey": "Date",
"type": "datetime",
"required": false,
"cardinality": "single",
"readonly": false,
"resolution": "date"
},
{
"name": "twosteptest_proc:string",
"type": "string",
"cardinality": "single",
"required": false,
"rows": 1,
"readonly": false
}
]
}
]
}
]
}
]
] |
| appClientsystem_taskForm | Example code for saving the Flowable variable appClientsystem_taskForm via BPM-API PUT tasks using schemaProperties: | Code Block |
|---|
{
"action": "save",
"variables": [
{
"name": "appClientsystem_taskForm",
"type": "json",
"value": {
"schemaProperties": [
"tenKolibri:strsingle",
"tenKolibri:datesingle"
]
}
}
]
} |
Example code for saving the Flowable variable appClientsystem_taskForm via BPM-API PUT tasks using a form model: | Code Block |
|---|
{
"action": "save",
"variables": [
{
"name": "appClientsystem_taskForm",
"type": "json",
"value": {
"model":
{
"name": "twosteptest_proc:2nd_task",
"situation": "EDIT",
"script": "",
"elements": [
{
"name": "core",
"type": "o2mGroup",
"elements": [
{
"type": "o2mGroup",
"layout": {
"align": "row"
},
"elements": [
{
"type": "o2mGroup",
"name": "twosteptest_proc:simplefields",
"layout": {
"align": "column"
},
"elements": [
{
"name": "twosteptest_proc:date",
"labelkey": "Date",
"type": "datetime",
"required": false,
"cardinality": "single",
"readonly": false,
"resolution": "date"
},
{
"name": "twosteptest_proc:string",
"type": "string",
"cardinality": "single",
"required": false,
"rows": 1,
"readonly": false
}
]
}
]
}
]
}
]
}
}
}
]
} |
| Dynamic Task Form This client-specific task parameter can be used to present dynamically only those form fields that are relevant to be handled by the user. If the given property name does not have a representation in the schema it will be ignored other the attributes of this property will be used in the form. There are two ways to handle a dynamic form offered: - Using
schemaProperties the relevant property names can be listed. - Using model a usual form model syntax can be used for more complex forms.
|
|