As a user that creates a charge using the DataHub user interface
I want to be notified synchronously with the result of my action
so that I know whether the charge fulfills all requirements to be created.
This spike should clarify whether (and how) or not, we can provide a synchronous response to the user.
Background information
As the result of the implementation of #1836 (and/or one or more stories covering the same story), it is possible to create a charge using the DataHub UI, but as a user, you will not be notified whether the charge could be created or not unless you use the B2B interface to get the result of the asynchronous create-operation.
Tech notes
The idea currently at stake is that we could create an endpoint in the Charges.WebAPI, which could verify a charge using all existing charge verification rules, and respond with a verification result synchronously. This endpoint could later be used to enable or disable the request to actually create the charge as implemented in #1836
Questions
How do communicate with the frontend if a command was accepted or rejected in an async setup? (SignalR?)
How do we avoid sending B2B confirmations/rejections when a charge was created through frontend? (ServiceBus messageTo?)
Batman thoughts?
Acceptance criteria
[ ] A clarification in the form of a technical solution that makes it possible to respond synchronously to whether the provided charge fulfills all requirements to be created.
As a user that creates a charge using the DataHub user interface I want to be notified synchronously with the result of my action so that I know whether the charge fulfills all requirements to be created.
This spike should clarify whether (and how) or not, we can provide a synchronous response to the user.
Background information As the result of the implementation of #1836 (and/or one or more stories covering the same story), it is possible to create a charge using the DataHub UI, but as a user, you will not be notified whether the charge could be created or not unless you use the B2B interface to get the result of the asynchronous create-operation.
Tech notes The idea currently at stake is that we could create an endpoint in the Charges.WebAPI, which could verify a charge using all existing charge verification rules, and respond with a verification result synchronously. This endpoint could later be used to enable or disable the request to actually create the charge as implemented in #1836
Questions
Acceptance criteria