In fact this is the larger and hence more important market! But to get data into Hana and to use the Hana options, that is when it becomes hard to argue why multiple external tools should be used, each with its own connectivity and capability. All of these tools will continue to be enhanced as standalone products. Customers requiring to merge two SAP ERP company codes will use SLT for that, it is built for this use case. For example a customer not running Hana or where Hana is just yet another database, such a user will prefer a best of breed standalone product like Data Services always. The individual tools like Data Services do make sense still for all those cases the requirement matches the tool’s sweet spot. Provide one connectivity that supports all.There should be no difference between loading local on-premise data and loading over the Internet into a cloud target other than the protocol being used.
Allow transformations on batch and realtime data.Support batch and realtime for all sources.The user however has very simple requirements when it comes to data movement these days:
With the Hana Smart Data Integration feature you get all in one package plus any combination, when it comes to loading a single Hana instance. You used Data Services for batch transformations of virtually any sources, SLT for realtime replication of a few supported databases with little to no transformations, HCI-DS when it comes to copying database tables into the cloud etc. Prior to Hana SP9 SAP suggested to use different tools to get data into Hana: Data Services (DS), System Landscape Transformation (SLT), Smart Data Access (SDA), Sybase Replication Server (SRS), Hana Cloud Integration – DS (HCI-DS),… to name the most important ones. Hana Smart Data Integration – Fun with Transformation Services.Hana Smart Data Integration – Architecture.Hana Smart Data Integration – Realtime Sources with History Preserving.Hana Smart Data Integration – Realtime Sources with Transformations.
0 kommentar(er)
