Attribute View on tables of schema SYS

[danielschindler_com]

Hi everybody,

is it possible to create an attribute or analytical view on tables of the schema SYS?

If have created a new XS project and there I wanted to create an attribute view. I can add tables from this project to the view but no table from the SYS schema.

What can I do?

If I want to create a new view in the SYS schema, I only have the option to implement it with SQL...

I'm logged in with the user SYSTEM. Maybe it is an authorization problem?

Thanks for any help.

Best regards,

Daniel

[lbreddemann]

Hi Daniel,

"SYS" objects are not available to modelling and that's on purpose.

Would you mind to share what you like to model on top of the SYS views/tables?

- Lars

[danielschindler_com]

Thanks for your replies.

I want to build an application where users can see their roles, authorizations, etc.

The users should be able to request roles and via the front end somebody should be able to grant roles.

[danielschindler_com]

I forgot to mention that I do NOT want to create new objects within the SYS schema.

I want to create a complete new XS application with its own schema, etc. There I want to use the SYS tables for analytical views, etc.

[lbreddemann]

In that case, you don't need any of the modeled views.

You could just write SQL queries against the public dictionary views, like SAP HANA Reference: USERS or SAP HANA Reference: ROLES.

However, typically it's not the greatest idea to expose database level roles and privilege management. Instead the application should encapsulate its roles via its own API.

This could be as easy as a view that filters for the application relevant roles and SQLScript procedures to grant/revoke the roles.

- Lars

[former_member184768]

Hi Daniel,

I like the suggestion from Lars. Typically the the roles requested by end users are "Business Roles" which could result into one or more "Technical" roles implemented in HANA. Hence exposing the system roles directly may not be a good idea.

As Lars mentioned, encapsulating the roles with APIs and script based GRANT / REVOKE option should be a better way to implement the requirement.

Regards,

Ravi