Workflow notifications through Web Dispatcher

[Dan Stoicof]

Sint intru totul de acord cum vin ciorile pe lume!

--- On Thu, 1/14/10, POURNARAS KONSTANTINOS <pourne at otenet.gr> wrote:

> From: POURNARAS KONSTANTINOS <pourne at otenet.gr>
> Subject: RE: Re: Workflow notifications through Web Dispatcher
> To: sap-wug at mit.edu
> Date: Thursday, January 14, 2010, 8:02 AM
> 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
>