Purpose of SAP Business workflow
This blog outlines the process of troubleshooting, when the workflow fails to start correctly. You can use the SAP Business workflow to define business processes that are not yet mapped in the R/3 system. These may include simple release or approval procedures or may even include a much more complex business process like creating a material master and the related coordination of the involved departments.
SAP workflow finds suitability in certain scenarios where work flows have to be executed repeatedly or in certain circumstances, where the business processes needs the involvement of a large number of agents in a specific sequence.
Another utility of SAP Business workflow is it helps you in responding to errors and exceptions in other existing business processes. You can commence a workflow when predefined events occur. For example, if specific errors were found during an automatic check, an event can be triggered.
Integration
SAP Business Workflow uses the existing transactions and functions of the R/3 system and does not alter the functions. You can integrate the existing functions of the R/3 system to create a new business process with SAP Business Workflow. The workflow system takes over the control of the business processes.
Troubleshooting when the workflow doesn’t start correctly
Now that you have got an overview of the purpose of SAP Business workflow and the integration aspects, the next step is to start a workflow. However, in certain instances, workflow may not start correctly and this blog basically addresses this aspect – troubleshooting when the workflow doesn’t start properly.
Here there are 2 scenarios:
- When the workflow does not start at all
- When the workflow starts twice
When the workflow does not start at all
This is the common scenario encountered by most of us. If the workflow does not start properly, it could be either of the cases – workflow not being triggered properly or the work flow definition is incomplete. As a first step, find out how the workflow should be started. Is it directly or via customizing a table or via an event? Transactions SWUD provides an intelligent diagnosis help to find out the right cause to know whether:
- The flow has been started
- The triggering event has be fired
- The flow is syntactically correct
- The users have been assigned all the tasks.
When the workflow starts twice
This is a unique scenario that is also commonly encountered at the time of starting the workflow. The most probable reason for a workflow to get started twice is the simultaneous triggering by two separate mechanisms. For instance, if the flow is being triggered by an event, ensure that this event is only firing once. You can check this out in two instances.
1. Firing once due to customization for change documents
2. Firing once due to customization of status changes.
Thus, transactions SWUD helps you to determine how many times the event gets fired. In case, if it is firing only once, ensure that the workflow is not additionally being started directly by a program or by customizing tables. Also check that the workflow is not customized to trigger on two separate events.
Sending e-mails from the workflow
You have a wizard in the workflow editor that lets you send straightforward mail from the workflow. The wizard generates a step, based on the business method SELFITEM SendTaskDescription. Under any circumstances, you cannot modify the business object SELFITEM and delegate. However, if you want to accomplish something more complex, the only way is the 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.
Varied mechanisms to access work items
If you are at an early stage of the project, you should take into the account the issue of how users would be notified offline and have access to the work items. Though this decision might not influence the definition of the workflows, however, there might be certain organizational issues involved, which you should consider at this early stage. ASAP provides a list of alternative methods; the most common being:
- Microsoft Outlook
- Lotus Notes
- mySAP.com Workplace
- SAP Business Workplace (formerly the universal inbox)
- Web Inbox
Without modifying your workflow, you can configure the email notification automatically. In order to ensure tighter integration into other mail programs, you can incorporate form functionality for the workflow steps that will benefit mostly from this.
When to use asynchronous tasks?
Asynchronous tasks are those tasks that terminate when a terminating event is received. Hence, this makes them useful for tasks, where you need to be absolutely sure that the user has accomplished what was intended. When the terminating condition is met, the event is usually triggered within the method itself.
Some of the cases, where implementation of asynchronous tasks are suitable are as follows:
- The user must make a change in the business object (Ex: status change).
- Since post-processing of the method takes place in the update task, it is necessary that the workflow does not resume until this pre-processing has been fully completed (Ex: creation of a business object).
- Feedback via the event is necessary to ensure that the workflow resumes automatically, since some users often execute this task directly from the menu without accessing the workflow system.
Ensuring robust flow
Ensure that your workflow definition will not stop or get confused when a user executes several tasks in one step. Avoid dictating the order of processing with your workflow definition, unless this is a mandatory aspect of the business work flow. Provide your users with greater flexibility to work on their own terms, but ensure that they work within the boundaries of the business framework. Check whether the workflow synchronizes properly with other events. For instance, if a purchase requisition is removed, the workflow should stop immediately and send notifications to all users involved in the process so far. Provide deadlines to check whether the process runs through on time and that a supervisor is informed when a delay occurs.
Role of documentation
Since the workflow is dynamic, you may need to change the business process at times. You need to have a robust documentation in place, which is written to ensure that any changes, which are made can be done easily without upsetting any aspects of the process.
There are different types of documentation you can maintain for different users to ensure that the standard operational workflow doesn’t break down:
Operational documentation
For an operational user, documentation can be made available online with a URL included in the work item description. As part of this documentation, it should contain help-line numbers and what to do tasks if you receive a work item for some other member (in case you have left the department).
Administrator documentation
Administrator documentation should include how to perform periodic health-checks, how to add a new user to the process (or even delete an existing user), what tasks need to be performed when a user is absent for a short period of time, contingency plans, if any and other related aspects.
Technical documentation
This is the most important documentation as it needs to include a complete catalogue of all workflows, tasks, business objects and roles used in the process. The most important component that needs to be documented are the events, which must be documented in the system, explaining how they get triggered (E.g. program xxx, status changes). The workflow documentation should explain how the workflow gets triggered (Ex: Event, program…..). Sub flows also should be labelled accordingly and synchronization issues should be documented with lot of care, so that changes can be made without posing a risk to the process.
mWorklist solution from Innovapptive leverages the SAP's business workflow!
Innovapptive developed an universal approvals solutions - mWorklist leveraging the SAP's business workflow to ensure a seamless approval mechanism on ioS, Android and Windows mobile. Using mWorklist, a user can a process a series of transactions involving timely approvals related to purchase orders, expense reports, time sheets, contracts, shopping carts and much more from the comfort of his/her mobile, anywhere, anytime. mWorklist lets the user to access the master and transactional data of the various modules (Inventory, HR, etc.) of the SAP server and pulls the transactions that needs approval to enable seamless processing of such requests.
This blog provided you an overview of how to troubleshoot in case the SAP business workflow doesn’t start properly, walking you through the two common scenarios: when the workflow doesn’t start at all and when the workflow starts twice. Finally, this blog dealt with the significance of documentation for various user groups to ensure seamless workflow implementation, apart from providing an overview of Innovapptive's mWorklist solution that leverages the SAP's business workflow to provide a seamless universal approval process.
If you would like a demo of Innovapptive's portfolio of Native or Web based mobile solutions, 
please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.
