Jump to content

Error Business Process


Nikolaj

Recommended Posts

Hello support,

can you please help me i get this error:

Xmlmc method invocation failed for BPM invocation node 's1/task-88ad8e69': 0200 task taskCreate2 The specified user 'SYS_BPM_MANAGER' does not exist

thanks

Nikolaj

Link to comment
Share on other sites

Hi Nikolaj,

I'm not sure what the issue is, but as a possible workaround you may want to look at the BPM workflow where the error is happening and look at the nodes that create Human Tasks.  If the Owner field is left blank, it makes the SYS_BPM_MANAGER the owner.  Try adding a user as the owner.  You could add a team leader or manager as the owner.  This has an added advantage that the Owner can view these activities in their Activity Calendar and they can also re-assign the tasks they own to other users.

image.png

If you have requests that have a red or broken BPM, it is possible to also fix these.  Have a look at this post if this is the case 

I hope this helps.

Regards,

James

Link to comment
Share on other sites

@Steve Giller Thanks now it is working for all my users. A bit strange because for me and some other colleagues it was working fine. but for some others not when they initiate the process.

As you can see now i have it two times. one in the beginning because i had it before and this is how i do it normal. and one you told me after change approved and  before Human Task. (nodes waiting for change owner and get request details). But if it works then  it is fine by me.

Thanks

Nikolaj

image.png.06a7ed82e08c7a56ed531e6d462eb1e3.png

 

Link to comment
Share on other sites

@Nikolaj the error you reported is typical for when the task is configured be assigned to a user via a flowcode variable usually the request owner. If when the task is created the flowcode variable for owner does not have a value it will be replaced with SYS_BPM_MANAGER value but a user with this ID does not exist hence the error. 

One would need to ensure the variable has a value when used for assignment of a task and mind you this does not necessarily mean the request having an owner at the time the task is created... is all to do with the values for flowcode variables ... if the values for the variables get populated when the request did not have an owner and not refreshed afterwards (e.g. after the request gets an owner) then there won’t be a value for the variable when the task is created and the error will occur...

Link to comment
Share on other sites

@Nikolaj just wanted to make sure that you do indeed need to assign it to a role instead of the owner ... having the task configured to assign to a role might mean that the task is not necessarily assigned to the request owner... if you do need the task assigned to the request owner then I would say have it configured to the owner ID flowcode variable...

I'll expand on my above explanation in case someone else (or even you) are interested in this in more detail, it is not something very easily understood without explanation .... this is something I also explained recently to our partner in the US... so:

When using "Get Request Details" node, this will create a set of request variables (such as owner, team, request type, and may others) which will be available throughout the process. The purpose of this is to provide the ability to design the business process using dynamic values rather than static hard coded values. 

The set of request variables that gets created by the node represents a snapshot of the request as it existed at the time the node was reached and they are not automatically refreshed (!). This is very important. So all the variables for request data will have a set of values based on the request data available at a point in time. For example, let's say you have this configuration:

image.png

 

When the process starts it will have a "Get Request Details" node which means a set of flowcode variables get values. At the time the node runs, let's say the request does not have an owner as such the value for Owner ID will be empty. The process continues doing various stuff then it gets suspended waiting for a request owner. The request is assigned, the process resumes and attempts to create a human task and assign it to the request owner and it fails. Now, one would wonder why since the request has an owner. The reason is that the value for the Owner ID variable is still empty as it was created in the beginning, when the request did not have an owner. Because the values for the variables holding request data do not automatically refresh when any of this data is changed it means that our variable still has no value regardless of what happened on the request between "Get Request Details" node and the human task. How do we cater for this? We can do the following configuration:

image.png

 

What we did there is to add another "Get Request Details" right before the Human Task to refresh the values for the variables holding request data. When the second "Get Request Details" node runs, because the request now has an owner (following the suspend wait for owner), it means that the Owner ID variable now does have a value and the Human Task will be created successfully.

I will expand on this example to show a bit more complex scenario to stress the importance of refreshing the values for these variables at key points in the process and how to do this a bit more efficiently. We can have the following configuration:

image.png

 

We now have two Human Tasks, one created after the request is suspended for an owner and another after the request is suspended for prioritisation. For the first task we have a "Get Request Details" right before creating the task to refresh the variables for the reasons detailed above. For the second task however we do not have such a node because we already have refreshed values with Owner ID having a value. However because we have another suspend point (wait for Request Priority) it means that while the process is suspended anything can happen to request data. It does wait for a request priority but during this suspension the request can also be assigned to a different user or even a different team. A user can for example re-assign the request then prioritise it, the process will resume only after prioritisation. Because we do not refresh the variable value before creating the second task it means the second task will be assigned to the previous owner which might not make sense. An obvious solution will be adding a "Get Request Details" before the second human task.

image.png

 

However this creates another potential dangerous scenario: let's assume that while waiting for Request Priority, a user re-assigns the request to a team but no owner. The "Get Request Details" before the second Human Task will refresh the variable values meaning that now, Owner ID will be (again) empty which means the task will fail to create. A solution would be to actually check the variable values, before creating a  human task especially the ones we use in a human task to make sure they have values and/or they have the correct values. Like this:

image.png

 

The decision node there will branch the process into another Wait For Request Owner in case the Owner ID variable is empty. It will join back the main flow once an owner is assigned (obviously followed by a variable value refresh) which will create the task.  It is possible that one simple adds a "Wait For Request Owner" followed by "Get Request Details". The reason for the decision is to deviate the process only if a request does not have an owner which means the additional nodes added asa fail safe will only run in a specific scenario rather than all the time. It simply makes the process run more smoothly more efficient and less resource intensive. My advice would be to always use a decision node to check for values rather than simply put a "Get Request Details" because on many occasions it is not actually necessary and is an overkill that usually makes the process unnecessarily more sluggish. Happy to cover this in more depth if necessary and offer other examples if needed.

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...