Zirius: Norwegian ERP System on the NetBeans Platform

Zirius is a software company developing ERP solutions for small and medium sized businesses in Norway. Our main product is called Zirius ERP, which is based on the NetBeans Platform. The program is in Norwegian and can be downloaded from http://www.zirius.no. Some of the things Zirius ERP solves are accounting, project management, storage handling, invoicing, asset control (rental, deprecation etc), document archives, document workflow, and purchase handling.

Zirius ERP is used by, among others, accounting agencies and entrepreneurial businesses in all parts of Norway. The company was started in 2004, and we have had steady growth since then. The company also provides Android applications that work with our main application and we have a free web based invoice system at http://www.fakturaweb.com. 

Here's the main screen of Zirius ERP:

Though we are indeed using the NetBeans Platform, we're currently not using a lot of the functionality it offers. Our product is about 8 years old already, so you can imagine it has a lot of old code that cannot be ported very quickly.

Installer and Update Center

What started us down the path of using the NetBeans Platform was the fact that we use NetBeans IDE as our development environment. We saw the need in our product for an installer and an update center, just like those that NetBeans IDE has.

Previously, we used Java Web Start (JNLP) to deliver products to our customers. JNLP presented a few issues however, in particular with terminal server users. For these users, the NetBeans Platform saved us by giving us a proper installer and an easy and reliable way of delivering updates through the update center mechanism.

We have created five seperate update centers for our customers:

• Production. This is where 90% of our customers will be.
• Entrepreneur. For our biggest companies in terms of users (~10-100 users), where we push updates less frequently. Our software requires the same version on all clients in a company and, as such, it can be a hassle to get frequent updates.
• Woodwork. This is for production and treatment of wood, such as planks, etc. These companies have special needs and we also have to handle the integration with different products, such as saws, so therefore they require their own update pace.
• Beta and Release Candidate. This is for features in development and for bug fixing.

Previously, it was somewhat of a hassle with JNLP to get the above kind of mechanism to work. Some users would, for example, save the JNLP file locally and then run it from there, thus giving us support when they did not get new JARs for example.

Another big advantage is that customers can now download our release candidate version and then just swap back to production. They will then eventually just sync up with the production version. Previously, if customers wanted to do this, they had to have two installations on tehir PCs, while manually making sure they swapped over to production at a point where they had the same version.

Here is the update center selector we created to support the above mechanism:

We have made it so that you can only have one update center installed at a time.

Single TopComponent

Zirius has been a Swing product for a long time and, as such, to start with, we have provided the NetBeans Platform with just a single TopComponent, which is unclosable and unmoveable.

To achieve this:

• we hide the Toolbar via ToolbarPool.getDefault().setVisible(false)
• we hide the tabs via this article
• we add the content of our old JFrame to the TopComponent

Login & Menu Management

We have both a security manager and a license manager for limiting access to users to various menu points. To make our menu system work in the NetBeans Platform, we insert our own menubar instance into the NetBeans Platform. We do this in our menubar module, where we have made public our menubar API, which we install via the layer:

<folder name="LookAndFeel">
    <file name="MenuBar.instance">
        <attr name="instanceOf" stringvalue="org.openide.awt.MenuBar"/>
        <attr name="instanceCreate" newvalue="com.zirius.core.netbeans.uiconfigurator.menubar.implementation.SortedMenubar"/>
    </file>
</folder>

System.setProperty("netbeans.winsys.menu_bar.path", "LookAndFeel/MenuBar.instance");

Below you can see that the "Meny" menu is removed, because access to it has not been granted:



And here the "Meny" menu is available because the user has logged in:



Decoupling via Lookup API

We have different modules that now can be totally decoupled from their parents, via the NetBeans Lookup API.



Previously, each module would at least need to know about the handler class for the event, so as to add itself as a listener. With the Lookup API, the only thing we now need to know about is the interface, which means less dependencies.

Here is an example of a listener that adds a logout event to to our menubar.

To have the NetBeans Platform trigger the events, we have a class in our core package that is added to the old event handler in our code, like so:

    @Override
    public void loggedIn(LogEvent le) {
        clearMenu();
        final Collection allInstallers = Lookup.getDefault().lookupAll(ZiriusLoginListener.class);
        for (ZiriusLoginListener observer : allInstallers) {
            observer.loggedIn(createZiriusLogEventFromLogEvent(le));
        }
    }

The NetBeans Platform seems to be a solid platform thus far. We have not experienced any bugs with the parts of it that we use for our product and it does what we tell it to do.

It also seems to have a solution for most problems we encounter, even though they might not all be so well documented. The only real reason we aren't using more parts of the NetBeans Platform for our product is the time it would take to change our old code. If we were starting today, from scratch, I am sure we would use the NetBeans Platform for nearly everything it can offer.

The biggest issue with the NetBeans Platform I have found has been the documentation for the layer files. There are so many things that can be done in the layer files, but they do not seem to be documented, especially about how to use it well or optimally.

Our integration into the NetBeans Platform has been relatively easy. It has not taken much time, but there have of course been some issues. The biggest was probably when we changed from a single update center to several. The first time a new update center is added, it is enabled. If it is removed and then added again, it is disabled by default. This caused quite a few customers to need to reinstall their application, as we could no longer push updates to them to fix the problem. So, remember to manually set update centers to enabled if you add them at runtime because they could be locally stored as disabled!