We are integrating with SagePay using the server integration method.
The notification POST from SagePay calls back to a PHP script our side.
Our PHP callback itself has to call several methods on an external webservice.
Sometimes, due to network latency, our callback script takes over 20 seconds to run. SagePay doesn't like this and reissues a new notification POST. This results in our callback ultimately running twice, or more, which is less than ideal (sends out multiple payment complete emails etc). Basically SagePay keeps issuing notifications until it gets a response in less than 20 seconds.
We can't just ignore the latest POST request from SagePay as they 'forget' about any previous notifications and look to receive a response from the most recent one. We can't do anything about network latency either.
Does anyone have any advice on what to do in such a situation?
The first thing your Notification callback could do is to check the transaction table and if not already updated then update the transaction table with the message and continue with your business processing, or else discard the repeated call. I wasn't aware that Sagepay only accepted a response from the most recently issued Notification callback, and this isn't mentioned in the integration guide.
You should still aim to speed it up, however. Have a think about how you might send your emails in a cron/scheduled job every minute, so that your customers are not held-up waiting for your third parties to respond. Rather than sending emails in your Notification callback you can simply add rows to an email_queue table, to be processed later by the cron job.
Related
So when I submit a braintree order for settlement, there will/can be multiple state changes until I get my money. It can settle, stay in settling, get declined, and so on.
How can I get this information without having to call their API constantly? Is there some kind of webhook for that? Because in my tests, I only get updates for disbursements, which is (if I understood it correctly) basically the last step of the whole transaction.
There are webhooks for some events, but not for specifically when a transaction changes status.
You can, however, use the Search API to create a script or cron job that checks for status changes over a period of time.
If you have additional questions about webhooks or using the API, contact Support.
If I make a request to the gmail API for Users.messages.list it will return 100 of the newest messages.
If I make another request, 1 minute later and there are no new emails it will return the same 100 most recent messages.
If I make a third request, 2 minutes after the original and there is a reply to one of the 100 most recent messages it will still return the 100 most recent messages.
The problem with this is the it only returns the message id and thread id, not if there is a new reply or not. That would mean that I would have to check every message that I have locally stored, or every one of the 100 returned messages just to know if there was a reply to it or not.
The way that works, you couldn't "check" your email via the api because if you had stored 10000 messages and you were checking replies on all of them you would use up your entire API "number of requests" allocation in a single day!
What's wrong with you Google?
Sure I could use pop3 or imap but why when I could just use something like /list_recent?
You should definitely take a look at this part of the Gmail API documentation: https://developers.google.com/gmail/api/guides/push
Basically, it explains you how you can setup a "watch" over a Gmail account and receive notifications (new e-mail, deleted e-mail, labels added...) through Pub/Sub, the messaging queue protocol from Google.
The notifications will contain an historyId, which is a kind of milestone in the Gmail account. Using the /history endpoint, you'll then get the e-mails that were added and/or deleted since this history point. You have to store the latest historyId you handled somewhere in your app, so that you can query the right changes (and not miss anything) on the next notification.
If you don't need to react to changes in real-time, maybe you can call the /history endpoint periodically, but it will definitely be less efficient at scale.
It takes a bit of work to get this working but at the end of the day you get a very efficient system able to react about changes in real-time.
I have an application which allow an user to send a lot of SMS to his contacts (like thousands).
Obviously that tasks can take a lot of time to complete.
So the idea is to display a progress bar on the client side, to indicate the user how many messages have been sent so far.
The back end of my app is a restful spring webservice.
The front end is done with ReactJS and Redux.
The question is:
Is it technically possible from the back end to periodically push data to the client, to update the progress bar, with the amount of messages already sent.
First question regarding the back end architecture:
I've seen that using JAX-RS 2 with spring, I can make asynchronous call in the back end, to execute other tasks(like querying the DB to see the messages already sent) while the other process is sending all messages. Am i looking in the right direction here ?
Second question regarding front end :
So far I use thunk functions for my requests(post/get) to the server, which returns a json response, and it works well. But in this case, the back end would periodically push data to the client side, until the main task is completed, so I don't understand how would that work out exactly ?
I guess I'm not gonna be able to achieve that using the same request ? Should I look at other technologies to achieve that ?
Please let me know, if the description of my problem is not clear.
Cheers
There are two options: you can keep track of the task on the backend and have an API endpoint to check the status and poll it every x seconds.
The other option would be to use sockets, the frontend client would listen for an event and update display onEvent. The backend would be responsible for emitting events.
I'm working on a real-time chat. I need to change statuses of the room owner and connected users, together with the UI. Since NodeJS/SocketJS/etc don't guarantee message delivery, I switched to pure Ajax for that.
The system works like that:
- User presses a button to change his status
- An Ajax request is being sent to the server, and a status change request is being saved in the queue in DB
- Users send Ajax heartbeats every second. On the server this heartbeat function also processes the queue (when sent by the room owner). Besides it sends the current statuses of users in the room in response every time.
The issue is: there might be temporary internet problems on both sides, which causes all kinds of problems. This happens due to the fact, that the heartbeat Ajax requests are being processed in an arbitrary order on the server, or the responses are being received in a wrong order on the client side. As a result users have wrong data about current statuses and the UI changes are also wrong.
What is the best approach when making a system like that? What am I doing wrong or how can I fix the issues above?
Thank you!
Have a look at Max's blog a Django-Realtime-Chat and how he does it.
I'm wondering how it's implemented in Gmail, that every time you receive e-mail, the list of mails is automatically refreshed. It looks like the server is sending some kind of event to the browser, but how is it possible? Or maybe it’s simle: the browser ask the server for new messages every let’s say 2 seconds? But it would probably kill the performance…
Anyone have some ideas?
EDIT: OK, so if it's the simple answer, how do they manage performance? When I send an email from an other account to the gmail account the view is "refreshed" almost instantly. You were saying about a simple function that returns true / false, but it must have some logic (db connection or reads some files). How they manage it?
See also: How is GMail Chat able to make AJAX requests without client interaction?
Dont know exactly which technoloy Gmail uses, but the concept is to open a channel - using reverse AJAX, comet or sprocket based techniques.
Think of it as the client requesting the server for data, but the server does not return for one minute unless it has new mail. Using this technique, the client can almost show the results in a real time manner and it does not have to poll every 2 secs. Makes sense?
gmail is, in fact, polling the server for updates. Not as often as every two seconds, though. That would be madness. A bit of testing with Tamper Data makes it look like maybe every 20 seconds, though there seem to be multiple events going through that confuse it a bit.
Regarding your edit, I imagine they might have a last-activity timestamp on the account tracking in their database, with the client polling query retrieving that via Ajax and comparing with its last sync to determine whether it needs to do a full update.
You have right with simple answer. Google Mail checking new messages on server via AJAX.
It must be some kind of ajax listener that get informations every X seconds.
I already set something like that for one of my projects. What I was doing is calling a function that was returning true or false. True if the page needed to be refreshed, false otherwise. Then if you have an update, you do another call to get the actual update. This way you don't have to refresh everything every time... but it's still intense on the server if you have a lot of users.
In other words and like chaos said, it's polling the server.