SAP Portal and SAP Fiori – Common Architecture
The SAP Enterprise Portal is the recommended single point of access for applications and content for more than 10 years and being implemented by thousands of customers across regions and industries.
The SAP Portal UX is aligning with the Fiori UX in two dimensions:
- The SAP Fiori launchpad in running on the SAP Enterprise Portal (as a new portal framework page)
- Fiori applications serving as business content for the portal
A typical scenario for the SAP Enterprise Portal together with the Fiori apps is the consumption on mobile devices, providing access to the system from inside and outside of the corporate network on multiple devices. This integration raises many architectural and security questions, which eventually lead to the question: what is the common architecture to integrate the SAP Enterprise Portal and with Fiori apps?
Typical reasons to integrate the SAP Enterprise Portal and SAP Fiori?
- Provide end users a single point of access, with a single URL, to all the end users daily business applications (Fiori and non-Fiori) and content
- Renew the SAP Enterprise Portal user experience with attractive, responsive and multi-device applications while keeping the established UIs in place
- Aligned look&feel of the portal and the business applications (including Fiori apps)
- Strong authentication and Single Sign-On concepts provided by the portal and the NetWeaver platform
- Leverage existing investment in the SAP Enterprise Portal
To learn more about this topic, please have a look at the following new white-paper presenting the topic and shading light on the common architecture, especially when consuming apps from outside of the corporate network. If you would like to review only the architecture slides, these are also available in the following link.
Thanks Thomas Csapo for co-writing this white-paper and Andy Silvey for providing very valuable feedback.
Thanks for the document and link to whitepaper. Its really great to see one of my wish in BIT taking shape.
HI Aviad Rivlin,
Thanks for documents.we need more docs on fiori related with portal.Such a nice blog it was.
Thanks for sharing it - it is really useful.
It seems to me that parts of teh architecture changed from Portal 7.31 to 7.40 - SAP Web Dispatcher seems to be available only for NW 7.40 in this scenario: Configuring SAP Web Dispatcher - Portal - SAP Library
Is it true? Becomes Portal 7.40 mandatory if you want to benefit from Fiori? What kind of restrictions do you have in release Portal 7.31?
The web dispatcher is a mandatory component in the Fiori apps integration scenario to removing/relaxing Click-Jacking Protection (see also note 2057847).
I'm going to be slightly controversial. Whilst some companies may want this (and the blog is very useful for them), most organisations I am working with actively want to remove their SAP portal and replace it with Fiori launchpad or integrate it into SharePoint. Why? Two reasons:
Having said that, thank you for the blog and it does have some very good architecture points in it which help explain the wider requirements around gateway / Fiori etc.
There are thousands of customers running the SAP Portal today and the Fiori launchpad (running on the portal) is a great opportunity for them to re-new their portal while re-using their current investment (mobile is a key…).
The Fiori launchpad strategy is to run across platforms (ABAP, SAP Portal, Cloud/HCP, HANA), hence giving customers the option to choose which is the right platform for them, in their specific scenario (not only the portal, but the portal is a good option).
Finaly, the Fiori launchpad (across its deployment options) is the entry point for SAP applications going forward. You can see more details in the User Interface Technologies - Roadmap slide #52.
These were few comments from my side...
I believe both Microsoft and EP have their own
advantages, and some disadvantages (cost to support, license, resource
knowledge, etc.) depending on the maturity and availability of internal
resources/knowledge at a specific client(s). I had both a customer who moved
away from SAP Enterprise Portal to SharePoint, and also a customer that adapted
the SAP NW 7.09 SP09 Fiori/SAPUI5, etc. quite easily due to developers
(internal) that were both knowledgeable on either .NET or SAPUI5/Fiori-like
development. I also have a few customers who have a mixed scenario wherein
single point of access is SharePoint, and links and Web Parts (mostly
customized) to launch Portal Apps (Web Dynpro, BSP, etc.) I came from the
Microsoft world and transitioned into SAP, and hoped that they improved DUET to
a much better option (they have done great since DUET 1.0/1.5), but I think
this went back to MS and SAP being both a partner and also competitors. I
believe that the Common Architecture and UI-UX strategy of SAP is gaining a lot
of ground and acceptance, as it has evolved quite progressively (also with a
lot of investment from SAP), especially today. One thing I wish SAP worked on,
is the knowledge, training, and information being available and delivered to
non-SAP (internal) folks out in the industry. It is quite confusing, and
constantly changing (Dynamic), and keeping up with changes, is not easy on
clients that do not even have an overall UI-UX strategy. I think the key is to focus on offering a solution that works and fits within the clients environment (considering budget, technology, resources, and what is supported way beyond the extended maintenace periods. Building a comparison chart, GAP Analysis, and Risk Assessment as well as available (in this case a UI-UX strategy) options for the customer certainly helps.
Thanks Aviad for the User Interface Technologies Roadmap.
Thanks Aviad for sharing the architecture, very useful for a dummy. However being a SAP Portal Consultant, i too feel that there should be less coding and more efforts should be going to enhance Customer UX, which i feel Fiori will definitely serve the purpose.
Excellent Blog. But there is one limitation in this design or I am missing the point.
It's always Proxy which redirect between Portal and Backend not Portal directly communicate with Backend.
In our company, we currently have Apache redirect with 2 url path.
Portal -> /irj
ABAP - /sap/bc
We are using this for ITS/BSP services using HTML Plug-in.
Now with Central HUB NWG in landscape, I have to configure One Apache to redirect as
Portal -> /irj
ABAP - /sap/bc
FIORI - /sap/bc/ui2_ui5
My only concern is many of these services in /sap/bc available in backend and FIORI ABAP frontend.
Any suggestion on using Apache Redirect here?