Performance improvements in Nakisa 3.0 SP3
In Visualization Solutions by Nakisa (VSN) 3.0 SP3 Nakisa introduced a new configuration build (SAP_Live_RFC) and ABAP Add-on that uses SAP function modules to retrieve data from SAP. This was done in order to improve performance in data retrieval by enhancing processing times and reducing calls to the backend.
Previously VSN solutions used a mix of function modules that were called via application classes and NakisaRFC. NakisaRFC uses an application class and SAP function module to return data as configured in NakisaRFC functions. It extracts up to 32 tables and joins them together to create one or more output tables, which can also have data processing performed.
In order to move this processing into a more flexible and efficient environment Nakisa introduced SAP function module integration in VSN 3.0 SP2. Now in SP3 they have leveraged this to provide a set of function modules to return data back from SAP quickly and efficiently.
Now, what prompted this blog was what I saw today on a 3.0 SP3 delta-training presentation from Nakisa. I was pleasantly surprised at the performance increases this new configuration build were providing.
| Task Performed | SP2 | SP3 | Difference |
|---|---|---|---|
| Initial Load |
4.3 |
1.3 |
70% |
|
Changing view to OrgUnit Manager |
10.3 |
1.5 | 85% |
|
Expand an OrgUnit (33 nodes) |
27 |
1.7 | 93% |
|
Collapse an OrgUnit (33 nodes) |
2.4 |
0.8 | 66% |
|
Open OrgUnit details panel |
7 |
1.2 | 83% |
|
Perform a search (3655 records) |
9.4 |
0.7 |
93% |
Note: all times are in seconds
You don’t have to be Einstein to realize that the difference in performance is exceptional. It is worth noting that even in the Staged and standard Live build the performance is also quicker.
Summary
SAP and Nakisa both recommend using the Live approach and Nakisa recommends that all new implementations of 3.0 SP3 should use the new SAP_Live_RFC configuration build. I definitely agree and I look forward to seeing the results of some 3.0 SP3 implementations that not only use this configuration build but also prove that that performance enhancements are retained once the function modules are extended to add additional fields.
It was great to see these stats today in the webinar and having used SP3 briefly, the improvements are obvious.
Worth noting that the Live RFC default setup is hybrid in OrgChart; live chart, details and searching with analytics provided via the staged approach (DB).
Also that the new Add On is backwards compatible but only required if Live RFC is being used.
Shame for customers that there is not an automated upgrade path for existing pre SP3 installations.
Stephen
Hi Stephen,
Thanks for the comments. I was positively surprised - and excited - when I saw the stats. Previously I had used SP3 and, like you, I had clearly noticed the difference.
I think you must "not" from your last sentence! 🙂
Best regards,
Luke
I've corrected my missing "not" ... changes the meaning of my whole point by missing it out!!
Small point ... didn't the new function module integration come in SP1?
(your sentence "Nakisa introduced SAP function module integration in VSN 3.0 SP2")
Stephen
It certainly does! 🙂
re: function module integration, I was under the same impression but when I checked my blogs it was listed in the SP2 blog. I know it was withdrawn from release in some releases because it wasn't stable. I don't have an SP1 build to hand, so I can't confirm - but usually my blogs are fairly accurate 😉
Best regards,
Luke
Hi Luke
I am still unclear on a couple of things..
1.) When would you choose a Staged OrgChart build?
i.e.
Position Org Data >10k, >50k, >100k,
with lots of field customisations
backend security not using struc auths
Bearing in mind that storing preferences globally or using analytics requires a database in any case?
2.) There appears to be no new live_RFC option in OrgModeler in SP3 so is the OrgChart here going to be slower?
3.) If using Staged OrgChart why is there no option to use a Staged OrgModeler, if the decision has been made to use Staged surely the same reasons apply to OrgModeler?
4.) What are the real Performance bottlenecks, i.e.
Data retrieval in a large dataset
Rendering customisations
Hope you can clarify this for me.
Regards
Stuart
Hi Stuart,
1. I would always go with the Live version unless the client has a specific reason to stage their data (SAP authorizations are complex and slow, data is often updated during the day or the SAP server of a global company might be unavailable, for example).
2. Yes, the OrgChart module in OrgModeler will be slower than OrgChart. However, this is only used for reference and shouldn't be a big problem.
3. Nakisa did specify a reason for this and it escapes me. I'm pretty sure it was because of authorizations.
4. The biggest performance bottlenecks will be data processing and manipulation in SAP. Incorrect hardware infrastructure and network bandwidth are also issues. The larger the dataset the slower the response time, but with function modules the speed should always be fairly quick. Having multiple calls to the backend and very complex authorizations are also potential issues.
Best regards,
Luke
Hi Luke
Thanks for the update, very useful..it was just that with Staged still being available as an option I thought there must be a point where the SAP\Nakisa recommendation then must switch from Live to Staged. I guess this is rarely and must be considered carefully against individual client needs.
Thanks
Stuart
Laurent,
Certainly (as this blog explains), there is a big improvement in using the Live_RFC build in SP3 but the big problem is that you are both upgrading and changing build.
You might find my blog series on upgrading VSN useful.
In the Live_RFC build, the speed improvements are made by utilising one (new) RFC call to SAP which gets all the data needed for that action (i.e. one function module to get all data for the position details panel, one for search, etc). Nakisa did not promise or communicate any significant performance improvements in Live_2 or Staged builds in SP3.
One option might be to move to SP3 Live_2 build and then also evaluate configuring Live_RFC build alongside. But even then (as a warning I will discuss in my blog!), be aware that between a recent SP2 Live_2 build and a recent SP3 Live_2 build there are over 220 files with differences in them. So blindly importing your SP2 build into SP3 is not necessarily safe or advisable. Of course your .delta will only contain a subset of files from the whole build and only some will conflict with the 220 files that differ ... it is these that you need to "manage".
You might be better to re-apply your requirements into SP3 Live_RFC build - certainly there will be some similarities but they are certainly not identical.
e.g. files in AppResources\dataelementconfiguration are very similar but files in AppResources\detailconfiguration are very different.
Regards,
Stephen
Hi Laurent,
It is possible to upgrade SAP_Live_2 to SAP_Live_RFC in SP3 without redoing the customization, but you are looking at some effort for the data source. It's simply not possible to just have a method to convert your NakisaRFC functions to an SAP function module. With exception of the data source, the rest of the configuration will work the same in both SP2 and SP3. The only other changes will be the data elements and field names, but if you created function modules using the field same field names. Of course, if you wnated to continue to use your Live configuration in SP3 then this will work. In most cases you can simply import your SP2 configuration into SP3, but the likelihood is that you need to delta-merge your PresentationResources.xml file because this has some important tempalte in SP3, plus some other files depending on the extent of your customizing. But generally it will work in the 6 or 7 upgrades that I've performed.
There are definite performance improvement in SP3 for Staged and Live. Stephen is correct that only the SAP_Live_RFC performance improvements have been communicated, but if you use the Staged version you will notice a vast difference in processing time compared to SP2. Live is noticeable, but not so noticeable compared to Staged or SAP_Live_RFC.
Best regards,
Luke
Laurent.
It can be difficult to explain to customers as I think SAP as a general rule have an exceptional architecture for abstracting to allow more hands off upgrades. However I think Nakisa probably stacks up fairly well against other systems outside of SAP in that they actually have the .delta structure in place to help provide some level of separation from the 'core' code and configuration. Perhaps framing it against other systems that integrate with SAP might help the case for upgrading?
If you don't have much customisation, then the option to just import a build without issue is probably significantly higher. However the more customisation, the greater the chance you'll run across something that's been improved or fixed in the interim. Remember service packs are fairly significant incremental updates in terms of VSN.
Saying that, armed with a good file & directory comparison tool it is certainly not an insurmountable task to convert an existing build; but if you discover lots of files with large volumes of changes you can balance the effort against what it would take to apply the customisations and configuration to a "clean" build.
Stephen.
Hi Stephen,
It's worth noting that most fixes in SP3 were code-changes and not XML changes. There were a few XML changes made in SP2, so it really depends on the version that is being upgraded to. If only someone had written a series of blogs on this recently... 😉
I began working on an upgrade tool with Nakisa last year for release in 4.0 which we hope will help accelerate upgrades by helping to identify changed files etc, based on the source and target version, etc.
Best regards,
Luke