In my project.i have below requirement.
we have to send some request to ATM.
so before sending response Atm will send some notifications.
As per requirement we have to listen the notifications and some how we need to send these content of this Notification tag to presenter.
for example
we are sending request to ATM---Rq1
then it sends some notifications like N1--it is a xml so for example value tag value is "some text".so this we need to send to presenter.if again we receive
N1 then needs to send the value tag value to presenter.so all these should send to presenter immediately.
once we receive response from ATM we can send the response data by using RPC.
The main motive is if we receive notification at 10:00 AM then we should send value tag value to the presenter.then next notification if we receive at 10:01 that value tag also we need to update to presenter.
So kindly advise us..if my question is not clear kindly let me know.
To my knowledge, an RPC call will only return once. And a server cannot directly communicate to a browser like the browser can to a server.
You might want to implement an asynchronous polling system. Essentially, your call your main RPC service, call it bigMethod(). After you call it, you immediately and asynchronously begin calling a polling method. just call it poll().
Every second or two, (or however long you think), it runs out to the ATM to check if there's a message. Once bigMethod() finishes you stop polling.
The downside is that this solution will require some tweaking of the back end code to handle it.
Related
We have implemented a Logic app to call do a POST call to a third-party API which returns a 202 with location header. The Logic app in the backend automatically polls using the location header resulting in GET request to the third-party provider hoping to receive a 200 response once the processing is complete. However, the GET requests are resulting in 404 errors.
We have tried disabling the check location headers but for some reason Logic apps still continues to send the GET requests and at a faster rate.
Is there any way to stop the GET request from Logic Apps or should this be the third-party provider's responsibility to handle the polling and not send 404's?
Yes, you can stop the GET request from your Logic Apps. Basically it totally depends on your workflow. If you are designing a stateful workflow then I would suggest that not to stop the GET request.
For stateful workflow all HTTP-based actions follow the standard asynchronous operation pattern as the default behavior. Where after an HTTP action calls or sends a request to an endpoint or API, the receiver immediately returns a "202 ACCEPTED" response. And the response can include a location header which the caller can use to poll or check the status for the asynchronous request until the receiver stops processing and returns a "200 OK" success response or other non-202 response.
But if you are designing a stateless workflow, then caller doesn't have to wait for the request to finish processing and can continue to run the next action. In this case the receiver return the "202 ACCEPTED" response as-is, and proceed to the next step in the workflow execution. A stateless workflow won't poll the specified URI to check the status.
You can stop the GET request from your logic app by following any of the two approaches mentioned below.
Turn off Asynchronous Pattern setting.
You can achieve this by going to the Logic App Designer, on the HTTP action's title bar, selecting the ellipses (...) button and setting Asynchronous Pattern to Off if enabled.
Disable asynchronous pattern in HTTP action's JSON definition.
In the HTTP action's underlying JSON definition, add the "DisableAsyncPattern" operation option to the action's definition so that the action follows the synchronous operation pattern. Check this document for more information.
Also check this Asynchronous request-response behavior document by Microsoft for more understanding.
I was looking at Microsoft's duplex WCF sample:
It starts here but the interesting bit is here at the end with the client.
// Wait for callback messages to complete before
// closing.
System.Threading.Thread.Sleep(5000);
// Close the WCF client.
wcfClient.Close();
Console.WriteLine("Done!");
If you take out the Sleep, you will get an exception
The session was closed before message transfer was complete.
So clearly the client knows there's stuff in the air, is there a way to ask it for its current status? There's a state but that just defines whether it's open or closed (i.e. connected not active).
This is not entirely true. Your methods are one-way method calls. So, when you call the service from your client, that call (or set of calls) is completed. In other words, the "message" has been delivered to the service and there is no expectation for a response since it is one-way. It might callback on the callback contract...it might not.
When you setup Duplex channel, you're standing up an endpoint for the service to call back on (client becomes a service essentially). If you close the client, then if/when the service decides to call back, the communication exception will occur. That's just the way this message exchange pattern works.
You really sort of answered your own question. Which is, when you check the status it is either open, closed (or faulted). When you're using a duplex channel, open in this case means there is potentially "activity" on the channel. That's why the sleep is there - to allow the service time to call back. If you look at the SDK sample (http://msdn.microsoft.com/en-us/library/vstudio/ms752216(v=vs.110).aspx), it's basically doing the same thing except it sits there waiting for you to press ENTER before it closes the client application.
So, in a real application (not a console based sample like these are), either keep your client proxy active or change your message exchange pattern to a request/reply pattern.
If a call is incoming when using a Client Browser (twilio.js) and I am already connected to an active call in the Client Browser. Client Browser doesn't ring or given any indication of an incoming call while I'm already on a call with someone else.
Is this a bug? What can be done about it so I can tell if there is an incoming call? I need to be able to answer that 2nd, 3rd, 4th, etc... incoming call should I have multiple people calling my Twilio number at the same time.
Kind of a late reply but you can use the Enqueue verb to place your callers in a queue, and then use the REST API with a javascript setInterval to list the callers in the queue. After that you can dequeue them with a Dial method or via the REST API.
We have crafted call-center functionality in node using a similar method where callers are placed in a queue which triggers a setInterval loop that monitors the queue for its members, and also looks for available agents to call.
For anyone interested I have solved this problem for myself, but in a different way to what #Ding suggests.
I'm not sure if the API has changed since this questions but you are able to access multiple Connections from a single Twilio.Device(). See this question for more details: Twilio call routing/management for small customer service team
I am using RestKit to request data and perform actions using this data.
Once I have parsed the data and displayed it to the user, they can select an item to initiate playback. When the user has selected the playback the server will respond with a response code, but the server also notifies the app when the playback has finished.
e.g.
client server
request data ->
<-respond with JSON
request_playback ->
<-playback_started OK
<-playback_stopped OK
Hope that the diagram helps out.
I need the App to be aware of changes on the server, in this example playback started/stopped or recording started/stopped.
So basically Is there a way for RestKit to accept a response that is not initiated by a request?
Thanks for your help.
Greg.
You should look into things like 'long polling' or 'reverse AJAX' or 'web sockets'. These are all techniques to be able to leave a connection open to the server and continuously receive responses from the server.
Maybe an alternative cleaner solution is to use Apple's push notification mechanism.
My WCF service(hosted as Windows Service), has some 'SendEmail' methods, which sends out emails after doing some processing.
Now, I have got another requirement where client wants to preview emails before they are being sent out, so my WCF service needs to return whole email object to calling web app.
If client is happy with emails object, they can simply click 'Send out' which will then again call WCF service to send the emails.
Because at times it can take a bit longer for emails object processingy, I do not want calling application to wait until emails object is ready.
Can anyone please guide what changes I need to make to my WCF service (which currently has all one way operation)?
Also, please guide me whether I need to go for Asynch operation or message queuing or may be a duplex contract?
Thank you!
Based on your description I think you will have to:
Change current operation from sending email to storing email (probably in database).
Add additional operation for retrieving prepared emails for current user
Add additional method to confirm sending one or more emails and removing them from storage.
The process will be:
User will trigger some http request which will result in calling your WCF service for processing (first operation)
WCF service will initiate some processing (asynchronously or firt operation will be one-way so that client doesn't have to wait).
Processing will save email somehow
Depend on duration of processing you can either use AJAX to poll WebApp which will in turn poll WCF service for prepared emails or you will create separate page which will user have to access to see prepared emails. Both methods are using second operation.
User will check prepared email(s) and trigger http request which will result in calling third operation to send those emails.
You have multiple options:
Use Ladislav's approach. Only to add that service returns a token and then client uses the token to poll until a time out or a successful response. Also server keeps these temp emails for a while and after a timeout purges them.
Use duplex communication so that server also gets a way to callback the client and does so when it has finished processing. But don't do this - and here is my view why not.
Use an Asynchronous approach. You can find nice info here.