The image that you attached does not open up for some reasons. Could you try re-attaching ?
Does the error happen while you try to claim the tasks? If so, most likely the case that the user does not have the rights to work on the task. The task potential owner , or the business admin list needs to be verified if the user is part of those groups.
Also, do you know if the partner link (as defined in the setRunAsRole script activity in your process) evaluates to a correct value during run time, when the issue occurs ?
Any other errors in the ldap logs, assuming you use ldap for identity service ?
[Reason Code: ae.ht.task.no.auth] User is not authorized to get task instance
Hi, the problem is when we call getInstance - and i know that the problem is not caused by LDAP inaccessibility.
Is true that it really happen few times in a day, we have about 300 tasks in a minute.
By the way, we had today LDAP not accessible but there were not faults in Avos node logs, is there a way how to be notified that the LDAP is broken?
Sorry 300 tasks in hour
it seems to me for some reasons the engine believes that the user who tries to invoke that process is not authorized, but by looking at your pdd definition, it seems that you have most likely given the username of an admin that have access to all the tasks. Is that correct ?
Since you mentioned that "we had today LDAP not accessible but there were not faults in Avos node logs", could you verify that this error in AVOS happened about the same time, thereby not resolving the user ?
Also, no there isn't a way to be notified that the LDAP is broken, but you would surely see issues similar to this.
yes you are right, it is admin who has access to all tasks. Where could be the problem?
No, the problem has happened in last week, and occurs regularly since i works in Avos team in Ceska (our company).
Is this issue in a non -production system? If so, would you be able to enable persistence on the aeb4p-task-client process for a short while since you say this is reproducible regularly.
The following is a screen of the process from my environment when the getInstance operation is invoked. All this process (specific Scope) is doing is, checking if the task is in the Final state by querying the database, and then invokes the task state process to retrieve the task state.
Here is how you do it.
1. In ActiveVOS Console > Catalog > Deployed Processes > Uncheck HideSystem > type aeb4p-task-client for Process name > Click on Submit.
2. One result would be returned. Click on the name > version > change persistence type to Full > Logging level as Execution > Click on update.
(Note: The task client is called on every getter process. So you might end up in several calls of this process and as a result of which the logging data might increase too. If it is possible please test only this getInstance scenario - example, put a suspend after the getInstance call, so other activities in the process do not get called. This is only for testing purposes. You will have to revert these changes to the original setting once we identify what is causing this issue.)
3. Enable logging for the task state process - Using step 1, spot the aeb4p-task-state2 process name. once results are returned set the Logging level as Execution.
When the issue is reproduced, please download the process execution logs (as you can find them from each of these individual process - task client and task state2 - active process detail page) and upload it here.
OK, thank you very much, i will allow you instructions.
I am tacking the exacly same issue as Pavel, working for the same company. Can we continue with discussing the problem? Here is the picture of the error:
And here is how it looks like after clicking on the partner link:
Looks like the user with access to all task was used, or should I look somewhere else?
Here is the potential owners and business administrators:
How do I find if avosAdmin has those roles (CMT_EWS_Assess, CMT_EWS_OperatorRSM, abAdmin) assigned? Thank you very much for your time.
Already solved by turning off a cache for roles (IdentityService). However, this cache is quite important for performance, so we will consider using retry policy instead (trying to call getInstance automatically again in case of crash). The rusult is, that we do not need to find out the cause of this crash any more, because that might take a long time.