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 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:|
Given you reuse an entity type multiple times:
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|
|Property||Compared with a ‘column’ in relational database modeling||Yes|
Use the same rule for all properties among all Entity Types and Complex Types
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
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)
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)
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!