This page describes the data structure of a workflow task as it's used in combination with the REST Workflow API. A workflow task has a limited number of attributes compared to a static task as most of it's attributes are defined by the workflow status to which it belongs.

Example
WorkflowTask
Task Callback
- Callback Payload for Finished state
- Callback Payload when the process must be terminated

Example

This is an example workflow which has multiple workflow tasks. In this example only typical and mandatory attributes are provided for the workflow task. Please see the table below for the full list of attributes which can be provided here.

<rest:RESTRequest
    xmlns:rest="http://schemas.activebpel.org/REST/2007/12/01/aeREST.xsd">
    <rest:method>POST</rest:method>
    <rest:pathInfo>rest/V1.0/manage/workflow</rest:pathInfo>
    <rest:headers>
        <rest:header name="authorization" value="{ $Authorization }"/>
        <rest:header name="bpm-correlation-id" value="{ $processId }"/>
        <rest:header name="Content-Type" value="application/json"/>
        <rest:header name="accept" value="application/json"/>
    </rest:headers>
    <rest:payload contentType="application/json">
{{
   "identifier": "{ $workflowName }",
   "label": "{$workflowName}",
   "version": "{$workflowVersion}",
   "status": [
      {{ "status": "Classification",
         "workflowTask" :  {{ "container" : "'{$catalogIdentifier}'", "entity" : "Article", "template" : "Item classification UI", "workflowServiceEndpoint" : "ApprovalWorkflowTaskClassification-Finish", "userGroup" : "AllRights" }}  }},
      {{ "status": "TranslateSpanish",
         "workflowTask" :  {{ "container" : "'{$catalogIdentifier}'", "entity" : "Article", "template" : "Item translation UI", "workflowServiceEndpoint" : "ApprovalWorkflowTaskTranslateSpanish-Finish", "userGroup" : "AllRights" }}  }},
      {{ "status": "TranslateItalian",
         "workflowTask" :  {{ "container" : "'{$catalogIdentifier}'", "entity" : "Article", "template" : "Item translation UI", "workflowServiceEndpoint" : "ApprovalWorkflowTaskTranslateItalian-Finish", "userGroup" : "AllRights" }}  }},
      {{ "status": "TranslateFrench",
         "workflowTask" :  {{ "container" : "'{$catalogIdentifier}'", "entity" : "Article", "template" : "Item translation UI", "workflowServiceEndpoint" : "ApprovalWorkflowTaskTranslateFrench-Finish", "userGroup" : "AllRights" }}  }},
      {{ "status": "Approve",
         "workflowTask" :  {{ "container" : "'{$catalogIdentifier}'", "entity" : "Article", "template" : "Item approve UI", "workflowServiceEndpoint" : "ApprovalWorkflow-Finish", "userGroup" : "AllRights" }},
        "rejectDecision": {{ "label": "Title of Reject Dialog", "singleChoice": true,
            "decisions": [{{ "label": "Classification", "id": "executeClassification" }},
                        {{ "label": "Translation", "singleChoice": false, "decisions":
                            [{{ "label": "Translate texts into French", "id": "executeTranslationFrench" }},
                             {{ "label": "Translate texts into Spanish", "id": "executeTranslationSpanish" }},
                             {{ "label": "Translate texts into Italian", "id": "executeTranslationItalian" }}
                            ]
                          }}
                       ]
          }}
      }}
     ]
}}
</rest:payload>
    <rest:locales>
        <rest:locale country="US" lang="en">en_US</rest:locale>
    </rest:locales>
</rest:RESTRequest>

WorkflowTask

