How to repair incomplete Task Execution Context of Workflow Tasks

If any user accepts items from Workflow tasks initially assigned to a user group, then she/he can give them back to initial user group using "Cancel work" or "Assign" action. Now both actions work exactly the same way. To make it possible a new TaskEntityInitializer has been added to the list of initializers proceeded during P360 Server startup.

This initializer checks all workflow tasks for an incomplete TaskExecutionContext storing amongst other information the user group items to be worked on are initially assigned to. An incomplete TaskExecutionContext can occur when items initially assigned to a user group are accepted by an individual user and are then assigned back to the initial user group.
The InitialUserGroup as "primary owner" of the task has been lost in this case, so newly entered items are not visible in the user group task. The TaskEntityInitializer tries to find out the initial user group id and to repair the execution context of workflow tasks created for specific workflow status. In most cases it can be repaired automatically and there will be some log outputs written about tasks, which have been repaired by the initializer.

But under certain conditions the repair tool cannot find the initial user group and thus does not repair the task execution context programmatically. However, the full information about such workflow tasks will be logged as ERROR and can be used to repair incomplete TaskExecutionContext manually:

Steps to execute:

1. Use the log output to note the combination of WorkflowID + WorkflowStatus + ContainerID + Entity.

2. Determine the UserGroup ID, to which this workflow task should be initially assigned to. Get the name of user group from the "Create Workflow" Service API call (e.g. "demo group") and execute the following statement on MAIN database:

3. Find the task entry in the database table Task using the statement below. NOTE: It's enough to update the context of only one task for the corresponding combination of WorkflowID + WorkflowStatus + ContainerID + Entity, the other tasks for this combination will be corrected at the next P360 Server start automatically.

4. Copy the XML containing the TaskExecutionContext to a text editor. In our case it looks like this:

5. Add the XML entry for InitialUserGroup so the TaskExecutionContext string looks like this:

6. Update the task execution context in the database using modified string

7. Update task content using ServiceAPI: http://<host>:<port>/rest/V1.0/manage/task/<taskId>/content?updateTask=true

How to complete the value of Task.IsOriginWorkflow field

Since version 8.1.0.03 the new field IsOriginWorkflow has been added to the table Task. This field is a marker if the workflow task has been initially created by the workflow or has been created manually by the user during assigning or accepting of items from the workflow task. However the value of this field must be checked/completed in existing databases. Please check the database table and complete the value using following steps:

1. Create a list with all workflow status for all workflows:

   SELECT "WorkflowID", "WorkflowStatus", "ContainerID", "Entity", "DeletionTimestamp"

   FROM "HPM_MAIN"."Task"

   GROUP BY "TaskType", "WorkflowID", "WorkflowStatus", "ContainerID", "Entity", "DeletionTimestamp"

   HAVING "TaskType" = 'WorkflowTask' AND "DeletionTimestamp" = TO_TIMESTAMP('9999-12-31', 'yyyy-mm-dd')

   AND "WorkflowID" IS NOT NULL AND "WorkflowStatus" IS NOT NULL AND "ContainerID" IS NOT NULL

   ORDER BY "WorkflowID", "WorkflowStatus";

   

2. Analyze all tasks created for each workflow status.

   SELECT "ID", "UserID", "UserGroupID", "SupplierID", "TaskExecutionContext", "IsOriginWorkflow"

   FROM "HPM_MAIN"."Task"

   WHERE "WorkflowID" = 703

   AND "WorkflowStatus" = 'HPM-42468 Classify'

   AND "ContainerID" = 1

   AND "Entity" = 'Article'

   AND "DeletionTimestamp" = TO_TIMESTAMP('9999-12-31', 'yyyy-mm-dd')

   ORDER BY "ID" ASC;

   

3. There should be one task marked with IsOriginWorkflow = 1. If not, analyze the content of TaskExecutionContext field.
   If for example the xml contains initial user group id ( search for <![CDATA[InitialUserGroup]]> ) equal to the assigned user group of the task and doesn't contain any other assignee ( search for <![CDATA[UserGroup]]> or <![CDATA[User]]> or <![CDATA[Supplier]]> ), then this task has been created by workflow initially. In our case it's the task with ID = 1455. So you can update the field IsOriginWorkflow for this task and set it to 1.

   UPDATE "HPM_MAIN"."Task"

   SET "IsOriginWorkflow" = 1

   WHERE "ID" = 1455

   Other tasks are obviously created by users during assigning or accepting and must have IsOriginWorkflow = 0
   

