This questions is in reference to Yodlee data extract procedures.
The example and diagram towards the bottom of the page depicts a call to getRefreshedUserItems every minute. I'm assuming this example passes input parameters (refreshDataFilter.startDate and refreshDataFilter.endDate) which span one minute of time. In the diagram, 40 items are refreshed before getRefreshedUserItems is called again the next minute.
Is it necessary that all items are successfully retrieved on behalf of consumers before the next call to getRefreshedUserItems? I'm imagining a scenario where there may be too many items to retrieve in a given minute. Can the retrieval of items be queued and processed while the refresh continues to loop every minute?
Answer to your question:
Is it necessary that all items are successfully retrieved on behalf of consumers before the next call to getRefreshedUserItems?
No, it is not necessary that all the items were refreshed successfully. In case of failure item, where user action is required for e.g., like Password expired etc you can update those items in your data base and ask user to perform required action. In case of any other error, Yodlee re-schedule's the refresh for that item.
Can the retrieval of items be queued and processed while the refresh
continues to loop every minute?
As, number of items should not be huge this is why Yodlee recommend to call this API every minute and get those items and may be queued and processed while continuing the loop to retrieve next set of items.
Related
I plan to send personalized emails to multiple recipients via AWS SES.
Amazon recommends here to call multiple times the SendEmail method, once for every recipient, instead of just one single call including all recipients at once. However, I'm afraid to hit some API rate limit when calling this method multiple times as they suggest.
They also state here that:
All actions (except for SendEmail, SendRawEmail, and SendTemplatedEmail) are throttled at one request per second.
without specifying the actual limit for the above-mentioned methods, which I haven't been able to find somewhere else.
Does anyone know what is the actual rate limit when calling SendEmail?
You can retrieve this information from the AWS SES dashboard or by using the GetSendQuota API.
The GetSendQuota returns the following:
Number of emails you have sent during the past 24 hours
Sending quota for the current 24-hour period
Maximum send rate
Maximum send rate determines the no. of mails you can send per second.
You can apply for increasing the quota (i.e; both no. of emails you are allowed to send per second and max. send rate).
More info on the same here.
Attaching the screenshot of SES dashboard for reference.
How to calculate Session Duration or Call Duration in TokBox API?
We need to display Session/Call duration for each Session-Id, we created from Backend. In our case, only 2 people can connect to a session as we are sharing session-id & token with two users only. Now On the Admin Panel, we need the Actual Call time between these two users.
Is there any API which provides these statics?
There is no such API to calculate the exact call duration.
You can check your invoices on the dashboard under the billing section.
Another way is, you can log the timestamps on event listeners. Like when the first-person joins the session, connectionCreated event gets fired, in that you can log your time stamp and send it to your server. Similarly, when someone leaves the session, you get connectionDestroyed event. Refer to this page for all events related to the session.
You can also refer to our Session Monitoring API - https://tokbox.com/developer/guides/session-monitoring/ which lets you receive real-time session callback events on your server endpoint thereby monitoring the user's session activity.
By using the events mentioned above you can calculate the session duration.
Thanks!
Please explain the refresh process that is employed when refreshing transaction data, answering the following questions:
1) How often does this refresh happen?
2) What time does it happen?
3) Does it happen at different times for different institutions?
4) IF a refresh fails for a particular account for one user, how is that handled?
5) What happens if all txs from one bank for all users fails?
1) How often does this refresh happen?
Yodlee does a refresh on a daily basis during a 19 hour window. This also depends upon the type of account and also the error state of that account.
Example - Bank / Credit card accounts are refreshed on a daily basis but loan and mortgage are refreshed on a weekly basis.
Also account in a 402(invalid credential) error is not refreshed at all.
2) What time does it happen?
Between 10 am to 5 am PST.
3) Does it happen at different times for different institutions?
No, it's dependent on the automatic refresh logic of Yodlee. It doesn't vary based on institutions.
4) IF a refresh fails for a particular account for one user, how is that handled?
Depending on the error code the next refresh is scheduled. If the refresh failed with UAR then account is never refreshed by Yodlee. If refresh failed by agent or site error , then the refresh is again scheduled for a later time.
For error codes please refer error_code document
5) What happens if all txs from one bank for all users fails?
If the refresh fails then no new transaction is scraped and old transactions will still be with Yodlee.
Our site uses Facebook connect. When a new user signs up we ask for permission to pull their interest data, their list of friends, and their friends' interests. Fetching this data used to be a very quick process (couple seconds). Over the last week or so, the time to fetch this data has increase to 10+ seconds. According to Facebook insights, our site is not being throttled. We didn't make any changes to our site.
Anyone else experiencing this issue with Facebook? Have any ideas for how to address it?
Thanks!
As of 1/26 at 7:55 PM EST, the live status page doesn't indicate any irregular activity.
Sometimes this occurs because a user simply has a lot of likes and interests. I would recommend making this operation asynchronous following a flow something like this:
User connects with your app
Get the access token and store it in a queue that a background process can access.
Get all the information you need immediately to make the app work.
Some time later
In a background process, grab an access token from the queue, parse it and handle it however you'd like.
A simpler, although less stable option, is redirecting the user to a page upon installation which makes an AJAX request to that page telling it to download the information from the graph. This keeps the response time low, but does require your user to have Javascript enabled and for them to stay on the destination page long enough for the request to be created.
I'm working on a project that require my application to pay the user to his paypal account when he asks it.
Here's how I did it so far:
The (logged) user goes to the Pay page that will list all his Payments (received or not)
He enters his Paypal email and his application (mine) password (for security)
The POST page get a list of all the Payments that have status="UNPAID" for that user and update the status to "WORKING" (to avoid the user to refresh the page before the whole process is done and resend the same amount of money)
We count the total amount to pay in that list (a simple for)
The amount is sent to Paypal via Paypal Adaptive Payment API (request: PAY)
The response is checked, if completed, the list status is set to "COMPLETED", if not, the list is reverted to "UNPAID" (the SQL update is made via a WHERE id IN(x, y, z) in case a second Payment request has been made during that time.
A message is then displayed to the user
But I need your help, I'm in front of one risky problem I'd like to avoid, and I would know how you would do:
If the user hit refresh on the process page, I don't want to send him twice (or more) the amount (The "WORKING" lock is here for that, but what happens if the user hit refresh before I set the lock ?)
Rare possible: what happens if the user hit f5 after the lock "WORKING" is made, but before the request to paypal, and a new payment is received. By following what I did, just one item (the new) would be get and set to WORKING, but all others previous payment would be losts
How would you do? What is the best way to make it to be 100% reliable?
Thanks for your help
Note:
The steps between 4 to 6 is made via a PlayFramework jobs, called with now() and awaiting() the result
you can:
prevent double post via JQuery
use the checkAuthenticity() method to validate the request
do a GET redirect after processing the POST (so they can't submit the same 2 times even by mistake)
do the payment processing asynchronous (see below)
For the payment, instead of calling the job, set the id's of payments in a queue (or table in the database) and a job that runs once per minute that processes that table if it has some data. When the user does the POST you redirect to a page that says that you are processing the payments and will notify if there is some issue. You can notify the user later via a UI warning using comet or via mail.
That way you don't link the request to the processing, and you won't have threading/racing issues, as well as being able to detect stale requests (payments already done) if you do a sequential processing.