How can i implement an asynchronous callback scenario in Apigee.
For example i need to call a host and the host may take some time to process response. Once the response is ready that needs to be delivered to the caller/client.
Thanks in Advance
Regards
Can not claim that it is a standard way of doing this, however here is a design:
Assumption: The target host must support registering a call back URL.
When the client calls Apigee proxy, Apigee proxy in the middle can generate a unique callback URL and send to the target as a parameter when making the API request. In the meantime it would have to block the client ( and start polling an internal storage).
The callback URL would be itself be a proxy in Apigee that receives the response from the target side and then updates an entry in Apigee persistence store, which is being polled by the first proxy.
If the callback happens within say x seconds, then the apigee proxy can send the response back to the client. If it does not happen within that time than it can send back some error.
To implement you can use Key Value Map or Caching policy in apigee for the transient persistence store. And for blocking the client and polling the persistence store use java or javascript policies
Take a look at https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/async-callout and see if that helps. This sample makes the requests to the target, stores the response handles in the JS "session", goes away to do other things, and then retrieves the handles from the "session" and checks the responses.
Related
I want to standup an endpoint /foo which is a synchronous endpoint for clients but the response is dependent on a callback /foo_callback being called on the app as a result of the request to the synchronous endpoint.
to elaborate the workflow:
Flow diagram
I havent decided on a technology to use so ideally would look for a recommendation.
High level what I am thinking of is starting an async thread in the request handler and check for an update on a singleton map to see if the server has responded but I am wondering if there is a better way
I dont have control over the client and cannot really use websocket or long polling.
For the last week I've been researching a lot on the microservice architecture pattern and its requirements and constraints.
The majority of ressources suggest to use event buses/message brokers (asynchronous communication) to communicate between microservices rather than using REST API endpoints.
Synchronous calling would result in a higher response time and may cause cascading failure in case of a particular microservice failing in the chain.
Question:
Let's say the user requests a particular functionality or page on a website/mobile app which then needs to fetch data from multiple microservices and use theire respective functionalities to provide the desired outcome. But to achieve the desired outcome (response to client) ALL the services need to do their work before the backend sends the response back to the client (website/mobile app).
But if we use asynchronous service requests - which means the calling service doesnt wait for a response and would send its own response back to the client without getting the data from the asynchronously called service - the outcome might not be complete if an asychronously called service doesnt respond in time (service is unavailable or network issues). This would mean that the backend will send an incomplete response back to the client which is not acceptable.
How can I deal with this issue or did I get the concept wrong?
I'm thankful for every answer
If it's absolutely essential that a request gets a full response (i.e. that the request is synchronous), that's a strong argument in favor of the service stitching together synchronous requests and responses (and potentially needing to handle rollback in cases of partial success etc.).
Many requests don't fall into that pattern, though. For instance, a response might well be interpretable as "we've received your request and the operation will be performed. You can track the progress of your operation by using this request ID"; such an approach fits well with asynchronous messaging.
Let's imagine there is a server, that when receives a request with a car model queries all known car dealers looking for the cheapest one and responds back with the price (using whatever protocol). This actions takes a while.
In a casual blocking request/response server model, I do
request = "audi a8" // prepare a request and one line after have the response
response = server.findCheapestCar(request) // takes 20 seconds
I don't want to block my client main thread for 20 seconds, so would rather want it to be executed asynchronously. My understanding for something being asynchronous is that I can pass some sort of an object to it and carry one with my work. Once the server is ready with the response it will notify the object I passed -> Casual callback pattern.
This approach would require library match - both client ad the server need to know the object. But I want my asynchronous server built on Netty to be able to handle requests from various clients (C++/Python and others).
Where is the asynchronousness of netty coming from? What do I need on the client side to benefit from the asynchronousness?
Where is the asynchronousness of netty coming from?
Netty adopted the principle of eventloops which you may known from a language like JavaScript. This allows netty to work fully asynchronous. (For more information about eventloops and the basic underlying principle I would recommend this video about the evenloop in JavaScript)
What do I need on the client side to benefit from the asynchronousness?
Client sends request (containing payload and request id = clientside incrementing integer)
Server process the request for 50sec
Server sends response (containing the payload and the same request id the client send in his request)
Client receives the response and looks up the request id (If the client is able to find the request id and its underlying callback it will invoke it)
Hope that helped
I need to send a asynchronous message to client from my CXF (JAX WS) webservice layer...
How client would be capable of receiving it?What steps need to be taken care to achieve this?Is there a sample tutorial available?
You have two options to achieve asynchronous calls from client with CXF.
You can poll the service for response
You can define a callback which will be executed when the server's job is done
Each solution has pros and cons, so choose according to your needs.
The polling gives you a Response object and you can test if the call is complete on it by response.isDone(). (if not, wait some time, then send another request)
The callback gives you a Future object which wraps the call, you can define an AsyncHandler for instance when you call the service to define what will be run when the process is finished.
From the server side, you should take a look at WS-Addressing (to define a replyTo endpoint for callback if needed) and WS-POLICY: http://cxf.apache.org/docs/ws-addressing.html
Note that if you need to use callbacks (it seems so), you will have to define a CXF client on the client side to enable WS-addressing (on the cxf bus).
Is it possible to call (Post to) a Method in a ASPX (Code behind) page via HTTP endpoint in Sql server 2008/2005.
HTTP endpoints are first of all, deprecated. No new development should rely on them. Second, they have been, even for their brief lifetime, exclusively for incomming HTTP requests. HTTP endpoints can only serve a SOAP response, can never make an outbound call (GET or POST, mathers not). And last, all the points #gbn already made: never block a transaction on an outbound call. Do the business validation from a process call, before insert into the DB.
At worst, if no validation is possible before the insert, queue up a request for validation and place the data in a 'pending' state in the trigger, then commit. Then an external process can scan that queue and service the validation requests. You can Use Tables as Queues.
And no, CLR Web calls from triggers are no a solution (I'm sure some will mention them)...