Implementing Simple / Complex Approval Workflow for an Existing Application (ASP.NET MVC, AngularJS, SQL Server Architecture) with ELSA (.NET 5.0)

[sranjan-m]

Hello.
I have a scenario and I just want to make sure if it's possible and need some assistance on how to implement the ELSA workflow in our existing application's architecture.

We already have an existing application (an ERP System) which is on ASP.NET MVC (back-end), AngularJS (front-end) and SQL Server (database). We have several simple as well as complex Approval Flows which were done in SQL Server Stored Procedures and doing a great job in the Production for the last 3-4 years.

As an improvement and maintainability measure, now we are planning to implement the ELSA Workflow as a standalone application (.NET 5.0 and MongoDB for Persistence Storage) and we want our ERP System to communicate with the ELSA Application when a user Sends any record for Approval or any Approver Approves/Rejects any request in our ERP System.

Here's a descriptive example.

1. User creates a Record in our ERP System.
2. After keying in and verifying the data, the User sends the record for Approval. Here we need to update the Status in our SQL Server as well as trigger the ELSA workflow from our ERP System's Api to proceed to the next Configured Activity (e.g: Approval by Approver 1) and send acknowledgement by Email (or any other technique).
3. When the Approver 1 approves the record in the ERP System we need to again update the Status in SQL Server and trigger the ELSA workflow to proceed to the next Configured Activity (e.g: Approval by Approver 2)... And so on....

I have gone through the Documentation, and have some idea about configuring the ELSA Workflows, but when it comes to implementing it in our architecture it feels bit challenging and not sure how to proceed with the development.

Any assistance or any reference matching our architecture (need not to be exactly the same as ours) would really help to at least refer and start with the development and build on top of it.

Thank you.

[sfmskywalker]

Although I don't have a reference application or example project available yet, your use case scenario seems to be a classical one. A customer is implementing a very similar architecture. Here's what they are doing:

1. They have an ASP.NET Core project that represents the Workflow Server, which uses Elsa.
2. The project exposes a set of API controllers that is consumed by their portal application (the equivalent of your ERP system).
3. These controllers use Elsa to start and resume workflows.

Depending on your specific needs, the most simple approach might be to use Signal Received activities that represent approvals from your ERP.

The communication would go a little bit like this:

1. User submits a Record into your ERP system and invokes an API endpoint in your Workflow Server, e.g. POST /notifications/records/{recordId}/created.
2. The API controller action triggers Elsa with a named signal "Record Created", providing the Record ID as the correlation ID. For this you would use the ISignaler service.
3. You have a workflow that starts with a Signal Received activity that is configured to trigger on "Record Created" signals. Because you are providing a correlation ID when using the signaler service, the workflow instance will be correlated with the Record ID.
4. The next activity might be a Send Email activity, notifying those whom need to approve the created record.
5. The next activity in the workflow would be another Signal Received activity, this time configured with "Approved" as the signal name. This will suspend the workflow from further execution until it receives the "Approved" signal.
6. When the Approver approves the record in the ERP system, you send an HTTP request to another API controller, e.g. POST /notifications/records/{recordId}/approved.
7. This API controller action also uses ISignaler to send a signal, this time using the "Approved" signal name and of course the Record ID as the correlation ID. This will resume the correct workflow instance that is blocked on the "Approved" signal for the specified Record ID.

You can see how this can go on and on. And since you are using Elsa, it will be easy to use control flow activities such as If/Else, Switch and Fork/Join activities, send emails, wait for timer events, and of course easily extend it with custom activities to better model your domain.

I hope this helps. If you have more questions, I would love to hear them.

[sranjan-m]

Thanks a lot for your time. We'll try to proceed as per your suggestion and see how it goes.
Also, we're looking at this tutorial of you and hope it'll help us and give some idea in implementing in our architecture.

Thank you.