This note will provide you with some troubleshooting tips so you can analyse any workflow problems

in your system. The note is divided into the following areas. [1] Agent Assignment/Agent Determination Work items are not going to the correct users or to any users in your system. You need to troubleshoot the issue. Once you have identified the workflow template and step where the problem occurs you need to check the following: Possible Agents Identify the task assigned to the step in the workflow template via the builder and click on the 'Agent Assignment' button. This brings you to 'Maintain agent assignment' screen for the task. (Alternatively display the task via transaction PFTS or double click on the task ID in the step. From the menu goto Additional Data => Agent Assignment => Maintain or Display) If there are no possible agents assigned to the task or it is not set to status 'General' (available to all users) then this is most likely the reason for the agent assignment issue. You need to add users/positions/Org Units/etc to the task or set it as General. Responsible Agents Get More information on SAP ABAP Questions And Answers Responsible agents are assigned in the workflow step in the 'Agents' section. Typically you will see Positions, Expressions or Rules used to determine the responsible agents. You must check to see if any agents are returned at runtime. If the possible agent assignment of your task is ok then you need to test the responsible agents. Troubleshoot as follows: Rule If you use a Rule then you can simulate the rule execution via the 'Simulate rule resolution' button in PFAC. A rule will receive data at runtime from the workflow container so please check the binding in the workflow definition to see what data should be passed from the workflow container to the rule container. Then select the work item instance that has the problem and use the data from the workflow container for your simulation. When using the Simulation option in PFAC make sure you use F4 to enter the test container data. If the agents returned are not what you expected then you must check the rule implementation e.g. do you use a custom function module or have you maintained Responsibilities. Special feature for authorizations in the workflow Expression If you use an expression to determine the responsible agents then you will need to check the work item instance where the problem has occurred and see what value is contained in the expression in the workflow container. If it is a value that is unexpected then you must identify where the expression is filled in the workflow and investigate why the value is incorrect. A good way to find out exactly which steps use a particular container element is by right clicking on the container element in the workflow builder and selecting the "Display were-used list in graphic". This will highlight all the steps where the container element/expression is used. Useful Transactions PFAC - Maintain/Display Standard Rule PFTC - Task Maintain/Display SWDD - Workflow Builder PPOSW - Display Orgainsational Plan [2] Hanging Workflow This area is broken down into 4 sections Work item enqueue SM58/SWU2 Short Dump during method execution Transactions to restart work item in error Learn More About SAP ABAP Transaction Code Work Item ENQUEUE If a work item is being executed and the workflow runtime system tries to access the work item then it will not be successful due to the lock or enqueue currently on the work item. Some examples are: Example 1 An asynchronous task is being executed by a user. While the work item is being executed the terminating event is raised in the system and tries to set the work item status to COMPLETE but cannot due to the lock/enqueue.In this

case the event is buffered in the event queue. As soon as the work item is released, it will deliver the buffered event immediately. Example 2 You use parallel processing where you have a fork with 2 branches (1 Branch necessary for completion). In one branch is a dialog activity step and in the other is a 'Wait for Event' step. While the dialog step is being executed by a user the Wait for Event step receives its event and continues along the branch and completes the fork (Remember only 1 branch needed for completion). Once the end of fork is reached the dialog work item should be set to status Logically Deleted but this does not occur due to the lock/enqueue on the work item while the user is executing it. Since a callback is essential for a workflow to continue running, this callback is suspended (stored in the SWP_SUSPEN table). These callbacks are started again via the RSWWERRE report. If you have not scheduled report RSWWERRE then the work items will remain in table SWP_SUSPEN and the work items will not receive their callback and will therefor will not continue. Troubleshooting If there are examples of work items hanging then check table SWP_SUSPEN to see if the callback work item ID is there. If it is then make sure you have the RSWWERRE job running in order to redeliver it. If RSWWERRE is running and the entry is not being delivered then please check for notes using the search term "RSWWERRE" and "SWP_SUSPEN". If there is no entry in SWP_SUSPEN, then check the workflow definition to see if the work item is asynchronous i.e. needs a terminating event as in Example 1 above. Check the event queue via transaction SWEQADM to see if the terminating event is being buffered there. If it is then it should automatically be redelivered so do a notes search in relation to the event queue. Study more about SAP ABAP Tutorials SM58 or SWU2 Sometimes if there are network problems, system crash, tRFC &qRFC issues in your system you may find that work items will hang. If you check the workflow technical log you will see work items in status "In Process" or "Complete" that will not contine to the next step. The best option here is to check SM58 to see if there are entries here in relation to the tRFC execution. If you want to find out the corresponding work item to the entry in SM58 then double click on the entry under 'Transaction ID' and this will provide some useful information such as the standard task, business object, object instance, related event and work item ID. These details are not always provided but you should be able to get enough information to be able to track down the work item ID e.g. If it has the Task ID then goto SWI1, enter the Task ID as well as the date & time of the entry and you should be able to narrow it down. Useful Information The entries in SM58 can be restarted as long as the issue that caused them to be there in the first place has been resolved. You can select the entry in the list and then goto the menu: EDIT => Execute LUW to restart one entry. If you want to process many entries then goto the menu EDIT => Execute LUWs or schedule the report RSARRCEX with the correct data. Short Dump during method execution Check ST22 to see if there are any related short dumps to the hanging work item. If you search ST22 with the date and time the work item was executed as well as the executing user or WF-BATCH. You can usually find out exactly where the dump occurred and if it is custom code or SAP Standard code. A short dump may occur for example in custom code due to poor exception handling within the method code. If this is the case then the best option is to test the object method via transaction SWO1 with the data from the work item container which you can get from the workflow log. If the object method is SAP standard code then you will need to identify which application area is responsible for the object method and create a message in this component. Useful Information Goto SWO1, enter the business object and click the Display button. Then click on the Basic Data button . You will see the Program name associated with the business object listed here so please just run report RSSTATUS to find the conponent that owns the object. e.g. Object FORMABSENC Program name: SWUFORMA Run report RSSTATUS: Component BC-BMT Transactions to restart work item in error SWPR - Workflow Restart After Error SWPC - Continue Workflows After System Crash SWF_ADM_SUSPEND - Restart Suspended Workflow Callbacks SWF_ADM_SWWWIDH - Restart Suspended Deadline Callbacks [3] Performance in SAP Business Workplace (SBWP) The overall performance of of SBWP can be controlled by a number of factors which are listed below. Archiving Table access & performance

