Hi,
I am working on a large S/4HANA 1610 implementation project. As a part of this project we are also implementing an EDW based on BW/4HANA product.
EDW will source data from S4/HANA and 100+ other source systems.
We plan to use SAP HANA Smart Data Integration (SDI) to replicate / move data into EDW.
I am looking for a HANA document or knowledge base that describes best practices around schema organizations, users, package organization and security between all this.
For eg. We are planning to have 2 schemas for each source system e.g. S4 and S4_REPL. S4 will hold data tables relicated in realtime from S/4HANA and S4_REPL will hold virtual tables, procedures etc that are generated by SDI replication task. All developers will have select right access to these data schemas. As for packages, we are separating SDI packages from HANA content packages. SDI packages will be organized by source system. Each source system will have one or more packages. Each package will have one or more replication tasks. Content packages are more organized by Departments and then within departments packages there will be sub-packages by functional areas.
Considering this scenarios, I need guidance on security setup and content migration between different environments. If we use lifecycle manager, what special tasks we need to do as developers to make use of LCM to move objects between environments. Also we plan to create a HANA developer role. Any guidance on what privileges / rights this role should have ?
Thanks
-Vijay.
1 Answer
-
Dec 08, 2016 at 01:14 PM
This sounds like an interesting project! :)
I'm not aware of a general document or guideline covering this, but happy to share a few thoughts.
About schema and security design on a HANA technical level please check the recent blog post https://blogs.sap.com/2016/03/29/hana-schema-user-and-role-security/ which I think provides a good overview.
The idea to provide each source system its own schema surely makes it easy to deal with the potentially overlapping namespaces but adds quite a bit of administrative burden to it. Which user is going to own these schemas? Ideally. this should be a single administrative account.
On the package organisation around the departments... I would strongly suggest reconsidering this. Solutions easily can stretch cross department borders and the responsible departments for any given function might/will change. My gut feel here is that it would likely be better to organise the packages around specific solutions and rather set up the necessary roles for privilege management.
Given the large number of source systems I also suggest to build the tooling for the management of the schemas and the roles/role assignments up front.
That's my 2cts on this.
Add comment
Add comment