Lifecycle Management in SAC - Transporting : Single-Tenant Landscape
1 General
SAP Analytics Cloud is a powerful frontend and offers multiple options to share stories with consumers.
When consumption is growing it is also very important that new developments are deployed smoothly for end users. Especially in a landscape with one tenant, acting as development system, quality system and productive system this could be a challenge.
The following paper takes a deeper look into changing an already existing published story where the story was developed in a Single-tenant environment.
2 Changing a published Story
Stories and their URLs are often shared and changing the StoryIds could lead to some trouble.
In this part the focus is on how story development can be done within a single tenant scenario without having the need to send out new URLs to the users or share with the users again and again. The aim is to keep Story-Ids of stories stable and be able to develop/change and run a productive story at the same time.
While it seems rather simple, it is important in handling lifecycle-management.
2.1 Create a new Version
For the purpose of this demo, a story has been created and is shared with multiple users.
Original Story ID
https://<tenant>/sap/fpa/ui/app.html#;view_id=story;storyId=748CE70D4ED1CDE664A1B64E384E9E9E
The Original Story has the following simple layout with 3 pages, some widgets and filters
In order to keep development versions from the productive story, without disturbing current usage for the users, a development folder is created and not shared with the public. There all versions of a story can be stored for back-up or archive reasons as well as development of changes.
A copy of the original story is saved as V1.1 within this folder so a version of the original story is saved (for security reasons as well as possibly later usage if the deployed changes have to be taken back).
Another copy of the original version to a new version V1.2 where changes are done, was created.
This new story has a new unique story ID as seen in the next screenshot as has any other version which is saved within this folder.
https://<tenant>/sap/fpa/ui/app.html#;view_id=story;storyId=885A6D855BDB12DB5C28E9578C323E1B
Various changes are then made within the story – for example here: deleted widgets, changing filters etc
2.2 Deploy changes to productive story
In the second part, the changes made, should be deployed to the original story, shared with the public. In order to get these changes to the original story, press Save As
and choose the Original Story in the respective public folder:
And Overwrite:
The Original story shows now all the changes we’ve done within version 1.2 and in addition the story keeps the original Story-ID.
Changes have been made and end users simply have to refresh their existing story. As the Story-ID has not changed, no further difficulties in accessing the story should occur.
(storyId= 748CE70D4ED1CDE664A1B64E384E9E9E)
2.3 Final Thoughts
When working with a single SAC tenant, versions should be handled carefully. Especially handling of shared URLs including storyIds could lead to unintentionally negative impacts for end users. Keeping the URL/storyid and be able to develop without pressure is very helpful for developers and consumers of a story.
Be aware that personal user bookmarks will be removed by this “save as …” release of a story update. Global bookmarks defined in the development story will be copied but additional global bookmarks defined only in the production story will be lost.
More related Blogs
Lifecycle Management in SAC – Content Network Storage: Single-Tenant Landscape
Lifecycle Management in SAC – Content Network Storage: Multi-Content Network
Lifecycle Management in SAC – Transporting in SAC: Multi-Tenant Landscape