Che cos'è il SAP BTP Cockpit? Navigazione, configurazione e controllo dei costi

Il SAP BTP Cockpit è l’interfaccia di amministrazione via browser della SAP Business Technology Platform. Qui si gestiscono global account, directory, subaccount, entitlement, utenti e costi. Chi è responsabile di un landscape BTP svolge qui gran parte del lavoro amministrativo, e la struttura scelta nelle prime settimane è quella con cui si convive per anni.

Questa guida mostra come è organizzato il cockpit, che cosa fanno le singole aree e quali schemi di configurazione evitano gli errori che vediamo più spesso nei progetti BTP.

In sintesi: il SAP BTP Cockpit è l’interfaccia web per amministrare SAP BTP. La gerarchia comprende global account, directory facoltative e subaccount; org e space di Cloud Foundry si trovano all’interno dell’ambiente di un subaccount. Tre elementi decidono se il cockpit resta gestibile: una convenzione di denominazione e una struttura di directory fin dal primo giorno, il trust verso l’identity provider aziendale con role collection mirate e una verifica mensile di entitlement e consumi. Per le attività ripetitive, la btp CLI svolge gli stessi compiti tramite script.

Che cos’è il BTP Cockpit e come è strutturato?

Il cockpit riproduce il modello di account di SAP BTP. Per chi è nuovo alla piattaforma, conviene partire da che cos’è SAP BTP e dove si colloca; questo articolo presuppone che un account esista già.

Global account. Il livello più alto, corrisponde al contratto con SAP. Qui si gestiscono entitlement, dati di consumo e membri del global account. Vi si accede da cockpit.btp.cloud.sap, che reindirizza al cockpit regionale (per l’Europa emea.cockpit.btp.cloud.sap). SAP descrive l’accesso nella documentazione BTP.

Directory. Un livello facoltativo per raggruppare i subaccount per unità di business, progetto o regione. Le directory diventano utili a partire da circa una mezza dozzina di subaccount. Senza di esse, l’account explorer si trasforma in un lungo elenco piatto.

Subaccount. L’unità di lavoro vera e propria. Ogni subaccount ha la propria regione, i propri entitlement e le proprie assegnazioni utente, oltre a uno o più ambienti di runtime: Cloud Foundry, Kyma o ABAP. La maggior parte delle aziende crea subaccount separati per sviluppo, test e produzione.

All’interno dell’ambiente. In un subaccount Cloud Foundry, l’org è suddivisa in space che isolano applicazioni o team. Gli space non sono un quarto livello della gerarchia del cockpit: appartengono all’ambiente Cloud Foundry di un singolo subaccount.

Modificare la gerarchia in un secondo momento è oneroso: spostare applicazioni e istanze di servizio tra subaccount significa ridistribuirle e riconfigurarle. Conviene definire la struttura prima del primo progetto.

Come si naviga nell’account explorer?

Aprendo un global account, la prima vista è l’account explorer. Mostra directory e subaccount con il relativo stato. Da qui è possibile:

• creare ed eliminare subaccount, scegliendo regione, ambiente e descrizione
• organizzare i subaccount in directory
• consultare i dettagli di un subaccount: regione, provider dell’infrastruttura (AWS, Azure o Google Cloud), sottodominio e tenant ID
• vedere quali subaccount sono attivi, in fase di provisioning o sospesi

La navigazione laterale dipende dal punto in cui ci si trova. A livello di global account si vedono entitlement, informazioni su consumi e costi e i membri dell’account. All’interno di un subaccount si trovano l’ambiente (Cloud Foundry o Kyma), il service marketplace, istanze e sottoscrizioni e le impostazioni di sicurezza del subaccount.

Il problema più frequente nei landscape esistenti non è tecnico: subaccount senza convenzione di denominazione. Quando dieci di essi si chiamano «test», «dev2» e «project-x», nessuno sa più che cosa gira dove. Una convenzione come {progetto}-{ambiente}-{regione} non costa nulla il primo giorno e risparmia molto lavoro investigativo in seguito.