Performance of SBWP (Available BAdI's) RFC Archiving Please put a WORKITEM archiving strategy in place so you can keep your workflow table size under control. You use transaction SARA and archiving object WORKITEM in order to archive work items and this will list the tables that will be affected. The lower the number of entries in the workflow runtime tables the beteer the performance of the workflow engine. Table access & performance Performance of SBWP (Available BAdI's) If you are experiencing performance issue in SBWP the main reason being that users have far too many work items in their inboxes (Several thousand). Some customers have a business need to have all work items in their inboxes rather than use more specific agent assignment (Call Centre scenario). Therefor several BAdI's were provided to improve performance e.g. reduce the number of work items in users inboxes WF_BWP_SELECT_FILTER This BAdI enables you to limit the number of the work items displayed by filtering. It is mainly suited to scenarios where all users are working on the same inventory of work items (for example, call center). WF_BWP_DYN_COLUMN Hiding the dynamic columns improves performance in the Business Workplace. If this is not possible, you can implement the BAdI WF_BWP_DYN_COLUMN to determine the values of the dynamic columns directly from the application data. WF_BWP_OBJ_ATTRIBUTE With this BAdI, it is possible to set the default attributes of the dominant object (_WI_Object_ID) and the grouping characteristic (_WI_Group_ID). The default attributes are used for grouping according to content, and grouping according to sort key and for hiding the group object column and work item content. The BAdI is available with Note RFC If you go with registering the destination you must have your RFC parameters set correctly so that there are not delays in processing work item execution due to lack of available dialog processes and so on. [4] Events Deactivation of Event Linkage When the event linkage gets deactivated, a mail is sent to the SBWP of the WF administrator, detailing the cause of the error. Ususlly this is due to incorrect data being passed from the Object event to the event receiver/workflow template. Please check the inbox(not workflow inbox) of the Wf admin for mails around the time of the deactivation and you should get your answer. Have you thought about using the Event Queue (Transaction SWEQADM)? You can use the event queue to try an balance the load of workflows being triggered. The event queue will store the results of the event linkage temporarily in a database table after the start conditions and check functions have been evaluated (If you use Start Conditions). However, you can also use the event queue to store events that are in error and when you have corrected you can redeliver the events. In SWE2, set the flag 'Enable event queue' in the event linkage. Also set the 'Behaviour upon feedback' = Do not change linkage. You can set the basic data of the event queue with transaction SWEQADM. Troubleshooting Deactivation Activate the Event log (transaction SWELS). As soon as the linkage gets deactivated again, please check the event log with transaction SWEL and it should have an entry for all successful entries but will also have entry for the one that deactivated the linkage. If you double click on this it should give some information on why this is happening. (It is not advised to leave the Event log switched in Production for long periods as it may cause performane issues. Switch off once the linkage is deactivated) What event is triggering the workflow? Is it SAP standard or a custom designed event. Sometimes with custom designed/raised events, not all information is passed from the event to the receiver/workflow and so will cause deactivation. In order to analyse the event container you could do the following: Define a new entry in SWE2: Enter the Event, for the receiver type enter a user name (your user name), and for the receiver function module enter SWE_EVENT_MAIL. You will then get the event container in an email for every event and can see if some data is missing. It could be possible that a mandatory input element in the workflow is not passed from the event. Useful Transactions

