Skip to Content
Author's profile photo Krishna Kishor Kammaje

OData Model Naming Conventions

Hi Friends,

I thought of sharing the naming conventions I follow to improve the readability of my OData service for UI developers and other consumers.

General rules for all artefacts No “ALL CAPS”
Use Camel case
No Underscores
Use English Names
No SAP technical names
Entity Names Only Nouns
Only Singulars
Not to contain operation names
🙂 examples SalesOrderHeader, SalesOrderItem, Address, CostCenter
😥 examples: SALES_ORDER, PO_CREATE, Orders, CostCenterF4, Bukrs, PurchaseOrderList
Complex Type Whenever you have too many fields in your entity, improve the readability of your Entity by grouping fields into Complex Types
🙂 examples

Complex Type “Address” for complex properties “DeliveryAddress”, “PostalAddress”

Complex Type “CompensationDetail” for complex properties “OldCompDetail”, “NewCompDetail”

Entity Sets Plural of Entity name. Or add ‘Set’ at the end of Entity name
🙂 examples: SalesOrderHeaders, SalesOrderItems, Addresses, CostCenters, Currencies, CurrencySet
Navigations Same as Entity name if the target cardinality is 1
Same as EntitySet name if the target cardinality is M

Consider two self explanatory, related entities, SalesOrderHeader and SalesOrderItem. Consider the navigation between them named as “SalesOrderItems”. Now, to navigate from header to item, we canuse a self explanatory URL as below.


If you had named the Navigation as say “Header_Item”, then you would have called URL


which is not at all consumer friendly.

Function Imports Name should clearly Indicate the operation getting performed
🙂 examples: ReleasePO, ApproveLeave, BlockSalesOrder, GetReleaseStatus

Let me know your views and if you follow any other best practices.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Munagala Uday
      Munagala Uday

      krishna, It looks perfect and meaningful naming conventions for any developer to understand.