Querying: $filter, $select, $expand and paging

Most API tests are reads: check that a document exists with the right values, that a list contains what it should, that a filter returns the right subset. Getting the query exactly right is a testing skill in itself, because a wrong query fails quietly: it returns 200 with the wrong data, or with only the first page.

The query options you will use daily

V4 adds richer syntax: $filter=contains(BusinessPartnerFullName,'Fleet') where V2 uses substringof('Fleet',BusinessPartnerFullName), and V4 allows options inside an expand, such as $expand=_Item($select=Product,RequestedQuantity). Whether a service supports a function or a nested option depends on the implementation, so try it in the sandbox before writing it into a test.

Literals by type

Keys, leading zeros and encoding

• Leading zeros. Many SAP keys are character fields with leading zeros. In some services the key must be sent with them; others convert. Great Lakes Fleet Services is business partner 17100001, which some interfaces show as 0017100001. Read the metadata and test both forms once.
• Quotes. String keys and literals go in single quotes; a quote inside a value is doubled.
• Encoding. Spaces, quotes and special characters must be URL-encoded. Most clients do it; hand-built URLs in scripts often do not.
• Case. Property names are case-sensitive. businesspartner is not BusinessPartner.

Paging: the quiet failure

Services may limit how many entries they return per request. When they do, the response contains a link to the next page: __next in V2 JSON, @odata.nextLink in V4. A test that counts "all open sales orders for Great Lakes" and reads only the first response is wrong as soon as the data grows. Always request a count, and follow next links until there are none.

Testing the filter itself

When the thing under test is a filter (an interface that pulls "orders changed since the last run", or a custom service with a date parameter), apply the boundary-value technique from sap-tst-201. Create or find records just before, exactly on and just after the boundary, and assert which come back. Date filters are the usual culprits: ge versus gt, time zones in V4 DateTimeOffset values, and V2 DateTime values that the backend reads as local time. A delta interface that misses records created at exactly midnight is a real and expensive defect.

$expand versus many calls

A test that needs a sales order and its items can make one call with $expand=to_Item or one call for the header and one per item. The expanded call is faster and is what Fiori apps typically do, so it also tests the path users take. Expanding several levels deep on large documents can be slow or hit service limits, though, so keep expands to what the assertions need.

Worked example: Great Lakes orders

In CMQ, Maria's regression set checks that sales order 1000457 for Great Lakes Fleet Services carries 50 pieces of CMC-ALT-100 at 240.00 USD. A precise read is GET /sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder('1000457')?$expand=to_Item&$select=SalesOrder,SoldToParty,TotalNetAmount,TransactionCurrency,to_Item/Material,to_Item/RequestedQuantity,to_Item/NetAmount. The test asserts SoldToParty 17100001, TotalNetAmount 12000.00, currency USD, one item with material CMC-ALT-100 and quantity 50. Property names come from the service metadata; verify them for your release before you rely on them.