In case you’ve missed our dev tips in past weeks, we will be posting them in the blog moving forward. To sign up and get your dev tips delivered to your inbox each week, click here!
Tip of the Week
Use descriptive property names in OData entities. This will make your service self-documenting and much clearer for consuming applications. An example is naming your property “SalesOrderNumber” rather than “VBELN”.
| When I first started in the SAP development world many years ago, my mentor told me that when the table and field names started making sense, I could consider myself a “real” ABAPer. If you’re reading this, you likely agree! That being said, the SAP development world has changed, and we now find ourselves writing Gateway services for developers who have never logged into SAP. We can easily eliminate the learning curve for our front-end developer brethren by using better property (field) names in our OData entities.
Which of these is easier to understand to a non-SAP person? Both return the same data.
Option 1: SAP Table and Field Names Used |
|
| Option 2: Descriptive Names Used |
|
Option 2 is definitely the winner. There are multiple advantages to using this strategy.
- Your service is self-documenting. If a developer sees the entity SalesOrderHeader and property CreatedByName, there is little doubt on what information will be returned.
- Front-end programs become self-documenting, in terms of the data shown.
- It is kind to the developer who changes the service after you. Descriptive names are like program comments – they let the next person know the intent of each entity and property.
|
|
If you have an interest in viewing similar content, visit our blog, here.
View our LinkedIn, here.
