Links in Extended notifications need to point to portal not backend

[Dart, Jocelyn]

Margaret,
As SWNCONFIG is a customizing table, pointing it to the custom handler would be on a customizing request.
Are you sure you transported the customizing request to your runtime client before running SWN_SELSEN_TEST.
Did you try just a normal run of SWN_SELSEN also?
Regards,
Jocelyn

________________________________
From: sap-wug-bounces at mit.edu [sap-wug-bounces at mit.edu] On Behalf Of Hilsbos, Margaret A [Margaret.Hilsbos at dayzim.com]
Sent: Friday, 23 July 2010 3:35 AM
To: SAP Workflow Users' Group
Subject: RE: Links in Extended notifications need to point to portal not backend

Thanks, Jocelyn and Mike, for your excellent inputs!

I’ve now got this working in our development system. I found I did not need a custom BSP page. The basic steps I did:


•       My portal administrator created a portal page for the standard SAP BSP, swn_wiexecute

•       I enhanced the method CL_SWN_NOTIF_WORKFLOW->ADD_LINK_ACTION_DECISION to replace the url with the portal url  (we are on 7.0 EhP1  and can use implicit enhancement points at beginning and end of methods – very useful!)

However, I did want to create the custom handler as a copy of CL_SWN_NOTIF_WORKFLOW, as Mike reported he did.  But I could not seem to get the extended notification configuration to see the new handler. I changed it on the Category details of scenario Workflow – I changed the field ‘Notification Handler’ to my new class. Yet when I ran SWN_SELSEN_TEST it kept using the standard class. (I know this  because there was an error in the enhancement code that caused a dump. That error is definitely not in the custom class since I could write it completely differently, directly in the method).

So I have a couple questions about the configuration if I wanted to use a custom handler class (which will give us more flexibility):


•       Is the category the right place and the only place to update it? Is it sufficient to just change the notification handler?

•       Because I’ve struggled with SWNCONFIG/SWNADMIN before (ok, truth: I always dread having to touch this configuration. I end up with many more gray hairs and wishing I were home to pour a stiff drink. Is it just me?) – is there a lag time, or some sort of buffer issue with changes in the config actually being incorporated when SWN_SELSEN is run?

Thanks again for all your help!


Margaret Hilsbos
Business Systems Analyst
Day & Zimmermann, Inc.
(215) 299-5630
margaret.hilsbos at dayzim.com<mailto:margaret.hilsbos at dayzim.com>

This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Dart, Jocelyn
Sent: Wednesday, July 21, 2010 7:13 PM
To: SAP Workflow Users' Group
Subject: RE: Links in Extended notifications need to point to portal not backend

Hi Margaret,
You need to look at the handler class CL_SWN_NOTIF_WORKFLOW and method ADD_LINK_ACTION_DECISION.

You can if you like create your own handler and swap it at the relevant level of the SWNCONFIG.
Regards,
Jocelyn

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Hilsbos, Margaret A
Sent: Wednesday, 21 July 2010 10:30 PM
To: SAP Workflow Users' Group
Subject: RE: Links in Extended notifications need to point to portal not backend

Hi,

(I changed the subject line to make it more relevant to the actual issue - this thread began life as "Extended notifications and UWL- no notifications created/sent")

I built the simple BSP, as Mike suggested, to do the redirect. The redirect page works fine when I paste the link into the browser with an appropriate query string. The problem now is that I can't find where to change the extended notification to call my new portal iView that is based on the BSP. I tried changing the host values in SWNCONFIG general settings, but the resulting email is still building the url's for the user decision based on the swn_wiexecute BSP (i.e. same as before). As I think Jocelyn had noted previously, the host values in general settings are not the place to influence this.

So this is where I am stuck - how do we change the url that is called when a user clicks a user decision link in the extended notification emails? (The objective is to require the portal login credentials instead of the backend credentials when the user clicks a user decision link or execute/display work item.)

Some possible options I see are:


 *   Custom message template (which I don't quite know how to do yet)
 *   Enhance the standard message template (not sure if that will work)
 *   Do away with the user decision links and embed the links in the email text (this is easier for one workflow, but more work if we want all workflows to work this way)

This seems like it is more difficult than it should be … am I missing something basic? I am also wondering -

 *   if there are any settings that can be made in SICF for the web service that would accomplish our objective
 *   Is there something that can be done with visualization settings (SWFVISU) for the user decision task, so that it opens a webdynpro in the portal? (I haven't done anything that required SWFVISU yet, so I don't know it well, but it seems like it might be the intended approach)

Can anyone provide advice or suggestions?

Thanks!


Margaret Hilsbos
Business Systems Analyst
Day & Zimmermann, Inc.
(215) 299-5630
margaret.hilsbos at dayzim.com

This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

-----Original Message-----
From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU] On Behalf Of Hilsbos, Margaret A
Sent: Friday, June 25, 2010 2:43 PM
To: SAP Workflow Users' Group
Subject: RE: Extended notifications and UWL- no notifications created/sent

