Agent determination issue in a workflow

[#1]

Greetings everyone!

I'm configuring some business scenario with the help of a business workflow in SAP CRM 7.0 I'm using activity step and want to determine agents using standard SAP rule 10000162 ("Employees for responsible org. unit"). I've tested the rule outside of the workflow and it's working fine, but in workflow it fails to determine an agent.

In a log I see following errors:

Agent determination for step '0000000023' failed;

Result of agent resolution does not agree with agents of task;

I've made some tests depending on what assignment task has:

1. When it is a general task, work item was created for a workflow initiator even though rule failed to determine an agent.

2. When it is a task with general forwarding with assigned position(s), which rule will never determine, work item was created for holder(s) of that position(s).

3. When it is a task with general forwarding with no assignments, workflow could not determine an agent as expected.

I've also debugged functional module for that rule and it determines appropriate agent but then do some check with the help of RH_TASK_AGENT_CHECK function and returns an error.

Can someone help me with this problem? Is it some standard expected behavior or not?

Maybe something wrong with the org. plan?

All answers are appreciated.

Thanks in advance,

Alex.

[Former Member]

I've debugged more carefully and found out that the reason of the failure is not the table read of excluded agents. Everything fine at that step.

After check of excluded agents, function RH_CHECK_VALID_ORG_TYPE gets called which checks valid org types ([screenshot1|http://www.picdrop.net/?v=orgtypecheck.png])

It performs FILL_ORG_TYPES ([screenshot2|http://www.picdrop.net/?v=orgtypecheck2.png]) and fills ORG_TYPES table with values. And here the problem comes. There is no CP type in that table after FILL_ORG_TYPES performed.

Inside the FILL_ORG_TYPES form there are two selects from table t779o and t777o ([screenshot3|http://www.picdrop.net/?v=orgtypecheck3.png]) and we can see that we will NEVER get CP org. type because there is no CP type in a table t779o ([screenshot4|http://www.picdrop.net/?v=orgtypecheck4.png]).

So FILL_ORG_TYPES fill the table with org. types but there is no CP type and of course the check of a valid org types will not pass.

So I've added CP into t779o table and now rule works fine. I've solved my issue.

Thanks for participation.

And last question.

Is that a system bug?

Regards,

Alex.

[Former Member]

Hello,

I'm glad you figured it out.

I thought it was strange about the CPs, I've never seen them used before like this.

Can't you convert them to US instead? I would do that instead of adding entries to tables.

It could be that SAP tells you it's not a bug, but you could try anyway.

regards

Rick Bakker

hanabi technology

[Eddie_Morris]

Hi Alex,

Great news.

Regards,

Eddie

[Eddie_Morris]

Hi Alex,

The problem may be due to authorizations of the user who executed the previous work item. This user will be used to

resolve the agent assignment of step 48 and this may be the reason why the work item goes into error. Please make sure their users have PLOG as detailed in note 755767.

Regards,

Eddie

[Former Member]

Hello,

You can test for Eddie's suggestion by inserting an extra step beforehand which calls a dummy background method. This ensures your step is run under WF-BATCH.

regards

Rick Bakker

hanabi technology

[Former Member]

Thank you for your answers Rick and Eddie!

But, first of all, this is the first step of a workflow that creates a work item, so there is no previous step.

Secondly, the work item is created even if an agent can't be determined properly. Technically, there is no fatal error, the log just says that determination is failed, but the status of that executions is success with green icons.

I've tried your suggestions, created a dummy step as in note 755767. It didn't help, still the same behavior. Also step which creates work item and executes rule is created by WF-BATCH regardless of a step with dummy background method.

So I assume that this is not an authorization problem, or am I wrong?

Here's the [screenshot|http://www.picdrop.net/?v=sapworkflowlog.png] of what I'm getting in a workflow log. Maybe it will clear some things.

What else can it be?

Regards,

Alex.

[Former Member]

Hi!

you can check this thread..

Link: []

Regards,

Steph

[Former Member]

Hi, I've checked it. Did not solve my problem. I see the record in a table HRP1217 for my task and it is a general task.

And also I've tried to refresh org. environment, no luck either.

I've tried to use the rule with standard SAP task in a standard workflow for approving quotations, and it is the same behavior there also.

What am I missing here?

[Eddie_Morris]

Hi Alex,

If your rule does not have the option "Terminate if rule resolution has no result" then it will not go into error if no agent is returned. The default behaviour is to send the work item to the possible agents of the task.

You mentioned when you test the rule it returns agents. Are these agents included in the possible agents?

When you test the rule did you get the data from the workflow container in order to test....are you sure all the data needed for the rule is available in the workflow container? If not then this might explain why the rule fails.Regards,

Eddie

[Former Member]

Hi Eddie,

The rule doesn't have the option "Terminate if rule resolution has no result" so I now understand why work item goes to all possible agents or to the initiator if it is a general task.

Agent which is returned by the rule is included in the possible agents of the task if I set it as a general with forwarding.

If it's a general task I assume every agent can be a possible one.

When I tested the rule I did get the data from workflow container and the only data is needed for the rule is a responsible sales org unit which is passed to the rule in binding.

I am sure also because I did turn on workflow container diagnosis and get a popup window where I see what value the rule gets from the workflow and also I see that when debug FM assigned to that rule. Here is the [screenshot|http://www.picdrop.net/?v=debugcontainerwindow.png] of container contents. SA_RESPORG is what rule expects to receive. And it does receive it. And I've tested the rule with that value and it does return [result|http://www.picdrop.net/?v=ruleresolutionresult.png] as expected in PFAC.

What am I doing wrong?

Regards,

Alex

Edited by: Alexander Milshtein on Apr 8, 2011 1:21 PM

[Eddie_Morris]

Hi Alex,

Have you set the task as "General Task" or "General forwarding allowed". If it is "General forwarding allowed" and you have not assigned any specific users/positions/org units then there are no agents assigned to the task. "General Task" means everyone is a possible agent...."General forwarding allowed" means nobody is assigned.

Regards,

Eddie

[Former Member]

Sorry, duplicate message...

Edited by: Alexander Milshtein on Apr 8, 2011 1:34 PM

[Former Member]

I've tried both options.

1. General task - All possible agents. Rule fails to determine and creates work item for a workflow initiator.

2. General forwarding allowed - Assigned position with the central person which rule returns if I test it in PFAC.

I understand, that when it is not a general task we have to assign possible agents. And I did that when set the task as a "General forwarding allowed" ([screenshot|http://www.picdrop.net/?v=taskpossibleagentsas.png])

Regards,

Alex

[Eddie_Morris]

Hi Alex,

Can you assign the user or user directly to your task TS90000001 rather than assigning the postion S 50000086. Maybe there is a problem with the link between Position - CP -US. Does this help?

Regards,

Eddie

[Former Member]

Hello,

Just make it General Task and set it to fail if there is no rule resolution.

Thanks for the screenshots, they really help.

CP values should work as a rule result. Try using that one directly (ie without a rule) in that workflow and see if it works.

regards

Rick Bakker

hanabi technology

[Former Member]

Hello Rick and Eddie.

I've tried to assign user directly instead of position to a task with no help. I get the same result.

I've tried to set a task as a general task and made the rule to fail if there is no resolution and it fails.

I've tried to assign position or user directly to activity in a workflow and it does work but that's not what I need in my scenario.

As I said earlier I've tried to debug that rule invoked from a workflow. I will post some screenshots for you.

I set a task as a general task and assigned rule 10000162 (ABBR="PARTNER_1", Name="Employees for responsible org. unit") to activity step in a workflow and here is what I get:

1. Function CRM_ORGMAN_ORGOBJECTS_FIND_2 gets called by the rule and resp. sales org. unit is passed there ([screenshot1|http://www.picdrop.net/?v=debug1.png])

2. Next function CRM_ORGUNIT_GETEMPLOYEES gets called passing id of a resp. sales org.unit without a type.

3. Next RH_STRUC_GET gets called and returns result table with position and central person for that position ([screenshot2|http://www.picdrop.net/?v=debug2.png])

4. In the end of CRM_ORGMAN_ORGOBJECTS_FIND_2 function only central person in inserted to the actor_tab ([screenshot3|http://www.picdrop.net/?v=debug3.png])

5. After CRM_ORGMAN_ORGOBJECTS_FIND_2 ends we appear in a RH_GET_ACTORS function where we can see that agent check is performed if act_task is not initial. I assume that check is not performed if we do a simulation of a rule ([screenshot4|http://www.picdrop.net/?v=debug4.png])

6. Then RH_TASK_AGENT_CHECK function gets called for every record in a actor_tab. In out particular case it's one record. ([screenshot5|http://www.picdrop.net/?v=debug5.png])

7. Inside that function checks act_wi_id (activity work item id?) if it's initial and get exluded agents. It is initial in my case ([screenshot6|http://www.picdrop.net/?v=debug6.png])

8. Then function tries to read table with keys equal to type and id of found agent and errors there, perhaps because there is no record in that table ([screenshot7|http://www.picdrop.net/?v=debug7.png])

That error results in overall agent determination failure.

Hope this screenshots will help to identify a problem.

Why read table results in an error and because of that all rule fails?

Regards,

Alex.

[Former Member]

i've already checked the rule in PFAC transaction and it works fine. I've also done a binding and checked it while testing workflow and debugging that rule. Workflow pass required input parameter to the rule.

Edited by: Alexander Milshtein on Apr 7, 2011 1:52 PM

[Former Member]

Hi,

Please simulate/test Rule 10000162 seperately through transcation PFAC.

Get the input form the workflow container.

This is happen when rule is unable to fetch the agents.

Please check the binding of Workflow to rule as well whether the correct data is passing or not.

Check the workflow container values as well.

Maintain the Task Attribute as 'General Task'

Thanks and regards,

SNJY