This post describes the importance of having some kind of name convention when creating an oData service, specially in SAP Gateway. All conventions suggested here are based on my personal thoughts.

Have you ever worked with oData services which had bad or no naming convention at all? This is usually an indication that the back end implementation was done with the same level of care.

So, I would like to share what I believe is a good naming convention for every piece of a oData Service created using SAP Gateway.

oData Terms

oData termMeaningUsed in UI5 code?General SuggestionExamples:
Entity TypeA type that can be reused in many Entity SetsNo

Use a singular noun







Entity SetThe most important part of your service. Data is retrieved via themYes

Use a plural noun


Given you have a single entity set for a given entity type:

  • Materials
  • SalesDocuments
  • SalesDocumentItems

Given you reuse an entity type multiple times:

  • Employees / Contractors (Entity type Employee)
  • FinishedGoods / RawMaterial (Entity type Material)

Link between two entity types

Contain details about cardinality

NoParent Entity Type Name + [separator] + Child Entity Type Name




Association SetLink between two entity setsNoParent Entity Set Name + [separator] + Child Entity Set Name




Complex TypeA type that can be reused and which don’t need to have a keyNoSame as Entity TypeSame as Entity Type
Function ImportFunctionality which cannot be catagorized using CRUD-Q as Entity Sets.Yes

Use verbs at the beginning (as usually happens in SOAP services).

Make it a sentense




Function Import ParameterURL parameter of function importsYes

Use nouns

lower case




PropertyCompared with a ‘column’ in relational database modelingYes

Use the same rule for all properties among all Entity Types and Complex Types





  • Id
  • Name
  • CompanyName
  • CostCenterGroupId
  • CostCenterGroudName


  • Bukrs
  • Werks
  • Uname
  • Vbeln
Navigation Property

Compared with a ‘foreign key’ in relational database modeling

Are linked with Associations


Use a prefix (i.e. To) to distinguish them from regular properties.

Use singular noun when linked with an association which has a 1:1 relationship

Use plural noun when linked with an association which has a 1:n relationship

ToFullName (1:1)

ToCustomer (1:1)

ToCustomers (1:n)

ToItems (1:n)



1) Project Name

Make it as short as possible. Up to 13 characteres if you want to have your gateway project with the same name of your UI5 app (BSP). If not, make it short enough so that DPC and MPC classes have names matching SEGW project (30 characteres considering prefix ZCL and suffix _DPC_EXT)

2) Description

Give the same name of the Fiori App (if your project is for Fiori) which will consume this service. (by the way, do not reuse the same oData service among manu apps).

3) Service Generation

When using function modules inside your project to use what is called service generation, name your function module with the exact entity and operation which will be mapped inside SEGW >> Service Implementation. Examples are:

  • Z_MYAPP_CUSTOMERS_Q (Query on Customers EntitySet)
  • Z_MYAPP_CUSTOMERS_R (Read on Customers EntitySet)
  • Z_MYAPP_SALES_ORDERS_C (Create on SalesOrders EntitySet)
  • Z_MYAPP_SALES_ORDERS_U (Update on SalesOrders EntitySet)
  • Z_MYAPP_SALES_ORDERS_D (Delete on SalesOrders EntitySet)

Gateway Configuration

System alias

Do not use the system ID to give your system alias a name. The only purpose of the system alias is rename the RFC destination so your DEV/QAS/PRD environments have all the same routing configuration.

Use names like: “ECC” , “S4”, “CRM” or “SOLMAN”

What does help you?

I hope your liked such conventions. Do you already use any? Please share your opinion below!

New NetWeaver Information at

Very Helpfull

User Rating: Be the first one !