OData V4: New JSON Format – Sample Payload 2.0 vs. 4.0

The main paradigm in OData V4 is the reduction of data. Reduction is achieved through a more powerful query language and a new optimized JSON protocol. At the same time, richer metadata can be leveraged.

 

When comparing the payload of a request that retrieves product details, we can see that even the JSON response in V2 contains lots of metadata, while in the V4 response, the metadata has been reduced to one single property and the rest of the data is simple name/value pairs.

 

 

Cross-Service References

With the support of cross-service navigation, several requirements of SAP Fiori like applications can be addressed.

1. The rich metadata can be leveraged; but at the same time, the complete data model does not have to be loaded at startup time of an application. There is the option to have a lazy loading of parts of a service model on demand.
2. Services can be reused more easily because services can be partitioned without the loss of navigation.

Examples of such services that can be reused in various SAP Fiori applications are Users, Attachments, Conditions, and Addresses.

 

 

Cross-service navigation enables inter-communication of services. Navigation properties of entities of one service can reach entities of another service in a service group.

 

Support for Any and All

/sap/opu/odata4/sap/sepm_odata_ref/sadl/sap/sepm_odata_c_salesorder/0001/SEPM_OData_C_SalesOrder?$filter=_Item/any(AnODataIdentifier:AnODataIdentifier/Product eq 'HT-1007')

 

 

{
"@odata.context" : "$metadata#SEPM_OData_C_SalesOrder",
"value" : [
{
"SalesOrder" : "500000250",
"ChangedBy" : "EPM_DEMO",
"CompanyName" : "SAP",
"CreatedAt" : "2017-07-28T22:00:00Z",
"CreatedBy" : "EPM_DEMO",
"Currency" : "EUR",
"Customer" : "100000000",
"TotalGrossAmount" : 26339.78,
"LastChanged" : "2017-08-04T22:00:00Z",
"OverallStatus" : "D"
},
{
"SalesOrder" : "500000310",
"ChangedBy" : "EPM_DEMO",
"CompanyName" : "SAP",
"CreatedAt" : "2017-07-28T22:00:00Z",
"CreatedBy" : "EPM_DEMO",
"Currency" : "EUR",
"Customer" : "100000000",
"TotalGrossAmount" : 26339.78,
"LastChanged" : "2017-08-04T22:00:00Z",
"OverallStatus" : "D"
},
{
"SalesOrder" : "500000250",
"ItemPosition" : "40",
"Product" : "HT-1003",
"GrossAmount" : 3927.00,
"Currency" : "EUR"
},
{
"SalesOrder" : "500000250",
"ItemPosition" : "50",
"Product" : "HT-1007",
"GrossAmount" : 1067.43,
"Currency" : "USD"
},
{
"SalesOrder" : "500000250",
"ItemPosition" : "60",
"Product" : "HT-1010",
"GrossAmount" : 4757.62,
"Currency" : "EUR"
},

 

 

OData V4: Query Options on Expanded Items

$expand is used to retrieve several entities that are connected through navigation properties in one request/response cycle. When using $expand, you actually follow the navigation properties of an OData service.

 

In our example, $expand would be used to either retrieve all sales orders of a business partner or all items of a sales order or, as a third use case, all sales orders including all their items of several business partners (or all sales order items of all sales orders of all business partners, if you want to stress the system).

 

 

With OData V4, it is now possible to filter the result set of an expanded entity set on each level. In the example shown in the figure, OData V4: Query Options on Expanded Items, we can first filter on the business partners, only retrieving those business partners that are located in Walldorf.

 

We then only retrieve the sales orders where the gross amount exceeds a certain threshold. We are now finally able to use an additional filter on the sales order item level to retrieve only those items that contain a certain product.

 

/BusinessPartnerList?$filter=Address/City eq 'Walldorf'&

 

$expand=BP_2_SO($filter=GrossAmount ge 1100;

 

$expand=SO_2_SOITEM($filter=Product/ProductID eq 'HT-1041')

 

OData V4: Aggregation: Simple Composable Query Language

Let's have a look at an analytical scenario as shown in the figure. Data will be retrieved from a list of sales orders.