Do you work with transport monitoring systems, process and approve applications, or are you part of the development team for such products? Then this material will be of interest to you.
In the article on the example of a product Monitor3S we will tell you how to organize the work with transport requests in the best way, if it is difficult for a company to find a box-based monitoring solution using GPS and GLONASS. Who cares – welcome to cat.
What’s the problem?
We will definitely get to the technical description, but first we will tell you about the difficulties of the customers, which prompted us to look for optimal solutions using automation.
Situation No. 1 EDMS – monitoring program – 1C – waybill
The customer has its own electronic document management system (EDMS), where applications for transport are made. Further, the applications go through a chain of approvals, according to the results of which a vehicle and a driver are assigned to the initiator. Then the driver receives a waybill printed from the accounting program (1C), independently develops a route through all loading / unloading points and at the end of the shift submits a waybill with information on fuels and lubricants (fuels and lubricants), mileage and other attributes of a standard waybill …
The scheme seems clear, however, even when using a vehicle monitoring system using GLONASS / GPS, if you need to correlate the status of the application with the change plan (for example, there are doubts about the fuel and lubricants spent or a fine has arrived), this can be done only by checking data from several information systems: look at the application in the EDMS, look at the movement track in the vehicle monitoring system, and then check the consumption rates in 1C and check all this with the waybill.
If shown schematically, it looks like this:
As we can see in the figure, in the center of information flows movement there is a dispatcher who, for a number of reasons, cannot always provide timely information update, data upload and is not immune from commonplace errors.
To make this work easier, the entire process needs to be automated.
Situation number 2 Plan – fact
If the organization has a lot of transport and the nature of its use is different (transportation of passengers, transportation of goods, special equipment, construction equipment), then planning and budgeting its work for long periods is a time-consuming task. It is especially difficult to solve in the presence of an extensive branch network and a large number of participants in the process, including contractors.
In this case, in addition to the prompt formation of the required number of applications for equipment, it is necessary to track the class of transport, check with the planned indicators of the production program, check the actual services provided for each completed application, and summarize the final data and generate reports for the management based on the results of the reporting period. The figure schematically shows the process of interaction of all participants in the process:
The passage of an application for the provision of a transport service through any one static workflow with the participation of the main elements of the workflow can be illustrated as shown in the diagram below:
Everything looks simple on the diagram, but in practice these manipulations take a lot of time, and automating a workflow with the necessary flexibility in using its elements is not easy.
Attempt # 1
In the first approach to solving the problems described above, we extended the API to Monitor3S… It would be possible to refine the solution in 1C and “drag” everything that users expected there, supplement it with indicators from the vehicle monitoring system, but we took the path of integration between programs, strengthening the functionality of the software package.
By making a special integration module inside Monitor3S, which independently initiated requests to the EDMS, updated the status of tasks within the vehicle monitoring system and the route point, formed a final “waybill” with actual indicators (fuel, mileage, engine hours, etc.), as a result, we got a scheme of work, presented in the figure below …
This scheme turned out to be working, but during operation it revealed a number of shortcomings:
- if the software version of one of the systems is updated, then sometimes the integration mechanisms also change;
- the composition of data varies from system to system. Sometimes it becomes clear when something has already broken;
- In addition to the analyst, developers must be involved in any changes to the automated workflow, and a boxed version of the product with updates must be regularly released, and this is additional significant labor costs.
Attempt # 2. BPMN + Activiti
We wanted to achieve more flexibility in the resulting solution, and the more we detailed the processes, the more we realized how difficult it would be to support these schemes and possible changes in functionality. Even the versioning of the process itself can become a problem, since some requests may already be initiated and are accompanied by one workflow, and new requests must start moving along a different workflow due to the updated rules that have come into effect from a strictly defined date.
It became obvious that it was necessary to minimize distortions of real work processes and provide analysts with a flexible mechanism for modeling business processes, automatically generating their descriptions in a standardized format with the possibility of easy correction and further automation.
To solve all these problems, we began to use in our work BPMN, since this system allows you to store the legend and their description in XML format for displaying business processes in the form of diagrams. It is aimed at both technical professionals and business users. To do this, the language uses a basic set of intuitive elements that allow you to define complex semantic constructs. In addition, the BPMN specification allows you to transform diagrams describing a business process into executable modules. The BPMN specification is executable and portable (that is, a process drawn in one editor from one manufacturer can be executed on a business process engine of another manufacturer, provided they both support BPMN).
An important requirement was that the description format should be an open standard, free and not belonging to the area of proprietary developments that limit the choice of engine implementations.
After a series of studies, we decided that the product Activitibeing one of the implementations of the “engine” for executing BPMN schemes, it is quite suitable for automating the processes themselves, subject to the decomposition of operations to the required level.
After prototyping and evaluating the architecturally important details, we realized that this is a really good option for a number of reasons:
- in Activiti, in addition to the engine itself, it also implements a REST-API for interacting with external systems. This allows systems deployed on various platforms (Windows, Linux, etc.) to interact with Activiti;
- Activiti has a web interface that allows you to manage loading BPMN diagrams, launching processes based on loaded diagrams, and performing many other operations to manage and control processes;
- Support for working in a cluster has been implemented. We were glad to see such an opportunity, because for enterprise customers, resiliency is very important.
The general diagram of the Activiti components and the interaction between them is shown in the figure below:
Activiti is not visible to end users, but plays a significant role in the backend and application logic.
Analysts “draw” processes in any convenient tool with support for exporting workflows in the BPMN standard. You can use different editors to create a BPMN description, but we chose an intuitive BPMN editor, implemented on the basis of Eclipse using a plugin eclipse bpmn2 modeler, which fully supports the BPMN 2.0 standard and allows you to generate a file with a BPMN description (diagram) for further loading into Activiti.
Once the BPMN diagram is loaded into Activiti, the application generates a process definition based on it. Then, using a REST-API request from an external system or Java-API (for applications written in Java) or a web application interface (Activiti Explorer), Activiti creates an instance (thread) based on the process description, which starts executing like magic, moving step by step through the elements of the circuit, following the directions indicated by the arrows, thereby implementing the logic of the circuit:
Thus, the BPMN diagram, which is an xml file, starts executing as if it were a program written in one of the programming languages.
Already imported workflow (part) looks like this:
During the implementation, the developers mainly used a minimum of code to check the boundary conditions for the execution of a particular schema element, and also extended the capabilities in Activiti itself by implementing a “custom extension” or adding custom logic to the BPMN process, for example, by implementing the so-called. “Service task” or “event listener” and extending api applications Monitor3S…
Inside Activiti, “custom extension” and “custom logic” are implemented in Java or Groovy, but the difference in stacks between Monitor3S and Activiti does not matter here, since the systems interact via REST-API via https.
As a result, in the context of equipment composition, a typical complex Monitor3S can be represented like this:
As for fault tolerance, then, of course, both it and the high availability of the service database of Activiti itself is implemented by separate database tools (we have special utilities for this in the Jatoba DBMS), but as a result, multiple Activiti instances can work correctly with a single database.
Thus, the implementation of Activiti in the backend allowed flexible and quick adjustment to different needs of the work processes associated with the movement of applications for vehicles in Monitor3Sby optimizing a number of functions:
- Operational transport management.
- Automatic generation of a certificate for verifying the actual indicators of the fuel level in the tanks and mileage, in order to quickly check the completion of the waybill by the driver.
- Prompt information on the employment of transport.
- Improvement of the reporting system, since summary reports on the plan / fact of runs and fuels and lubricants are formed taking into account the classes of transport, drivers and branches.
Currently, Activiti already has mature forks, and we would be interested to hear about your experience with them. Write in the comments about your experience with BPMN and business process automation engines.
The material was prepared by a team of authors: Alexey Goryachev, Andrey Karpenko, Denis Rozhkov.