Launching WDA items from Extended Notifications

Mike Pokraka wug at workflowconnections.com
Fri Feb 25 11:40:25 EST 2011


Hi Ramki,

We've drifted way off topic into specific problems so I changed the
title...

Had a quick look, can use SAP_WAPI_GET_METHODS to derive whether it's a
webby item and SAP_WAPI_LAUNCH_URL_GET is self-explanatory.

That's the easy bit, the extended notification part can get a tricky.
Haven't worked with it for a while but from memory I think you may need to
do an enhancement. CL_SWN_NOTIF_WORKFLOW is a good starting point.

Cheers,
Mike

On Fri, February 25, 2011 4:12 pm, Ramki Maley wrote:
> 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
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>





More information about the SAP-WUG mailing list