This area of ERPGenie has moved to WorkflowGenie.COM

Quicklinks

Creating a link between the purchasing group and the personnel number

1. Transaction PFOM
   
   1. Choose the Organizational unit where all the purchasing people sit
   2. Selection period: Today to whenever
   3. Org. object type = T024 (Purchasing Group)
2. Click F7 or the change Icon
   
3. Expand the Purchasing department by clicking the + sign
4. For each Buyer / Sr. Buyer position (or in essence for every Purchasing group) expand the position by click +. (PS: If you want to see the keys as displayed below then click Shift F5)
   
5. Click on the yellow line indicating the buyer the want to link, followed by the Create (relationship) icon (F5)
6. A popup is displayed asking to enter a purchasing group:
   
7. If you know the purchasing group you can type it in or press F4 to see a list of possible entries to choose from
8. Enter the applicable purchasing group and ENTER
   
9. The names need to match up. Repeat steps 5 to 8 until all purchasing groups are assigned to a personnel record.
10. Click BACK to exit.

Rules / Roles

Use PFAC to define your rules / roles. Use OOCU_RESP to assign people to the rules in systems other than DEV.

Raising a business object event with a container

Seeing SAP EMails in the UWL

You can re-route the SAP Office notification mails via smtp to your e-mail server. If you want the mail to appear in the UWL then have a look at a pilot project of SAP codenamed SONiC to do this. Here's the link to SDN to explain more. https://weblogs.sdn.sap.com/pub/wlg/3594

Creating workflows that start with a transaction and without an instance
By Kevin Wilson

1. Create your object <object>using SWO1
1. Add ‘instance-independent’ method CREATE.

   1. In your method call your dialog module to center the required data

   2. Return the key for your object in the dialog module

   3. swc_set_objectkey <object_key_var>

2. Create workflow template using PFTC
1. Add object <object> to the workflow container
2. Create your single step task call the CREATE method
   1. Bind _WI_Object_Id from the task container to the workflow container <object>

   2. <object> now makes the workflow and instance dependent workflow

3. Create a workflow start transaction using SWUG
1. If you have not defined a namespace for your workflow start transactions then you can do it using transaction SWUT
2. Enter your task type, task number and screen number and save
3. Once you have created a transaction you can edit the code using the same transaction SWUG

   1. If you want to bypass the initial screen and simply start the workflow immediately then find the PBO module EXIT_PBO_END_<SCREEN_NO> and insert the following code in the generated perform EXIT_PBO_END_<SCREEN_NO>:
         PERFORM CHECK_OBLIGATORY.
         PERFORM START_WORKFLOW.
         leave to screen 0.

4. Starting the workflow
1. Run standard transaction SWUI, select your workflow and select START
2. Run the transaction that you generated in step 3
3. Run standard transaction SWUS to test your workflow

Debugging a background workflow process

In your method write the following code:

data exit.
Do.
  if exit = 'X'.
    exit.
  endif.
enddo.

Run the workflow, causing an infinite loop on that step, and then go to SM50.
Here you can debug the process.

Cool Workflow Function Modules

• For locking of work items against execution, use the function module SWW_WI_DISABLE.
• For unlocking of work items against execution, use the function module SWW_WI_ENABLE.
• To read the container elements of a particular work item, use the function module SWW_WI_CONTAINER_READ.
• We can change the attributes of the deadline monitoring for a particular work item by using the function module SWW_WI_DEADLINES_CHANGE.

Sending a mail on triggering a particular event

Do you want to send a mail when a particular event has been raised?
1. Go to transaction SWETYPV
2. Select "New entries".
3. Enter the Business object and the corresponding event name. Enter the SAP userid in the "Receiver type" and SWE_EVENT_MAIL as the reciever FM.
4. Set 'Type linkage' to active.
Whenever the event is raised, an SAP office mail is sent to the corresponding SAP user id. This mail also includes the container elements of that particular event.

Passive vs. Active Substitutions
Set substitution from PASSIVE to ACTIVE. The substitution should be in HRUS_D2 from the original user id to the substitute user id for ALL tasks and for the relevant dates. This will make the original user's work items IMMEDIATELY appear in the substitute's inbox - like email auto-forwarding. This will also tell you if you have the substitution relationship between the two users set up correctly.

Now swap from ACTIVE back to PASSIVE substitution. Here the original user's work items DO NOT immediately appear in the substitute's inbox. The substitute must use the ADOPT SUBSTITUTION option in their inbox and select the original user to look at the original user's work items. This adopt substitution is always off when then enter their inbox, so they only see the original user's work items on request.

Returning worklfows attached to a business object

Call function module SAP_WAPI_WORKITEMS_TO_OBJECT

objtype = 'BUS1001006' (e.g. Material - Substitute with the applicable business object) 
objkey = material number
top_level_items = 'X' or space
selection_status_variant = 0000

Worklist is returned with workflows tasks linked to the business object.

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.

Hints on keeping the HR model synchronized between systems.

Use ALE distribution to maintain the HR Model between the systems (Org structure and Central User Administration - CUA)

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

Useful Online Service Notes.

The following notes are continuously updated so that they remain up to date.  It's worth checking for updates now and then.

Dynamic parallel processing in SAP Workflow
Suresh Kumar Parvathaneni

Sometimes we need to process a dialog step (activity) several times in parallel and we may not be aware of how many times exactly this step has to be processed. Consider this scenario: For a sales order, we need to check the available quantity of the line items (materials). For each value of this list, a particular function has to be performed. So we need to create different work items for each material. This is called dynamic parallel processing, since the number of line items is known only during runtime.

To achieve this, follow these steps:

1. We need to define a multiline container for the material.
2. Go to "Others" tab of the dialog step (activity)
3. Enter this workflow container element on this tab.

Restriction : The multiline element should not contain more than 99 values. At runtime, the workflow system generates from the step as many parallel work items as there are values in the multiline container element at that time. The number of values need not be known at definition time. If the table is empty, this step is ignored.