Repointing System : SAC Stories with Datasphere Models as Data Source

[Hjaiswal]

Introduction

While SAP is working on a tighter integration of Datasphere and SAC there are still some features missing for advanced administrative tasks. One gap is the missing option to exchange the data source in a SAC Story with a Datasphere live connection. In case the story has to be migrated to a different Datasphere view a new story has to be (re-)created to cover the new source object. This can be very painful and time-consuming in case of complex stories.

In this blog I’d like to show a simple way to change the data source of a SAC story running on Datasphere live connection by calling the SAC API via Postman and change the path to the data source. It doesn’t matter if the new data source is just a different view in the same space or if the new view is in another space or even on another tenant.

The path to the data source consists of three elements:

• Tenant


• Space


• Object

Each or all of these elements can be changed and therefore provide the flexibility to redirect your story to any other Datasphere source which is accessible from your SAC tenant.

Prerequisite

To follow long the step you must have a Postman installed in your system. The Postman scripts used in this blog can be downloaded at GitHub.

The new data source must be consumable/accessible with the given user.

Preparation

Story

To avoid any impact to productive applications we are not working on the original story.

• Create a copy of the story. Note that during this copy process, copies of all SAC models will be created, too. Hence adjusting them will have no effect on the original story.


• Open the copied story and switch to display mode to remove any potential locks.

 

Postman

Import the postman script and navigate to the variables of the collection tab.

Import postman collection

Fill the variables init_* with your specific values:

• init_url: Your tenant URL


• init_cookie: A session cookie - logon to SAC in your browser and copy the session cookie


• init_story_id: Story Id your like convert


• init_old_connection: name before


• init_new_connection: name after


• init_old_space: space name before replacement


• init_new_space: space name after replacement


• init_tenant_id: this is a single digit char - you can find it when you search for a contentlib call - there is a parameter like tenant="id".


• inti_old_dwc_model: model technical id before replacement


• init_new_dwc_model: model technical id after replacement

 

Fill the init variable Current Value

Note:

• The replacement in the story and the model is done using a combination of name-value pair. As an example: "connectionName" is enriched to "SystemName":"connectionName". This helps to ensure that we replace semantically correct. There 3 or 4 name-values pair used.


• If old and new values are identical the replacement is skipped. For example if you leave both values empty, nothing happens.

Perform the repointing

Start a collection runner, e.g. via the context menu on the collection name, and select all requests. The sequence is not relevant - just the "get-csrf-token" request must be first.

Start the execution and check that all tests are green.

Following action will be performed my collection requests:

1. Get-CSRF-Token: GET request to fetch the craft-token by using the session id. Both session id and crf-token required by other requests.


2. GetStory definition from server and replace: POST request to fetch the story details from the server and replace the connection, space, and model only at story level. Identity all the associated models and save changes locally.


3. UpdateStory on the server: POST request to update the server with story local changes.


4. GetModel definition from server: POST request to fetch the model details from the server and replace the connection, space, and model. Save changes locally.


5. UpdateModel replace and send to server: POST request to update the sever with model local changes. If we have more than 1 model present in the story, then request 4 and 5 will repeat in a loop until all models are updated on server.

Congratulation! That's it

Hint: if you have several stories to migrate you need to change the init_story_id and start the next run.