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.
 |
Figure
1 |
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
EXPORTING
NAME = 'WI_ID'
IMPORTING
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'
EXPORTING
WORKITEM_ID = WI_ID
IMPORTING
RETURN_CODE = rc
TABLES
SIMPLE_CONTAINER = l_cont.
* Set the workitem completed so that the workflow continues.
CALL FUNCTION 'SAP_WAPI_WORKITEM_COMPLETE'
EXPORTING
WORKITEM_ID = wi_id.
wd_This->Fire_Approve_Plg( ).
endmethod.
|
Figure
2 |
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.
Note!
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.
Summary
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
www.sap-press.com, and may be
contacted at alan.rickayzen@sap.com. |