Creating a step where a supervisor manually assigns an operator to another workflow step.
Use the business object WF_TASK. There are several possible methods to use. Refer to the documentation of the methods to determine which is suitable for your task. If the task is customized as a general task the supervisor can suggest user names directly (using wild cards), otherwise the supervisor selects from a list of possible agents.

Troubleshooting when the workflow does not start correctly.
Case 1: When the workflow does not start.
If the workflow does not start this is either because it is not being triggered properly or the workflow definition is not complete. First determine how the workflow should be started. Directly? Via a customizing table? Via an event? Transaction SWUD offers intelligent diagnosis help to establish if the flow was started, if the triggering event was fired, if the flow is syntactically correct, if users are assigned to all the tasks...

Case 2: When the workflow starts twice.
The most probable cause of a workflow being started twice is that it is triggered by two separate mechanisms simultaneously. For example if the flow is being triggered by an event, check that this event is only firing once. For example, you might find that it has fired once due the customizing for change documents AND once due to the customizing of status changes.  Transaction SWUD will allow you to determine how many times the event is firing. If it is only firing once, check that the workflow is not additionally being started directly by a program or customizing tables. Check that the workflow is not customized to trigger on two separate events.

Sending e-mails from the workflow.
There is a wizard in the workflow editor which will help you send straightforward e-mails from the workflow. The wizard generates a step based on the business method SELFITEM SendTaskDescription. You cannot modify the business object SELFITEM and delegate so if you want to do something more sophisticated you should build your own method in another object based on the function modules SO_xxx_API1. These function modules are the APIs for sending mail and are fully documented. Use the where-used list to see examples.

Different mechanisms for accessing work items.
In an early stage of the project you should consider the issue of how users are going to be notified off and access work items. Usually this decision will not influence the definition of the workflows but there may well be organizational issues involved which you should consider early on. ASAP contains a table of alternative methods. The most common being:
mySAP.com Workplace
SAP Business Workplace (previously the universal inbox)
Microsoft Outlook
Lotus Notes
e-mail
Web Inbox
The e-mail notification can be done automatically without modifying your workflow at all. For tighter integration into other mail programs you can add form functionality for the workflow steps that will most gain from this.

When to use asynchronous tasks.
Asynchronous tasks are often misunderstood so here's a short note about them. You'll find a fuller description in the online documentation. Asynchronous tasks only terminate when a terminating event is received. This makes them especially suitable for tasks where you want to be absolutely sure that the user has done what was intended. The event is usually triggered within the method itself when the terminating condition is met.
These cases cry out for being implemented as asynchronous tasks:
The user MUST make a change in the business object (e.g. status change)
Post-processing of the method takes place in the update task and it is essential that the workflow does not continue until this post-processing has fully completed (e.g. creation of a business object)
Some users often perform this task directly from the menu without accessing the workflow system so feedback via the event is essential to ensure that the workflow continues automatically.

Ensuring that your workflow is robust.
Check that your workflow definition will not stall or get confused when a user performs several tasks in one step. Try not to dictate the order of processing with your workflow definition unless this is a necessary part of the business process flow. Allow the users to work the way they want but make sure that they are kept within the realms of the business process framework. Check that the workflow synchronizes properly with other events. For example, if a purchase requisition is withdrawn the workflow should terminate immediately and send notifications to all users involved in the process so far. Use deadlines to ensure that the process runs through on time and that a supervisor is informed when a delay occurs. Often the cause is simply due to illness or vacation and the task can be performed by someone else.

Documentation issues.
Workflow is dynamic. You can change the business process without sending everyone to be retrained so bear this in mind with your documentation. Your documentation should be written to ensure that any changes which are made  can be done easily and without upsetting any aspects of the process.

Documentation for the operational user can be made available online with a URL included in the work item description. This documentation should contain help-line numbers, what to do if you receive a work item intended for someone else (you've left the department), FAQs, whether the user may create ad hoc attachments (the other users must be aware of the possibility if you want to make use of this functionality)...

Documentation for administrators should include how to perform periodic health-checks, how to add a new user to the process (and how to remove someone), what to do when a user is absent for a short period of time, contingency plans, list of counterparts in different parts of the process if the process is cross-application.

Technical documentation must include a complete catalogue of all workflows, tasks, business objects and roles used in the process. There is ample room within the system for documentation about the individual components but of particular importance  the events. These must be documented in the system, explaining how they are triggered (E.g. program xxx, status changes...). The workflow documentation should explain how the workflow is triggered (E.g. event, program...). Subflows should be labeled as such. Synchronization issues should be documented carefully so that changes can be made without jeopardizing the process

Return to :-
SAP ABAP/4 Programming, Basis Administration, Configuration Hints and Tips