Workflow Rules

[Former Member]

Hi All,

I have created a workflow,in which i am determining agents by Rule.If we go to transaction 'pfac' and excute the rule it gives me the required result but after using the rule in workflow it is not at all giving me any result ( i.e the workitem is send to all users )I even tried sending it hardcode values.

Thankx and Regards,

Prajakta

[Former Member]

Hi Mike,

As i said earlier this rule was working fine and it did execute the step sucessfuly , so there is not authorisation problem.

1) I dont have any dialog step before it. This is the first dialog step in my workflow.

2)I didnt get this idea , can you give in details.

Alternatively, insert a dummy background step before the failing one - this will switch processing to the system user WF-BATCH.

3) I tried using a User and gave my user-id ,it worked.

Thankx and Regards,

Ranju.

[pokrakam]

Hi,

OK, so this would still indicate an auth problem.

The 'previous' user in your case would be the user who triggered the WF. Look at the <i>technical</i> log, expand the first few steps. You should see which user triggers the WF.

Run an auth check (/nsu53) for that user immediately after they performed whatever it was that triggered the WF. How is the flow triggered? Doesn't sound like you're using events, because events start the flow under user WF-BATCH.

As to inserting a dummy step, just create a method with no code in it, define it as background and create a task based on that method. Insert it as the first step in your WF. Because it's background, the system will execute it as WF-BATCH, and the next step will evaluate it's agents under this user. NOTE, this should be for testing, as it doesn't really address the problem.

Cheers,

Mike

[Former Member]

No i havent used condition USER name.

I have written a Rule which internaly calls a function module which gives me the AGENT.

This functionality was working earlier but since the change in pakage it is not working.

[Former Member]

Hi Guys,

Thankx for your inputs.

1) I have tried all that before , i.e the binding's,type of the conatiners etc .

2) For this worflow we have Test users so they dont have access to any other transactions other than Inbox and Marketing Planner, so the other thing cannot be tried.

3) This workflow was working fine with all that i wanted but , it was initialy stored in $TEMP pakage so i changed it to a std pakage. Since then this is not working

Now i have tried all kind of bindings,created a new rule even created a new workflow.But still nothing is working.

Can the change in the pakage cause a problem ?

[Former Member]

Hi,

Did you use any System variables(like SY-UNAME) in your Function module that determines the AGENT?

Regards,

<i><b>Raja Sekhar</b></i>

[pokrakam]

When you say

> 1) I have tried all that before , i.e the

> binding's,type of the conatiners etc .

Does that include authorization checks? Because:

> 2) For this worflow we have Test users so they dont

> have access to any other transactions other than

> Inbox and Marketing Planner, so the other thing

> cannot be tried.

That seems to back up my suggestion that you look into authorizations. Other ways to check:

Immediately after the user of the <i>previous</i> step has executed their bit, do a /NSU53 in the same session. This is because the agents of a task are evaluated by the previous task's user if it is a sequence of dialog tasks.

Alternatively, insert a dummy background step before the failing one - this will switch processing to the system user WF-BATCH.

Another way to test this is to change your agent assignments to make sure the step which is failing <i>and</i> the one <i>before</i> it are executed by yourself - since you have the necessary auth's.

Cheers,

Mike

[Former Member]

Hi,

May be, why dont you check your Bindings from WORKFLOW CONTAINER to RULE CONTAINER?

Regards,

<i><b>Raja Sekhar</b></i>

[pokrakam]

Hello Prajakta,

Is the work item being executed with the same userID that you tested it with? If not, it is likely an authorization problem.

If the user in question doesn't have authorization for PFAC, you can also test rules using OOCU_RESP. Simulate the role resolution under that userID, then do an auth check immediately afterwards (SU53) to determine which authorizations are missing.

Cheers,

Mike