SWELS - Switch the event trace on/off SWEL - View the event trace SWU0 - Event Simulation SWUE - Create Event SWEQADM - Event Queue SWETYP - Type Linkages SWEINST - Instance Linkages [5] Transport (a) Workflow Templates Versions & Activation This is how versions work in relation to transporting Workflow Templates Create or make a change to a workflow in your development system and transport it to Test. If the workflow already exists in Test and it has running instances then a new version of the workflow is created automatically in Test. This is done so that the existing instances can use the old version and new instances created after the transport can use the new version. If the workflow already exists but had no existing instances (In Test) then it would simply be overwritten with the new transport. You do NOT need to have versions synchronized between systems. Get more information about SAP ABAP Courses Troubleshoot versions & activation Do the Source and Target systems have the same system date & time? If you created any new container elements in your workflow can you make sure that the their data references also exist in the test system. Did you create any new tasks and add them to the workflow in the development system. If so please make sure that you also transported the task to the quality system. Have you checked transaction SWDM -> Extras -> Transported workflows in the target system? It will show up in red if there are any issues. Useful Transactions SWDM - Business Workflow Explorer (b) Agent Assignment The options for transporting agent assignment (e.g. Possible agents of tasks) or organization structures are as follows: [1] Automatic transport of all Org plan changes. Table T77S0, entry TRSP.CORR is set to space. [2] Manual transport of Org plan changes, by manually selecting what part of the Org plan is to be transported. Table T77S0, entry TRSP.CORR is set to 'X'. Program RHMOVE30 performs the transport. [3] Transport via an object lock by using a change request. Table T77S0, entry TRSP.CORR is set to 'X'. Program RHMOVE50 performs the transport. [6] Extended Notifications & Delta Pull If you are experiencing performance issues with SWN_SELSEN or RSWNUWLSEL then please review the following notes and tips. The selection of the notification/workitems is logged by using the application log. You can influence the log level via transaction SWNCONFIG. Call transaction SWNCONFIG -> Goto the General Settings. There is a setting called MAX_PROBCLASS. When you choose e.g.log level 1 then only the very important information is logged. Changing the log level may help with performance. The main tasks of program RSWNUWLSEL (in FULL mode) are Selection of all open dialog and deadline work items in the system. Open means status READY, SELECTED, STARTED and COMMITTED Determine the agents of these work items Create notifications (relation work item to user) Store them in table SWN_NOTIF. This means insert new notifications, logically delete obsolete notifications and update notifications. Check the following: Are there open work items belonging to tasks where there may be an agent assigment issue. e.g. If a task or tasks have a position assigned to them but the position no longer exists. If this is the case then RSWNUWLSEL tries to determine the agents of work items without any result and will slow performance. One way to determine this is to run transaction SWI2_ADM1 to see if there are many work items without any agents. If this is the case then reorganizing your work items in your system will help. Also check if the work items are still relevant and if not maybe they can be

archived or deleted. For information about deleting and archiving work items, please take a look at note 573656. In addition there is program RSWNNOTIFDEL. This program deletes entries from table SWN_NOTIF which are in status logically deleted. A notification gets status logically deleted the corresponding work items is completed (processed). So to keep the number of entries in SWN_NOTIF as small as possible you should schedule RSWNNOTIFDEL periodically. A suggestion would be running it with the default value 10 days. If this is not sufficient you could change the value later on. [7] Transactions for troubleshooting SWUD - Workflow Disgnosis SWDM - Business Workflow Explorer SWUS - Test Workflow SWU8/SWF_TRC - Workflow Trace On/Off SWU9/SWF_TRC - Workflow Trace Display SWF_APPL_DISPLAY - Display Application Log SWU0 - Event Simulation SWELS - Event Trace On/Off SWEL - Event Trace Display SWPR - Workflow Restart After Error SWPC - Continue Workflows After System Crash SWI2_DIAG - Diagnosis of Workflows with Errors SWU2/SM58 - Workflow RFC Monitor

A log entry is written for every receiver found for every workflow event triggered by function module SWE_EVENT_CREATE. This also applies to the workflow events triggered by message control, change documents or status management. This log takes time to write. This log is mostly only interesting in test situations, that is until the workflow administrator can be sure that all of the event linkages of the used workflows are set correctly. For this reason, the SAP default provides for the writing of the log entries to simplify a possible error search. Creating a workflow event slows down the triggering program. The log of the workflow events should be deactivated at the latest by the time production starts. It should only be active in production system if this is necessary for an error analysis. You can deactivate the log of the workflow events as follows 1. Go to the workflow developer menu: Tools -> Business Engineering -> Business Workflow -> Development 2. There, deactivate the event log: Utilities -> Event log -> on/off .

Create basic workflow to display material Step1 Execute transaction SWDD Execute transaction SWDD and press the create button. If this is your first time in this should already be at this point.

Step 2 Add activity step type Either right click on the undefined step->create->activity or drag the activity type step onto it from the left menu.

Step 3 Create task Click on option arrow at side of display icon to create new task

Step 4 Assign object method Enter Abbr., Name and desired object category, object type and method. In this example I am using method DISPLAY within object type BUS1001006 which displays the material transaction. Click yes on the transfer container elements popup dialog.

Step 5 Possible Agent assignment Go to menu option Additional data->Agent assignment->Maintain. From here you can either click on Attributes and assign to General Task or click on the Create agent assignment icon to assign a specific agent (user, role, job etc). We are going to do the second option

Step 6 Create possible agent assignment Click on the Create agent assignment icon and choose the user option from the popup window, then enter your own SAP user name. Thats agent assignment donbe so click the back button to return to task details screen

Step 7 save task Within the task press save followed by the back button to return to the step screen. You should see the following popup screen to define container elements and binding. Simply press the green tick to accept the defaults.

Step 8 Assign actual agent and save Within the Agents section, click on the Expression dropdown and select workflow initiator (expression). This means whoever initiates the workflow will become the agent. Now press the green tick at the top of the step details screen to save this step

Please note you can also get to agent assignment via this screen by clicking on the yellow egg shaped agent assignment icon on the step screen (above). Step 9 Access container Within the left menu choose Workflow Container to see available containers

Step 10 update container settings Double click on the BUS1001006 container, go to the properties tab and tick the Import checkbox

Step 11 Time to test First check your workflow model look similar to this

The click on the test button to test your workflow, first time you do this you will be asked for an Abbr. and Name. Just enter what you want here and press ok. Next it will ask for package and transport details, simply fill in as usual.

Step 12 Executing the workflow Double Click on the BUS1001006 entry and you will be presented with an input field at below. This is the import parameter you turned on in the container properties. Simply use the input help for the field and enter a material number.

Now when you press the execute button the SAP display material transaction should be displayed for selected material.

Add SAP Workflow event trigger

