Which approach should be used (XSC vs XSA) when using HANA Native and BW4HANA on the same instance?

[KonradZaleski]

I know that there are bunch of question regarding XSC and XSA, but for me it is still quite confusing when to migrate to XSA.

As per SAP statement: SAP HANA Extended Application Services classic model (XS classic) and SAP HANA Repository are deprecated as of SAP HANA 2.0 SPS 02.

In our scenario in the same instance we have HANA views which are consumed directly by users (as native views or exposed to BW through Composite Providers) and reporting on BW4HANA objects. We can easily combine Native HANA Views with BW4 objects and take benefits from mixed scenario.

In such a setup should we migrate HANA views to XSA? I know that now it's possible to consume XSA views by BW objects (Composite providers, Open ODs etc.) but it's not possible to generate XSA views from BW objects.

Now I have some concerns for following scenarios:

• consuming XSC views (generated from BW objects) by XSA views
• mapping input parameters from XSA views to BW Composite providers
• using XSA views as data sources in Transformations

We are using HANA Views both for reporting and as data sources for BW transformations. Views generated from BW objects are used for mixed scenarios.

Could you please advise in which case migration to XSA is reasonable?

[lbreddemann · Accepted solution]

Ok, as a disclaimer: I don't work for SAP and I am not a fan of XSA as a development environment for what most SAP customers do (trying to maximize the use they get out of their HANA systems).

So, you have a BW4HANA (or a BW/HANA, whatever) and that can create views (XSc) to allow accessing the data in the BW schema.

It also allows using code, views, and data in other schemas (such as _SYS_BIC) by mere granting of access privileges.

This works well for you, I assume, as you've built solutions with this setup already.

Now, XSA is there and SAP decided to deprecate XSc, because they see XSA as the better approach to develop cloud-ready applications (using the 12-factor application model, cloud foundry concepts, an API approach to all operating activities etc.).
This also includes the handling of database objects and access to those objects as those need to be isolated from the rest of the DB in XSA. Shared access to any object is only possible by explicitly declaring and allowing such access; which reduces accidental dependencies between different applications but increases the development effort when shared access is the main point of whatever you develop.

The thing here is: both XSc and XSA are development environments for application development. The management of database objects is a side-concern for these environments and for your use case - sharing data, code, and views - XSc comes with the lower hurdles to achieve this goal.

At this point, you would argue, that there's no point in using XSA for what you want to do.

Now, unfortunately, SAP conflated several aspects together and decided not only to stop further development of XSc, but also to stop the development of the development tools that use the XSc database object management, namely HANA Studio and the Web-based IDE.
As a consequence of this, these tools now don't support all the database features that HANA 2 provides. For nearly all the more recent features (e.g. hierarchy nodes, table functions w/ tables as input parameters, data masking, etc.) the use of the XSA development environment is mandatory.

In short: if you want to use the newer HANA features in graphical modelling, there is no way to go around XSA - just because SAP decided to not make those features available in the tools for XSc. Note that the features themselves don't rely on XSA at all - once deployed, a data masking view works fine without any XSA or XSC application running.
What you can do, in many cases, is to wrap the SQL equivalents for the newer modelling features in table functions (e.g. hierachy functions) and expose those in graphical models.

Concerning the deprecation: the recent post https://blogs.sap.com/2020/02/21/planned-release-of-sap-hana-2.0-sps05-and-impact-on-maintenance-for... on the maintenance schedule for SAP HANA 2 makes it clear, that SP 5 - which includes XSC - will be maintained until at least 2025. The deprecation means that only the next major version of HANA (HANA 3?) won't include XSC anymore.

That means, that for at least five more years, you can build and use XSc and the way it handles database objects without any limitation.
Given that XSA as an application development model does not seem utterly successful (there are even third-party development environments now - see wdaehn's posts https://blogs.sap.com/2019/12/25/hana-development-where-are-you-going/ and https://blogs.sap.com/2020/03/02/hanaappcontainer-play-time/) it seems possible that SAP untangles the application development from the data/view modelling aspect again (a similar situation like your is present for folks that want to do mixed-scenario reporting off their HANA instance in SAC or other reporting tools).
As a customer, that would be my request to SAP, because for such scenarios that are about data/view modelling and not application development, XSA requires far too much jumping-through-hoops.

By now it should be clear, what my thinking here is:

I'd stick to XSc as long as possible and try to avoid investing into XSA, if there is no application being developed that benefits from XSA.

With all it's limitations and issues, the view modelling in XSc does have one thing going for it: it is a really effective way to work in classic SAP (central-shared-DB) scenarios and it ties in well with the ABAP side of these developments.
Put another way, it gives you "much bang for your buck".

I hope this gives you a way to think about this and I'd be interested in your's and other folks' opinion an the matter. I already tagged wdaehn - I'm sure he has something to add to this.

Cheers,

Lars

[werner_daehn · Accepted solution]

perfect summary, I subscribe to the statements 100% and have nothing to add.

[michael_eaton3 · Accepted solution]

Great summary.

I was planning to be in Walldorf today at the HANA Summit, and my main feedback was to be the un-deprecation of XS Classic, or introduction of a simpler model than XSA.

[KonradZaleski · Accepted solution]

Thank you lbreddemann for such an effort with detailed explanation. Now it makes much more sense.

Talking to my friends, there are many implementations where companies are using HANA only for reporting purposes, hence for me this whole XSA setup is not very useful from that stand point (usage of local schemas, branches etc. may be useful for programming but for graphical modeling I don't see benefit out of it apart from some new functionalities).For us XSA has a lot of drawbacks comparing to XSC (need of synonyms, difficulties with debugging when project deployment fails, response time, working with git and much more). For me effort with migration to XSA is not comparable to the benefits which it gives (including all the drawbacks which I mentioned).

We would follow same approach as you mentioned to stick with XSC as long as it's possible.

[lbreddemann]

michael.eaton3 if you are interested in a simpler way to build apps on top of HANA then make sure to have a look at Werner’s blog posts that I referenced in my answer.

Werner has released a whole new app container, that allows to build data driven apps with minimal code and even less boilerplate rain-dance around it.