Business Process Management

Gives an overview on the available Informatica BPM integration and provides a tutorial on how to build workflows which interact with Product 360

General

Since version 8.0 Product 360 allows to interact with the Informatica BPM system in an enhanced manner.

The interaction is using REST based message calls, to trigger workflow instances on Informatica BPM side on the one hand and to use various functionalities of the Product 360 system on the other hand.

Various functionalities means the whole functionality made available by the REST based Service API of the Product 360, which includes read and write access to entities like item, product, variant and much more, as well as the possibility to start data quality checks or e.g. to create tasks, which are involving an user interaction.

Informatica BPM was previously called ActiveVOS. We use the new name even though some tools and documents still refer to ActiveVOS.

Big picture

images/download/attachments/507895999/BPM_Integration_Communication.png

Additionally to the Product 360 application server an additional server instance will be available, carrying an Informatica BPM installation.

The Informatica BPM system is using specifically designed workflows for the customer needs, to interact with and control the Product 360 instances as well as other third party applications.

On the other hand the Product 360 system is able to initiate workflows within the Informatica BPM system. Both systems will use REST based APIs, whereby within the Product 360 system the Service API is available to be called from workflows.

The usual process on workflow execution in the Product 360 context starts with some action in Product 360. For example, an Import or a manual object modification or an export. Those actions have associated triggers which can be seen in the "Business process management" perspective's trigger list. For each of those triggers exist a separate list of trigger rules, which can optionally be activated and configured. For example, "After an Import, but only for a certain supplier", or "After an item modification, but only for certain fields". For this specific trigger configuration, the user can choose a Service Endpoint from a workflow which is deployed in the Informatica BPM instance.

As soon as the trigger is fired, the Workflow integration will call the Informatica BPM server and provides the items which are affected by the trigger. For example, the items which have been imported or changed. Informatica BPM now uses the Product 360 Service API to fetch additional data and execute processes like import, export, merge or data quality checks. In general everything that is possible with the Service API can be used here too.

Definition of triggers using the "Business process management" perspective

The BPM integration is based on events that will occur in the context of an entity. To act on different events it is possible to define triggers that will act as messaging between the Product 360 and the Informatica BPM.

Triggers are related to events which can be used to initiate a workflow call. Based on the information an event provides, there are filter possibilities to enable a more fine-grained control.

Every call to a workflow will have a specific payload of information rendered as xml which differs from trigger to trigger. To be able of implementing workflows on Informatica BPM side the following interface definition can be used.

Please see the larger section about Trigger Configuration below.

Item status

Concept of item related status information

Since business departments very often have the concept of a status where a single item could be within, e.g. 'translation' or 'review', there is now the possibility via the Service API to put one or multiple items in one or multiple status states.

This allows later to group items within the same status together by so called workflow tasks and show them to the user.

Status summary field

The item list in the explorer perspective will have a new calculated field available, called process status overview, which will show the status entries the given item is within.

images/download/attachments/507895999/field_selection.bmp

images/download/attachments/507895999/summary_field.bmp

User interaction - tasks and workflow tasks

To allow interaction with a user, the Product 360 provides the concept of tasks.
There are two types of tasks:

  • regular tasks

  • workflow tasks

Regular tasks will group some items together or in some cases not an item at all, but allowing a single user to accept the whole task in one.

Workflow tasks are different, they are more a container or a view of items belonging to a specific status at the moment of time. Instead of accepting the whole workflow task, the items are in focus and will be accepted one by one.
That concept allows multiple users to pick up items from a bigger pool of items to be worked on.

Custom plugins

Custom plugins can be used to add new triggers or call service endpoint of informatica BPM

Extension point of the trigger framework

Extension point: com.heiler.ppm.std.core.triggers

An extension should be declared in a core package, since client and server will need access to it.

To fire triggers you can use the TriggerService resolvable using the TriggerComponent.

BPMService & BPMComponent

To call a service endpoint there is the BPMService available, which can be retrieved using the BPMComponent.

The basic definition of the method is:

public void callServiceEndpoint( Object request, String endpointName, String correlationId ) throws CoreException;

The given request object, can be any object annotated with jaxb xml annotations like the following:

@XmlRootElement
@XmlAccessorType( XmlAccessType.FIELD )
public class JobFinished implements Serializable
{
private String stateLabel;
 
...
}

The endpoint name is that of the service name definied in the partner link section of the workflow deployment descriptor, e.g. 'SimpleWorkflow1-Start' .

The correlation id is used to determine the actual process instance of a workflow, this is something like '1232343'

Integration Tutorial

Integration between Product 360 and Informatica BPM is based on the Product 360 Service API see REST Service API for details).

Deploy Workflows in Informatica BPM

  • Start Active VOS designer and open workflow (import it as existing project)

  • To deploy workflow to BPM server, right click at project in Active VOS Designer and select Export. Use “Contribution – Business Process Archive” option.

  • After pressing Finish your workflow will be deployed to Informatica BPM server.

Calling the Service API from within a workflow

Product360 Service API is called through REST, so to use it from within the workflow action you can use build in functionality that exists in Informatica BPM. See section "Using a REST-based Service" of Informatica BPM documentation for the details.

The demo workflow that is available in the Product 360 Accelerator package is a good starting point for your own workflows.

Waiting for asynchronous Product 360 processes

Some Product 360 service APIs now support asynchronous requests which means that it is possible of providing a service endpoint callback. For details please refer to the REST Service API documentation.

Alternative approaches to get the status change of an item could also be a polling mechanism by using the Service API, the recommended way could be polling for the job status using the Product 360 Service API's byItems report of the JobHistory entity.

