Introductie

In 2013 introduceerde SAP haar nieuwe user-interface model genaamd Fiori. Hierbij werden 25 Fiori applicaties beschikbaar gesteld welke de meest gebruikte business transacties vertegenwoordigden. Sindsdien is het aantal Fiori applicaties exponentieel toegenomen en zijn ook steeds meer bedrijven SAP Fiori applicaties voor één of meerdere processen gaan gebruiken.

Om Fiori applicaties te kunnen gebruiken, zijn er bepaalde vereisten met betrekking tot het SAP systeemlandschap. De belangrijkste vereiste is dat er een front-end server beschikbaar is, van waar de SAP Fiori applicaties aangeroepen kunnen worden. De front-end server dient gekoppeld te worden met het achterliggende backend systeem, bijvoorbeeld een SAP ECC systeem, waarop het daadwerkelijke business proces zich afspeelt.

Tot voor kort werd de rol van front-end server vervuld door een SAP NetWeaver Gateway systeem op te nemen in het SAP systeemlandschap. Echter sinds medio 2016 is het ook mogelijk om SAP Fiori vanuit het SAP Cloud Platform te consumeren; het SAP Cloud Platform fungeert hierbij als front-end server. In deze blog wordt dieper ingegaan op de voor- en nadelen van het on-premise scenario versus het SAP Cloud scenario met betrekking tot SAP Fiori.

NB. Omdat het gros van de bedrijven SAP Fiori applicaties gebruikt voor de SAP Business Suite is deze blog voornamelijk op deze setup gebaseerd. Echter, voor een S/4HANA scenario gelden grotendeels dezelfde regels.

SAP NetWeaver Gateway server

In het on-premise scenario is een SAP NetWeaver Gateway vereist om SAP Fiori applicaties te kunnen aanroepen. Hierbij worden bestanden, waaruit de SAP Fiori applicatie is opgemaakt, opgehaald van de SAP NetWeaver Gateway. Deze bestanden vormen de zogenaamde user-interface (UI) van de SAP Fiori applicatie en zijn gebaseerd op SAPUI5.

Daarnaast wordt er in SAP Fiori applicaties gebruik gemaakt van het OData protocol om business data uit het gekoppelde backend systeem aan te kunnen roepen. Immers, zonder data is een SAP Fiori applicatie een “lege huls”; de applicatie moet wel in verbinding staan met een backend systeem dat het voorziet van data.

Voor het aanroepen van OData services in een on-premise scenario (zie figuur 1) is een SAP NetWeaver Gateway systeem benodigd. Het ondersteunt het zogenaamde CRUD concept (Create, Read, Update, Delete) om de applicatie te voorzien van data, of om bepaalde handelingen uit te voeren in het backend systeem. Denk hierbij bijvoorbeeld aan het aanmaken van een inkooporder, of het goedkeuren van een factuur. Wanneer er in een bepaalde SAP Fiori applicatie op de knop “Goedkeuren” wordt gedrukt, dan wordt deze goedkeuring via een OData aanroep verwerkt in het achterliggende backend systeem. Iedere SAP Fiori applicatie heeft een OData service, welke kan worden geregistreerd op het SAP NetWeaver Gateway systeem. Zonder deze Gateway registratie kan de OData service niet aangeroepen worden vanuit de Fiori applicatie. De externe OData aanroep wordt middels de registratie omgezet naar een SAP specifieke aanroep, bijvoorbeeld een methode in een ABAP klasse.

Ondanks dat ieder SAP NetWeaver systeem vanaf 7.0 of hoger in principe kan fungeren als SAP NetWeaver Gateway systeem, is het inzetten van een SAP NetWeaver Gateway systeem on-premise een extra belasting op het beheer van het systeemlandschap. Denk hierbij bijvoorbeeld aan het scenario voor het goedkeuren van inkooporders. Wanneer dit middels de standaard SAP Fiori applicatie gedaan moet worden, dient er naast het beschikbare SAP ECC systeem een nieuw SAP NetWeaver Gateway systeem opgezet te worden voor één relatief eenvoudig proces/applicatie.

