Platform with microservice architecture based on open source technology stack to reduce Time2Market any business processes
Ready-made foundation for the customer’s own development
A set of integrated open source tools and process templates for Java development based on industry-standard frameworks
A set of integrated open source tools and process templates for Java development based on industry-standard frameworks
Single front office
Combines applications on one screen, unifies user access, provides comprehensive information about the client
Combines applications on one screen, unifies user access, provides comprehensive information about the client
BPM + Robotic process automation (RPA)
Integrates and ensures the interaction of applications, automates the processes of sales and customer service, and regulates user actions
Integrates and ensures the interaction of applications, automates the processes of sales and customer service, and regulates user actions
What do we offer
The foundation for a successful start of digital transformation and the ability to eliminate architectural errors in project development
Modern open source technology stack and source code transfer for development and support by the customer’s own team
A long-term team of experts for comfortable learning and interaction
Basic microservices and tools set
- Service discovery;
- Gateway and load balancer;
- Business Process Model Validator Workbench;
- Business process engine;
- Authorization, authentication;
- User management;
- Logs collection and analysis, monitoring;
- Development and testing toolkit;
- CI/CD plugins for business process delivery;
- Administration panel
included
- Java/Groovy — business processes and services creation;
- Spring Framework — platform core;
- MongoDB — basic platform entities storage;
- Hazelcast — fast cache and microservices synchronization;
- DockerSwarm/Kubernetes — deployment and scaling;
- ELK, Prometheus, Grafana — collection, storage, logs analysis, monitoring;
- Apache Kafka — message broker;
- Angular, Vue. js, React — user interfaces creation;
- WebSocket — user interface real-time notifications
- Support for any relational and non-relational database
“Proof of concept” technology stack
interface
Flexible approach to interface development
The platform contains its own component base and style guide for popular frameworks.
Opportunity to use corporate style and tools familiar to the customer
Opportunity to use corporate style and tools familiar to the customer
Platform FAQ
At the architecture design stage, the Synplity Platform included the ideas and entities of processes, associated attributes, methods for starting, stopping, and handling events that are characteristic of the ProcessFlow API set.
Interaction with the ProcessFlow API of large corporate systems occurs in terms of describing the structures and methods of interaction between process instances.
Various specifications are supported, such as TMF701 — Process Flow developed by the Tele Management Forum, as well as its alternatives.
The depth of interaction with the systems of the corporate circuit in accordance with such specifications can be different, ranging from a simple call to the API of third-party systems (delegation of work), and ending with the need for a complete adaptation of the Synplity Platform entity structure.
Interaction with the ProcessFlow API of large corporate systems occurs in terms of describing the structures and methods of interaction between process instances.
Various specifications are supported, such as TMF701 — Process Flow developed by the Tele Management Forum, as well as its alternatives.
The depth of interaction with the systems of the corporate circuit in accordance with such specifications can be different, ranging from a simple call to the API of third-party systems (delegation of work), and ending with the need for a complete adaptation of the Synplity Platform entity structure.
Rules can be obtained from outside by working with scripts. For example, the client has a certain service that takes as input the data of the user working with the system (or whose client it serves), and at the output it provides information about available operations. In scripts, you can refer to this service at the desired stage and, based on this, build the logic of transition to another stage, or adjust the composition of the data displayed at the current stage, or not let it into the process/stage. In the end, if it is possible to reuse any logic in scripts, you can put the same rules into a separate script utility, for example, and call them briefly in scripts. In addition, it is possible to specify tags / groups for the user of the system, which allow you to restrict access to the stages of the process, calling certain rules, access to the API in general.
In the part of the pipeline for scripts, there are auxiliary tools — a library for developing scripts and writing unit tests for them. Running project unit tests can be configured in the CI tool you are using.
A maven-plugin was written for deployment, which has two functions: the first is to validate the project structure (location of scripts) and a description of the process model and graph; the second is to put the whole structure together and update it at the specified stand. By changing the plugin settings and running it in the same CI, you can roll out process changes to a test or production environment.
In terms of the pipeline for modules, everything is standard — build a docker image in CI, update the stack.
A maven-plugin was written for deployment, which has two functions: the first is to validate the project structure (location of scripts) and a description of the process model and graph; the second is to put the whole structure together and update it at the specified stand. By changing the plugin settings and running it in the same CI, you can roll out process changes to a test or production environment.
In terms of the pipeline for modules, everything is standard — build a docker image in CI, update the stack.
There are two options.
The first is to implement audit in your own way, by creating a module and a database for it with the desired structure of records, and then add records there by calling this module from scripts via Rest or Kafka.
The second is to use our implementation of a similar module, which also allows you to add audit messages from scripts. There is also a spring-boot plugin library that wraps your modules' APIs with aspects that will fire according to a customized pattern when these methods are called, sending audit events to the module.
The first is to implement audit in your own way, by creating a module and a database for it with the desired structure of records, and then add records there by calling this module from scripts via Rest or Kafka.
The second is to use our implementation of a similar module, which also allows you to add audit messages from scripts. There is also a spring-boot plugin library that wraps your modules' APIs with aspects that will fire according to a customized pattern when these methods are called, sending audit events to the module.
Versioning scripts and the process model would be most logical with the help of GIT, because. it is more convenient to develop them there. And the interface is a static part that depends only on the data of the process instance (this data is described by a contract that both the backend and frontend observe for mutual understanding and elimination of errors), then different versions of the same process must be separated by different identifiers and an additional call should be added to client or in scripts (if the process is created according to the logic of an external process) to select the process variant to be launched.
Logging implemented with slf4j & logback, logs are served on ELK cluster. The composition of indexes with example values is as follows: module name ("sp-core"), logger name ("sp.commons.request.Filter"), date, thread name ("asyncExecutor"), logging level ("INFO"), main trace identifier ("asddsj32r87gtksdf094"), child trace identifier — if the main thread spawned several substreams ("asddsj32r87gtksdf093"), and the message itself + stacktrace. By trace identifiers, you can trace all the actions caused by an external call in different microservices. You can write your search queries in Lucene syntax. There are tables with descriptions of all loggers and examples of their messages in system modules.
If we consider the development of the front from scratch on popular frameworks, for example, Angular, then we need to take open source developments as a basis, work out the architecture of the service, select a component base and / or write our own, work out the interaction contract with the Backend. In the case of using the Synplity platform, you get a component base with the ability to use your own / others, a style guide (integrate your own / others), a well-developed and documented architecture and a contract for interaction with the Backend. This greatly improves the speed and quality of project implementation
1. Recommended operating system
— CentOS x64 current version
2. Equipment for 75 thousand running business processes per day, each of which makes up to 10 calls to external systems.
— 21 servers — Kubernetes/DockerSwarm worker nodes, 64 GB RAM, 16 CPU cores, 135 GB disk.
— 3 servers — Kubernetes/DockerSwarm control nodes, 8 GB RAM, 4 CPU cores, system disk only.
— 3 servers — MongoDB, 32 GB RAM, 16 CPU cores, 150 GB disk.
— 3 servers — Kafka, 32 GB RAM, 16 CPU cores, 200 GB disk.
— 1 server — ELK, 16 GB RAM, 8 CPU cores, 1000 GB disk.
— 2 servers — HA Proxy, 4 GB RAM, 8 CPU cores, 150 GB disk.
— 1 backup server — optional.
3. Equipment for 30 thousand running business processes per day, each of which makes up to 10 calls to external systems.
— 9 servers — Kubernetes/DockerSwarm worker nodes, 64 GB RAM, 16 CPU cores, 135 GB disk.
— 2 servers — MongoDB, 32 GB RAM, 16 CPU cores, 150 GB disk.
— 1 server — Kafka, 32 GB RAM, 16 CPU cores, 200 GB disk.
— 1 server — ELK, 16 GB RAM, 8 CPU cores, 1000 GB disk.
— 1 server — Nginx, 4 GB RAM, 8 CPU cores, 150 GB disk.
— 1 backup server — optional.
4. Equipment per 10 thousand running business processes per day, each of which makes up to 10 calls to external systems.
— 3 servers — Kubernetes/DockerSwarm worker nodes, 32 GB RAM, 8 CPU cores, 135 GB disk.
— 1 server — MongoDB, 16 GB RAM, 8 CPU cores, 150 GB disk.
— 1 server — Kafka, 16 GB RAM, 4 CPU cores, 200 GB disk.
— 1 server — Nginx, 4 GB RAM, 4 CPU cores, 150 GB disk.
— 1 server — ELK, 16 GB RAM, 8 CPU cores, 500 GB disk — optional.
— 1 backup server — optional.
— CentOS x64 current version
2. Equipment for 75 thousand running business processes per day, each of which makes up to 10 calls to external systems.
— 21 servers — Kubernetes/DockerSwarm worker nodes, 64 GB RAM, 16 CPU cores, 135 GB disk.
— 3 servers — Kubernetes/DockerSwarm control nodes, 8 GB RAM, 4 CPU cores, system disk only.
— 3 servers — MongoDB, 32 GB RAM, 16 CPU cores, 150 GB disk.
— 3 servers — Kafka, 32 GB RAM, 16 CPU cores, 200 GB disk.
— 1 server — ELK, 16 GB RAM, 8 CPU cores, 1000 GB disk.
— 2 servers — HA Proxy, 4 GB RAM, 8 CPU cores, 150 GB disk.
— 1 backup server — optional.
3. Equipment for 30 thousand running business processes per day, each of which makes up to 10 calls to external systems.
— 9 servers — Kubernetes/DockerSwarm worker nodes, 64 GB RAM, 16 CPU cores, 135 GB disk.
— 2 servers — MongoDB, 32 GB RAM, 16 CPU cores, 150 GB disk.
— 1 server — Kafka, 32 GB RAM, 16 CPU cores, 200 GB disk.
— 1 server — ELK, 16 GB RAM, 8 CPU cores, 1000 GB disk.
— 1 server — Nginx, 4 GB RAM, 8 CPU cores, 150 GB disk.
— 1 backup server — optional.
4. Equipment per 10 thousand running business processes per day, each of which makes up to 10 calls to external systems.
— 3 servers — Kubernetes/DockerSwarm worker nodes, 32 GB RAM, 8 CPU cores, 135 GB disk.
— 1 server — MongoDB, 16 GB RAM, 8 CPU cores, 150 GB disk.
— 1 server — Kafka, 16 GB RAM, 4 CPU cores, 200 GB disk.
— 1 server — Nginx, 4 GB RAM, 4 CPU cores, 150 GB disk.
— 1 server — ELK, 16 GB RAM, 8 CPU cores, 500 GB disk — optional.
— 1 backup server — optional.
it might be interesting
CTO of Synplity Platform Development Center
Nicolae Ermolar
Head of Analytics Department
Anthony Zeniukowski
Head of Synplity Platform Development Center
Alex Savelini
Chief Business Architect. Lecturer at the Institute of Intelligent Cybernetic Systems of Eastern Europe
Sergio Mitronescu
The project team
Do you want to launch new services before your competitors and not spend years on development?
Fill out the form and we will promptly answer you!
Fill out the form and we will promptly answer you!