Once you have created a basic workflow it is time to add an event trigger to it. This means that when your specific event is triggered it will call your workflow. Step 1 Assign event receiver to a basic workflow Within SWDD go to basic details (hat icon) of your workflow and select the Start Events tab. Within here insert the category and type of your business object along with the event. In the example I am going to use event CREATED of business object BUS1001006.

Step 2 Setup bindings Now press the binding button

On the following screen press the Generate Automatic binding button

Step 3 Activate start event Now press the activate icon. The third button is for start conditions so you can add further restrictions on when the workflow starts.

Step 4 Activate workflow Now return to main workflow screen and activate it. This should be be setup and if workflow is running correctly whenever the event you have assigned you workflow too is triggered it should in turn execute your workflow. Step 5 Test workflow Use transaction SWUE to simulate an event triggering to check if your wf is executed.

SAP Workflow - my first workflow

created by Vikas Gautam on Nov 26, 2012 10:19 AM, last modified by Vikas Gautam on Dec 5, 2012 7:38 AM
Version 2
inShare

Workflow
Workflow is a tool for the automation of the business process, consisting of sequence of steps, tasks or event. One similar example to workflow is the automated lines in the manufacturing industry with station points or loading points. You can arrange and manage the dependency of tasks. Users can be sent notification for the task waiting in the SAP inbox for approval or action. Users can be informed of milestones in the process.

By automating the process, you free the users from having to know what to do when. Work items are sent to the participants notifying them of what they have to do, and a single click on the notification calls the correct transaction and navigates to the relevant screen.
WebFlow is the internet functionality of SAP Business Workflow.

Components:
Organizational Plan: to manage the hierarchy of reporting and message flow Workflow Builder: To generate the Workflow. The Workflow Builder provides a graphical view of the workflow definition. Events Business Workplace: SAP Inbox Role Resolution Components - Organizational Unit (a functional unit in your enterprise) - Position (Represents a post) - Job (classifications of functions in an enterprise) Organizational Plan Standard Task - Staff Assignments/Assignment of User-ids - Task (A description of an activity) - Overview Workflow Builder - Step types

- Tasks - Messages - Triggering Events Events - Terminating Events

Example:
- The scenario starts when an employee fills out a request for leave. - The filled-out form is then automatically sent to that employees supervisor. - If the supervisor rejects the application, the employee is informed and asked to decide whether he/she wants to re-submit the application or withdraw it completely. - If the employee decides to revise the application, the form is forwarded to his/her inbox for re-submit. - If the supervisor approves the request, the employee is informed and the workflow can end.

Steps:
1. Define Organization Plan (T-code PPOCE) 2. Create Workflow template: (T-code PFTC_INS) to create a basic template of workflow, (T-code SWDD) to build the workflow in the workflow builder 3. Define 1st task (T-code PFTC_INS) (Create notification of absence) 4. Add activity > first task in the workflow 5. 1st Test in SAP Inbox (T-code SBWP) 6. Define 2nd task (Check notification of absence) 7. Add activity > second task in workflow 8. 2nd Test 9. Integrate User Decision for Re-submit 10. 3rd Test 11. Define 3rd task (Revise notification of absence) 12. Add activity > third task to the workflow 13. Add 4th Customer Task (Send Notification for approval of leave)

Steps:

Step1: Define Organization Plan or Orgn. Unit (Tcode PPOCE)

Step 2:a: Create Workflow Template (T-code PFTC_INS)

Using Tcode PFTC_INS you can create workflow template and tasks also. This take you to the Task: Maintain. In the Task type field, choose the Workflow template for Workflow Template.

For Creating tasks: Choose Standard Task in the Task type field. Step2:b: View the workflow in T-code SWDD (Workflow Builder)

In the middle we have overview graphic/flow-chart. And on the right side on the bottom we have various small buttons/icons called step types. This we can drag and drop and insert into our worflow. We will be using the first step type which is like the of Absence. play button called activity for our Step 3: Create Notification

Step3: Define 1st task (Create notification of absence) Go to the T-code PFTC_INS : Tasks: Maintain Choose Standard Task in the Task type field. Give the following values and Save the task. On saving it will give a code Id: like 99500654 Name: Form_created Abbr: create_form Work Item Text: vik_notif_absence-create Object Type: FORMABSENC Method: CREATE Checkbox Synchronous object method, Object method with dialog checked. Step 4: Add activity > first task in workflow

Add the Step: Activity to your workflow.

in place of undefined step.

We have created Task TS99500654 separately using PFTC_INS.

Note the checkbox Advance with Immediate dialog. This means that the work item of the workflow is made available for processing immediately. The user who starts the workflow is also one of the recipients of this first work item. This is the case here because you entered the container element _WF_Initiator as the agent in the step definition. Note the Binding button. The binding _WI_ObjectId -> &ABSENCEFORM& has been automatically defined here by the system. This binding ensures that the reference to the notification of absence created is not only known in this task, but also in the workflow.
Now the Workflow Builder screen looks like

Step 5: 1st Test in SAP Inbox (T-code SBWP) When the workflow runs it creates work items which are like e-mails in the SAP Inbox. When it is executed it calls the respective task or transaction screen with the correct data. Execute your workflow: The notification of absence form is displayed.

Do not make any entries and do Not Save. Instead, choose Cancel. You have now started the workflow but canceled the processing of its first step.

Your workflow inbox now contains one work item for processing. This is the work item for creating a notification of absence, the processing of which you canceled previously. You have to select your work item with the subject as the work item text you have given. Select the work item, and choose execute (F8). You return to the Create notification of absence screen where the notification of absence form is displayed. Fill out the form and choose Save. The work item disappears from your workflow inbox.