Mike,

Thanks again, this sounds like it will work and not be too difficult to accomplish. It might be next week or longer until I get to try it, but once I do, I will post again with my results.

Have a great weekend!

Margaret Hilsbos
Business Systems Analyst
Day & Zimmermann, Inc.
(215) 299-5630
margaret.hilsbos at dayzim.com

This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Pokraka
Sent: Friday, June 25, 2010 12:27 PM
To: SAP Workflow Users' Group
Subject: RE: Extended notifications and UWL- no notifications created/sent

Hi Margaret,

Yes, that's exactly it. Memory is a bit hazy, but it went something like:

- Configure the BSP as an iView in the portal.

- In SWNADMIN plug the portal's path to the BSP iview somewhere into the
config (SAP backend hostname?).

- The BSP basically takes whatever URL it's being called with, strips out
the portal portion and replaces it with the backend. Then it redirects the
user there. I think I just did a simple navigation in the OnRequest event
handler.

- To enable a BSP for anonymous login you give it a fixed username in
SICF. Any requests to that BSP will be executed under that ID. Although on
second thoughts I think this wasn't necessary, the iview was already
enough to force a login via the portal.

Cheers,
Mike


On Fri, June 25, 2010 1:51 pm, Hilsbos, Margaret A wrote:
> Mike,
>
> Thanks for your help! I verified that it does work on my system exactly as
> you've described, so your fix should work for us.  I have just enough BSP
> and portal knowledge to be dangerous, but I can get help if I need it.
>
> If I understand correctly, we need to:
>
> 1) create a bsp application that redirects to the SAP standard page (I
> take it that is 'swn_wiexecute' with the query string appended)
> 2) configure extended notifications to point to the custom page
>
> Couple questions -
> 1) where do I call out the new bsp page in the extended notifications
> configuration?
> 2) how do I set the bsp application for anonymous access?
>
> With those bits filled in this sounds like a very simple and useful
> solution.
>
> Thanks,
>
> Margaret Hilsbos
> Business Systems Analyst
> Day & Zimmermann, Inc.
> (215) 299-5630
> margaret.hilsbos at dayzim.com
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may contain confidential and/or privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies of the original message.
>
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Mike Pokraka
> Sent: Friday, June 25, 2010 6:08 AM
> To: SAP Workflow Users' Group
> Subject: RE: Extended notifications and UWL- no notifications created/sent
>
> Hi Margaret,
>
> The good news: I've encountered this and have a simple workaround.
> The potential bad news: you will need a little BSP and portal skills, if
> this is not your area then hopefully you have some people who can help.
>
> As you picked up, this is an authentication issue that would not normally
> happen if userids & passwords were synchronised. The exact mechanics
> depend on your landscape, but in my case if users log onto the portal
> BEFORE clicking on the approve/reject link in the mail, it worked fine
> because there was an established session it could use. But if you click on
> the link without first logging onto the portal it will try to authenticate
> via the backend because that's there the approve/reject link points to.
> (Please check this applies to you before proceeding).
>
> The last bit is the key - the approve/reject link points to the backend,
> so if no session exists it will try to authenticate there. My hack
> involved a simple BSP app which redirects the user to the real page. This
> app is set up for anonymous access so no auth is needed until the user
> lands in the portal.
>
> Extended notifications are then configured to point to the BSP page, which
> simply redirects to the 'real' link.
>
> Hope that makes sense. If not let me know and I will try to dig through my
> notes for more details.
>
> Cheers,
> Mike
>
> On Thu, June 24, 2010 2:16 pm, Hilsbos, Margaret A wrote:
>> Jocelyn,
>>
>> Thanks for your info and clarifications, your response is very helpful!
>>
>> But, if I follow your suggestions, can I get all the links in the email,
> other than the Inbox link, to go directly to the work item via the UWL,
> not the backend system? I mean for Execute Work Item, Display Work Item,
> and User Decision links.  We are trying to avoid user confusion when
> their
>> passwords differ between portal and backend. Many of our workflow users
> will not be regular backend SAP users ... we want to give them the
> direct
>> links - including direct approve/reject from the email - but NOT have
> them
>> worrying about which password to use (and not submitting Help Desk
> tickets).
>>
>> Thanks,
>>
>> Margaret Hilsbos
>> Business Systems Analyst
>> Day & Zimmermann, Inc.
>> (215) 299-5630
>> margaret.hilsbos at dayzim.com<mailto:margaret.hilsbos at dayzim.com>
>>