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 term Meaning Used in UI5 code? General Suggestion Examples:
Entity Type A type that can be reused in many Entity Sets No

Use a singular noun







Entity Set The most important part of your service. Data is retrieved via them Yes

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

No Parent Entity Type Name + [separator] + Child Entity Type Name




Association Set Link between two entity sets No Parent Entity Set Name + [separator] + Child Entity Set Name




Complex Type A type that can be reused and which don’t need to have a key No Same as Entity Type Same as Entity Type
Function Import Functionality 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 Parameter URL parameter of function imports Yes

Use nouns

lower case




Property Compared with a ‘column’ in relational database modeling Yes

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 !