Step 6: Define 2nd Customer task (Check notification of absence) This form formabsenc-create you created before will now be sent to supervisor for approval using the object formabsenc-approve object. Create another task using PFTC_INS:

Note the checkbox Confirm end of processing. Step 7: Add activity > second task in worflow Include Task: Check Notification of Absence in the Workflow. We have Task code as TS99500545. Check the binding properties

We need to create the Approver variable in the workflow container. (left side bottom, you will see a menu option Workflow container <double click to create>)
Make the following entries for object &Approver&: Element: Approver, Name: Approver, Description:Approver of

the absence request, Reference table: WFSYST, Reference field: AGENT. and use the object &absenceform& already there. For Agents Choose Position. Select your position by the name you have created in the organization. You can note down the id of your position from your organization (Tcode PPOCE) as S50001707. (Dont provide S in the text field).

We can also implement deadline in activities using Latest end, Requested Start, Latest start, Requested end. For e.g. If the superior has not made the decision about the leave request, the requester should be notified. Once the deadline (for e.g. latest end) passes, a work item for missed deadlines appears in your Business Workplace notifying you of the missed deadline.

Now, You will see that two branches are now inserted in your workflow definition for the two marked outcomes Approved and Rejected.
Step 8: 2nd Test Choose execute the workflow. You go to the screen Create Notification of Absence.

When the workflow is started, the work item for creating the notification of absence is provided to you directly for processing. This is because of advancing with immediate dialog. You were introduced to this in the first test. Fill out the form and choose Save. You now go to the screen of Business Workplace > Inbox through the user-id of superior/supervisor (head). The work items for you to process are displayed with their work item texts and certain other attributes.
Select your work item for checking the notification of absence and Choose execute.

Either reject or approve the request. Notice the two buttons Approve and Reject.

Step 9: Integrate User Decision for Re-submit

You can see that check Notification has two branches Approved, Rejected. We will be adding a user decision to the outcome Rejected. With the user decision, the requester can decide to revise and resubmit the leave request if the head of department/supervisor rejects it. Add the step type : User decision to the workflow.

Now your workflow looks like

Step 10: Third Test

Again execute your workflow. Fill out the Form and Save it. The work item will disappear from your inbox. As a superior: Reject the application.

If the request is not approved, the next step in the workflow definition is the user decision. The requester (&WF_INITIATOR&) was entered as the agent for the step. The decision is therefore offered to you again as the requester. There will be two options: Revise request or Withdraw request. If you choose Revise request, that should take you to the re-submit form. That is our next step.
Step 11: Define 3rd Customer task (Revise notification of absence) and add to undefined step at outcome - Revise after the user decision.

Use FORMABSENC-UPDATE as object. In the binding give _WI_Object_ID <= &ABSENCEFORM& In the Agents > expression give &_WF_INITIATOR& in the field.
Step 13: Add 4th Customer Task (Send Notification)

You have created a complete workflow template with which a notification of absence can be created, approved and revised. Now you will insert a step in the workflow definition that sends a notification to the requester after the request has been approved.
Choose Step "Send mail". Drag it to the Undefined Step after the outcome approved of the step Check notification of absence. Choose Recipient type Organizational object, Choose Agents > Expression Choose &_WF_INITIATOR&. Enter the subject < Leave Approved >. Enter the mail text < Dear Colleague, your leave was approved. > Choose Enter. You will be asked for the name and abbreviation of a task. Fill up the fields. Other features that can be used in this example: Integrate Step: Until loop to the workflow, Adding Container Operations which sets the value of flag, Modify Customer Tasks (Confirm end of processing), Implement deadlines in activities. Other types of step types which can be used in the workflow are Activity, Process Control, Condition, User decision, Document from template, Container operation, Event creator, Multiple condition, Fork, Undefined step, Loop (Until), Wait step, Loop(While).

Trigger workflow upon Status Change

Readers! Today I will show you how to trigger a workflow,upon a specific System Status.e.g PM module Notification IW21 status.

Our case is built on PM Notification system Status (OSNO) (outstanding)but can be made on any other too. We want to trigger the workflow and send mail to relevant person when ever the system status is OSNO Go to SWDD. Create a new workflow and save it under your package

 Custom BO / event will be used because BUS2080 Business Object does not have our required Event.So we first create a new BO which is a subtype of BUS2080 thru delegation concept. Thru SWO1 tcode ,we have made a new BO ZBUS2080 which inherits all Attributes and methods of BUS2080.In this custom BO,We have added a new event OSNO

Click on the Basics Data button or press Ctrl-f8 and enter the work flow starting event.

Click on agent assignment button and assign task as General Task. Add a mail step.

Go to BSVW (Status Management) tcode which is used for event linkage

Click on Customer Settings. Add a new entry as shown in figure.We will use QMI Status OT.It will vary depending on Module/requirement.

Now test your workflow ,it will trigger whenever the Notification System status is OSNO

Hope this tutorial is helpful to you.

Operation of the Binding Editor

Use
You are using the binding editor to define binding between two containers.

Features
The binding editor consists of two screen areas. The top half of the screen displays the source container on the left hand side and the target container on the right hand side. It also contains fields that can be selected. This screen area is only displayed in the change mode if you have selected the Drag&Drop indicator using (Personal Settings). You can for instance use the context menu for a container element to choose Select Compatible Elements. Elements in different containers that are compatible for assignment are highlighted in a different color. The binding definitions that you can process are displayed in the lower screen area:

