July 2019
New versions CMDBuild READY2USE 2.0 and openMAINT 2.0
After CMDBuild 3.0, released in April, and CMDBuild 3.1, released in mid-July, are now available the new versions of the vertical applications CMDBuild READY2USE 2.0, dedicated to the IT Asset Management and Services, and openMAINT 2.0, dedicated to the Facility Management.
Both products are based on the latest CMDBuild 3 "core" and include as well numerous new application features, as already mentioned in the previous newsletter.
As in the past, the basic features are released as open source, while some additional external components are reserved for those who subscribe to the Subscription Service.
We are also already working at the CMDBuild “core”, for the upcoming appointments scheduled after the summer period, which will lead first to an intermediate maintenance release (bug fix) with 3.1.1 version and then at about the end of the year to the 3.2 version.
Version 3.2 will retrieve the last functionalities left out from the previous 3.0 and 3.1 releases and will add several new features, some identified by the Tecnoteca Maintainer and others suggested by users already migrated to the new 3.x version.
At the next news you will find a more extensive description of the new “core” implementations.
Work in progress for CMDBuild 3.2
The CMDBuild 3.2 version, whose release is expected at the end of the year 2019, will retrieve some implementations that for reasons of time had not found place in the last releases, and will add new important features.
Among the implementations that will be retrieved, we mention:
- dashboards;
- completion of the thematisms;
- dedicated user interface for managing processes with parallel activities;
- password control functions;
- CAS (Central Authentication Service) authentication;
- massive modification of the data cards of a class (to be confirmed if in 3.2 or 3.3 version).
Among the new features that will be released, we mention:
- extension of user preferences: start page, configuration of class and process grids;
- personalization of the layout of the data cards, with the possibility of distributing the attributes across multiple columns, even in variable numbers on the same card;
- form triggers on processes for the execution of personalized behaviours (extending the mechanism already available on normal classes);
- new types of permits on processes;
- schedule: possibility to set as a “deadline” some data type attributes, to automatically request additional information during the modification of the data card and generate schedule lines, to access to a page of overall consultation of the schedule (list, detail tab, calendar view, report) and close the solved deadlines;
- limited administrator with the possibility of creating users on his own tenant;
- service functions for the administrator: viewing and downloading logs and other system files;
- update to Java 11.
Display of thematisms in the GIS of CMDBuild
The thematisms can be used to visualize and classify in a graphical way on the map, with colours and shapes, information contained in the data cards, such as the status of an asset, its seniority, the intended use of a building or a room, the electrical panel on which a device depends, etc.
The readability of data (colour interpretation) is guided by a special legend.
The thematisms are therefore an additional way to perform analysis on the information on the card, on statistical data or on correlation information, relative to the objects visible on the map.
The functionality was available in CMDBuild 2 and will now be retrieved in CMDBuild 3.
In the CMDBuild 3.1 version, the “punctual” thematism type have already been re-implemented, which highlight the objects on the map with a colour correlated to the value of the chosen attribute, both configurable during the definition of the thematism.
In 3.2 version, the “interval” thematism type will then be restored, which can be used to perform analysis on value ranges referring to numerical or given attributes, and both types of thematisms will be extended with the possibility of correlating colours to information returned by more complex functions (fault frequencies, total repair cost, etc.).
An important improvement compared to the previous 2.x versions is that now the thematisms can be saved and reactivated when necessary, in a similar way to user filters.
A new function is also already available in the Administration Module, to make accessible to the enabled roles thematisms of general interest configured by individual users.
CMDBuild Reference and Case Study: Hedmark IKT (Norway)
Hedmark IKT is an IT company in Norway, owned by 7 municipalities with a combined population of about 100,000 people. In addition to being an IT partner for these municipalities, approximately 30 other public companies use our services, including cinemas, waterworks and fire departments.
About 20,000 people in more than 260 different physical locations use our solutions, including health personnel, teachers, students and municipal administration. Hedmark IKT has about 40 employees in two offices with one datacenter.
Up until 2016 we primarily used Excel documents to keep track of our assets, like subnets and IP addresses, servers, databases, switches and wireless access points. Suffice to say, this was cumbersome, inefficient and insecure. We started looking for other solutions and tested CMDBuild, among other solutions. CMDBuild did a great impression as it was Open Source and highly extensible, and we could build our own data model to fit our needs. Furthermore, we could import data from Excel documents into CMDBuild with very little effort.
We already had a decent ticketing system, so we decided to build our own model with just servers, subnets and IP addresses. Later we added switches, routers, printers and firewalls, server operating system, switch operating system, systems, databases and businesses, all connected together, searchable and easy to maintain. With some planning, this agile, evolutionary approach is achievable with CMDBuild.
Compared to CMDBuild READY2USE this is a very simple data model, but it serves our purpose and helps a lot.
A more recent addition to the data model is DHCP scopes and options. Using CMDBuild and some automation scripts, we configure our DHCP server scopes just using CMDBuild. Our next step is to automate monitoring setup using CMDBuilds API and Nagios.
We look forward to upgrade to CMDBuild 3, and see some long-awaited features that we will take advantage of, especially triggers and improved UI performance.