In my last post, I promised to shed more light on the support rules. As I mentioned, they’re developed by the SAP UI5 framework and control experts in collaboration with Fiori design elements and app teams. Since the rules are the backbone of the Support Assistant, I’ve dedicated this article exclusively to the essence of the support rules – their types, attributes, development approach and some extra details.
Let’s start from the basics. What is a support rule?
The support rule is the bread and butter of the Support Assistant. In fact, the usefulness of the Support Assistant depends on the applicability of the rules. A typical rule checks certain conditions, limitations and best practices in the running application. It consists of a descriptive part – its essential properties, and a check function – the active part where all the action happens. Among the rule properties are the ID, audiences, categories, description, resolution and async. The description and resolution give a human-readable synopsis of what the rule checks and how to fix the findings. The async property defines if the rule check function contains asynchronous operations.
The part which I call active is the check function – this is what makes the rules rule 🙂 . The main API assets provided to your check function are oIssueManager, oCoreFacade and oScope. The optional one is fnResolve – it works when the async property is set to true. Check our documentation to get more information about them.
So, think about the rules as a clever way to express a human expertise into a machine-readable and executable asset that can automatically check for a variety of issues and runtime conditions. Here are some possible rule types.
- Structural - related to the application control structure, attributes and runtime instances. For example, it can check all buttons in the application and verify their runtime instance properties. See below a rule of this type.
- CSS - related to CSS modifications. Such rules can check if you have custom styles and if there are controls for which the standard CSS styles have been overwritten.
- Dynamic - related to the application logs and traces, the place to explore and catch true runtime and time-bound issues. These are rules that explore and analyze the log entries or console traces generated by the running application.
In addition, we also cover for more complex checks that involve asynchronous processing. Asynchronous operations in the check function are usually calls to external resource, for example an AJAX call. In such a case, mind that you must call the given resolve function so that our rule engine knows your check logic is done. The rule times out if it takes more than 10 seconds to resolve. The ‘Stable control IDs’ is a good example of such a rule and it can greatly help you to check your App Flexibility readiness.
Well, folks, we’re all set. Are you eager to try it yourself? Just go ahead and start playing with the embedded code editor. Create a temporary new rule or clone an existing one and change it. And then use your favorite Web IDE to submit the newly created rules along with your library in the correct location and test them.
I hope you now have enough understanding of the Support Assistant rule development. With the powerful check engine and API provided, and the wealth of approaches to check at runtime SAPUI5-based applications, only the sky is the limit for your creativity.
Daniel Vladinov
Previous Post: UI5ers Buzz #21
 Daniel Vladinov is a Product Owner at SAP with 13+ years of experience in the company. Member of the UI5 (HTML/JS UI library created by SAP) development unit in Sofia. Strongly focused on UI5 supportability tools. |
- SAP Managed Tags:
