Vai al contenuto

Padroneggiare il SAP BTP Cockpit: semplici passaggi che chiunque può seguire

Il SAP BTP Cockpit è il posto da cui gestisce ogni servizio cloud SAP che possiede. Ecco come accedere, configurarlo nell'ordine giusto ed evitare gli errori che costano settimane ai team.

Schermata di login del SAP BTP Cockpit accanto a un robot umanoide bianco su sfondo neon
Indice
  1. Come è organizzato il Cockpit
  2. Sequenza di configurazione della prima settimana
  3. Subaccount ed entitlement
  4. Utenti, trust e role collection
  5. Servizi, istanze e chiavi
  6. Costruire su BTP
  7. Scegliere un runtime
  8. Collegare BTP a S/4HANA e ad altri sistemi
  9. Gestire BTP giorno per giorno
  10. Monitoraggio e controllo dei costi
  11. Automazione e domini personalizzati
  12. Gli errori che vedo più spesso
  13. Domande frequenti

Il SAP Business Technology Platform (BTP) Cockpit è la console web da cui si gestisce l'ambiente cloud SAP: account, servizi, utenti, sicurezza, applicazioni distribuite e costi. Se amministra BTP, ci distribuisce applicazioni o ne approva il conto, questa è la schermata in cui passerà il suo tempo.

Per entrare, apra il gateway regionale della sua regione: https://emea.cockpit.btp.cloud.sap, https://amer.cockpit.btp.cloud.sap oppure https://apac.cockpit.btp.cloud.sap (SAP Learning). Serve un ID utente SAP; il suo amministratore può crearlo. Gli account trial usano https://cockpit.hanatrial.ondemand.com/trial/ e durano fino a 90 giorni, con un'estensione necessaria dopo 30 (SAP Developers).

Poi imposti tutto nell'ordine che segue. La prima volta ci ho messo giorni a capirlo. La maggior parte dei guai è venuta dal fare il passaggio quattro prima del passaggio uno.

Tutto sta in una gerarchia. Il global account è il suo contratto con SAP e contiene il pool di servizi che ha acquistato. Le directory raggruppano i subaccount, per esempio per business unit. I subaccount sono il luogo in cui si lavora: ciascuno ha una regione, un ambiente come Cloud Foundry o Kyma, i propri utenti e le proprie istanze di servizio.

Come è organizzato un global account BTPOgni subaccount attinge a un unico pool finito. Concordi i nomi e la suddivisione prima di creare il primo.
  1. Global accountIl suo contratto con SAP e i servizi che ha acquistato
    EntitlementIl pool finito a cui attinge ogni subaccount
  2. DirectoryRaggruppa i subaccount, per esempio per business unit
  • Finance-DevSviluppo, con piani gratuiti o piccoli
  • Finance-TestTest, con utenti e role collection propri
  • Finance-ProdProduzione, con gli alert configurati prima del go-live

BTP in sé copre quattro aree: sviluppo e automazione delle applicazioni, integrazione, dati e analytics, e AI. Le incontrerà tutte e quattro nel Cockpit, ma la maggior parte dei programmi parte dall'integrazione e dalle estensioni di S/4HANA.

Questo è l'ordine che seguo su un nuovo global account. Ogni passaggio ha un responsabile naturale.

  1. Concordare la struttura dei subaccount e la convenzione dei nomi (responsabile della piattaforma). Sviluppo, test e produzione per ogni area, per esempio Finance-Dev, Finance-Test, Finance-Prod.
  2. Collegare l'identity provider (responsabile della sicurezza). Lo si faccia prima di aggiungere un solo utente.
  3. Definire le role collection per funzione lavorativa (responsabile della sicurezza), inclusa una role collection admin break-glass.
  4. Distribuire gli entitlement, prima il minimo (responsabile della piattaforma). Se ne aggiungono altri quando un team dimostra di averne bisogno.
  5. Installare e configurare il Cloud Connector (team infrastruttura) se BTP deve raggiungere sistemi on-premise.
  6. Attivare alerting e revisione dell'utilizzo (responsabile della piattaforma). Si decida chi guarda cosa, e con quale frequenza.
  7. Mettere tutto per iscritto fuori dal Cockpit (architetto). Struttura, regole sui nomi, suddivisione degli entitlement e le ragioni di ciascuna scelta.

Subaccount ed entitlement

È qui che la maggior parte dei team crea un pasticcio che si trascina per anni.

Una volta ho lavorato con un cliente che aveva più di 50 subaccount con nomi casuali, e nessuno riusciva a trovare niente. Sbrogliare la matassa a progetto in corso è doloroso. Dedichi un giorno a mappare la struttura su carta, prima. Se lavora in più regioni, replichi la struttura in ciascuna e usi le etichette per raggruppare i subaccount collegati.

Gli entitlement decidono quali servizi può usare ogni subaccount, e in che misura. Il suo global account ha un pool finito. Io parto dal minimo e aumento quando serve, e questo approccio ha fatto risparmiare ai miei clienti migliaia di dollari in servizi inutilizzati. Molti servizi hanno un piano gratuito, che basta per i test.

