A deeper look at the Release State Feature in SAP Datasphere

SAP recently released the new so-called Compatibility Contracts feature in SAP Datasphere. In this blog I will take you through this new feature and its possibilities.

Before the introduction of “Compatibility Contracts” it was hard to understand if a certain view that was used was still undergoing active changes or not. This sometimes resulted in a view being used in multiple layer models, while the foundation of that model was still being changed, leading to columns disappearing and data constantly changing. This all should no longer be the case with compatibility contracts.

In below diagram you can see the “natural flow” that an object normally would go through according to the SAP way of thinking. 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 it needs to at least 2 years after it was released).

 

Enough of the theory, let me show this new feature in a nice example.

Let us start with a newly created acquisition view, based on a table that we have in SAP Datasphere. After completing that view we can first deploy it and then change the Release State of that view under the Model Properties (when you click on the last node of a view or have no node selected).

By clicking on the window pane we can change the state of the view to Released by clicking on the Released button:

Now when we deploy the view, we get a new warning message, telling us that we are going to Release the view and we will not be able to revert this once it is deployed.

After clicking the “Deploy Anyway” button we get another information screen telling us what the released state means, and we need to confirm again that we really want to release a view.

A released view

The view now has a status “Released” and while having the view open, we get a yellow notification in the top of the screen telling us that we should not make any changes that will interrupt the consumption of the data of this view.

But what interrupting the consumption of data actually mean? Well to put it at its simplest you cannot remove any columns, remove input parameters or remove associations. You can however add columns, add input parameters with a default value (if there was already an input parameter available) and add additional associations. You can also add a filter node and deploy the view without any problems, which in my opinion could interrupt the consumption of data by dependent objects. I can imagine that at a later stage SAP will make it customizable for customers to add certain things that are not allowed on a Released view.

Deprecating a view

When you want to change a released view in such a way that the impact is bigger than what can be done in a released view than you must build a successor view and deprecate the earlier released view. Deprecating a view works in a similar way as releasing it, we just need to click on the Deprecated button:

Unfortunately, the window for the Release State disappears after the click, because we need to do one more thing: tell SAP Datasphere what the successor for our currently released view should be:

Only after filling in the successor are you able to deploy the view in a “Deprecated” state. Of course, we get a warning when trying to deploy, because of the nature of the Release State change:

We do not get an automatic overview of the views that are impacted by deprecation of the current view. Obviously we could get this ourselves by looking at the dependent objects in the View Properties, but still I think seeing what the impact is shows a better impact of the deprecation and gives an easy way to communicate this action with other developers.

Impact of deprecation

So, what is the impact of a deprecated view? It’s not as big as you might expect. In the top we do get a warning that we are viewing something that was deprecated:

If, however, we are trying to build a new view on top of a deprecated view, we can do so. We do not get a warning when dragging a deprecated view onto our canvas, nor do we get a warning when trying to deploy a view on top of a deprecated view. The only way we could identify if a view used is deprecated is by looking at the Release State of the source view. This is in my opinion a missed chance, because when working with multiple developers on the same datasphere tenant this is something that can easily be missed. Especially when the view built on top was already existing and just needs a few minor changes. 

Decommissioning a view

Due to the set-up of the deprecation I can not test the Decommissioning State of a view. As you can see in below screenshot I can only test the working of this state as of 12 September 2026.

Basically, what the decommission state does is, is releasing the view for deletion. When a view is still in deprecation state you cannot delete that view with normal privileges:

Changing a state by accident

Of course, it is possible that a certain state change happens even after you thoroughly checked your work. You clicked through the two warning messages and found out that that one column you added to your output should not have been there. Normally you could not go back from this, but users with sufficient privileges are able to change a state back to a previous state. They do however get a nice warning and need to confirm this action by typing in “CHANGE”.

I do think this a great addition to the process because I have seen situations at customers where things were accidentally deleted even though a lot of warnings were present before the deletion process started.

Conclusion

The new Compatibility Contracts feature is a great feature to have available in SAP Datasphere. In systems where multiple developers work at the same time this might be a real game-changer, especially when SAP brings the compatibility contracts even a step further with added warnings in views using deprecated views and the ability to customize and tweak certain conditions of a certain state.  If you have any questions, feel free to reach out here or via Linkedin!