Recognizing that not every company uses the RSA Archer native reporting engine for all of their reporting needs, I'm excited to share with you some exciting updates made to the Content API as of RSA Archer Platform 6.7, generally available October 29, 2019. For those of you who may not be aware, the Content API facilitates integrations with many of the top BI Tools in the market today, but we've heard your feedback that the performance is not on par with your expectations. To address those concerns, we've made three key changes to the behind-the-scenes operation of the Content API, all aimed directly at performance improvement.
The first change we made, was to revisit the code base of the Content API holistically, looking for opportunities to redesign or refactor the way in which the Content API does what it does. The bright minds of RSA Archer Engineering were able to identify a number of areas of opportunity, and as a result of their efforts to streamline the code behind the API, the Content API is now running ~20% faster in our lab environments.
In-memory caching was the second change made to the Content API. As a part of the redesign analysis, it was observed that the Content API was spending a non-negligible amount of time retrieving the same relatively static values from the database hundreds or thousands of times. To address this, in-memory caching is now used to store those infrequently changing values such as the names, IDs, and aliases of Groups, Users, Applications, Fields, Values List Values, and more.
By default, the cache is set to expire stored values every 20 minutes. Depending on the volatility of your data, you may need to adjust this value up or down for optimal performance, and can do so by editing the <appSettings> section of the web.config file on the instance's web servers. Tuning this parameter to meet your environment's specific needs will further improve the performance of the Content API. Keep in mind, that if set too high, the Content API could return a stale value from the cache for something that was recently renamed. In this case, bouncing IIS or waiting for the timeout to expire will grab the new values and put them in the cache.
Finally, we added support within the Content API for the OData filtering parameter "$top". This parameter allows you to specify the maximum number of records the Content API will return in a single call. Previously, this value was hard set by the system to always be 1,000 records. With RSA Archer 6.7, the "$top" parameter now defaults to 1,000 if not specified in the URL, and by default accepts any value between 1 and 10,000 inclusive. Should your web server hardware be robust enough to handle serving up more than 10,000 records in a single call, you can raise this maximum limit again in the web.config files.
In our lab testing, by returning more records in a single call we were able to reduce the overall time to extract all records from an application. This is due in large part because each API call carries with it some overhead in building up and tearing down the various code pieces involved with a full request and response API call. By eliminating the repeated overhead that is the same for every API call, the results come back faster.
This blog is the first of many you will see in the coming weeks as we highlight and demo all of the amazing things contained within RSA Archer Platform 6.7. Please make sure to follow the RSA Archer Blog and Free Friday Tech Huddle (FFTH) pages to get all of the latest updates and attend live demos of RSA Archer 6.7! We kick off the FFTH series THIS FRIDAY, with the RSA Archer Platform 6.7 Overview. You won't want to miss it!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.