In the Part I post Introduction to SAP Netweaver Gateway and OData, we learned about the definition, terminologies and concept of SAP Netweaver Gateway, OData and HTTPs. Now we have a fair idea of the RESTful and STATEless concept. In this article, we will do a hands-on exercise and generate our first OData Service in SAP and play around with the different URIs of the service. These URIs are the endpoints of Server side of OData which the outside world (Client side) would need to call using HTTP(s) in order to update/extract data to/from SAP. In SAPUI5 applications, we need to consume these URIs to connect to SAP and play with its data. We will re-define the standard methods and add our custom ABAP logic to meet our requirements.
A. Define Data Model
Go to t-code SEGW (SAP Gateway Service Builder). Remember it like SE38. Instead of 38, add GW for GateWay. So our friendly t-code for today’s topic is SEGW. Hit the Create Icon and provide the name of the Project, description and package (or local) and save it.
The project gets created with four folders, namely Data Model, Service Implementation, Runtime Artifacts and Service Maintenance. Please take note that Data Model further has three sub-folders viz Entity Types, Associations and Entity Sets. All the folders are empty by default.
Before you ask yourself, what is Entity Types and Entity Sets, let me answer it quickly. After all, SAPSPOT is here to hand hold you and help you cross this SAP Gateway learning curve smoothly.
Entity Type is our very own structure (or a work area (holds just one row)). And you guessed it right, Entity Set is an internal table (holds more than one entity/rows). ABAPers, are you gaining confidence? You just learned two new terms.
Let us create our first structure; oops!! work area; oops Entity Type (right term in Gateway terminology).
Right click on Entity Types folder and select “Create”, provide the name you like and do not forget to tick the checkbox “Create Related Entity Set”. For our example, POHeader is the structure(work area) while POHeaderSet is our internal table.
Check the Service Implementation folder has POHeaderSet Operations auto generated. These are ABAP Methods which would be triggered when the relevant endpoints would be called.
Now we need to define the fields of the structure/work area and internal table.
Doble click on the Properties folder, hit the create icon and then start adding the field names and the type and length. In the example, we have added Ebeln and Bukrs. So on and so forth, we need to build our Entity Type.
Doesn’t it look too tiresome to add one field at a time in the Entity Type? There has to be a better way. The above steps are just to let you know such thing exists. In real projects, you would like to use the below method. Delete the POHeader Entity Type and POHeaderSet Entity Set by right clicking and hitting delete.
Let us create them again.
Right click on the Data Model folder and Import the DDIC Structure. Give the Entity Type name and ABAP structure whose fields you want to import to your Entity Type. Do not forget to click the checkbox for Entity Set (unless you are sure you will not need an internal table).
Hit Next and choose the fields from EKKO (our example) structures which you want to add to your Entity Type.
Next, choose the Key for your structure/entity type and entity set. For our example it is Ebeln.
After you hit finish hit the save button and check the Properties and Service Implementation folder. They would have the structure and operations respectively.
At this point, let us import one more Entity Type called POItem from EKPO using the steps just mentioned above.
From the above image, it is clear that every Entity Types will have its own Properties and Navigation Properties Folder. And every Service Implementation Entity Set will have its own Operations (Create, GetEntity, Update, Delete etc).
As of now, we have a Header Table and an Item/Detail Table. Let us assume we do not need any more Entity Types.
B. Implement/Register the Service
Let us go ahead and generate and register our service.
Hit the Generate icon and hit ok. Provide the package and transport number or save it as local. You should get the success message as shown below.
Please note the Technical Service Name is the actual Service which the external system needs to call. Two classes, Model Provider Class (MPC) and Data Provider Class (DPC) are also generated along with Base and Extended Class.
Model Provider Class inherits from /IWBEP/CL_MGW_ABS_MODEL and Data Provider Class inherits from /IWBEP/CL_MGW_ABS_DATA. The below image shows the relationship between the generated classes and their superclasses (parents).
FYI: Data Provider Class provides the Gateway Service functionalities. Model Provider Class defines the Gateway Service interface. DPC and MPC are not connected by any coding. They talk to each other via Configuration.
C. Add Service to Service Catalog (Register the Service to Gateway Hub)
We have implemented the Service, now we need to add the service to the Service Catalog.
Most of the tutorial present on the internet shows that the Service Maintenance folder would have an entry with System details and the Register/Maintain buttons are active (as in above image). If you see an entry in Service Maintenace folder, it means your system has “Embedded Deployment“.
SAP Netweaver gateway components are installed as add-ons on the SAP backend system itself in the Embedded Deployment option. Both the OData modeling and the exposing of the Services to the outer world is done from the backend system.
The advantage of Embedded Deployment Strategy:
i. Saves cost as there is no need of any dedicated Gateway Hub
ii. It is faster as the runtime overhead due to remote calls in case of two separate systems (separate front end and back end) is avoided
Disadvantages of Embedded Deployment Strategy:
i. There is no single point connection to the backend via Gateway Hub; instead, back end system is directly exposed to the outer world (consumers), so better security measures need to be in place
ii. Back end system upgrade would follow a different cycle than Netweaver Gateway
iii. If the landscape has multiple SAP Business Suite backend, then each system needs to have its own installation and configuration of Netweaver Gateway components.
If you have Embedded System, hit the Register and Maintain buttons and you are good.
The above image is not from our sap system. Our system does not show any entry in Service Maintenance folder. Our architecture is “Hub Deployment with Development in the Backend System“. In this strategy, the SAP Netweaver Gateway is installed on separate SAP machine called as Gateway Hub. Gateway Hub would be the window for the outer world to SAP. Gateway Hub would register and expose the OData Services, but the development would still happen in the SAP backend system.
The advantage of Hub Deployment with Development in the Backend System Strategy:
i. Better security as it has only one point of access to SAP Backend system for outer space via Gateway Hub
ii. Although Gateway components are in different SAP system, it still has direct access to Backend DDIC and business data for OData Model/Services
iii. Gateway Hub can be in advanced newer version NW 7.3/7.4 or up while Backend still can be in the lower release. Gateway on new release would support SAPUI5.
Disadvantage: More cost and maintenance effort along with the runtime overhead due to remote calls.
Coming back to our screen. We are in our Backend system, therefore by default, we do not get the option to maintain and register our service in our backend system. We need to go to our front end system where we have the Netweaver Gateway i.e. our Gateway Hub.
Go to your Gateway Hub (Front-end system) and execute t-code /n/IWFND/MAINT_SERVICE. Save this t-code in your favorite list or remember it by heart. ? You will need it for all your OData services.
Our service is still not added to the Service Catalog. After we add the service to the Service Catalog, only then is our service available for the outer world to access.
Hit the Add Service button, provide your backend system alias and external service name (our case ZGW_PO_SRV). You will get the service you created in the backend. Click on it and it would show the Service (technical/external) name along with the Technical name of the Model (ZGW_PO_MDL) and hit save. Go back to the Service Catalog screen.
Find your service, click on it. It would show up in System Aliases window at the lower right corner. Let us test it using SAP Gateway Client. Or use t-code /IWFND/GW_CLIENT (remember this t-code as well). You can also test by Call Browser option. For now, we will use SAP Gateway Client option.
OOPs!! You get this error. Status 403, Forbidden with the message “No authorization to access Service”. Let us check the Authorization Object issue in t-code SU53 and ask your SAP Security Team to provide you access to this authorization.
Just in case your security team asks what has to be done. The below screenshot might help him.
Where did the ZGW_PO_SRV_0001 come from? The below screen might help.
Assuming your authorization is in place. Let us try t-code /n/IWFND/MAINT_SERVICE, select the service and hit SAP Gateway Client or directly use t-code /n/IWFND/GW_CLIENT. Hit the Execute button. This time the status code is 200 i.e success.
Congratulations!! You just created, maintained and activated your first OData Service.
In the above image, our URI (/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml) has format XML. Let us change it to JSON (/sap/opu/odata/sap/ZGW_PO_SRV/?$format=json). Both xml and json informs that they have two Entity Sets.
Please note: The word json is case sensitive. Give lower case “json”.
Now let us check the metadata of the OData. In layman’s term metadata means the structure and properties or full skeleton (X-Ray view).
It shows the Entity Type (work area/structure) Names. In our OData, we have two (POHeader and POItem). It also shows the Entity Set (Internal tables) Names which are also two for our case (POHeaderSet and POItemSet). At the bottom of the page, you would see a link. That is the link which opens your service in Web Browser. Copy the link and paste it in your browser (you need to give your SAP Front End credentials).
If you were a non-sap web developer who would need to consume this SAP OData service and you just have the service name and URI. You would be interested in knowing the details of the structures so that you can make use of it in your non-sap application. The first thing you would do is use ?$format to check the details.
Below is two popular way to check the format.
- ?$format = json
http://txaixegd01.sapspot.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=json - ?$format=xml
http://txaixegd01.sapspot.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml
How can ABAPers find the error of OData service if any?
In case you enter something incorrect in the URI or your URI is not working, you will get the message “Run transaction /IWFND/ERROR_LOG on SAP Gateway hub system” to find the issue.
T-code /n/IWFND/ERROR_LOG would be an ABAPers friend for stormy weather. Check the message for the URI.
For the above error, a “?” is missing in front of “$”.
wrong: http://txaixegd01.sapspot.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/$format=xml
right: http://txaixegd01.sapspot.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/?$format=xml
Check the /n/IWFND/ERROR_LOG screen.
Now let us check if we can pull some data for POHeaderSet.
Enter URI http://txaixegd01.sapsapot.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet in your browser or /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet in your SAP t-code /IWFND/GW_CLIENT.
OOPs, we get the error, Not Implemented. Method ‘POHEADERSET_GET_ENTITYSET‘ not implemented in data provider class.
In our backend system, in t-code SEGW, we created the Entity Types/Set and activated the service and registered it. The MPC and DPC were generated. But the DPC methods were not re-defined. We need to write our ABAP code and logic to pull data from the backend system and populate the Entity Set (internal table). Once the entity set is populated, we can see the output in our OData service call.
Let us just re-define the method and write no code. What do you expect the OData service to return (give output)?
Go to change mode in the DPC Extension class and not in Base class (we work in the extension class since we are enhancing the inherited class).
Put the cursor the method you want to re-define. Hit the re-define method icon and hit enter. Some auto generated code would show up.
We would learn about all the importing and exporting parameters of the methods in next article. For now save as it is and activate the class. Check the folder Redefinition has the method ‘POHEADERSET_GET_ENTITYSET’ listed. This means our method is successfully re-defined.
Let us check the output. Go to t-code /n/IWFND/MAINT_SERVICE or /n/IWFND/GW_CLIENT and give the URI: /sap/opu/odata/sap/ZGW_PO_SRV/POHeaderSet
This time we do not get any error. The status code is 200 and it is OK. But, the body has no data yet. Quite obviously, we did not write any logic to populate the internal table (entityset).
Now, let us write one small statement to pull 10 entries from Purchase Order table EKKO in the method and activate it.
METHOD poheaderset_get_entityset.
SELECT * UP TO 10 ROWS FROM ekko INTO CORRESPONDING FIELDS OF TABLE et_entityset.
ENDMETHOD.
Now, let us check the output again.
10 entries are returned. If you expand the entries, you would see the details of each row.
Now, we can see the same output in the browser as well.
Let us stop here for today. In the next post, we will implement all the other methods and manipulate the URIs to meet our requirement. We would show you how Association and Navigation links can be created to flow/pull/push data to and from different Entity (i.e. Navigation and Association between data models). The next article will be more hands on with lots of code and tips. So, please stay tuned.
i. Hub Deployment with Development in the Gateway Hub
There is a third Deployment Strategy, in addition to the two mentioned above, for SAP Netweaver Gateway. It is “Hub Deployment with Development in the Gateway Hub“. The Gateway component need not be installed in the backend system as all the development related to SAP Netweaver Gateway takes place in the Gateway Hub. If we don’t want to do any kind of developments in the backend system and leverage the standard/custom what is already existing in the system, this might be the strategy.
Disadvantages of Hub Deployment with Development in the Gateway Hub:
i. No access to backend data dictionary objects directly. Only the existing BAPIs and RFCs can be the data source for OData Service development
iii. Additional cost and maintenance effort as compared an embedded deployment option with just one system.
ii. How is the URL for OData Service determined for the Web Browser?
In this post, we have used t-code /IWFND/MAINT_SERVICE and execute SAP Gateway Client (or directly from t-code /IWFND/GW_CLIENT) to test our OData Service in SAP screen. We also saw that we can call the URL in web browser and test it as were doing in SAP Gateway Client. But, how actually is the URL created for Web Browser?
Ans: The actual URL for OData in Web Browser consists of: http(s)://:/(rest is from the relevant ICF path).
Now another question arises, how do we know the Hostname, Service (Port Number) and ICF path of our SAP system?
Ans: Go to t-code SICF. Execute it with default values. Menu Goto->Port Information. The pop-up window would have the Hostname and the Service name (Port Number) for the system.
In order to find the default ICF path, provide the service name in the t-code SICF and execute it. Expand the roots till you reach the service name. For our example the ICF path is sap->opu->odata->sap->zgw_po_srv.
Now concatenate the http, Hostname, Service(Port Number) and ICF path. For our example, it would be http://txaixegd01.retail.sapspot.com:8000/sap/opu/odata/sap/ZGW_PO_SRV/. So next time if someone asks you what is the Hostname and Port of your system, you know how to find it.