Come funzionano gli entitlement e il service marketplace?

Gli entitlement stabiliscono quali servizi e piani un subaccount può utilizzare e in quale misura. Il global account dispone di un pool di entitlement in base al contratto, che viene distribuito ai subaccount come un budget.

Schemi che funzionano:

• Piani di servizio: la maggior parte dei servizi offre più piani. Per sviluppo e test si usa il piano più piccolo adeguato, e il piano adatto alla produzione solo dove serve.
• Quote: alcuni piani hanno quote numeriche, ad esempio la memoria di runtime in Cloud Foundry. Vanno monitorate, affinché un deployment non si blocchi su un limite.
• Assegnazione automatica: le directory possono assegnare automaticamente gli entitlement ai nuovi subaccount, evitando la configurazione manuale di ogni nuovo ambiente.

Il service marketplace è il catalogo all’interno di un subaccount. Elenca i servizi consentiti dagli entitlement e permette di creare istanze o sottoscrizioni. Voci tipiche sono SAP HANA Cloud, SAP Integration Suite, SAP Build, i servizi Destination e Connectivity e Authorization and Trust Management (XSUAA). Come questi servizi si combinano è spiegato nei cinque pilastri di SAP BTP.

Come si gestiscono sicurezza e accessi degli utenti?

La sicurezza è la parte del cockpit che più spesso viene configurata in fretta e poi lasciata com’è. Agisce su due livelli, entrambi descritti da SAP nella guida all’amministrazione della sicurezza.

Configurazione del trust. Collega un identity provider a BTP. L’impostazione predefinita è il SAP ID service. Per tutto ciò che va oltre una prima prova, SAP raccomanda di collegare SAP Cloud Identity Services (Identity Authentication) e di usarlo come proxy verso l’identity provider aziendale, ad esempio Microsoft Entra ID o Okta. Si ottengono così il single sign-on e un unico punto di gestione del ciclo di vita degli utenti.

Role collection. Gruppi di ruoli assegnati a utenti o a gruppi provenienti dall’identity provider. BTP fornisce role collection predefinite come Subaccount Administrator, ed è possibile crearne di proprie. Lo schema che regge nel tempo: role collection che corrispondono ai ruoli del team, non autorizzazioni puntuali per singole persone.

Errori che vediamo regolarmente:

• Tutti ricevono Subaccount Administrator invece di una role collection limitata, il che rende molto più difficili audit e analisi degli incidenti.
• La produzione gira sul SAP ID service predefinito invece che sull’identity provider aziendale.
• Il trust viene configurato in un subaccount e si presume valga ovunque. La configurazione del trust è per subaccount: ognuno ha bisogno della propria.

Come si monitorano i costi nel cockpit?

A livello di global account, il cockpit mostra consumi e costi dell’intero account. SAP illustra le viste nella pagina sul monitoraggio di utilizzo e costi di consumo. Si vedono:

• il consumo rispetto al contratto, ad esempio i cloud credit
• una ripartizione per servizio e per subaccount
• l’andamento nel tempo; i dati vengono aggiornati una volta al giorno, non in tempo reale

Schemi pratici:

1. Verifica mensile. Una revisione mensile fissa individua le tendenze prima che diventino un problema di budget.
2. Indagare sui salti. Una regola empirica utile: se il costo di un servizio aumenta di circa un quinto o più da un mese all’altro, conviene capirne il motivo. Cause tipiche sono istanze di test dimenticate, un’istanza SAP HANA Cloud sovradimensionata o ambienti di sviluppo che nessuno ha spento.
3. Dimensionare correttamente gli ambienti. Sviluppo e test raramente necessitano di piani da produzione.
4. Eliminare i servizi inutilizzati. Le istanze che nessuno usa occupano comunque quota e possono generare costi. Per la maggior parte dei landscape basta un audit trimestrale.

Qual è la differenza tra il cockpit e la btp CLI?

