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

[Mike Pokraka]

Hi Mikko,

Great post! You've hit the nail on the head with two of the most important
reasons for OO: class re-use outside of WF, and being able to share work
with ABAPers who have no clue about WF. Once upon a time a workflow
solution was just another silo app, but these days it's all a bit more
integrated and component re-use is more of an issue.

Cheers,
Mike


On Fri, February 25, 2011 7:24 am, Mikko Mäki-Rahkola wrote:
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>