Field	Datatype	Description
`container`	`ENTITY_ITEM`	The container, items of the workflow task are contained in. In case of Products, Variants or Items this would be a Catalog for example.
`entity`	`String`	Entity identifier of the task's content type.
`workflowServiceEndpoint`	`String`	The endpoint which is to be triggered on Informatica BPM side when a workflow task is marked as finished.
`workflowCommunicationMode`	`QUEUE/REST`	The communication mode which can define message queue or REST communication to BPM
`workflowQueueId`	`String`	The queue id from the server.properties which is defined by the syntax "queue.[queueId].name" which is used for the response message
`userGroup`	`ENTITY_ITEM`	The user group the task will be assigned to. Error if specified userGroup does not exist. At least one of the parameters user or userGroup or supplier have to be given. If none of them is given the creating user (see below "creationUser") will be used as assigned user by default. If user and userGroup are given the assignee user has priority. Error if supplier and user/userGroup are given.
`user`	`ENTITY_ITEM`	The user the task will be assigned to. Error if specified user does not exist. At least one of the parameters user or userGroup or supplier have to be given. If none of them is given the creating user (see below "creationUser") will be used as assigned user by default. If user and userGroup are given the assignee user has priority. Error if supplier and user/userGroup are given.
`supplier`	`ENTITY_ITEM`	The supplier the task will be assigned to. Error if specified supplier does not exist. Error if supplier does not match the supplier of catalog used for task content (container in the case of workflow task). At least one of the parameters user or userGroup or supplier have to be given. If none of them is given the creating user (see below "creationUser") will be used as assigned user by default. Error if supplier and user/userGroup are given.
`template`	`ENTITY_ITEM`	Identifier of the UI template the task is bound to (aka Flexible Task UI). Error in case the template for this identifier does not exist
`maximumDuration`	`Long`	The maximum amount of time in milliseconds an item residing in a workflow task can be worked on (after accepting) until the deadline for this item is reached. No functional impact as of now (only for information purposes).
`name`	`String`	The name of the task. Ideally a meaningful short description of what is to do.
`description`	`String`	Optional long description of the task.
`priority`	`Integer`	The priority of that task (pure information). When creating the priority "normal" is used. Error if given value does not exist in priority enumeration (0,1,2).

Task Callback

As soon as the user decides that the task is finished for a specific list of items of a workflow task, Informatica BPM will be called from Product 360 so BPM can move the affected workflow instances to the next step.

For this, you need to provide the workflowServiceEndpoint when the workflow task is created, and the processId when the item will enter the corresponding workflow status. Informatica Product 360 will call BPM for each workflow instance of this status so the workflow can be moved forward to the next action. Please note that Informatica BPM will be called for each process instance for this workflow.

Additionally to this pure "signal" we provide some payload data on the current process status the item was in when the user finished the task for the item. This way the workflow can decide what to do next without having to fetch this again from Product 360.

Callback Payload for Finished state

Here is an example of the payload which is given in the callback. Note that either user, or userGroup or supplier is given here. (TODO: correct!?)

Note: This extended callback payload is available with 8.1.1.00.05 and after.

<rest:RESTRequest xmlns:rest="http://schemas.activebpel.org/REST/2007/12/01/aeREST.xsd">
   <rest:method>POST</rest:method>
   <rest:headers>
      <rest:header name="bpm-correlation-id" value="8002"/>
      <rest:header name="connection" value="keep-alive"/>
      <rest:header name="host" value="localhost:8080"/>
      <rest:header name="Content-Length" value="1547"/>
      <rest:header name="accept" value="text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2"/>
      <rest:header name="Content-Type" value="text/xml"/>
   </rest:headers>
   <rest:payload contentType="text/xml">
      <decisions>
         <decision id="p360.bpm.finish"/>
         <processStatusInfo>
            <processIdentifier>8002</processIdentifier>
            <itemEntity>Article</itemEntity>
            <item>2401@1</item>
            <statusEntry>
               <attribute>
                  <name>workflow</name>
                  <value>905</value>
               </attribute>
               <attribute>
                  <name>status</name>
                  <value>Test Status1</value>
               </attribute>
               <attribute>
                  <name>startTime</name>
                  <value>2018-10-02T14:50:38:440+0200</value>
               </attribute>
               <attribute>
                  <name>lastStartTime</name>
                  <value>2018-10-02T14:50:38:443+0200</value>
               </attribute>
               <attribute>
                  <name>user</name>
                  <value>100</value>
               </attribute>
               <attribute>
                  <name>userGroup</name>
               </attribute>
               <attribute>
                  <name>supplier</name>
               </attribute>
               <attribute>
                  <name>endTime</name>
                  <value>2018-10-02T14:51:16:486+0200</value>
               </attribute>
               <attribute>
                  <name>duration</name>
                  <value>0</value>
               </attribute>
               <attribute>
                  <name>visitCounter</name>
                  <value>1</value>
               </attribute>
               <attribute>
                  <name>errorMessage</name>
                  <value>No error</value>
               </attribute>
               <attribute>
                  <name>acceptDate</name>
                  <value>2018-10-02T14:51:08:521+0200</value>
               </attribute>
               <attribute>
                  <name>deadline</name>
                  <value>2018-10-02T14:51:08:440+0200</value>
               </attribute>
               <attribute>
                  <name>creationDate</name>
                  <value>2018-10-02T14:50:38:480+0200</value>
               </attribute>
               <attribute>
                  <name>creationUser</name>
                  <value>300</value>
               </attribute>
               <attribute>
                  <name>modificationDate</name>
                  <value>2018-10-02T14:51:08:520+0200</value>
               </attribute>
               <attribute>
                  <name>modificationUser</name>
                  <value>100</value>
               </attribute>
               <attribute>
                  <name>hint</name>
               </attribute>
            </statusEntry>
         </processStatusInfo>
      </decisions>
   </rest:payload>
   <rest:ssl>false</rest:ssl>
   <rest:contextPath>/active-bpel</rest:contextPath>
   <rest:requestURI>/active-bpel/services/REST/TestStatus1-Finished</rest:requestURI>
   <rest:locales>
      <rest:locale country="US" lang="en">en_US</rest:locale>
   </rest:locales>