Binding definition from source container to target container (binding direction ) The binding is executed at runtime before the associated action. You should only define one binding to the container elements of the target container for which the Import indicator is set. Binding definition from target container to source container (binding direction ) The binding is executed at runtime after the associated action. This binding is only available if the action can produce results that can be entered in the source container. You should only define one binding of container elements in the target container for which the Export indicator is set.

Binding Definition
A binding definition consists of one or more binding lines (binding instructions). A binding line consists of the following elements. Expression for the binding source Symbol for the binding instruction Symbol for the binding direction Expression for the binding target

Binding lines are executed in the binding editor in the order specified. If a container element is used again in a subsequent binding line as a target element, the subsequent binding line overwrites the result of the previous line.

Binding Instruction
The following types of binding instruction are available: Expression Expression: Source and target are one expression respectively e. g. &Form.Issuer& &_WF_INITIATOR&

Container Container: for transformation in which several elements in the source container are required simultaneously (e.g. data accumulation) or several elements in the target container are selected simultaneously You can select both types of instruction any number of times in any order. The following table shows the pre-defined binding instructions. By implementing pre-defined interfaces, you can program your own operators for both types of binding instruction (see also: Programmed Binding).

Binding Instruction Delete ( Assign ( ) )

Type Expression Expression Expression Expression

Description Deletes the content of the target expression. Assigns the content of the source expression to the target expression. Existing contents of the target expression are overwritten. Accesses the XSLT program for the source expression and assigns the result of the transformation to the target expression. You can define and select your own XSLT programs. The full range of CALL TRANSFORMATION is supported (see also: SAP XSLT processor - Reference). The transformation ID that you can use to perform format conversions is made available as standard.

XSL Transformation ( )

Expression Expression

Append to Tables ( Add to ( ) )

Expression Expression Expression Expression

Appends the content of the source expression to the multiline container element of the target expression. Adds the value of the source expression to the target expression (example of a programmed binding that has been implemented: CL_SWF_BND_TRANS_ADD_TO). Subtracts the value of the source expression from the target expression (example of a programmed binding that has been implemented: CL_SWF_BND_TRANS_SUBTRACT_FROM). Overwrites elements with the same name in the target container with elements from the source container.

Subtract from ( )

Expression Expression

Transfer all Elements (Except System) ( )

Container Container

Programmed Binding (BOR Container) ( )

Container Container

Executes a function module that uses the BOR container, see also Programmed Binding

Programmed Binding (Container IF) ( )

Container Container

Executes a function module that uses the container interface, see also Programmed Binding

Options for Binding Instructions

The following table shows the options that you can select according to the binding instruction involved:

Option Handle error as a warning

Description Suitable for optional binding instructions: If an error occurs, the workflow does not terminate but displays a warning. Warnings are only displayed in the workflow log if you have selected the No logging restriction entry in the version-dependent basic workflow data ( ) on the Control tab page under Performance Optimization. However, this logging level setting can impair performance. Only overwrites the target value if a new source value is available. If the source element still contains the initial value, the target value remains unchanged. Only overwrites the target value if a source value is available. If the source element is blank, the target value remains unchanged. Only transfers the source value to the target element if the target element does not have a value. If the target element already has a value, this remains unchanged. Only useful for structures: Overwrites sub-components with the same name in the target structure using components in the source structure. If the source container contains elements that are not available in the target container, these elements are created in the target container.

No action for initial source value No action for blank source value Only overwrite blank values: For structures: Assign sub-components with the same name Create elements that do not exist in the target container

Conventions for Expressions

Target expressions may not refer to attributes for a BOR object. A target expression cannot contain a method call. If the target expression references a structure, the source expression must also reference a structure.

If the source expression references a multiline container element, but the target expression references a single-line container element, the first row is transferred. Additional conventions for expressions are described under Expressions: Functional Methods and Access to Multiline Table Elements.

Dynamic Parallel Processing

During binding from a workflow to a task container, a multiline source element can be processed dynamically in parallel (see also: Table-Controlled Dynamic Parallel Processing). In the activity that is used for the dynamic, parallel processing, you must select the Multiline container element indicator on the Other tab page for the multiline element of the workflow container. You indicate that the multiline source element in assigned to a single-line target element line-by-line in the binding editor. To do this, specify the source expression as follows: &<multiline_element>()&

Activities
1. To define your personal settings for use of the binding editor, choose Personal Settings ( ). You can define the following: Operation of the binding editor using Drag&Drop Immediate syntax check of data lines for each entry 2. Define the source and target expression and the binding instruction for each binding line. You can specify the source and target expression using one of the following methods: Drag&Drop If you have defined operation using Drag&Drop, you can enter a container element from the top half of the screen in the required cell in the binding line. Input help If you use the input help in an empty field of a binding row and an entry in another field of the binding row has already been made, the system highlights container elements with a suitable data type in color. Direct entry You can enter constants directly. To define the binding instruction, click on the icon for the binding instruction, and select the binding instruction and the options required. 3. Create new binding lines as required. If you have defined operation using Drag&Drop, you can enter a container element from a container in a container element for a different container to create a binding line. 4. Assign binding lines in the sequence in which they are to be executed.

Assignment Rules for Binding Definitions

Basically, you cannot use an attribute of a BOR object type as a target of a binding row.

Identity and compatibility of data types Identical data types

A binding definition is possible if the two container elements or expressions have identical data types. The data type is specified using the data type reference of the relevant container element.

Compatible data types

