I should briefly mention that OData service is a protocol that enables data exchange between SAP and the outside world as you know. SAP now makes almost all web-based communication over this great protocol. The services that Fiori applications use are also oData services.

In the services previously developed by SAP consultants, such as soap web services, the intervention of the developer to the service is at a very low level, while the situation is a little different in the oData service and there are many issues that the developer should pay attention to.

Recently, as far as I can see, some of my friends who are SAP consultants are making improvements (in my opinion, this should be the case) with hearsay methods or intuitive methods when creating an oData service. In doing so, they can make serious mistakes.

I would like to contribute to raising awareness by sharing the 10 most serious mistakes that I have meet.

1. Being ignorant of the SEGW transaction code

SAP has designed a very nice interface for developers to create an oData service and has presented it to us with the SEGW transaction code. We have some colleague who are unaware of this situation and they create a service over SICF and return data in json format with this service, and they think are creating ODATA service.

1. Developing OData service on front end

In general, the Fiori (frontend) system and the ERP (backend) system are installed on different machines. In this case, oData services should be created in the backend system, not in the Fiori system. There can be some exceptions. If you ask what are these exceptions, for example, the ERP system is so old that the package containing the SEGW transaction code cannot be installed on the system, even if it is installed, it remains at a very old level, but you need a latest version of SEGW, that is, a latest model oData service.

1. Using the SEGW tcode as a decoration

Unfortunately, we also have colleague who use the SEGW transaction code only to create the “entities” of the service and write everything else manually with ABAP code. As I mentioned in first paragraph, SAP has provided us with a very nice oData service creation interface. In this interface, we can map the create, update, delete, getEntity, getEntitySet methods to call RFCs directly, and then the code is automatically generated by this interface.

1. Being unaware of “Function import” feature

Using the “update” method instead of the “create” method and using the “create” method instead of the “update” method are among the mistakes I frequently meet. The “create” method should be used to create a data that does not exist, and the “update” method should be used to update the fields of an existing data. There is also the mistake of using the “update” method, which I often see. Although no field of the data has changed, a field called approval is added to the data, and this field is filled in and approval/rejection is performed. However, SAP offers us the structure we call “function import” for this. For this, 2 different “function imports” should be created and their names should be like “ConfirmOrder”, “RejectOrder”.

1. Error message managing is not correctly

Some of our colleagues make the results of the “update”, “create” and “delete” methods with the “message” field they add to the “entity”. But in which BAPI have you seen the result return like this?

The correct method for this job should be to add a “table” or “export” parameter of “bapiret2” type to the called function and add this parameter as log on the mapping screen.

1. Not understanding the difference between “batch” and “create deep entity”

The “Batch” operation should be used when saving data in block. However, if there is a connection between these data and one cannot exist without the other, this data should be saved in the “create deep entity” method. For example, if block approval is desired, the “batch” operation should be used, and if it is desired to save data with a title-item relationship, the “create deep entity” method should be used.

1. Filling the “search help” entity with code

Writing a separate function for each “search help” is unfortunately one of the mistakes made. Actually, SEGW operation code can import “search help” in a few steps, it can create “entity” and match this “entity”.

1. Changing non „ext“ class

SEGW tcode generates 4 main classes. We can change 2 of these classes with the extension “ext”. However, some of our friends, who are not satisfied with this, write code inside the regenerated classes every time and leave this code there like a time bomb. Whenever another consultant reproduces the service, that code disappears from there.

1. Doing “repairs” in standard class

Our some colleagues who “debug” the oData service for the first time in their lives find the error in standard classes and “repair” these classes. While self-confidence is a beautiful thing, too much of it harms us all. It is best to look for the fault in ourselves first J

1. Creating a “vulnerability” or „security bug“

Maybe I should have written this article at the beginning, but I left it to the end. One of the issues that I pay the most attention to is minimizing the security vulnerability.

One of the mistakes I frequently encounter is not checking whether the person calling the service has the authority to see the data returned from the service and whether the person who wants to update the data is authorized to do this.

For example, an “entity” has a key field called “id” and this numeric “id” field is incremented by 1 by 1. The details of the data are retrieved by sending the “id” to the service. A cleaver user also pressed f12 and saw the address of the called service. Then incrementing the “id” value by 1, it called the url and saw all the information it wasn’t supposed to see. If this situation is not desired, authorization control must be done in the “backend” system.

If you have any subject you would like to add or correct, I would be happy to hear.