Technical Articles
SAP Analytics Cloud Story development in a single tenant scenario
SAP Analytics Cloud is a powerful frontend and offers multiple option 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 landscape with one tenant, acting as development system, quality system and productive system this could get a challenging. Stories and their URLs are often shared and changing StoryIds could lead to a lot of trouble.
Objective
In this blog we describe how story development can be done within a single tenant scenario. The aim is to keep Story-Ids of stories stable and be able to develop and run a productive story at the same time.
Setup
The productive version V1.0 is located in a folder with storyid 93600301222716D3CE41C815C44AEF2B available through URL https://<tenant>/sap/fpa/ui/app.html#;view_id=story;storyId=93600301222716D3CE41C815C44AEF2B
To separate development from productive story a folder is created to keep development versions.
In our case we created the folder “Development” and share this folder only with the development team.
Within this folder we can keep development versions and further reflect this in the naming of the story.
Create a new Version and handle bookmarks
Before creating a new version, the productive version has to be copied to the development folder and renamed to the new version. When coping the current active productive version all global and private bookmarks will be save into the development version.
In our case we have created one global bookmark “Before_Copy_Global” and one personal bookmark “Before_Copy_Personal” before coping the productive version to a development version.
We copied productive version 1.5 to version 1.6 in development folder (Dashboard_V1_6.) in order to do our changes.
A closer look at the bookmarks of the copied story 1_6 will show also the bookmarks created on the productive version are still available in the copy.
We now change our copied version 1.6 accordingly and create new bookmarks named “After_Copy_Global_V16” and “After_Copy_Personal_V16”.
Deploy changes to productive story
Simple with “Save As” in “File Menu” and selecting the productive story we are able to deploy version 1.6 to the productive version and overwrite 1.5.
Select the productive version and rename Dashboard_XX
Confirm overwriting the existing item.
After doing this the changes done in version 1.6 are deployed to the productive version. The storyid is still 93600301222716D3CE41C815C44AEF2B and still available through URL https://<tenant>/sap/fpa/ui/app.html#;view_id=story;storyId=93600301222716D3CE41C815C44AEF2B
All bookmarks are copied from development version 1.6 to the productive version. All bookmarks created during development time in the productive version are deleted.
Conclusio
When working with a single SAP Analytics Cloud tenant version 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 in my opinion very helpful for developers and consumers of a story.
But always keep in mind that only bookmarks of the copied version will survive.
Hi Mario,
nice blog! Good to see that our thinking in regards to development in single tenant matches yours!
One thing I would like to point out: in our system we observe that the publication to analytical catalog is lost when you overwrite the "productive" version. So we make sure to screenshoot the publication before overwriting to be able to publish "again" to same teams as before.
Hopefully SAP will fix this sometime as it can be painful if the story is shared across various teams and I don't understand why the publishing is lost at all as the ID remains same ....
Best regards,
Axel
In addition to the deletion of the object in the Catalog, users will also no longer see the object in "Favorites" (if tagged prior), is removed from a user's "Recent Story" list, and any object level shared permissions are deleted as well.
Hi Mario,
we also did this approach on one of our customer projects.
It works, but you definetly need to be careful, just as you pointed out.
Nice Blog!
Kind regards
Eric
Hi Mario,
thanks for sharing you thoughts, I actually didn't know that "save as" preserves the storyID of the "saved to"-file.
Best Regards
Thomas
The problem with single tenant development comes into play when one utilizes a live connection such as a BW system in the backend. As the model of a story will point to the productive system there is no easy way to create a copy of the story/application that will then point to the dev or quality system. This would also impact the productive version of the story or the designer needs to basically recreate the whole story and point it to different models that point to the dev/quality system.
So with live connections it is not really feasible to use only one tenant if changes to the underlying data structures in the source system are needed.
Hi, Can you guide me how you connect to the respective system connections to models from each folder like Dev versus QA for example? Or when you do save as the new story should fetch data from the DEV or QA system respectively.
thanks in advance.