A binding definition is also possible if the two container elements or expressions have compatible data types. Data types expressed by field references are compatible under the following circumstances: No field is specified for the target element of the assignment, but it is an ABAP Dictionary reference.

Data types expressed by an object reference are compatible under the following circumstances: The source element references an object type that is a subtype of the object type referenced by the target element (meaning that subtype supertype is allowed) No object type is specified for the target element of the assignment, but it is an object type reference.

A binding definition from the element _WI_Object_ID (with a data type reference to object type FORMABSENC) in the task container to the element UntypedObject (with an unspecified data type reference to an object type) in the workflow container is allowed. However, a binding definition from an unspecified element to an element with a specified data type reference is not allowed.

Binding Definitions from Task Container

Use
You can define bindings from the task container to the following containers:
Workflow container Rule container Method container

Features
Binding definition to workflow container
The binding is applied after execution of the work item. The binding can be defined in step type definitions that refer to a task. It is necessary if you require information for the workflow, which is available after execution of the underlying object method.

Special information on object reference

If an object is created (for example, with the method Create) or established (for example, with the method Find) in task processing, you must define the binding from the element _WI_Object_ID in the task container to the element in the workflow container, which can contain the object reference. The

information is only available in the workflow, and therefore for the subsequent steps, if you have defined this binding.

If the workflow container contains an element which is defined with a data type reference to the same object type that is created in the referenced task, this binding definition is proposed automatically when an activity is defined. If no element with an appropriate data type reference is available in the workflow container, a suitable element is added to the workflow container and the binding entered.

Actual agent: Element _WI_Actual_Agent in the task container

If you want to transfer the actual agent of a work item (available under the element ID _WI_Actual_Agent in the task container) to the workflow container for further use, you define an appropriate element in the workflow container to contain this information. You create this element with a reference to the ABAP Dictionary field WFSYST-AGENT.

The binding from the step container back to the Workflow container is only executed when a method has been successfully executed. The binding is not executed in the following situations:

Processing of the work item is denied (for example, from the Business Workplace) An administrator or control step sets the work item to obsolete A deadline becomes active and steps in a modeled outcome are executed The "complete work item" condition for the step is true and the step is completed

without executing the method To nevertheless determine the agent in the instances above, use the container element _PREDECESSOR_WI to access the predecessor work item. For example, the expression&_PREDECESSOR_WI.WORKITEMID& gets the work item ID of the predecessor work item. For a detailed description of how to use the _PREDECESSOR_WI container element, see SAP Note 903692.

Result of the object method: Element _WI_Result of the task container

The result of the object method is available under the element ID result (_WI_Result) in the task container. You must define an appropriate element in the workflow container, if you want to transfer the result into the workflow container. When defining the container element, use the same data type reference that the element _WI_Result has in the task container.

You require the result of this activity in a subsequent step of the type loop (UNTIL) in order to formulate the loop condition.

Binding definition to rule container

You define this binding in the definition of a task if you have entered rules for one or more recipient types on the tab page Default rules.

You must add the elements required to resolve the rule to the task container in order to define a binding between these new elements and the appropriate elements of the rule container.

Note that you must create a binding from the workflow container to the task container in the step definition, via which these "new" container elements are given their values. Depending on the type of the rule for agent determination, you need to transfer the following data: Rule type Responsibilities Organizational data Function module What is transferred in the binding? Container elements that are used for the responsibility check Attribute of the business object that refers to the organizational object

Container elements that are used as import parameters for the function m

Binding definition to method container

The task container is completely copied to the method container at runtime as standard. You can define this binding definition when defining a task. SAP only recommends that you do this if you do not explicitly want to provide the import parameter of the method with data or if you define your own binding from the method to the task container.

If you define the binding of the task to the method container, you also have to define the binding from the method to the task container. The content of the container is only automatically copied to the relevant target container if you do not define either of the two bindings.

Catering for the container elements _WI_Object_ID

The container element _WI_Object_ID in the task container is not incorporated into the binding definition to the method container. At runtime, the workflow system ensures that the object reference from the element_WI_Object_ID is available in the key fields in the program of the object type.

Activities
For more information, see Operation of the Binding Editor.

Binding from Task to Custom Method

My workflow is largely based on template WS2000040 - Approve Trip. The standard is a two step approval process with 2 decision tasks sent out 1) Check Trip Facts 2) Approve Trip. I've copied and changed the flow to have a slightly different approval process again 2 decision tasks are sent out. 1) Approve Trip 2) Settle Trip (Custom code)

The workflow is based on business object BUS2089. I've created a subtype of BUS2089 and named it ZBUS2089, and created a method ZEmployeeTrip.ZTripSettle which calls a function module (FM) to carry out the settle process (submit's a SAP standard program RPTTEC00 (TCODE PREC)). The FM has the following parameters EMPLOYEENUMBER LIKE BAPIEMPL-PERNR Optional Passes Value Personnel Number TRIPNUMBER LIKE BAPITRVXXX-TRIP Optional Passes Value Trip number The code works correctly stand alone. I've tried to implement it in a similar manner to BUS2089-APPROVE.

My problem is that when called from the workflow the parameters for my method are always blank and the container of the method is also blank. This is a view of the flow (bottom up). 14:23:11 B STARTED TS90100002 Settle Trip 14:22:59 W COMPLETED TS00008267 Settle Trip of Test Test rr 04.01.2003 1000004552 14:22:58 B COMPLETED TS20000130 Set trip 1000004552 status to approved 14:22:46 W COMPLETED TS20000131 Approve trip of Test Test/rr/04.01.2003/1000004552 14:22:45 F STARTED WS90100002 Custom Employee Expenses The informations I need is stored in element TRIP. The fields that are key and the ones that I need passed through into my method are employeenumber like pskey-pernr, tripnumber like bapitrip-tripno, These fields are sucessfully passed from the workflow container into my role to determine the agent of task TS20000131 and subsequently task TS00008267. I'm pretty sure my problems relate to the binding between the task container and the method container. TS00008267 <-> ZBUS2089-ZTRIPSETTLE. And possibly my binding throughout the workflow template. I'm getting several binding errors that raise the following questions:

