In today's high-tech world, medium and large enterprises use more than ten different software solutions. From e-mail clients, information about customers, suppliers, products to complex CRM and ERP systems. Sooner or later the need for integration arises, as databases grow with the growth of business.
Using Service Bus integration in your work, you can solve some of the thorniest issues in managing your business.
When integrating, not a classical Enterprise Service Bus (ESB) * is used, but an API Layer that routes data batches with different systems. An API Layer is responsible for storing these data and converts them, if necessary, from one system to another.
* A Service Bus is an ESB that deals with routing, collecting, sending, data batch statistics, stores information about systems that have received data batches and tracks transformations that have occurred in the system.
This article describes work schemes and where this technology can be applied to, what business problems can be solved with its help.
In Service Bus integration technology, certain cases and architectural solutions are used to solve a number of applied business tasks:
All ERP and CRM systems are mostly classical ones. MS SQL servers are mainly built according to normal forms. Sometimes it is necessary to denormalize these data into very wide large tables for BI systems.
This solution can be used when it is necessary to analyze large data intervals. Using integration, we do not utilize any accounting system for data collection.
No load on the transaction system
When we periodically upload a data set (normal or denormalized) from the main system for use by other systems, we do not load the main accounting ERP system.
Data denormalization helps to:
Often, modern enterprises have got quite old implemented tasks and systems that at some point cease to be relevant. That is, we come to the point where, technologically, the platform does not provide new tools. It is impossible to make, for example, API access for other systems in “1C: Enterprise 7”. We need some kind of layer that will provide this access. For this, a Service Bus is used to configure the integration with "1C: Enterprise 7". It runs once in a certain interval, and a Service Bus already delivers this data promptly.
These products are important and interesting from historical point of view. However, sometimes they require transition and integration with new systems. API layer in a Service Bus provides this feature because API can provide access to any data.
Hence, the task of ERP or CRM systems re-implementation derives.
The task is not a simple one. For most companies, it lies in the strategy. Many ERP systems implemented several years ago require redeployment. Doing it in one leap is rather difficult.
System redeployment opportunities
You can use an iterative method for selection of some pieces.
There are separate independent areas that can be pulled into a Service Bus excluding historical data. These data can be left in the Service Bus functionality or migrate to a new system. Plus, it allows you to work in parallel.
When switching to some other system, if we separate individual functional blocks into a Service Bus and work with these data from another system through API, we reduce the total pool of what we need to transfer to a new ERP system. That is, we sort of cut into pieces and divide the moment of transition to a new system.
It is often used for various integrations, especially with Internet sites. All Internet site platforms have different architectures, in terms of aspects that are classic for us: nomenclature, nomenclature characteristics (colors, volumes), orders, contractors, etc. They usually do not fit in with the ERP system itself - they differ either on a technical level or on a logic level. What is meant?
For example, we sell pencils: green and red ones. We have one nomenclature with different colors on our site. PrestaShop, OpenCart and other CMS display data like this. In ERP, historically, these pencils have different item numbers. Often they are entered not in nomenclature-characteristic, but in the nomenclature itself. Accordingly, the exchange between these systems is disrupted.
There must be a compliance. That is, the matrix of how one item from ERP system is transformed into an item with a characteristic in the Internet site system. Accordingly, for this purpose you can either use direct point-to-point integration or create a correspondence matrix. Alternatively, you can use a Service Bus, which will store this correspondence matrix for exchange.
An example: a case for modnaKasta company. They had a complete system, but they wanted to divide it. As there was no need for accountants to see jeans in different sizes and colors, they decided to adopt a more advanced WMS system.
10 thousand of jeans arrived in a container and at the end of the month, the accounting department may write off five thousand of them and not think about their characteristics. However, it is impossible from the warehouse point of view. The end user should receive a specific color and specific size.
Terefore, this task lies before data convolution, when at the time of migration from one system to another we lose some information. That is, we convolve it: at the transmission moment, we fold the information to the volume required by another system.color and specific size.
For example, we create a chat bot “how many days of vacation leave does an employee have?”. This information can be obtained by contacting your ERP system directly and counting, loading the system. As a rule, there is no exact figure inside the system - it is calculated. Or you can count this figure once a day. There is no need to update this information more often than once a day. It becomes possible to contact a chat bot for this summarized information without loading the main system.
Now division of a system becomes a relevant issue. Сompanies that have large ERP systems, have an increasing need for a self-service mode development. For example, so that your customers could go to their personal accounts, make an order, track some information. This reduces the load on the call-center and sales managers. Work with regular customers becomes automated. This is the first task.
The second task is interfaceless systems. Large customers ask for an order to be recorded through API. And here arises the problem of access to the perimeter.
If the perimeter is strongly protected - then it does not look into the ERP system. There are two options:
Sometimes, at the time of granting access, there are a number of restrictions. As an example, let’s use Parfex company engaged in
perfumery business. They do not give out the final figure of their stock balance to their distributors, since the market is saturated and some large retailers can create an artificial shortage of a certain product. They can buy the entire perfume of a certain brand and inflate the price for it intentionally.
Therefore, at the time of uploading information into such a Service Bus, they provide access simply to the information if this product is available or not, limiting the contexts that you can see.
The same task has been solved for Ukravit: to make a large integration of about 14 systems. The company does not provide 
its distributors with all the information about its stock. They show indicatively: there is a lot of goods, enough of goods or few goods.
By doing this, the company stimulates, on the one hand, when the product ends - to buy the remaining goods. On the other hand, not to show a specific figure. When a customer sees that there is a lot of this product available - it can postpone the moment of purchase.
When providing our partners with some information from our IT system. So, we, for example, sell products to a huge number of retail outlets. Sometimes a retail outlet has an accounting system, sometimes not (then we keep records for them). We provide partners with tools for analyzing their own sales and show how much goods were shipped, order statistics, schedules, etc.
The inverse task is solved with these tools, when there are accounting systems and we create orders for them to fill. From the client’s side, there is an integration into our API, informing us what goods and in what quantity we have sold, and we can seize the moment for preparation of a new order to this customer and transfer it automatically.
In accounting for total cost of ownership, one point is often forgotten - the last one. Everyone understands that it consists of software purchase, implementation, support, some compulsory license payments, etc. They always forget the issue extremely rarely found even in documentation - output value.
Therefore, you have implemented the software and after a while (early or late, in five or ten years) you are forced to renounce of it. This output value is different for each software product. It depends on many factors. There are technologies, which are very difficult to receive data from. They have a denormalized structure, so it is hard to understand (if you look at its database), which tables are responsible for what. This part greatly increases the value.
When creating exchanges and putting information into Service Buses, you have to structure it in some way -and you get an API. Having a Service Bus integrated with your ERP system, when switching to other software, you still have a source of access to this information. Due to this access, you reduce the Total Cost of Ownership (TCO) of the information system. This access is very simple, fast and auto-documented.
It often happens that a company wallows in one technology. Developing only one technology in a stack, you become a hostage of one system. As a result, your company becomes dependent on a very narrow circle of specialists. In some cases - also on closed systems that are no longer supported.
Modularity of functions is a feature allowing taking information out. It helps reduce dependence on one particular system.
We build our solution on C # /. NET, Web API and Vuetify JS Framework. Speed access is as fast as possible and very scalable due to both technical and non-technical level. What does it mean? At technical level, we simply extend parameters of servers. It means when we increase a parameter - performance increases, too.
The system works both with relational and non-relational data. It is possible to use both MS SQL and some non-relational databases as following ones: Mongo, Redis, etc. Accordingly, it is possible to use MS SQL for a number of tasks, if convenient; for some tasks, you can use non-standardized structures in the form of documents / objects of non-relational databases.
In case of additional module introduction - there is no need in application rebuilding. Aside from the fact that this is a Service Bus that exchanges data, it has its own interface on Vue.js and it is possible to add ready-for-service modules. As of today, there are a number of solutions for online store integration, "1C: Enterprise" platforms and CRM platforms (Bitrix, AmoCRM and others).
Proprietary Solutions:
The system is based on open code. It is not always true for some companies, although they state it so. The platform itself, the core, the code inside the core are open. C # - on the backend side, on the front-end - a standard Vuetify on Java Script, and you can also build your own modules. Now we are working on a separate website for the platform and instructions on how to make a fork from the repository and use the code openness for our own purposes. You can inspect what happens inside the code and how it works.
We have specialized in this for the past five years. During this time, we have accumulated a great experience of ready-made cases and theoretical basis for integration of different systems. All data are available in the Genumis system. The site has a description and it is possible to use it in the cloud and our servers, or use them on local machines.
Using Genumis platform gives your business an opportunity to gradually build an IT environment of new generation.
External Web interfaces integrated with your main accounting system through API give opportunities to :
Copying of this content is allowed only with reference to the source and indication of the author of TQM systems' material. Thank you for respecting our intellectual property rights. TQM systems
Web Apps developing
Automation of business
IT Expertise
IT integration
If you would like to get new blog posts, articles, news and white papers by email - submit!
Our IT-company was established at the 2008 with young talanted people.
Our mission is to simplify data management.
Copyright © 2008-2024 TQMsystems. All Rights Reserved. Privacy Policy | Terms of Service
