Let's explore the approach in naming convention of objects, how you can work with different versions of objects, the release state of objects and the sharing of objects across spaces.
Naming Objects
A naming convention can help to identify and separate the objects in SAP Datasphere or describe their purpose. The technical names are technically unique per space. In case it is required to have a harmonized naming across spaces, this will require some governance next to the system capabilities.
Another main aspect of naming conventions is an evolution of the model over time. People and responsibilities may change over time. Having a naming convention and adhering to that convention helps developers and users in the system, through having a purpose, an area, an origin or even the priority of a model as part of a naming convention. Anyone would as such be able to quickly understand an object and its purpose, if it can be reused or if it is allowed to be altered.
Note
Avoid the Prefix "SAP" for any object, as SAP delivered business content is using this prefix. SAP Datasphere does not provide the functionality to define name spaces.
General recommendations for naming rules in an organization:
- Unambiguous: Use clear, well defined descriptions, if in doubt, talk to your project’s information developer and check SAP terminology. The goal is that users understand immediately what the entity is used for.
- For descriptions and business names use blanks. Do not use underscores or camel case words.
- Avoid abbreviations as much as possible.
Note
First Guidance Document: Development Guidelines and Naming Conventions
Versioning
Each time you deploy your object, a new version is created in the repository. You can review previous versions of an object at any time and choose to restore a previous version.
Object versioning allows you to review the history of changes to your objects and, for certain types of objects, to restore a previous version.
Note
No validation rules are applied and certain features, such as impact and lineage analysis and data preview are not supported.
Release State
To encourage confidence in the stability of your views and to guarantee backward compatibility when they are updated, you can set their Release State to Released. Once a view is released, it must continue to provide the same output columns until it is replaced by a successor, at which point it can be deprecated and, eventually, decommissioned.
There are currently 4 states that an object in SAP Datasphere can be in:
Not released: The default state that a view is in. You can edit the object freely and consumers can you use the object without any guarantee of the object changing in the future.
Released: When a view is in the status "Released" it can only be edited in such a way that it will not break backwards compatibility. In practice, this means that the column output of a view is static, and only columns can be added, not removed.
Deprecated: A view can be set in the state "Deprecated" once a successor of that view is available in SAP Datasphere. While setting this state, the view asks for its successor view, which should be in a released state as well (otherwise you cannot select it).
Decommissioned: A view that is set to the state "Decommissioned" can be deleted from the system. Before you can set the state "Decommissioned", a view needs to be in the deprecated state for at least 1 year (and at least 2 years after it was released).
Note
Release states are an optional feature. By default, all views are set to "Not Released" and there is no obligation to release any view. Test thoughtfully if the entity is in its final state before releasing it.
You can only switch from "Released" to "Deprecated" and then to "Decommissioned". Only an administrator can reset an entity to "Not Released".
Sharing Objects Across Spaces
To see models or data, users must be assigned to a space that contains these models. Therefore a suitable role must exist. By default, all business users, which are assigned to a given space, are able to consume all of its data. Your space is a secure area and its entities and other objects cannot be seen in other spaces unless you choose to share them. When you share an entity to another space, users in that space can use it as a source for their views and other objects.
Suppose you have created a connection to a source system. Then business users of the sales department should have access to such data. Then, the IT should generate a model and share it with the sales space. Sales modelers can create another model in the sales space on top of the shared object that contains sales costs, for example, then share it with the finance space.
You only need access to the source space in order to start sharing. Sharing is a one-way reference. You cannot change the shared object from the target space, but you can create a view on top of it and remove, rename, or join fields in the view.
Shared objects cannot be edited in the target space, but you can include them in another view. As a tricky alternative, you can export an object as a CSN (this is based on JSON) file and import it in another space, but then you must export and import all required objects with the same name.
When access to the model or data should no longer be available, you can unshare the object from selected target spaces. To share or unshare, you must work in the data builder in the source space. If you try to unshare an object that is used in the target space, you will get an error message with a list of objects that use it directly. For a full overview of dependencies, check the lineage and impact analysis. Only after a manual re-design of the upper-level objects, you then can unshare.