1) When I attempt to activate the workflow template I'm told some values are not used or some values are for read purposes only. I can see these values in my workflow container and when attempting to delete them from the workflow container I get the message: 'Inherited elements may not be deleted'. 2) As I mentioned I'm trying to implement this like BUS2089-APPROVE is implemented by SAP. When I click on my object binding within task TS90100002 I always see the key parameters to my function module called by my method ZBUS2089-ZTRIPSETTLE and I am unable to change this. However when I look at BUS2089-APPROVE it does not work like that and in the method code it takes it's values from object-key-employeenumber and object-key-tripnumber. I've tried using this method in my code and also using swc_get_element ac_container 'EmployeeTrip' z_tripno. swc_get_element ac_container 'EmployeeNumber' z_person but in both cases I have no values populated.

First thing to check is see if your method works on its own. you can do this from the swo1 transaction. click test, instantiate the object and execute the method. if it works correctly, then you will have to straighten out the binding betn the task and the method. While testing your method thru swo1, you can put a hard break-point in your method code and execute the method that way you can check if the values are being read by the method.

When I switch on container debugging I'm getting binding errors and my target container (the method) is empty. I realise there are binding problems but I don't know how to repair them. Primarily because of the error messages (re: original posting) I receive during my attempts to repair the binding.

It's definitely a binding problem - under no circumstances should the global data field 'object' be empty in your method code. In your workflow container, you should have an instantiated business object ('trip'?), which contains the fields you're interested in.

What you need to do is bind this element from the workflow container to that of your standard task, which you do at the activity step level in the workflow builder. The container element 'trip' should be bound to the task element '_WI_OBJECT_ID'. Once that's in place, this should feed down into your method automatically, but by all means check this at PFTC standard task level. When you've done this correctly, you can access your element NOT through the workflow container using 'SWC_GET_ELEMENT', but through the business object key. i.e. object-key-pernr etc... Finally, make sure you're delegated your subtype 'ZBUS2089' system-wide to BUS2089 using SWO6 - you shouldn't be creating a standard task based on ZBUS2089, which can cause problems too. The standard task should be based on object type BUS2089, method ZTRIPSETTLE.

The business object is &TRIP& and is instantiated to begin with i.e. the value get's passed to the first task. I believe also to the second task as I'm writing those values out in the workitem line item text.

Resolution 1) 'The container element 'trip' should be bound to the task element '_WI_OBJECT_ID'.' 2) Created standard task based on BUS2089.

Definition of Binding
At definition time you create binding definitions for the workflow. This involves specifying the assignment rules for how data is exchanged between two containers. At runtime these binding definitions are executed making workflow execution possible.

Note
If a target container from a source container element is to be filled with a binding at runtime and if the source container element is initial or unavailable, then determine in the options of the binding instruction whether the content of the target container element is changed by the binding.

You can also allocate values to container elements using initial value assignment at definition time.

Example
Application Within the transaction for creating an accounting document (object type AccountingDocument), an event is generated created), which indicates that a document has been successfully created. This event is to be thetriggering event of a workflow. Event The event container is passed with this event. This container always contains an element _Evt_Object with a reference to the object created. Workflow container In the container of the workflow that is to be started by the event created of the object typeAccountingDocument, you have created a mandatory import element (under the ID AccountingDocumentfor example) with a data type reference to the object type AccountingDocument. The element can therefore hold the reference to the object created (type AccountingDocument) at runtime. Binding to workflow The event parameter (= element in event container) _Evt_Object can be passed in a binding to the workflow container of the workflow that is to be started in response to the event. You define the following binding for this: _Evt_Object (event container) AccountingDocument (workflow container)

Features
The graphic below illustrates which bindings can be defined.

Binding Definition from Task Container

You define the bindings from the task container in the following two places:

In the definition of a task:

There are binding definitions to the: Method container (for import parameters of method) Rule container (for definition of default rules)

In the step definition in the Workflow Builder

The binding definition to the workflow container.

Binding Definitions to Workflow Container

You define the bindings from the workflow container within the Workflow Builder. There are binding definitions to the: Task container (activity, user decision, document from template, send mail, form step) Event container (event creator) Rule container (for definition of responsible agents and recipients)

Binding Definition from Method Container

You define the binding from the method container to the task container (for export parameters of the method with synchronous methods) during definition of a task.

Binding Definition from the Rule Container

You make the binding definition from the rule container to the workflow container during the definition of a step.

Binding Definition from Event Container

You define the bindings from the event container in the following three places: In the definition of a task for the binding definition to the task container (for triggering or terminating events of the task). In the Workflow Builder in the basic data of a workflow for the binding definition to the workflow container (for triggering events of the workflow). In the Workflow Builder in the definition of a wait step for the binding definition to the workflow container.

Note
The system makes proposals automatically for the binding definition between the workflow container and the task container. You can change these proposals. For information, see Rule-Based Proposal for Binding Definitions.

Activities
You define the bindings in the binding editor, which is always called via a definition tool. This cannot be done separately.

SWu3 Workflow configuration