Indien SAP Fiori vanuit de Cloud geconsumeerd wordt, is de noodzaak voor het opzetten van een extra SAP NetWeaver Gateway systeem on-premise niet meer noodzakelijk. Er zijn inmiddels vele standaard SAP Fiori applicaties beschikbaar gesteld op het SAP Cloud Platform. De rol die het SAP NetWeaver Gateway systeem vervult voor het beschikbaar stellen van de user-interface (UI) van de SAP Fiori applicatie, kan dus overgenomen worden door het SAP Cloud Platform. Wanneer er gebruik gemaakt wordt van het cloud-scenario, dient er wel een SAP Cloud Connector geïnstalleerd te worden. De SAP Cloud Connector zorgt voor de verbinding tussen het SAP Cloud Platform en het achterliggende SAP backend systeem.

De meest gebruikte standaard SAP Fiori applicaties zijn inmiddels beschikbaar gesteld op het SAP Cloud Platform en dit aantal wordt uitgebreid. In een on-premise scenario zijn dus vooralsnog meer standaard SAP Fiori applicaties beschikbaar dan in het cloud-scenario.

Naast het consumeren van de UI vanaf het SAP Cloud Platform, dienen de OData services op de SAP backend nog steeds geregistreerd te worden zodat deze aan te roepen zijn vanuit de SAP Fiori applicatie. Er kan gekozen worden om deze registratie plaats te laten vinden op het on-premise Gateway systeem, waardoor er naast de SAP Cloud nog steeds een SAP NetWeaver Gateway systeem benodigd is. Echter, nu is de on-premise Gateway alleen bedoeld voor de registratie van de OData services en niet meer voor het UI-gedeelte. We spreken hier van een zogenaamd hybride oplossing (zie figuur 2).

Voor het gebruik van SAP Fiori in de SAP Cloud dienen licentiekosten betaald te worden. Wanneer er een extra Gateway server in het landschap staat, puur en alleen voor het registreren van de OData services, dan zou dit hybride scenario een onnodige verhoging van de kosten met zich meebrengen. We zien daarom vaak dat in dit scenario de SAP backend server de rol van de Gateway vervult voor het registreren van de OData services. Hiervoor dient het achterliggende backend systeem minimaal een SAP NetWeaver 7.0 systeem te zijn.

Naast het hybride scenario kan er ook gekozen worden voor een volledig cloud-scenario (zie figuur 3). Hierbij vindt naast het consumeren van de user-interface, tevens de registratie van de OData services plaats op het SAP Cloud Platform. Dit gebeurt middels de zogenaamde OData Provisioning service.

In dit scenario dient alleen nog de OData service aanwezig te zijn op het on-premise SAP backend systeem, maar is er geen SAP NetWeaver Gateway systeem meer benodigd voor de registratie van de OData service. In dit scenario vervallen dus de beheerskosten van een SAP NetWeaver Gateway server. Door middel van registratie via de OData provisioning service op het SAP Cloud Platform, worden OData aanroepen vanuit de Fiori applicatie gerouteerd naar het betreffende backend systeem waar de OData service beschikbaar is.

SAPUI5 versie beheer

Belangrijk bij het gebruik van SAP Fiori applicaties is de beschikbare SAPUI5 versie op de front-end server. De SAPUI5 versie bepaalt onder andere hoe de SAP Fiori applicatie zich gedraagt, welke look & feel er van toepassing is en of bepaalde user-interface (UI) elementen gebruikt kunnen worden in de applicatie. Het kan bijvoorbeeld zijn dat een SAP Fiori applicatie pas draait vanaf een bepaalde SAPUI5 versie. Anderzijds kan het voorkomen dat gebruikte UI elementen in een SAP Fiori applicatie in een hogere versie van SAPUI5 niet meer ondersteund worden of zijn vervangen door andere elementen. Daarnaast worden er ook upgrades doorgevoerd met betrekking tot security en dienen nieuwe ontwikkelingen in de mobiele sector ondersteund te worden middels nieuwe SAPUI5 versies. Hierdoor is het noodzakelijk met enige regelmaat de SAPUI5 versie te upgraden/patchen naar de laatst beschikbare versie.

