Skip to Content
Technical Articles
Author's profile photo Chen Nee Faulhaber

The Data Action API for Analytics Designer – Beautiful Game Changer

One of the most exciting releases from the SAP Analytics Cloud planning would have to be the beautiful Data Action APIs for the Analytics Designer.

Beautiful – because with just a few lines of code, an Analytics Designer App developer can automate a chain of data actions in background, triggered by a single end user action. This constitutes a simpler and more direct end user workflow, cleaner application UI, and also eases the creation of the planning apps in which less effort can be spent on guiding users through the maze of data action triggers, and more on the business logic. The elegance this API brings to the UI, process, and app structure is something that is definitely going to push planning applications to the next frontier.

Now how does it look like exactly?

In the Analytics Designer you will now find a new technical object “Data Actions”

Once you have created a new object, you will be able to assign an existing Data Action to it via the builder panel, eliminating the need to place a Data Action trigger onto your canvas.

Once you have done that, the app becomes your playground with the following Data Action component methods:

Combined with the DataActionExecutionResponse component, you are able to do some awesome automation in the background, such as:

  • Triggering a Data Action implicitly
  • Using the status of a triggered Data Action to trigger the next in line
  • Setting the Data Action parameters automatically

Below is an example where you can trigger a Data Action (deriveDimension) implicitly, query the execution status and use it in turn to trigger the next Data Action in line (copyAllocatedValue), setting the parameter for it at the same time:

Application.showBusyIndicator("Preparing execution..."); 

var deriveDimResponse = deriveDimension.execute(); 
if (deriveDimResponse.status === DataActionExecutionResponseStatus.Success){
	Application.refreshData();
	copyAllocatedValue.setParameterValue("Investment", selectedMember.id);
	var copyAllocResponse = copyAllocatedValue.execute();
	if (copyAllocResponse.status === DataActionExecutionResponseStatus.Success){
		Application.refreshData();
		Application.showMessage(ApplicationMessageType.Success,"Execution successful.");
		} else {
				Application.showMessage(ApplicationMessageType.Error,"An Error has occured. Please try again."); 
				}
		Application.hideBusyIndicator();
	}

Below is another example where you can use the filter context of another widget and apply it to your data action, making it context sensitive:

var filters = table_1.getDataSource().getDimensionFilters("Account");
for (var i = 0; i < filters.length; i++) {
	if (filters[i].type === FilterValueType.Single) {
		var singleFilterValue = cast(Type.SingleFilterValue, filters[i]);
		dataAction.setParameterValue(parameterId, [singleFilterValue.value]);
	} else if (filters[i].type === FilterValueType.Multiple) {
		var multiFilterValue = cast(Type.MultipleFilterValue, filters[i]);
		dataAction.setParameterValue(parameterId, multiFilterValue.values);
	}
}

You can see now how with just these few lines of code it is possible to say goodbye to the long queues of data actions in the UI and the need for users to enter identical parameters repeatedly as they proceed in their workflow.

(No more long queues of data actions in the UI.)

 

This API could be used in all events of any shape/widget – the possibilities are only limited by your imagination. Typical use cases will of course include using it on the onClick event of a button or onResultChanged of a table – but it is by no means limited to that. And it is worth mentioning that one of the greatest advantages that this API will bring, among the many, is the elimination of the ambiguity in data brought about by the possibility of user having forgotten a trigger or used it in the wrong order. This could now be ruled out.

To conclude – with the new API it is possible to bring the complexity in planning process below the surface and triggering automation precisely there where you need it. It extends your control over the data flow and hence also the data quality.

If you are interested in further related topics, do check out the links below:

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jef Baeyens
      Jef Baeyens

      Absolutely great functionality! Only I miss an event for when users actually change & submit data...
      Vote here if you miss it too.
      I don't see how onResultChange() event in a table can work because it triggers upon each data refresh & filter change.

      Author's profile photo Sean Johnson
      Sean Johnson

      Although it may not work in every situation, checking the isDirty() flag of the planning versions in the onResultChanged() event of the Table object could work. Assuming a simple table with one Public version this would be pretty straightforward as the isDirty() flag will return false after the user publishes the data. However, if you have multiple versions in the same table then you would likely need to use Global variables, in conjunction with the onResultChanged() event to compare current dirty state with the stored dirty state to see which versions (if any) were published.

      Of course this will only work with Public versions as Private versions do not require users to Publish Data.

      Author's profile photo Jef Baeyens
      Jef Baeyens

      Indeed, tried that already but found out it's tricky and prone to error. The table will then need multiple refreshes and/or forced publish actions in the foreground.
      Were you able to get to a workable best-practice?

      Also with isDirty() flag on Version there's no easy way to distinguish which input / table the user has updated, let alone with which filters, such that the right & perfectly scoped data-action gets triggered.

      Author's profile photo Dantuluri Kalyan
      Dantuluri Kalyan

      Waiting for this functionality. Complex process can be automated with this functionality. Thank you for the blog.

      Thanks

      Kalyan

      Author's profile photo Jorge De Miguel
      Jorge De Miguel

      Hi,

       

      Do you know if there is a way to execute the data action in the background as a non blocking process? I have noticed that users have to wait for the data action to finish to carry on working on the application. I can't see an option to trigger it as a background job like we can in normal stories.

       

      Any ideas?

       

      Thanks

      Jorge

       

      Author's profile photo Chen Nee Faulhaber
      Chen Nee Faulhaber
      Blog Post Author

      Hi!

      Currently this is not supported, but we are looking into this. Meanwhile it is worth considering:

      a) is it possible to reduce the scope of your data action further

      b) should this chain of data actions be only triggered by this one persona alone, or can it be shifted to a scheduled workflow. E.g. scheduling the data action via Calendar to take place at certain intervals.

      Cheers,

      Chen Nee

      Author's profile photo Jef Baeyens
      Jef Baeyens

      Hi Chen Nee, is there already a plan for more improvements in this area?

      Author's profile photo Chen Nee Faulhaber
      Chen Nee Faulhaber
      Blog Post Author

      Hi Jef,

      Currently there is no concrete timeline yet to communicate but we are looking into this.

      Cheers,

      Chen Nee