March 2019
The release of CMDBuild 3.0 is scheduled for April 12th
In about ten days CMDBuild 3.0 will be released!
After two years of work, done by a dedicated team of designers and developers, the new 3.0 version will finally be available next April 12th.
As you know, the new version is actually a new product, with a completely rewritten user interface, which maintains all the previous configuration logics extending them with several new important server-side features.
The objectives we had set ourselves, and which we believe we have fully achieved, were to adapt the user interface to the new paradigms of web design, to guarantee high performances to operators (even with the availability of a new workflow engine), to be able to use the system in multitenant mode and to overcome certain limitations in the customization of events and in the graphic layout when consulting and updating data.
We now await the most important confirmations from those who already use CMDBuild and will migrate to the new version in the next coming weeks.
The migration from version 2.5 to version 3.0 will be guaranteed by the mechanism of the patch manager already present in the previous versions, except for operations performed manually in the database (writing of triggers, functions, etc.) which may require specific adjustments.
The dashboard configuration functionality has been temporarily excluded in the 3.0 version for time restrictions, and it will be restored in a next 3.x version.
In the coming months new versions will be released, both for bug fix activity and for the development of new functionalities. A 3.1 version is already planned for next June, about this you can refer to the next news.
CMDBuild 3.0 will come with the most important Manuals already available (Overview Manual, Administrator Manual and User Manual), the others will follow based on technical preparation times.
Concerning the migration roadmap for CMDBuild READY2USE and openMAINT, please refer to the previous newsletter.
CMDBuild 3.1 work in progress
The functionalities foreseen for CMDBuild 3.x will not end with version 3.0, but will continue according to a roadmap that will be developed in the coming months / years.
The first scheduled release will be CMDBuild 3.1, planned for the end of June.
CMDBuild 3.1 will include:
- implementation of a new mechanism for importing / exporting data via CSV files;
- new automatisms in the modification of the data cards;
- bug fixes.
The new data import / export mechanism via CSV files will allow to:
- configure one or more templates (list of columns and mapping on the CMDBuild data model) for the import and export of data related to a given class;
- carry out the operations in automatic batch mode;
- import CSV files in “merge” mode, so executing automatically the operations of insertion / modification / deletion (or status change) to synchronize pre-existing data.
The new automatisms in the modification of the data cards will include the possibility to:
- set the contents of an output field from another field using a javascript code;
- display as an additional fieldset on the card main page the relations of a predefined "domain";
- extend the mechanism to hide an output field from another field, with the possibility of keeping it visible but not editable.
CMDBuild and the interoperability with other systems
An important use of CMDBuild is to collect information from external systems to “feed” its database through appropriate connectors.
CMDBuild READY2USE already includes standard batch connectors with LDAP tools (information on active employees), with OCS Inventory (information on computers installed in the company network), with VMware VCenter (information on physical and virtual servers belonging to the VMware infrastructure) and with network devices having SNMP and LLDP protocols (information on the devices and on connected devices), as well as the real time connector with the Zabbix monitoring system, to receive and manage any alarms.
Recently we have implemented new custom connectors, following request of our customers, to synchronize:
- from AWS (Amazon Web Services) information on virtual machines (via Amazon EC2 API) and on virtual networks (via Amazon VPC API);
- from Openstack information on virtual machines, clusters, disks and network settings (via the Openstack standard API).
Concerning openMAINT, it may instead be required to collect information from sensor systems (IOT or Internet of things).
Recently we have implemented an energy control system for school buildings, connecting temperature sensors (internal and external, cable and wireless with repeaters), water temperature (heating and sanitary), water flow meters and calorie meters (boilers).
The data are collected via local concentrators and sent via modem to the openMAINT server, where the customer can consult them in text and graphic form, also obtaining a control report on energy consumption with evidence of trends on an annual and seasonal basis.
CMDBuild Reference & Case Study: USA State Benefit Management Program
Case study for the requirement of a CMDB in the support of a large State Benefit Management System from Michael Porter, Operations Manager in Deloitte LLP.
Project Phase 1: On Premises Application
My company provides consulting services (software development, hardware, infrastructure and design) for a large benefit management system in the USA hosted in State datacenters. The sensitive PII (Personally Identifiable Information) and IRS (Internal Revenue Service) data contained in the system brings demanding regulatory requirements and a gap that was identified during a past audit was the lack of a functional CMDB to track infrastructure and access changes in the system. After a number of POCs, Tecnoteca was chosen as the vendor to supply software and services to fulfill the requirements of the CMDB, the CMDBuild READY2USE solution was selected due to the “ready to use” functional features as well as the overall value Tecnoteca affords.
The original configuration included connectors to vSphere and LDAP to provide infrastructure and user data to the CMDB. This was accomplished within a few days. Although most of the systems are virtualized, the physical systems were quickly loaded through input sheets and Tecnoteca Engineering staff quickly converted the XLS spreadsheets containing all the associated “relational” data (application, software, environment, hosted services) and a full relational CMDB was completed for the “application” within a very short timeline. With this data a report could be generated each night that reported changes in infrastructure or user accounts, based on whatever CIs were deemed requiring monitoring to fulfill the requirements of configuration management of the application.
Project Phase 2: Public Cloud Application
It was decided that a “transformation” of the application was required and the new architecture included the UI in Salesforce and the computational backend moved to Amazon Web Services (AWS). Tecnoteca reengineered the infrastructure connectors to now connect to the AWS API for EC2 and VPC data and enhanced the relational data to provide simpler access for generating needed reports like environment lists for calculating patching sets.
As the systems were migrated into AWS the previous CMDBuild READY2USE solution was used to control and track the decommissioning of systems remaining in the State datacenters. It was an invaluable tool to keep track of the migration process between the new servers migrated into AWS and the servers remaining in the old data centers.
Since AWS TAG data was used to define the systems in the EC2, all data was now automatically pulled through the AWS API. This included in part the environment, services, application and patching set. Now as systems are added, changed removed all relational data in the CMDB was automatically kept up to date and a change report was generated each night.
The rate at which the CMDB model progressed for both of the project’s phases was very impressive and we would like to thank Tecnoteca for their great product and engineering support.