De release cycli van SAPUI5 versies en patches verschilt aanzienlijk van de traditionele release cycli voor SAP software. Kijkend naar de patches die uitgebracht worden voor SAPUI5 versies, dan is er ongeveer om de maand een nieuwe patch beschikbaar. Bijvoorbeeld voor SAPUI5 versie 1.44 zijn recentelijk de volgende patches uitgebracht:

Versie 1.44.45 – 02 mei 2019
Versie 1.44.44 – 11 maart 2019
Versie 1.44.43 – 12 februari 2019
Versie 1.44.42 – 30 november 2018
Versie 1.44.41 – 25 oktober 2018
…..

Het upgraden van een on-premise systeem heeft een relatief grote impact op het ICT landschap en kost tijd en geld om uitgevoerd te worden. Denk hierbij aan het beschikbaar stellen van resources, het inspelen van support packages of het uitvoeren van de SPAU. Al deze impact vervalt in het cloud-scenario waarbij een nieuwe SAPUI5 versie simpelweg beschikbaar wordt gesteld op het SAP Cloud Platform. Het upgraden naar een hogere SAPUI5 versie op het SAP Cloud Platform houdt niet veel meer in dan het selecteren van een hogere versie in de configuratie van bijvoorbeeld de SAP Fiori Launchpad.

Het upgraden van de SAPUI5 versie zou mogelijk kunnen leiden tot dat de in gebruik zijnde standaard SAP Fiori applicaties niet meer correct werken. Kijkend naar een on-premise scenario, houdt dit in dat er mogelijk diverse SAP OSS notes of support packages/patches ingespeeld dienen te worden om de SAP Fiori applicatie werkend te krijgen op een hogere SAPUI5 versie. Ook deze effort is niet meer benodigd in een cloud-scenario; de standaard SAP Fiori applicaties beschikbaar op het SAP Cloud Platform werken op de daar beschikbaar gestelde SAPUI5 versies. Er zou zelfs even “gespiekt” kunnen worden of alle SAP Fiori applicaties werken in een hogere SAPUI5 versie op het SAP Cloud Platform. Dit is niet mogelijk in een on-premise scenario, waarbij er maar één versie beschikbaar is. Wanneer er gebruik wordt gemaakt van de SAP UI Theme Designer om eigen thema’s te creëren, dan dienen deze opnieuw gegenereerd te worden wanneer een nieuwe SAPUI5 versie geïnstalleerd wordt. In een on-premise scenario dient dit als een van de activiteiten opgenomen te worden in de upgrade. In een cloud-scenario worden eigen thema’s automatisch opnieuw gegenereerd, zodra er een nieuwe SAPUI5 versie beschikbaar is.

Zoals eerder vermeld zijn er minder standaard SAP Fiori applicaties beschikbaar in het cloud-scenario (+1.100) ten opzichte van het on-premise scenario (+2.100), maar dit verschil zal geleidelijk steeds minder groot worden. Er is overigens altijd de mogelijkheid om een standaard Fiori applicatie, welke alleen on-premise beschikbaar is, naar het SAP Cloud Platform te halen. Dit kan simpelweg middels een on-premise download van de SAP Fiori applicatie gevolgd door een upload (of deploy vanuit de SAP Web IDE) naar het SAP Cloud Platform.

User-/identity management

