Sei migrato ad S/4HANA ma le performance del sistema non ti soddisfano? Gli utenti hanno lunghi tempi di risposta dal sistema (rispetto al normale oppure rispetto alla precedente release)?
Vediamo quali casi e situazioni si possono verificare e come può essere possibile risolve o prevenire.
Quali problemi di performance possono insorgere?
In generale quando il sistema è lento, possono essere davvero moltissime le cause. Questo tra l'altro può coinvolgere molti "strati" diversi della tecnologia (stack ISO/OSI):
- problemi legati alla rete
- problemi durante l'analisi del traffico da parte di alcuni apparecchi
- problemi di database
- problemi del client
- problemi dell'applicativo stesso (in questo caso S/4HANA)
- e così via
Può quindi non essere immediato analizzare la problematica ed indirizzarla nella maniera corretta. In quanto spesso servono persone di team diversi e può capitare che il problema in realtà non cada in "casa" ad un solo dipartimento ma che la soluzione sia attivarsi su più elementi di diverse parrocchie.
Così come possono insorgere problemi di questo tipo solo in determinati momenti (rendendo ancora più complicata l'individuazione della causa, data dal fatto che può essere difficile replicare facilmente il caso, non sapendo da cosa esso sia originato).
Una nota SAP, costantemente aggiornata, che raccoglie le principali problematiche (e risoluzioni) su questo argomento è la seguente: 2689405 - FAQ: SAP S/4HANA Performance Best Practices - Collective Note per ogni problema viene riportata la nota di riferimento con le indicazioni.
Ma possono le autorizzazioni rappresentare un problema di performance del sistema?
Purtroppo sì (ma non in tutti i casi allo stesso modo). Anche in questo caso, pur considerando solo questo aspetto ci sono diverse casistiche per le quali scelte non corrette possono portare a problemi (più o meno facilmente risolvibili a seguito dell'avvio del sistema).
Nei casi di aggiornamento del sistema in modalità bronwfield l'impatto delle autorizzazioni è sicuramente minore per quanto riguarda le performance. Così come nella maggior parte dei casi di aggiornamenti in modalità bluefield.
Mentre nei casi dove l'aggiornamento della release passa attraverso la modalità greenfield in particolare con l'adozione di SAP FIORI, quindi l'utilizzo di un browser per fruire delle applicazioni, questo aspetto può diventare un problema per le performance. E qui l'aspetto della sicurezza applicativa può indirettamente causare qualche problema.
Ma l'analisi si può complicare dato che sono stati aggiunti ulteriori livelli, per via della tecnologia che viene utilizzata. Una nota molto utile in questo caso è la seguente: 2916959 - Fiori Performance Troubleshooting dove sono mostrati, strato per strato, quali potrebbero essere le principali cause del problema. Queste le principali sezioni della nota
- Classification of Fiori performance issues
- General system aspects
- Trace execution and analysis for web-based applications
- Network
- Distance from end user to Frontend Server
- Browser of the respective device used
- SAPUI5 resource
- SAP GUI for HTML & WebDynpro performance
- Limitations of SAP GUI for HTML
- Fiori Layer
- Fiori Launchpad startup performance*
- Fiori Launchpad Search performance*
- Single Fiori App Performance
Non tutte riguarda aspetti legati alla sicurezza, solo un sottoinsieme. Quelli dove troviamo l'asterisco sopra hanno alcuni possibili impatti.
Quali i punti di utili nel nostro caso quindi:
- Assicurati di essere nella release del componente SAP_UI più aggiornata possibile. In questo componente viene gestita la cache delle applicazioni Fiori, nelle ultime release di SAP è stata notevolmente migliorata (da SAP_UI maggiore o uguale a 7.58)
- Durante i go-live può capire che in caso di qualche mancanza gli utenti non vedano subito le modifiche importante nel sistema produttivo (specialmente lato Fiori) questo può costringere gli amministratori a svolgere un reset della cache. Questa azione, che viene svolta nell'interesse di "far recepire" il prima possibile la modifica segnalata come mancante, dopo averla sistemata ed importata nel sistema produttivo, ha l'effetto collaterale di far ricalcolare (in maniera puntuale o su tutte le utenze) la cache (allungando i tempi di risposta del sistema).
- Il numero di applicazione per ogni catalogo non dovrebbe superare le 100 unità, questo è il suggerimento della SAP. Attenzione, i cataloghi standard SAP potrebbero non essere compliant loro stessi in alcuni casi.
- Sfrutta alcune configurazioni del Fiori Launchpad o Space
- Se devi valutare con quale modalità utilizzare Fiori, utilizza gli space. Purtroppo in questo caso la SAP ha cambiato idea "recentemente". Dapprima esistevano solo i Cataloghi e Gruppi Fiori, poi, dopo un periodo relativamente breve dal rilascio di S/4HANA, questi ultimi, sono stati dichiarati obsoleti a favore degli space (che offrono al momento performance in generale migliori rispetto ai gruppi). Questo ha "causato" che per diverse installazioni effettuato nel costo di S/4HANA, pur essendo relativamente recenti, utilizzino ancora i gruppi, anziché gli space
- Se parti dai cataloghi standard, rimuovi le applicazioni non usate (ma allora conviene partire dagli standard oppure no?), attenzione, su questo aspetto conviene concentrarsi bene lasciando solo le APP necessarie, almeno tra quelle proposte nell'interfaccia
- Limitare il numero di connettori disponibili ed eventualmente impostare un default per la ricerca delle APP. Per questo aspetto nel contesto S/4HANA Onpremise esistono due modalità (che possono essere entrambe attive oppure è possibile scegliere)
- CDS-based Search Models: in questo caso il controllo autorizzativo avviene su oggetto: SDDLVIEW
- Classical Search Models: in questo caso il controllo autorizzativo avviene su oggetto:S_ESH_CONN
In entrambi i casi è importante non inserire il valore (asterisco) * in uno o entrambi gli oggetti sopra, ma autorizzare puntualmente i connettori che dovranno essere effettivamente utilizzati