</rest:RESTRequest>

Field	Datatype	Description
`processIdentifier`	`String`	The process identifier, aka `correlationId` of the workflow process
itemEntity	String	The repository entity of the item which has been finished (e.g. Article, or Product2G etc.)
`item`	`ENTITY_ITEM`	The object for which the workflow task has been finished in the String Syntax of entity items
`statusEntry`	`StatusEntry[]`	The status entry object of the status the user just finished. Note: Although the model defines an array here, it can actually be only a single status entry each status represents a task the user finished working on.

The `StatusEntry` object
Field	DataType	Description
`workflow`	`ENTITY_ITEM (in String syntax)`	The workflow object this status entry belongs to
`status`	`String`	The identifier of the status
`user`	`ENTITY_ITEM (in String syntax)`	The user which finished the work on the item. It's either a supplier, or a user, never both.
`supplier`	`ENTITY_ITEM (in String syntax)`	The supplier which finished the work on the item. It's either a supplier, or a user, never both.
`errorMessage`	`String`
`hint`	`String`	Optional hint provided by the user when finishing the work. Example would be an approval task in which the approving user gives a hint as to what is not correct.
`startTime`	`Timestamp`	The first time the item started to be part of the workflow task. In other words, the first time the item entered this workflow state
`lastStartTime`	`Timestamp`	The last time the item started to be part of the workflow task. In other words, the last time the item entered this workflow state
`endTime`	`Timestamp`	The last time when the item finished this workflow task. In other words, the timestamp the item left this workflow state the very last
`acceptDate`	`Timestamp`	The time the user accepted the workflow task for this item the last time
`deadline`	`Timestamp`	The calculated deadline of the item in this workflow task. Based on the time the item entered the task (`startTime`) and the given `maximumDuration` for this status. (TODO: is this correct?)
`visitCounter`	`Long`	The number of times this state has been entered
`duration`	`Long`	The total duration the item was part of this workflow state. This means for each recurring enter/leave the time is summed up here.

Typically a workflow is designed to not trust the users very much. In case a data quality result will trigger the item to be part of a manual task, it's normal that the workflow will check the data quality again after the task has been finished. In case the data quality is still not correct, the workflow will loop back and enter the same workflow task again. So a user which "just finishes" a task, without actually solving the data quality issue of the item, will get this item back.

In other words, the same item can be multiple time in the same status of the same workflow instance. Therefore we do record how many times the item was in this state (visitCounter) and we sum up the total duration of the item in this state (duration).

Callback Payload when the process must be terminated

In case a workflow id deleted in Product360 while there are still instances running, or because of other scenarios, Product 360 will contact BPM with a predefined terminate process endpoint. The identifier of this endpoint is P360-TerminateProcessInstance.

Even in this case, in which the user did not finish a task by himself, but the system terminated the workflows we provide as much information as possible to the workflow.

Field	Datatype	Description
`processIdentifier`	`String`	The process identifier, aka `correlationId` of the workflow process
`item`	`ENTITY_ITEM`	The object for which the workflow task has been finished
`statusEntry`	`StatusEntry[]`	An array of status entry objects of all the status the item was currently in at the time the workflow got terminated. In contrary to the payload when the user finishes his work for a specific status (above) this payload contains the entries of all status - as all of them terminated at once. For details on the StatusEntry object please see above