第 77 页 / 共 465 页
2.4 Prototyping Tools
Shell Bar
Header Title Bar
Tab Bar
Page Content
Footer Toolbar
Figure 2.22 Structure of a Worklist Page
The worklist page is the right fit only for some specific scenarios:
(cid:2) If the user needs to go through multiple work items and decide which one needs to
be processed first based on importance or relevance
(cid:2) If the user needs direct access to a work item for taking the required action
(cid:2) If the same content needs to be displayed (with the help of tab bars) in multiple
tabs based on status, for example, work items that are Open, In Process, Com-
pleted, and so on
Worklist pages may not be the right fit for all app scenarios, such as the following:
(cid:2) If the items in the list aren’t work items
(cid:2) If the user needs to work with a large list of items and it’s represented by tables or
charts
(cid:2) If the user needs to work with a large list of items by filtering, sorting, or searching
through the results
2.4 Prototyping Tools
When it comes to prototyping, there are multiple methods developers can build on,
including designs drawn on paper (low-fidelity designs), Microsoft Excel sheet-based
layouts, or interactive prototypes generated using wireframing tools (high-fidelity
77
第 78 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
designs). To help developers reduce their initial efforts to create a high-quality proto-
type, SAP has provided a set of prototyping tools.
Prototyping tools are a great way of coming up with mock-up designs of your apps.
Some of the most commonly used prototyping tools are Axure and SAP Build. These
tools not only provide a static mock-up design but also gives you an option to make
those designs somewhat interactive so that they can mimic page navigations, button
clicks, mock data, and so on.
2.4.1 Axure
Axure is a third-party wireframing/prototyping tool that SAP supports (download a
30-day trial version of Axure from www.axure.com/download). SAP provides a down-
loadable add-on stencils kit that can be imported into Axure to enable support for
SAP Fiori prototyping and to help you visualize SAP Fiori app ideas within Axure
(https://experience.sap.com/fiori-design-web/wp-content/uploads/sites/5/2017/09/
Design-Stencils-Version-1.50_External.zip). This downloadable package also contains
a set of SAPUI5 icon fonts.
If you don’t want to use any of the prototyping tools, then another solution is the
design stencils for Microsoft PowerPoint (https://experience.sap.com/fiori-design-
web/wp-content/uploads/sites/5/2017/09/PPT_Stencils_external_1.50.zip). However,
this option is limited because it lacks the option to make the mock-ups interactive
and other rich features that a dedicated prototyping tool such as Axure or SAP Build
can provide.
2.4.2 SAP Build
Compared to Axure, SAP Build is a dedicated prototyping tool for SAP Fiori apps. In
addition, unlike Axure, SAP Build offers a set of prebuilt mock-ups, including mock
data for multiple app scenarios. You can start with one of these prebuilt templates
that most closely matches your app and then adapt the mock-up accordingly, or you
can start a new template from scratch. You can use the SAP Build tool free of charge
by going to www.build.me.
A gallery of prebuilt SAP Fiori app prototypes (Figure 2.23), strictly based on the SAP
design guidelines, will help you understand how a typical SAP Fiori app is designed,
and you can even adapt those mock-ups to fit your design if you don’t want to start
designing a mock-up from scratch.
78
第 79 页 / 共 465 页
2.4 Prototyping Tools
Figure 2.23 Prototype Gallery for SAP Build Tool
In addition to building a mock-up, if you want to add team members to your new SAP
Build project, you can invite them to collaborate with you on the project.
After you’re done with the mock-ups, you might want to share this mock-up with
your customer or other team members for their feedback. SAP Build allows you to
generate a sharable URL instantly, so you can send your team members a working
interactive prototype, instead of screenshots of the mock-ups or a ZIP file, enabling
them to get an idea of how the final app will look.
As we explained earlier in this chapter, SAP Fiori UX is all about design-led develop-
ment or “humanizing our apps.” SAP Build tools have an interactive learning cards
section, which spans across the Discover, Design, and Develop design principles of
the SAP Fiori design guidelines. Clicking on one of the nodes (as shown in Figure 2.24)
within each of these design principles brings up a learning card explaining each
phase.
79
第 80 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Figure 2.24 Design-Led Development Learning Cards in the SAP Build Tool
2.4.3 Building a Prototype Using the SAP Build Tool
Our aim is to build a simple app for managing purchasing documents for a user
whose primary role is to manage the department expenditure. The user needs to
keep track of all the purchase documents made by his department, needs to view
detailed information of the purchasing documents, and needs the option to approve
or reject purchasing documents if necessary.
Let’s follow the design-led development process as you would in an actual project.
With the help of the SAP Build tool, we’ll make this prototype and use it to build the
actual app in the upcoming chapters. The following subsections describe the differ-
ent phases of the design-led development process.
Discover Phase
In this phase, we’ll identify the following: the app’s scope, for whom the app is
required, the challenges, and the possible bottlenecks. In addition, we’ll talk to end
users to create a persona for the app based on their needs. To simplify these tasks,
we’ll subdivide them into the following parts.
Scope
During this phase, it’s essential to communicate with your customer and understand
what the project is about. You’ll need to document things so that you’ll have a clear
picture of what needs to be done so you can explain it to your team. SAP Build pro-
vides multiple templates to help you with the tasks defined in the different phases of
design-led development.
80
第 81 页 / 共 465 页
2.4 Prototyping Tools
Note
Go to the following link for a sample template you can use to document the project
scope:
https://standard.build.me/splash/sites/default/files/ProjectScope_example_
template.pptx
Such a document will help you communicate with your team about what needs to be
delivered. You’ll also be able to see the overall goal of the project, key deliverables,
stakeholders, timeline, milestones, and so on. You can refer to Table 2.1, which con-
tains the project scope details of our sample application for managing purchasing
documents.
Project Scope Details: Manage Purchasing Documents
Overall goal To keep track of the expenses within the company, managers need
an app with a UI that would help them identify high value pur-
chases, to monitor and approve or reject them accordingly. We'll
build an app to manage purchasing documents.
Project scope To deliver a solution that manages purchases within the organiza-
tion, that can flag orders that are above the threshold limit, show
the status of the orders, including a detailed view of purchasing
documents with items and options to approve or reject the orders.
Project stakeholders (cid:2) Sponsor: James Paul, Andre Green
(cid:2) Stakeholders: Evelin Smith, Julia Thomas
Project organization (cid:2) Lead: Sebastian Joseph
(cid:2) Contributors: Richard Williams, Sam Andreas
Project deliverables (cid:2) Personas, point of view (POV) statements
(cid:2) Storyboard
(cid:2) Prototype
(cid:2) Working software
Milestones (cid:2) First draft review with Andre - 3/27/2019
(cid:2) Executive review (Paul, Andre, Evelin) - 4/1/2019
(cid:2) Final draft - 4/5/2019
(cid:2) Prototype - 5/5/2019
(cid:2) Final product - 7/2/2019
Table 2.1 Project Scope Details
81
| Note Go to the following link for a sample template you can use to document the project scope: https://standard.build.me/splash/sites/default/files/ProjectScope_example_ |
| template.pptx |
| Project Scope Details: Manage Purchasing Documents | |
|---|---|
| Overall goal | To keep track of the expenses within the company, managers need an app with a UI that would help them identify high value pur- chases, to monitor and approve or reject them accordingly. We'll build an app to manage purchasing documents. |
| Project scope | To deliver a solution that manages purchases within the organiza- tion, that can flag orders that are above the threshold limit, show the status of the orders, including a detailed view of purchasing documents with items and options to approve or reject the orders. |
| Project stakeholders | (cid:2) Sponsor: James Paul, Andre Green (cid:2) Stakeholders: Evelin Smith, Julia Thomas |
| Project organization | (cid:2) Lead: Sebastian Joseph (cid:2) Contributors: Richard Williams, Sam Andreas |
| Project deliverables | (cid:2) Personas, point of view (POV) statements (cid:2) Storyboard (cid:2) Prototype (cid:2) Working software |
| Milestones | (cid:2) First draft review with Andre - 3/27/2019 (cid:2) Executive review (Paul, Andre, Evelin) - 4/1/2019 (cid:2) Final draft - 4/5/2019 (cid:2) Prototype - 5/5/2019 (cid:2) Final product - 7/2/2019 |
第 82 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Research
This phase is all about gathering as much information as you can about your users to
help you make meaningful decisions during project development. The best way to
gather such information is in the form of asking your customers a set of questions
like an interview. SAP Build also has a reference template to help you with coming up
with a set of questions to gather that information.
Note
Go to the following link to get an interview script template from SAP Build:
https://standard.build.me/splash/sites/default/files/Interview_script_example_
template.docx
Synthesize
After the information gathering is done, it’s time you sit down with your team along
with the people who did the interview. Now, you can discuss the essential points
from the information you’ve collected so far by writing all the essential points on a
board so that you can discuss among other team members to decide which informa-
tion is relevant and thereby further tweak the information. Highlight the problems/
pain points of your app and discuss how to tackle those within your app.
With an idea of who exactly your customer is based on the information at hand, it’s
time to build a persona of the potential users of the app. For creating personas, you
have two options within the SAP Build tool: either use the template (available at
https://standard.build.me/splash/sites/default/files/Persona_example_template_
0.pptx) or use the wizard/online form in the SAP Build tool.
To build a persona (as shown in Figure 2.25), you should list some key information
about the user, such as an introduction about the user obtained from the interview
phase, with whom the client mainly works, main goals for the user, what the user
wants, job responsibilities, pain points mentioned by the user, and so on.
After you have created a persona, you can use it to make simple point of view (POV)
documents for each requirement of the user (template available at https://stan-
dard.build.me/splash/sites/default/files/PoV_example_template.pptx). This will help
you focus separately on each main need instead of trying to tackle all the require-
ment at once. This document will help you and your team focus on that specific prob-
lem and try to resolve the problems one by one. A typical POV should be very
minimal and focused on one requirement.
82
| Note Go to the following link to get an interview script template from SAP Build: https://standard.build.me/splash/sites/default/files/Interview_script_example_ |
| template.docx |
第 83 页 / 共 465 页
2.4 Prototyping Tools
Figure 2.25 Persona Creation Wizard Using SAP Build
Design Phase
Now that you have an idea about the app, possible problems, and all the required
information on the type of users of the app, you need to come up with solutions, then
build a prototype, test the prototype, share the prototype end users, collect feedback,
and tweak the designs based on that feedback to come up with a final prototype.
83
第 84 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Ideate
In this phase, you try to understand how your users will use the existing system to
complete their tasks and determine at which point they run into issues/problems
with their current system and what alternatives they can take to overcome the prob-
lems. For this, you might want to clearly record all the steps performed by the user to
re-create these on your end. Creating some flow diagrams will help you visualize
these steps more accurately. Try to build separate use cases for the goals from the
POVs (use the template at https://standard.build.me/splash/sites/default/files/Use-
CaseDiagram_template.xlsx).
With use cases in hand, now it’s time to do some brainstorming with your team.
Think about how you’ll resolve a specific issue if it was you. This session will help you
come up with possible solutions and design concepts for the app.
After the brainstorming session, you can try to come up with a storyboard to provide
a pictorial representation of how the user will perform his task with the help of your
new solution (download a storyboard template at https://standard.build.me/splash/
sites/default/files/Storyboard_HowTo.pdf). This approach will basically give the team
a high-level understanding on how the app will help the user in overcoming their cur-
rent problems.
Figure 2.26 Example Storyboard
84
第 85 页 / 共 465 页
2.4 Prototyping Tools
In Figure 2.26, you can see a sample storyboard from SAP Build that will give you an
idea of how to come up with a visualization of your prototype that helps your cus-
tomer complete his task. You can create story boards based on the free available list
of scenes here: https://experience.sap.com/designservices/approach/scenes.
Prototype
Now it’s time to make the prototype. Sketch your design at least once on paper to get
a feel for the app; such sketches are called low-fidelity designs. Now let’s decide which
type of layout to make for the example Manager Purchasing Documents app. We
need a list of all the purchasing documents on the same screen. A worklist page won’t
fit this requirement because the purpose of the worklist app is to list only the action
items for a user. According to the personas, POVs, and use cases, the user needs more
than just a list of actionable items. He needs to filter out, drill down, and act on cer-
tain items if needed. So, the obvious choice is a combination of a list report page for
the purchasing documents and an object page to show items in detail.
Note
To make sketches for your prototype, you can download a template containing the
different wireframe layouts for a desktop, tablet, and a mobile device from the fol-
lowing link:
https://standard.build.me/splash/sites/default/files/Handsketch_template.pdf
For this example, the sketch for the list report page is shown in Figure 2.27 for the first
screen of the prototype. You can see that there is a list of purchasing documents in
the table, filter options, and action buttons for approve/reject. Furthermore, the table
is designed to select multiple rows so that the user can perform mass approvals/
rejections on the items.
Now that the first page sketch is done, let’s focus on the object page for the second
screen. As show in Figure 2.28, this page lists all the items related to that purchasing
document, so the user can see the cost breakdown of the item. This additional infor-
mation will further help the user decide whether the purchase needs to be approved
or not. The same approve/reject option is also provided here in the object page so
that the user doesn’t need to go back to the first screen to approve/reject the item.
85
| Note To make sketches for your prototype, you can download a template containing the different wireframe layouts for a desktop, tablet, and a mobile device from the fol- lowing link: |
| https://standard.build.me/splash/sites/default/files/Handsketch_template.pdf |
第 86 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Figure 2.27 List Report Page Sketch on Paper
Figure 2.28 Object Page Sketch on Paper
86
第 87 页 / 共 465 页
2.4 Prototyping Tools
Okay, now we have the rough sketch of the prototype. But these sketches aren’t that
professional looking if you want to share it with your customers to collect their feed-
back and they aren’t interactive either. If you can give your customer an interactive
prototype design, their feedback will also help you further tweak the UX because the
users are getting a feel about the final product that you’re trying to deliver.
To make a design closer to the final product and make it interactive, SAP Build has a
set of templates to start with. You can also start a new project from scratch, but
because our designs are based on a list report page and an object page, we can start
with a template.
In the SAP Build tool, click on New Project (cid:2) Create New Project. Here you’ll also get
the option to upload the existing persona document you created from the template,
or you can click on the Create a Persona button to use the wizard. Then you can click
the Start with Template option (Figure 2.29).
Figure 2.29 SAP Build Create Project from Template
From the list of templates, select List Report. Click on the Edit Page option to see a
basic design of the list report (Figure 2.30). You can now modify the list report by add-
ing the required filters, action buttons, and sample data for the table.
87
第 88 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Figure 2.30 List Report Page Template
After all the UI elements are added to the template, the design should look like our
sketch but closer to the real app (Figure 2.31). You can also create the required mock
data for the table via the data editor feature of SAP Build. The layout editor also has
useful features such as the option to view the mock-ups on different device layouts
(e.g., desktop, tablet, and phone). It also provides the option to switch themes.
Figure 2.31 Completed Prototype of the List Report Page
Now you need to build the object page for the details screen. For this, you don’t need
to create another project; instead, you can add another page to the current project by
clicking on the + icon next to the Outline option in the current project window (see
Figure 2.32) and selecting Object Page.
88
第 89 页 / 共 465 页
2.4 Prototyping Tools
Figure 2.32 Adding an Object Page Template to the Project
Now you can start modifying the object page based on the sketch. As you can see in
Figure 2.33, the object page design is complete with the additional item details of the
purchasing document. You can also add navigation actions to the table list in the list
page to enable navigation to the object page.
Figure 2.33 Object Page Prototype
Now you can preview the prototype by clicking on the Eye icon on the top-right cor-
ner of the UI editor (Figure 2.34).
89
第 90 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Figure 2.34 Previewing the Prototype
When you’re happy with the preview, you can generate a sharable link to send it to
your customer. Click on the SHARE button on the top-right toolbar of the UI editor,
and you’ll get a popup with the URL link. Additionally, you can also download a ZIP
file of the prototype that can be imported into your Web IDE so that you’ll be getting
the basic codes required for the actual app, which will already be generated for you
(Figure 2.35).
Figure 2.35 Generating a Sharable URL for the Prototype
Validate
After you’re done with prototyping, you can share the prototype with your customer
and wait for feedback to rectify any issues. This will make sure that the client is okay
90
第 91 页 / 共 465 页
2.4 Prototyping Tools
with the prototype before you enter the development phase. To collect the feedback,
you can either use the template (download at https://standard.build.me/splash/sites/
default/files/Test_script_example_template.docx) and test the script link, or you can
use the feedback tool within the layout editor of the app to generate a sharable inter-
active feedback URL that you can share with your customer.
To create feedback, in the UI editor window, click on the Create Study button on the
top-right side of the toolbar. In the popover screen, give a name and description for
the study. Now click on the Create and Go to Feedback button. As shown in Figure
2.36, you can add your own set of questions to ask the client about the app.
Figure 2.36 Feedback
Now let’s add a few questions. Click on the NEW QUESTION button (Figure 2.36), and
select the prototype from the Prototypes tab. Here (Figure 2.37) you’ll have multiple
methods to create questions: you can ask the customer to complete a certain action,
ask the customer for his opinion about a specific feature, give the customer multiple-
choice options to select from, and give the customer the option to add comments
anywhere on the screen.
91
第 92 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
Figure 2.37 Prepare Questions for Feedback
After all the questions have been added, click on the Publish button to generate a link
for the feedback. You can send this link to your customer along with the prototype.
After the customer has tested the prototype and completes the feedback, you have
the option to analyze the results from the feedback. In the Questions tab of your feed-
back (Figure 2.38), you can see statistics such as the number of participants, how
much time they spent on each question, whether the customer was able to complete
an action specified in a question, and so on.
In addition, you can go through each question in the feedback and check which con-
trols or area of a page of the prototype the customer was most interested in. This can
be done by selecting the Heatmap checkbox in the questions window. In Figure 2.39,
you can see the areas with which the customer has interacted the most. This is a very
powerful feature because you’ll be able to see how the customer uses the app, which
might be completely different from how you might have used the app. Such insights
will help you further tweak your prototype.
92
第 93 页 / 共 465 页
2.4 Prototyping Tools
Figure 2.38 Analysis of Feedback from Customers
Figure 2.39 Heatmap Option in the Feedback Tool
93
第 94 页 / 共 465 页
2 SAP Fiori and the Design-Led Development Process
2.5 Summary
SAP Fiori is the new UX for SAP software, so it’s important for developers to under-
stand its design principles and guidelines to develop new apps. Following these
design guidelines are important because it will ensure that your apps look and feel
just as good as the standard suite of apps SAP Fiori offers. SAP Fiori works seamlessly
across desktops, tablets, and mobile devices to enable users to work on the go.
In this chapter, we laid out the basic design principles of SAP Fiori apps, discussed
responsive and adaptive designs, and explained SAP Fiori launchpad and its compo-
nents.
Then we looked into the design-led development process and its different phases
that are crucial for a SAP Fiori project. We considered different app types offered by
SAP Fiori to help developers with app development.
Finally, we discussed the different prototyping tools that will help you create beauti-
ful design sketches and interactive prototypes for your final product.
In the next chapter, you’ll learn about the ABAP programming model for SAP Fiori
and its associated technologies.
94
第 95 页 / 共 465 页
Chapter 3
ABAP Programing Model for SAP Fiori
This chapter introduces the ABAP programing model for SAP Fiori,
which has been available since SAP S/4HANA 1610, SPS 03, or SAP
NetWeaver Application Server for ABAP 7.52, SP 02. It’s the standard
development model for new SAP S/4HANA applications and reflects
the SAP S/4HANA core architecture described in Chapter 1.
In general, the model supports the development of SAP HANA optimized OData ser-
vices for SAP Fiori applications based on Core Data Services (CDS) views and covers
analytical, transactional, and search application scenarios. Two main scenarios can
be distinguished when developing applications using the programing model: read-
only applications and transactional applications. Read-only applications only require
an underlying CDS data model and application-specific analytics or search annota-
tions. The CDS data model and its annotations are then exposed as an OData service
using the Service Adaptation Description Language (SADL) technology.
Transactional applications, in addition to read-only applications, require the genera-
tion of a Business Object Processing Framework (BOPF) business object for handling
create, update, and delete operations as well as additional business logic imple-
mented via BOPF actions, validations, and determinations. In the following, we’ll go
through the different technologies associated with the ABAP programing model.
3.1 Core Data Services
Core Data Services (CDS) are the foundation of all SAP S/4HANA application types.
They are deployed on top of legacy or new SAP ERP tables and enable the develop-
ment of semantically rich data models that foster code pushdown to the SAP HANA
database. They are developed on the ABAP stack and therefore use the standard life-
cycle management of ABAP development objects; for instance, they are transported
between systems using the standard ABAP Change and Transport System (CTS).
95
第 96 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
On activation of a CDS view, two artifacts are generated: a corresponding Data Dictio-
nary (DDIC) view in the ABAP Dictionary (@AbapCatalog.sqlViewName) and a SAP HANA
view on the database. Only the CDS view definition is transported and has the object
repository entry R3TR DDLS <CDS_DEFINITION_VIEW_NAME>.
To cover different application scenarios, CDS views, which are defined using the data
definition language (DDL) of CDS, can be enhanced using different types of annota-
tions.
(cid:2) Analytical annotations
To use a CDS view as a data cube or query within analytical application scenarios
via the Analytical Engine, it must be annotated using @Analytics annotations.
(cid:2) UI annotations
CDS views can be annotated with user interface (UI) annotations (@UI) to define
where certain entities, fields, and data will be placed within a SAP Fiori elements
template application, which reduces the required JavaScript SAPUI5 frontend code
drastically. UI annotations can be moved to a metadata extension file with object
repository type R3TR DDLX in order not to clutter the core CDS view with loads of UI
annotations.
(cid:2) Search annotations
CDS views can be configured for search scenarios using @Search annotations, for
instance, as an Enterprise Search (ESH) model for the SAP Fiori launchpad search
or for SAP Fiori in-app search by defining the SAP HANA text search scope and
fuzziness.
(cid:2) Transactional annotations
To enable transactional processing capabilities (create, write, delete) in addition to
analytical or search capabilities, a BOPF object can be generated for a CDS entity by
providing transactional @ObjectModel annotations.
Figure 3.1 shows an overview of the ABAP programming model development flow
and involved artifacts. As you can see, CDS is in the center of the development flow
and, for instance, the basis of the OData service, which is, in turn, consumed by the
SAP Fiori app or the BOPF business object for transactional processing.
96
第 97 页 / 共 465 页
3.2 SAP Gateway
SAP Web IDE SAP Fiori app
Consume
ABAP Development Tools
in Eclipse OData service
Search objects
Core Data Services (CDS) Generate/
publish
Enrich Generate
Metadata BOPF business
Data definition
extension object
Implement
Custom ABAP
business logic
Database table Draft table
Figure 3.1 Overview of the ABAP Programming Model Development Flow and Its Artifacts
3.2 SAP Gateway
SAP Gateway plays a crucial role in providing an easy-to-use non-ABAP-based access
to business data stored in backend SAP NetWeaver systems. Access to business data
is granted via REST-based OData services using HTTP as the underlying data transfer
protocol.
As of SAP NetWeaver version 7.40, the software component SAP_GWFND is installed as
part of the SAP NetWeaver standard and includes the full scope of functionality
required for hub and backend enablement. In general, from an architectural perspec-
tive, there are two deployment approaches: embedded deployment or hub deploy-
ment. The hub deployment can be further split up into development on the hub or
development in the backend system. The usual setup for an SAP S/4HANA on-prem-
ise system is shown in Figure 3.2. Usually, development takes place in the ABAP back-
end system, and a hub system will be introduced to handle the additional load of
97
第 98 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
client OData requests to the SAP Gateway component. This setup requires an addi-
tional SAP NetWeaver system functioning as the SAP Gateway hub system or fron-
tend server and a trusted remote function call (RFC) connection between the hub and
backend system to forward requests from the frontend to the backend system, which
contains the business logic and the data. The RFC-enabled function module passing
data from the frontend to the backend is /IWBEP/FM_MGW_HANDLE_REQUEST.
SAPUI5/SAP Fiori Elements
Browser
OData/
HTTPs
R
SAP Gateway Activated OData Service
(Hub deployment)
RFC
R
OData Runtime
(Model and Data ABAP A pplication
Provider) Server
R
Service Adaptation Definition
Language (SADL)
R
R
Business Object Processing
Framework (BOPF)
Core Data Services (CDS) Views
Database Tables
SAP HANA Database
Figure 3.2 High-Level Overview of a Typical SAP S/4HANA System
Setup with SAP Gateway Provided as a Separate Hub System
98
| Core Data Services (CDS) Views |
| Database Tables SAP HANA Database |
|---|
第 99 页 / 共 465 页
3.3 OData
The SAP Fiori app running in the browser sends OData HTTP GET, POST, DELETE, or PUT
requests to the SAP Gateway system, which exposes all registered and activated
OData services. The SAP Gateway passes the incoming OData requests to the backend
via a trusted RFC connection. The OData runtime in the backend then delegates the
actual data selection to the SADL framework layer. If the request is a read-only GET
request, SADL will delegate the request to its query engine, which will generate an
SQL SELECT statement to select the requested OData entity’s data from the database
tables via its corresponding CDS view. In case of a write access, for instance, POST for
create or PUT for update, the request will be delegated to the transactional BOPF run-
time, which will handle the database updates according to the provided transactional
annotations specified in the CDS view.
3.3 OData
OData is a REST-based data protocol used for transferring business data as well as
metadata between the ABAP backend system and client applications via the SAP
Gateway hub system. In SAP S/4HANA, client applications of OData services usually
are SAP Fiori SAPUI5 applications running in the local browsers of end-user devices
such as desktop PCs or tablets. Together with the SAP Gateway, OData provides access
to the SAP backend business data in an easy-to-understand and well-defined way
using HTTP as its data transfer protocol.
3.3.1 Overview
An OData service organizes data in the form of entities that have a set of properties
interconnected via associations. These elements resemble the elements of CDS data
models, so CDS data models are the perfect candidates for exposure as OData ser-
vices.
The structure of an OData service can be explored by looking at its service document
and its service metadata document. The service document contains a list of entities
or resources that can be accessed using this service and can be requested via /sap/
opu/odata/sap/<OData_service_name>/. Additionally, you can see whether the service
allows creating, changing, or deleting entities by looking at the sap:creatable,
sap:updatable, and sap:deletable attributes of the <app:collection> tag, which also
contains a relative reference to the entity set via its href attribute (see Figure 3.3).
99
第 100 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
Figure 3.3 Service Document of a Simple Purchase Document and Purchase Document Item
OData Service
The service metadata document is a lot more detailed than the service document and
shows all metadata of the service. It can be requested using the $metadata option:
/sap/opu/odata/sap/<OData_service_name>/$metadata. It displays all entities of the
service, including their properties and associations.
OData uses the REST HTTP commands POST, GET, PUT, and DELETE for creating, reading,
updating, and deleting (CRUD) entities. Additionally, OData defines a simple but
powerful query language for restricting the result set provided by the SAP Gateway.
Table 3.1 lists the most common OData query options.
Operation Query Option
Filtering $filter, e.g., $filter = PurchaseDocument eq
‘0005’
Projecting or selecting properties $select, e.g., $select = PurchaseDocument, Pur-
chasingOrganization,…
Sorting $orderby, e.g., $orderby = CreationDate desc
Client-side paging $top and $skip, e.g., $top = 10&$skip = 0
Table 3.1 Most Important OData Query Options
100
| Operation | Query Option |
|---|---|
| Filtering | $filter, e.g., $filter = PurchaseDocument eq ‘0005’ |
| Projecting or selecting properties | $select, e.g., $select = PurchaseDocument, Pur- chasingOrganization,… |
| Sorting | $orderby, e.g., $orderby = CreationDate desc |
| Client-side paging | $top and $skip, e.g., $top = 10&$skip = 0 |
第 101 页 / 共 465 页
3.3 OData
Operation Query Option
Counting $count
Formatting $format, e.g., $format = JSON
Table 3.1 Most Important OData Query Options (Cont.)
3.3.2 OData Service Creation
As you already know, you can directly select data from a CDS view using Open SQL in
ABAP, as you would select data from a conventional database table. However, SAP
Fiori apps require the exposure of data as an OData service using HTTP as the data
transfer protocol.
Currently, a CDS data model can be exposed as an OData service in three different
ways: Auto-Exposure, Reference Data Source (RDS), or Mapped Data Source (MDS).
Auto-Exposure
The simplest, but also the most restricted, way of exposing a CDS model as an OData
service is by using the @OData.publish:true header annotation (Listing 3.1).
@AbapCatalog.sqlViewName: ‘SQL_VIEW_NAME’
…
@OData.publish: true
define view CDS_VIEW_NAME as select from …
Listing 3.1 @OData.publish:true Header Annotation to Expose a Simple Coherent CDS Data
Model as an OData Service
When activating the view in the ABAP development tools in Eclipse, several artifacts
will be generated in the system (Figure 3.4):
(cid:2) The actual SAP Gateway Business Suite Enablement - Service object named <CDS_
VIEW_NAME>_CDS (object type: R3TR IWSV)
(cid:2) An SAP Gateway model named <CDS_VIEW_NAME>_MDL (object type: R3TR IWMO)
(cid:2) An annotation model named <CDS_VIEW_NAME>_CDS_VAN (object type: R3TR IWVB)
By default, the generated OData service won’t be activated. This must be done manu-
ally by accessing Transaction /IWFND/MAINT_SERVICE on the SAP Gateway hub sys-
tem.
101
| Operation | Query Option |
|---|---|
| Counting | $count |
| Formatting | $format, e.g., $format = JSON |
第 102 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
SAP NetWeaver
SAP Gateway Service Catalog
RFC
ABAP Development Tools
CDS Data Definition Editor AS ABAP Activate
CDS OData
service
Runtime
…
@Odata.publish: true Edit/Save
define view … CDS Data Service
Definition Artifacts
Activate
Figure 3.4 Components and Activities Involved When Exposing a CDS Data Model as an
OData Service Using the Auto-Exposure Method
The Auto-Exposure OData service creation method can only be used for simple
coherent CDS models that consist of a root node and first-level-associated views. It’s
not possible to add additional non-first-level-associated or unrelated CDS views as
OData entities to the service; for instance, if you have a coherent model of a purchase
document root view that has an association to a purchase document item child view,
and the item view in turn has an association to a material view, the material entity
can’t be part of the service because it’s not a first-level association of the root node
(Figure 3.5). If this is required, one of the other approaches must be used.
Scope of <CDS_VIEW_NAME>_CDS OData service
@Odata.publish:true
Purchase Association
Document
Association
Purchase
Document Item
Material
Figure 3.5 Scope of the OData Auto-Exposure Service Creation
102
| Service Artifacts | |
|---|---|
| Service Artifacts | Service Artifacts |
| CDS Data Definition |
|---|
第 103 页 / 共 465 页
3.3 OData
Referenced Data Source
For complex CDS view models that need to be exposed as OData entities within a
common OData service, the Reference Data Source (RDS) approach is the right choice.
A CDS model can be considered as complex in this case when it has several levels of
associations or unrelated root views. The RDS approach, however, requires the cre-
ation of an SAP Gateway Service Builder project. This can be done by carrying out the
following steps:
1. Open Transaction SEGW.
2. Choose the Create Project button in the toolbar (Figure 3.6).
Figure 3.6 Creating a New SAP Gateway Service Builder Project
3. In the Create Project dialog that appears (Figure 3.7), provide a description and
name for the SAP Gateway project that will become a transportable ABAP reposi-
tory entry (R3TR IWPR Z_PURCHASING_DEMO). In this entry, IWPR stands for Gateway
Business Enablement – Service Builder Project. Choose Continue.
Figure 3.7 SAP Gateway Service Builder: Create Project Dialog
103
第 104 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
After the project has been created, you can start creating the actual OData service.
First, you must create a data model. For the RDS scenario, we’ll create a data model by
referencing a CDS model. Therefore, choose Reference (cid:2) Data Source from the context
menu of the Data Model folder (Figure 3.8).
Figure 3.8 Creating a Data Model by Referencing a CDS Data Source
This will trigger the Reference Data Source Wizard (Figure 3.9). You must enter a CDS
view you want to expose as an OData entity within your OData service, usually the
root view or one of the root views of your CDS model.
Figure 3.9 Entering the CDS Root View of the Referenced CDS Model
In the next step of the wizard (Figure 3.10), you can select the associated views of the
previously selected CDS view and make them part of your OData service model defi-
nition.
104
第 105 页 / 共 465 页
3.3 OData
Figure 3.10 Selecting Associations of the CDS Root View
When you finish the wizard, you’ll see a new folder called Data Source References
Folder. If you open its subfolder, Exposures via SADL and select the CDS-Entity Expo-
sures node, you’ll see the previously selected CDS entities that will be exposed as
OData entities (Figure 3.11).
Figure 3.11 The Exposed CDS Entities of the Service Builder Project
You can also add any additional CDS entities using the Add CDS-Entity button, which
makes the RDS scenario a lot more flexible than Auto-Exposure. Finally, the OData
service can be generated using the Generate Runtime Objects toolbar button, which
will generate the runtime artifacts of the service and register them in the backend
system.
The first time the service is generated, the Model And Service Definition dialog will
appear so you can edit the default names of the objects to be created (Figure 3.12). As
105
第 106 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
you can see, the RDS scenario will also generate a model provider class (MPC) and a
data provider class (DPC), including the respective extension subclasses with the suf-
fixes MPC_EXT and DPC_EXT. The MPC provides the runtime representation of our refer-
enced CDS data model in the form of the service metadata document. The DPC
provides the actual entity data by delegating the incoming requests to the generic
SADL engine, which will transparently select data from CDS views and map them to
OData entities.
Figure 3.12 Model and Service Definition Dialog
With the RDS scenario, you have a lot of flexibility over the service creation process
and implementation. You can even extend the MPC_EXT class to provide additional
annotations or implement additional logic in the DPC_EXT class. However, adding
non-CDS entities to the service isn’t recommended.
Mapped Data Source
The Mapped Data Source (MDS) scenario is only used if one of the previous scenarios
isn’t applicable, for instance, if the service will contain non-CDS OData entities. Creat-
ing an OData service using the MDS scenario requires more manual work than the
RDS and Auto-Exposure approaches. As with the RDS approach, you must first create
a SAP Gateway Service Builder project using Transaction SEGW. Then, you must
define a data model either manually or, in the case of CDS views, by importing the
106
第 107 页 / 共 465 页
3.3 OData
ABAP SQL view name of the CDS view as a DDIC structure. You can do this by choos-
ing Import (cid:2) DDIC Structure from the context menu of the Data Model folder (Figure
3.13). Then, under the Service Implementation folder, select the entity, and choose
Map to Data Source.
Figure 3.13 Mapping the OData Entity to a Data Source
Select a CDS view to which you want to map the OData entity (Figure 3.14). This map-
ping will enable model-based data selection via the SADL engine, and you don’t have
to code the OData entity CRUD methods manually.
Figure 3.14 Mapping an OData Entity to a CDS Business Entity
107
第 108 页 / 共 465 页
3 ABAP Programing Model for SAP Fiori
Finally, you must manually map the fields of the OData entity to the fields of the CDS
entity by dragging fields from the SADL Model pane on the right side of the screen to
the mapping table in the middle (Figure 3.15).
Figure 3.15 Mapping Fields of the CDS Entity to Fields of the OData Entity
In addition to the mapped data source entities, you can also manually create entities
and implement their CRUD methods in the DPC_EXT class generated on the first gen-
eration of the service. As you can see, the MDS approach requires a bit more manual
work than the previous options but provides you with full flexibility over the service
creation. It supports generic data access to SADL CDS models as well as the manual
ABAP-based implementation of OData entities.
Activating a Service on the SAP Gateway Hub System
One step we omitted for all three scenarios was the activation of the service in the
Service Catalog of the SAP Gateway hub system, which we’ll show now. Transaction
/IWFND/MAINT_SERVICE is used to maintain all registered services, as well as to reg-
ister and activate new services. It’s the central entry point for dealing with OData ser-
vices. To add a new service, you must click the Add Service button (Figure 3.16 1). This
will lead you to another application for adding not yet registered backend services to
the Service Catalog of the SAP Gateway system 2. To find a certain service in a back-
end system, you must provide the system alias of the backend system in which the
service has been created as well as the technical service name; for instance, in the
Auto-Exposure case, this is <CDS_VIEW_NAME>_CDS. Finally, you can add the service to
the Service Catalog by selecting the corresponding line and clicking the Add Selected
Services button 3.
108