La manutenzione del database è quell’attività che ogni amministratore Automic sa di dover eseguire regolarmente, ma che continua a rimandare in silenzio — finché i dati di esecuzione, i vecchi report e i messaggi di sistema non hanno gonfiato il database AE. Per anni, la manutenzione del database Automic ha significato ricorrere alle utility locali del database AE o accedere direttamente al database, ed è proprio per questo che è scivolata in fondo alla lista delle cose da fare. In Automic V26 questo ostacolo è stato eliminato: è possibile archiviare, riorganizzare, eliminare e ripulire i dati operativi direttamente dalla prospettiva di amministrazione AWI e dall'API REST AE. Questo articolo fa parte della nostra serie dedicata all'implementazione di Automic V26 e si concentra sul percorso API REST; il video dimostrativo qui sotto mostra le stesse operazioni dall'inizio alla fine.
Cosa è cambiato nella gestione del database Automic nella versione 26
Nelle versioni precedenti, l'archiviazione, la riorganizzazione e lo scaricamento del database AE venivano gestiti tramite le utility autonome di AE DB o intervenendo direttamente sul database. Automic V26 pone queste attività sotto un controllo regolamentato e basato su API: le stesse attività di manutenzione sono ora disponibili tramite l'API REST di AE e la prospettiva di amministrazione AWI, quindi non sono più necessari i file binari delle utility locali o le credenziali dirette del database per eseguirle.
In generale, i dati che si gestiscono sono quelli che Automic definisce "dati operativi": messaggi di sistema, dati di esecuzione (precedentemente denominati "statistiche"), report e commenti. In linea di massima, l'API REST di AE copre cinque operazioni: archiviazione dei dati operativi, creazione di report di revisione, riorganizzazione dei dati operativi, eliminazione dei dati operativi e svuotamento del Cestino.
Il vantaggio concreto è la governance. Gestire la manutenzione tramite l'API REST di AE significa che ogni operazione di archiviazione, riorganizzazione ed eliminazione è una chiamata verificabile e ripetibile, anziché un'utilità eseguita ad hoc sulla workstation di un utente; inoltre, può essere concessa tramite un unico privilegio anziché un accesso a livello di database. Per i patrimoni Automic regolamentati, tale tracciabilità è importante tanto quanto lo spazio liberato nel database.
Privilegi e configurazione da impostare per primi
Prima di eseguire qualsiasi operazione di manutenzione del database Automic tramite l'API REST, è necessario che siano presenti due elementi: i privilegi utente adeguati e le variabili che controllano ciascuna operazione.
- Privilegi. Il
DB_MAINTENANCEprivilegio avvia i processi di archiviazione, riorganizzazione ed eliminazione. Per scaricare i pacchetti di archivio e i rapporti di revisione è inoltre necessarioACCESS_METRICS_ENDPOINT, mentre per leggere o svuotare il Cestino è necessarioRECYCLE_BIN. - Variabili di configurazione nel Client 0. I parametri di archiviazione si trovano
UC_UTILITY_ARCHIVE, i parametri di riorganizzazione inUC_UTILITY_REORG, mentre i parametri di eliminazione si trovano inUC_UTILITY_DB_UNLOAD. Per i report di revisione, la registrazione degli oggetti (OBJECT_AUDIT) deve essere abilitata inUC_CLIENT_SETTINGS. - Percorso di destinazione. L'archivio o il pacchetto di report viene salvato automaticamente nella directory specificata nel file INI di Automation Engine per i sistemi on-premise, oppure nel
values.yamlfile per gli ambienti AAKE (containerizzati). Da lì è possibile trasferirlo dove serve.
Con i privilegi concessi e le variabili configurate una volta, ogni esecuzione successiva è una singola chiamata API. La guida passo passo riportata di seguito mostra queste operazioni in AWI e tramite l'API REST AE: segui attentamente, quindi utilizza le chiamate di riferimento nella seconda metà di questa guida.
Le operazioni di manutenzione tramite l'API REST di AE
Ogni operazione viene avviata nel Client 0 e può essere indirizzata a un singolo client (target_client=100) o tutti i client (target_client=ALL) — non è possibile selezionare un sottoinsieme arbitrario. La maggior parte dei processi restituisce un run_id che si utilizza per recuperare il pacchetto risultante.
Archiviazione dei dati operativi
L'archiviazione raccoglie messaggi di sistema, dati di esecuzione, report e commenti in un file ZIP scaricabile. La si attiva con una richiesta POST, quindi si scarica il pacchetto con l'ID di esecuzione restituito:
POST /ae/api/v1/0/system/clients/archive?target_client=100
→ { "run_id": 1007001 }
GET /ae/api/v1/0/system/clients/archive/1007001
→ (scarica il pacchetto dell'archivio)Con un client REST come Postman, utilizzare l'opzione "Invia e scarica"; con cURL, aggiungere -o per salvare il file su disco. Lo stesso endpoint, chiamato con il metodo reset, cancella il flag di archiviazione.
Creazione di rapporti di revisione
I rapporti di revisione forniscono una cronologia, pronta per l'auditing, delle modifiche apportate a un client: oggetti creati, eliminazioni, trasporti, accessi utente e altro ancora, il che mantiene un ambiente regolamentato conforme. È possibile definire l'ambito di un rapporto per intervallo di date e per tipo di modifica:
POST /ae/api/v1/0/system/clients/revisionreport?target_client=ALL
{
"from": "2026-01-01T00:00:00Z",
"to": "2026-03-31T00:00:00Z",
"types": ["CREA", "ELIMINA", "MOD_OGGETTO", "UTENTE", "TRASPORTO"]
}Se types viene omesso, vengono incluse tutte le categorie di modifica. Il report viene scaricato con il suo run_id, esattamente come un pacchetto di archivio.
Riorganizzazione dei dati operativi
La riorganizzazione dei dati operativi contrassegna i record obsoleti per la cancellazione senza però eliminarli immediatamente. La logica di conservazione combina due impostazioni: una riorganizzazione per i record più vecchi di una soglia in giorni e un conteggio degli ultimi record da conservare. Ad esempio, con la riorganizzazione impostata su 30 e il numero di record da conservare su 5, il processo conserva tutti i dati degli ultimi 30 giorni più i cinque record più vecchi per ogni oggetto.
POST /ae/api/v1/0/system/clients/reorg?target_client=ALLEliminazione dati operativi
Una volta contrassegnati i record, l'eliminazione dei dati operativi li rimuove in modo permanente dal database AE. È un singolo trigger per client o per tutti i client:
POST /ae/api/v1/0/system/clients/deletedata?target_client=TUTTISvuotamento del Cestino
Gli oggetti eliminati vengono spostati nel Cestino invece di scomparire immediatamente. Dal client 0 è possibile elencare il contenuto del cestino di un client e quindi svuotarlo:
GET /ae/api/v1/0/recyclebin?target_client=100
DELETE /ae/api/v1/0/recyclebin?target_client=ALLGli oggetti che contengono ancora dati operativi non archiviati non vengono eliminati; vengono restituiti nella risposta sotto failedObjects. La regola generale è semplice: prima archivia, poi svuota.
Reimpostazione dei flag di archivio e riorganizzazione
Se è necessario rieseguire un ciclo, ad esempio per archiviare record che erano già stati contrassegnati, gli endpoint di archiviazione e riorganizzazione accettano un metodo di reset che cancella il flag corrispondente. Ciò consente di correggere un'esecuzione temporizzata in modo errato senza toccare il database, mantenendo l'intero ciclo di manutenzione all'interno dell'API REST di AE.
Trasforma la manutenzione del database Automic in un'attività pianificata, non in un compito noioso
Poiché ogni operazione è ora una semplice chiamata REST, il passo logico successivo è smettere di eseguirle manualmente. Inserite la sequenza "archiviazione → riorganizzazione → eliminazione" in un flusso di lavoro Automic pianificato, in modo che il database AE venga gestito con una cadenza prevedibile — e includete il Client 0, che raccoglie i log del server e degli agenti ed è facile da dimenticare. Se si preferisce chiamare gli endpoint da uno script, la nuova integrazione Python di Automic V26 consente di invocarli da un processo Python nativo insieme alla logica di automazione esistente. La manutenzione affidabile del database Automic è una delle parti meno affascinanti ma più gravose per il corretto funzionamento di V26.
Un modello sensato consiste nel riorganizzare a intervalli regolari, archiviare prima della cancellazione e svuotare il Cestino una volta che l'archiviazione ha confermato che non è rimasto nulla di non archiviato. Adeguare le soglie di conservazione al volume dei dati è dove risiede la maggior parte del valore: abbastanza aggressivo da mantenere il database snello, abbastanza conservativo da soddisfare la tua finestra di audit.
Questa guida fa parte della nostra serie dedicata all'implementazione della versione Automic V26. Se SAP è un elemento centrale del vostro ambiente, il documento di approfondimento sul supporto di più sistemi da parte di SAP Agent tratta un'altra modifica della versione V26 che vale la pena esaminare prima di procedere all'aggiornamento. Per le specifiche ufficiali, consultate la panoramica sulla versione Automic V26 di Broadcom e la documentazione sulla manutenzione del database 26.0 AE REST API.
Domande frequenti
Quali autorizzazioni sono necessarie per la manutenzione del database Automic tramite l'API REST?
È necessario il privilegio DB_MAINTENANCE per avviare l'archiviazione, la riorganizzazione e l'eliminazione. Per scaricare i pacchetti di archivio e i rapporti di revisione è necessario anche ACCESS_METRICS_ENDPOINT, e per leggere o svuotare il Cestino è necessario il privilegio RECYCLE_BIN.
Funziona sia in ambiente locale che in ambienti AAKE containerizzati?
Sì. Le operazioni sono identiche; cambia solo la posizione di destinazione. Negli ambienti on-premise si imposta la directory dei pacchetti nel file INI di Automation Engine, mentre negli ambienti AAKE (container) si imposta nel file values.yaml.
Quali dati operativi vengono considerati da Automic?
Dati operativi significa messaggi di sistema, dati di esecuzione (precedentemente chiamati statistiche), report e commenti. Questi sono i record che si accumulano durante il funzionamento quotidiano e che la manutenzione è progettata per archiviare, riorganizzare e rimuovere.
Posso eseguire la manutenzione per tutti i clienti contemporaneamente?
Sì. Dal Client 0 puoi puntare a un singolo client con target_client=100 o a ogni client con target_client=ALL. Non puoi selezionare un sottoinsieme arbitrario di client in una singola chiamata.
Come scarico un pacchetto archivio o un report di revisione?
Utilizza l'ID di esecuzione restituito al momento dell'avvio del processo in una successiva richiesta GET. In Postman, utilizza l'opzione "Invia e scarica"; con cURL, aggiungi il flag -o per salvare il file su disco.
Qual è la differenza tra riorganizzare ed eliminare?
La riorganizzazione contrassegna i dati operativi obsoleti per la cancellazione in base alle impostazioni di conservazione, ma li lascia nel database. La cancellazione rimuove poi definitivamente i record contrassegnati. Eseguendo prima la riorganizzazione e poi la cancellazione, si mantiene il controllo su ciò che viene effettivamente eliminato dal database.
Dove è archiviato il pacchetto di archivio o di report?
Quando attivi il processo, un processo in background raccoglie i dati in un file ZIP e li scrive nella directory definita nel file INI di Automation Engine (on-premises) o nel file values.yaml (AAKE). Quindi li scarichi o li trasferisci da lì.
Pianifica il tuo setup di manutenzione V26
Trasferire la manutenzione del database all'API REST è una modifica di piccola entità che offre enormi vantaggi in termini di preparazione alle verifiche e integrità del database; tuttavia, è importante definire correttamente i privilegi, le soglie di conservazione e la pianificazione in base al proprio ambiente specifico. Se desiderate un secondo parere sulla vostra configurazione V26, prenotate una consulenza gratuita con il team di Tricise Automic.
