Figure 1 Source: SAP

This was an ASUG webcast given by David Stocker  this week.

Thanks to SAP’s Ingo Hilgefort  for arranging this for ASUG.

Figure 2 Source: SAP

Legal disclaimer applies; things in the future are subject to change and time frames are subject to change.

Figure 3 Source: SAP

Allows you to build widgets / items that SAP doesn’t ship

3rd party components

Partner components

Sold as extensions, ISVs

Once installed, it is just like any widget that SAP ships

Built using web components, and HTML5 extension

Supply JavaScript to implement HTML tags

Using web development JavaScript

D3 is a popular library – the go to library for visualization

Add widget dropdown

On the right, screen shots from last year’s SAPPHIRE – relied on custom widgets

Gauge shown as a widget

Figure 4 Source: SAP

Figure 4 shows widgets at a high level

End user browser, at top see SAC deployment at an AWS data center, there is metadata for every widget, uploaded to SAC client

Do not have data binding yet

Javascript

A widget contains at least two and possible three files:

1.The metadata file, which SAC uses to define the widget

2.A JavaScript file with the code for rendering the widget in the canvas of the application or story. This will be written as a web component. This is the “main” web component.

3.An optional JavaScript file with the code for rendering a web component in the styling pane of the widget during design time. This is the “styling” web component. Source: SAP

Figure 5 Source: SAP

Stored in your tenant

Saved in a widget folder

Explains to SAC what it needs to know about widget

Needs to know where JavaScript is hosted

Script methods, how work, define in metadata

Footprint/styling sheet in panel

Figure 6 Source: SAP

Web components are JavaScript

Styling sheet , build panel, canvas

Figure 7 Source SAP

Has an inner HTML – other HTML – define, hard code CSS

Use CSS in custom widgets

Constructor runs first time opened

When you create property, it is scriptable

Figure 8 Source: SAP

Properties element in JSON

Property called foo

Inside that entity, add attributes – a type, description, default

Types – string or number

Properties :

A property needs two things.

It needs to be defined in the properties section of the metadata .json file and it needs to have getters and setters in the web component .js file. The property definition in the metadata will actually make the property available for reading or setting via script. The getters and setters are what actually hooks that property into the widget.  ​

 

Suppose we had a property called foo: The metadata property definition would have three attributes. It would have the type of property, such as string or number. It would have a default value and it would have a description, for the designer.  ​ In the web component .js file, we’d need to add two methods. get foo()  set foo() ​ ​

 

The get foo() function would be fired whenever we asked for the value of foo via script. The value of foo is whatever we return from this function. It could simply return and existing variable from the web component, it could perform a complex computation, etc. It can do whatever you want, as long as it returns something of the expected type. ​

 

The set foo() function would be fired whenever we set it via script. Again, you can do anything you want on this function, but you don’t need to return anything as a return is not expected for a setter.   Source: SAP

Figure 9 Source: SAP

Methods block in metadata definition

Description, parameters block – pass into script method

Body element – where implementation is – written in Analytics Designer language

Methods ​

The methods section of the metadata is how you add script methods. Each method has a name, a list of parameters that is called with, and a body. The name is what the designer will call via script.  The parameters are the values passed in. Each parameter definition includes a name, a type and a description.  The body is the script that is run when the method is called. It is important to note that this is a script, meaning that it does not have access to the internal workings of the web component, but can see the Analytics Designer scripting API. Be careful here to only execute scripts involving the current widget (via the keyword this) or objects that you can always expect in the app.  Source: SAP

 

Figure 10 Source SAP

Figure 10

Traditional event

Callable

​Events

SAP Analytics Cloud widgets have two separate kinds of events; events within the widget itself and ones dispatched to the scripting environment.

 

Both are running in the JavaScript engine of the browser, but are segregated and you should not confuse them. 1.Traditional JavaScript eventing is listening for browser events; such as onClick. The Mozilla developers page has an excellent and comprehensive reference of browser events.

 

2.The ones that you define within the metadata and these give you the hooks to react via script. You add events to the metadata. Each of these events is a script hook. You can name them whatever you want and add as many of these script hooks as you want. You use the dispatch Event method built into the web component class to fire off these named events. These custom events could be for anything. E.g. you can fire an event whenever a property changes, whenever the user mouses over the widget, etc. You could even add an event for screen resize and provide a scripting hook for that. Source: SAP

 

Road map (subject to change)

• 3 things (planned for H1 2021)
  1. Data binding – bind widgets to model and consume directly; have a work around now – script event, result set, pass it in as parameter, pass current result set to AD widget
  2. When data binding is available, then you can put custom widgets in stories. Today widgets are an application only feature. If plan to have widget in stories and apps, build for both, just no housekeeping done by script
  3. Lifecycle management/catalog support

Q&A

Q: So we can use CSS with widgets on SAC? I thought custom CSS was not supported in SAC designer?

A:Please see this blog – https://blogs.sap.com/2019/12/06/build-a-custom-widget-in-sap-analytics-cloud-analytics-application/ ” A custom widgets are implemented as Web Components. The Web Components are made of HTML, CSS and JavaScript.”

See Blog Post:

https://blogs.sap.com/2020/01/27/your-first-sap-analytics-cloud-custom-widget-introduction/

Q: are there any browser dependencies or browsers that don’t work with widgets?

A: only works with chrome

Q: Will the widget ‘apps’ be support on mobile for IOS and Android?

A: need to test that

Q: Will/can custom widgets support triggering transactions/actions into S/4 for example?

A: If it is an OData action you can do this now already

Q: How can I protect a widget I develop from being swiped, stolen? How can I monetize it?

A: First part of question – tricky, copyright; since you are in charge of hosting your own code you can implement domain name checks; you can sell via SAP Store

Q: Is there a community site for sharing widget examples?

A: not really; Analytics Designer Community at https://community.sap.com/topics/analytics-designer

Create an GitHub for the Analytics Cloud community; he would support

_______________________________________

Stay tuned for data binding