Over the last few years, workflow has been undergoing a change so gradual you may not have even noticed it in your everyday work creating new automated processes, building enhancements to current processes, or tweaking existing workflows to adapt to changing business environments. But with the advent of SAP NetWeaver and the Web, tasks and workflow have undergone dramatic changes for the better. This article points you to some substantial changes that have happened under our noses in the last few years, and how you can take advantage of them to simplify and modernize the user experience without changing the underlying enterprise systems or workflow processes.
A Key Workflow Turning Point: Tasks Emerge
In the single-application world, where actions can be modeled as synchronous chains, modeling various processes and tasks to stay synchronized with user interaction is simple. So there was never any need to expand the traditional workflow model. This was the client-server world, where SAP R/3 and similar programming models were the norm.
Then, we experienced a paradigm shift. Enter the Web. Enter distributed systems. With these changes and the onset of Web services emerged new challenges — such as creating a Web UI for services provided outside the system — and a new workflow-engineering paradigm was required. Enter the Universal Worklist in the portal.1 Enter the concept of the task as an entity in its own right; although the task is not quite independent of the processes that use it, it has certainly become independent of the software driving the processes. The dramatic change in workflow today centers around this new conceptualization of tasks, and the possibility that a task deployed in the workflow can be treated as a separate entity, perhaps even with a separate software engine driving it.
By considering the task as a separate entity, we are freed from the tight integration between tasks (typically rendered by forms) and the processes that trigger these tasks. This allows flexibility in the way tasks are assigned to users, perhaps via an organizational management structure as a set of attributes of a particular job, or in relationship to a process as a set of roles assigned to steps in a process. For example, finding the user qualified to release a budget sheet involves locating the person through the organizational structure (which takes Sarbanes-Oxley requirements and other prerequisites into account), whereas finding a user qualified to release a purchase requisition will likely be derived from customizing tables related to an approval role used in the process.
No matter how tasks are assigned, the workflow capabilities in SAP NetWeaver do a great job of facilitating either approach and ensuring that the tasks themselves are consistent.
SAP and IBM: Extending the Business Process Standard to Include Users
SAP and IBM have been working together on a newextension to the Web Services Business Process Execution Language (WS-BPEL) specification, which is a language primarily used for designing processes that orchestrate activities or different components exposed as Web services. This extension, known as BPEL4People, addresses the following topics about how people can be introduced intothe process description:
Enabling users to perform activities within the business process instead of by launching Web services
The different roles users play when interacting with business processes, such as tracking workflow progress
The interaction between manually performed (human) tasks and the business process
This new user-focused extension describes how Web services can be orchestrated together with user activities so that the sequence in which services are executed is clearly defined. In other words, rather than simply describing the functions that are to be performed using Web services, a complete process is described, including all activities and instances where people are involved.
The concept of a user-centric process is nothing new. In fact, it is what most people think workflow is all about. So it is no surprise that attempts to define protocols and schemas to incorporate users into processes already exist. What is new in BPEL4People, however, is how it exposes the symmetry between orchestrating automated Web services and human activities, and where these symmetries break down — for example, take escalation management and look at a single user and the many different roles and identities this one user takes in a heterogeneous software landscape.
The new workflow model presented in this article is aligned with the BPEL4People extension.
Exploring the New Paradigm
The challenge now becomes: How can you take advantage of the benefits of the task-based paradigm and apply this new paradigm to your own workflow? Given the emergence of tasks as a separate entity, here's a five-step approach that SAP now recommends for modeling workflows:
1. A process defines a sequence of tasks and the global data accessed and changed by these tasks. Local data required by the tasks does not need to be visible to the process.
2. When the workflow is executed, it generates work items that are picked up by the Universal Worklist and presented to the user (see Figure 1), who can then perform the necessary task.
|Web Dynpro User Interface for a task, Launched from an SAP R/3 4.6C Workflow
3. When a user selects a work item, the Universal Worklist triggers the task. At this point, the workflow is no longer required; it is completely dormant, and the Universal Worklist is now the driving force.
4. The task instance interrogates the process instance to find the context details (data). This is new, revolutionary, and worth digesting for a moment: The task is pulling data from the process rather than being pushed to it, as was the case in the past. The task is now the driving force.
5. Finally, when the task completes, it pushes the information back to the workflow, and the workflow removes the work item from the Universal Worklist. The workflow or process is in the driver's seat again.
Only recently have we realized the significance of steps three and four. The Universal Worklist is responsible for instantiating the task, and the task has a life of its own. This model makes the whole workflow much more portable and independent of the user interface technology that is used to render it (a Windows, Web, or Java UI, for example).
Enabling Tasks in Practice
So what does a workflow developer have to do to instantiate this new task-based workflow model? The developer has to make a few minor adjustments to the code so that when the task is instantiated by the Universal Worklist or any other task client, it knows:
- Where to find the workflow (the RFC destination, for example)
- Which process step it relates to (such as the work item ID)
- That it has a mechanism for transferring results back to the underlying process
In other words, the task must perform the following steps once it is instantiated:
1. Query the workflow container for the available data, via a WAPI function call 2 to the workflow engine
2. Render a user interface based on this data, such as .NET or a Web Dynpro application
3. Return the data or a fault back to the process, via another WAPI call to the workflow engine
Following this paradigm for developing workflows and the tasks that are called offers several immediate advantages. The user interface can be developed on a different software system from the one that the workflow is running on. Since the Universal Worklist is already independent — a single list of work items presents different workflow systems of different release levels (such as SAP R/3 or mySAP CRM) — users will profit from this distributed arrangement. It enables you, for example, to replace a task modeled in an aging Internet Transaction Server (ITS) or Windows GUI transaction with an up-to-date Web Dynpro application, perhaps using interactive forms based on Adobe software to render the data to the user. The workflow does not have to be changed at all, and can continue to run in the original, perhaps outdated, system.
Since so much of workflow development is planning and synchronizing process flow, this is great news: By keeping the workflow definition intact, you can improve the user interface without touching the backend process.
A Refreshing Look at Workflow ROI
Your workflow process may already work well, and as the popular saying goes, "If it isn't broke, don't fix it." If your process has been continuously tweaked for improved efficiency, and it accurately reflects changes in your surrounding business environment, you may just want to give this process a new coat of paint by improving the user interface without adjusting the foundations. The administration remains the same, the process efficiency reporting remains the same (watch out for the latest PI Basis Plug-In3 to enable easier SAP NetWeaver Business Intelligence reporting on existing processes), and the monitoring remains the same. This minimizes the "I" in return on investment (ROI) while giving the process a completely new appearance — not just cosmetically, but also in terms of additional business context that can now be presented with the task.
In fact, if you simply want an existing workflow task to execute from the Universal Worklist, there's no need for any new investment at all.4 Even if the task was originally developed using SAP GUI for Windows, it will execute in the browser using SAP GUI for HTML, instead. What we are investing in here is a new, improved user interface to existing workflow tasks, using UI technology that may not be available in the system where the workflow executes. To take advantage of this added return on investment, the new ROI recipe is:
- Remodel the task by writing new code to provide the task's user interface. Choose an up-to-date development environment in which to do this, such as a recent release of SAP Web Application Server. Choose the user interface that you think your users are most comfortable in: Adobe forms (using interactive forms based on Adobe software), Java Web Dynpro, Enterprise Service Interface (ESI) user interface patterns, you name it.
- Since the task will be passed the work item ID as a parameter, you must add the WAPI function call to collect the work item container contents. Because this is usually XML, there are no limitations as to what type of data (lists, strings, structures) is possible. You must also add code to update the work item container and return a result to the workflow (see Figure 2). Messaging between systems or triggering events within the system are also valid ways of returning results and closing the work items.
method ONACTIONAPPROVE .
data: wi_id type sww_wiid,
workflowrawdata type ref to IF_WD_CONTEXT_NODE,
l_cont type standard table of swr_cont,
l_cont_line type swr_cont,
rc type sy-subrc.
workflowrawdata = wd_context->get_child_node( 'WORKFLOWRAWDATA' ).
CALL METHOD WORKFLOWRAWDATA->GET_ATTRIBUTE
NAME = 'WI_ID'
VALUE = wi_id .
* Set approved flag.
l_cont_line-element = 'Approved'.
l_cont_line-value = 'X'.
append l_cont_line to l_cont.
* Write the approved flag back to the workflow.
CALL FUNCTION 'SAP_WAPI_WRITE_CONTAINER'
WORKITEM_ID = WI_ID
RETURN_CODE = rc
SIMPLE_CONTAINER = l_cont.
* Set the workitem completed so that the workflow continues.
CALL FUNCTION 'SAP_WAPI_WORKITEM_COMPLETE'
WORKITEM_ID = wi_id.
|Code Sample Showing How a Work Item is Completed
- Reconfigure the Universal Worklist to call this task using the appropriate launch handler (Java Web Dynpro,for example). Note that even hereyou don't need to adapt the workflow definition in any way.
You may also wish to remove the task from table SWFVISU 5 so that there is no danger of the configuration being overwritten if and when the workflow system is re-registered.
The Benefits of Central Task Management
In addition to the benefits we've already explored, there are even more advantages behind this new paradigm shift. So far we have just looked at the workflow tasks — tasks that are embedded in business processes. Let's also look at the benefits of handling tasks centrally, and the generic capabilities of tasks that can be presented in a simple, intuitive manner.
If we take into account other task variants, such as collaborative tasks or even alerts, we can see that general patterns apply to all tasks.6 For example:
- A task can be forwarded, irrespective of what software generated the task or from which component in the system landscape it was instantiated, even though different components may have different organizational models and different user groups
- Attachments can be added to the tasks
- We can monitor the progress of a task
- When someone goes on vacation or is ill, we can set up a substitution rule so that colleagues cover for him
Since these are all central task capabilities, dealing with them on the central Universal Worklist — as opposed to having users go to the relevant component that generated the task — is a result and benefit of the new task-based paradigm. From the user's point of view, one central task list is easy and brings numerous advantages. For example, users can prioritize tasks at a glance, save time by not having to redundantly log in to systems where no tasks are currently waiting, and work with a familiar and consistent user interface for accessing infrequent activities, such as setting up a substitute or uploading an attachment.
Thanks to the architecture of the SAP NetWeaver platform, and the ability to deploy this architecture in conjunction with previous releases of SAP software, customers can take advantage of a new task-based paradigm and spruce up existing processes according to this improved workflow standard. The shift to this task-based paradigm has been so steady and continuous that you may not have even noticed it progressing. But it has happened in such a way that SAP software already in production can make this shift without the inconvenience of a release upgrade, meaning that tasks generated by existing workflows in existing business systems are presented to users in a simplified and attractive way, continually taking advantage of the newest SAP NetWeaver development capabilities.
It's easy to get excited about the new capabilities that this task-based paradigm offers and the minimal effort it takes to get spectacular results. By revisiting workflow with a refreshed look at tasks, customers can enjoy enhanced productivity, improved maintainability, and increased user satisfaction.
For more information about the BPEL4People white paper, visit the SAP Developer Network (SDN) at www.sdn.sap.com --> SAP and IBM Join Forces to Extend WS-BPEL.
1 - For more information on the Universal Worklist, see my article "Implement a Central Inbox for One-Stop Access to Work Items from Any Business Process" in the October-December 2003 issue of SAP Insider (www.SAPinsider.com).
2 - WAPI stands for Workflow API. The WAPIs used are: SAP_WAPI_READ_CONTAINER, SAP_WAPI_WRITE_CONTAINER, and SAP_WAPI_SET_WORKITEM_COMPLETED.
3 - The PI Basis Plug-In is used to deliver BW Service API technology. Please visit http://service.sap.com/ r3-plug-in for more information.
4 - See SAP note 794439 to check current limitations.
5 - When a component is registered to the Universal Worklist, it generates a default XML configuration for each task that it finds in SWFVISU, including the invocation of the appropriate launch handler. This saves time (configuration is generated instead of being created manually), but here the goal is not simplification but beautification; manually creating a configuration that redirects elsewhere is a valid proposition.
6 - For more information on collaborative tasks, see my article "Collaboration Tasks Bring Structure to Chaos" in the April-June 2005 issue of SAP Insider (www.SAPinsider.com).
Alan Rickayzen has been with SAP since 1992 and in data processing since 1988. Since 1995, he has been performing development work as well as process technology consulting for various major US customers and, as a result, has amassed a good deal of technical knowledge in collaborative process technology. Alan Rickayzen is co-author of the book Practical Workflow for SAP, available at http://store.sapinsider.wispubs.com/products/H3057, and may be contacted at email@example.com.