4. Commit database changes and restart P360 server.

How to handle duplicates of workflow tasks in the database

Some special circumstances can lead to duplicated workflow tasks for the same workflow, workflow status, container, entity and assignee and this can result in strange behaviour assigning items to another assignee. Since version 8.1.0.03 TaskEntityInitializer has been extended to find such duplicated workflow tasks during P360 Server startup.
The full information about such workflow tasks will be logged as ERROR and can be used to repair data manually. If the server log contains a message like this then there is a reason to handle:

Steps to handle:

1. Use the log output to note the combination of WorkflowID + WorkflowStatus + ContainerID + Entity + UserGroupID/UserID/SupplierID.

2. To identify which tasks are affected, execute following statement on HPM_MAIN database using data from log output:

3. To identify which task has been created by the workflow execution initially, analyze the content of TaskExecutionContext field.
If the xml contains initial user group id ( search for <![CDATA[InitialUserGroup]]> ) equal to the assigned user group of the task and doesn't contain any other assignee ( search for <![CDATA[UserGroup]]> or <![CDATA[User]]> or <![CDATA[Supplier]]> ), then this task has been created by workflow initially. In our case it's the task with ID = 1455

So you can update the field IsOriginWorkflow for this task and set it to 1.

4. Other tasks can be updated with assignee taken from TaskExecutionContext ( search for <![CDATA[UserGroup]]> or <![CDATA[User]]> or <![CDATA[Supplier]]> ). In our case it's the task with ID = 1461

You can also delete them if they don't contain any items ( Count = 0 ), they will be created on demand during manual assignments. In our example it's the task with ID = 1460

5. Commit all database changes and restart P360 server.

How to trace content of which tasks has been updated

To monitor, which tasks have been updated, the trace level TRACE can be set in the log4j.xml for com.heiler.ppm.task.server.internal.communication plugin.
<category name="com.heiler.ppm.task.server.internal.communication">
<priority value="TRACE"/>
</category>Also the errors and warnings provided by com.heiler.ppm.task.core.context.ReportResultProviderExecutionContext class give nformation about problems during report execution.

How to find Bottle necks in calls from ActiveVOS to PIM

1. Go to the ActiveVOS Console

2. Go to Monitor

3. Click on Server Performance

4. Click the Second tab

5. Order this by Average Time Decending

Services Used by Processes

1. Open an instance of a Process with the First Process Name

2. Look at the log to see the actual timing

3. Use this to determine potential bottle necks.

Process Log

How to resolve http response 403-> SOME endpoint is not a registered REST service.

How to resolve Project <> with namespace <> does not exist on the server

Deploy the mentioned project then redeploy the project that failed.

How to resolve Email service is disabled.

Email service is disabled. will be returned see message below

• To enable the email service go to the ActiveVOS Console> Admin>Configure Services>Email Service

• for boxes inside INFA you can use smtprelay.informatica.com

• For boxes without access to theINFA network use the normal email client information.

• make sure to check the Enable box and click update.

< messageData name = "faultMessage"

namespaceURI = "http://docs.active-endpoints/wsdl/email/2007/04/email.wsdl" >

< part name = "faultPart" >

< email:faultElement xmlns:email = "http://docs.active-endpoints/wsdl/email/2007/04/email.wsdl" >

< email:code > 4 </ email:code >

< email:message > Email service is disabled. </ email:message >

</ email:faultElement >

</ part >

</ messageData >

My New workflow is replying on an old endpoint

Change your workfow name or add a version number when the triggers for that endpoint change

I cannot see the messages in the ae-messages-0.log because there are too many calls to the rest list service

From PIM 8.0.6.04 and Pim 8.1 there is a configuration porperty to set how often the rest service list should be polled. the deafult is 5 which means 5 seconds.

This is set in the server.properties file.

1. Find the server.properties file for your PIM server

   1. Example : c:/informatica/PIM/server/configuration/HPM/server.properties

2. Find the infa.bpm properties

3. Create a new proiperty called infa.bpm.serviceEndpointListPollInterval

   1. Make sure there is not other entry already in the server.properties file for the same name

4. Set it to a larget number than 5 (300 means one call every 5 minutes)

   

5. Save

6. Restart your PIM server

7. Start the ActiveVOS server if it is not started

8. Update ActiveVOS to log all Messages

9. wait at least 5 minutes

10. Find the ae-messags.0 file

11. Copy this file

12. Edit the copy

13. Note how long it is between calls to the Rest List

    

14. In this example we see a 5 minute wait