When using the SOAP API, anytime I call FilteredEnvelopeStatuses to try and retrieve approximately 200+ envelopes I keep getting an exception: "The UserID did not identify a User in the systems". I am using a production account. I seem to be at a loss as to what the message means when it comes to retrieving the envelope, since as long as I keep the number of retrieved envelopes below the stated number the code works fine, What do I need to do to exceed or better yet if possible remove this limit when calling such method or others like it?
Related
I was planning to send data messages (I do not mean notification messages!) to specific users via FCM. I tried the REST Api named ARC but since it is still in beta use it seems like there are still some issues that need to be fixed. I get "401 Unauthorized" all the time so I was looking for another way to get these messages to the users. How exactly am I supposed to send the requests to the Firebase-endpoint (https://fcm.googleapis.com/fcm/send)?
MY Request looks like this:
Request
Thanks alot!
I am developing a small REST API. As I got into analyzing all the possible failure scenarios, which I have to handle to create a reliable and stable system, I went into thinking about how to make my APIs atomic.
If we take a simple case of creating a contact through the POST API.
The server gets the POST request for the new contact.
Creates the contact in the DB.
Creates a response to send back to the client.
The server crashes before sending the response.
The client gets a timeout error (or connection refused?)
The client is bound to think that the contact creation has failed, though, in fact, the contact was in the DB.
Is this a rare case we can ignore? How do big companies deal with such an issue?
To handle this, you should make your write APIs idempotent i.e. If the same operation is executed multiple times, the result should be same as the operation was done only once.
To achieve this in your current example, you need to be able to identify a contact uniquely based on some parameter, say emailAddress. So, if the createContact is called again with the same emailAddress, check in the DB if a contact already exists with the emailAddress. If so, return the existing contact. Else, create a new contact with the emailAddress and return it.
Hope this helps.
If the request times out, the client should not make any assumption about whether it failed or succeeded.
If it is just a user making a request from a web form, then the timeout should just be exposed to the user, and they can hit the back button and check whether the operation succeeded or not, and if not they submit the request again. (This is fine as long as you always keep a consistent state. If your operation has multiple steps and fails mid way, you need to roll back.)
However if reliable messaging is important to your application you will have to use a library or build your own reliable messaging layer. This could work by having the client assign a unique ID to every request, and having another request that lets you check the result of that request ID later. Then you can do automated retries but only where necessary.
We have a user who is getting 1000 results back from a realtime API query but is expecting more.
From the docs:
https://developers.google.com/analytics/devguides/reporting/realtime/v3/reference/data/realtime#resource
It does not appear that the realtime API response contains a facility for paging.
Is it correct to assume this API endpoint:
https://developers.google.com/analytics/devguides/reporting/realtime/v3/reference/data/realtime/get
Can return a maximum of 1000 results?
You need to remember that real-time is still beta. The real-time request doesn't include a next link which means there is no way to get extra data back.
Try setting &max-results=10000 see what that returns. The max rows for the Reporting API is 10000, however I have been unable to find any information on what the max number you can set in the Real-time API is. Real-time isn't returning an error if I set it to 10000 however I don't have an account with that many real-time users so I cant test it. I am going to send Google an email to see if I can get a verification what the max number is for the real-time api.
https://www.googleapis.com/analytics/v3/data/realtime?ids=ga:78110423&metrics=rt:activeUsers&access_token={accessToken}&max-results=10000
You might want to add a issue request to issues - google analytics requesting that they add nextlink at the very least.
I am conducting test for a future project. I tried to rapidly post 100 - 200 test messages to a test user's feed from a server creating ~20 threads in parallel to send them as fast as possible. I got positive response to each one of those requests (including the id of the item being created in the body) but random number of those those messages does not appear on the facebook user's feed. For example it as ~40 when sending 200 in batch.
Any idea what could be causing this? It is weird especially considering that I am getting positive answer to each request.
Most likely Facebook spam detectors are filtering the messages after they get posted. Why would you possibly need to post 200 messages in a row to a users account? Your app would get shut down so fast. You can use the Facebook api to create a bunch of test accounts and then try distributing the posts to several different users to simulate real usage.
In Salesforce you can set up various workflow processes or build API apps that send email. For most standard Salesforce orgs, there is a limit of 1000 emails per day. (e.g. see here)
I can't find any info on what happens after you reach the limit.
e.g. what sort of errors occur, and are administrators automatically notified?
It'll throw an exception (I can't remember the exact message). I've gotten these from time to time and I think they can't be caught. A quick way to check would be create an anonymous block with an isFuture method that sends 10 emails inside of a loop. Call this isFuture method inside of another loop (also 10x) and you'll send 100 emails without hitting governor limits.
Of course you'll have to run your code 11x to get the email exception. This is a pretty shite way to do it, but it's better than clicking a button 1000x.