One Fiori Launchpad for Huge System Landscape? Limitations of FLP Technical Concepts?

[LutzR]

Hi,

currently I am getting asked if it is a reasonable idea to use one single FLP as entrypoint for the system landscape of a large company.

Lets consider this example of a system landscape:

• 5 ERPs (EHP7 or 😎 for different business areas and regions
• 3 are S/4HANA
• At least two BW landscapes both running on HANA

Of course native HANA (XS) content shall be used on all HANAs.

Now there are users that need to work in several if not all of these systems. This is no theoretical showcase.

The prerequisite for successful integration into one single FLP is that all systems are accessed over one single SAP Web Dispatcher (identical https://fqdn:port) because of current clickjacking protection mechanism.

As a reference I would take this document by : Configuring the Web Dispatcher for Multiple Systems - Clarifications and Examples - Application Serv... and this one by :

So is there a way to achieve this? Currently I would say "no" because we can route the same path (e.g. /sap/hba) only to one system and not to many. System cookies would also probably lead to confusion.

Did I miss something? Or is the FLP really limited to one system of each kind and only one native HANA in the complete landscape?

Regards,

Lutz

[petr_solberg]

Hi Lutz and All,

I have to come up with a Fiori strategy and am committed to Single Point of Entry - ie, one url for everything.

Correct me if I am wrong we are talking here about:

1 x Central ABAP Front End Server

serving

Multiple x SAP Backend Systems

This is documented by SAP here:

          https://eaexplorer.hana.ondemand.com/_item.html?id=11115#!/overview

         

Deployment Architecture:

The deployment architecture of SAP Fiori Front-End Server is based on the following main technical components:

•The SAP Web Dispatcher serving as reverse proxy

•The SAP Friori Front-End Server (FES) based on SAP NetWeaver AS ABAP and containing

•Fiori Applications (UIs) inclusive Fiori Launchpad Content,

•The central UI technology providing the the UI5 framework and the Fiori Launchpad (FLP),

•SAP Gateway server components (already part of AS ABAP with SAP NetWeaver 7.4 or higher) plus optional central SAP Gateway content

•SAP application backend systems containing

•Fiori Applications (backend OData integration), deployed via Add-Ons or Support Packages •SAP Gateway backend components (already part of AS ABAP with SAP NetWeaver 7.4 or higher)

Is that solving what you are talking about or is the question something different ?

Andy.

[LutzR]

Hi Andy, I would start discussion with this simple picture from slide 17 of

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/30e401f4-ee41-3310-f2a8-9ef94bad3...

and just extend it by two more S/4HANA ERPs (for simplicity 😞

the price winning question is: How would a SAP Web Dispatcher profile have to look like to cope with this? How would the Web Dispatcher reliably know which request to forward to which system when all backends use the same URIs? How would systems react when getting some cookies from the other two systems?

At the moment I would say this scenario is not possible for technical reasons. Is it?

Regards,

Lutz

[petr_solberg]

Hi Lutz,

thank you for clarifying the question.

I have previously put this same question to SAP, for requirements which I have to achieve the same goal. SAP's answer was, (and I have not implemented it yet), yes this is supported and possible by proper configuration of the Web Dispatcher.

I have not implemented this yet, but it is a goal.

And I don't see any other possibility, there must be only one Url single point of entry (one FLP), we cannot give the Users multiple different entry points.

Therefore, I expect based on SAP's feedback to be able to implement this.

Best regards,

Andy.

[isaias_freitas]

Hello Andy, all,

I would say that the Web Dispatcher part is "easy" and doable.

We can refer to the help.sap.com page found by Lutz.

This help.sap.com page (and its child pages) has further information about the modification rules.

The question I do not know to answer is how to configure the FLP (or the applications published on it) to add something at the URI (like "o=SID") so the Web Dispatcher can know which system it should send the request to.

Best regards,

Isaías

[LutzR]

Hi Isaías,

this is exactly what I mean with "reliably". This "o=SID" thing looks more like a workaround than a solution. I feel quite shure that this parameter will be lost during navigation some way or the other latest when it comes to "legacy" frameworks like WD or WebGUI.

So I would love to see this kind of solution alive to be convinced.

Best regards,

Lutz

[isaias_freitas]

Hello Luts,

Yes, the "o=SID" will be lost (at least, the way I see it).

However, it will not matter anymore because of the "x-sap-webdisp-target-sid" cookie.

But then we come to the question "how will the session cookies work?" .

Besides that cookie, there will be the SAP session cookies, when FLP opens a transaction at one of the backends...

I guess that FLP will open such transaction at a new tab, then maybe the browser will know which cookies belong to which tabs?

Best regards,

Isaías

[LutzR]

Hello Isaías,

unfortunately there is nothing like a tab-cookie or a window-cookie. Current browsers share the session across all tabs and windows as long as the user does not explicitly specify to open a new session.

But a new session would also mean a new logon...

On the other hand Fiori is stateless (at least you read it everywhere) even in S/4HANA - so there is no cookie in the sense of a backend session. But there is a cookie "sap-usercontext=sap-language=EN&sap-client=001" issued to path "/" by fiori and what if the client is not 001 everywhere?

So we probably all agree that there are some important pieces still missing in the puzzle.

Best Regards,

Lutz

[isaias_freitas]

Hello Lutz,

... there is nothing like a tab-cookie or a window-cookie.

This is what I knew... But maybe there was something new that I was not aware of .

We just need to keep looking, and we will figure this out .

I'll update this thread if I find anything that would help.

Best regards,

Isaías

[petr_solberg]

Hi Isaias,

after years of pursuing the single point of entry, I am reluctant to go back to multiple points of entry.

I haven't implemented it yet, but SAP said the single FLP is possible with multiple backends.

Agree with all of the worries and agree, let's use this thread as a container for our findings and experiences, to keep everything in one place.

Best regards,

Andy.

[isaias_freitas]

Hello Lutz,

I am not an FLP expert, but when I read your thread I tend to agree with your answer ("no").

Is the port number really considered for the clickjacking protection mechanism?

If it is not, I would way "problem solved".

You could then use different ports at the Web Dispatcher in order to be able to reach the different backends, despite they would have the same URI path (like /sap/hba).

Looking forward to see the comments from an FLP expert .

Regards,

Isaías

[isaias_freitas]

Hello again,

While taking a second look at this thread (actually, at the blog from Jochen), I noticed the SAP note 2057847 (Removing/Relaxing Click-Jacking Protection for the SAP Fiori Launchpad) being mentioned.

This note has a "zip" file attached to it.

I started comparing the files "FioriLaunchpad.html" ("full" clickjacking protection) and "FioriLaunchpadRelaxedCJ.html", and I believe that if you use the later one it would work.

Let's say that the hostname of your Web Dispatcher is "wdp.company.com".

I believe that if you change the variables "retainOurs" and "retainParent" to 3 (from "FioriLaunchpadRelaxedCJ.html"), the port number would not be considered anymore.

However, the protection would still be in place, and any request not coming through "wdp.company.com" would be blocked.

Maybe this is something worth testing .

Cheers!

Isaías

[LutzR]

Hi Isaías,

thanks a lot for your hint!

Unfortunately the most important sentence of the note is the following:

"Note that usage of this modified launchpad is at your own risk, and not part of the original SAP solution."

This results in a no go in a scenario of this size. Imagine the next major FLP update coming and SAP discontinuing this workaround. But we will clarify with product management and/or development.

But I learned now that web dispatcher is not only needed for clickjacking protection but also for CORS compliance.

Here I found a link to this help Configuring SAP Web Dispatcher to Dispatch Requests to Different Systems - SAP Fiori Launchpad - SAP... telling that there might be options to send calls to same URIs on different systems using rewriting rules and header variables.

This looks more like a workaround for a very special scenario.

So investigations will continue ...

Regards,

Lutz

[isaias_freitas]

Hello Lutz,

You are welcome!

That help.sap.com page you found seems to solve the puzzle.

Would you be able to add the "o=<SID>" query parameter for all calls made within the FLP?

For example, if you have tiles that execute the same transaction using the WebGUI (/sap/bc/gui/sap/its/webgui), but on different ERPs.

If that is possible, I just wonder how the session cookies would behave...

Regards,

Isaías

[LutzR]

Hi Isaías,

the cookies are why I don't trust this. And I also doubt that it will be possible to always practice this kind of parameter to header rewriting. But I am not deep enough into FLP functionality yet to finally judge.

It would be great if someone (c) would do some kind of monster landscape FLP architecture evaluation.

But there is also the UX side. There are serious doubts the a 20 page long FLP and a search function that would deliver 5 times the identically named app because there are 5 ERPs would really make sense. Both architecture and UX probably is why SAP enabled PFCG  roles to contain and launch Fiori Apps (at least in NWBC). So I guess.

So for the first time in its existence NWBC (the installable version) might make sense to me thanks to Fiori. What an irony of fate.

Cheers,

Lutz