I have a portal page where I am making many AJAX API calls (authenticated user) and we have set a limit of a maximum 1000 ajax calls for a currently logged in user. However, I am exceeding this API calls limit and am trying to log the user out and then log the user back into the environment. Upon programmatically clicking on the logout button, the user is not taken to the login page again (because there is an automatic redirection for the user to a destination page). Is there a way I can log the user out successfully and then log them in in order to make sure that the AJAX API call limit is not an issue? Kindly let me know.
I don't know of a solution to this but I do think a good idea to this problem would be something like an event listener that would count all the API calls from when the user logs in and when the max limit number is reached a script is fired that automatically re-logs the user into the system. A pop-up window can be launched to inform the user of this process if need be.
I think this would help a lot because if a user went to create a new record when they hit their maximum limit the system currently inconveniences the user and then they have to re-create the record from scratch once they log back in. I think it could be useful to post this in the idea's section if there is no current solution to this problem.
Hello and Good Day,
Is it an option to use server-side formula fields stored on the User object instead of making a large amount of client-side AJAX calls?
I find that, for the exact reason that you are asking, using a large amount client-side calls is very inefficient.
I've had times where I would convert my client-side calls to a server-side formula OR to a more concise client-side call (by trying to lessen the number of calls I make).
As you mentioned, the 1000 call limit is very hard to deal with when using a large amount of client-side calls.
I actually don't agree with your solution to log a user out and then back in. I would rather adjust your script and totally remove the need for a logout (by lessening your client-side API calls if at all possible).
If you can give the logic of why you are using a large amount of client-side calls I can help you further.
Hope this makes sense,
Concise client-side call makes sense but there's only a limited amount of information you can retrieve from one selectQuery. In order to get further information from related records, you always have to make multiple queries by using rbf_selectQuery, rbf_getRelatedIds, rbf_getFields etc. and when you do this a few times, then you run out of AJAX calls very quickly.
I fully understand your concept. Im wondering if you can get away by having the calls server-side and rendered as a formula field token instead thereby bypassing the 1000 limit. This can only work though if your queries are not user driven.
If you dont have a choice, try looking into getPage() which gets children records as well. But do be warned that performance of getPage() is very poor per my experience.
Hope this helps.
I haven't tried getPage() yet but I'll give that a go. However, I have requested for this feature to add an api call that does a lot more than just one query. Have a look at this post:
Please be aware we have added a new API in V4.5 that you may find useful for this purpose (and others :)).
Similar to rbf_getPage() and rbf_getPage2, this function fetches a set of records in a view, including (optionally) dependent records, but allows you to apply a filter to the results. It brings info back to the page using asynchronous AJAX mechanism.
Please try it out on EAP and give us feedback/discuss it in the EAP forum.