<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_Optimizing_Performance_in_SAP_Analytics_Cl_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2025-03-06T14:23:04.000Z

Deciding When to Use the getResultSet API Instead of getMembers API

<div id="content"><div class="parentsection"><div class="section"><p tabindex="0">In this lesson, we will explore reading dimension members and explain why it’s best practice to use the <code>getResultSet</code> API instead of the <code>getMembers</code> API. However, we will also look at a scenario when it might be better to use the <code>getMembers</code> API for better script performance.</p><div class="kalturaVideoLessonWrapper"><div aria-label="" class="kalturaVideoLessonContainer" data-testid="video" id="1_shtnt6jc"></div></div></div></div><div class="parentsection"><div class="section"><div tabindex="0"><h3>Summary</h3></div><p tabindex="0">With any story, performance can vary depending on how the story is set up, how the scripts are written, and the data connections that are used. Performance depends on not only the scenario but also how the script is built. Script processing is related to frontend time, so it may be slower, or even faster, depending on the user’s machine.</p><p tabindex="0">It’s generally true that the <code>getResultSet</code> API in a script is faster than the <code>getMembers</code> API as it does not require an extra round trip to the backend server. However, depending on the size of the results, it can take longer to loop over it and find the values you need instead of using a separate backend request that directly delivers the data you require.</p></div></div></div>

getResultSet API and getMembers API

Managing Performance in SAP Analytics Cloud

<div><div><div><div><div><div><div><div><div><div><div><div><div>Explore the best practices for reading dimension members using the getResultSet API versus the getMembers API in SAP Analytics Cloud. Understand performance differences and scenarios for optimal script usage.<br><br># This description was auto-generated #</div></div></div></div></div></div></div></div></div></div></div></div></div>

Understanding When to Choose the getResultset API Over the getMembers API

In this video, we will explore reading dimension members and explain why it's best practice to use the getResultset API instead of the getMembers API. But we will also look at cases when it might be better to use the getMembers API instead. Let's take a closer look. You can see that we have created a very simple story with a table that shows countries and five measures. In this scenario, you want to create a script that reads the members of the country and populates the dropdown boxes. Let's start by looking at the getMembers API. Let's run the script containing the getMembers API in the story. The 16 countries are in the dropdown, as you can see in the story and in the developer tools. When you run the script that contains the getResultset API, you can see in the developer tools that the dropdown is populated with the same 16 countries. In our scenario, in order to compare performance, we have the same amount of data, and we are targeting the same level of information, so it's possible to use either API. Let's take a look at the getMembers API and how it is used in the story script. We use the getMembers API to read all countries with booked values from the data source. We then loop over that list and add this to the dropdown box and pass it to the console. Now, let's take a look at the script that uses the getResultset API. The getResultset API uses the result set that already exists in the table, using the data that we already have. These lines of code generate the list of countries. The code that we see here is made in a more generic way, so that it also works if your drill down status is more complex. In this story, we only use country and the measures in it, but we do not have other dimensions such as regions or calendar years. So, the script that we use here in the getResultset API is a little bit more complex than what we need for our scenario, but we want to show you a script that reflects the more complex use case that would be typical in an SAP Analytics Cloud story. We read the results set that we have in the table and loop over that. Within the loop to make sure that we only get the countries once and collect them in an array. When we have the list of countries, we simply write it to the dropdown box and put it to the console. Now, let's compare the performance using the two APIs in a story. When we open Performance Insights, we see that the script getMembers took approximately 1100 milliseconds to run. The getResultset script took 73 milliseconds. In this specific situation, the getResultset script performed 10 times better than the getMembers script. Of course, the times can vary depending on how the story's set up, the scripts, and the data connections. It's generally true that the getResultset API in a script is faster than the getMembers API, and it's for this reason, using the getResultset API to read dimension members is recommended for better performance. There are however a few scenarios where you may choose to use the getMembers API instead. Let's take a look at one of these scenarios. In this story, the table has four dimensions, not just the countries but also the calendar year, product rating, and product ID. The results set itself is much bigger, so now looping over the results set would take much longer. We use in general the same looping mechanism that we used in the other story, but you see here, the results set has no limiting selections. Depending on the position of the desired dimension in the table, you might need to adjust the code, for example to ensure proper sorting of the dimension members. But let's take a look at the performance in this story with a larger results set than in the first story used in this video. Let's turn on performance optimization and run the two scripts. When we open the performance insights, we see that the getMembers script was processed in about 1.8 seconds and the getResultset in 1.9. When you compare it to the earlier story, you can see that in this specific case it's slower to use the getResultset API in the scenario of a large result set. What we have to keep in mind is that performance depends not only on the scenario but also how the script is built. The first danger is you can do something really wrong in the code, for example not restricting your result set using the selections parameter. As this is now pure script processing with some loops in it, you are much more dependent on the power of the machine. Script processing is related to frontend time, so it may be slower or even faster, depending on the user's machine. This means that it's a little bit more unpredictable how long it will take, and users will have different performance experiences when interacting with the story. The getMembers script is an easier and cleaner script. It's much easier to come up with the right script, as there isn't much that you need to include. There is less of a danger of making a mistake in the script and you are not that reliant on the performance of the user's machine. In conclusion, we saw that if we already have the results set in a chart or in a table where we need the values of a dimension from, then it is typical faster to go over the getResultset API than going over the getMembers API. It's important to think about the different scenarios and plan which scenario will suit your data and requirements.