Big Results With Little Effort

The shift to a task-based paradigm has been so steady and continuous that many SAP customers 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.

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, a paradigm shift came up. 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. 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 the Sarbanes-Oxley Act 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.

Exploring the new paradigm

The challenge now becomes: How can customers take advantage of the benefits of the task-based paradigm and apply this new paradigm to their 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, who can then perform the necessary task.
  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, the significance of steps three and four has been realized. 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

To instantiate this new task-based workflow model, a workflow 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) – and it knows 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 Workflow API function call 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 them, 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, customers can improve the user interface without touching the backend process.

A refreshing look at workflow ROI

Workflow processes may already work well. If a process has been continuously tweaked for improved efficiency, and it accurately reflects changes in the surrounding business environment, the enterprise 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, 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 customers 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 has to be invested 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, customers just have to remodel the task by writing new code to provide the task’s user interface. They choose an up-to-date development environment in which to do this, such as a recent release of SAP Web Application Server. Then they choose the user interface that they think their users are most comfortable in: Adobe forms (using interactive forms based on Adobe software), Java Web Dynpro, or Enterprise Service Interface (ESI) user interface patterns. Since the task will be passed the work item ID as a parameter, they 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. The customers must also add code to update the work item container and return a result to the workflow. Messaging between systems or triggering events within the system are also valid ways of returning results and closing the work items. Then they can start to reconfigure the Universal Worklist to call this task using the appropriate launch handler (Java Web Dynpro,for example). Note that even here, they don’t need to adapt the workflow definition in any way.

The benefits of central task management

In addition to the benefits already explored, there are even more advantages behind this new paradigm shift. There are more benefits of handling tasks centrally, and the generic capabilities of tasks that can be presented in a simple, intuitive manner. If other task variants, such as collaborative tasks or even alerts, are taken into account, it becomes obvious that general patterns apply to all tasks. 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. Users can monitor the progress of a task. When someone goes on vacation or is ill, an administrator 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. 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.

Source:SAP Insider

Alan Rickayzen
Alan Rickayzen