As we have already gone through the basics of OData in Part 2 of the series, let’s focus on creating an OData service in the system itself. Let’s begin.
To create an OData service/Project, you need to go to the transaction SEGW. or /n/IWBEP/SB. The Transaction will look like below
To create a project, click on the create project button -> You will get once pop up, provide the project name and description as below. If you want to put this information in into transport then provide the package name else save in local object
once you create a project, you will get the details of the project
So an OData project is consisting of the following element
- Data Model – This comprised of Entity Type, Association, Entity Set (details can be checked in Part 1)
- Service Implementation –Once the Data Model is created then you can create the business logic either via ABAP code or through Mapping. This can be done under this section
- Runtime Artifacts – This will contain the list of ABAP objects created in the system associate with this project
- Service Maintenance –In this section, you get the detail about the service registration like status, RFC destination, etc.
Let’s create a data model first – there are a couple of ways to create an entity type and entity set, You can create an entity type and entity set manually by adding individual fields and its properties/attributes
The other way is to import it from different sources like DDIC, Search helps, etc
I will go with the approach importing from the DDIC structure, we will check other approaches in due course.
Then select the list of fields you want to import
Then modify the entity type properties if required and set the key field. In this case, I have taken the custom structure of sales order header information, hence I have selected the key field as the order number
once you finish the wizard, we will see both entity type and set are created in the project. Now to click on the generate button
Upon generation -> it will ask for names for the Runtime artifacts
Let’s talk about different runtime artifacts. ending with
- DPC – DPC stands for data provider class – It holds all standard logic to perform or handle the request/response. It is generated by SAP standard. Don’t touch this class as this class will be regenerated/reconstructed every time you generate the project.
- DPC_EXT – This is the extension of class DPC. All the business logic will go over here. As a developer, you will spend most of the time 😉
- MPC – MPC stands for Model provider class. It holds all the structure information. like types, table types, etc. similar to DPC this was also generated by standard SAP, hence don’t touch the class as this will generate/recreate each time you generate the project.
- MPC_EXT- This is an extension of MPC class when you can define your custom types and also used for changing the runtime information of the Data model.
Apart from these four classes, there is a technical service name(ending with SRV) and model(MDL) name generated which is used for service registration purposes.
We will discuss more details about artifacts in due course.
Next Part:Get Operation in OData Service – Part 4 – ABAP Skill
Previous Part:Deployment Options in SAP Gateway – Part 2 – ABAP Skill
Reference: https://help.sap.com/doc/saphelp_grcac101/10.1/en-US/70/3f8a89729a437e9b263d1d5129b89d/frameset.htm
2 Comments
Deployment Options in SAP Gateway – Part 2 - ABAP Skill · July 10, 2021 at 4:52 pm
[…] Next Blog: https://abapskill.com/odata/odata-service-creation-in-sap/ […]
Get Operation in OData Service – Part 4 - ABAP Skill · July 11, 2021 at 12:38 pm
[…] Part 3, different artifacts in OData service are covered. In this part, we will check the implementation […]