
Indice
- Come è organizzato il Cockpit
- Sequenza di configurazione della prima settimana
- Subaccount ed entitlement
- Utenti, trust e role collection
- Servizi, istanze e chiavi
- Costruire su BTP
- Scegliere un runtime
- Collegare BTP a S/4HANA e ad altri sistemi
- Gestire BTP giorno per giorno
- Monitoraggio e controllo dei costi
- Automazione e domini personalizzati
- Gli errori che vedo più spesso
- 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.
- Global accountIl suo contratto con SAP e i servizi che ha acquistatoEntitlementIl pool finito a cui attinge ogni subaccount
- 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.
- 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. - Collegare l'identity provider (responsabile della sicurezza). Lo si faccia prima di aggiungere un solo utente.
- Definire le role collection per funzione lavorativa (responsabile della sicurezza), inclusa una role collection admin break-glass.
- Distribuire gli entitlement, prima il minimo (responsabile della piattaforma). Se ne aggiungono altri quando un team dimostra di averne bisogno.
- Installare e configurare il Cloud Connector (team infrastruttura) se BTP deve raggiungere sistemi on-premise.
- Attivare alerting e revisione dell'utilizzo (responsabile della piattaforma). Si decida chi guarda cosa, e con quale frequenza.
- 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:
- Costruirle attorno alle funzioni lavorative, non alle singole persone.
- Tenerle abbastanza specifiche da avere un senso, ma non così granulari da doverne mantenere centinaia.
- Tenere una role collection admin break-glass per le emergenze.
- 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.
| Runtime | Ideale per | Attenzione a |
|---|---|---|
| Cloud Foundry | App Java, Node.js e Python, incluso SAP Cloud Application Programming Model (CAP) | Il default maturo; meno sorprese per la maggior parte dei team |
| Kyma | Microservizi nativi Kubernetes ed estensioni event-driven | Richiede competenze Kubernetes che molti team SAP non hanno |
| ABAP environment | Estensioni ABAP Cloud accanto a S/4HANA | Scelta 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.
| Scenario | Come impostarlo |
|---|---|
| S/4HANA on-premise o Private Edition | Cloud Connector nella sua rete, una destination nel subaccount, poi API OData o SOAP |
| App cloud SAP come SuccessFactors | Destination più Integration Suite o Event Mesh, con estensioni in CAP |
| Sistemi non SAP come Salesforce o Workday | Adapter di Integration Suite, oppure integration flow personalizzati |
| Esporre le proprie API | API 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:
- 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.
- Stato di salute delle applicazioni. Tempi di risposta e tassi di errore per applicazione, dalle viste di Cloud Foundry o Kyma.
- 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.
- Creare subaccount prima di concordare una convenzione dei nomi.
- Assegnare ruoli a singoli individui invece che a role collection e gruppi.
- Far girare servizi di sviluppo su piani dimensionati per la produzione.
- Lasciare l'alerting a dopo il primo blocco.
- 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.
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.




