magnett-automation-core VS conductor

Why use a library dedicated to process automation in particular? After having worked for more than 20 years and dedicating so much of this time to make integrations, either with internal or external systems, such as payment gateways, and seeing several strategies from dedicated applications to make these integrations, such as BPM's, ESB's, custom systems, etc., I believe that in one way or another, when that integration was not direct "A" calls "B" but that it had a certain logic "A" calls "B" with the result of "C", or the error control involves transaction rollback, was when the problems began. The code that was in charge of the orchestration often lost that separation of responsibilities between integration (data mapping, security, etc.) and the orchestration of the same. The code lost readability and became difficult to reuse and test, among other things. The creation of this library intends to alleviate all these weaknesses. It covers all kinds of scenarios and allows to have the orchestration encapsulated and tested independently. It also allows the creation of flows as if it were a single service and facilitates the reuse of code, as we can create our own libraries with the definition of our flows. For more details regarding this library, please visit its GitHub page: [https://github.com/LHPiney/magnett-automation-core]

Meanwhile, don’t forget to ⭐ our Conductor OSS repo here!