In een on-premise scenario dienen de SAP gebruikers van het SAP backend systeem gerepliceerd te worden op het SAP NetWeaver Gateway systeem. Dit vergt dus extra beheer werkzaamheden voor het onderhoud van medewerkers binnen een organisatie. In het cloud-scenario zijn er geen extra Gateway SAP-gebruikers meer nodig, maar dienen de gebruikers aangemaakt te worden in een gekoppelde identity provider in het SAP Cloud Platform. Bij het gebruik van SAP Fiori in de Cloud wordt er door SAP een identity provider beschikbaar gesteld welke hiervoor gebruikt kan worden. Echter, het SAP Fiori cloud-scenario is zeer uitvoerig voorbereid om gebruik te maken van de reeds beschikbare identity provider binnen een organisatie. Denk hierbij aan een Active Directory of Miscrosoft Azure oplossing, waarbij een gebruiker voor de SAP Fiori Launchpad inlogt met zijn of haar eigen e-mailadres en wachtwoord wat ook elders gebruikt wordt (bijvoorbeeld bij het inloggen op de pc of e-mail account). Hierdoor hoeven er dus geen extra SAP gebruikers onderhouden te worden en kan gebruik worden gemaakt van de reeds beschikbare identity provider van de organisatie.

Figuur 5: Voorbeeld opzet user- en identity management

Voor wat betreft user-/identity management zijn er twee stromen te onderscheiden; een datastroom en een authenticatiestroom. Er dient geauthentiseerd te worden richting de gekoppelde identity provider (in onderstaand figuur is dit een Active Directory), waarna vervolgens de data opgehaald kan worden uit het gekoppelde SAP backend systeem. De gebruiker die vastgesteld is bij de authenticatie wordt meegestuurd met de datastroom richting het SAP backend systeem.

Ongeacht welke identity provider er gekozen wordt in het cloud-scenario, dient er uiteindelijk met de corresponderende SAP gebruiker ingelogd te worden in de SAP backend om bijvoorbeeld de goedkeuring van een inkooporder onder de juiste gebruiker uit te voeren in SAP. Hiervoor wordt gebruik gemaakt van het zogenaamde “principal propagation”. Er wordt met certificaten een trust relatie gerealiseerd tussen de verschillende componenten vanaf het SAP Cloud Platform tot en met het SAP backend systeem. Middels zogenaamde “SAML2 assertion” wordt een attribuut van de gebruiker op de aan het SAP Cloud Platform gekoppelde identity provider “gepropageerd” richting het SAP backend systeem. In het SAP backend systeem zorgt dit attribuut er middels een mapping voor dat de juiste SAP gebruiker ingelogd is en de handelingen doorvoert in het SAP backend systeem.

Om dit te realiseren zijn er de volgende trust relaties opgezet middels certificaten:

Identity provider <-> SAP Cloud Platform
SAP Cloud Platform <-> SAP Cloud Connector
SAP Cloud Connector <-> SAP backend system

Het spreekt voor zich dat een dergelijke opzet om deze vereiste principal propagation te realiseren een zekere multidisciplinaire inspanning vergt, welke niet perse noodzakelijk is in een on-premise scenario. Het grote voordeel is echter, dat gebruikers het gemak ondervinden van single sign on (SSO) en met hun reguliere gebruikersnaam en paswoord binnen het bedrijf ook gebruik kunnen maken van SAP Fiori, zonder dat er aparte SAP gebruikersnamen en paswoorden onthouden moeten worden. Uiteraard kan een dergelijke SSO opzet ook in een on-premise scenario worden gerealiseerd, maar is niet vereist en komt daardoor minder vaak voor. Daarnaast is het on-premise scenario niet op eenzelfde manier voorbereid c.q. voorgesorteerd op het instellen van een lokale identity provider zoals dat het cloud-scenario dat is.

Rapportage/Monitoring

Wanneer een on-premise scenario gebruikt is, worden er diverse rapportage- en monitoringsmogelijkheden geboden in zowel het backend en front-end systeem. Voordeel hiervan is dat er bij eventuele foutafhandeling de monitoring en logging op een centrale plek aangeroepen kan worden, namelijk het SAP NetWeaver Gateway systeem. Mogelijke fouten in het backend systeem, zijn tevens inzichtelijk in SAP NetWeaver Gateway.

Figuur 6: Error log SAP NetWeaver Gateway

