Yes, you are right. I do mean the UserTask count groupBy Assignee report.
I didn’t apply any filters. I tried to see the user id values that I can filter with it only has one value and it is “unassigned”.
Regarding the version of the definition I have only one version and it is the latest one.
Regarding the tenant I wasn’t prompted anything related to it when I created the report and in the configuration file I also didn’t change the defaultTenant value.
I have no defined tenants on the process engine instance.
Thanks for checking. One more thing: can you double check that Optimize is connected to the correct engine? You can see the engine name Optimize is connected to in the lower left hand corner of Optimize in your browser.
If it is connected to the correct engine, could you check the following:
In your report setup, could you select Distributed By “UserTask” and check that all userTask names from your definition appear in the table header? I am wondering if it is assignee oder userTask data that is missing from this report.
Also, can you confirm that the userTasks were assigned to users at the time they were completed? Optimize only displays the last value of the userTask assignee field in reports, so if the userTask was assigned to a user, then unassigned and then completed, Optimize will display this userTask as unassigned.
I also forgot to reply to this from your first messge:
GroupBy Variable is not a configuration that is available for userTask reports, so it’s normal that you cannot select it in the GroupBy dropdown if you have selected a UserTask View.
You should however be able to select it as a View or a GroupBy on other reports (eg after selecting ProcessInstance or FlowNode views).
I made sure that I have only one process engine instance available and that I am connected to it.
Yes, all of the task names appear correctly.
I double checked. At the moment TaskService.complete(TaskID) is called the task is assigned to a user.
GroupBy Variable is not a configuration that is available for userTask reports.
Sorry for not being clear in this part. Actually this is another problem not related to the assignee one. what I meant is that it is not enabled for all report views including ProcessInstance and FlowNode views
Thanks for checking all of that.
Did you alter your Optimize configuration in any way? If so, can you please post your new configuration.
And could you also provide the Optimize log? Maybe there’s something in there explaining why this instance data has not been imported yet. I am assuming the instance count of 4 is correct, so there are no instances missing in Optimize?
Ah, so you are performing these tasks programmatically (not manually in Tasklist)? Could you share your code? The issue might be related to how the assignees (and variables) data is set in your code.
Interesting. Let’s tackle the assignee issue first, though they might be related.
If you are familiar with Elasticsearch, you could also have a look in the optimize-process-instance index to check if the process instance Ids match what you have in your engine DB. I would also be intrigued to see what the content of the assignee and assigneeOperations fields of the userTasks in the userTasks field of your instances is.
No, I didn’t. The only two values I changed are engines[‘camunda-bpm’].name and engines[‘camunda-bpm’].rest so I can connect to my process engine.
Sure, I checked it but found nothing special. optimize.log (2.2 KB)
Yes, no instances where missing.
Aha, I do that programatically. But sadly, I am not allowed to disclose the codebase. However I can tell which methods are used to claim/complete tasks.
I actually doubt that, because I used Postman to connect to the engine’s API and retrieve all the tasks in the history. Claimed tasks had their assignee value set as shown in the json response included in this attached file below.
This file (29.8 KB) contains the state of the engine and Elasticsearch.
4 active process instances and now 9 user tasks are in the system and some tasks have the assignee value of “user”.
I also show that one of the process instances have variables and those are not reflected in Elasticsearch.
The data from the engine is a bit misleading in this case, as there is no one-to-one relationship between engine and Optimize entities. Optimize does not get its userTask assignee and variable data straight from the activity instance engine data. Instead, it has its own engine endpoints which query for IdentityLinkLog and VariableUpdate data.
For example, for assignee data, Optimize retrieves a collection of IdentityLinkLogs which detail when a userTask was assigned/unassigned and to whom. This data then allows us to update Optimize’s ProcessInstance data accordingly with a complete log of assignee changes, including the info of what the current assignee is.
Given that some event data like start- and endDates appear to have been imported into Optimize correctly, it’s possible that either the engine does not return the relevant IdentityLinkLog data or Optimize fails to import it correctly.
To figure out which one it is, lets try the following:
First, lets see what data the Optimize endpoints for IdentityLinkLogs and VariableUpdates are returning.
The endpoints are the following : GET /engine-rest/optimize/identity-link-log and GET /engine-rest/optimize/variable-update
If you have an import user configured, you need to use those users credentials when performing these rest calls.
The second step depends on what the above returns. If there is data returned, then lets try triggering a reimport with the relevant import log levels set to debug which should result in a more helpful Optimize log:
Glad to hear we’ve found a clue now, if these endpoints don’t return any data then that will be the reason there are no assignees and variables in Optimize.
Now the question is why the relevant logs don’t exist/aren’t returned from the engine, and there could be a few reasons as to why this is. For example, your history might be turned off but I’m not an engine expert so I will reach out to the relevant team for you to get some more qualified help on this.
In the meantime, could you upload your engine configuration? That’ll help pinpoint the issue.
I was creating a process engine instance programmatically using ProcessEngineConfigurationImpl.buildProcessEngine(). I didn’t set the history to ProcessEngineConfiguration.HISTORY_FULL, I thought the default value HISTORY_AUDIT was enough in my case.