Odata
OData
Why we need ODATA
SAP OData comes with multiple advantages. It not only helps us to expose data but also helps a customer to access data from anywhere and any device. If there will be no OData services, then the data will remain on premise and in case a user needs to access their data, they might have to visit the data location, which is uncomfortable for the digital world.
Advantages of an ODATA
Using SAP OData provides us following advantages:
- It helps to obtain human readable results i.e. you can use your browser to see the output data
- It is very easy and relatively fast to access data
- It uses all the standards of web protocols i.e. GET, PUT, POST, DELETE, and QUERY
- It uses Stateless Applications: It means Server does not save any data of Client (e.g. UI5 Application) and treats every OData call as a new call
- It receives data in form of related pieces of information, one leading to another: It is an interaction pattern known as “alert-analyse-act”, “view-inspect-act”, or “explore & act”. According to this pattern not all data are loaded together, and a user analyses a data and reaches its required information after navigation. In this way the data loads quickly and correctly.
HTTP codes are 3 digit integers.
OData allow creation and consumption of RESTful APIs.
What is REST?
REST or REpresentational State Transfer is an architectural style that uses simple and lightweight mechanism for inter-machine communication. It is an alternative to the RPC (Remote Procedure Calls) and Web Services.
REST is resource based unlike RPC or SOAP which are action based. In SOAP you will have a request to get material data whereas in REST, material will be identified as a resource using URI and then use HTTP verbs to determine which operation shall be performed on the resource. It is important to note here that it is possible to have multiple URIs pointing to the same resource.
Representation of the resource is the not the resource itself but only a representation.
The term representation is how the resources are manipulated in a rest based architecture
Representations depicts parts of the resource state which are transferred between client and server in mostly JSON or XML format. Client will typically have enough information to manipulate the resource on the server. For example, if Person is modelled as a resource and there is a service to get contact information of a person then the representation that you will get of that Person would be Name, Address and Phone details in JSON or XML format.
The Six Constraints
Following are the six constraints defined which are attributes of a RESTful API.
1. Uniform Interface
Uniform Interface is fundamental to the design of any REST based service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.
What that means is that it should be possible to identify the individual resource in the request, for example using URI. Once the Client has a representation of the Resource then, it should have enough information to update or delete the resource. And that the Client should not assume that any particular action is available on a resource beyond those described in the representation received from the server previously.
2. Stateless
The Server should not contain any Client state. It is possible to process a request only if they are self-descriptive and that the request should have enough context to act upon. For example, if the Person resource address needs to be updated then it is required that the Client pass on the particular Person resource details in the request for which it has received the representation from the Server in the previous request. If the state has to be maintained, it should be at the Client side.
3. Client-Server
We have already established this constraint that the RESTful architecture is a Client-Server architecture. Resource representations are transferred between client and server. We should always keep at the back of our minds that the Client of RESTful APIs will not have direct connects to the Resources.
4. Cacheable
Another constraint on a RESTful API is that any response that is coming from the Sever should be cacheable on the Client side. Caching could be implicit, explicit or negotiable. Implicit and Explicit caching is self-explanatory whereas Negotiable caching means that the Server and Client agree on how long a representation can be cached on the Client.
5. Layered System
The constraint of Layered System is closely related to the above two constraints of Client-Server and Cacheable. It suggests that the Client of a RESTful API should not assume that there will be a direct connection between the client and the server. There could be multiple layers of software or/and hardware in between the two. The Client need not know whom exactly it is talking to and whether a response is coming from the server or is accessed from a local cache. This improves scalability.
6. Code on Demand
This constrains suggests that it should be possible that a Server can extend a Client temporarily. It means that Server can transfer logic to the client as representation to be executed at the client.
This is the only optional constraint.
A RESTful service needs to adhere to all of the above mentioned constraints (except Code on Demand) to be called as a RESTful API.
What is OData?
“Open Data Protocol (OData) is an open data access protocol from Microsoft that allows the creation and consumption of query-able and interoperable RESTful APIs in a simple and standard way”.
The protocol enables the Clients to publish and manipulate the resource identified by URIs and defined in a data model using simple HTTP messages.
To put it in simple words, OData is an open source to exchange data over the Internet. Server hosts the data and clients can call this service to retrieve the resources and manipulate them. Servers expose one or more endpoints which are services that refers to the resources. Clients need to know this server side endpoints to call the service to query or manipulate the data. The protocol is HTTP based and designed with RESTful mindset which means it follows the constraints to be called as a RESTful service.
Since the protocol is HTTP based, any programming language with HTTP stack can be used to consume OData services. Existing Client side libraries can be used to transform the JSON or ATOM payloads from the server into objects making programming simple. On the other hand, many libraries exists on the Server side to generate the payloads in ATOM or JSON from the existing data.
It is important to note that both Client side and Server side development can be in completely different programming languages till the time both are able to communicate via HTTP.
Clients consume the service to query and manipulate the data from OData Services and are also called as Consumers of OData Service.
Similarly, Servers that expose the OData services via endpoints are known as Producers of Odata services.
So, we now know that in OData protocol, the resources are exposed in two formats; XML based Atom and JSON.
A brief description of what is Atom ad JSON.
Atom is a combination of two protocols, Atom Syndication and Atom Publishing protocol. The Atom Syndication Format is an XML language used for web feeds, while the Atom Publishing Protocol (AtomPub or APP) is a simple HTTP-based protocol for creating and updating web resources.
JSON stands for JavaScript Object Notation is a light weight data-interchange format. JSON is self-descriptive and easy to use and is completely language-independent.
Advantages with OData
There is a lot of data on the web today but lot of it is locked up in different specific applications or formats and different to access from outside. Many Organizations have now started exposing data using REST based services however, it is difficult to write applications which works with multiple data sources as each provider will expose the data in a slightly different way. OData service producer can expose its service along with metadata which contains the semantics for consumption. OData exploits the common formats like XML, Atom and JSON for communication which are commonly understood. Clients can now understand these OData services using generic tools and can combine information from multiple data sources.
Exposing your data with OData services comes with multifold advantages. For example, as we mentioned earlier, as a consumer, you need not worry about the programming language used by producer as long as the services are exposed as OData service.
ODBC for the Web
ODBC (Open Database Connectivity) is a standard API to access the database management systems independent of the database management systems or operating systems. ODBC manages this by adding drivers between the Application layer and the DBMS to translate the queries fired by application into instructions which DBMS can understand.
OData has similarity with the ODBC in a sense that here, OData provides the middleware between producers and consumers to communicate data. There is a uniform way to consume data and is independent of the producer much like ODBC. The fact that OData is based on HTTP RESTful services makes it the ODBC for the Web!
SAP Netweaver Gateway – An Introduction
For Business Users, ease of access has become critical with the advent of various mobile devices that support end-to-end scenarios and also provides a rich user experience. There is a need to better integrate data, reduce complexity and improve productivity. This has been a challenge for the Developer community to be able to support multiple platforms to consume enterprise data more easily than ever before and on the other hand provide solutions that are scalable and with low TCO (Total Cost of Ownership).
Point-to-point solutions are not the right way as it has lot of drawbacks including duplication of development effort, increased cost, complex landscape, poor scalability and difficult to maintain.
SAP Netweaver Gateway is a technology that has the answer to this. It can seamlessly connect devices, platforms and environments to SAP Enterprise Data using the OData services. SAP Netweaver Gateway offers connectivity to SAP Business data using any programming language and without the need of strong SAP development knowledge.
SAP Netweaver Gateway comes with design-time tools to facilitate modeling OData services for consumption. These tools improve user experience and provide automatic connectivity to the SAP backend that reduces development efforts and improves productivity.
SAP Netweaver Gateway sits on top of the existing SAP Backend infrastructure. There are set of add-on components that needs to be installed on a SAP Backend system to enable SAP Netweaver Gateway services. It is this architecture that enables consumption of SAP data by variety of interfaces such as BAPIs and RFCs
SAP Netweaver Gateway Service Builder tools is SAP GUI based modeler to create and publish Odata services using transaction SEGW.
There is also an Eclipse-based Odata Modeler tool available. It provides an easier way to model the service that is a much easier way to develop if you are not too familiar with ABAP programming language. The models can be conveniently created here are exported to the development environment for the Gateway.
SAP Annotation with Odata
SAP has leveraged the extensibility feature provided by Atom Publishing protocol to add SAP specific annotations. AtomPub allows you to add your own markups in the service document. SAP adds annotations from the ABAP Data Dictionary, for example, labels to the documents which can then be consumed by the front end application without having to worry about translations in this case.
What is OData and REST in SAP Netweaver Gateway
SAP Netweaver Gateway provides REST based and open interface that implements simple access to SAP systems via OData protocol.
With SAP Netweaver Gateway any one can i.e. any user interface(UI) can access the data through OData protocol.
Is this the only one that can communicate to other systems in SAP portfolio? the answer in NO. We have SAP PI system to exchange information between different systems and especially between a company and 3rd parties.
But the main difference between SAP PI and SAP Netweaver Gateway is in their usage.
SAP Netweaver PI is to communicate the information between system-to-system, but SAP Netweaver Gateway is system-to-user.
Lets look at what is OData and REST mean actually.
What is OData?
OData is REST based protocol to access and update the data. OData is build on Atom Publishing Protocol(AtomPub), XML and JSON.
This make the protocol easy to understand and use.
In short OData is an Online Database Connectivity(ODBC) for the web. It offers a simple and uniform way of sharing the data on protocol level which in turn enables broad integration across different products and platforms.
For more information
What is REST?
The full form of REST is REpresentational State Transfer. REST is not a kind of protocol, it is a architectural style.It builds on HTTP.
An architecture is a REST based when it complied these constraints
- Client Server architecture
- Statelessness
- Cache-ability
- Layered system
- Uniform Interface
- Code on demand
Let put this simple, to access list of sales orders in SAP we can access through an URI(Unified Resource Identifier) and if we want to get the data of particular sales order data we just need to change the URI and add the sales order # to URI.
Structure of OData Service
As you known about SAP OData. In this blog lets look at the basic structure of the OData service. It have mainly two parts
- Service document
- Service metadata document.
Service document
Service documents consists of all list of resources URI’s that can be accessible. ZSL_EPM_DEMO is the OData service which we will be going to build in future tutorials. Basically this service will retrieve sales order data.
Lets look at what information does this service documents holds.Service document is accessible through the URI.
Service metadata document
Service metadata documents contains meta data of all elements in the service. You can see the metadata of a service by simple adding “$metadata” to the service URI.
Different elements we see in SAP OData service are
Entity Type: Entity is like work area which holds empty or one record data. As we have different fields in work area here also we have different fields and we call them as Properties.Each Entity should have at least one key field.
Entity Set: Entity Set is a collection of same entity types. It is like internal table which holds n records of same type. For example list of sales orders is a Entity Set.
Property: It represents a primitive data type element.It is like a single field in a work area or single column in a table. one or more properties are used to create an Entity Types.
Association: It defines the relation between different entity types.For example if we have two entity types one for Sales Order header and other for Sales Order Item we can build the association between these two entity types with cardinality.
Navigation property: Entity Types include one or more navigation properties.It is specific type which acts like a link to the other Entity types based on cardinality provided in the Association property. To create the navigation property for an entity type we need first define the association between those entity types.
How to Activate SAP Netweaver Gateway
1. Go to SPRO >> SAP Reference IMG
2. Expand SAP Netweaver >> Gateway >> ODATA Channel >> Configuration >> Activate or Deactivate SAP Netweaver Gateway
3. Click on Activate or Deactivate button to activate or deactivate SAP Netweaver Gateway. In this case gateway is already activated.
Please feel free to comment and let us know your feedback. Subscribe for more updates
How to Connect SAP Gateway to Backend Systems
Below are steps related to connection settings to sap netweaver gateway.
1. Go to SPRO >> SAP Reference IMG
2. Expand SAP Netweaver >> Gateway >> ODATA Channel >> Configuration >> Connection Settings >> SAP Netweaver Gateway to SAP System.
3. Execute “Mange RFC Destination”
4. Create a new ABAP RFC Connection to SAP Back-end Systems (ERP, SRM, CRM etc.).
- If you choose Hub Deployment, create a RFC connection to connect to SAP ERP system.
- If you choose Embedded Deployment, create a RFC connection to itself.
Model your first ODATA Service
Hello everyone, in this blog post, we will learn how to create OData service in SAP Netweaver Gateway System.
Below are steps to model OData service and this tutorial is one among the first sap netweaver gateway tutorials.
To access all SAP Netweaver Gateway tutorials, please click here.
1. Go to transaction code SEGW(Gateway Service Builder).
2. Click on Create Project button. Provide the following details and click on OK.
3. Project will be created successfully with following artifacts
4. Right click on Data Model → Import → DDIC structure
Provide below information and click on Next
- Name – SalesOrder
- Select “Entity Type”
- Give ABAP Structure as SNWD_SO
- Check “Create Default Entity Set” , if you want to create Entity Set by default
5. Select the fields from the structure SNWD_SO to be the part of the ODATA service and Click on Next.
6. Choose SO_ID field as Key and click on Finish.
7. An Entity Type is successfully created. Go back and expand the Data Model you can find newly created Entity Set “Sales Order” and its properties.
8. Click on Generate to generate the Service
9. Click on OK
10. Service will be created successfully with below screen
Implement your first OData Service in SAP Netweaver Gateway
In our first sap netweaver gateway how to guides we have modeled the OData service. In this tutorial we are going to implement the service i.e. writing the actual business logic to pull the data from the back-end system.
1. Go to Gateway Service builder SEGW and expand the Service Implementation node of the service.
2. Under this node you will find five methods for each Entity Set.
- Create – Includes the business logic to create data in the back-end system.
- Delete – to delete the data from the back-end system.
- GetEntity(Read) – to read the single record details from back-end system.
- GetEntitySet(Query) – to read the list of data from the back-end system
- Update- to update the data into back-end system.
Example: The service we are going to implement is Sales Order related. So to get the list of sales orders from the back-end system we should write the abap code in GetEntitySet (Query) method. To read the single sales order details we should write the abap code in GetEntity (Read) method.
3. First we are going to implement the method GetEntitySet (Query) method to get the list of sales orders from the back-end system. To do so right click on GetEntitySet(Query) → Go to ABAP Workbench.
4. As we are going to implement the method ignore the popup and click on continue
5. You will be navigated to DPC_EXT class and find the method SALESORDERSET_GET_ENTITYSET to write the code.
6. Select the method SALESORDERSET_GET_ENTITYSET method and click on redefine button on the top.
7. You will find some commented code in the method when you redefine ignore that and write the below code to fetch the sales order using BAPI.
DATA: ls_max_rows TYPE bapi_epm_max_rows,
lt_salesorder TYPE TABLE OF bapi_epm_so_header,
ls_salesorder TYPE bapi_epm_so_header,
ls_entityset TYPE zcl_zdemo_gw_srv_mpc=>ts_salesorder.
ls_max_rows-bapimaxrow = 20.
CALL FUNCTION 'BAPI_EPM_SO_GET_LIST'
EXPORTING
max_rows = ls_max_rows
TABLES
soheaderdata = lt_salesorder.
IF lt_salesorder IS NOT INITIAL.
LOOP AT lt_salesorder INTO ls_salesorder.
MOVE-CORRESPONDING ls_salesorder TO ls_entityset.
APPEND ls_entityset TO et_entityset.
ENDLOOP.
ENDIF.8. Save and activate the method SALESORDERSET_GET_ENTITYSET and then class ZCL_SL_EPM_DEMO_DPC_EXT. Go back to the Service Builder.
This completes the service implementation of the service ZSL_EPM_DEMO. In our next tutorial we will register and test the service in SAP Netweaver Gateway system
Register your first ODATA Service
Dear SAPLearners, in this tutorial we will learn how to register the OData service to be able to access from the applications.
After modeling and implementing the service we have to register the OData service to use it. Previous SAP OData tutorials can be accessed here. So lets get started
Step-by-Step Procedure
1. To register the OData service go to /IWFND/MAINT_SERVICE transaction. Add “/n” in-front of the tcode.
2. Click on Add Service button to register the service.
3. Search for the service name in the system where you have created your service. Click on Get Services
Hub Deployment – Provide the alias as your back-end system.
Embedded Deployment – Provide “LOCAL”
4. Select the service and Click in Add Selected Service button.
5. Assign the package to the service and leave other fields as it is and Click on OK.
6. You will get below popup saying that service is registered successfully.
7. Go back to service maintenance tcode /IWFND/MAINT_SERVICE. You will find the service and technical name of the service will be <ProjectName>_SRV.
Please stay tuned to us for more OData tutorials.
Test your first ODATA Service
After modeling, implementing and registering the service in SAP Netweaver gateway. Now the service is ready for use we can test the service.
1. To test the service, open /IWFND/GW_CLIENT – SAP Netweaver Gateway Client transaction.
2. Enter the service name and add $metadata at the end and Execute.
3. Metadata of the service will be retrieved and the “HTTP Response will be 200”.
4. Now enter the service name and add Entity Set name. List of sales order will be retrieved in the form of XML format.
5. If you want to retrieve data of one Sales Order #, append the Sales Order# to the service and execute.
To retrieve the data of a single Sales Order# we need to implement the method GetEntity (Read) of the service. Click here
Single record read of a ODATA Service
In previous SAP Netweaver Gateway tutorials part1, part2, part3 and part4 we retrieved the list of Sales Orders. In this tutorial we are going to retrieve a particular Sales Order.
We need to implement the method Get Entity (Read) of an OData service.
1. Go back to SEGW and choose the service name ZSL_EPM_DEMO.
2. Expand the service. Service Implementation → GetEntity(Read) → Right Click → Go to ABAP Workbench.
3. Find the method SALESORDERSET_GET_ENTITY in DPC (Data Provider Class) ZCL_ZSL_EPM_DEMO_EXT and click on Redefine to redefine the method.
4. Let’s have a look at the signature of the method.
IT_KEY_TAB – stores the all key values and its value of the request. In our entity type the key is “SoId” .
ER_ENTITY – this is the exporting structure in which we need to pass the sales order details.
5. Write the below code in the method SALESORDERSET_GET_ENTITY
DATA: lwa_key_tab TYPE /iwbep/s_mgw_name_value_pair,
lv_so_id TYPE snwd_so_id,
lwa_snwd_so TYPE snwd_so.
* To get the Sales Order#
READ TABLE it_key_tab INTO lwa_key_tab WITH KEY name = 'SoId'.
IF sy-subrc = 0.
lv_so_id = lwa_key_tab-value.
ENDIF.
* Alpha Conversion
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING
input = lv_so_id
IMPORTING
output = lv_so_id.
* Get the data from the table
SELECT SINGLE * FROM snwd_so INTO CORRESPONDING FIELDS OF er_entity WHERE so_id = lv_so_id.
6. Save and activate the method and then DPC extension class.
7. Go to SAP Netweaver Gateway Client /IWFND/GW_CLIENT to test the service. Enter the service name with sales order number like below and the Execute.
8. The result will look like below.
You have successfully implemented a Single Read in SAP Netweaver Gateway OData service.
Header and Item data in SAP OData Service
In our earlier SAP Netweaver Gateway OData tutorials part1, part2, part3 and part4 we tried to retrieve the Sales Order Header Information.
In this tutorial we will learn how to retrieve Item data and how to associate the Header Entity with Item Entity.
1. Create a new Entity Type for Sales Order Item information in service ZSL_EPM_DEMO. Right Click on Data Model → Import → DDIC Structure.
2. Provide the name of the entity type, ABAP structure name and Click on Next.
3. Pick the fields from the structure and Click Next
4. Choose Sales Order and Sales Order Item as key fields and click on Finish
5. This completes the creation of Entity Types. Regenerate the service to add the “OrderItems” Entity Type. Next step is to implement the methods of this entity type to pull the data.To implement the methods navigate to Service Implementation node and choose, expand the entity type “OrderItemsSet”.
Right click on GetEntitySet(Query) → Go to ABAP Workbench.
6. Go to the change mode of the DPC_EXT class and select the method ORDERITEMSSET_GET_ENTITY method and click on redefine.
7. Write the below code to retrieve the sales order item data for first 20 rows from the tables.
8. Save and activate the DPC_EXT method and class. This completes the implementation of the service to get the list of Sales Orders and their item data.Lets test the service to make sure that every thing is working properly till now.
9. Go to SAP Netweaver Gateway Client /IWFND/GW_CLIENT and enter service name with Entity Set name and execute the service.
10. In the result you can see the Sales Orders and Item data are retrieved in XML format. Till now we just retrieved the order and item data individually.
But now we want to retrieve the item data from entity set by giving the Order number in the service URI. To do, we need to understand two important concepts Association and Navigation in OData Service.
Q1. What is the name of the protocol that is supported by SAP Gateway?
A1. TCP/IP
A2. OData
A3. SOAP
A4. RFC
Q2. The service metadata document contains following information
A1. Structure of an OData Service
A2. The Service Operation exposed
A3. The known links between resources
A4. All the above
Also Read: Structure of OData service
Q3. Which of following HTTP commands and their operations are correct?
A1. PUT – Allows to update the whole entity
A2. POST – Allows to create an entity
A3. PATCH – Allows to partially update the entity
A4. All the above
Q4. You can group multiple operations into a single HTTP request by using?
A1. OData Grouping
A2. OData Batching
A3. OData Collection
A4. OData Clustering
Q5. Which of following query options can be used to limit the size of the result set?
A1. $filter
A2. $orderby
A3. $select
A4. $expand
Q6. Which of following query option can be used to limit the size of the result set by limiting the number of columns?
A1. $expand
A2. $filter
A3. $select
A4. $top
Also Read: Query Options in OData Service
Q7. Arrange the following phases in the development of OData services in the correct order?
(A) Data Model Definition
(B) Project Creation
(C) Service Maintenance
(D) Service Implementation
A1. A, B, C and D
A2. B, A, D and C
A3. D, B, A and C
A4. D, B, C and A
Q8. What is the name of the tool that is used to implement OData services for SAP Gateway?
A1. Eclipse ABAP Development Tool
A2. SAP Gateway Service Builder
A3. SAP Gateway Client
A4. SAP Gateway Editor
Q9. Which of the below transaction is used to check the error logs in SAP Gateway hub system?
A1. /IWFND/ERROR_CHECK
A2. /IWFND/ERROR_LOG
A3. /IWBEP/ERROR_CHECK
A4. /IWBEP/ERROR_LOG
Q10. Which of the following tasks can be performed using transaction /IWFND/MAINT_SERVICE?
A1. Assign/remove additional system alias
A2. Define the data model of an OData service
A3. Add/remove services from the hub
A4. Implement the data provider extension class
Q11. Which of the following query options will retrieve the number of entries that the list contains?
A1. $count
A2. $top
A3. $inlinecount=allpages
A4. $select
Q12. The wizard for creating an entity type based on a search help performs two steps. What are these steps?
A1. Data model definition
A2. Service maintenance
A3. Service implementation
A4. Service activation
Also Read: Using Search Helps in OData service
Q13. When generating a service by using redefinition, which of the following options are available?
A1. Redefine a BW query service
A2. Redefine an RFC function module
A3. Redefine an existing SAP Gateway service
A4. Redefine a search help
Q14. What are different ways to create a Gateway service based on a CDS view?
A1. Code mapping
A2. Project redefinition
A3. Data reference
A4. @OData.publish
Also Read: Different ways to create a OData service
Q15. Which development tool is needed when using the odata.publish:true annotation for CDS view?
A1. Eclipse
A2. SE80
A3. SEGW
A4. /IWFND/MAINT_SERVICE
Also Read: How create OData service based on CDS view using annotation
Q15. ABAP CDS views are supported from which of the following releases?
A1. SAP Netweaver 7.51
A2. SAP Netweaver 7.40
A3. SAP Netweaver 7.0 with SAP Gateway 2.0 SP08
A4. SAP Netweaver 7.50
Q15. SAP Gateway hub supports multiple back-end systems through routing and multiple origin composition?
A1. True
A2. False
Q16. In routing scenario, the SAP system alias that points to specific back-end system is selected by using following as a filter?
A1. User role
A2. User profile parameter
A3. Modify the SAP standard implementation
A4. Implementing a BAdI
Q17. $expand is used to retrieve multiple entities that are connected through?
A1. Identical property names
A2. Function Imports
A3. Navigation properties
A4. Connectors
Also Read: How to implement $expand in OData service
Q18. SAP Gateway support online scenarios and does not support offline scenarios?
A1. True
A2. False
Q19. The Function Import functionality is implemented via mapping by using the RFC/BOR generator?
A1. True
A2. False
Also Read: How to implement Function Import
Q20. OData does not support the handling of binary data?
A1. True
A2. False
Also Read: How to handle binary data in OData service via media links
How to map message to OData response header SAP-Message
Hello everyone, in this blog post you will learn how to to map message to OData response header SAP-Message.
Message Container
Message Container in back-end OData service is used to add the success or error messages to the response of the OData service.A standard interface /IWBEP/IF_MESSAGE_CONTAINER is available to add the messages to the OData response.
OData response header parameter “sap-message”
When a request called from SAPUI5/SAP Fiori application is successful and the success, warning messages needs to be send back to the consumer, we can use the response parameter “sap-message” to send the messages.
Message container interface /IWBEP/IF_MESSAGE_CONTAINER is used to map message container to this message protocol.
Lets start by creating an example to map the messages in the OData service and how SAPUI5/SAP Fiori application can retrieve these message to display on UI.
Step-by-Step Procedure
#1 Create an OData service
Create a OData service in back-end system/front system with an entity set called “AirlineSet” which retrieves the different airlines available in the table. Here I took this simple example to demonstrate the concept, you may choose a different example as per your need.
We have step-by-step guides available here to explain the process of OData creation, I will not explain the process as we are focusing on this particular concept.
Please continue further after you have an entity set ready and code exists in the Data Provider Class(DPC) extension to get the data. You code may look like below
METHOD airlineset_get_entityset. SELECT * FROM scarr INTO CORRESPONDING FIELDS OF TABLE et_entityset. ENDMETHOD.
#2 Test the OData Service
Test the OData service in the gateway client, you should see a success response like below with HTTP response code as 200.
Now our next step to step is add the some success, warning message to this response. Lets say a sample message about airline discounts. So modify the above code to add the message.
#3 Adding a message to OData response header parameter “sap-message”
Instantiate the Message Container
Method GET_MESSAGE_CONTAINER is found in the DPC extension class to instantiate the message container. Sample ABAP code is available below
METHOD airlineset_get_entityset.
SELECT * FROM scarr INTO CORRESPONDING FIELDS OF TABLE et_entityset.
*1. Instatiate the Message Container
DATA: lo_message_container TYPE REF TO /iwbep/if_message_container.
CALL METHOD me->/iwbep/if_mgw_conv_srv_runtime~get_message_container
RECEIVING
ro_message_container = lo_message_container.
ENDMETHOD.Add the message to the Message Container
To add a message to the message container, we can use any of these methods in the message container interface, in the example we use the basic method ADD_MESSAGE
- ADD_MESSAGE_FROM_EXCEPTION
- ADD_MESSAGES_FROM_BAPI
- ADD_MESSAGE_FROM_BAPI
- ADD_MESSAGE
- ADD_MESSAGE_TEXT_ONLY
Method ADD_MESSAGE required message class, id and type of the message.
METHOD airlineset_get_entityset.
SELECT * FROM scarr INTO CORRESPONDING FIELDS OF TABLE et_entityset.
*1. Instatiate the Message Container
DATA: lo_message_container TYPE REF TO /iwbep/if_message_container.
CALL METHOD me->/iwbep/if_mgw_conv_srv_runtime~get_message_container
RECEIVING
ro_message_container = lo_message_container.
CALL METHOD lo_message_container->add_message
EXPORTING
iv_msg_type = /iwbep/cl_cos_logger=>warning
iv_msg_id = 'ZTEST'
iv_msg_number = '000'
iv_add_to_response_header = abap_true. "add the message to the header
ENDMETHOD.The important parameter which should be noted here is IV_ADD_TO_RESPONSE_HEADER,if we set this parameter as true then the message will be added to the response header parameter “sap-message”.
Now test the service again in the gateway client to validate whether the message exists in the response header.
In the above OData response, the message appears in the header parameter “sap-message”.
We have successfully map the message container to the response header parameter “sap-message”.
Display the message in SAPUI5 / SAP Fiori application
To display the message in SAPUI5 and SAP Fiori applications, we need to read the response object and read the message. Below sample JS code snippet can be used to read the header message.
Below is the code of a view controller, in this example we log the message to the console. You may have alternative way to display the messages in dialog
sap.ui.define([
"sap/ui/core/mvc/Controller"
], function(Controller) {
"use strict";
return Controller.extend("com.saplearners.controller.View1", {
onInit: function() {
var oModel = new sap.ui.model.json.JSONModel();
this.getView().setModel(oModel, "viewData");
var oServiceModel = new sap.ui.model.odata.v2.ODataModel("/sap/opu/odata/sap/ZMSG_CONT_DEMO_SRV/");
var mParameters = {
method: "GET",
success: jQuery.proxy(function(oData, response) {
this.getView().getModel("viewData").setProperty("/AirlineSet", oData.results);
// response header
var hdrMessage = response.headers["sap-message"];
var hdrMessageObject = JSON.parse(hdrMessage);
// log the header message
console.log(hdrMessageObject);
console.log(hdrMessageObject.message);
}, this),
error: jQuery.proxy(function(oError) {
}, this)
};
oServiceModel.read("/AirlineSet", mParameters);
}
});
});Console
Congrats..! We have successfully learned how to map message to OData response header SAP-Message. Please stay tuned for more SAP OData tutorials.
How to create OData Service for ABAP CDS View using Mapping Editor in SEGW
Hello everyone, in this blog post we will learn how to create an OData Service for ABAP CDS Views using Mapping Editor in SEGW(Gateway Builder).
There are 3 different ways to implement an OData service for an ABAP CDS view. Till now we have learnt 2 different approaches, in this blog we will learn the last approach using Mapping Editor in SEGW Gateway Builder. Please find the links below for the first 2 approaches.
- Expose one or more ABAP CDS views to OData service including associations, actions
- Expose one specific ABAP CDS view to OData service using annotation @Odata.publish:true
Lets start the process by creating an ABAP CDS view in Eclipse ADT(ABAP Development Tools). Copy and paste the below DDL source code in the CDS view editor.
@AbapCatalog.sqlViewName: 'ZV_ODATA_DEMO'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'OData service on ABAP CDS View'
@OData.publish: true
define view ZODATA_DEMO as select from scarr
{
key carrid as AirlineCode,
carrname as AirlineName,
currcode as Currency,
url as AirlineURL
}Save and activate the CDS view.
Step-by-Step Procedure
1. Creating a New Project
1.1 Launch SEGW – Gateway Service Builder transaction on front-end server(FES).
1.2 Click on Create Project and provide the necessary details on Create Project dialog box.
1.3 A new SEGW project will be created with empty data model like below.
1.4 Right click on the Entity Types node which is under Data Model to create a new entity type.
1.5 On Create Entity Type dialog box, provide the Entity Type Name, tick Create Relate Entity Set check box to system proposed Entity Set Name. Hit OK button.
Note: To create an entity type you can directly import the DDIC Structure by right clicking on Data Model node → Import → DDIC Structure.
1.6 After creating entity type and its corresponding entity set, now the project will look like this.
2. Mapping Editor
In this step we will map the ABAP CDS view data source to the entity set to retrieve the data
2.1 Expand Service Implementation node → Select and Right click on the entity set name to which you need to map the data source and choose Map to Data Source from the context menu.
2.2 On Map to Data Source dialog box, for Type field choose “Business Entity” and select value-help for Name field.
2.3 On Select Business Entity dialog box, chose the ABAP CDS view name and hit OK button.
2.4 On Mapping Editor screen, hit the button Generate Mapping to automatically map the fields. Instead you can also map the individual fields by drag and drop the fields.
3. Generating Model Provider Class/Data Provider Class and Other Run-time Objects
3.1 Navigate and select the project node and hit Generate Runtime Objects button to generate the SEGW OData service run-time artifacts.
3.2 On Model and Service Definition dialog box, a list of classes is shown and will be generated. You can go with default name or change them if you like to give different names and hit OK.
3.3 On the Create Object Directory Entry dialog box, enter a value (e.g. $TMP) to the Package field, and then choose Save.
3.4 Now the gateway service classes are generated successfully.
4. Activating Service
4.1 Launch the transaction /IWFND/MAINT_SERVICE – Activate and Maintain Services.
4.2 Choose Add Service.
4.3 On Add Selected Service screen provide the value for System Alias field and then choose Enter. A list of services is then displayed.
4.4 From the list of services choose the relevant service, you can search based on your project name. Click on Add Selected Services
4.5 On Add Service dialog box specify the package name and choose Enter.
4.6 Service is successfully activated with message dialog box like below.
4.7 Go back to the Activate and Maintain Services screen and filter with service we just created above. Choose SAP Gateway Client.
5. Test Service in Gateway Client
5.1 On SAP Gateway Client, choose Execute to view the metadata of the OData service.
5.2 Navigate to EntitySets button from the application toolbar and choose the entity set.
5.3 Choose Execute to view the data retrieved from the ABAP CDS view.
How to create OData service for ABAP CDS views using Referenced Data Source in SEGW
Hello everyone, in this blog we will discuss on how to create OData service for ABAP CDS views in SEGW based on Referenced Data Source.
In previous blog How to create OData service for ABAP CDS Views we have seen an easy approach on exposing the ABAP CDS view as an OData service using the annotation @OData.publish: true and also the restrictions/disadvantages by following the approach.
Referenced Data Source
To overcome the above restriction, we can follow this approach. Below are the features supported.
Advantages and Features Supported
- Multiple Entities i.e multiple CDS views
- Associations
- Actions using Function Imports in SEGW
- CDS View with parameters
- CDS annotations considered and derived at runtime
- CDS changes will be reflected at runtime, no need for re-activation
Prerequisites
Basic understating of ABAP CDS views, to know more click here.
Step-by-Step Procedure
1. Creating an New Project
Launch SEGW – Gateway Service Builder transaction on front-end server(FES).
Click on Create Project and provide the necessary details on Create Project dialog box.
A new SEGW project will be created with empty data model like below.
1.2. Reference Data Source
Now right-click on the Data Model choose Reference and then Data Source.
A new Reference Data Source wizard will open like below. Choose ABAP CDS view using the F4 help and hit Next.
In the next wizard step check the information and hit Finish.
ABAP CDS entity will be successfully referenced in the SEGW project and new folder Data Source References will be created under Data Model folder.
Entity types, Entity Sets and Associations will automatically created for the ABAP CDS view.
You can further explore the properties and other artifacts created.
2. Generating Model Provider Class/Data Provider Class and Other Runtime Objects
Navigate and select the project node and hit Generate Runtime Objects button to generate the SEGW OData service run-time artifacts.
On Model and Service Definition dialog box, a list of classes is shown and will be generated. You can go with default name or change them if you like to give different names and hit OK
On the Create Object Directory Entry dialog box, enter a value (e.g. $TMP) to the Package field, and then choose Save.
Now the service classes are generated.
3. Activating Service
Launch the transaction /IWFND/MAINT_SERVICE – Activate and Maintain Services.
Choose Add Service.
On Add Selected Service screen provide the value for System Alias field and then choose Enter. A list of services is then displayed.
From the list of services choose the relevant service, you can search based on your project name. Click on Add Selected Services
On Add Service dialog box specify the package name and choose Enter.
Service is successfully activated with message dialog box like below.
Go back to the Activate and Maintain Services screen and filter with service we just created above. Choose SAP Gateway Client.
4. Test Service in Gateway Client
On SAP Gateway Client, choose Execute to view the metadata of the OData service.
Navigate to EntitySets button from the application toolbar and choose the entity set.
Choose Execute to view the data retrieved from the ABAP CDS view.
Congrats..! You have successfully created an OData service for ABAP CDS view using SEGW based on SADL framework. Please stay tuned for ABAP CDS View Tutorials.
https://blogs.sap.com/2018/04/07/sap-odata-service-get-multiple-table-output/
http://blogs.sap.com/2018/03/30/sap-odata-post-multiple-table-input/
Implementing the Search Help Generator in ODATA
SEARCH HELP OPERATION MAPPING
Service Implementation via Mapping Development Flow
To start the service implementation, create an entity type and entity set based on the import of a search help. To perform service implementation, use mapping of the read and query method of the search help.
Defining the Data Model and Service Implementation
The wizard for creating an entity type based on a search help performs two steps: data model definition and service implementation. In the first screen you select the appropriate search help and select a (readable) name for the entity type (here: Country).
Select the Create Default Entity Set checkbox so that an entity set with the name <EntityName>Set (here: CountrySet) is generated.
Also select the Query and Read checkboxes so that the read and query method implementations are mapped automatically.
Defining the Data Model and Service Implementation — Wizard
In the second screen, you select the fields that should be part of the entity type and entity set. In the third step, you specify the key field(s).
Service Implementation Result
The wizard has performed the mapping for input and output. For the query method, the range tables have been mapped so that $filter is supported. For the read method, an input parameter has been mapped for the property that has been marked as a key field.
SEARCH HELP GENERATOR – $FILTER SUPPOR
As a result of the service implementation, there is out-of-the-box support for $filter, as shown in the figure Search Help Generator — $filter Support, where $filter is used in the Gateway client using the following URI:
/sap/opu/odata/SAP/ZGW100_XX_SEARCHHELP_SRV/CountrySet?$filter=Key eq ‘US’&$format=json
Implementing Function Imports
FUNCTION IMPORTS
Function imports are used to perform an action on a business object that can’t be executed by using CRUD-Q methods. An example of such an action is the release of a sales order.Releasing a sales order means not just changing a property’s status in an entity, but also starting several back-end processes. Other examples include confirming an order or performing an availability check.
If cardinality is set to 0…n or 1…n, a return entity set has to be selected. If a function import is read-only, GET should be used as the HTTP method.
If POST is used, the framework checks for a CSRF token. Therefore function imports that perform changes should use the HTTP method POST.
Function imports are defined on the service level not entity set level. As a result, you must determine the name of the function import in the service implementation .
Function Imports – Data Model Definition
You define the function import and parameters with the following data:
Define function import:
- Name
- Return Type ( Complex Type , Entity Type , No Data)
- Return Type Kind (Any entity type defined in the data model)
- Cardinality (0 … 1, 1, 0…n, 1…n)
- HTTP method (GET, POST)
Define function import parameters
- Name
- EDM Core Type
- Precision, Scale, Max
Since all function imports are handled by the single method /IWBEP/ IF_MGW_APPL_SRV_RUNTIME~EXECUTE_ACTION, you have to use a CASE statement to identify the correct one.
Function Imports – Implementation
Use io_tech_request_context to retrieve the name of the function import and the import parameters of the function import as follows:
Example:
https://www.123techguru.com/courses/sap-gateway-hub-functionalities/
Comments
Post a Comment