Kijkend naar een cloud-scenario, dan zijn de rapportage- en monitoringsmogelijkheden meer verspreid over de verschillende onderdelen van de installatie. Grofweg zijn deze verdeeld over drie onderdelen:

SAP backend systeem
SAP Cloud Connector
SAP Cloud Platform

De rapportage en monitoring op het SAP Cloud Platform en in de SAP Cloud Connector is niet zo uitgebreid als wanneer er een on-premise scenario van toepassing is. Daarnaast is de logging van bijvoorbeeld fouten niet centraal georganiseerd zoals dat van toepassing is in een on-premise scenario. Het optreden van een fout kan immers zijn oorsprong vinden in een van bovengenoemde drie onderdelen, en er dient dus op meerdere plekken geanalyseerd te worden wat er fout is gegaan en waarom.

Performance/geografisch verspreid

Indien een on-premise SAP NetWeaver Gateway systeem gebruikt wordt in geografische verspreide locaties, kan er vertraging optreden bij het laden van SAPUI5 resources. Hoe verder men zich geografisch gezien bevindt van de Gateway server, hoe meer mogelijke vertraging (zogenaamde latency) optreedt bij het laden van de SAPUI5 resources.

Dit probleem wordt opgevangen in het SAP Cloud Platform middels de meerdere SAP Cloud data center locaties. Zie onderstaand figuur voor een weergave van de verschillende locaties waar de diensten van het SAP Cloud Platform wordt gehost.

Figuur 7 - SAP Cloud data center locaties

De SAP Cloud diensten die afgenomen worden met betrekking tot SAP Fiori zijn SAP Fiori Cloud en (eventueel) OData Provisioning. In onderstaande tabel is weergegeven welke locaties deze diensten ondersteunen op het SAP Cloud Platform.

Figuur 8: SAP Fiori Cloud en OData Provisioning data center locaties

Doordat de diensten op het SAP Cloud Platform verspreid over de wereld beschikbaar zijn, kunnen resources geladen worden van een server op een locatie die zich het dichtstbij de aanvrager (is client) bevindt.

Daarnaast kan er ook gebruik worden gemaakt van een zogenaamd Content Delivery Network (CDN). Sinds 2015 is SAPUI5 op het SAP Cloud Platform ook beschikbaar gesteld via een dergelijk CDN, namelijk het Akamai CDN. Het Akamai CDN routeert aanvragen naar de dichtstbijzijnde Akamai server, te weten VS, Duitsland of Australië. De meerdere SAP Cloud data center locaties gecombineerd met de route-optimalisatie geboden door het Akamai CDN zal zorgen dat eventuele vertraging (latency) wordt gereduceerd en de applicatie sneller wordt geladen.

Conclusie

Figuur 9: Voor- en nadelen Fiori on-premise versus Cloud

Samenvattend, kunnen we stellen dat het SAP Cloud Platform een zeer goed alternatief is voor een on-premise SAP NetWeaver Gateway systeem. Met name de flexibiliteit op het gebied van upgrades, de plug & play ervaring voor standaard SAP Fiori applicaties en de performance optimalisatie die mogelijk is zijn voordelen die het SAP Cloud Platform met zich meebrengt. Hier tegenover staat dat het landschap voor een cloud-scenario meer multidisciplinaire inspanning zal vergen aangezien dan een on-premise scenario. Tevens zijn er momenteel meer SAP Fiori apps beschikbaar voor het on-premise scenario dan voor het cloud-scenario. Echter, dit laatste kan overkomen worden middels een down- en upload van de applicatie naar het SAP Cloud Platform.

Bijgaand is een opsomming geplaatst van alle voor- en nadelen benoemd in deze blog.

Voor verdere vragen of informatie over dit onderwerp kunt u contact opnemen met Joost van Poppel. Voor andere vragen op het gebied van SAP Workflow, Fiori, SAP Invoice Management (SIM) of SAP Master Data Governance (MDG) kunt u contact opnemen met Sander van der Wijngaart.

Fiori on-premise versus Fiori Cloud