Marzo 2019
Fissato per il 12 aprile il rilascio di CMDBuild 3.0
Fra una decina di giorni sarà rilasciato CMDBuild 3.0.
Dopo due anni di lavoro di un team dedicato composto da progettisti e sviluppatori la nuova versione 3.0 sarà finalmente disponibile il prossimo 12 aprile.
Come sapete la nuova versione è di fatto un nuovo prodotto, con una interfaccia utente completamente riscritta, che mantiene tutte le logiche di configurazione precedenti estendendole con diverse importanti nuove funzionalità lato server.
Gli obiettivi che ci eravamo dati, e che crediamo di avere pienamente raggiunto, erano quelli di adeguare l’interfaccia utente ai nuovi paradigmi del web design, di garantire prestazioni elevate agli operatori (anche con la disponibilità di un nuovo motore di workflow), di poter utilizzare il sistema in modalità multitenant e di superare alcune limitazioni nella personalizzazione degli eventi e del layout grafico in fase di consultazione e aggiornamento dei dati.
Attendiamo ora le conferme più importanti da parte di chi già utilizza CMDBuild e migrerà nelle prossime settimane alla nuova versione.
La migrazione dalla versione 2.5 alla versione 3.0 sarà garantita dal meccanismo del patch manager già presente nelle versioni precedenti, salvo operazioni effettuate manualmente nel database (scrittura di trigger, funzioni, ecc) che potranno richiedere interventi adeguativi specifici.
E’ stata temporaneamente esclusa per esigenze di tempo dalla versione 3.0 la funzionalità di configurazione di dashboard, sarà ripristinata in una successiva versione 3.x.
Nei prossimi mesi usciranno nuove versioni sia per attività di bug fix che per lo sviluppo di nuove funzioni. E’ già pianificata per il prossimo mese di giugno una versione 3.1 per i cui contenuti vi rimandiamo alla notizia successiva.
CMDBuild 3.0 uscirà con i manuali più importanti già disponibili (Overview Manual, Administrator Manual e User Manual), gli altri seguiranno in base ai tempi tecnici di preparazione.
Per la roadmap di migrazione di CMDBuild READY2USE e openMAINT si rimanda al precedente numero della newsletter.
In preparazione CMDBuild 3.1
Le funzionalità previste per CMDBuild 3.x non si esauriranno con la versione 3.0, ma proseguiranno secondo una roadmap che si svilupperà nei prossimi mesi / anni.
Il primo rilascio programmato sarà CMDBuild 3.1, pianificato per il prossimo mese di giugno.
CMDBuild 3.1 includerà:
- implementazione di un nuovo meccanismo per l’import / export di dati tramite file CSV;
- nuovi automatismi nella modifica delle schede dati;
- bug fix.
Il nuovo meccanismo per l’import / export di dati tramite file CSV consentirà di:
- configurare uno o più template (lista di colonne e mappatura sul modello dati di CMDBuild) per l’import e l’export dei dati relativi ad una data classe;
- eseguire le operazioni in modo batch automatico;
- importare file CSV in modalità “merge”, eseguendo quindi in automatico le operazioni di inserimento / modifica / cancellazione (o modifica stato) per sincronizzare i dati preesistenti.
I nuovi automatismi nella gestione delle schede dati saranno estesi con la possibilità di:
- impostare tramite codice javascript il contenuto di un campo in uscita da un altro campo;
- visualizzare come fieldset aggiuntivo nella pagina principale le relazioni di un "dominio" predefinito;
- estendere il meccanismo per nascondere un campo in uscita da un altro campo, con la possibilità di mantenerlo visibile ma non editabile.
CMDBuild e interoperabilità con altri sistemi
Un utilizzo importante di CMDBuild è quello di raccogliere informazioni da sistemi esterni per alimentare il proprio database tramite appositi connettori.
CMDBuild READY2USE include già i connettori standard batch con strumenti LDAP (informazioni sui dipendenti attivi), con OCS Inventory (informazioni sui computer installati nella rete aziendale), con VMware VCenter (informazioni sui server fisici e virtuali facenti parte della infrastruttura VMware) e con apparati di rete dotati di protocolli SNMP e LLDP (informazioni sugli apparati e sui device collegati), oltre al connettore real time con il sistema di monitoraggio Zabbix per ricevere e gestire eventuali allarmi.
Recentemente abbiamo realizzato dei connettori personalizzati su richiesta di nostri Clienti per sincronizzare:
- da AWS (Amazon Web Services) informazioni sulle macchine virtuali (tramite API Amazon EC2) e sulle reti virtuali (tramite API Amazon VPC;
- da Openstack informazioni su macchine virtuali, cluster, dischi e impostazioni di rete (tramite le API standard di Openstack).
Nel caso di openMAINT può essere invece richiesto di raccogliere informazioni da sistemi di sensoristica (IOT o Internet of things).
Recentemente abbiamo realizzato un sistema di controllo energetico per edifici scolastici, collegando sensori di temperatura ambiente (interni ed esterni, via cavo e wireless con ripetitori), temperatura acqua (riscaldamento e sanitari), contalitri acqua e contacalorie (rilevati sulla caldaia).
I dati vengono raccolti tramite concentratori locali e inviati tramite modem al server openMAINT dove il Cliente può consultarli in forma testuale e grafica, ottenendo anche un report di controllo dei consumi energetici con evidenza dei trend su base annuale e stagionale.
CMDBuild sul campo: USA State Benefit Management Program
Case study relativo alla necessità di una soluzione CMDB a supporto di un grande sistema di gestione statale americano. Di Michael Porter, Operations Manager di Deloitte LLP.
Fase 1 del progetto: applicazione On Premises
La mia azienda fornisce servizi di consulenza (sviluppo software, hardware, infrastruttura e progettazione) per un grande sistema di gestione americano ospitato nei datacenter di uno Stato degli Stati Uniti. I dati sensibili PII (Personally Identifiable Information) e IRS (Internal Revenue Service) contenuti nel sistema comportano requisiti normativi esigenti ed una lacuna che era stata identificata durante una revisione passata è stata la mancanza di un CMDB funzionale per tracciare l'infrastruttura e accedere alle modifiche nel sistema. Dopo un certo numero di analisi e verifiche, Tecnoteca è stata scelta come fornitore per fornire software e servizi per soddisfare i requisiti del CMDB, la soluzione CMDBuild READY2USE è stata selezionata grazie alle sue caratteristiche funzionali “pronte all'uso” ed al valore complessivo offerto da Tecnoteca.
La configurazione originale includeva i connettori per vSphere e LDAP, per fornire al CMDB dati relativi all'infrastruttura ed agli utenti. Questo è stato realizzato in pochi giorni. Benché la maggior parte dei sistemi siano virtualizzati, i sistemi fisici sono stati rapidamente caricati attraverso i fogli di input, lo staff tecnico di Tecnoteca ha rapidamente convertito i fogli di calcolo XLS contenenti tutti i dati “relazionali” associati (applicazione, software, ambiente, servizi in hosting) e un completo CMDB relazionale è stato ultimato per l’applicazione richiesta in tempi brevissimi. Con questi dati è possibile generare ogni notte un report in cui vengono segnalate le modifiche nell'infrastruttura o negli account utente, per qualunque CI richieda un monitoraggio per soddisfare i requisiti di gestione dell'applicazione.
Fase 2 del progetto: applicazione Cloud pubblica
È stato poi deciso che era necessaria una “trasformazione” dell'applicazione e che la nuova architettura includesse l'interfaccia utente in Salesforce ed il backend computazionale spostato su Amazon Web Services (AWS). Tecnoteca ha riprogettato i connettori dell'infrastruttura per connettersi ora alle API AWS per EC2 e VPC ed ha migliorato i dati relazionali per fornire un accesso semplificato per generare i report necessari, come gli elenchi di ambienti per il calcolo dei set di patch.
Quando i sistemi sono stati migrati in AWS, la precedente soluzione CMDBuild READY2USE è stata utilizzata per controllare e tenere traccia della disattivazione dei sistemi rimasti nei datacenter dello Stato. È stato uno strumento preziosissimo per tenere traccia del processo di migrazione tra i nuovi server migrati in AWS e i server rimasti nei vecchi data center.
Poiché dati AWS TAG sono stati utilizzati per definire i sistemi nell'EC2, ora tutti i dati sono stati automaticamente importati attraverso le API AWS. Questo include in parte l'ambiente, i servizi, l'applicazione e il set di patch. Ora che i sistemi sono stati aggiunti, tutti i dati relazionali rimossi sono stati aggiornati automaticamente nel CMDB e vengono generati automaticamente ogni notte dei report sulle modifiche.
La velocità con cui il modello CMDB è progredito in entrambe le fasi del progetto è stata veramente impressionante, e vorremmo ringraziare Tecnoteca per il suo eccellente prodotto e supporto tecnico.