I have a script which is taking 6 seconds to run. I removed a line of code which submits some data at the end before serving a dialog to the user, and the time dropped to 1.5 secs. This submitted data is not vital for the user but it does need to be submitted. Is there a way I can submit this data in the background while serving the dialog to the user.
Use Promise API available in NetSuite, it will create a different thread for each request.
Related
With IBM ICD/Maximo version 7.6.1.2 I am trying to inform a user when an attachment (arriving via a REST call) has finally arrived.
I have access to the USERID of the requester
the launchpoint is 'add' on DOCLINKS
I aim to inform the user using a message box (or something similar) if he/she is still active on the platform
The whole send/receive action takes more than 10-15 minutes so waiting for a response during the same REST call is not possible. The user sends a POST and later receives a POST.
The problem is, mbo.getUserInfo() points to the username of the external service and not the requester so in my opinion I need to either change the active session or active user in order to be able to use commands like:
service.webclientsession().showMessageBox(msggroup,msgkey,params)
I need a method or commands to do that.
One possible way to do this would be by sending a bulletin board message to the user to notify that their file has been uploaded as shown here
I've been building a prototype for account information gathering using the Yodlee API, and was playing around with their pre-made UI at first.
All of the features for the Fastlink UI worked, however the load times for after log-in processing were unacceptably slow...sometimes taking up to 30-45 seconds for verification and information display.
Is this normal?
Figured out the issue. The bulk of the delay times comes from the delay for the registry of MFA services.
The providers/providerAccounts/{id} endpoint is continuously called until the MFA data is available which in some cases takes some time.
I have read this article
Please explain the refresh process that yodlee employs..
We understand this happens within a 19 hour window, is there anyway to stop the automatic refresh (the initial refresh on a Site based AddAccount1 is fine) - so that the subsequent refreshes can be manually controlled.
Thanks
The automatic refresh can be turned off for any client by Yodlee. You can contact the customer care team by logging a service request through YCC(Yodlee customer care ) tool and they will help you with that.
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.