Part 1: Preparation
— — No ABAP development skills required — —
Part 1: Preparation (this blog)
* Quick-View on Prerequisites
* Service-Oriented View
Part 2: Create the Annotation Model
* Create Project
* Reference the Gateway Service
* Reference the vocabulary
* Create the Annotation Model
* Runtime Artifacts
Part 3: Explore the Annotation Model
Part 4: Connect the Cloud
* SAP HANA Cloud Connector
** Configure 1
** Configure 2
** Access HCP trial
** Tip: Avoid SSO
Part 5: OData provisioning
* Find it
* Configure it
** Assign Roles
** Create Destination
* Register Service
Part 6: The Fiori Application
* Create destination pointing to OData provisioning in HCP
* Generate application
* Run the application
Part 7: Trouble-Tips
The intention of this tutorial is to show how to generate a UI5 application based on Smart-Templates.
This requires an OData service and annotations.
While we’ll be using an existing service, we’ll be going in detail through all the steps required to create the annotations in the ABAP backend.
Furthermore, we’ll be learning how to use the SAP HANA Cloud Platform along with its offerings OData provisioning and SAP Web IDE
In the beginning of our tutorial, we’re creating the annotation model in the SAP backend.
But: what does that mean?
Basically, it means to create an ABAP class and overwrite the corresponding base-class-method to define the annotation model.
At the end, the model is attached to a Gateway service, the model is registered and is listed in the catalog service (/IWFND/CATALOGSERVICE), where it can be viewed in xml representation.
What is the benefit?
Annotations are helpful to add semantic information to metadata. For example, the metadata can declare that a property contains data as string. But with an annotation, we can declare that this data is always an eMail address.
So, annotations are used to enrich the metadata of an OData service.
They can be added directly in the corresponding xml element, like an attribute, but they can also be collected in a separate section of the metadata document.
They can even be located in a separate xml document, which then has to point to the OData service, which should be enriched.
Because of their structure, we refer to the set of annotations as an Annotation Model.
In our example, the annotation model declares UI elements and binds them to properties of the OData service.
Yes, the model belongs to an OData service, although it is defined outside of the service. The service doesn’t know about it. As such, any existing OData service can be enriched with detailed information about how it should be represented in the UI.
This is possible because the used annotations are based on a common public definition, which is stored in a so-called vocabulary.
As such, these annotations can be understood by a UI technology, and that UI technology will render the UI according to the annotations.
An OData service itself focuses on the data
-> e.g. the existing products and their names
Annotations that are defined inside the service provide additional info
-> e.g. can a product be filtered by name?
An (external) annotation model declares how to represent the data
-> e.g. products are shown in a table, but only name and description, and a selection field should allow to filter by name
The UI technology decides how to represent the data and renders the UI elements
-> e.g. labels, editable fields, lists
In our example, the UI technology used to create applications based on annotations is UI5 with its feature called Smart-Templates
At the end, when the Smart-Template-application is started, the SAP UI5 runtime renders the UI controls based on the specified annotations. That guarantees a unified look at feel, because all applications that are based on those annotations will look similar.
In case that UI5 changes the rendering, then it will affect all those applications
In this tutorial I’m talking about defining the UI with the help of an annotation model. However, the annotation model is not restricted to annotations relevant for UI. It can contain any annotations that are provided by any vocabulary.
More information in Ashish’s vocabulary blog
In our example, the OData service is an SAP Gateway service, as it is built and running upon SAP Gateway technology
Below image shows the scenario and the techhologies and components covered in this tutorial:
Even if you’ve never touched an SAP NetWeaver system, at the end of this tutorial you’ll have used the most prominent SAP Gateway development tools like a pro 😉
You don’t create an OData service, but you create an annotation model for an existing service.
And you learn a lot…!
How is it done?
In order to create an annotation model, the following steps have to be performed:
1. Create a Gateway Service or choose an existing one (this blog)
2. Create the annotation model using Service Builder tool and verify the xml representation of the annotation model via OData service (next blog)
Quick-View on Prerequisites
In order to follow this tutorial, you need the following prerequisites:
* Access to a SAP NetWeaver system where the OData service /IWBEP/GWSAMPLE_BASIC is available and up and running.
See the Links section (last blog) for more info.
Note that you don’t need any ABAP development know-how to follow this tutorial.
You only need to be able to log into the NetWeaver system.
if you’re not familiar with ABAP, you need to be aware of being confronted with a kind of user interface that you aren’t used to…
* SAP HANA Cloud Platform
If you’re not up in the cloud, don’t worry…
During the tutorial, I’m going to describe how to get access to the trial account of the SAP HANA Cloud Platform (HCP)
This section is dedicated to the OData service on which the Fiori application which we’re going to create, will be based on.
In our example, we don’t need to create a new Gateway service, since the so-called standalone annotations are anyways created in a separate project.
So we’re using the standard demo service GWSAMPLE_BASIC which is available as per default in SAP NetWeaver. Please refer to the Links section at the end of the tutorial for more info about the service.
Note that we aren’t modifying the service, we’re creating a separate, standalone annotation model that refers to it.
There might be other annotation models that refer to the same service, but that’s no problem. Imagine that there might be different tools that are use the data that is delivered by that service and those different tools display a different subset of the data, for example.
Let’s have a quick view on the service.
We invoke the Service to see if it is running and we invoke the SalesOrder collection on which our future application will be based.
In order to invoke the service we can use the REST client tool which is delivered with SAP Netweaver
* log-on to your SAP system
* open the SAP Gateway Client tool using the transaction /IWFND/GW_CLIENT (or /n/IWFND/GW_CLIENT)
* Execute the following URI:
* Invoke the collection of sales orders:
Refer to the screenshot for details:
The call should be successful.
Tip: don’t close the window, we’ll need it later.
That’s it for the first step – it was for free;-)
I recommend continuing with the next blog where you’ll learn how easy it is to create an annotation model…
— — Stay tuned and you’ll have nice annotations — —