How to resolve Webcallout error System.LimitException: Too many callouts: 101 when displaying data on...
up vote
1
down vote
favorite
I'm making a webservice callout to an external webservice and displaying data on a Lightning component. Data is returned in JSON format in multiple pages. Each page has 50 records. In my apex controller class, I make multiple callouts in a for loop by specifying page number and populate the data into a list which is then displayed on the lightning page. Everything was working fine as long as the maximum nuber of pages was 100.
But in some cases, data returned from JSON has more than 100 pages. Then I get this
Error System.LimitException: Too many callouts: 101.
I saw solutions where using Batch class was suggested but in my case, I have to display all the data on a UI page. I'm not making any updates. It is just displayed on a UI page. I'm not sure how to use batch class to make more than 100 callouts and display that data on a UI page. Can someone please suggest a solution or point me in a direction on how to handle this situation.
apex lightning-components rest-api soql-limit-exception
add a comment |
up vote
1
down vote
favorite
I'm making a webservice callout to an external webservice and displaying data on a Lightning component. Data is returned in JSON format in multiple pages. Each page has 50 records. In my apex controller class, I make multiple callouts in a for loop by specifying page number and populate the data into a list which is then displayed on the lightning page. Everything was working fine as long as the maximum nuber of pages was 100.
But in some cases, data returned from JSON has more than 100 pages. Then I get this
Error System.LimitException: Too many callouts: 101.
I saw solutions where using Batch class was suggested but in my case, I have to display all the data on a UI page. I'm not making any updates. It is just displayed on a UI page. I'm not sure how to use batch class to make more than 100 callouts and display that data on a UI page. Can someone please suggest a solution or point me in a direction on how to handle this situation.
apex lightning-components rest-api soql-limit-exception
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm making a webservice callout to an external webservice and displaying data on a Lightning component. Data is returned in JSON format in multiple pages. Each page has 50 records. In my apex controller class, I make multiple callouts in a for loop by specifying page number and populate the data into a list which is then displayed on the lightning page. Everything was working fine as long as the maximum nuber of pages was 100.
But in some cases, data returned from JSON has more than 100 pages. Then I get this
Error System.LimitException: Too many callouts: 101.
I saw solutions where using Batch class was suggested but in my case, I have to display all the data on a UI page. I'm not making any updates. It is just displayed on a UI page. I'm not sure how to use batch class to make more than 100 callouts and display that data on a UI page. Can someone please suggest a solution or point me in a direction on how to handle this situation.
apex lightning-components rest-api soql-limit-exception
I'm making a webservice callout to an external webservice and displaying data on a Lightning component. Data is returned in JSON format in multiple pages. Each page has 50 records. In my apex controller class, I make multiple callouts in a for loop by specifying page number and populate the data into a list which is then displayed on the lightning page. Everything was working fine as long as the maximum nuber of pages was 100.
But in some cases, data returned from JSON has more than 100 pages. Then I get this
Error System.LimitException: Too many callouts: 101.
I saw solutions where using Batch class was suggested but in my case, I have to display all the data on a UI page. I'm not making any updates. It is just displayed on a UI page. I'm not sure how to use batch class to make more than 100 callouts and display that data on a UI page. Can someone please suggest a solution or point me in a direction on how to handle this situation.
apex lightning-components rest-api soql-limit-exception
apex lightning-components rest-api soql-limit-exception
edited Dec 5 at 17:11
codeyinthecloud
2,621321
2,621321
asked Dec 5 at 17:08
Saha
183
183
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
7
down vote
You need to move some or all of your pagination to the front end, rather than trying to load the entire data set in a single Apex transaction.
Your Lightning component might, for example, fire a server action to request a load of the first 10 pages' worth of data. Once the user consumes this data (whether that means scrolling through or paging in your UI, or whatever metaphor you are using), your component can then fire another server action to request the next 10 pages of data.
In this fashion, you avoid ever firing more than 10 (or whatever cutoff you choose) callouts in a single Apex transaction. Additionally, you will probably increase the responsiveness of your component substantially, because you're not trying to load more than 5,000 records in a single server-side operation via callouts.
While it's not impossible that a batch class could be a solution here in some form or another - you haven't given us a lot of information about your use case - I don't think it's likely to be the route you need to take.
add a comment |
up vote
2
down vote
You can also think of using Continuation call from Lightning Component through Visualforce (use ContinuationProxy component). Refer Invoking Apex Continuations from Lightning Components
This way, you can get a chunk of data from asynchronous webservice call and store them on UI layer in JSON format and use array.slice(start, end)
to display the data in a paginated way.
Just to note, the limit of response size from this each Continuation call is 1 MB.
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
You need to move some or all of your pagination to the front end, rather than trying to load the entire data set in a single Apex transaction.
Your Lightning component might, for example, fire a server action to request a load of the first 10 pages' worth of data. Once the user consumes this data (whether that means scrolling through or paging in your UI, or whatever metaphor you are using), your component can then fire another server action to request the next 10 pages of data.
In this fashion, you avoid ever firing more than 10 (or whatever cutoff you choose) callouts in a single Apex transaction. Additionally, you will probably increase the responsiveness of your component substantially, because you're not trying to load more than 5,000 records in a single server-side operation via callouts.
While it's not impossible that a batch class could be a solution here in some form or another - you haven't given us a lot of information about your use case - I don't think it's likely to be the route you need to take.
add a comment |
up vote
7
down vote
You need to move some or all of your pagination to the front end, rather than trying to load the entire data set in a single Apex transaction.
Your Lightning component might, for example, fire a server action to request a load of the first 10 pages' worth of data. Once the user consumes this data (whether that means scrolling through or paging in your UI, or whatever metaphor you are using), your component can then fire another server action to request the next 10 pages of data.
In this fashion, you avoid ever firing more than 10 (or whatever cutoff you choose) callouts in a single Apex transaction. Additionally, you will probably increase the responsiveness of your component substantially, because you're not trying to load more than 5,000 records in a single server-side operation via callouts.
While it's not impossible that a batch class could be a solution here in some form or another - you haven't given us a lot of information about your use case - I don't think it's likely to be the route you need to take.
add a comment |
up vote
7
down vote
up vote
7
down vote
You need to move some or all of your pagination to the front end, rather than trying to load the entire data set in a single Apex transaction.
Your Lightning component might, for example, fire a server action to request a load of the first 10 pages' worth of data. Once the user consumes this data (whether that means scrolling through or paging in your UI, or whatever metaphor you are using), your component can then fire another server action to request the next 10 pages of data.
In this fashion, you avoid ever firing more than 10 (or whatever cutoff you choose) callouts in a single Apex transaction. Additionally, you will probably increase the responsiveness of your component substantially, because you're not trying to load more than 5,000 records in a single server-side operation via callouts.
While it's not impossible that a batch class could be a solution here in some form or another - you haven't given us a lot of information about your use case - I don't think it's likely to be the route you need to take.
You need to move some or all of your pagination to the front end, rather than trying to load the entire data set in a single Apex transaction.
Your Lightning component might, for example, fire a server action to request a load of the first 10 pages' worth of data. Once the user consumes this data (whether that means scrolling through or paging in your UI, or whatever metaphor you are using), your component can then fire another server action to request the next 10 pages of data.
In this fashion, you avoid ever firing more than 10 (or whatever cutoff you choose) callouts in a single Apex transaction. Additionally, you will probably increase the responsiveness of your component substantially, because you're not trying to load more than 5,000 records in a single server-side operation via callouts.
While it's not impossible that a batch class could be a solution here in some form or another - you haven't given us a lot of information about your use case - I don't think it's likely to be the route you need to take.
answered Dec 5 at 17:12
David Reed
28k61746
28k61746
add a comment |
add a comment |
up vote
2
down vote
You can also think of using Continuation call from Lightning Component through Visualforce (use ContinuationProxy component). Refer Invoking Apex Continuations from Lightning Components
This way, you can get a chunk of data from asynchronous webservice call and store them on UI layer in JSON format and use array.slice(start, end)
to display the data in a paginated way.
Just to note, the limit of response size from this each Continuation call is 1 MB.
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
add a comment |
up vote
2
down vote
You can also think of using Continuation call from Lightning Component through Visualforce (use ContinuationProxy component). Refer Invoking Apex Continuations from Lightning Components
This way, you can get a chunk of data from asynchronous webservice call and store them on UI layer in JSON format and use array.slice(start, end)
to display the data in a paginated way.
Just to note, the limit of response size from this each Continuation call is 1 MB.
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
add a comment |
up vote
2
down vote
up vote
2
down vote
You can also think of using Continuation call from Lightning Component through Visualforce (use ContinuationProxy component). Refer Invoking Apex Continuations from Lightning Components
This way, you can get a chunk of data from asynchronous webservice call and store them on UI layer in JSON format and use array.slice(start, end)
to display the data in a paginated way.
Just to note, the limit of response size from this each Continuation call is 1 MB.
You can also think of using Continuation call from Lightning Component through Visualforce (use ContinuationProxy component). Refer Invoking Apex Continuations from Lightning Components
This way, you can get a chunk of data from asynchronous webservice call and store them on UI layer in JSON format and use array.slice(start, end)
to display the data in a paginated way.
Just to note, the limit of response size from this each Continuation call is 1 MB.
edited Dec 5 at 18:43
answered Dec 5 at 18:38
Santanu Boral
30.1k52152
30.1k52152
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
add a comment |
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Isn't each Continuation still limited to 3 sequential callouts, though? (I'm not very familiar with them, to be honest)
– David Reed
Dec 5 at 19:01
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
Correct you are, three asynchronous callouts in a single continuation
– Santanu Boral
Dec 5 at 19:08
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f241543%2fhow-to-resolve-webcallout-error-system-limitexception-too-many-callouts-101-wh%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown