The vision of Hana SDI was to designu00a0 transformations once and let the user decide the qualities at activation time. He could choose:
- Federation: Data is current as the source system gets queried directly but the users stress the source system with their queries unintentionally. The queries return with source-system speed, if that.
- Batch ETL: Move the data at the highest possible speed into the Hana instance, hence queries will run at Hana speed. But data might is not current and not transactional consistent at any time.
- Realtime Push: The source system is asked to push changes to Hana and these changes are incorporated into the Hana target tables. Hence all queries will run at Hana speed and will return current data. Depending on the transformation, this can be a lot of work to accomplish.
By using Hana Smart Data Access as the foundation and extending it, within a year (Nov 2014 with Hana 1.0 SPS9) the first version of Hana SDI was released. It allowed to add own Adapters and to use realtime push with various sources.
The other concepts of transitioning between the three integration styles was started but never completed. Only now this concept starts to get traction again by other Hana teams.
So if there are any questions in regards to Hana SDI, your chance to talk to the very creator of this product. I’m who you want to consult for this.