Skip to Content

SAP S/4HANA 1709 Table Simplification & Compatibility with Native HANA

Sep 21, 2017 at 05:51 PM


avatar image

Hi All,

I had 2 questions regarding S/4HANA interaction with a native HANA.

1. Since the FI tables have been simplified, the original tables like BSEG have become views in S/4HANA. How does it impact scenarios where BSEG was being replicated via SLT to another native HANA system. How does the trigger based replication work on a case when BSEG is a view now.

2. S/4HANA 1709 is on HANA 2.0. What impact does this have on a target native HANA system? Should the target native HANA system also be on 2.0?

Thanks in advance.



10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Best Answer
Lars Breddemann
Sep 25, 2017 at 04:20 AM

ad 1) As SLT replication is based on data changes in tables, the new tables will have to be replicated with S/4 (quite obvious, don't you think?).

ad 2) I'm not aware of technical limitations that would stop a HANA 1 system from being a replication target for a HANA 2 source. However, when you're already using a HANA 2 instance you probably do not want to go "backwards" with using a HANA 1 target. Also, as always, check the specifics in the SLT documentation and SAP notes relevant to your release.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Thanks Lars.

About the SLT, yes it is quite obvious that the SLT shouldn't break. SAP surely won't create chaos on it's current implementations :).

I am a bit more intrigued to know how the trigger based replication works on these views now.

Maybe it is a silly question but wanted to understand how SLT on views is different from SLT on Tables (if at all they are different).

Thanks for your time again.


Shyam Uthaman


I see two options here:

1. HANA supports the INSTEAD OF trigger, but only on views. So if your application tries to insert into a view, you can write code to do something with that data instead. That would be one option to do it.

2. The changes made to data in compatibility-views effectively are changes in the new base table. A SLT trigger on that base table will catch all changes that came in via all compat-views. This could be the other option.

As I understand it, in S/4 both the compat-views and the base tables are used to capture data changes. So, in order to avoid "double counting" of changes that come in through compat-views, I assume that option 2 is the one that is actually used most of the time.

Alas, I don't have a S/4 system nor an SLT setup at hand to verify these thoughts.