Workflow notifications through Web Dispatcher

POURNARAS KONSTANTINOS pourne at otenet.gr
Thu Jan 14 10:02:44 EST 2010


Hello Florin, 

I am coming back regarding my initial question with the solution that worked for me, plus my findings.
Subtyping CL_SWN_MESSAGE_CONTROLLER and redefining method GET_BASE_HREF worked. Assigning the subclass as the controller class for the BSP, everything gets replaced in the generated message source properly.

The reason that the HTTP Exception table entry does not work in the Workflow Notifications case lies in IF_HTTP_SERVER~GET_LOCATION_EXCEPTION at line 84:

     CHECK host_header IS INITIAL OR host_header CP <httpurlloc>-host.

host_header contains “localhost”, and <httpurlloc>-host contains the web dispatcher server name as set on the exception table, on my example “sapwebdisp”. This fails, so the default fully qualified name is returned instead.
Note that this is not the case when simply testing CL_SWN_URL_GENERATOR=>GET_BSP_HOST as the host_header variable is initial.

After the call returns to ZCL_SWN_MESSAGE_CONTROLLER->GET_BASE_HREF, code can be written that evaluates the HTTP exception table again without the seemingly problematic statement above.

Thanks to the entire group for your attention.



Best regards,
Evangelos Pournaras


Florin Wach <florin.wach at gmx.net> wrote: 
> Hello Pournaras,
> 
> I have recently replaced the message-Generator with a custom one because I needed to change and extend an existing attribute on the HTML BSP-View of the MESSAGE-Service (which I've also copied for other reasons). That's why I just yesterday stumbled over that coding spot yesterday.
> 
> Within the BSP Application swn_message1 you'll find the view html_indiv.htm (if you're using individual mails, otherwise refer to the respective other views).
> 
> Under "Page attributes" you can find a parameter BASE_HREF.
> 
> That's the one being used for this part here:
> <htmlb:content id="EmailBodyIndiv" checkForCookiesAndJavaScript="FALSE">
>   <htmlb:document>
>     <htmlb:documentHead>
>       <base href="<%= BASE_HREF %>">
> 
> And with a look at here:
> 
> CL_SWN_MESSAGE_CONTROLLER->do_request
> you'll find
> 
>   TRY.
>       l_base_href = get_base_href( ).
>       li_view->set_attribute( name = 'BASE_HREF'
>                               value = l_base_href ).
> 
> That's where it comes from. And that refers down to "point 2" that you've already found:
> 
>    get_base_href() --> cl_swn_url_generator=>get_bsp_host( )
> 
> 
> You've got several options to work around that problem:
> * Subtype the message controller class, replace do_request with a copy of the coding and change the setting for l_base_href as you like. Enter that class within SWNCONFIG
> * Change the BSP Application view "html_individ.htm" directly and hard-code that Base-URL, making it work only for production system. That's the most quickest solution but also something you'd usually don't want to do
> * Extend the class method cl_swn_url_generator=>get_bsp_host()
> * Copy the Message BSP application to your own application and do something else
> 
> 
> Next step is the maintenance of the SWNCONFIG base URL there, to get the other hyperlinks correctly set (as you've found out with point 3).
> 
> 
> 
> Nevertheless I think that it's a BUG that the get_bsp_host() class method is not using/checking the WG_HOST checking of the SWNCONFIG.
> 
> Good luck by creating an OSS message there.  For the time beeing, I'd suggest to use a workaround by combining your solutions 2) and 3).
> 
> 
> Best wishes,
>    Florin
> 
> 
> 
> 
> 
> 
> -------- Original-Nachricht --------
> > Datum: Tue, 12 Jan 2010 12:03:24 +0200 (EET)
> > Von: POURNARAS KONSTANTINOS <pourne at otenet.gr>
> > An: sap-wug at mit.edu
> > Betreff: Workflow notifications through Web Dispatcher
> 
> > Hello all,
> > 
> > I have a problem with the e-mail messages created through Workflow
> > Notifications. The productive landscape is a central instance under which two
> > application servers reside; <sapp1> and <sapp2>. The fully qualified names for
> > these servers is <sapp1.company.com> and <sapp2.company.com>. 
> > Users connect to the central instance through Citrix, and eventually get
> > assigned to one of the instances. When a workflow notification is created,
> > the links use the fully qualified server names in port 8000; so, the links
> > start with <http://sapp1.company.com:8000/...> or
> > <http://sapp2.company.com:8000/...>.
> > 
> > The problem is that all HTTP traffic is served through Web Dispatcher at
> > <http://sapwebdisp:8100/...>, so all HTTP requests should start as such.
> > 
> > I have attempted to fix this in the following ways:
> > 
> > 1.	Setting the icm hostname to sapwebdisp; this would work on a landscape
> > with one instance, but not on the aforementioned landscape with two
> > instances. Even the Web Dispatcher would not respond, but emails generated had the
> > proper links and HTTP references.
> > 
> > 2.	Creating an entry in HTTPURLLOC table; this seems to generate proper
> > URLs by testing class CL_SWN_URL_GENERATOR, but actual message generation
> > through SWN_SELSEN still uses the fully qualified name of the initiating
> > instance. This is kept though, as CL_SWN_URL_GENERATOR is used by other parts of
> > my workflows to send information messages.
> > 
> > 3.	Setting WG_HOST; in transaction SWNCONFIG -> General Settings ->
> > WG_HOST is set as <http://sapwebdisp:8100/sap/bc/gui/sap/its/webgui/>. This gives
> > me correct links in the body of the emails generated, so I have an
> > operating solution. The problem here is that HTML formatting is lost, due to the
> > fact that the message source still contains references to the fully
> > qualified name of the server, e.g.  <html><head><title></title><base href="
> > sapp1.company.com "…>.
> > 
> > Maybe you have an alternative solution to propose? It seems that the only
> > problem remaining with my solution (points 2 and 3) is the reference of the
> > fully qualified name in the message source; can that be altered somehow
> > with customizing or parameter settings?
> > 
> > 
> > 
> > Best regards,
> > Evangelos Pournaras
> > 
> > _______________________________________________
> > 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