Api Gateway to FraudCheckApiMediatorService communication

[vadivelanmuthuramalingam]

Hi

Is it possible to provide the sample code between API Gateway service & FraudCheckApiMediatorService by using solace request/reply approach instead of HTTP Post operation.

Example: Api Gateway is request/publish the message to FraudCheckApiMediatorService and waiting the for the final response and the same response is send back to Api Gateway consumer

Regards Vadivelan M.

[itsJamilAhmed]

Hi Vadivelan, thanks for checking out this repo.

For the sample code you are looking for, I assume you mean an end-to-end flow like the one here, just without the microgateway feature doing the translation from HTTP to messages?

You could indeed build an equivalent service that takes HTTP as input and then builds a properly constructed request message to kick off all the other services in this repo. Need to make you aware that this new service will end up with some unavoidable state though, meaning one instance cannot take over the work of a failed one without some coordination first. (Or in a more simpler setup, you could have all active HTTP operations to an instance get abandoned/timeout if it fails.)

I use the microgateway specifically to avoid this so that the event broker is responsible for keeping that state and open handle to the HTTP operation. That state can happily fail over with the HA deployment of the broker too.

In short, the whole architecture stays much simpler if you are able to use the microgateway feature to bridge the synchronous world with the asynchronous.

[vadivelanmuthuramalingam]

HI Jamil

Thanks for your response, is spring cloud stream is supporting request-response patter like scenario below:

I have some business logic in Service A its depends with service B.

Like, service A is sending request service to service B and A compiler is waiting for the response to proceed the next line code.

Is Spring cloud is supporting request-response (sync) communication? Is it possible to achieve without HTTP post call?

How Api micro gateway is understand the particular response is to particular consumer? Can you provide the HTTP Post request header values?

When the application error handling topic is invoked for timeout scenario.

[itsJamilAhmed]

Hi Vadivelan,

is spring cloud stream is supporting request-response patter like scenario below: I have some business logic in Service A its depends with service B. Like, service A is sending request service to service B and A compiler is waiting for the response to proceed the next line code. Is Spring cloud is supporting request-response (sync) communication? Is it possible to achieve without HTTP post call?

With spring cloud stream being message-oriented communication over publish-subscribe semantics, my first thought would be no to its suitability for the coupled synchronous communication you describe. It's really the type of architecture to be moving away from.

How Api micro gateway is understand the particular response is to particular consumer?

For every HTTP operation, the microgateway assigns a specific replyTo address on the outbound message that is created. A response message arriving on that topic asynchronously is enough to correlate back which response is intended for which HTTP operation.

An example replyTo header looks like this: solace_replyTo=#P2P/v:pri-aws-eu-west-1a-7n4ccrr6k2q/#rest-93e75c9d519c2d48/POST/fraudCheck

Can you provide the HTTP Post request header values?

Yes on the HTTP operation, you can set headers and those will be accessible on the resulting message in the headers for it. In the example below, I set a header in postman called "myHeader" with content "myContent". It is then on the message in this header prefixed by the string JMS_Solace_HTTP_field_:

JMS_Solace_HTTP_field_myHeader=myContent

Doc ref here.

You can see all the headers by adding a line like so in the mediator service: log.info("Headers on the message: " + input.getHeaders().toString());

When the application error handling topic is invoked for timeout scenario.

The services currently handle a timeout scenario between the mediator service and the orchestrator service picking up the request to trigger all other necessary services. The mechanism for that is applying a message time-to-live (TTL) of 3 seconds (3000ms) so that if its still on the queue and unconsumed when the TTL triggers, the message gets moved to a different queue instead. That different queue is then the inbound channel for the Error Handling service so it can timeout gracefully that call. With multiple competing instances of the orchestrator service able to run, no instance being able to pick up that service in the 3 second time should be rare in a final deployment.

Hope all that helps clarify.

Thanks Jamil

[itsJamilAhmed]

Hi Vadivelan, closing this issue as you have separately confirmed the microgateway feature has worked successfully for you to handle this requirement of communication between an API Gateway and the first microservice using events.