Learn the Basics of Analytic Application Design
Learn some basic aspects of analytic application design.
What is an analytic application?
An analytic application in SAP Analytics Cloud is an analytical application that visualizes data in various forms and lets you navigate the data. It can also allow planning.
Analytic applications can range from simple static dashboards showing static numbers to highly customized applications with many options to browse and navigate data, change the visualization, navigate across multiple pages or areas, up to an extensively customized look and feel according to customer branding.
What is the Analytics Designer?
The analytics designer for SAP Analytics Cloud is the capability to create analytic applications.
There is a dedicated design environment in SAP Analytics Cloud in order to create such applications. The term design in analytics designer doesn't refer specifically to the UX or UI design aspect of an analytic application. It is the entire process of creating an analytic application: defining the data model, laying out the screen, configuring widgets, and wiring it all up with the help of custom scripts.
The analytics designer offers you another way to create analytical content in SAP Analytics Cloud.
What can you do with analytic applications that you can't do with stories?
An analytic application typically contains some custom logic, expressed with the help of scripts. A story is created in a self-service workflow and can comprise many laid-out widgets and a lot of configured functionality. However, the amount of customization is limited to the foreseen possibilities offered in the story design-time environment. With analytic applications there is much more flexibility to implement custom behavior. It also requires a higher skill level to create those.
How are stories and analytic applications related to each other?
From a consumption point of view, there shouldn't be any difference between stories and analytic applications. The consumer shouldn't be aware of whether the analytical content is a story or an analytic application. The exposed widgets, the available functionality, and the look, feel, and behavior should be the same.
However, analytic applications can use widgets, which do not exist for stories, and can have custom logic, which cannot be implemented in stories since there is no scripting. In general, stories and applications share widgets and functionality to a large extent, but some widgets can only be used in applications because they need to be scripted (dropdown boxes or buttons, for example).
Why do you need both stories and analytic applications?
Stories and analytic applications share functionality and widgets and may even have very similar design environments, so why are two different artifact types necessary? The answer is that story designers and application designers have completely different expectations. This is related to the differences between stories and applications.
In the story design environment, it's practically impossible for you to create a story that doesn't work. The expectation of self-service design time for stories is that business users are guided (to some extent also limited) in what they do and can do. The story design time is supposed to consist of multiple configuration steps that prevent business users from creating something which breaks. With story design time, we ensure some level of consistency.
It's completely different with applications, especially with the added scripts. As soon as application designers add custom logic with scripting, they have complete freedom to change the default behavior of the entire analytic application. The design environment will provide everything to create correct applications, but it doesn't guarantee that the application is correct or won't break.
In addition, an analytic application has a dedicated life-cycle. You start it and then there are certain steps which are performed, like the startup event, for example. The story doesn't have that. You can switch the story between edit and view mode as often as you like.
These are major differences. That is why we offer two artifacts and two corresponding design-time environments to create stories and analytic applications.
What is the typical workflow in creating an analytic application?
An analytic application is always data-driven. The foundation of an analytic application is one or more underlying SAP Analytics Cloud models.
As a first step you decide whether you want to visualize your data in a table or a chart, and add a table or a chart to your analytic application. This triggers another step for picking a model. In addition to widgets showing data, you add to the layout other widgets that control data, such as filters, arrange and configure them, and wire them up.
Almost all widgets expose events. In order to add custom logic to the analytic application, you can implement event handlers with the help of the scripting language.
What are typical analytic applications?
-
Table-centric Data Visualization
The application is comprised of a table, which consumes a large extent of the available screen real estate. Around the table, typically above it, are many UI controls (buttons, checkboxes, dropdown boxes, and so on) to change the data display, such as to filter the data,change the data view, or show different dimensions. The nature of this application is that there is only one table, but many and potentially complex ways to show data differently.
-
Dashboard
The application is a dashboard visualizing a few data points with the help of tiles. There is no interactivity, but it gives users an overview of highly aggregated data. A typical option of some dashboards is to use the tiles for further drilling into details: clicking on a tile takes you to a more detailed page or an entirely new application showing more details for the aggregated number on the tile.
-
Generic Application
Many applications are created for a specific model. That means that the UI, the widgets, and the logic are done with knowledge of the model and its available dimensions, members, and so on. Another category is generic applications. These are applications which need to be provided with a model whenever the application is executed. These applications are more complex to create as their logic needs to work with whatever model the end user selects at runtime. The advantage is that customers don't need to create applications for each and every model they have maintained in their system.
How does scripting work in analytic applications?
Almost all widgets, whether smart, data-related widgets or simple widgets such as buttons and dropdown boxes, expose events. Even the analytic application itself exposes events such as a startup event or similar. In order to add custom logic to the application, you can implement event handlers with the help of the scripting language.
Let's say a dropdown box is populated with the available years in the data model - 2015 to 2019. The dropdown box exposes the event OnSelect, which is triggered whenever a value is selected from the dropdown box. The implementation of that event handler could read the selected value and set a filter for the selected year in the model. The numbers shown will reflect the selected year.
Because you can add many event handlers using the scripting APIs of all widgets and other service APIs offered, the application can be geared towards the specific needs of a customer.
What's the scripting language for analytic applications?
The scripting language is JavaScript. Scripts are executed by the Web browser without any transformation. We use the Web browser's script execution engine, which is available out of the box. In order to offer good tool support for application designers, we add a type system on top. This is used for the tooling and also for script validation. Let's look at an example:
Let's say that there is an API method available for filtering members: setFilter("YEAR", "2014"). The plain JavaScript method expects two strings and this is also what is executed at runtime by the Web browser. However, our definition of the API method uses dedicated predefined types for our problem domain, that is setFilter(Dimension, Member). With that definition, the system checks and validates that the passed strings are a valid dimension and a valid member.
The script editor also uses the type information. It doesn't just statically check the types, but uses the knowledge about the underlying model and provides value help to offer dimensions and members existing in the model.