SAP Fiori Elements Overview PDF

Overview of SAP Fiori Elements ============================== Explaining the Architecture of Fiori Elements --------------------------------------------- **Challenges of Fiori Elements:** --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Challenge Solution ----------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Uniform Experience** -- a way to ensure uniformity so that the output from every development team looks consistent and performs well Since the templates in SAP FE are developed and maintained by SAP, you will get the same user experience consistency with SAP standard Fiori apps. The development investment is protected going forward as SAP will handle the UI updates. **Expensive Redesign** -- SAP Fiori system has been evolving, UX is getting better. But it would be expensive to redesign all the Fiori apps. SAP FE allows to scale SAP Fiori development by delivering a template and metadata-based approach to app creation. **Extensive App Volume** -- the number of Fiori apps has been growing. In 2013 there were 25 apps, now thousands. SAP FE and SAP Fiori tools gives the means to accelerate development and keep maintenance in check, thus enabling us to handle this volume.\ Apps that are built using SAP Fiori elements are automatically enterprise-grade apps. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SAP FE provides UI logic out of the box (like navigating between pages and apps, ability to search, sort, and filter lists. **SAP FE Page Types:** - **Overview Page** -- data-driven SAP Fiori app for organizing large amounts of information. Information is visualized in a card format in an attractive and efficient way.\ Different cards are used for different types of content. - **List Report** -- SAP FE contains predefined templates for list reports and object pages. A list report lets users filter, view and work with items (objects) organized in list (table) format. - **Analytical list page (ALP)** -- offers a unique way to analyze data step by step from different perspectives, to investigate a root cause through drill down, and to act on transactional content. You can use SAP FE to build apps that require visualization and reporting of data using filters, interactive charts, and other data points such as KPIs - **Worklist** -- displays a collection of items to be processed by the user - **Object Page** -- lets users work with objects, providing functions for viewing, editing and creating objects. Typically used in conjunction with an object page. **OData Versions**: **OData V2** -- allows to add annotations to metadata document. The purpose of the annotations is to add information and hints to the Entity Data Model elements. This structural metadata makes it easy to understand a service, and human-readable documentation can be directly embedded into the metadata document, helping developers consume and OData service. In ODataV2 the annotation is stored in XML tag of Data metadata to describe an entity or fields like datatype, nullable and so on. **OData V4** -- you get a reduced amount of data, through a more powerful query language, a revised and optimized JSON protocol and a change in the metadata concept. In OData V4 annotations are separated from the main part of the OData metadata document. It can be a stand alone part of OData metadata document apart from the main part, or can be stored in a separate file. **Vocabulary** -- defines how you can add annotations to an OData service. All annotation files must start from references and give an alias to some vocabularies. The form of vocabulary is an XML document containing information of Terms and Types. In SAP FE scenario, the most important vocabulary is UI vocabulary. It defines most of the annotations you can use in SAP FE. **Target** -- annotations must be grouped by targets. Targets associate a group of annotations to something in OData service. As most annotations are data relevant, they try to target an entity type or property. In some cases, annotations target an Association, a Function Import, or other objects in OData service. **Term** -- all annotations must have a term. A term determines the meaning of an annotation. For example, term UI.FieldGroup defines a group of fields. If you have two annotations with the same term for the same target, a qualifier must be added to make your annotation unique. Terms are defined in a vocabulary. A term definition comprises the following Information: - **Term Name** -- refers to the name of the term - **Data Type** -- if there is only one record in the term, write the name of the type. If the term has multiple records, the Type attribute needs to be 'Collection(\)' - **Applies To** -- defines the kind of elements in OData service that can be a target of this term - **Nullable** -- the default value is true. Most annotations are Nullable - **Annotation Term** -- used to refer to development tools **Type Inheritance** -- supported for better re-usability. Abstract data type has the properties of Base Data Type. **Smart Controls** -- specific category of SAPUI5 controls that have some special features in addition to the standard SAPUI5 features. This makes it easier to use the control in certain scenarios. Explaining Templates for Fiori Elements --------------------------------------- ### List Report With a List Report users can view and work with a large set of items. This floorplan offers powerful features for finding and acting on relevant items. It is often used as an entry point for navigating to the item details, which are usually shown on an Object Page. **Use the list report floor plan if:** - Users need to find and act on relevant items within a large set of items by searching, filtering, sorting and grouping - You want to let users display the whole dataset using different visualizations, but no interactions are required between these visualizations. - Users need to work with multiple views of the same content, for example on items that are "Open", "In Process", or "Completed". You want to let users switch views using tabs, segmented buttons, or a select control. - Drilldown is rarely or never used - Users work on different kinds of items **Do not use the List Page floorplan if:** - Users need to see or edit one item with all its details (Object Page Floorplan) - Users need to work through a comparably small set of items (Worklist Floorplan) - Users need to extract knowledge or insights from data (ALP) ### Object Page Used to display and categorize all relevant information about an object. Categorized content can be accessed quickly using anchor or tab navigation, and users can switch from display to edit mode to change the content. To create a new object, users can switch to create mode. Comes with flexible, responsive layout and a dynamic page header that can be adapted to display simple and complex business objects. This allows you to adjust the layout of a wide range of use cases. **Us the object page floorplan if:** - Users need to display, create or edit an object - Users need to get an overview of an object and interact with different parts of the object **Do not use the object page floorplan if:** - Users need to edit several items at the same time, find relevant items without knowing the exact item details (List report floorplan) - Users need to be guided through a series of steps when a new object is created, the creation process for a new object is not linear, but can have different paths, depending on the information selected (Wizard floorplan) - Users need a way to analyze data step by step from different perspectives, need to interact with independent chart and table views (ALP) ### Overview Page (OVP) Data-driven SAP Fiori app type that provides all the information a user needs in a single page, based on the user's specific domain or role. It allows users to focus on the most important tasks, and view, filter and react to information quickly. Each task or topic is represented by a card (or content container). The overview page acts as a UI framework for organizing multiple cards on a single page. **Use the OVP if:** - You want to provide an entry-level view of content related to a specific domain or role - Users need to filter and react to information from at least two different applications to complete their role-specific tasks. - You want to offer different information formats (such as charts, lists and tables) on a single page. - You plan to have at least three cards. They should not all be of the same type. **Do not use OVP if**: - A high-level or birds-eye view of app content is sufficient - You just want the user to launch an app (SAP Fiori Launchpad home page) - You want to show info about one object only (Object page floorplan) ### Analytical List Page (ALP) Offers a unique way to analyze data step by step from different perspective, to investigate a root cause through drilldown and to act on transactional content. All of this can be done seamlessly within one page. The purpose of ALP is to identify interesting areas within datasets or significant single instances using data visualization and BI. The main target group are users who work on transactional content. They benefit from fully transparent business object data and direct access to business actions. **Use the ALP if**: - Users need to extract key information to understand the current situation or identify a root cause. The way the data is presented is crucial for giving them the insights they need to take the right action - Users need a way to analyze data step by step from different perspectives, investigate a root cause through drilldown and act on transactional content within one page - In addition to the filtered dataset, users need to see the impact of their filter settings in a chart (visual filter) - Users need to switch between integrated chart and table views (hybrid view) - Users need to see the impact of their action on a KPI - Users need to find and act on relevant items out of a large set of items by searching, filtering, sorting, grouping, drilling down and slicing and dicing - Drilldown is rarely used, not used at all, or is only needed after navigating to another page, rather than as free or flexible drilldown within the page itself. Users need different visualizations for the entire dataset. Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping, without using drilldown or \"slice and dice\". (List Report Floorplan) - Users need to find a specific item, and the item or an identifying data point is know to the user (such as code). (Initial Page floorplan) - Users need to work through a comparably small set of items, one by one. Users need to interact with interdependent chart and table views (rather than using charts for visualization only). (Worklist floorplan) ### Worklist Page Displays a collection of items a user needs to process. Working through the list usually involves reviewing details of the items and taking action. In most cases, the user has to either complete a work item or delegate it. It's a versatile floorplan that offers three main variants: - **A simple worklist (plain page with a table)** - **A worklist with tabs** - **Worklist with one or more KPI tags** **Use the worklist floorplan if:** - Users have numerous work items and need to decide which ones to process first. - You want to give users a direct entry point for taking action on work items. - Users need to work with multiple views of the same content (for example, items that are \"Open\", \"In Process\", or \"Completed\"). You want to offer tabs for switching between views. **Do not use the worklist page floorplan if:** - The items you are showing are not work items. - You want to show large item lists, or combine different data visualizations (charts or tables). Users need to find and act on relevant items from within a large set of items by searching, filtering, sorting, and grouping. (List report floorplan) Exploring the Basic Process of Building Fiori Elements Application ================================================================== Steps: 1. Create an SAP Fiori elements application. 2. Choose an OData service. 3. Create an annotation file and writing annotation. 4. Modify the configuration file. 5. Translate resource bundles. 6. Deploy your SAP Fiori elements application. 7. Configure SAP Fiori launchpad. 8. Authorize user to access the SAP Fiori application. 9. Log on to SAP Fiori launchpad and add the tile to the SAP Fiori launchpad. Using the Core Data Services (CDS) View --------------------------------------- The ABAP Core Data Services (ABAP CDS) are the platform-independent implementation of the general CDS concept for AS ABAP. The ABAP CDS makes it possible to define sematic data models on the standard AS ABAP database. Unlike the SAP HANA-specific variant HANA CDS, the ABAP CDS are independent of the database system. **Basic Syntax of CDS**: - **SQLView Name** -- for compatibility with ABAP dictionary, each CDS must have a name in Old ABAP dictionary format (Max length: 16) - **Data Source** -- A CDS view selects data from one or several database tables or CDS views. If data comes from more than one data source, SQL JOIN syntax can be used to select data from multiple data sources. - **Projection List** -- the most important part of a CDS view. Complex expressions can be used to create calculated field. **Annotations for CDS Views:** **Domain** **Usage** ------------------------------ --------------------------------------------------------------------------------------------------------------------------- **UI Annotations** Most important domain for Fiori Elements. Nearly one-to-one relationship between CDS annotation and OData annotation term **Consumption Annotations** Control visibility of a data field or the whole entity. Useful when defining value help for a field **Object Model Annotations** Provide definitions of structural as well as transactional related aspects of the business data model **Semantics Annotations** Enrichment of semantic information for data field **CDS Associations** A CDS view can define some associations. An association is a declaration of the relationship of views which can be consumed by itself or by the consumer of this CDS view. **Three main areas of an association:** - **Definition** -- quite like SQL JSON syntax. An easy way to reference fields in the current project list is \$projection - **Use Fields from an Existing Association** -- access fields from associated CDS view by connecting association name and field name with a period '.' - **Expose an Association for External Use** -- to expose an association for consumer of this view, write the name of association in the projection list. Using the Service Adaptation Definition Language (SADL) ------------------------------------------------------- All SAP Fiori elements related annotations are translated to OData annotations. In this way, you can combine your business logic, OData service development, and annotation into one CDS view. If a CDS view has the annotation \"\@Odata.Publish:true\", an OData service is generated automatically in your back end system. The only thing you need to do is to activate it in your front end system. Each OData service, no matter how it was developed, must be activated in transaction/IWFND/MAINT\_SERVICE so that it can be queried externally. The CDS view you are working on is transformed to an EntitySet with a name identical to the generated OData service. All CDS views associated to this view are also transformed to an EntitySet. The association relationship is transformed to the Association and Navigation Property in the OData service. Like OData Annotations, CDS Annotations can apply on an EntitySet or a data field. In most cases, there is a 1:1 relationship between an OData annotation term and a CDS annotation with a similar name. CDS Annotations are grouped by target. Annotations with the same target stay together. OData Annotations do not have a fixed position. It is usually grouped by terms. When translated to an OData annotation, the sequence of CDS annotations belonging to one term is determined by a position property. Explaining Metadata Extension ----------------------------- The syntax of CDS will grow if complex annotations are needed. That may reduce the readability of CDS. A **metadata extension** separates annotation from business logic. **Perform the following steps to implement a metadata extension:** 1. Add an annotation of *\@metadata.allExtensions:true* to the CDS view. 2. Create a Metadata extension and write annotations for the view and its fields. 3. Use \";\" to separate fields. Learning Scenarios of Fiori Elements Implementation =================================================== Minimum version of SAP NetWeaver is 7,50 SP01 (Otherwise the SADL will not work) Many new annotations are added in each upgrade of SAP NetWeaver. Hence, SAP Fiori elements will be more powerful if you choose the newest version of SAP NetWeaver. NetWeaver Web IDE Related S/4HANA Version ---------------------- --------------- --------- ------------------------- List Report \>= 7.50 SP01 \>=1.17 S/4HANA 1511 Object Page \>= 7.50 SP01 \>=1.17 S/4HANA 1511 Overview Page \>=7.51 \>=1.17 S/4HANA 1511 Analytical List Page \>=7.52 \>=1.17 S/4HANA 1709 In general, CDS works on any database, but SAP HANA is recommended when good performance is needed, due to CDS push down the calculation to the DB layer. If SAPUI5 runs on a non-ABAP platform like SAP CP, or you\'re using OpenUI5, SAP Fiori elements only requires the version of SAPUI5/OpenUI5. SAPUI5/OpenUI5 SAP\_UI ---------------------- ---------------- -------------------------------- List Report \>1.38 SAP\_UI 7.50 and UI add-on 2.0 Object Page \>1.38 SAP\_UI 7.50 and UI add-on 2.0 Overview Page \>1.44 SAP\_UI 7.51 Analytical List Page \>1.48 SAP\_UI 7.52 **When to choose SADL Annotation vs Local Annotation?** **SADL** **Local** ----------------------------------------------- ------------------------------------------------------------------------- Write annotation for the entire view Complex annotation not associated to particular field (ex. UI Facets) Write annotation for one field Back-end server is not ABAP server (for example AS Java, Hana) Data intensive logic (for example Value Help) The annotation you want to use is not supported by current ABAP version List Report =========== Explaining Basic Annotations for List Report -------------------------------------------- The list report is a full screen floorplan. It can also be used in flexible column layout, where it is usually displayed in the first column. The list report page is based on the dynamic page, and is divided into a header area and a content area, as defined by the dynamic page layout. ### Components: - **Dynamic Page Header** -- contains the header title and the expandable/collapsible header content - **Header Title** -- part of the header area and should display a title or variant for the whole page (mandatory), filter information (if the header is collapsed) and a header toolbar with global actions such as Share (optional) - **Header Toolbar** with global actions - **Header Content** -- used to display the filter bar of the smart filter bar (mandatory) - **Header Features** -- allow users to expand/collapse the header (mandatory) and pin/unpin the header area - **Content Area** - **Table/chart title, textual icon tab bar** or **select** (optional) - **One table/chart toolbar per tab** - **One or multiple tables and/or charts** ### Basic Annotations for Creating a List Report **Mandatory:** - **OData.publish:true** -- auto exposures the CDS view as OData Service - **\@UI.headerInfo.typeNamePlural** -- Determines the text displayed on the upper left corner of the list report ### Annotations for Adding Columns to Report **\@Ui.lineItem** -- used to set default columns for list report. Its Data Types are a collection of Data Fields, but in most cases only one \@UI.lineItem exists for a field.\ Mandatory property: **position** -- determines the sequence of columns. ### Annotations for Semantic Information The following items should be noted when adding semantic Information for amount/quantity fields: - For amount and quantity fields, you should point out where to find its currency/unit fields. - Fields selecting from DDIC or other CDS entities may already have this information. If it is defined correctly, the currency/unit displays with the amount/quantity fields. Options for Adjusting the Display of Columns -------------------------------------------- The controls used in a list report are designed for all clients. Different clients have different screen widths. The fields displayed in a Smart Phone should be smaller than a desktop browser. Use **\@UI.lineitem.importance** to determine in which clients the field should display: - **\#HIGH**: Default value, display in all clients - **\#MEDIUM**: Only display in desktop browser or tablet - **\#LOW:** Only display in desktop browser ### Hiding Fields Some fields are not suitable for displaying on the report. You can use \@UI.hidden to hide them in the table settings dialog. Using Searching and Filtering Data ---------------------------------- Searching and filtering data are fundamental functions for a report. The List Report supports two ways of search and filtering: - **Search Field** is a field in the top left corner of a list report. Users can search data by entering a keyword in the search field. The report searches data across several fields according to the rule defined by developer. - **Selection Fields** are input fields with value help dialogs on top of a list report. Each selection fields represent a filter for one property of the back end OData service. Users can customize selection fields of their own and save them as a variant. To add a search field for a list report, enable it on CDS view level by adding a **\@Search:searchable:true** annotation. To enable a selection field, use **\@UI.selectionField.position** as the element annotation on the field that needs to be a filter. Even fields that do not display as a column can be used as a filter condition. Providing the Value Help ------------------------ If there is an association for a field, you can use this association as a check table for the field. Then, you can provide a value help for the user. The following steps are used to provide value help with foreign key association: 1. Find appropriate association for value help. 2. Annotate the selection field with *\@ObjectModel.foreignkey.association*. 3. Expose the association. Although it\'s easy to declare a foreign key based value help, it has the following limitations: - Normally, only technical key fields of a business entity have the association to other views, which are fields we want to hide from the end user. - In the search help window, only the key field and one field annotated with *\@semantics.text:true* can be displayed in the search result window. - All fields from check view are present as selection fields of the value help screen. **Steps to create a modeled value help view:** 1. Create a CDS view, select data from existing table or CDS view. 2. You can add additional \'where\' conditions and calculated fields for your value help view. 3. Create an association from your report CDS view to the value help view, associate them with a selection field, which is understandable by end users. 4. Annotate the selection field with **\@Comsuption.valuehelp:\'\.** 5. Expose the association Explaining Variant Management ----------------------------- SAPUI5 flexibility services enable functions for different user groups to personalize SAP Fiori apps, adapt their user interface at runtime, and develop new apps. The service store user-specific data and client-wide data in a special repository on an ABAP server, which is called layered repository. **Prerequisites of SAPUI5 Flexibility Service**: - Server: ABAP front end server and SAP NetWeaver 7.31 SP11 (or higher) - The following ICF node must be activated: /SAP/BC/UI5\_Ui5, /SAP/BC/LREP - For creating shared variants: ABAP authorization object /UIF/FLEX with authorization field /UIF/KEYU = \'X\' is required, A transport request with a task assigned to the user is required The *Selection Variant* stores filter conditions for users. After filtering the data, a user can save the condition as a variant. The following items are options for a selection variant: - Name: Name of the variant - Default: Select this variant when user entering the report - Execute on Select: Execute query immediately after user select the variant - Shared: Shared variant, a transport request must assigned when set a variant to shared A user can manage their variants by clicking the *Manage* button. Object Page =========== Using Basic Annotations for Object Pages ---------------------------------------- ### Elements of object page: - Dynamic page header (mandatory) - Navigation bar (optional) - Content area (mandatory) **Dynamic page header** -- contains key information about the object and provides the user with the necessary context. It also contains global actions for the object such as Edit or Delete. ### Basic Annotations for Object Pages - **\@UI.headerinfo.typeName** - Indicates the type name of the business object. - **\@UI.headerinfo.title.value** - Points to the ID data field. - **\@UI.headerinfo.description.value** - Point to the Description data field. - **\@UI.identification -** Like UI.LineItem, fields with this annotation displays in the *General Information* section of the page. Using Header Facets for Object Pages ------------------------------------ **Header Facets** - pieces of information placed on the header part of an Object Page. Generally, key information and status information should be put in this area. **Types of Header Facets:** - **Field Group Facet** - displays a group of fields with a label - **Plain Text Facet** -- displays description information from exactly one field - **Communication Facet** -- generates a hyper link. The user can access communication information by selecting the link (for example phone, email) - **Smart Micro Chart Facet** -- displays a micro chart to help the user get the most important KPI information - **Rating Indicator Facet** -- displays rating information as stars - **Data Point Facet** -- displays a key figure or status information in different color or style to help user get the meaning at glance (for example availability: In Stock) **Field Group --** defines the fields displayed within a specific reference facet. The term UI.FieldGroup is used to define field groups. Because, in most cases, a CDS view has more than one field groups, a qualifier should be assigned to each field group to distinguish among those field groups. A field can belong to different field groups so that the UI.fieldGroup annotation for each field is an array. The annotation should use JSON format for easier modification in the future. To define a Field Group facet, a **\@UI.facet** annotation should be added for the first field of a CDS View. The **Plain Text Header Facet** is quite like the field group header facet. To define a **plain text header facet**, you should do the following: - Define a field group containing only one field. - Set the field as a multiline text. Technically, a **communication header facet** is a Field Group header facet. The only difference is at least one field of the field group should reference to a *vCard.Contact* annotation. Currently, a **communication header facet** can only be created by adding local annotation through the annotation modeler in SAP WebIDE. If there is more than one header facet, they will arrange in a row and will start a new row if there is not enough room. Using Sections and Facets in Object Pages ----------------------------------------- The areas of the Object Page below the header facets are facets grouped by sections. There is also a navigation bar for navigation to specific sections. **Types of Facets in Sections:** - **Contact Facet** -- displays contact information from a 1 to \* association - **Plain Text Facet** -- displays a long description - **Smart Chart Facet** -- displays a chart - **Field Group Facet** - displays field groups in a section Back end annotations do not support the definition of facets. Local annotation can be used to define facets. Guided Development will help you create a facet and add the facet (if needed) to a newly created section. There are different terms for the collection facet and the reference facet. The steps are: 1. Create a UI.CollectionFacet. 2. Create a UI.ReferenceFacet under the collection facet and reference it to field group annotation. If you need to display data from a 1 to \* association as a table in an object page, you should use a reference facet to create a section, since the section can only contain one facet. Steps to display data of a sub-entity through CDS annotation: 1. Create a CDS view for detailed data (for example sales order items data) 2. In the CDS view for the list report, create a to \* association to the CDS view created in step 1 3. Expose the association by writing its name like a field 4. Create a facet with type \#LINEITEM\_REFERENCE and link it to the association by setting the targetElement property Advanced Topics of List Report and Object Page ============================================== Explaining Navigation Concept and Annotations --------------------------------------------- **Internal Navigation** -- navigation within a Fiori Elements app. Configured in **manifest.json** **3 Types of internal navigation:** - From List Report to Object Page - Within List Report Only - From Object Page to Subpage **Flexible column layout** -- allows different layouts on the same page. Up to 3 columns so users can expand and collapse the screen areas. Defined in **manifest.json**. **External Navigation** -- navigate to other addresses **Two options**: - **Using a URL**: Navigates to any URL \[create a field representing URL -\> add a link, set the type \#WITH\_URL and point to the URL field using the *url* property - **Using Semantic Object Navigation** (Display as a link/Use a button on the toolbar) \[Add *\@consumption.semanticObject* before the field, Set *UI.lineItem.type* to \#WITH\_INTENT\_BASED\_NAVIGATION (as a link) or \#FOR\_INTENT\_BASED\_NAVIGATION (as a button), Set *\@UI.lineItem.semanticObjectAction* Using Data Visualization ------------------------ ### Data Visualization: 1. **Criticality** -- display a value in a different state (Neutral, Negative, Critical, Positive) with different colors 2. **Micro Chart** -- for the header of an Object Page. Add an area micro chart or a bullet micro chart. 3. **Rating Indicator/Progress Bar** -- for data to represent a rating or progress, a rating indicator and a progress bar can be used to display them in a more vivid way 4. **Smart Chart** -- in the section area of the Object Page, add a smart chart as a section to get insight from an entity set with 0..\* association Overview Page (OVP) =================== Exploring the Overview Page (OVP) --------------------------------- Basic structure and appearance of the OVP is governed by the **dynamic page layout** and is divided into a **header area** and **content area**. **Dynamic Page Header** -- comprises the header title and expandable/collapsible header content **Content Area** -- the OVP layout describes the position, size and characteristics of cards in the content area below the dynamic page header. Two layout variants: **Fixed card layout**/**Resizable card layout** **Cards** -- containers for app content. Represent entry-level view of the most pertinent app data for a given topic or issue. ### Card types: 1. **List Card** -- displays lists of records. Up to 6 fields of data in each list item 2. **Bar Chart** -- type of object group card, displays a set of items in a vertical list 3. **Link List Card** -- allows to view a list of links with title picture, icon or subtitle 4. **Analytical Card** -- lets view data in a variety of chart formats. The card is divided into two areas (header and chart) 5. **Table Card** -- displays a list of records. Displays data in a 3-column table layout. (Can configure smart links to access quick links) 6. **Quick View Card** -- single-object cards. Display basic details for one object, such as the name, address and phone numbers 7. **Stack Card** -- aggregate a set of cards of the same type, based on a common topic or action ### Create an OVP 1. Prepare Backend Service for Global Filter 2. Prepare Backend Services for Cards 3. Create Fiori application using OVP template 4. Add a card to an OVP ### OVP Properties: - **smartVariantRequiredEnable/Disable** the smart variant management control on the smart filter bar. - **showDateInRelativeFormat **Show date on the SFB like *yesterday*, *tomorrow*, and so on. - **enableLiveFilter **Show/Do not show the Go button on the smart filter bar. - **refreshIntervalInMinutes** Refresh the OVP every x minutes, minimum is 1 min. - **useDateRangeType **True // true to enable Semantic Date, default false. Modularizing SAPUI5 Applications ================================ **Modularization** -- instead of defining and loading a large bundle of JS code, an application can be split into smaller parts, that can be then loaded at runtime when they are needed. **Module** -- a JS file that can be loaded and executed by the browser. Is defined by calling the sap.ui.define() method. **Configuration Options:** - **async** -- enables the module loader to load single modules as well as library preload files asynchronously - **onInit** -- define code that is executed after initialization - **resourceroots** -- possible to redirect requests for app-specific modules to the corresponding Web application Working with Views and Controllers ================================== **Model View Controller (MVC)** -- concept used in SAPUI5 to separate the presentation of information from user interaction. This facilitates the development and modification of an application. **Model**: Contains the application data and provides methods for reading and changing the data **View**: Responsible for defining and rendering the UI **Views** can be linked to a **Model** via **Data Binding**: - **One-way binding** -- view can only display the model data on the UI - **Two-way binding** -- data changes mad by the user on the view are written back to the model **Controller:** implemented in JS and defines via its methods how models and views interact ### View Types: 1. **XML view** -- declarative views in which the UI is defined in a file or string in XML format (recommended) 2. **JSON view** - declarative views in which the UI is defined in a file or string in JSON format 3. **Typed view** -- UI is defined in a programmatic manner using JS. The view is defined using a separate view class ### View Instantiation - **Create** method in the class **sap.ui.core.mvc.XMLView** - **Create** method is passed as an object with the required configuration options (for example id, viewName) - **Create** method loads views asynchronously via the module system ### Working with View Controllers To assign a controller to an XML view, the attribute **controllerName** can be used in the **\** tag.\ SAPUI5 loads the controller via the module system. Controls can trigger event (for example button -\> press). In XML View **event handlers** can be attached to events. To do this, an attribute with the name of the event is added to the corresponding control tag, for example a **press** attribute to a **\** tag. Structuring the Application via Components ========================================== Configuring and Instantiating Components ---------------------------------------- **Components** -- independent and reusable parts used in SAPUI5 applications. They facilitate the encapsulation of closely related parts on an application. Types of components: - **Faceless components (class: sap.ui.core.Component)** -- have no UI and are used for coding then no UI elements are needed, such as for a service that provides data from a back-end system - **UI components** **(class: sap.ui.core.UIComponent)** -- extend faceless components and add rendering functionality to the component. They represent a screen area or element on the UI along with the respective settings and metadata. ### Structure of a Component 1. **Component.js** file -- component controller, provides the component methods and the component metadata. Defined as a JS module by calling the **sap.ui.define** method 2. **Descriptor** -- provides a central, machine-readable and easy-to-access location for storing metadata associated with component To render UI components, wrap in a **sap/ui/core/ComponentContainer**. **Options to load and create a new component:** - Create a new component instance asynchronously before creating the container using the *create* method of **sap.ui.core.Component** - Create a new component instance asynchronously when creating the container using the constructor of **sap.ui.core.ComponentContainer** Implementing the UI =================== Structuring the UI with Controls -------------------------------- Simple Form: - Toolbar (Optional) - Content - Title - Label - Input **Panel** -- provides a container for grouping and displaying information. Consists of a title bar, an optional header toolbar, optional info toolbar and a content area. **Page** -- container control that hold one whole screen of an application. Often used as the root control of a view.\ **Areas:** - **Header** -- title, navigation button - **Content** -- determines the content of the page, occupies the main part and can contain any number of controls of any type - **Footer** -- optional, occupies the bottom part of the page Application often consist of multiple pages, where the user can go to detail pages and back again. SAPUI5 supports this pattern by providing the control sap.m.App. The App control inherits the navigation capabilities from the sap.m.NavContainer control. Using Densities for Controls ---------------------------- ### Content Densities: - **Cozy** (Phone, tablet) (default) **\[sapUiSizeCozy\]** - **Compact** (Desktop) **\[sapUiSizeCompact\]** Dealing with Fragments as Reusable UI Parts =========================================== **Fragments** -- UI parts that can be reused. Defined similarly to views, but do not have their own controller. Can connect to the controller of the owning view. Types of Fragments: XML, HTML, JS **XML Fragments** are like **XML views** but have no **\** tag as root element. Instead, they have **\** as root element. A file containing the definition of an XML fragment has the extension **\*.fragment.xml** **Options to instantiate fragments via API:** 1. **Use method loadFragment()** -- if a fragment is to be instantiated within a view controller, the **loadFragment** method can be used. It is available in any view controller. The method passes to the created fragment the view controller as fragment controller. 2. **Use method sap.ui.core.Fragment.load()** -- outside of controllers, the generic method sap.ui.core.Fragment.load can be used **Dialogs** -- fragments that open on top of regular app content, and thus do not belong to a special view. Can be used in more than one view of an application. Elements of a Simple Dialog: - **Sap.m.Dialog root control** -- used to prompt the user for an action or confirmation. When the dialog is opened in the application, it interrupts the current application processing because it is the only focused UI element and the main screen is blocked - **Content** -- fully customizable, defined using the **content** aggregation - **beginButton** -- used to define an action button that will be displayed in the footer area of the dialog Models and Data Binding ======================= Working with Models ------------------- **Model** -- in the Model View Controller concept holds the data and provides methods to retrieve the data and to set and update the data. **SAPUI5 predefined models:** - **OData Model (v2, v4)** -- enables binding of controls to data from OData services - **JSON** -- can be used to bind controls to JavaScript object data \[client-side\] - **XML** -- bind controls to XML data - **Resource** -- designed to provide text in different languages \[client-side\] **Client-side models** -- model data is loaded completely and is loaded on the client. Operations such as sorting and filtering are executed on the client without further server requests. **Server-side model** -- only loads data requested from the model **Data Binding** -- defines how models and view communicate with each other. In the view, you bind UI elements to model data by specifying a **binding path** for a control property. **Binding path** -- consists of a sequence of name tokens separated by a delimiter. The separator is "/". When a binding path is defined for a control, a **binding context** is created that connects the control to the data model. The UI control then retrieves the data through the binding context and displays it on the screen. **Binding Models**: - **One-time** -- the values for the view are read only once from the model - **One-way** -- binding from the model to the view. Each value change in the model updates all corresponding binding in the view - **Two-way** -- binding from the model to the view and from the view to the model. Any change in the model updates, any change in the view updates automatically **Default Binding Modes**: - **JSON** -- two-way - **XML** - two-way - **Resource** -- one-way - **OData V2** -- one-way - **OData V4** -- two-way Implementing Aggregation Binding -------------------------------- ### Binding types: - **Property Binding** -- used to initialize and update properties of a control automatically based on model data - **Element Binding (Context Binding)** -- allows UI elements to be bound to a specific object in the model data, which will create a binding context and allow relative binding within the control and all its children - **Aggregation Binding** -- used to automatically create child controls for an aggregation of a parent control based on model data. To bind an aggregation, create a template or provide a factory function Implementing Element Binding ---------------------------- ### A screenshot of a computer Description automatically generated Using Data Types ---------------- **Formatters** -- employed to format model data for display on the UI **Data Type** -- work both ways, they format the model data for the UI and parse and validate user input ### Simple Types: - **Integer** -- represents integer value. Supports validation: minimum, maximum - **Date** -- represents a date without time. Transforms a given value in the model into a formatted date string and the other way around. Validation: maximum, minimum - **Currency** -- composite type, consists of the parts "amount" (of type number or string) and "currency" (of type string) If you press *Enter* or move the focus to a different UI control, SAPUI5 executes the parse and validation function belonging to the corresponding data type.\ If parse or validation exceptions occur due to incorrect user input, these errors are not automatically displayed on the UI.\ You can use the message manager for reporting these error messages back to the user. To do it, you must register the corresponding UI elements with the message manager. Implementing and Using Formatter Functions ------------------------------------------ Formatter Function has a single parameter, which is the value which needs to be formatted to an external representation. Can be used not only to format a value, but also to do type conversion or calculate results from a given value. Sorting and Filtering --------------------- Sorting and Filtering can be provided for the initial display of data. Filters and sorter properties are specified in the XML view and can be used to pass an array with one or more filter or sorter objects. To **filter** data manually, call the **filter** method on it. The method applies a new set of filters to the data represented by the queried binding. The filters passed are objects of *class sap/ui/model//Filter.* This method: 1. Instantiates a Filter object that filters the model data 2. The created object is added to an array via the push method 3. The table is retrieved via its Id and the binding object for its items aggregation is queried 4. Filter method is called on the binding object and the array with the Filter object passed to it To **sort** data manually, call **sort** method. It sorts the data represented by the queried binding according to the passed **sorter object**. Steps same as sorting. Using Expression Binding ------------------------ **Expression Binding** -- enhancement of the SAPUI5 binding syntax, which allows for providing expressions instead of formatter functions. It is specified in an XML view by one of the following 2 options: - {= expression} -- this variant uses one way binding. This allows the automatic recalculation if the model values change - {:=expression} -- uses one-time binding Adapting Applications to Different Device Types ----------------------------------------------- Controls with built-in device adaptation: - sap.m.SplitApp - sap.m.ResponsivePopover - sap.m.OverflowToolbar - sap.m.PullToRefresh **Device model** -- based on the Device API (sap.ui.Device). This API provides information about device specifics, like the operating system along with its version, the browser and browser version, screen size, current orientation and support for specific features. Working with a Resource Model ============================= With the resource model control properties can be bound to translatable texts. The language-dependent texts are stored in so-called **resource bundle files**. **Resource bundle file** -- Java properties file, that contains key-value pairs, where the values are the language dependent texts, and the keys are used by the application. OData Model =========== **OData Model** -- server-side model. Sorting/Filtering done on the server. The client sends a request to the server and shows the returned data. The requests to the service to fetch data are made automatically, based on the data bindings that are defined for the controls. OData model supports all SAPUI5 binding modes. Currently two-way is only available for properties and not aggregations. An OData V4 model instance can be created in JS using the constructor of the sap.ui.model.odata.v4.ODataModel class. The value for serviceUrl is the root URL of the service to request data from. The path part of the URL must end with a forward slash, according to the OData V4 specification. The parameter synchronizationMode control synchronization between different bindings which refer to the same data for the case data changes in one binding. Alternatively, an OData model can also be instantiated declaratively via the manifest.json application descriptor. OData model settings parameters: - **operation Mode** -- defines the operation mode for filtering and sorting - **earlyRequests** -- Boolean parameter, defines whether the Service Metadata Document, additional annotations files and the security token are requested at the earliest convenience - **autoExapndSelect** -- determines whether the OData model's bindings automatically generate select and expand system query options. ### Binding Types (OData V4): - **List bindings** -- represent a collection of OData entities (such as UX\_Customer) or a collection of complex or primitive types - **Context bindings** -- represent a single entity or a structural property with a complex type - **Property bindings** - represent a single, primitive type property in an entity or in a complex type **Absolute binding** -- their path starts with a forward slash. Creates a data service request to read data once data is requested by a bound control or a child control with a relative binding. **Relative bindings** -- initial, they have no data if they have no context. They obtain a context either from a list binding where the context represents an entity for a certain index in an entity collection, or from a context binding where the context represents the one entity of the context binding OData V4 model also supports **server-side filtering** of lists.\ For example -- a sap.ui.model.Filter object is created that filters the table content with respect to the content of the CustomerName property. Only those customers are display whose name contains the value entered by the user.\ To set the filter object, the list binding object for the items aggregation of the table is retrieved. The filter object is passed to this object via the filter method. Creating New Entities through an OData Model -------------------------------------------- The OData Model sends requests in the following cases: - Implicit read requests to retrieve data for a binding - Implicit update requests via two-way binding - Explicit requests triggered through API calls like refresh, execute For each of these cases, it is possible to specify a Group ID of type string that allows you to group multiple operations into a single HTTP request payload (batch request). Group IDs in SAPUI5: - **\$auto and \$auto.\*** - requests are sent in a batch request, which is triggered automatically before rendering - **\$direct** -- requests are sent directly without batch - **Application Group IDs** -- defined by the developer, sent in a batch request by calling the method \#submitBatch(sGroupID) To specify a Group ID for implicit requests, use the following parameters for the binding which triggers the request: - \$\$groupId -- Group ID for read requests - \$\$updateGroupId -- Group ID for update requests Routing and Navigation ====================== In SAPUI5 navigation and routing is implemented using a router to forward the hash change and the data in the hash to one or more views of the app. Routes are used to notify application that the hash has changed to a certain value. For each route, you define the pattern as hash part of the URL that matches the route. With targets, you define the view or component that is displayed. By referring to one or multiple targets in a route's definition, you can load and show the views or components once the route's pattern matches the current hash. Whenever a hash is added to a URL, the router checks whether there is a route with a matching pattern. In the app descriptor, the configuration is found in the routing property of the sap.ui5 namespace. **Sections:** - **Config** -- contains the global router configuration and default values that apply for all routes and targets - **Route** -- defines a name, a pattern, and optionally one or more targets to which to navigate when the route has been matched - **Target** -- defines the view or component that is displayed. It is associated with one or more routes, or it can be displayed manually from within the app. The router need to be **initialized** by the component. To do this, get a reference to the router in the init method of the Component.js component controller and call the initialize method on it. After initialization, the routing configuration in manifest.json is automatically enabled in the application: the current URL Is evaluated and the corresponding views are automatically displayed **navTo** -- method to navigate to a specific route by setting the browser's hash accordingly To **navigate back** in an app, the user can use the browser's native **Back** button. However, this *Back* button always uses the browser history for navigating back. To change this, a separate **Back** button is implemented for the application. In the implementation of the corresponding onNavBack event handler method, the History module is used to access the navigation history of the SAPUI5 app. The *getPreviousHash* method of the history object is employed to check if there is a previous hash value in the app history.\ If there is no previous hash, the app navigates to the route named *overview* via the router. If a user tries to access an invalid pattern that does not match any of the configured routes, they should be notified that something went wrong.\ To implement this feature, the bypassed property is available in the routing configuration. Using this property, you specify the navigation target that is used whenever no navigation pattern is matched. **Parameter Handling** -- the parameters of a route are set using the navTo method. A configuration object with the parameter values for the route is passed to this method as the second parameter. Implementing Full-screen Application ==================================== Designing a Full-screen Application ----------------------------------- The MVC concept is used in SAPUI5 to separate the representation of information from the user interaction. In general, when you are implementing the information architecture of an application, it consists of more than one page. Apps are composed of several pages. Based on user interaction, the user will navigate from one view to multiple related views. SAPUI5 supports this pattern by providing the control, sap.m.App.\ Types of transition: - Slide (default) - Fade - Flip - Show Recommended application design is to have one XML that only contains the implementation of the sap.m.App control as a root control. The remaining views are used for the pages. The sap.m.App control provides an aggregation called *pages*. The control aggregated by the *pages* aggregation receive navigation events. The starting point of each SAPUI5 app is the **index.html** file. It contains the SAPUI5-bootstrapping implementation. The SAPUI5 bootstrap script in the page initialize SAPUI5 runtime automatically as soon as the script is loaded and executed by the browser. The html-body contains all the necessary implementation details for loading the SAPUI5-component using the namespace. Each application contains a view implementation that contains the *sap.m.App* as the central control. This view is shown right after the application has been loaded on the client. Implementing Router Configuration --------------------------------- The manifest.json file of the SAPUI5 project contains the configuration for the routing. The pattern of a route is basically the hash part of the URL that matches the route. As of SAPUI5 version 1.30, SAP recommends that you define the routing in the *manifest.json* descriptor file using routes and targets. Properties used to control the application flow when the user triggers a navigation action or opens a link to the application directly: - **Config Section** -- contains the global router configuration and default values that apply for all routes and target - **Routes Section** -- contains configuration object for navigation routes. Each route defines a name, a pattern, and one or more targets to navigate to when the route has been hit - **Target Section** -- contains target config. Object for each target. A target defines a view that is displayed. Each route is associated with at least one target. Routing patterns: **URL Pattern** **Example** **Details** ---------------------------- --------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hard Coded Parts "carrier/Settings" Will only match if the hash of the browser is carrier/settings. No arguments will be passed to the events of the Route Mandatory Parameters "carrier/{carrierid}" {carrierid} is a mandatory parameter. For example the following hashes would match: carrier/AA. The matched event of the Route will get AA passed as carrierid in its arguments. The hash carrier/ will not match. Optional Parameters "carrier/{carrierid}/showtab/:tabid:" :tabid: is an optional parameter. The following hashes would match carrier/AA/bookings Mandatory Query Parameters "carrier{?query}" {?query} allows you to pass queries with any parameters. For example, the following hashes would match carrier?first=value1 Optional Query Parameters "carrier/{carrierid}/flights:?query:" :?query: is an optional query parameter. The following hashes would match: carrier/AA/flights?from=New York carrier/AA/flights Implementing Navigation ----------------------- 1. Implement the Carrier View 2. Implement Handler for Press Event in the Carrier View Controller 3. Detect the Carrier in the Flights View Controller Implementing List-Detail Application ==================================== Designing a List-Detail Application ----------------------------------- **List-detail Applications** -- operate with a layout divided into two or three areas: a list area and two detail areas.\ The list area displays the items available to the user.\ The first detail area displays the details of an item selected in the first area. Sometimes contains a list of items. **Sap.f.FlexibleColumnLayout** -- offers different layouts with up to three columns. Users can expand the column they want to focus on, switch between different layouts, and view the rightmost column in full screen mode. **List view** -- when you start the application you see the list page with a list of items. **beginColumnPages** contains the list view. **first detail area** -- displays relevant data for the item selected on the list view. **midColumnPages** contains the details of the first level. **Second detail area** -- displays further information about a selected item in the first detail area. **endColumnPages** contains details of the second level. **When to use List-Detail Pattern?** - You need to review and process different items quick with minimal navigation **When not?** - You need to offer complex filters for the list of items - You need to see different attributes for each item in the list, and compare these values across items - You want to display a single object. Do not use the list to display different facets of the same object Implementing Views and Controller --------------------------------- **App.view.xml** contains the container Control sap.m.App.\ Inside the App-control the sap.f.FlexibleColumnLayout is embedded. The control gets an id and the layout property is bound to a model property with the name layout. The layout property will be used to control how many columns of the sap.f.FlexibleColumnLayout should be displayed during application runtime. **rootViewconfiguration** object (in the manifest.json) -- defines the starting view of the application (should be App view). The rootView points to the view that contains the sap.f.FlexibleColumnLayout control. The pages will be added automatically using rooting configuration or if necessary, by code. ### List View The **DynamicPage** control, representing a web page, consists of a title, header, a content area and an optional floating footer. - **Dynamic Page Title** -- consists of a heading on the left side, content in the middle and actions on the right. Displayed content changes based on the current mode of the DynamicPageHeader - **DynamicPageHeader** -- can contain a single layout control and does not care about the content alignment and responsiveness. The header works in two modes -- expanded and snapped. - **Content Area** -- can have a single UI5 layout control and does not care about the content alignment and responsiveness. - **Footer** -- positioned at the bottom with a small offset and used for additional actions. **When to use DynamicPage control?** - You need to have a title, that is always visible and a header that has configurable Expanding/Snapping functionality. If you don't need this functionality, it's better to use sap.m.Page - You're displaying a sap.m.FlexBox with non-adaptive content - You are using sap.ui.layout.form.Form, sap.m.Panel, sap.m.Table and sap.m.List control is the content of DynamicPage, you need to adjust their left text offset if you want to achieve vertical alignment between the Header content and Page content - The snapping of the DynamicPage Title is not supported in the following case: When the DynamicPage has a scroll bar, the control usually scrolls to the snapping point. The **responsive behavior** of the DynamicPage depends on the behavior of the content that is displayed. ### The Detail View **Sap.uxap.ObjectPageLayout** -- composed of a header, an optional anchor bar and block content wrapped in sections and subsections that structure the information. - **Header** -- implements snapping header concept. This means that the upper part of the header (Header Title) always stays visible, while the lower part (Header Content) can scroll out of view. - **Anchor Bar** -- automatically generated menu that shows the title of the sections and subsections and allows the user to scroll to the respective section and subsection content - **Sections, Subsections, Blocks** -- the content of the page that appears bellow the header is composed of blocks structured into sections and subsections **Use the ObjectPageLayout if:** - The users need to see, edit, or create an item with all its details - Users need to get an overview of an object and interact with different parts of the object Working with Device API ----------------------- The *sap.f.FlexibleColumnLayout* control comes with default responsive behavior but, depending on the device, the controls used inside may behave differently when they are used on a desktop or on a mobile. By introducing a **Device Model,** you can bind control properties to the device's capabilities. To use the device model in a view implementation, bind the attribute of the control to the property of the model. Each view has its own controller implementation. We provide two event handler functions to support the two different scenarios based on the device on which the application is executed on. Implementing View Synchronization --------------------------------- View sync is needed if the user changes the hash in the url. Steps to implement Synchronization functionality: 1. Initial ListSelector implementation 2. Extend ListSelector Implementation 3. Implement Item Selection 4. Create ListSelector in Component.js 5. Assign List Reference to ListSelector 6. Incorporate ListSelector in Element Binding of Detail View Implementing Navigation ----------------------- The basic navigation principals are the same, the difference is that we have to extend it with the sap.f.FlexibleColumnLayout controls. Working with UI5-Controls ========================= **Control** -- UI component that can react to the activities of the user and expose properties, methods, and events to the application using JS API. **UI5 control at design time consist of:** - **Control API** definition -- defines the properties, events, methods and sometimes the associations and aggregations - **Control Renderer** -- responsible for creating the HTML string that defines the structure of the control - **Control Behavior** -- JS code taking care of the control interactivity, reacting to user events, firing control events, handling method calls, and property changes - **Control Style** -- defines the visuals of the control (usually a control that has different visual designs, bundled as "Themes") **Rules for Custom Controls**: - A control consists of the following elements: - Interface - Behavior - Renderer - CSS Theme Data - You can define properties - You can define Aggregations and associations - You can define events - You can define normal methods - You can have a renderer method **Rules for Control Method Implementations:** - After adding the metadata, you add method implementations to the control - Method naming: - Do not use names of method provided in superclass - Private methods are identified by name starting with a underscore, for example, \_checkForZero, all other methods are considered public - Do not use names starting with get, set, etc - Method names with special meanings as follows: - on: used for event handlers - init: used to initialize the control, after its instantation - renderer: used for the function that creates the control's HTML **Control renderer:** - Responsible for creating the HTML structure for the control - Assigned to the render method of the control - Static - RenderManager collects and concatenates string fragments and places them in the DOM at the appropriate position by using its methods - Renderer method has access to control's property getters and setters - It also has access to any aggregations and associations defined by the control Creating Control and Component Libraries ---------------------------------------- **Advantages of control libraries:** - Reuse controls/functionality in different applications - Provide automatic support for theming - Provide automatic support for right-to-left languages - Can be installed on the ABAP-platform - Can be installed in the SAP BTP **Characteristics of controls in a custom library are as follows:** - Multiple controls can be added to a library - The full qualified classname must match the one defined in the library.js - Standard JS can be used - Define as JS module with name, dependencies and factory function At the end, you must implement the controls that are going to be encapsulated in the UI library. When you are finished with the development, you have to deploy the UI library project to your on-premise or cloud system. After deployment, the UI library shows up in transaction SICF. A dependency is defined in the *manifest.json* file of the application that uses the UI library. The dependency triggers the get response of the *library.js* file from the dependent UI library. Ensuring Software Quality in UI5 ================================ Performing Unit Tests with Qunit -------------------------------- **Unit test (Component test)** -- check whether the components written by the developers work as they intend. **QUnit** -- JS unit and integration test framework. It can test any generic JS code. It supports async tests out-of-the-box. It can be found at the following: QUnit uses a set of top-level functions to provide sematic meaning in unit tests. It follows an arrange-act-assert pattern, a common test pattern emplouyed during unit testing. **Constructs:** 1. **Module (String)** -- defines a module 2. **Test (String, Function)** -- defines a test 3. **Ok (Boolean, string)** -- validates to true or false 4. **Equal (value1, value2, message)** -- compares two values, using the double-equal comparator 5. **DeepEqual** **(value1, value2, message)** -- compares two values based on their content, not just their identity 6. **StrictEqual (value1, value2, message)** -- strictly compares two values, using the triple-equal comparator Structure and details of the Test relevant aspects of a UI5 Project: - Test folder - Arrangements for the tests like startup methods - Pages -- contains the page objects which represents the UI under test. Contains locators, actions and assertions - AllJourneys.js -- test suites are collected here - unitTests file -- sets up the SAPUI5 environment and triggers the AllTests file to start the tests When you are using the SAPUI5 project template, which is provided by SAP Business Application Studio, all relevant aspects are generated to start the application under test mode using the unitTests.qunit.html file located in the unit-subfolder. To launch the application under the test start, Preview Application, from the menu in the project explorer of SAP Business Application Studio, or to open the file package.json located in the project, hover over the unit-tests-script and choose start script. When the unit test is fully complete, a results screen is displayed. Performing Integration Tests with One-Page Acceptance (OPA5) Tests ------------------------------------------------------------------ **OPA5** -- JS based test framework for SAPUI5 that allows the development of: 1. User Interaction Tests 2. SAPUI5 Integration Tests 3. Navigation Tests 4. Data Binding OPA5 is fully supported for execution on any mobile device. The dev writes tests during development. Test Driven Development (TDD) results in less fragile code. **Advantages of OPA5:** - Quick and easy access to JS functions - Easy ramp-up (can be used with any JS unit test framework) - Enables debugging - Good SAPUI5 integration - Fast turnaround - Direct tests execution - Asynchronicity is handled with polling - Enables TDD **OPA Limitations:** - Screen Capturing - Testing more than one page - Remote execution - Authentication/Fragility (end-to-end tests not recommended) The file **opaTests.qunit.html** -- contains bootstrapping code for the execution of OPA-tests. The bootstrapping file is generated by the SAP BAS during project generation. Each test case scenario is implemented in a different JavaScript file. OPA gives following three objects: - Given = arrangements - When = actions - Then = assertions Advanced Data Handling ====================== **Smart Controls** -- specific category of SAPUI5 controls that have some special features in addition to standard and thus make it easier to use the control in certain scenarios. The namespace *sap.ui.comp* contains the following control types: - SmartField - SmartTable and SmartList - SmartFilterBar - SmartChart and SmartMicrochart - SmartVariants - SmartGroup SmartForm -- displays form content and can be used in combination with SmartField control and OData metadata annotations along with additional configuration. The control allows you to create a form with minimal effort. Depending on their user authorization the form enables users to: - Switch from display to edit mode - Add and group fields - Rename field labels - Implement a user input check Version Control -- Working in Teams =================================== ![A diagram of a working directory Description automatically generated](media/image2.png) Staging Area -- lets you group related changes into highly focus snapshots before committing the snapshots. Staging commands shown on screen iclued single file addition, single directory addition and addition of specific parts of a file with changes. Commit -- commits the staged snapshots to the project history. Snapshots are committed to the local git repository. Check out -- checking out files, checking out branches, checking out commits. GIT Branches: - Serves as an abstraction for the staging and commit process - Works with an independent working directory and staging area - Is a reference to a commit Usage of branch command: - Git branch -- list all branches - Git branch \ - crate a new branch - Git branch -d \ - delete a branch Git Checkout -- allows switching between different branches - Git checkout \ - switch to a branch - **Git checkout -b \** - create and checkout a new branch - **Git checkout -b \ \** - create and check out a branch from an existing branch Git merge -- allows the integration of one branch into another - **Git merge \** - merge a branch into the current branch Applying the Golden Rules of SAPUI5 Development =============================================== +-----------------------------------+-----------------------------------+ | How to Design and Build SAP Fiori | - SAP Fiori apps must have an | | App? | approved UX design | | | | | | - SAP Fiori UIs are built with | | | SAPUI5 | +===================================+===================================+ | How to Use OData services in SAP | - SAP Fiori apps are based on | | Fiori? | OData services | | | | | | - SAP Fiori UIs and OData | | | Services must be defined in | | | different software components | | | | | | - One SAP Fiori app - One OData | | | service | +-----------------------------------+-----------------------------------+ | Why Use Declarative Design for | Every SAP Fiori app is defined | | SAP Fiori Apps? | by a set of metadata | +-----------------------------------+-----------------------------------+ | Why Use UI Theme Designer to | No custom CSS is allowed | | Apply Corporate Design? | for SAP Fiori apps | +-----------------------------------+-----------------------------------+ | How to Make SAP Fiori Apps | - Every SAP Fiori app must run | | Platform Independent? | as a web app and must run in | | | the SAP Fiori Launchpad | | | | | | - Every SAP Fiori app must run | | | on mobile devices in the | | | native app paradigm | +-----------------------------------+-----------------------------------+ SAP Fiori Launchpad =================== The **SAP Fiori Launchpad** page is the first page that users see after they have logged in. The launchpad home page presents tiles that allow the launch of apps and may show additional information The home page is provided by the SAP Fiori launchpad. Apps use this home page and do not design their own. **Apps can use the following services offered by the SAP Fiori launchpad:** - Settings (apps only): Each app can provide app-specific settings to the launchpad. - User Preferences: This service provides details about the user currently logged in to the app. In addition, it offers theme selection. - Contact Support: You can offer a Contact Support option as a channel for user incidents. Note, that this option is only available if the customer configures the support setup. - Give Feedback: This service allows users to give feedback on the app. Note, that this option is only available if the customer configures the feedback setup. - About (apps only): This option is automatically available for all apps. It provides technical details about the app. **Apps can use the following services offered by the SAP Fiori launchpad:** - Log In / SSO / Log Out: All aspects of logging in and out are handled by the launchpad. If single-sign-on (SSO) is used, no user password is required. If SSO is not used, the launchpad provides a login screen. - Save as Tile: This service allows users to save a snapshot of the app as a tile on the launchpad. The tile bookmarks the current state of the app. - Navigation: SAP Fiori Launchpad handles all navigation between apps. SAP Fiori 3.0 key capabilities: - New delightful visual theme: SAP Quartz - SAP Fiori 3 Launchpad does not use viewports anymore - Notifications - Merged header - New SAP Fiori elements The launchpad now offers contextual help. User assistance is part of the attractive, simple and enjoyable UX. - Instant: exactly when the user needs it - Context-sensitive: exactly what is needed - Seamless: within the target application - Productivity: interactive user guidance **Tile** -- container that represents an app on the SAP Fiori launchpad home page. All apps have at least one tile, except for fact sheets. There is a variety of types of tiles: - KPI Tile - Comparison Chart Tile - Mini-Charts like Bullet Chart, Trend Chart, Column Chart - Basic Launch Tile - Monitoring Tile - SAP Jam Tile - Feed Tile A tile consists of: - Header Area (Mandatory) - Subtitle - Content Area (Mandatory) - Status Area Tile catalog -- tiles are grouped into it. Functions: - Tiles that are used most often can be added to the *Home* page. - Tiles, that are used more seldom, can be accessed directly from the catalog, without adding them to the *Home* page. The figure gives an optical illustration of the steps described below. ( a ) FioriLaunchpad.html: FioriLaunchpad.html is at the center of the SAP Fiori Launchpad architecture and act as the central point of entry to the SAP Fiori Apps. ( b ) Runtime Configuration - The Launchpad gets the RuntimeConfiguration from the SAP-system, containing the configuration provided by the SAP-system. ( c ) Shell Container - The so-called Shell Container is responsible for providing all relevant services like personalization or navigation to applications that are executed inside the SAP Fiori Launchpad. ( d ) Application Container - SAP Fiori applications are executed inside the so-called application container. ( e ) Shell Services - Each application can access the platform-independent shell service through the API of the shell container. Services that need platform-specific data handling or connection management use platform-specific adapters. SAP Fiori Launchpad Configuration --------------------------------- Each user of the SAP Fiori Launchpad is assigned to various Business Roles, based on the assignment the user sees Tiles or Links in the SAP Fiori Launchpad. The following figure gives you an overview of the different objects and how they are related. **Configurations steps:** 1. Create Semantic Object /UI2/SEMOBJ 2. Create Catalog 3. Copy/Create Tiles/TargetMappings a. Optional: Create Group assign Tiles 4. Create PFCG Role 5. Assign Catalog/Group to Role 6. Assign User to Role The SAP Fiori 3 spaces concept gives your users stable, well-structured, and personalizable access to their important apps. A space represents an area of work, typically corresponding to one or more business roles. You can structure each space using one or more pages for various work contexts, and optionally use sections to further group the work within a page. A tile in the SAP Fiori launchpad doesn\'t point directly to an SAP Fiori app A tile points to a target mapping in conjunction with a semantic object and an action. With this so called intent the SAP Fiori Launchpad can resolve the navigation target. The navigation concept is called intent-based navigation. To start a configuration in SAP Fiori Launchpad Designer you need to create a transport request and assign it to a system (SE01) - Customizing (CUST) This layer can be used for testing or other purposes. - Workbench (CONF) All content that you want to deliver to customers must be created in the CONF layer. Semantic objects can be created using the transaction /ui2/semobj. The **CrossApplicationNavigation** service is used to navigate from one SAP Fiori application to another. Applying SAP Fiori Design Guidelines ==================================== The SAP Fiori Design Guidelines knows two main layouts and three layout variants. Main layouts are: - Dynamic Page - Flexible Column Layouts Layout variants are: - Comparison Pattern - Multi Instance - Semantic Page **Dynamic Page Layout** (successor to the Fullscreen Layout) provides the following features: - Fully responsive - Page header functionality - Allowed floorplans: - Analytical List Page - List Report - Overview Pager - Wizard - Worklist - Initial Page - Object Page The dynamic page itself is a skeleton structure, filled by content elements. They can be built in the following 3 ways: - Automatically - Semantic Pages - Manually Areas of the Dynamic Page Layout: 1. Header (expandable/collapsible) a. Title (optional subtitle/summary) b. Key Information c. Global actions 2. Content d. Footer toolbar e. Finalizing actions **When to use dynamic pl?** Use the dynamic page layout if you are building a freestyle application that uses the dynamic page header and footer toolbar features of SAP Fiori (versions 1.40 and higher) **When not to use?** Do not use the dynamic page layout if you are planning any of the following scenarios: - Use SAP Fiori elements, such as the list report, analytical list page, overview page, or object page. These elements already incorporate the dynamic page layout. - Implement an initial page or object page floorplan. These floorplans already incorporate snapping header and footer toolbar features. The behavior is similar to the dynamic page, but the technical foundation is different. - Display a small amount of information. In this case, use a dialog instead. If you cannot avoid using the dynamic page layout, use letterboxing to mitigate the issue. **The flexible Column Layout** -- displays multiple floorplans on a single page and displays up to 3 columns. **When to use flexible column layout?** Use the flexible-column layout if you want to create a master-detail or master-detail-detail scenario in which the user can drill down or navigate. **When not to use?** - You want to build a workbench or tools layout. - You want to create a dashboard with context-independent pages. - You want to open multiple instances of the same object type. Use the multi-instance-handling floorplan instead. - You want to split a single object into multiple columns, or display only a small amount of information. - You want to embed the SAP Fiori launchpad or overview page into one of the columns. SAPUI5 Flexibility ================== **SAPUI5 Flexibility** -- enables functions for different user groups to adapt SAPUI5 applications in a simple and modification-free way. Available on ABAP platform, SAP Cloud services in the Cloud Foundry environment. Replaces the extensibility concept by broadening the adaptability of SAPUI5 application and simultaneous increase of maintainability and simplicity. - Lifecycle-stable and modification-free - Cost-efficient - Intuitive tooling Personas: - End user - Personalizes Settings for Views - (Make changes to the running app in the browser) - Key User - Creates and Manages Variants - Manages View Settings - (Make changes to the running app in the browser) - Developer - Manages View Settings - Adapts and Extends Standard Apps - Creates and Manages variants of their own apps - (Make changes in the SAP BAS) The flexibility of SAPUI5 is based on three pillars: - Ensures lifecycle-stable and modification-free UI changes based on deltas. - Facilitates cost-efficient UI change process for extending apps. - Provides intuitive tooling tailored to the needs of special target groups. **The SAPUI5 Adaptation Project** allows developers to extend SAP Fiori applications in SAP BAS. It lets you create an app variant for an existing SAP Fiori elements-based application on S4 Hana on premise ABAP system and provides extension capabilities for UI5 controls. Using SAPUI5 Adaptation Project you can make an app variant that includes the changes that you make to the source application and to the variant itself. Extensions are made via SAPUI5 flexibility possibilities and do not modificate the source. This modification-free approach allows to reference the source app and its artifacts. Adaptation project behaves like this: 1. Start as a preview 2. Adapt using SAPUI5 adaptation project 3. Deploy from SAP BAS ![The figure illustrates the description, given in the following context.](media/image4.png) On the level of view controllers developer an extend existing controller implementations modification free. Also possible is to replace the complete implementation of an controller or just some functions. This is called Controller Extension or Controller Replacement. It is very important to know that not every control of an application can be modified, only controls with a stable Id can be addressed by the flexibility tools to change the behavior of the control. - Stable IDs are used to identify UI-controls during processing. - Use of stable Ids: - At the id property on each level of UI-controls. This means also layout controls should have an stable id. - At the viewId property in the routing configuration on the level of target-configuration for routing. - Use semantic names for your IDs to make it easier to identify them later. Steps to **Implementing View Extension, Modification, and Replacement** 1. Enable App Extension 2. Setup manifest.json file 3. Add extension points 4. Configure metadata 5. Create adaptation project READ EXTRA ON THIS

SAP Fiori Elements Overview PDF

Document Details

Tags

Related

Summary

Full Transcript