Utenti, trust e role collection

Se la sua azienda ha già un identity provider come Microsoft Entra ID o Okta, non gestisca a mano gli utenti BTP. La strada raccomandata da SAP è un tenant SAP Cloud Identity Services, collegato al subaccount in Security > Trust Configuration. Quel tenant fa poi da proxy verso l'identity provider aziendale. Il trust può essere configurato in automatico con OpenID Connect. L'autenticazione a due fattori e le policy di accesso stanno così in un unico posto.

Le role collection sono raggruppamenti di ruoli che si assegnano a utenti o gruppi. Il mio approccio:

  1. Costruirle attorno alle funzioni lavorative, non alle singole persone.
  2. Tenerle abbastanza specifiche da avere un senso, ma non così granulari da doverne mantenere centinaia.
  3. Tenere una role collection admin break-glass per le emergenze.
  4. Rivedere le assegnazioni ogni trimestre. Le persone cambiano mansione e si tengono i vecchi accessi.

Servizi, istanze e chiavi

Per creare un'istanza di servizio, apra Services > Service Marketplace nel subaccount, scelga il servizio e un piano. Il piano controlla sia le funzionalità sia il costo. Salvi le impostazioni scelte in un posto fuori dal Cockpit; le serviranno quando qualcosa si rompe.

Colleghi (bind) l'istanza alla sua applicazione e BTP inietta le credenziali. Per strumenti esterni che non sono applicazioni BTP, crei una service key. Dia alle chiavi il nome di chi le usa, come jenkins-deployment, non key1.

Scegliere un runtime

Il Cockpit offre tre ambienti principali. Scelga tenendo davanti le competenze del suo team.

RuntimeIdeale perAttenzione a
Cloud FoundryApp Java, Node.js e Python, incluso SAP Cloud Application Programming Model (CAP)Il default maturo; meno sorprese per la maggior parte dei team
KymaMicroservizi nativi Kubernetes ed estensioni event-drivenRichiede competenze Kubernetes che molti team SAP non hanno
ABAP environmentEstensioni ABAP Cloud accanto a S/4HANAScelta naturale per gli sviluppatori ABAP; usa solo API rilasciate

Ho visto progetti ritardare di mesi perché gli sviluppatori hanno dovuto imparare un ambiente che corrispondeva al piano architetturale ma non alla loro esperienza. Il runtime tecnicamente migliore, su cui il suo team non sa costruire, è la scelta peggiore.

Per distribuire su Cloud Foundry, si descrive l'app in un manifest.yml (memoria, istanze, buildpack, variabili d'ambiente), poi la si carica con la CF CLI o con una pipeline. Cloud Foundry rileva il buildpack, collega i servizi e configura le route.

Collegare BTP a S/4HANA e ad altri sistemi

La maggior parte del lavoro su BTP è integrazione. Questi sono gli schemi che imposto più spesso.

ScenarioCome impostarlo
S/4HANA on-premise o Private EditionCloud Connector nella sua rete, una destination nel subaccount, poi API OData o SOAP
App cloud SAP come SuccessFactorsDestination più Integration Suite o Event Mesh, con estensioni in CAP
Sistemi non SAP come Salesforce o WorkdayAdapter di Integration Suite, oppure integration flow personalizzati
Esporre le proprie APIAPI Management in Integration Suite: progettare, pubblicare, monitorare

Il Cloud Connector apre un tunnel in uscita verso BTP, quindi non servono regole firewall in ingresso. Esponga solo i sistemi e i percorsi URL di cui BTP ha davvero bisogno. Se l'integrazione è il suo uso principale, il mio articolo su SAP CPI approfondisce le scelte di progettazione.

Il Cockpit conserva il cosa. Il perché non lo conserva mai. Quella parte la scriva lei.

Monitoraggio e controllo dei costi

Imposti il monitoraggio prima che serva. Io controllo le mie dashboard ogni mattina con il caffè. È diventato un rito, e mi ha salvato da più di un «perché il sistema è fermo?».

Cosa configurare:

  1. Alert. Il servizio SAP Alert Notification invia eventi di piattaforma e di applicazione via e-mail, Slack o al suo strumento di alerting. La mia configurazione abituale è l'e-mail per le app critiche e un webhook Slack per tutto ciò che non può fermarsi.
  2. Stato di salute delle applicazioni. Tempi di risposta e tassi di errore per applicazione, dalle viste di Cloud Foundry o Kyma.
  3. Utilizzo e costi. Usage Analytics in ogni subaccount, e Costs and Usage a livello di global account. I valori di utilizzo si aggiornano ogni 24 ore.

Elimini ogni mese le istanze di servizio inutilizzate. Riduca gli spazi di sviluppo fuori dall'orario di lavoro. Controlli il consumo degli entitlement prima di rinnovare, perché le allocazioni inutilizzate sono una fonte comune di spesa eccessiva.

Automazione e domini personalizzati

Cliccare nel Cockpit non scala. L'interfaccia a riga di comando di BTP (btp CLI) e le API della piattaforma possono automatizzare quasi tutto ciò che fa l'interfaccia: creare subaccount, assegnare entitlement, predisporre gli sviluppatori.

In un incarico mi servivano gli ambienti per 12 nuovi sviluppatori. Invece di cliccare nel Cockpit tutto il giorno, ho lanciato il mio script e sono andato a prendere un caffè. Quando sono tornato, era tutto pronto. Automatizzare le distribuzioni ha ridotto i tempi di configurazione dell'80% in un incarico, e collegare le service key e la CF CLI a una pipeline ha portato la distribuzione da ore a minuti.

I domini personalizzati valgono la fatica per le app rivolte agli utenti. Si configurano tramite il servizio SAP Custom Domain e non da un menu del Cockpit. In un progetto per un cliente, i dirigenti hanno notato subito l'aspetto più professionale.

  1. Creare subaccount prima di concordare una convenzione dei nomi.
  2. Assegnare ruoli a singoli individui invece che a role collection e gruppi.
  3. Far girare servizi di sviluppo su piani dimensionati per la produzione.
  4. Lasciare l'alerting a dopo il primo blocco.
  5. Non documentare la struttura degli account e le ragioni che la sorreggono. Il Cockpit conserva il cosa, mai il perché.

Bloccato su un errore specifico? La mia guida ai problemi del BTP Cockpit copre quelli più comuni. La guida al clean core spiega dove si collocano le estensioni BTP in un programma S/4HANA.

A cosa serve il SAP BTP Cockpit?

È la console di amministrazione web di SAP Business Technology Platform. Serve a creare subaccount, distribuire entitlement, gestire utenti e trust, creare istanze di servizio, distribuire e monitorare applicazioni e tenere traccia di utilizzo e costi.

Qual è l'URL di login del SAP BTP Cockpit?

Usi il gateway della sua regione: https://emea.cockpit.btp.cloud.sap per Europa, Medio Oriente e Africa, https://amer.cockpit.btp.cloud.sap per le Americhe oppure https://apac.cockpit.btp.cloud.sap per l'Asia-Pacifico. Gli account trial usano https://cockpit.hanatrial.ondemand.com/trial/. Per accedere serve un ID utente SAP.

Come devo strutturare i subaccount in SAP BTP?

Separi sviluppo, test e produzione in subaccount distinti fin dall'inizio, e li chiami in modo che area e fase siano evidenti, come Finance-Dev e Finance-Prod. Le organizzazioni più grandi aggiungono directory per business unit. Lo pianifichi prima su carta; la struttura è difficile da cambiare quando i servizi sono già in esecuzione.

Quali sono i quattro pilastri di SAP BTP?

SAP raggruppa BTP in sviluppo e automazione delle applicazioni, integrazione, dati e analytics, e intelligenza artificiale. La maggior parte dei programmi parte dall'integrazione e dalle estensioni di S/4HANA, poi aggiunge casi d'uso di dati e AI quando la piattaforma è stabile.

Come collego il mio identity provider a SAP BTP?

Configuri un tenant SAP Cloud Identity Services e stabilisca il trust con il suo subaccount in Security > Trust Configuration; OpenID Connect può farlo in automatico. Poi colleghi a quel tenant il suo identity provider aziendale, come Microsoft Entra ID o Okta. Utenti e autenticazione a due fattori vengono così gestiti in un unico posto.

Quale runtime BTP devo scegliere: Cloud Foundry, Kyma o ABAP environment?

Lo abbini al suo team. Cloud Foundry si adatta alle app Java, Node.js e Python ed è il default più sicuro. Kyma si adatta ai microservizi nativi Kubernetes ma richiede competenze Kubernetes. L'ABAP environment si adatta agli sviluppatori ABAP che costruiscono estensioni clean core accanto a S/4HANA.

Come collego SAP BTP a un sistema SAP on-premise?

Installi il Cloud Connector all'interno della sua rete. Apre un tunnel sicuro in uscita verso BTP, quindi non servono modifiche al firewall in ingresso. Esponga solo i sistemi e i percorsi di cui BTP ha bisogno, verifichi la connessione in Connectivity nel subaccount, poi crei le destination che le sue app e i suoi integration flow richiamano. Testi l'intero percorso prima della produzione.

Noel D'Costa

Scritto da

Noel D'Costa

25 anni di programmi ERP SAP e Oracle nei settori aviazione, pubblica amministrazione, finanza, retail e manifatturiero. Formazione in finanza. Aiuto i team di leadership a definire con onestà il perimetro delle trasformazioni, a recuperare i programmi in difficoltà e a costruire sistemi che superano il primo anno in produzione.

Il prossimo passo

Sta gestendo un programma ERP in questo momento?

Se questo articolo tocca un programma che sta seguendo in questo momento, una conversazione di 30 minuti di solito porta più lontano di un'altra settimana di analisi interna.