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)
- 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
- 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
- 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
- SAP Managed Tags:
5 Comments