Il cockpit è l’interfaccia grafica: ideale per esplorare, per configurazioni occasionali e per il monitoraggio visivo dei costi. La btp CLI (comando btp) copre la stessa amministrazione degli account da riga di comando; SAP mantiene un riferimento completo dei comandi.

Attività	Cockpit	btp CLI
Configurazione iniziale ed esplorazione	Scelta migliore	Curva di apprendimento più ripida
Configurazione ripetitiva	Lenta, molti clic	Script scritto una volta, eseguito più volte
Pipeline CI/CD	Non adatto	Pensata per questo
Monitoraggio dei costi	Viste grafiche	Output per reporting proprio
Gestione di utenti e ruoli	Più semplice per team piccoli	Migliore per modifiche massive
Tracciabilità	Limitata	Gli script si possono versionare e revisionare

Per la maggior parte dei team valgono entrambi: il cockpit per il monitoraggio e le attività occasionali, la CLI per tutto ciò che si ripete o va automatizzato. Nei nostri progetti BTP scriviamo fin dall’inizio gli script per la configurazione dei subaccount e degli entitlement, perché così il secondo e il terzo ambiente richiedono minuti invece di un pomeriggio di clic.

Chi dovrebbe gestire il landscape BTP?

Il cockpit è solo la superficie di amministrazione; ciò che conta è il landscape che sta dietro: estensioni, integrazioni e flussi di dati tra ERP e applicazioni CX. In Spadoom un unico team gestisce S/4HANA Public Cloud, le applicazioni SAP CX e il livello BTP che le collega. Per questo impostiamo struttura degli account, trust e controllo dei costi come parte dell’architettura, non a posteriori. Perché questo conta è spiegato in un unico partner per Cloud ERP e CRM, mentre il confronto tra i partner di sviluppo BTP in Svizzera si trova nella nostra panoramica dei partner di sviluppo SAP BTP.

Se il cockpit è cresciuto più in fretta della sua struttura, il team Spadoom è a disposizione: una verifica di gerarchia, trust ed entitlement richiede di solito pochi giorni.

Domande frequenti

Come si accede al SAP BTP Cockpit?

Si apre cockpit.btp.cloud.sap e si effettua l’accesso; si viene reindirizzati al cockpit regionale, per l’Europa ad esempio emea.cockpit.btp.cloud.sap. Compaiono quindi tutti i global account di cui si è membri. Gli utenti senza appartenenza a un global account non vedono questa selezione.

È possibile gestire più ambienti da un unico cockpit?

Sì. Ogni subaccount può attivare Cloud Foundry, Kyma o l’ambiente ABAP, e il cockpit li gestisce tutti. La navigazione si adatta all’ambiente del subaccount aperto: un subaccount Cloud Foundry mostra org e space, un subaccount Kyma la dashboard di Kyma.

Con quale frequenza si aggiornano i dati di consumo?

I dati di consumo e di costo del global account vengono aggiornati una volta al giorno, quindi non si tratta di una vista in tempo reale. Per lo stato attuale di un deployment conviene controllare direttamente le istanze di servizio e le applicazioni nel subaccount.

Che cosa succede se gli entitlement si esauriscono?

Non è possibile creare altre istanze di servizio per quel piano finché non si libera quota (ad esempio eliminando istanze inutilizzate o spostando quota tra subaccount) oppure si acquista capacità aggiuntiva da SAP. La quota viene assegnata per subaccount, quindi è bene verificarne la distribuzione prima di ordinarne altra.

Meglio il SAP ID service o il proprio identity provider?

Il SAP ID service è l’impostazione predefinita ed è sufficiente per una prima configurazione o una prova personale. Per i subaccount condivisi di sviluppo, test e produzione conviene collegare SAP Cloud Identity Services (Identity Authentication) e usarlo come proxy verso l’identity provider aziendale, ad esempio Microsoft Entra ID o Okta. Si ottengono così il single sign-on e un unico punto di gestione del ciclo di vita degli utenti.