Launching WDA items from Extended Notifications

Fri Feb 25 11:46:59 EST 2011

Mike, apologies for the drifting and thanks again for separating the 
issue and your valuable suggestions.

Best Regards,
Ramki.

On 2/25/11 11:40 AM, Mike Pokraka wrote:
> 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
>>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug