About

This is a technical description of the project. For information about the Business Logic, read the related articles.

ERP Core

ERP Core is a .NET & Angular microservice based framework for building highly customizable ERP systems.

The system comes with base business logic implementations for the most common applications such as: Accounting, Warehouse Management, CRM, Product, BOM, Manufacturing, POS etc. The system’s business logic examples are niched on the hospitality sector, but can be adapted to any other industry sector. A live system is already running successfully since 2021.

You can find a demo by clicking the ERP DEMO button in the main menu or click here. Due to security reasons the credentials will be sent on request. Please email or call us for the credentials.

System layout

The ERP system is composed of one master event broker and many satellite plus-ins. The master’s location (IP address and port) must be known by all the plug-ins. Each plug-in will automatically register to the master through the event system (SignalR). The communication between the master and the plug-ins is done via the event channel and/or via the standardised API. The plug-ins can access the same database as the master and/or add its own schema and tables. The plug-ins usually have access to the base ERP models and business logic, that they extend. You can also have plug-ins that don’t extend the base functionality and don’t need the base models. Also, you can have plug-ins with their own database. The plug-ins with separate databases must have their own storage and audit tables in the database, that means they must use the data access kernel DLL.

The systems landscape consists of many interconnected systems as you like. For example you can have a Development, a Test and a Production system but you can also maintain a separate HR system for example, totally disconnected from the rest of the systems for example and only transfer data when needed.

ORM

The system uses Entity Framework (the Microsoft implementation). This helps with data modelling. The ERP Core has attributes that decorate classes and properties in order to tell the metadata engine more about the object. For more information, please refer to the ERP Core data modeling documentation.

Metadata

The metadata engine is used by the UI to generate the proper controls. The UI is generated by an Angular application that reads the metadata from applications that run o the server and renders the controls. Most of the customizations are only done in C# thanks to the metadata driven UI.

Auto-Generated UI

The UI is an Angular application that talks with all the systems’s components and renders the controls as the metadata tells it to. This means that minimum or none UI development is needed when customizing the system. Of course, in order to make pretty websites, you need UI development, but for back-office use, auto-generated UI is most of the time enough.

API Data format

The data is transferred throughout the system as JSON. The API endpoints are fixed and the data format is standardized, that way one endpoint can handle various object types without any modification ensuring API forward and backward compatibility. Changes to the data format are allowed only for the actual data objects. Most of the data transfers contain some amount of metadata in order to tell the host or destination about the data being transferred.

Repository

When developing applications (plug-ins), the repository pattern is recommended. That way you decouple the actual business logic from the rest of the engine. You can reuse code from older applications if it is written in this way. When using the repository patterns, you need an interface that exposes the public business logic and a class that implements it. We also recommend using DTOs to transfer data. The audit and authorization engine will take care of the sensitive data being transferred if the proper roles are configured properly.

Other technical characteristics of the engine

  • Multi tenant – you can host as many independent business entities on a single server, each entity having its own private data;
  • Audit – all user actions are or can be recorded. That way you can avoid loss of data and can audit individual actions;
  • Authorization and Authentication – All the data is transferred via API. In order to have data access, the caller needs a valid JWT token that is send with each request. The token is issued by the authentication application after sending it the tenant name, user name and the password.
  • Data security – the engine implements automatic data stripping based on roles;
  • Error logging – all errors are logged to the database or file system, depending on the error type, that way it is easy to find bugs in the code;
  • Minimum downtime – for plug-ins modules, the system downtime is zero because each custom plugin runs in its own application. Only the base system modifications affect the downtime of the entire system, but those are very rare actions necessary only on kernel updates;
  • File system management – the system features some file storage implementation options. You can store the data locally on Windows or Linux (that means the data is stored in the running application’s folder) or remotely on another machine via FTP or WebDAV.
  • Plug-ins for customization – when you need a new functionality, all that is needed is a plugin. The plugin automatically tells the base system about itself and that way you don’t need to worry about any other configuration. The plugins can have their own database or acces the master database, depending on what the plug-in needs to do. If the plugin has its own data, the tables will be stored in a separate schema in the database.
  • Events – each time data changes take place in the system, events are rizzen. The events reach all the applications and plug-ins. Event subscribers can take action if need.
  • IoT – devices can be connected to read / update and insert data (an ERP plug-in is required). For example, in one of our implementations, we are running a Call-Waiter system connected to the POS. The devices transmit data (when a customer pushes a button on the device) via a 433MHz link to a device controlled by a plug-in, that informs the waiter.
  • Any database – thanks to Entity Framework, you can choose any database you want (and Entity Framework provides implementation for). We are running our servers with PostgreSQL.
  • Standardized API – all the standard API endpoints are standardized and fixed. That means that even if the implementation change, the endpoints will still be there. Even if the standard endpoints are there, you can still create your custom endpoints in your plug-ins, but it must be said: all the standard endpoints have the audit, authentication and role validations implemented by default. So when you create custom endpoints, you need to implement your own logic.