Workflow notifications through Web Dispatcher

[Florin Wach]

Thank you indeed for finding the very last piece in the puzzle. It was very interesting to read and thank you for your feedback!

-------- Original-Nachricht --------
> Datum: Thu, 14 Jan 2010 17:02:44 +0200 (EET)
> Von: POURNARAS KONSTANTINOS <pourne at otenet.gr>
> An: sap-wug at mit.edu
> Betreff: RE: Re: Workflow notifications through Web Dispatcher

> 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
> > 
> > 
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug