Step Workflow
Preface
The StepWorkflow project is a workflow with the following objectives:
You don't need to be a BPM (AVOS) expert to design workflows for MDM-Product 360 business use cases
Development of new workflows is more structured (in comparison to previous developments)
Easier to troubleshoot
Less issues because of tested re-usable code
Reduce the amount of running processes on the BPM server
Enable batching
Table of Contents
Prerequisites
The StepWorkflow is designed for the queue communication. Therefor Product 360 must also be configured for Queue communications. Please reach out to the Installation and Operation guide for the following areas:
Configuration of queues in the Product 360 server
Installation of ActiveVOS with ActiveMQ support and configuration of queues in ActiveVOS (Note: ActiveVOS version 9.2.4.6 is a prerequisite for queue based interactions between Product 360 and ActiveVOS)
Message headers and message formats for the various interactions between Product 360 and ActiveVOS
Installation
Before you can design your workflows based on the StepWorkflow you have to deploy these 4 resources:
InfaResources.bpr
StepWorkflow.bpr
InfaNextSteps.bpr
StepWorkflowExamples.bpr (optional)
with the BPM (AVOS) console.
Also it is possible that you deploy the workflows with your BPM designer. The resources of the projects are in the zip files:
InfaResources.zip
StepWorkflow.zip
InfaNextSteps.zip
StepWorkflowExamples.zip
Configuration
The base configuration of the StepWorkflow is defined in the BPM URN mappings. Therefore you have to define the following mappings in the BPM console.
|
URN |
URL |
Description |
|
urn:p360.api.username |
RestServiceUser |
Name of the Product 360 user in which context the requests are fired |
|
urn:p360.api.password |
******** |
Password of the user above |
|
urn:p360.api.manager |
ActiveMQ |
Name of the configured messaging service of the BPM server |
|
urn:p360.api.queue |
JNDI_P360_SERVICE_API |
JNDI name of the queue for the service calls |
|
urn:p360.rest.url |
http://p360server:1512 |
Url of the Product 360 rest services |
|
urn:dq.timeout |
PT4H |
Timeout for DQ calls |
|
urn:p360.api.data.quality.queue |
JNDI_P360_DATA_QUALITY |
JNDI name of the queue for the Data Quality calls |
|
urn:p360.api.data.quality.response.queue |
bpm_response |
Identifier if the response queue for DQ calls (default: bpm) |
|
urn:list.get.timeout |
PT4H |
Timeout for list calls |
|
urn:merge.delay |
PT30S |
Delay before starting the merge process |
|
urn:error.task.group |
Superuser |
Identifier of the usergroup for which a classic task will be created if an error happens within the StepWorkflow. (i.e. Step Id is not defined) |
|
urn:workflow.resource.project |
StepWorkflowExamples |
Name of the project (AVOS catalog) where the Mapfile is stored |
StepWorkflow XML files
The StepWorkflow itself contains sever xml files in the catalog resources.
|
Name |
Description |
|
StepWorkflowMap.xml |
This xml file defines the mapping between a Product 360 trigger configuration, Product 360 workflow identifier and a stepworflow.xml file. |
|
StepWorkflow.xml |
Such a file defines the steps for a specific business workflow. The name of the file should be adapted to your use case. A valid example can be ItemCreation.xml. |
|
ManufacturerTeams.xml |
This xml file defines the mapping between Product 360 usergroups and Product 360 suppliers (manufacturers). This is a showcase how to create tasks to different groups based on the manufacturer. |
The StepWorkflowMap.xml file
|
Tag |
Description |
|
files |
Within the files tag are the different file mappings that need to be defined |
|
file |
Each business workflow definition needs to be defined in this tag. |
|
path |
Path and name of the workflow. (Case-sensitive!) |
|
triggerConfiguration |
Name of the Product 360 trigger configuration. |
|
workflowIdentifier |
Identifier of the Product 360 workflow. |
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <files> <file> <workflowIdentifier>Default_Workflow_Article</workflowIdentifier> <path>project:/StepWorkflow/workflow/DefaultArticle.xml</path> </file> <file> <workflowIdentifier>Default_Workflow_Product2G</workflowIdentifier> <path>project:/StepWorkflow/workflow/DefaultProduct2G.xml</path> </file> <file> <workflowIdentifier>Default_Workflow_Variant</workflowIdentifier> <path>project:/StepWorkflow/workflow/DefaultVariant.xml</path> </file> <file> <triggerConfiguration>Example01</triggerConfiguration> <workflowIdentifier>Workflow_01</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_01.xml</path> </file> <file> <triggerConfiguration>Example02</triggerConfiguration> <workflowIdentifier>Workflow_02</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_02.xml</path> </file> <file> <triggerConfiguration>Example03</triggerConfiguration> <workflowIdentifier>Workflow_03</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_03.xml</path> </file> <file> <triggerConfiguration>Example04</triggerConfiguration> <workflowIdentifier>Workflow_04</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_04.xml</path> </file> <file> <triggerConfiguration>Example05</triggerConfiguration> <workflowIdentifier>Workflow_05</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_05.xml</path> </file> <file> <triggerConfiguration>Example06</triggerConfiguration> <workflowIdentifier>Workflow_06</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_06.xml</path> </file> <file> <triggerConfiguration>Example07</triggerConfiguration> <workflowIdentifier>Workflow_07</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_07.xml</path> </file> <file> <triggerConfiguration>Example08</triggerConfiguration> <workflowIdentifier>Workflow_08</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_08.xml</path> </file> <file> <triggerConfiguration>Example09</triggerConfiguration> <workflowIdentifier>Workflow_09</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_09.xml</path> </file> <file> <triggerConfiguration>Example10</triggerConfiguration> <workflowIdentifier>Workflow_10</workflowIdentifier> <path>project:/StepWorkflow/workflow/Workflow_10.xml</path> </file> </files></imp:payload>
The StepWorkflow.xml file
The separate StepWorkflow.xml files define the different business workflows. In this chapter we will describe, and provide examples for different workflows. If you want to create new xml files within your workflow you have to open the StepWorkflow project in BPM designer and add a new xml file in the workflow folder with the tag imp:payload to ensure that this file will be deployed with your workflow. After that, you have to register this new xml file in the StepWorkflowMap.xml file.
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <!-- This is a description and sample values of the fields in the Workflow Detail files and should not be used directly You should not use xml files with a lot of comments for live processing. Please remove all comments in your Workflow Detail files --> <workflow> <label>My Stepworkflow</label> <!-- Name of the workflow that is visible in the UI --> <identifier>My_Stepworkflow_V1</identifier> <!--Name of the workflow not visible in the UI must be unique thru all workflows --> <version>1.0</version> <!--version number of the workflow needs to be incremented by one if a Status, Usergroup, description, decision or UiTemplate has been changed --> <step> <!-- These are the steps to the workflow. They do not have to include entering into a task --> <id>1.1</id> <!-- This is the identifier of each step. They must be unique within a workflow. While generally numeric in nature, can be any string value. --> <entity>Article</entity> <!-- This is the entity container that the items will be placed in within the workflow in Product 360. Valid values are: Article Variant Product2G --> <workflowStatus>StartCE01</workflowStatus> <!-- This will be the status name within the Product 360 workflow. It will be the second part of the name of the task name in Product 360: Product 360 task name = [Workflow] - [Status] - [Catalog] --> <description>Desc 1.1</description> <!-- Description of the status. It will be displayed in the task in the Product 360 UI --> <enterStatus>Never</enterStatus> <!-- The circumstances when an item should enter a status (task): OnDqResults=Item(s) will enter the task/status on DQ failures or move to the next step on successfuls. Never=This is for steps that do not include a task Always=Item(s) will always enter a task/status the first time the step is run. Subsequent times are based on the dq results. --> <batchSize>500</batchSize> <!-- This is the batch size to use with trigger batching. If the tirggers coming from Product 360 have a large number of entities, this can break them down. Batch sizes can make Product 360 requests more efficient --> <userType>userGroup</userType> <!-- Type of the default assignee valid values: user userGroup supplier ==> mandatory field: <getField>Article.MainSupplier->Party.Name</getField> has to be set!--> <userName>Standardusers</userName> <!--Default assignee of the task. Should be either a Product 360 user or userGroup --> <uiTemplate>Item approve UI</uiTemplate> <!-- default UI of the task --> <singleChoice>true</singleChoice> <!-- This is for Rejects only and determines if you can have more than one choice. Should be true or nothing as it defaults to 'false' --> <rejectDecision> <id>p360.bpm.reject.TRIGGER:4.1</id> <!-- Always starts with 'p360.bpm.reject.' Can continue with: STEP : Which step is rejected ex. p360.bpm.reject.STEP:5.1 TRIGGER : Which parallel task is rejected ex. p360.bpm.reject.TRIGGER:4.1 SERVICE : Which process is generated with the reject ex. p360.bpm.reject.TaskByManufacturer-Workflow --> <label>Maintain texts</label> <!-- The label of the task being rejected. --> </rejectDecision> <executeDq>Always</executeDq> <!-- The circumstances when a DQ should be run: Always=DQ will be executed whenever this step is run regardless of whether it was run as a next step or from a trigger. OnTrigger=DQ will run only when the process was started from a trigger in Product 360 and not from a previous step. Never=DQ is not used for this step. --> <dqService>ExecuteDqBatch-Process</dqService> <!-- The service name of the process that will be handle the processing of the dq or any custom built business rules. --> <dqRule>Item image check</dqRule> <!-- List any Product 360 DQ rules you want to have run with a step. You can have multiple entries. --> <dqRuleGroup>Item descriptions</dqRuleGroup> <!-- List any Product 360 DQ ruleGroups you want to have run with a step. You can have multiple entries. --> <dqChannel>01 Classify</dqChannel> <!-- List any Product 360 DQ channels you want to have run with a step. You can have multiple entries. --> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <!-- This field allows the step to update a field in Product 360. The field must be fully qualified. --> <updateFieldValue>600</updateFieldValue> <!-- This is the value for the update. --> <getField>Article.CurrentStatus</getField> <!-- List of any fields directly on the entity that will be required. These entries must be fully qualified. --> <nextStep>STEP:3.1</nextStep> <!-- This is the step that the item(s) will move to if dq is successful or there is no dq. It must start with STEP: to move to a step. Otherwise it will be interpreted as a BPEL service that you can use for custom code. In both cases a the item(s) are sent in list using the ItemMap schema. --> <dqFailStep>TaskByManufacturer-Workflow</dqFailStep> <!-- This is the step that the item(s) move to if dq fails It must start with STEP: to move to a step. Otherwise it will be interpreted as a BPEL service that you can use for custom code. In both cases a the item(s) are sent in list using the ItemMap schema. --> <nextStep>StepWorkflow_ParallelTasks-Workflow</nextStep> <!-- StepWorkflow_ParallelTasks-Workflow should be used for steps that run in parallel --> <dqFailStep>StepWorkflow_ParallelTasks-Workflow</dqFailStep> <!-- StepWorkflow_ParallelTasks-Workflow should be used for steps that run in parallel --> <parallelStep>4.1</parallelStep> <!-- This is where you list parallel steps if a step should go to multiple steps at the same time --> <parallelNextStep>5.1</parallelNextStep> <!-- If all the parallel steps finish, then the item will move to this step --> <dqFailTrigger>StepWorkflow_ParallelTasks-Finish-3</dqFailTrigger> <!-- Used to route to the Parallel steps after logic in StepWorkflow process is finished. --> <nextTrigger>StepWorkflow_ParallelTasks-Finish-3</nextTrigger> <!-- Used to route to the Parallel steps after logic in StepWorkflow process is finished. --> </step> </workflow></imp:payload>Examples
Steps to run the examples
Check the table "Prerequisites for Product 360" and prepare your system accordingly.
Option 1
Open the BPM console in your web browser and navigate to Admin/URN Mappings and create the mapping "urn:workflow.resource.project" and set the value to "StepWorkflowExamples".
Define the trigger in the perspective "Business process management" in your MDM-Product 360 Desktop client. (refer to the StepWorkflowMap file in the examples project)
Option 2
Open the BPM console in your web browser and navigate to Catalog/Contributions/project:/StepWorkflowExamples and click on it.
Select one of the png files and click on it to see the flow of the workflow.
Select one of the xml files, i.e. Example_01.xml click on it and copy the content into your clipboard.
Now navigate to Catalog/Contributions/project:/StepWorkflow and click on it.
Select one of the xml files, i.e. Workflow_01.xml and click on it to enable the editing mode.
Copy the content of your clipboard and paste it into the browser window.
Click on update.
Make the necessary adjustments in the file: StepWorkflowMap.xml. (It is recommended to use Workflow_01.xml for the Example_01.xml and so on.)
Define the trigger in the perspective "Business process management" in your MDM-Product 360 Desktop client.
Finished!
Example 1 (1 Task)
The first workflow only puts items into a workflow task called “My first task” For this workflow task we need 2 steps. The first step checks whether the affected item is already in this workflow, if not it will be put into the task. The first step is mandatory and will be very useful in subsequent examples. With this approach you can ensure that the item is not in the same workflow more than one time. This is very important for typical approval workflows.
Diagram for example 1
Explanation of the steps example 1
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "My first task". |
Product 360 prerequisites for example 1
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
Info
Standarduser is the Identifier of the Usergroup!
StepWorkflow.xml file for example 1
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 1</label> <identifier>Workflow_01</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My first task</workflowStatus> <description>My first workflow task</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 0
This steps checks only whether the item is already in this workflow. If not the executed next step is 1. If yes the workflow will end because there is no next step defined.
|
Key |
Value |
Description |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:1 |
The item will be moved to the step with the identifier 1 if the above dq fails. |
Step 1
This steps checks only whether the item is already in this workflow. If not the executed next step is 1. If yes the workflow will end because there is no next step defined.
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My first task |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My first workflow task |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
Example 2 (2 Tasks)
The next example extends the first example with a further task after the first task.
Diagram for example 2
Product 360 prerequisites for example 2
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
Explanation of the steps example 2
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "My task 1". |
|
2 |
Put the item into the task "My task 2". |
StepWorkflow.xml file for example 2
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 2</label> <identifier>Workflow_02</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <nextStep>STEP:2</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>Detailed explanation of the steps
Only the differences to the previous example will be explained.
Step 0
Step 0 is an exact copy of the step 0 of the example 1.
Step 1
Step 1 is nearly the same as the step 1 of the example above. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in example 1. |
|
workflowStatus |
My task 1 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 1 |
Description of the status. |
|
nextStep |
STEP:2 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 2
Step 2 is mostly a copy of step 1.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than step 1. |
|
id |
2 |
Identifier of the step. |
|
workflowStatus |
My task 2 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 2 |
Description of the status. |
|
|
This step contains no next step, because the workflow have to end at this point. |
Example 3 (2 Tasks with DQ checks)
The next example extends the previous example so that the tasks will only be created when the DQ check fails.
Diagram for example 3
Product 360 prerequisites for example 3
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
|
DQ Channel |
Channel 1 |
|
DQ Channel |
Channel 2 |
Explanation of the steps example 3
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Run DQ check "Channel 1" if fail ==>put the item into the task "My task 1" |
|
2 |
Run DQ check "Channel 2" if fail ==>put the item into the task "My task 2" |
StepWorkflow.xml file for example 3
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 3</label> <identifier>Workflow_03</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 1</dqChannel> <nextStep>STEP:2</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 2</dqChannel> </step> </workflow></imp:payload>Detailed explanation of the steps
Only the differences to the previous example will be explained.
Step 0
Step 0 is an exact copy of the step 0 of the example 2.
Step 1
Step 1 is nearly the same as the step 1 of example 2. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in example 2. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter a status (task). In this case only when DQ check will fail! |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
ExecuteDqBatch-Process |
The service name of the process that will be handle the processing of the dq. |
|
dqChannel |
Channel 1 |
Name of the DQ channel which will be executed. |
Step 2
Step 2 is nearly the same as the step 1 of the example above.
Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in example 2. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter a status (task). In this case only when DQ check will fail! |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
ExecuteDqBatch-Process |
The service name of the process that will be handle the processing of the DQ. |
|
dqChannel |
Channel 2 |
Name of the DQ channel which will be executed. |
Example 4 (5 Tasks with DQ checks, parallel and sequential)
Example 4 starts with 2 sequential tasks, after that there are 2 tasks which are running in parallel and after finishing those 2 parallel tasks the last task will start.
Diagram for example 4
Product 360 prerequisites for example 4
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
|
DQ Channel |
Channel 1 |
|
DQ Channel |
Channel 2 |
|
DQ Channel |
Channel 3.1 |
|
DQ Channel |
Channel 3.2 |
|
DQ Channel |
Channel 4 |
Explanation of the steps example 4
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Run DQ check "Channel 1" if fail ==>put the item into the task "My task 1" |
|
2 |
Run DQ check "Channel 2" if fail ==>put the item into the task "My task 2" |
|
3.1 |
Run DQ check "Channel 3.1" if fail ==>put the item into the task "My task 3.1" |
|
3.2 |
Run DQ check "Channel 3.2" if fail ==>put the item into the task "My task 3.2" |
|
4 |
Run DQ check "Channel 4" if fail ==>put the item into the task "My task 4" |
StepWorkflow.xml file for example 4
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 4</label> <identifier>Workflow_04</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 1</dqChannel> <nextStep>STEP:2</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 2</dqChannel> <nextStep>StepWorkflow_ParallelTasks-Workflow</nextStep> <parallelStep>3.1</parallelStep> <parallelStep>3.2</parallelStep> <parallelNextStep>4</parallelNextStep> </step> <step> <id>3.1</id> <entity>Article</entity> <workflowStatus>My task 3.1</workflowStatus> <description>My task 3.1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 3.1</dqChannel> <dqFailTrigger>StepWorkflow_ParallelTasks-Finish-1</dqFailTrigger> <nextTrigger>StepWorkflow_ParallelTasks-Finish-1</nextTrigger> </step> <step> <id>3.2</id> <entity>Article</entity> <workflowStatus>My task 3.2</workflowStatus> <description>My task 3.2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 3.2</dqChannel> <dqFailTrigger>StepWorkflow_ParallelTasks-Finish-2</dqFailTrigger> <nextTrigger>StepWorkflow_ParallelTasks-Finish-2</nextTrigger> </step> <step> <id>4</id> <entity>Article</entity> <workflowStatus>My task 4</workflowStatus> <description>My task 4</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 4</dqChannel> </step> </workflow></imp:payload>Detailed explanation of the steps
Only the differences to the previous example will be explained.
Step 0
Step 0 is an exact copy of the step 0 of example 3.
Step 1
Step 1 is an exact copy of the step 1 of example above 3.
Step 2
Step 2 is nearly the same as the step 2 of the example above. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in example 3. |
|
nextStep |
StepWorkflow_ParallelTasks-Workflow |
StepWorkflow_ParallelTasks-Workflow defines that the next steps run in parallel |
|
parallelStep |
3.1 |
Identifier of the first parallel step, the item will be moved to this parallel step. The maximum number of parallel steps is 6. |
|
parallelStep |
3.2 |
Identifier of the second parallel step, the item will be moved also to this parallel step. |
|
parallelNextStep |
4 |
The item will be moved to this step when all parallel steps are finished. |
Step 3.1
|
Key |
Value |
Description |
|
id |
3.1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My task 3.1 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 3.1 |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter a status (task). In this case only when DQ check will fail! |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
ExecuteDqBatch-Process |
The service name of the process that will be handle the processing of the DQ. |
|
dqChannel |
Channel 3.1 |
Name of the DQ channel which will be executed. |
|
dqFailTrigger |
StepWorkflow_ParallelTasks-Finish-1 |
This is the service name of the partner link of the parallel tasks. It will be called if DQ fails to ensure that the item will remain in the status (task). |
|
nextTrigger |
StepWorkflow_ParallelTasks-Finish-1 |
This is another service name of the partner link of the parallel tasks. It will be called if the item will leave this step. |
Step 3.2
Step 3.2 is nearly the same as the step 3.1. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
id |
3.1 |
Identifier of the step. |
|
workflowStatus |
My task 3.2 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 3.2 |
Description of the status. |
|
dqChannel |
Channel 3.2 |
Name of the DQ channel which will be executed. |
|
dqFailTrigger |
StepWorkflow_ParallelTasks-Finish-2 |
This is the service name of the partner link of the parallel tasks. It will be called if DQ fails to ensure that the item will remain in the status (task). |
|
nextTrigger |
StepWorkflow_ParallelTasks-Finish-2 |
This is another service name of the partner link of the parallel tasks. It will be called if the item will leave this step. |
Step 4
|
Key |
Value |
Description |
|
id |
4 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My task 4 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 4 |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter a status (task). In this case only when DQ check will fail! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
ExecuteDqBatch-Process |
The service name of the process that will be handle the processing of the DQ. |
|
dqChannel |
Channel 4 |
Name of the DQ channel which will be executed. |
Example 5 (extending example 4 with an approval step)
The next example extends the previous example with an approval step at the end of the workflow, so the approver can reject the item to all of the previous steps.
Diagram for example 5
Product 360 prerequisites for example 5
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
|
DQ Channel |
Channel 1 |
|
DQ Channel |
Channel 2 |
|
DQ Channel |
Channel 3.1 |
|
DQ Channel |
Channel 3.2 |
|
DQ Channel |
Channel 4 |
Explanation of the steps example 5
|
Step |
Description |
|
0 |
Check whether item is already in this workflow |
|
1 |
Run DQ check "Channel 1" if fail ==>put the item into the task "My task 1" |
|
2 |
Run DQ check "Channel 2" if fail ==>put the item into the task "My task 2" |
|
3.1 |
Run DQ check "Channel 3.1" if fail ==>put the item into the task "My task 3.1" |
|
3.2 |
Run DQ check "Channel 3.2" if fail ==>put the item into the task "My task 3.2" |
|
4 |
Run DQ check "Channel 4" if fail ==>put the item into the task "My task 4" |
|
5.0 |
Check whether item is already in this workflow. |
|
5 |
Approve task with rejection options to all previous tasks |
StepWorkflow.xml file for example 5
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 5</label> <identifier>Workflow_05</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 1</dqChannel> <nextStep>STEP:2</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 2</dqChannel> <nextStep>StepWorkflow_ParallelTasks-Workflow</nextStep> <parallelStep>3.1</parallelStep> <parallelStep>3.2</parallelStep> <parallelNextStep>4</parallelNextStep> </step> <step> <id>3.1</id> <entity>Article</entity> <workflowStatus>My task 3.1</workflowStatus> <description>My task 3.1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 3.1</dqChannel> <dqFailTrigger>StepWorkflow_ParallelTasks-Finish-1</dqFailTrigger> <nextTrigger>StepWorkflow_ParallelTasks-Finish-1</nextTrigger> </step> <step> <id>3.2</id> <entity>Article</entity> <workflowStatus>My task 3.2</workflowStatus> <description>My task 3.2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 3.2</dqChannel> <dqFailTrigger>StepWorkflow_ParallelTasks-Finish-2</dqFailTrigger> <nextTrigger>StepWorkflow_ParallelTasks-Finish-2</nextTrigger> </step> <step> <id>4</id> <entity>Article</entity> <workflowStatus>My task 4</workflowStatus> <description>My task 4</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>ExecuteDqBatch-Process</dqService> <dqChannel>Channel 4</dqChannel> <nextStep>STEP:5.0</nextStep> </step> <step> <id>5.0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:5</dqFailStep> </step> <step> <id>5</id> <entity>Article</entity> <workflowStatus>Approve</workflowStatus> <description>Approval</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <rejectTrigger>StepWorkflow_ParallelTasks-Reject</rejectTrigger> <singleChoice>false</singleChoice> <rejectDecision> <id>p360.bpm.reject.STEP:1</id> <label>Reject to task 1</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.STEP:2</id> <label>Reject to task 2</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.TRIGGER:3.1</id> <label>Reject to task 3.1</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.TRIGGER:3.2</id> <label>Reject to task 3.2</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.STEP:4</id> <label>Reject to task 4</label> </rejectDecision> </step> </workflow></imp:payload>Detailed explanation of the steps
Only the differences to the previous example will be explained.
Step 0
Step 0 is an exact copy of the step 0 of the example 4.
Step 1
Step 1 is an exact copy of the step 1 of the example 4.
Step 2
Step 2 is an exact copy of the step 2 of the example 4.
Step 3.1
Step 3.1 is an exact copy of the step 3.1 of the example 4.
Step 3.2
Step 3.2 is an exact copy of the step 3.2 of the example 4.
Step 4
Step 4 is nearly the same as the step 4 of the example 4. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in the example 4. |
|
nextStep |
STEP:5.0 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 5.0
This steps checks only whether the item is already in this workflow. If not the executed next step is 5. If yes the workflow will end to avoid that the item will go to the step 5 (Approve) until it is somewhere else in the workflow.
|
Key |
Value |
Description |
|
id |
5.0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:5 |
The item will be moved to the step with the identifier 5 if the above DQ fails. |
Step 5
This steps checks only whether the item is already in this workflow. If not the executed next step is 5. If yes the workflow will end to avoid that the item will go to the step 5 (Approve) until it is somewhere else in the workflow.
|
Key |
Value |
Description |
|
id |
5 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
Approve |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
Approval |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
rejectTrigger |
StepWorkflow_ParallelTasks-Reject |
Endpoint for the reject trigger of parallel states (tasks). |
|
singleChoice |
false |
This is for Rejects only and determines if you can have more than one choice. ==> The workflow can be rejected to all steps in one decision. |
|
<rejectDecision>id |
p360.bpm.reject.STEP:1 |
Identifier of the 1st reject step. |
|
<rejectDecision>label |
Reject to task 1 |
Label of the 1st rejection. This label will show up in the UI. |
|
<rejectDecision>id |
p360.bpm.reject.STEP:2 |
Identifier of the 2nd reject step. |
|
<rejectDecision>label |
Reject to task 2 |
Label of the 2nd rejection. This label will show up in the UI. |
|
<rejectDecision>id |
p360.bpm.reject.TRIGGER:3.1 |
Identifier of the 3rd reject step. (In this case you have to reject to a trigger!) |
|
<rejectDecision>label |
Reject to task 3.1 |
Label of the 3rd rejection. This label will show up in the UI. |
|
<rejectDecision>id |
p360.bpm.reject.TRIGGER:3.2 |
Identifier of the 4th reject step. (In this case you have to reject to a trigger!) |
|
<rejectDecision>label |
Reject to task 3.2 |
Label of the 4th rejection. This label will show up in the UI. |
|
<rejectDecision>id |
p360.bpm.reject.STEP:4 |
Identifier of the 5th reject step. |
|
<rejectDecision>label |
Reject to task 4 |
Label of the 5th rejection. This label will show up in the UI. |
Example 6 (2 tasks (incl. 1 supplier task) + modifying of fields)
The next example extends the example 2 workflow with modifying of fields within the workflow after finishing the tasks,
Info
Please consider to define your trigger in Product 360 carefully, because if the initiator "Service API" is not excluded for this workflow will run in a loop!
Diagram for example 6
Product 360 prerequisites for example 6
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
Explanation of the steps example 6
|
Step |
Description |
|
0 |
Check whether item is already in this workflow |
|
1 |
Put the item into the supplier task "My task 1" |
|
2 |
Modify the field Article.CurrentStatus to the value 200 |
|
3 |
Put the item into the task "My task 2" |
|
4 |
Modify the field Article.CurrentStatus to the value 300 |
StepWorkflow.xml file for example 6
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 6</label> <identifier>Workflow_06</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> <getField>Article.MainSupplier->Party.Name</getField> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>supplier</userType> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <getField>Article.CurrentStatus</getField> <nextStep>STEP:2</nextStep> <nextStep>STEP:3</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>200</updateFieldValue> </step> <step> <id>3</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <nextStep>STEP:4</nextStep> </step> <step> <id>4</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>300</updateFieldValue> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 0
Step 0 is an exact copy of the step 0 of the example 5 (incl. getField for supplier tasks).
Step 0
This steps checks only whether the item is already in this workflow. The difference to the previous step 0 steps is, that in this case the mandatory field "Article.MainSupplier->Party.Name " for supplier tasks is called. When you work with supplier tasks it is necessary that this getField command is part of the very first step of the StepWorkflow.
|
Key |
Value |
Description |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:1 |
The item will be moved to the step with the identifier 1 if the above dq fails. |
|
getField |
Article.MainSupplier->Party.Name |
List of any fields directly on the entity that will be required. These entries must be fully qualified. |
Step 1
This step puts the item into a workflow task and when leaving this task the steps 2 and 3 are executed.
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My task 1 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 1 |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
userType |
supplier |
Type of the default assignee of this task. In this case it will be assigned to the supplier of the cataslog. |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
getField |
Article.CurrentStatus |
List of any fields directly on the entity that will be required. These entries must be fully qualified. |
|
nextStep |
STEP:2 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
|
nextStep |
STEP:3 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 2
Step 2 will manipulate data within the workflow. In this example we will change the field CurrentStatus of the entity Article.
|
Key |
Value |
Description |
|
id |
2 |
Same keys and values than in the example above. |
|
entity |
Article |
Entity container for this workflow. |
|
updateFieldDescriptor |
Article.CurrentStatus |
This field allows the step to update a field in Product 360. The field must be fully qualified. |
|
updateFieldValue |
200 |
This is the value for the update. |
The next table shows you how to qualify field.
|
Key |
Value |
|
FieldDescriptor |
Article.CurrentStatus |
|
FieldDescriptor |
Article.MainSupplier->Party.Name |
|
FieldDescriptor |
Article.ManufacturerName |
|
FieldDescriptor |
ArticleLang.DescriptionShort(9,"Default Channel") |
Step 3
This step puts the item again into a workflow task and when leaving this task the steps 4 is exectuted.
|
Key |
Value |
Description |
|
id |
3 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My task 2 |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My task 2 |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
nextStep |
STEP:4 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 4
Step 4 is similar to step 2, but it will set another value to the field.
|
Key |
Value |
Description |
|
id |
4 |
Same keys and values than in the example above. |
|
entity |
Article |
Entity container for this workflow. |
|
updateFieldDescriptor |
Article.CurrentStatus |
This field allows the step to update a field in Product 360. The field must be fully qualified. |
|
updateFieldValue |
300 |
This is the value for the update. |
Example 7 (2 Tasks + modifying of fields + approval step)
The next example extends the example 6 workflow with modifying of fields within the workflow after finishing the tasks followed by an approval task which also sets data if the task(s) are rejected.
Diagram for example 7
Product 360 prerequisites for example 7
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
Explanation of the steps example 7
|
Step |
Description |
|
0 |
Check whether item is already in this workflow |
|
1 |
Put the item into the supplier task "My task 1" |
|
2 |
Modify the field Article.CurrentStatus to the value 200 |
|
3 |
Put the item into the task "My task 3" |
|
4 |
Modify the field Article.CurrentStatus to the value 300 |
|
5.0 |
Check whether item is already in this workflow |
|
5 |
Approve task with rejection options to all previous tasks. If rejected modify the field Article.CurrentStatus to the value 300 |
|
6 |
Modify the field Article.CurrentStatus to the value 400 |
StepWorkflow.xml file for example 7
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 7</label> <identifier>Workflow_07</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> <getField>Article.MainSupplier->Party.Name</getField> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>supplier</userType> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <getField>Article.CurrentStatus</getField> <nextStep>STEP:2</nextStep> <nextStep>STEP:3</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>200</updateFieldValue> </step> <step> <id>3</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <nextStep>STEP:4</nextStep> <nextStep>STEP:5.0</nextStep> </step> <step> <id>4</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>300</updateFieldValue> </step> <step> <id>5.0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:5</dqFailStep> </step> <step> <id>5</id> <entity>Article</entity> <workflowStatus>Approve</workflowStatus> <description>Approval</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <rejectTrigger>StepWorkflow_ParallelTasks-Reject</rejectTrigger> <singleChoice>true</singleChoice> <rejectDecision> <id>p360.bpm.reject.STEP:1</id> <label>Reject to task 1</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.STEP:3</id> <label>Reject to task 2</label> </rejectDecision> <rejectFieldDescriptor>Article.CurrentStatus</rejectFieldDescriptor> <rejectFieldValue>100</rejectFieldValue> <nextStep>STEP:6</nextStep> </step> <step> <id>6</id> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>400</updateFieldValue> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 0 - Step 3
These steps are exact copy of the example 6.
Step 4
Step 4 is nearly the same as the step 4 of the example above. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in the example 6. |
|
nextStep |
STEP:5.0 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 5.0
This steps checks only whether the item is already in this workflow. If not the executed next step is 5. If yes the workflow will end to avoid that the item will go to the step 5 (Approve) until it is somewhere else in the workflow.
|
Key |
Value |
Description |
|
id |
5.0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:5 |
The item will be moved to the step with the identifier 5 if the above DQ fails. |
Step 5
This is the approval step with modifying a field while rejecting.
|
Key |
Value |
Description |
|
id |
5 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
Approve |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
Approval |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
rejectTrigger |
StepWorkflow_ParallelTasks-Reject |
Endpoint for the reject trigger of parallel states (tasks). |
|
singleChoice |
true |
This is for Rejects only and determines if you can have more than one choice. ==> The workflow can be rejected to only one step, |
|
<rejectDecision>id |
p360.bpm.reject.STEP:1 |
Identifier of the 1st reject step. |
|
<rejectDecision>label |
Reject to task 1 |
Label of the 1st rejection. This label will show up in the UI. |
|
<rejectDecision>id |
p360.bpm.reject.STEP:3 |
Identifier of the 2nd reject step. |
|
<rejectDecision>label |
Reject to task 2 |
Label of the 2nd rejection. This label will show up in the UI. |
|
rejectFieldDescriptor |
Article.CurrentStatus |
This is the field the will be modifed if the task will be rected. The field must be fully qualified. |
|
rejectFieldValue |
100 |
This is the value for the update. |
|
nextStep |
STEP:6 |
Identifier of the next step, The item will be moved to the next step, when this step is approved. |
Step 6
Step 2 will manipulate data within the workflow. In this example we will change the field CurrentStatus of the entity Article.
|
Key |
Value |
Description |
|
id |
6 |
Same keys and values than in the example 6. |
|
entity |
Article |
Entity container for this workflow. |
|
updateFieldDescriptor |
Article.CurrentStatus |
This field allows the step to update a field in Product 360. The field must be fully qualified. |
|
updateFieldValue |
400 |
This is the value for the update. |
Example 8 (2 Tasks modifying of fields approval step merge)
The next example extends the example 7 workflow with merging the item(s) after the approval.
Diagram for example 8
Product 360 prerequisites for example 8
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
Explanation of the steps example 8
|
Step |
Description |
|
0 |
Check whether item is already in this workflow |
|
1 |
Put the item into the supplier task "My task 1" |
|
2 |
Modify the field Article.CurrentStatus to the value 200 |
|
3 |
Put the item into the task "My task 3" |
|
4 |
Modify the field Article.CurrentStatus to the value 300 |
|
5.0 |
Check whether item is already in this workflow |
|
5 |
Approve task with rejection options to all previous tasks. If rejected modify the field Article.CurrentStatus to the value 300 |
|
6 |
Modify the field Article.CurrentStatus to the value 400 |
|
7 |
Merge the item |
StepWorkflow.xml file for example 8
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 8</label> <identifier>Workflow_08</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> <getField>Article.MainSupplier->Party.Name</getField> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My task 1</workflowStatus> <description>My task 1</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>supplier</userType> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <getField>Article.CurrentStatus</getField> <nextStep>STEP:2</nextStep> <nextStep>STEP:3</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>200</updateFieldValue> </step> <step> <id>3</id> <entity>Article</entity> <workflowStatus>My task 2</workflowStatus> <description>My task 2</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <nextStep>STEP:4</nextStep> <nextStep>STEP:5.0</nextStep> </step> <step> <id>4</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>300</updateFieldValue> </step> <step> <id>5.0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:5</dqFailStep> </step> <step> <id>5</id> <entity>Article</entity> <workflowStatus>Approve</workflowStatus> <description>Approval</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <rejectTrigger>StepWorkflow_ParallelTasks-Reject</rejectTrigger> <singleChoice>true</singleChoice> <rejectDecision> <id>p360.bpm.reject.STEP:1</id> <label>Reject to task 1</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.STEP:3</id> <label>Reject to task 2</label> </rejectDecision> <rejectFieldDescriptor>Article.CurrentStatus</rejectFieldDescriptor> <rejectFieldValue>100</rejectFieldValue> <nextStep>STEP:6</nextStep> </step> <step> <id>6</id> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>400</updateFieldValue> <nextStep>STEP:7</nextStep> </step> <step> <id>7</id> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <entity>Article</entity> <mergeProfile>profile_no_images</mergeProfile> <nextStep>MergeItems-Process</nextStep> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 0 - Step 5
These steps are exact copy of the example 7.
Step 6
Step 6 is nearly the same as the step 5 of the example above. Only the differences are shown in the next table.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than in the example above. |
|
nextStep |
STEP:7 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 7
Step 7 will execute the merge.
|
Key |
Value |
Description |
|
id |
7 |
|
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
|
|
entity |
Article |
|
|
mergeProfile |
profile_no_images |
Profile of the merge process. There are 2 profiles within the standard workflow package. They are located in the folder profiles merge-profile of the StepWorkflow project. If you need additonal profiles you have to add them to the project with your BPM Designer, |
|
nextStep |
MergeItems-Process |
This bpel prcoess allows you to merge items into the Master Catalog. |
Example 9 (Classic Tasks)
In this example we are creating a classic (standard) tasks. The first classic task is a supplier task and the second one is a classic task for an user group. The last task will be again a workflow (approval) task, with the option to send the items back to a further step. The difference between a workflow and a classic task is when finishing a classic task all items (products or variants) within this task will be finished at once. It is highly recommended to use this approach only with report based events like export completed, import started etc., because there will be always a new task created. Independent whether the same task with the same name for the entire catalog already exists.
Diagram for example 9
Explanation of the steps example 9
|
Step |
Description |
|
1 |
Run DQ check "Channel 1" if fail ==>put the item into the supplier classic task |
|
2 |
Run DQ check "Channel 2" if fail ==>put the item into the classic task |
|
3 |
Approve task with rejection options to all previous tasks |
Product 360 prerequisites for example 9
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
|
DQ Channel |
Channel 1 |
|
DQ Channel |
Channel 2 |
|
user |
jsmith |
|
user |
jsauer |
StepWorkflow.xml file for example 9
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"><workflow> <label>Example Workflow 9</label> <identifier>Workflow_09</identifier> <version>1.0</version> <step> <id>1</id> <entity>Article</entity> <batchSize>1000</batchSize> <getField>Article.MainSupplier->Party.Name</getField> <getField>Article.CatalogProxy->SupplierCatalog.Supplier->Party.Name</getField> <uiTemplate>Item approve UI</uiTemplate> <classicTask>Supplier Classic Task</classicTask> <userType>supplier</userType> <escalation>PT12H</escalation> <substitute>jsmith</substitute> <deadline>PT24H</deadline> <responsible>jsauer</responsible> <description>Select each item and fix any rules that failed in the Quality Status tab. Go back up to the task level, select Actions,Complete</description> <workflowServiceEndpoint>StepWorkflowClassic-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <executeDq>Always</executeDq> <dqService>ExecuteDqOneChannel-Process</dqService> <dqChannel>Channel 1</dqChannel> <nextStep>STEP:2</nextStep> </step> <step> <id>2</id> <entity>Article</entity> <uiTemplate>Item approve UI</uiTemplate> <classicTask>Standard User Classic Task</classicTask> <userType>userGroup</userType> <userName>Standardusers</userName> <resetTask>true</resetTask> <escalation>P2D</escalation> <substitute>jsauer</substitute> <deadline>P4D</deadline> <responsible>pim</responsible> <description>This task is testing StepWorkflow using classic, or standard, tasks.</description> <workflowServiceEndpoint>StepWorkflowClassic-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <executeDq>Always</executeDq> <dqService>ExecuteDqOneChannel-Process</dqService> <dqChannel>Channel 2</dqChannel> <nextStep>STEP:3</nextStep> </step> <step> <id>3</id> <entity>Article</entity> <workflowStatus>Approve</workflowStatus> <description>Approval</description> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <singleChoice>true</singleChoice> <rejectDecision> <id>p360.bpm.reject.STEP:1</id> <label>Send task back to supplier</label> </rejectDecision> <rejectDecision> <id>p360.bpm.reject.STEP:2</id> <label>Send task back to Standardusers</label> </rejectDecision> <rejectFieldDescriptor>Article.CurrentStatus</rejectFieldDescriptor> <rejectFieldValue>100</rejectFieldValue> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 1
This step will run a dq execution on channel "Chanel 1". If the result of this execution is false a classic task for the supplier will be created and the items will be put into this task.
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
batchsize |
1000 |
Batch size to use with trigger batching. |
|
getField |
Article.MainSupplier->Party.Name |
List of any fields directly on the entity that will be required. These entries must be fully qualified. |
|
getField |
Article.CatalogProxy->SupplierCatalog.Supplier->Party.Name |
List of any fields directly on the entity that will be required. These entries must be fully qualified. |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
classicTask |
Supplier Classic Task |
Name of the classic task. |
|
userType |
supplier |
Type of the task. In this case a supplier task will be created. |
|
escalation |
PT12H |
The escalation date of the task will be set to 12 hours after the creation data. |
|
substitute |
jsmith |
Substitute user of this task. |
|
deadline |
PT24H |
The deadline date of the task will be set to 1 day after the creation data. |
|
responsible |
jsauer |
Responsible user for this task. |
|
description |
Select each item .... |
Description of the task. |
|
workflowServiceEndpoint |
StepWorkflowClassic-Trigge |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter the task. In this case only when dq fails! |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
ExecuteDqOneChannel-Process |
This bpel service from InfaNextSteps executes a channel dq validation |
|
dqChannel |
Channel 1 |
Name of the DQ channel which will be executed. |
|
nextStep |
STEP:2 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 2
This step will run a dq execution on channel "Chanel 1 2". If the result of this execution is false a classic task for the usergroup "Standardusers" will be created and the items will be put into this task.
|
Key |
Value |
Description |
|
... |
... |
Same keys and values than step 1. |
|
id |
2 |
Identifier of the step. |
|
classicTask |
Standard User Classic Task |
Name of the classic task. |
|
userType |
userGroup |
Type of the task. In this case a classic task for a user group will be created. |
|
userName |
Standardusers |
Name of the user group. |
|
resetTask |
True |
If reset tasks is true, then the create date of the task will be the current date-time. If it is not set, then the new task will have the same create date-time as the original task. |
|
escalation |
P2D |
The escalation date of the task will be set to 2 days after the creation data. |
|
substitute |
jsmith |
Substitute user of this task. |
|
deadline |
P4D |
The deadline date of the task will be set to 4 days after the creation data. |
|
responsible |
jsauer |
Responsible user for this task. |
|
description |
Select each item .... |
Description of the task. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter the task. In this case only when dq fails! |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
ExecuteDqOneChannel-Process |
This bpel service from InfaNextSteps executes a channel dq validation |
|
dqChannel |
Channel 2 |
Name of the DQ channel which will be executed. |
|
nextStep |
STEP:3 |
Identifier of the next step, The item will be moved to the next step, when this step is finished. |
Step 3
Approve step with possibilty to reject.
|
Key |
Value |
Description |
|
id |
3 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
Approve |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
Approval |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
singleChoice |
true |
This is for Rejects only and determines if you can have more than one choice. ==> The workflow can be rejected to a previous step. |
|
<rejectDecision>id |
p360.bpm.reject.STEP:1 |
Identifier of the 1st reject step. |
|
<rejectDecision>label |
Send task back to supplier |
Label of the 1st rejection. This label will show up in the UI. |
|
<rejectDecision>id |
p360.bpm.reject.STEP:2 |
Identifier of the 2nd reject step. |
|
<rejectDecision>label |
Send task back to Standardusers |
Label of the 2nd rejection. This label will show up in the UI. |
|
rejectFieldDescriptor |
Article.CurrentStatus |
Field which will be modified if the item will be rejected. |
|
rejectFieldValue |
100 |
This value will be set during ejection. |
Example 10 (1 Task)
The tenth workflow puts items into a workflow task called “My first task” that is assigned to whatever user is in the field “ArticleLang.Remarks”. It also sends an email to that user. For this workflow task we need 2 steps. The first step checks whether the affected item is already in this workflow, if not it will move to the next step.. The second step puts the item in the task and sends the notification.
Diagram for example 10
Explanation of the steps example 10
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "My first task" and emails the user. |
Product 360 prerequisites for example 10
|
Product 360 entity |
value |
|
User |
The value in “ArticleLang.Remarks” field. |
|
Ui Template |
Item approve UI |
Info
Whatever user name is in “ArticleLang.Remarks” is user that the task is assigned to. There is a new status added to the workflow with the user name appended to the task name. There is a delimiter “|” between the task name and the user name.
StepWorkflow.xml file for example 10
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 10</label> <identifier>Workflow_10</identifier> <version>1.0</version> <taskUserDelimiter>|</taskUserDelimiter> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My first task</workflowStatus> <description>The description of my first workflow task.</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <getField>Article.SupplierAID</getField> <getField>ArticleLang.DescriptionShort(9, "Default Channel")</getField> <getField>ArticleLang.DescriptionLong(9, "Default Channel")</getField> <getField>ArticleLog.ModificationDate(HPM)</getField> <enterStatus>Always</enterStatus> <notificationService>NotifyUser-Process</notificationService> <batchSize>500</batchSize> <userType>user</userType> <userName>SERVICE:UserTask-Workflow</userName> <userDescriptor>ArticleLang.Remarks(9, "Default Channel")</userDescriptor> <includeLabels>true</includeLabels> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 0
This step checks only whether the item is already in this workflow. If not the executed next step is 1. If yes the workflow will end because there is no next step defined.
|
Key |
Value |
Description |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:1 |
The item will be moved to the step with the identifier 1 if the above dq succeeds. |
|
taskDelimeter |
| |
The delimiter that goes between the original task name and the user name. |
Step 1
This step enters the items in the task called “My first task” and emails the user this task is assigned to.
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My first task |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My first workflow task |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always |
|
userType |
user |
Type of the default assignee of this task. In this case it will be a user. |
|
userName |
SERVICE:UserTask-Workflow |
The service for the bpel process that will determine the user or usergroup to assign the task to. |
|
updateFieldDescriptor |
ArticleLang.Remarks(9, "Default Channel") |
The field which stores the user name to assign the task to for dynamic users. |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
notificationService |
NotifyUser-Process |
The service for the bpel process that will perform the email service. |
|
includeLabels |
true |
This will allow us to receive the item number in addition to the item ID. |
|
getField |
Several field names |
This will get the field values for the items from P360. By default, for NotifyUser, these will be included in an html table in the email. |
Example 11 (1 Task with DQ checks)
The eleventh workflow puts items into a workflow task called “My first task”. The first step checks whether the urn value for workflow_11.active is true, if not, the workflow will end. If it is "true", it will move to the next step. The second step checks to see if the affected items have a Current Status of 100, or “01 New” on most systems. If it is not, then the items will not go into the task and the workflow will end. If so, it will move to the next step. The 3rd step updates the current status of the items to 200. The 4th step puts the item in the task.
Diagram for example 11
Explanation of the steps example 11
|
Step |
Description |
|
0 |
Check whether urn is set to true. |
|
1 |
Check if the CurrentStatus of item is “01 New” |
|
NoLongerNew |
Update Current Status to something else/ |
|
2 |
Put the item into the task "My first task" |
Product 360 prerequisites for example 11
|
Product 360 entity |
value |
|
UserGroup |
Standardusers |
|
Ui Template |
Item approve UI |
|
Article.CurrentStatus |
100 |
|
ActiveVOS Console |
value |
|
Urn:workflow_11.active |
true |
Info
The DQ Service “dqValueCheck-Process” is used for both DQ’s. There are 3 elements of the rule: [TYPE] | [KEY] | [VALUE] The types of comparisons are not case sensitive and are:
* Descriptor: <dqRule>Descriptor|Article.CurrentStatus|100</dqRule>
* Name: <dqRule>Name|Status|100</dqRule>
* URN value: <dqRule> URN|urn:skip.merge.task|true</dqRule>
StepWorkflow.xml file for example 11
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 11</label> <identifier>Workflow_11</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>5000</batchSize> <executeDq>Always</executeDq> <getField>Article.CurrentStatus</getField> <dqService>dqValueCheck-Process</dqService> <dqRule>urn|urn:workflow_11.active|true</dqRule> <nextStep>STEP:1</nextStep> </step> <step> <id>1</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>5000</batchSize> <executeDq>Always</executeDq> <getField>Article.CurrentStatus</getField> <dqService>dqValueCheck-Process</dqService> <dqRule>descriptor|Article.CurrentStatus|100</dqRule> <nextStep>STEP:NoLongerNew</nextStep> <nextStep>STEP:2</nextStep> </step> <step> <id>NoLongerNew</id> <entity>Article</entity> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <updateFieldValue>200</updateFieldValue> </step> <step> <id>2</id> <entity>Article</entity> <workflowStatus>My first task</workflowStatus> <description>My first workflow task</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>Detailed explanation of the steps
Step 0
This step checks only whether the item is already in this workflow. If not the executed next step is 1. If yes the workflow will end because there is no next step defined.
|
Key |
Value |
Description |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
dqService |
dqValueCheck-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqRule |
urn|urn:workflow_11.active|true |
Checks to see if urn:workflow_11.active is “true” |
|
nextStep |
STEP:1 |
The item will be moved to the step with the identifier 1 if the above dq succeeds. |
Step 1
This step checks to see if the Current Status is 100. If yes, the workflow will move to the next step2 defined as NoLongerNew and 2.
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
dqService |
dqValueCheck-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqRule |
descriptor|Article.CurrentStatus|100 |
Checks to see if Current Status is 100, or “01 New” |
|
nextStep |
STEP: NoLongerNew STEP:2 |
The item will be moved to the step with the identifier 1 if the above dq succeeds. |
Step NoLongerNew
This step updates the Current Status field.
|
Key |
Value |
Description |
|
id |
NoLongerNew |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
updateFieldDescriptor |
Article.CurrentStatus |
The descriptor for the field being updated. |
|
updateFieldValue |
200 |
The value to update the field with. |
Step 2
This step puts the affected items in the "My first Task" task.
|
Key |
Value |
Description |
|
id |
2 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My first task |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My first workflow task |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a user. |
|
userName |
Standardusers |
The service for the bpel process that will determine the user or usergroup to assign the task to. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
Example 12 (2 Triggers and Merge with Results)
The twelfth workflow puts items into a workflow task called “Contact external team”. The first step checks whether the affected item is already in this workflow, if not it will be put into the task. The second step puts the items in the “Contact external team” task . The workflow then stops until it is triggered again by an import, export, or entity change. Once the workflow is triggered again, it moves to an approval task. Approved items go to the next step and rejected items end the workflow. In the last step, the affected items merge. Because it is set up as a dq, any items that fail to merge go into a “Failed to Merge” task.
Diagram for example 12
Explanation of the steps example 12
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "Contact external team". |
|
2nd Trigger |
This step is triggered by an import complete, export started, or an entity changed. It then moves to Step 3. |
|
3 |
Put the item into an approval task. Items that are rejected end the workflow. Ones that are approved move to step Merge. |
|
Merge |
Merge the items as a DQ. if fail ==>put the item into the task “Failed to Merge” and send an email. |
Product 360 prerequisites for example 12
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
Info
Standarduser is the Identifier of the Usergroup. This workflow stops after step one until a new trigger is generated for the step “2nd Trigger”. This workflow also features a merge that runs as a DQ. The items will merge, but if any fail, they will enter a merge failed task.
StepWorkflow.xml file for example 12
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 12</label> <identifier>Workflow_12</identifier> <version>1.0</version> <taskUserDelimiter>|</taskUserDelimiter> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>Contact external team</workflowStatus> <description>Contact external team and finish the task. Once the import is completed the workflow will pick up where it left off.</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> </step> <step> <id>2nd Trigger</id> <entity>Article</entity> <triggerConfiguration>Example12_ImportCompleted_2nd</triggerConfiguration> <triggerConfiguration>Example12_ExportStarted_2nd</triggerConfiguration> <triggerConfiguration>Example12_EntityChange_2nd</triggerConfiguration> <nextStep>STEP:3</nextStep> </step> <step> <id>3</id> <entity>Article</entity> <workflowStatus>Approve</workflowStatus> <description>Approval</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <rejectTrigger>StepWorkflow_ParallelTasks-Reject</rejectTrigger> <singleChoice>false</singleChoice> <rejectDecision> <id>p360.bpm.reject</id> <label>Reject</label> </rejectDecision> <nextStep>WorkflowWait-Process</nextStep> <wait>PT5S</wait> <nextStep>STEP:Merge</nextStep> </step> <step> <id>Merge</id> <entity>Article</entity> <workflowStatus>Failed to Merge</workflowStatus> <description>These items failed to merge.</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>OnDqResults</enterStatus> <userType>user</userType> <userName>pim</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Always</executeDq> <dqService>MergeItemsResults-Process</dqService> <mergeProfile>profile_no_images</mergeProfile> <dqFailStep>NotifyUser-Process</dqFailStep> </step> </workflow></imp:payload> Detailed explanation of the steps
Step 0
This step checks only whether the item is already in this workflow. If not the executed next step is 1. If yes the workflow will end because there is no next step defined.
|
Key |
Value |
Description |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:1 |
The item will be moved to the step with the identifier 1 if the above dq fails. |
Step 1
This step puts the affected items in a task. If the task is finished, the workflow will stop.
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
Contact external team |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
Contact external team and finish the task. Once the import is completed the workflow will pick up where it left off. |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
Step 2nd Trigger
Once this step is triggered, it just moves to the next step.
|
Key |
Value |
Description |
|
id |
2nd Trigger |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
triggerConfiguration |
Example12_ImportCompleted_2nd Example12_ExportStarted_2nd Example12_EntityChange_2nd |
The 3 different trigger configurations that can trigger the step |
|
nextStep |
STEP:3 |
The item will be moved to the step. |
Step 3
This is the approval step that moves to Merge if approved while workflow ends for rejected items.
|
Key |
Value |
Description |
|
id |
3 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
Approve |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
Approval |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
rejectTrigger |
StepWorkflow_ParallelTasks-Reject |
Endpoint for the reject trigger of parallel states (tasks). |
|
singleChoice |
true |
This is for Rejects only and determines if you can have more than one choice. ==> The workflow can be rejected to only one step, |
|
<rejectDecision>id |
p360.bpm.reject |
Identifier of the reject step. Since none is added, it will not go to a task. |
|
<rejectDecision>label |
Reject |
Label of the rejection. This label will show up in the UI. |
|
nextStep |
WorkflowWait-Process |
This step will wait and then go to the next nextStep. |
|
wait |
PT5S |
Standard duration notation. This is 5 seconds. |
|
nextStep |
STEP:Merge |
Identifier of the next step, The item will be moved to the next step, when this step is approved. |
Step Merge
This step does the merge through a DQ process. The items will merge, but if any fail, they will enter a merge failed task.
|
Key |
Value |
Description |
|
id |
Merge |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
Failed to Merge |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
These items failed to merge. |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
OnDqResults |
The circumstances when an item should enter a status (task). In this case only when DQ check will fail! |
|
userType |
user |
Type of the default assignee of this task. In this case it will be a user. |
|
userName |
pim |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the user "pim". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Always |
The circumstances when a DQ should be run. In this case always! |
|
dqService |
MergeItemsResults-Process |
The service name of the process that will be handle the processing of the DQ. In this case, it will merge the items and return Success for those that do not have issues and Failed for those that do. |
|
dqFailStep |
NotifyUser-Process |
This will send an email containing all items that failed to merge if any did. |
|
nextTrigger |
StepWorkflow_ParallelTasks-Finish-1 |
This is another service name of the partner link of the parallel tasks. It will be called if the item will leave this step. |
Example 13 (Workflow starts another workflow)
The thirteenth workflow puts items into a workflow task called “My first task” and then to another workflow. The first step checks whether the affected item is already in this workflow, if not it will be put into the task. The second step puts the items into the task. Once the items are finished in the task, they will move to another workflow at a specific step.
Diagram for example 13
Explanation of the steps example 13
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "My first task". When that task is finished, send the items to a step in another workflow |
Product 360 prerequisites for example 13
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
|
Ui Template |
Item approve UI |
|
Workflow |
Workflow_02 |
Info
Standarduser is the Identifier of the Usergroup!
StepWorkflow.xml file for example 13
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Example Workflow 13</label> <identifier>Workflow_13</identifier> <version>1.0</version> <step> <id>0</id> <entity>Article</entity> <enterStatus>Never</enterStatus> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:1</dqFailStep> </step> <step> <id>1</id> <entity>Article</entity> <workflowStatus>My first task</workflowStatus> <description>My first workflow task</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate>Item approve UI</uiTemplate> <executeDq>Never</executeDq> <changeWorkflowLabel>Example Workflow 2</changeWorkflowLabel> <changeWorkflowIdentifier>Workflow_02</changeWorkflowIdentifier> <changeWorkflowStep>2</changeWorkflowStep> <nextStep>ChangeWorkflow-Process</nextStep> </step> </workflow></imp:payload> Detailed explanation of the steps
Step 0
This step checks only whether the item is already in this workflow. If not the executed next step is 1. If yes the workflow will end because there is no next step defined.
|
Key |
Value |
Description |
|
id |
0 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
enterStatus |
Never |
The circumstances when an item should enter a status (task). In this case never! |
|
batchSize |
500 |
Batch size to use with trigger batching. |
|
dqService |
ItemsInWorkflowTasks-Process |
This DQ service is an additional bpel inside the StepWorkflow which checks whether the item is already inside this workflow or not. |
|
dqFailStep |
STEP:1 |
The item will be moved to the step with the identifier 1 if the above dq fails. |
Step 1
This step moves the items into a task called "My first task". When the items are finished by a user, they will move into "Example Workflow 2" step "2".
|
Key |
Value |
Description |
|
id |
1 |
Identifier of the step. |
|
entity |
Article |
Entity container for this workflow. |
|
workflowStatus |
My first task |
Status name within the Product 360 workflow. ==> Product 360 task name = [Workflow] - [Status] - [Catalog] |
|
description |
My first workflow task |
Description of the status. |
|
workflowServiceEndpoint |
StepWorkflow-Trigger |
This is the service name of the partner link. This name is defined in the process deployment descriptor of the workflow. |
|
enterStatus |
Always |
The circumstances when an item should enter a status (task). In this case always! |
|
userType |
userGroup |
Type of the default assignee of this task. In this case it will be a usergroup. |
|
userName |
Standardusers |
Name/Identifier of the Default assignee of the task. ==> The item will be assigned to the usergroup "Standardusers". |
|
uiTemplate |
Item approve UI |
This is the default UI of the task. |
|
executeDq |
Never |
The circumstances when a DQ should be run. In this case never! |
|
changeWorkflowLabel |
Example Workflow 2 |
The label of the workflow the item is going to. |
|
changeWorkflowIdentifier |
Workflow_02 |
The identifier of the workflow the item is going to. |
|
changeWorkflowStep |
2 |
The step of the workflow the item is going into. |
|
nextStep |
ChangeWorkflow-Process |
This process will send the item to another workflow and step based on the 3 previous parameters. |
StepWorkflow Sanity
The StepWorkflow package includes a Sanity process. It has a workflow file for configurations
<imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>StepWorkflowSanity</label> <identifier>StepWorkflowSanity</identifier> <version>1.0</version> <step> <id>Sanity</id> <urn>urn:p360.api.username</urn> <urn>urn:p360.api.password</urn> <urn>urn:p360.api.manager</urn> <urn>urn:p360.api.queue</urn> <urn>urn:p360.rest.url</urn> <urn>urn:dq.timeout</urn> <urn>urn:p360.api.data.quality.queue</urn> <urn>urn:p360.api.data.quality.response.queue</urn> <urn>urn:list.get.timeout</urn> <getField>Article.CurrentStatus</getField> <updateFieldDescriptor>Article.CurrentStatus</updateFieldDescriptor> <createTask>true</createTask> <sendNotification>true</sendNotification> <emailConfigs>sanity</emailConfigs> </step> </workflow></imp:payload> It consists of 3 main sections:
URN check. It verifies that urn values that are required for StepWorkflow do exist. It does this based on the values in the config file with the ‘urn’ tag. Users can add any urn's they want to include them in the sanity. If the urn exists and the test is considered SUCCESS if it does not, it is considered FAILED.
Workflow map files. The sanity goes through the StepWorkflow.map file and verifies that it can access each workflow file in this file. It also verifies that the workflow identifier in the map file matches the one in each workflow xml file.
Access to P360. The config file has get field and update field descriptor values to verify connection to P360. First, it does a get and verifies the response. Then it uses the same value to do a post. Using the same value makes sure nothing is changed for the sanity test but also verifies the connection.
The sanity test also allows for a task to be created and/or an email sent out. For the task and email, the sanity test is labeled a SUCCESS if no tests fail. Otherwise, it is considered FAILED.
|
Key |
Value |
Description |
|
urn |
urn:p360.api.queue |
These are the urn values that the Sanity will verify that they do exist. |
|
getField |
Article.CurrentStatus |
This is the field that the sanity will use to verify a get for P360 |
|
UpdateFieldDescriptor |
Article.CurrentStatus |
This is the fields used to verify that a post will work to P360. It must be one of the fields in the Update Descriptor field. |
|
CreateTask |
TRUE |
This determines whether or not there will be a task for the Sanity results. |
|
sendNotification |
TRUE |
This determines whether or not there will be an email sent for the Sanity results. |
|
emailConfigs |
sanity |
The xls file that serves as the template for the email. |
Sample email:
SanityResults
<type> <test> <name>urn:p360.api.username</name> <details>RestServiceUser</details> <results>SUCCESS</results> </test> <test> <name>urn:p360.api.password</name> <details>######</details> <results>SUCCESS</results> </test> <test> <name>urn:p360.api.manager</name> <details>ActiveMQ</details> <results>SUCCESS</results> </test> <test> <name>urn:This.is.a.test.urn</name> <details>none</details> <results>FAILED</results> </test> … <test> <name>project:/StepWorkflowExamples/workflow/Example_01.xml</name> <details>Loaded file</details> <results>SUCCESS</results> </test> <test> <name>Workflow_01</name> <details>Workflow id matches map file</details> <results>SUCCESS</results> </test> <test> <name>project:/StepWorkflowExamples/workflow/Example_02.xml</name> <details>Loaded file</details> <results>SUCCESS</results> </test> <test> <name>Workflow_02</name> <details>Workflow id matches map file</details> <results>SUCCESS</results> </test> … <test> <name>get(Article.CurrentStatus)</name> <details>0939699831001: 200</details> <results>SUCCESS</results> </test> <test> <name>update(Article.CurrentStatus)</name> <details>UPDATED</details> <results>SUCCESS</results> </test></type> Defaults
The StepWorkflow package includes 3 default workflows. 1 workflow for items, 1 for products and an additional 1for variants. These 3 workflows are only simple examples of defaults. Such a default workflow will be triggered if the trigger you defined in your Product 360 Desktop client does not match to an entry in the StepWorkflowMap.xml file.
DefaultArticle
Diagram for default article
Explanation of the steps default article
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "Default workflow task". |
Product 360 prerequisites for default article
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
StepWorkflow.xml file for defaultArticle.xml
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Item Workflow</label> <identifier>Default_Workflow_Article</identifier> <version>1.0</version> <step> <id>1</id> <entity>Article</entity> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:2</dqFailStep> </step> <step> <id>2</id> <entity>Article</entity> <workflowStatus>Default workflow task</workflowStatus> <description>Default workflow task</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate></uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>DefaultVariant
Diagram for default variant
Explanation of the steps default variant
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "Default workflow task". |
Product 360 prerequisites for default variant
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
StepWorkflow.xml file for defaultVariant.xml
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Variant Workflow</label> <identifier>Default_Workflow_Variant</identifier> <version>1.0</version> <step> <id>1</id> <entity>Variant</entity> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:2</dqFailStep> </step> <step> <id>2</id> <entity>Variant</entity> <workflowStatus>Default workflow task</workflowStatus> <description>Default workflow task</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate></uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>DefaultProduct2G
Diagram for default product2g
Explanation of the steps default product2g
|
Step |
Description |
|
0 |
Check whether item is already in this workflow. |
|
1 |
Put the item into the task "Default workflow task". |
Product 360 prerequisites for default product2g
|
Product 360 entity |
value |
|
Usergroup |
Standardusers |
StepWorkflow.xml file for defaultProduct2G.xml
<?xml version="1.0" encoding="UTF-8"?><imp:payload xmlns:imp="http://www.informatica.com/schema/ItemMap" contentType="string"> <workflow> <label>Product Workflow</label> <identifier>Default_Workflow_Product2G</identifier> <version>1.0</version> <step> <id>1</id> <entity>Product2G</entity> <batchSize>500</batchSize> <executeDq>Always</executeDq> <dqService>ItemsInWorkflowTasks-Process</dqService> <dqFailStep>STEP:2</dqFailStep> </step> <step> <id>2</id> <entity>Product2G</entity> <workflowStatus>Default workflow task</workflowStatus> <description>Default workflow task</description> <workflowServiceEndpoint>StepWorkflow-Trigger</workflowServiceEndpoint> <enterStatus>Always</enterStatus> <batchSize>500</batchSize> <userType>userGroup</userType> <userName>Standardusers</userName> <uiTemplate></uiTemplate> <executeDq>Never</executeDq> </step> </workflow></imp:payload>