NORD POS. The story of why I needed another fork of Openbravo POS

    Introduction


    In a previous article, I told readers a brief history of ten years of development of the Openbravo POS project. For 7 years, I took an active part in it and, together with other participants, developed an open source outlet management system. But this year I decided to transfer all my accumulated achievements to the independent project nordpos.mobi and develop them as part of my own fork, created on the basis of the open source Openbravo POS.



    The origins


    The key reason for stopping the development of Openbravo POS was the actual departure from the project of its founder Edrin Romer, he completely switched to the development of a commercial version of Openbravo Web POS and since 2010 he no longer touched the original code of the original version. Therefore, I did not have high hopes for the revival of the project, and I had a need to develop the application.

    Almost from the first days, in parallel with the public work on localizing Openbravo POS, I led the development of an internal project for my family’s business called NORD POS. Since our family business is associated with the maintenance of cash register and other trading equipment, we were also interested in the further development of our own application that could work with this equipment. Which prompted me in 2012 to upload the NORD POS source code first to the Mercurial repository on Bitbucket, and then to GitHub after switching to Git. Versioning had to start right away with the number 3 due to the fact that one of the main features of my application was the ability to migrate from the latest version of Openbravo POS. As a result, the first version of NORD POS was version 3.0.0,

    Separation of basis and superstructure


    The Openbravo POS application itself was generally self-sufficient for the tasks of organizing cash accounting. It contained a full range of functions performed at the cashier’s workplace, but users all the time lacked the capabilities and flexibility of adjusting them to the specifics of a particular business. Although something could be solved by writing built-in scripts, their scope was limited only to the sales panel. If it was necessary to somehow change the business logic and connect new equipment, then you had to make changes to the application core. And since it was originally monolithic and was essentially developed by only one person, these changes could affect a significant part of the source code. Although from version 2.10, where Adrian Romero singled out report generation as a separate pluggable resource, a gradual transition to modularity and extensibility began by removing some of the resources from the kernel of the application source code, but unfortunately since 2009 the project was essentially frozen and this process did not receive further development. Also, this direction did not find development in forks based on Openbravo POS, and it became interesting for me to try to implement it myself.



    Current version of the desktop application : NORD POS 3.0.1 Community Edition
    System requirements : Windows or Linux OS with Java SE 7.
    Interface : Java Swing in the desktop application and jQuery Mobile in mobile web applications.
    Databases : Apache Derby and MySQL as the main ones, but PostgeSQL, HSQL, Firebird or Oracle are available.
    Interface languages : English and Russian.
    Source code : github.com/nordpos/nordpos
    Binary assemblies : sourceforge.net/projects/nordpos/files/app-platform
    License : GNU GPL v3.

    Pluggable hardware in peripheral drivers

    I spotted this solution in the commercial version of Openbravo Web POS, where the interfaces were rendered using Java SPI in separate packages for each type of equipment. This made it possible to solve the problem with connecting equipment that was present only in our local market, for which there is now no need to make a separate fork of the entire system, and it is enough to make changes to only one driver that was taken to an independent library. In the same way, NORD POS implements connection to card processing payment gateways.



    The diagram shows the implemented interfaces for individual types of trading equipment. At the same time, the customer’s display, fiscal registrar, receipt and etiquette printer are controlled through special XML templates, the structure of these templates is described in Schema.Printer.xsd . Also, to implement work through plug-in drivers, the directory structure of the application for editing resources was changed without the need to compile the main package.
    • ./services , files with the announcement of the called services;
    • ./templates , custom templates;
    • ./lib-ext , the driver libraries themselves.

    In addition, as in Openbravo POS, barcode scanners or magnetic cards can be connected to NORD POS without problems in keyboard mode.

    Business logic in mobile add-ons

    I already spoke in detail about the idea in detail in the article Compact Java servlet for mobile web , later it could become the flagship of the Openbravo POS development, but unfortunately it was not picked up by anyone, and today it is the main distinguishing feature of the nordpos.mobi project . At the same time, it not only contains the source code for creating its own Java servlets, but also has the opportunity to try the demo versions for the product catalog and the waiter’s workstation , which are already compiled and deployed to a virtual machine in the Windows Azure cloud. And now I have plans to make a mobile online store and a mobile data collection terminal for the warehouse for NORD POS.



    From a technical point of view, these are stand-alone web applications that have only a common database with the desktop version of NORD POS, while the database is not very different from the original one, and NORD POS web applications can be used in conjunction with other Openbravo forks POS In contrast to the desktop version, where interaction with the database management system was carried out through SQL queries, Java servlets use Java annotations of the ORMLite library to access information through the data model . The list of supported databases through the JDBC driver is quite extensive, and all you need to connect is to specify connection parameters in the /WEB-INF/web.xml servlet. In this case, the only condition is that in the folder / WEB-INF / libthere was a JDBC driver for the corresponding DBMS. Here is an example of settings for MySQL:

    db.URLjdbc:mysql://localhost:3306/nordpos?useUnicode=yes&characterEncoding=UTF-8db.usernordposuserdb.passwordnordpospassworddb.application.idnordpos


    Visual schemes for data synchronization

    Another necessary feature of POS programs is the presence in them of integration tools with other software already implemented or planned for implementation. In our country this is usually 1C, abroad it is a different ERP system, and very often these are online stores built both on popular CMS and self-written. Most often, POS developers as a universal solution use uploading and downloading to a text file, which is then processed by an external system. But I liked the decision to use specialized software for ETL. Openbravo POS 2.30 used Pentaho Data Integration software.. Since this is a more universal approach, it can both adapt to the API of other systems and implement your own options for exchanging data. Pentaho Data Integration uses a visual approach to the process of extracting, transforming and uploading data. For example, the scheme for unloading tables of goods, categories and taxes from the NORD POS database will look as follows.



    Pentaho Data Integration transformation schemes can be launched in several ways: from the graphical shell, command line, scheduled, through a web server or built into another application API. For NORD POS, I chose the latter option, as it is most convenient for users.

    Implemented the transformation scheme integration was similar to the integration of JasperReports report templates. In the visual editor, a transformation scheme is created.



    After that, a script is created in a text editor or IDE to call it from the application.

    transformation = new com.nordpos.sync.panel.PanelTransformationBean();
    transformation.setTitleKey("Menu.SyncImportProducts");
    transformation.setTransformation("/com/nordpos/transformations/csv/IMPORT_PRODUCTS.ktr");
    transformation.addTransVariable("db.URL", this.app.getProperties().getDBURL());
    transformation.addTransVariable("db.driver", this.app.getProperties().getDBDriver());
    transformation.addTransVariable("db.user", this.app.getProperties().getDBUser());
    transformation.addTransVariable("db.password", this.app.getProperties().getDBPassword());
    transformation;
    

    In it, as a reference to the scheme is given, the parameters of the variables necessary for the conversion are set. If the conversion will be associated with the processing of information from the database, it is imperative to set the parameters for connecting to it. Then, in the application resource Menu.Root, a button and a call to the script execution panel in the application menu are set.

            submenu.addPanel("/com/openbravo/images/database_imp.png", "Menu.SyncImportProducts", "/com/nordpos/transformations/csv/import_products.bsh");
    

    And in the rights of the user role, access to it is allowed.


    By restarting the application, it will be possible to directly load data from external files into NORD POS according to Pentaho Data Integration schemes.



    Embedded Servers


    Database server

    The default database in Openbravo POS was Apache Derby , but not the network version, with the possibility of multiple simultaneous connections, and the built-in version from the JDBC driver with only one simultaneous connection. At the same time, to connect several POS-systems to one database, it was necessary either to install the Apache Derby server, or to select another DBMS in which the function for simultaneously connecting several connections was supported initially. It was also necessary to use several connections for data exchange through Pentaho Data Integration. Since the migration function from Openbravo POS to NORD POS was originally planned for me, I decided to use the built-in version of Apache Derby Network Server as a convenient means of updating the database. Now for updating it is enough to copy the folder with the database from Openbravo POS to the .derby-db folder of the user directory by writing its name in the URL of the JDBC driver, and the update will be automatic. If another DBMS is used as storage, then the launch of the embedded server can be disabled.

    Web application server

    Since the main audience of NORD POS will still be ordinary users, inexperienced in the issues of installing web servers and deploying web applications in servlet containers, by analogy with the built-in database server, the Jetty 9 web server was integrated into the application . It is launched optionally, if specified in the settings.



    Web applications are installed in the ./webapps folder directly in the NORD POS directory, during installation it is necessary to unpack the previously compiled contents of the war file into a folder with the corresponding name. After starting NORD POS, by the name of this folder in the browser line, the installed web application will be available.

    More changes and plans


    In addition to the above global changes, there are some not so dramatic changes in NORD POS:
    • all libraries were completely updated, including RXTX replaced by Neuron Robotics Java Serial , and JasperReports updated to 4.8.0;
    • support for two-dimensional DataMatrix barcodes and a QR code;
    • the ability to use discounts for the entire amount of the check or for individual items;
    • new reports;
    • syntax highlighting in resources and scripts;
    • Faenza icon set and default Dream theme.

    It was still planned, but so far unrealized, to transfer work with the database to ORMLite, and to do the calculations in BigDecimal, just as it has already been done in mobile web applications.
    For the rest, I want to concentrate more on working out what has already been done and creating extensions to the basis that I managed to create in the first public version of NORD POS (for example, there is already a branch for realizing payments using Bitcoin in it). But at the same time, I am most interested in attracting new participants to work on the project. So, if after reading this article you had questions about automation in trade, you are always happy to help and tell more about how this can be done using the open-source NORD POS code.

    Also popular now: