WDA & ABAP Objects - Percent of WF'ers using them?

[Mikko Mäki-Rahkola]

Hi all,

interesting to hear other workflowers' experiences on ABAP OO and WDA
usage! I hope you (especially Sue, Mike and Ramki) however don't mind
me as a late joiner combining the two topics of ABAP OO for WF and WDA
for WF when sharing my experiences, since I've been accustomed to
using both of them simultaneously and I strongly believe that 1 + 1 =
3 in this case :)

ABAP OO for WF experiences:
We've now been using ABAP OO for WF in ~10-15 projects since 2007 and
I can pretty much agree on the use cases and comments already stated.
Our rule of thumb is similar to others', we are using ABAP OO for WF
in cases where new functionality is required. Such cases have included
e.g. request objects in need of object specific functionality (like
material requests, where the usage of ISR notification objects is not
sufficient), but also completely new objects which SAP doesn't support
at all in BOR (e.g. SAP HCM Enterprise Compensation Management). Cases
where not to go with ABAP OO and resort to existing BOR objects have
included e.g. event handling, simple workflows (like IDoc handling)
where the standard objects are sufficient and customer driven cases
where the usage of BOR objects have been a must.

In general, we are using BOR objects nowadays only where it's
necessary like event handling or where the ABAP OO
replacing/complementing functionality would require too big an effort
when compared to a standard BOR object. The main benefits we have
perceived of going ABAP OO instead of BOR come from a developer
perspective. People using ABAP OO in other development (see my
comments below) are quickly accustomed to using the WF class
interface, the class editor is familiar to them and there is no need
for a separate editor, there are less restrictions (anyone had a
requirement for more than one delegation/subclass?) and in general
there's a single development environment which can be utilised for
other development as well.

WDA for WF experiences:
WDA has been around in our projects since 2007-2008 after customers
started upgrading their systems to SAP ERP 6.0 (gladly no more WDJ
since then!) and most of the WDA solutions we've done have been
integrated to WF in one way or the other. Some have just started off a
workflow either through a custom or a standard event, some have been
been developed for work item processing (= approval views) and some
have been done for work item reporting. Since both WDA and WF work on
the ABAP runtime, they work beautifully together. Firing events with
ABAP OO for WF, processing work items and reporting on them are as
straightforward with WDA as with plain ABAP.

Currently our nr 1 choice for a new customer specific web user
interface sitting on top of any SAP Business Suite (ok CRM and SRM may
be different) is WDA as per SAP's Best Built Application guidelines.
As Mike P stated before, it has lots of benefits when compared to the
other alternatives (WDJ, BSP, VC) available. So our outlook on it is
very positive, it works well together with WF implementations and also
has UI-wise very powerful features like POWL and FPM delivered with
the framework.

WDA + ABAP OO for WF experiences:
Yes, the 1 + 1 = 3 section :)

Having gone through multiple projects using the two, the main benefits
arising from the usage of ABAP OO together with Workflow and WDA are
reuse and encapsulation in my experience. What this basically means is
that when building a web enabled workflow solution having WDA as the
UI, we are first structuring the solution into architecturally
different layers. Most common layers in a typical scenario include the
UI layer (incl WDA), process integration layer (WF) and the business
logic layer (ABAP OO). Each of the scenario specific layers then have
several components like multiple WDA components, multiple workflow
definitions and multiple classes.

As an example, let's take a typical parked invoice approval scenario
where you need to have a web UI for casual invoice approvers, a
workflow to coordinate the process and a class to take care of invoice
actions and information provisioning. For the invoice object realized
as an ABAP OO class, the typical implementation should then include
not only WF interface methods, but also getters and setters (called as
functional methods from WF, and by WDA as instance methods), invoice
action methods (status changes triggered by WF and/or WDA) and static
methods used for invoice work item reporting etc. Having implemented
everything in one class, you can use e.g. the same object and its
methods efficiently and effectively by both the WDA and by the WF
definitions.

My experience in summary currently is that I would go no other way
than using ABAP OO in WF related projects. Switching back to BOR not
only would make my life miserable because of all the macros, outdated
editors and other features of BOR, but more importantly because its
integration to WDA would be so much more difficult when compared to
ABAP classes. There is of course the learning curve you need to
conquer as discussed in previous posts, but I definitely think it's
worth the leap.

Kind regards,
Mikko

Mikko Mäki-Rahkola
Managing Director
Nobultec Ltd
Tekniikantie 12
02150 Espoo
Finland
+358 50 558 7834
mikko.maki-rahkola at nobultec.com
www.nobultec.com - Work redistributed
fi.linkedin.com/in/mikkomakirahkola - Follow me on LinkedIn
twitter.com/mikkomr - Follow me on Twitter
twitter.com/nobultec - Follow Nobultec on Twitter