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

[Ramki Maley]

Mike, great ideas. I will look into them. I am under severe time 
constraints and was thinking in the lines of your first suggestion.

Many Thanks,
Ramki.

On 2/25/11 11:06 AM, Mike Pokraka wrote:
> Hi Ramki,
>
> The main issue is that your're launching a web app which drops down into
> GUI mode to launch a new web app. Very roundabout and spawns an extra
> unnecessary session.
>
> There are a few ways to work around this, mostly involving customizing
> Extended Notifications to some degree. You can look at the work item and
> if it's web-based then pull out the URL the work item is trying to launch
> (there's a WAPI for it), and put that into the mail instead of the link to
> SWNWIEX.
>
> Another solution I've built is to redirect everything to a filter app
> which looks at where it was launched from, what the work item does and
> then decides what to do. Useful if you have multiple entry points and
> execution mode. (e.g. if single approval in user's inbox, launch yes/no
> window, if multiple approvals in inbox then launch an overview app).
>
> Cheers,
> Mike
>
> On Fri, February 25, 2011 3:13 pm, Ramki Maley wrote:
>> Mikko, thanks for a great reply. I fully agree with you. I too have been
>> using ABAP-OO to create new objects, new methods for existing BOR etc.
>>
>> I am in a situation where the users want WebDynpro and don't want
>> anything to do with SAPGUI. The client does not have EP. We have built a
>> simple WDA application and used WF_EXTSRV to generate a task for it.
>> This works fine when executed from the SBWP. The issue is when an email
>> with Execute Workitem link is sent to Outlook using Extended
>> Notifictions. Since the link executes Txn. SWNWIEX, the 'Close Window'
>> screen is opened first in SAPGUI/browser and then the WDA is launched.
>>
>> Is there any way to launch the WebDynpro from the email other than
>> actually putting the URL in the workitem description?
>>
>> Thanks,
>> Ramki.
>>
>>
>>
>> On 2/25/11 2: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
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug