<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=287945&amp;fmt=gif">

Workflow processes that become Microservices

Posted by FlowWright on Jul 27, 2019 7:47:13 AM

Microservices can be architected in many ways; most depend on a lot of custom code, or modules strung together that then provide Microservices.  FlowWright takes a different approach to designing Microservices with the users in mind. We share more below.

Essentially, Micorservices within FlowWright have always been available to users, but up until now we weren't sure how to architect that message for users. Historically, Microservices were possible, but cumbersome to implement.  Implementing Microservice today lends to a developer understanding the object model of FlowWright, and the proper calls and parameters to the REST API.  Also the order of the REST API calls.  Here’s a view of the current architecture:

current REST API architecture within FlowWright

The current FlowWright REST API is a wrapper around the high performance .net API, giving you the performance and web services.

In FlowWright v9.6, Microservices implementation is simplified, where you can design a Workflow Definition and turn that definition into a Microservice.  The new Microservice architecture looks as follows:

v9.6 FlowWright Microservice architecture

Easily design your Microservice graphically as a Workflow definition, then use that workflow definition to define a Microservice.  Any changes to the Microservice is a simple drag and a drop away.  Once the Microservice is defined and compiled, it can be tested right within the FlowWright user interface, or use your favorite REST API call tester such as POSTMAN to test the calls. 

Have questions on how to build out your Microservices? Let's Talk! 

New Call-to-action

 

Topics: workflow validation, micro services