How to Design Best Built Applications that integrate with SAP Business Suite on HANA?
In the ABAP for SAP HANA Community of SCN we can learn how to optimize our ABAP Applications for the HANA database. And we can learn how to create next generation applications that combine analytical and transactions features.
This is very useful – but software architects especially if they are working in huge custom or partner development projects need more information especially about architectural patterns that are successful in HANA development. Let me give an example: many transactional ABAP applications of SAP and partners use cluster tables to store their data because this approach is very flexible and generic. Unfortunately this not optimal in an HANA environment if since the compression of BLOBs tables is not that efficient compared to traditional database tables and the transformation of those data has to be done outside the database layer in the application server. So the question arises whether cluster tables or similar persistence model still make sense.
This is only one of the questions that arise if you design data models for ABAP applications or if you want to optimize existing ones. For SAP this is a chance because the HANA database as well as the SAP Business Suite can be developed so that both fit together perfectly. But what about custom or partner development? Will it benefit from or slow down optimizations of SAP NetWeaver and SAP Business Suite?
I think now it’s the time that SAP should start to share architecture guidelines for HANA-based and HANA-optimized applications and the SAP Guidelines for Best-Built Applications that Integrate with SAP Business Suite by Richard Probst should link to them.
I am well aware of the fact that those guidelines and best practices will grow and may change due to the fact of the evolution of HANA database and SAP Business Suite. Please let me give an example: generic persistence techniques have serious drawbacks since you can’t work with them properly with SAP standard tools like SE16 and that’s why a consider them as dangerous since years, as you can read in my blog. They provide elegant solutions but shift the complexity to other areas like maintenance, other processes like development of BW extractors and so on. But should we redesign our data model? From discussions I learned that this is only necessary if you want to do operational reporting on those data, otherwise try out features that HANA offers like hybrid LOBs as part HANA SPS6 and this is exactly what I’m planning to do.
But this is just one of the questions software architects have to answer. The more general question is how to participate at the evolution of SAP Business Suite. What are your Best Practices? What questions should SAP answer – what topics should be covered? Let’s start the discussion!
Hi Tobias!
Thanks for the good blog.
I agree with you on the need for common accessible design patterns for systems build on SAP HANA.
But just as with many other areas where creativity and knowledge typically translate into money and/or career opportunities the incentive to share solutions that have been found/created are rather small.
What would be your approach on this?
Just demanding from SAP to publish their best practices would of course be one way here - although I reckon this would leave out many high quality contributions.
Something different: how do you see that hybrid LOBs would change your design decision for the data design?
In how far does it make a difference for your data design whether the LOB data is permanently kept in memory or not?
- Lars
Hi Lars,
thank you for your feedback!
> What would be your approach on this?
SAP already started to provide such guidelines for “Best Built Apps”. I think SAP could do the same: ask development architects at SAP to publish some relevant parts of the SAP internal guidelines. This is necessary especially if our solutions use SAP’s brand.
Branding partners as well big custom development needs the following:
> In how far does it make a difference for your data design whether the LOB data is permanently kept in memory or not?
Many cluster tables contain generic information that are seldom used in some dialog processes and are kept within the SAP system only for auditing reasons. In this case there is no need to keep it in the memory and we don’t need to waste the memory space. Moreover declustering doesn’t make sense – you don’t have to touch existing data models and your application architecture.
I hope I could clarify some points. The ABAP for HANA Community teaches us how to optimize and to create applications that benefit from HANA. Let me give some examples: we should use Open SQL first, and then use try to use more features of Open SQL (think of Joins) like ABAP developers usually do. These kind of information are tremendously important. The next step would be to provide architectural guidelines.
Best Regards,
Tobias
Hi,
concerning the use of Open SQL: one of the benefits from using HANA is to move the business logic down into the DB itself - making the transition from OpenSQL to SQLscript and/or views. In an ideal world, an ABAP program running on HANA would not contain a single SQL statement, instead you would use ABAP for facilitation and presentation purposes only. This is in my opinion the strongest point about HANA, even overshadowing the somewhat hyped-up http and XSJS etc. capabilities.
I would love for SAP to provide a set of best practices for procedure/view creation, especially with relation to how SAP themselves replace existing SQL-heavy standard ABAP functionality with HANA procedures and views. In particular focus on how to maximize the use of the CE functions (also since there seem to be a few inconsistencies between what is documented from SAP and how these work in real life implementations).
Regards,
Trond