Technical Articles
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.
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:
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.
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.
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.
Waiting for this functionality. Complex process can be automated with this functionality. Thank you for the blog.
Thanks
Kalyan
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
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
Hi Chen Nee, is there already a plan for more improvements in this area?
Hi Jef,
Currently there is no concrete timeline yet to communicate but we are looking into this.
Cheers,
Chen Nee