Dopo l’introduzione su come impostare ed avviare il tool SAP S/4HANA Readiness check, in questa seconda puntata della mini-serie “S/4HANA”, vado a trattare un altro tema fondamentale che è d’obbligo affrontare quando si mette in cantiere un progetto di passaggio da SAP ERP / ECC 6.0 ad un sistema SAP S/4HANA:
la revisione completa del codice ABAP Custom.
Nella prima parte del blog (“Prevenire è meglio che curare: avvia per tempo SAP S/4HANA Readiness Check!”) abbiamo visto come il SAP Readiness Check for SAP S/4HANA già introduca – per quanto a livello generale – le categorie di adeguamenti da apportare al codice custom.
Tuttavia, il Readiness Check non fornisce il dettaglio degli oggetti impattati da tali modifiche.
Per recuperare tale informazione, è necessario ricorrere a strumenti aggiuntivi.
Vediamo insieme quali…
Qui di seguito vado a descrivere nell’ordine:
- Le diverse tipologie di modifiche per il codice ABAP custom
- Il tool suggerito da SAP per l’analisi del codice
- Il landscape di sistemi da impostare per l’analisi
- I 5 steps per l’esecuzione dell’analisi e la raccolta dei risultati
Le tipologie di modifiche al codice ABAP custom
Prima di descrivere nel dettaglio come analizzare il proprio codice custom, occorre essere consapevoli di come il passaggio a SAP S/4HANA abbia un notevole impatto sulla struttura dei programmi custom esistenti.
Nell’ottica di un progetto di transizione ci sono tre aree principali di interventi da preventivare sul codice ABAP custom:
- Modifiche funzionali contestuali all’adozione di HANA come Database
- Modifiche “dettate” dal nuovo modello dati semplificato del sistema SAP S/4HANA rispetto al modello tradizionale SAP ERP / ECC
- Modifiche volte ad ottenere la massima performance nell’esecuzione dei programmi.
Le prime due tipologie di modifiche sono – ahinoi – obbligatorie, e non trascurabili, se vogliamo far sì che report custom continuino a funzionare regolarmente, una volta atterrati sulla nuova piattaforma SAP S/4HANA.
La terza area di intervento è invece solo opzionale, ma è caldamente raccomandata.
A prima vista, può sembrare di trovarsi di fronte ad uno sforzo “titanico”, specialmente per quei clienti SAP che fanno un ricorso massiccio a programmi Z*…
Tuttavia – nella parte conclusiva del blog – vedremo come sia possibile limitare l’elenco degli oggetti custom da adeguare dal punto di vista delle performance ai soli oggetti effettivamente utilizzati nel sistema.
L’ABAP Test Cockpit (ATC): il nostro tool per l’analisi.
Lo strumento di riferimento per analizzare il codice custom è l’ABAP Test Cockpit (ATC).
Si tratta di un buon “vecchio” tool SAP Standard, ideato per eseguire test automatici sul del codice ABAP, che è stato più recentemente esteso per analizzare il codice custom anche dal punto di vista della sua funzionalità su un sistema SAP S/4HANA.
Gli step necessari per il suo corretto utilizzo sono ben descritti dalle due note OSS SAP:
2364916 – Recommended SAP Notes for using ATC to perform remote analysis
2436688 – Recommended SAP Notes for using S/4HANA custom code checks in ATC
Ora, una volta identificato il tool, vediamo quali sono i requisiti di sistema, o meglio del panorama di sistemi richiesti per condurre l’analisi del codice…
Il Set-Up degli Ambienti
È fondamentale sottolineare che per effettuare l’analisi del codice custom del sistema ECC di partenza è necessario disporre di un ulteriore sistema (chiamato Evaluation System), con release NetWeaver (SAP_BASIS) 7.51 o superiore.
(Non è tuttavia obbligatorio che l’Evaluation System abbia un particolare componente applicativo, è sufficiente un sistema SAP NetWeaver nudo e crudo).
L’architettura per effettuare l’analisi sarà, quindi, la seguente:
Il sistema ECC da scegliere come oggetto dell’analisi (il cosiddetto Checked System) dovrebbe essere – possibilmente – il sistema di Sviluppo del Landscape che si intende convertire a SAP S/4HANA.
Questo per essere certi di condurre l’analisi su tutto il codice custom, incluso quello non ancora rilasciato in produzione e/o negli ambienti di test.
Sul Checked System identificato andranno inoltre installate le seguenti note:
2485231 – Remote ATC Checks of Modifications and Enhancements
2270689 – RFC Extractor for performing static checks
2190065 – ATC/CI: Remote Code Analysis – Object Provider Stub
2220902 – ATC/CI: No Check Possible for Some Y-/Z-packages
Sull’Evaluation System occorrerà poi installare diverse note OSS, in base alla release NetWeaver e al Support Package installato. Le due note citate in precedenza (la 2364916 e la 2436688) riportano nel dettaglio la lista di tutte le ulteriori note richieste.
Ad ogni modo per evitare di dover implementare troppe note, si raccomanda di installare come Evaluation system un SAP_BASIS 7.51 SP05 o superiore, oppure un SAP_BASIS 7.52 SP01 o superiore.
Hai definito il tuo landscape e installato tutte le note?
Bene! Possiamo finalmente procedere con l’analisi del codice ABAP.
I 5 steps per l’analisi del codice custom:
Ora non resta che seguire 5 steps in sequenza per ottenere il risultato dell’analisi e portare finalmente alla luce tutti i gap che ci separano dall’avere un codice ABAP ottimizzato a regola d’arte per HANA e S/4:
Definire una connessione RFC tra Evaluation e Checked System.
Scaricare il SAP S/4HANA Simplification Database dal Service Marketplace di SAP.
Installare il Simplification Database sull’Evaluation System.
Definire la customizzazione tecnica dell’ATC sull’Evaluation System
Eseguire la variante S4HANA_READINESS_REMOTE tramite ATC
Approfondiamoli uno ad uno nel dettaglio.
Step #1: Definizione della connessione RFC tra Evaluation System e Checked System.
Come primo step, sarà necessario definire una connessione RFC tra Evaluation System e Checked System, è raccomandato definire una Trusted RFC Connection tra i due sistemi.
In alternativa, si può optare per una connessione RFC tradizionale, con utente RFC che abbia il ruolo autorizzativo SAP_SATC_ADMIN.
Maggiori dettagli per definire la connessione tra Evaluation System e Checked System sono disponibili al seguente link: Setting up RFC Communications Between the ATC Master System and Satellite Development Systems
Step #2: Download del SAP S/4HANA Simplification Database dal SAP Service Marketplace.
Il Simplification Database contiene tutti i Simplification Items che SAP rende disponibili con ogni nuova versione di SAP S/4HANA.
Al momento in cui scrivo, l’ultima release SAP S/4HANA onPremise è la 1709 Feature Pack Stacks 01 (FPS01) e il Simplification Database è aggiornato alla versione Content Patch 6:
È possibile scaricarla seguendo i passaggi definiti nella seguente nota:
2241080 – SAP S/4HANA: Content for checking customer specific code
- Go to https://support.sap.com/swdc
- Select “Software Downloads”
- Search for Component “CCMSIDB” (select “Downloads” and enter CCMSIDB in the search area of the screen)
- Download the displayed “Simplification Database Content”
Step #3: L’installazione del Simplification Database sull’Evaluation System
Sempre seguendo le indicazioni della nota 2241080, è possibile installare il Simplification Database sull’Evaluation System utilizzando la transazione SYCM:
Nel popup, si dovrà selezionare il file zip precedentemente scaricato.
E se tutto è andato correttamente, sarà infine possibile visualizzare il Simplification Database:
Step #4: La Customizzazione Tecnica dell’ATC sull’Evaluation System
Come prima cosa, è necessario definire il ruolo dell’Evaluation System come sistema dove gli ATC Checks sono elaborati a partire dagli Object Providers.
Stiamo in pratica dicendo che il sistema non analizza il solo il codice ABAP locale, ma tutto il codice fornito in input da diversi providers collegati al sistema centrale.
Il sistema ECC che stiamo analizzando andrà quindi configurato come provider.
Per fare ciò, lanciamo la transazione ATC e selezioniamo il nodo “System Role”:
Nella schermata successiva selezioniamo “ATC Checks by Object Providers Only” e salviamo:
Una volta definito il ruolo ATC del sistema, andremo a configurare il sistema ECC (Checked System) come ATC provider: sempre dalla transazione ATC selezioniamo il nodo “Object Providers”:
Nella maintenance view successiva sarà necessario definire:
- Un “System Group” – Un System Group definisce un gruppo di sistemi con la stessa release;
- Un “Object Provider” – Sarà il nostro sistema ECC che vogliamo analizzare
Inserire un System Group (e.g. 702 se stiamo analizzando sistemi ECC con NetWeaver 702):
Nell’Object Provider dovremo agganciare in nome della connessione RFC precedentemente definita nel paragrafo 1: “Definizione della connessione RFC tra Evaluation System e Checked System”:
Step #5: Il Lancio della Variante S4HANA_READINESS_REMOTE tramite ATC e i Risultati
Una volta definita la customizzazione per l’ATC, possiamo schedulare la nostra analisi via RFC che punta sul sistema ECC sotto esame.
Sempre dalla transazione ATC, selezioniamo il nodo “Schedule Runs”:
Selezioniamo il bottone “Create”:
E inseriamo i seguenti dati:
- Come Object Provider, l’ID che abbiamo creato nello step precedente.
- Come Variante, la variante standard di SAP S4HANA_READINESS_REMOTE
- Per identificare gli oggetti che saranno verificati:
- Lasciamo attivo il tab “Checkable Namespaces”.
- Marchiamo il radio-button “By Query”.
- Inseriamo i valori Z* e Y* nel campo “Package”.
E’ importante notare che qualora avessimo dei namespaces customer dedicati (tipo /XYZ/) che vogliamo sottoporre all’analisi, questi dovranno essere definiti tramite transazione SE03 anche sull’Evaluation System.
È anche possibile selezionare gli oggetti tramite Object Sets definiti nel sistema remoto, in questo caso sarà necessario definire l’Object Set tramite transazione SCI sul sistema ECC.
Una volta inseriti i valori suddetti, salviamo la nostra configurazione.
Dopo aver salvato la nostra configurazione, possiamo schedularla selezionando il bottone “Schedule”:
Eseguiamo l’analisi e monitoriamone il progresso selezionando il nodo “Monitor and Control Runs” della transazione ATC:
Una volta completata, possiamo verificare i risultati cliccando sul bottone “Results”:
I findings trovati sono divisi per tipologia e il numero è organizzato per priorità d’intervento:
Facendo doppio click su ogni tipologia vengono mostrati tutti gli oggetti impattati e, tramite ulteriore doppio click, è possibile navigare fino al punto di codice che ha determinato l’errore.
Informazioni dettagliate sulla tipologia dei checks, sono disponibili analizzando la variante S4HANA_READINESS_REMOTE tramite transazione SCI:
Come dicevamo all’inizio del blog, ci sono due tipologie di errori fondamentali:
- Errori funzionali per i quali il codice non funzionerebbe più su un sistema SAP con database HANA
- Errori relativi al Simplification Database
Gli errori funzionali possono fare riferimento a una delle seguenti sottocategorie:
- Critical Statements: ad esempio utilizzo di SQL nativo e non OpenSQL
- Use of ADBC Interface: le Interfacce ADBC sono un’altra tipologia di oggetti che usano SQL nativo
- Search DB Operations in Pool/Cluster Tables: in HANA, le tabelle Cluster e Pool sono rese transparenti
- Search problematic statements for result of SELECT/OPEN CURSOR without ORDER BY: richiesto per limitare errori dovuti all’assunzione che una operazione di SELECT ritorni dati ordinati
- Find ABAP Statement Patterns: utilizzo di funzioni come DB_EXISTS_INDEX o DD_INDEX_NAME, in quanto in HANA parecchi indici non sono più utilizzati
Gli errori relativi al Simplification Database sono, invece, categorizzati in:
- S/4HANA: Field length extensions: esempio tipico è dovuto al fatto che il dominio per il campo codice materiale in SAP S/4HANA passa da 18 caratteri a 40
- S/4HANA: Search for database operations: vengono verificate operazioni SQL (tipo INSERT o MODIFY) su tabelle standard che nel modello dati di SAP S/4HANA sono sostituite da view
- S/4HANA: Search for usages of simplified objects : viene verificato l’utilizzo di oggetti dictionary o repository non più disponibili su SAP S/4HANA
- S/4HANA: Search for ABAP Dictionary enhancements: viene verificata la creazione di strutture append su tabelle o view standard semplificate
- S/4HANA: Search for base tables of ABAP Dictionary views : viene verificato l’utilizzo di tabelle standard semplificate all’interno di view custom
Step # 6: Eseguire i controlli relativi alle performance (Optional)
Come abbiamo introdotto all’inizio del blog, accanto ai controlli relativi alla correttezza funzionale e al Simplification Database, è possibile analizzare il codice custom anche dal punto di vista delle performance. Per ottenere questa analisi sarà necessario ripetere gli step indicati nel paragrafo “Eseguire la variante S4HANA_READINESS_REMOTE tramite ATC“.
Si dovrà sostituire la variante verificata con PERFORMANCE_DB:
Generalmente i controlli relativi alle ottimizzazioni dal punto di vista delle performance riportano il maggior numero di findings.
Per limitare l’effort dovuto alla loro ottimizzazione, SAP raccomanda di attivare il SQLMonitor (transazione SQLM) in produzione, per un tempo di almeno 4 settimane, al fine di ridurre l’elenco degli oggetti da ottimizzare ai soli oggetti effettivamente utilizzati a sistema.
La nota 1885926 – ABAP SQL monitor introduce e descrive l’uso del SQL Monitor.
Conclusioni
Siamo giunti alla fine di questo lungo Blog in due parti che tratta il tema della preparazione del sistema ECC al passaggio alla nuova piattaforma S/4HANA, mediante l’uso degli strumenti che SAP mette a disposizione, vale a dire il SAP S/4HANA Readiness System Check e l’ABAP Test Cockpit (ATC) per la revisione del codice custom.
Non resta che “rimboccarsi le maniche” e procedere a testare subito il grado di prontezza del Tuo sistema SAP ERP / ECC.