0% found this document useful (0 votes)
55 views21 pages

Session 22-Agent Determination Errors

Session 21-To launch Web Dynpro from SBWP Business Workplace
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
55 views21 pages

Session 22-Agent Determination Errors

Session 21-To launch Web Dynpro from SBWP Business Workplace
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 21

Agent Determination errors

Define task as General Task: Condition Applied


Case 1: The agents are determined, still work-items/request it is not sent to approvers.
Issue: The task is not defined as general tasks in Attributes section. But if you define the general
tasks at design time , you may face problems at run time. Since if agent determination fails
then the work-item is sent to all the valid sap user id’s.
Hence to avoid such situation and to resolve , we should try the following..
1. Instead of making it a general task, try to identify an actual list of 'possible' agents. This could
be by positions, userIDs, Org Units, etc. Make this list your possible agents instead of defining it
as a general task. At runtime the logic fails to determine an agent, then an error message is sent
to the WF admin instead of the task being sent to everyone.
2. Make sure your logic for determining the agent always return an agent. If you are using a
custom rule, then at the end of the logic check to see if an agent was determined and if not,
identify a default agent (like a WF admin or business analyst) that can receive the item and
investigate who to properly route it to.
Buffering errors.
Execute SWU_OBUF before testing your workflow changes.
To resolve buffering errors
1) Use Synchronize Runtime Buffer ( SWU_OBUF)
Always refresh the runtime buffer when you have made a change in a task definition or after
transporting new workflows or versions of workflows that are to be used on the day of transport
2) Use the refresh organizational environment option in Business workplace ( SBWP) or in start
workflow function ( SWUS) .This refreshes buffers for current user id .

Work-item Errors
SWI1_Rule - Execute Rules for Work Items
If we redefine the agent determination rule or change the attributes of task for e.g. General task. Then we need to
execute the t-code SWI1_RULE for all those dialog work-items which has already been executed but without agents.
Thus once executed the receiver/agents will receive the requests.

SWI2_Adm1 - Execute Work Items Without Agents


If we still need to execute the work-items if no agent is determined, then the tcode SWI2_ADM1 is executed.
SWIA - Execute Work Items without Agent Check
SWIA t-code can be used to diagnose the workflow and execute the work-items.
SWPR- Workflow Restart after Error
We can restart the workflows which are in error state after resolving the errors using the tcode SWPR.
SWI2_DIAG -Diagnosis of Workflow With Errors
If we need to find out what went wrong with workflow which has forced the workflow to end up into error then we can
execute the tcode SWI2_DIAG.
SWPC - Continue Workflow After System Crash
We can restart the workflow after the system crash by using the t-code SWPC.
SWUD- Workflow Diagnosis
Whole workflow can be diagnosis by executing the t-code SWUD.
SWUS- Test Workflow
If we need to test the workflow stand alone we can execute the t-code SWUS.
Event Linkage Errors.
SWE2 - Event linkage with BOR/Class object type

We need to check whether the linkage is activated or not in SWE2 for that workflow and BOR/Class. Since once the
workflow gets transported to other systems, the workflow which all are associated with events do not get trigger since
the event linkage gets deactivated. Hence we can activate the event in SWE2.
SWELS - Switch on the trace

To trace which event is associated with which application we can switch on the trace in SWELS and then run the
application. Then we can see the log in SWEL to see the event trace. In production SWELS should be switched off to
avoid performance issues.

SWEL – Event trace


To see the log we can execute the SWEL t-code , where we can see which event is associated with which
BOR/Class and which workflow is tagged/associated it with event.

SWUE – Test the event and check Function module

We can trigger the workflow which are associated with event using t-code SWUE , we don’t need to run application
many times instead we can use t-code SWUE to trigger the workflow by providing object key and event parameters.

You might also like