If Workflow Tasks are used it is possible to wait for a call to a specific service endpoint that will be triggered in case the item is finished. This approach can be used to notify a running workflow instance about a finished workflow task.

Provide Workflow Status Information and create Product 360 Tasks

In order to be able to provide statistical data for workflow processing within Product 360, the workflow needs to notify Product 360 whenever an item or multiple items enter or leave a certain status in a workflow. A status might contain multiple actions and steps in a workflow, it's up to the workflow designer to define which status are available in the workflow and when they begin and end. Some of those status are bound to a manual task which will result in a Workflow Task being created in Product 360, others don't and will only be recorded for statistical purposes.

Please note that the more different status an item can have in a workflow, the more load is put on the Product 360 application server since every status change needs to modify the item and actually persist the statistical data. So in general it's better to have only the status data which is really needed from a Product 360 perspective.

This diagram shows a typical, but abstract, workflow which integrates with Product 360. It provides two status, the first one just for statistical purposes (like "How long do my items take within the price calculation status"), the second one has also manual task properties which signals Product 360 that a Workflow Task should be created in the Task management. Of course, a status with manual task properties also has the full statistical information.

images/download/attachments/507895999/Workflow_Status.png

Start workflow

This action provides Product 360 the following information about the workflow:

  • Name of the workflow

  • List of workflow status and their order in the workflow

  • Definition of which workflow status are also manual tasks in Product 360

This information is used later on to manage workflow tasks in Product 360 and for statistical purposes (e.g. in the Product 360 Dashboard)

<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>

Action A

Any Product 360 action - the time for this action is part of the overall workflow processing time, but no separate statistic is logged for this action.

Enter Workflow Status "First Status"

<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/status/enter</rest:pathInfo>
<rest:headers>
<rest:header name="authorization" value="{$Authorization}"/>
<rest:header name="Content-Type" value="application/json"/>
<rest:header name="accept" value="application/json"/>
<rest:header name="bpm-correlation-id" value="{$processId}"/>
</rest:headers>
<rest:payload contentType="application/json">
{{
"processId": "{$processId}",
"workflowId": "{$workflowName}",
"status": "Classification",
"entity": "{$entityType}",
"hint": "{$hintClassification}",
"itemId": [ "{$entityId}" ]
}}
</rest:payload>
<rest:locales>
<rest:locale country="US" lang="en">en_US</rest:locale>
</rest:locales>
</rest:RESTRequest>

Action B + C

Any Product 360 action - the time for both actions is tracked in Product 360 as "First Status"

Leave Workflow Status

This call provides the workflow and the workflow status to leave to Product 360. It stops also the time measurement for the "First Status"

Action D

Any Product 360 action - the time for this action is part of the overall workflow processing time, but no separate statistic is logged for this action.

Enter Manual Workflow Status "Second Status"

This action starts a workflow task for an entity item. As a result, the entity item will be added to the corresponding Product 360 workflow task (as created in the "Start Workflow" step).

This call includes a correlation id, which is required by the next step. By default this correlation id is the process id (id of the workflow instance processing the current entity item).

It is passed as a http header field using the following naming:

bpm-correlation-id: 1234

Wait for Workflow Task Finished

This step waits for a notification from Product 360 that the corresponding workflow task has been finished. Again, the correlation id (provided by the previous step to Product 360) is send back as part of the notification.
This id is then used to correlate the Product 360 notification with the correct workflow instance. As a result, the corresponding workflow instance continues to the next action.

Action E

Any Product 360 action - the time for this action is part of the overall workflow processing time, but no separate statistic is logged for this action.

End Workflow

This action notifies Product 360 that a certain workflow instance is finished (identified by the process id). Optionally, a result message can be provided.

<rest:RESTRequest
xmlns:rest="http://schemas.activebpel.org/REST/2007/12/01/aeREST.xsd">
<rest:method>DELETE</rest:method>
<rest:pathInfo>rest/V1.0/manage/workflow/process?processId={ encode-for-uri( $processId ) }</rest:pathInfo>
<rest:headers>
<rest:header name="authorization" value="{ $Authorization }"/>
<rest:header name="Content-Type" value="application/json"/>
<rest:header name="accept" value="application/json"/>
</rest:headers>
<rest:payload contentType="application/json"> </rest:payload>
<rest:locales>
<rest:locale country="US" lang="en">en_US</rest:locale>
</rest:locales>
</rest:RESTRequest>

Error handling

It is important that Product 360 is informed about the end of a workflow instance, even in case of a failure of the workflow. Informatica BPM offers the concept of fault handlers, that can be used to catch all unexpected errors within the workflow execution.
This fault handler should include a call to End Workflow Process providing an error message explaining the reason for the failure. See the INFA BPM documentation for further information.

Details on the Workflow REST API, the parameters and examples how to use it can be found here.

Glossary

Term

Description

Workflow

Definition or blueprint of a workflow. You can compare it to a class in Java. Within Product 360, workflows are identified by a name which might include a version.
Informatica BPM identifies workflows by a plan id and a version.

Workflow Status

Part of a workflow, reflects a certain status (e.g. "English translation")

Workflow Process or Workflow Instance

Instance of a workflow which is executed on the Informatica BPM server.
Informatica BPM identifies workflow instances/processes by their process id.

Workflow Task

Special kind of Product 360 Tasks which are created and maintained by the workflow. There can be only one Workflow Task per Workflow and Status. Items which reach this status will all be shown in the item list of the Task. Users can pick single items to work on from this task (not the whole task as they do with the static and dynamic tasks)