Nell'introduzione di S/4HANA, nel caso si utilizzino le APP anziché le transazioni classiche, è necessario introdurre un Front End Server (FES).
Il FES può essere in cloud anche se abbiamo l'ERP on premise? Quali i punti di attenzione nel definire un modello autorizzativo in questo contesto?
Ne abbiamo già parlato in un altro post dedicato all'argomento SAP FIORI. Inoltre, è una tematica "calda" in fase di upgrade alla release S/4HANA.
Una delle "novità", esisteva anche nel contesto ECC la possibilità di utilizzare le applicazioni (APP) Fiori, è quella di avere un Front End Server, che permette di gestire la disponibilità di queste applicazioni, collegato ad un Back End Server (BES) dove è possibile recuperare le informazioni di business.
Un esempio? Ho una applicazione che mi permette di approvare degli ordini di acquisto (questa viene attivata nel Front End Server - Launchpad) ma i dati che utilizza questa applicazione risiedono nel Back End Server.
Esistono quindi diversi modelli che possono essere utilizzati a livello architetturale. Ovvero FES e BES sulla stessa macchina. Oppure su macchine diverse. O ancora un unico FES che "serve" più Back End. Chiaramente ogni soluzione deve essere analizzata nel proprio contesto al fine di scegliere quella ideale. Qui i vari scenari "SAP Fiori Deployment Options and System Landscape Recommendation"
Ma il Front End Server può essere anche in Cloud?
Uno dei possibili scenari implementatiti è quello di utilizzare un Front End Server separato. Questo può chiaramente risiedere nella stessa rete del BES (Back End Server) ma può essere anche in Cloud.
Esiste infatti uno specifico servizio nella SAP Business Technology Platform (SAP BTP).
La differenza tra 1 e 2 sopra (premesso che la parte di CF è quella più recente rispetto a Neo) è che nel Neo le APP sono nel servizio stesso del portale.
Mentre in CF ci possono essere due approcci diversi il portale e le APP sono nello stesso repository (Portal e APP) “SAP Fiori Launchpad Module”
oppure disaccoppiare il portale dalle APP, creando potenzialmente n versioni di Portali a sé stanti “Portal site”. Questo secondo approccio viene usato per creare potenzialmente dei portali aziendali.
Di fatto vengono costruiti dei ruoli ai quali vengono associate delle APP (questi ruoli sono poi associati ai SITI). Ed infine agli utenti, tramite le Role Collections.
Gli utenti vedono le APP in base ai gruppi dove sono state inserite queste ultime. Analogamente nel contesto onpremise.