2023 Aug 03 8:56 AM - edited 2023 Aug 11 3:21 PM
(Check out the SAP Developer Challenge - APIs blog post for everything you need to know about the challenge to which this task relates!)
In this task you'll become acquainted with entity sets in the classic Northwind service.
You may have heard of, or even interacted with an instance of, the Northwind model and service, originally and properly called "Northwind Traders". It has a classic and well-known set of related entities and is often a first introduction for many to database schemas, OData services and more. It was originally shipped with the Microsoft Access database application.
The entities and their relationships are easy to understand and it's partly for this reason that it's so popular. In this task, you will briefly explore the Northwind service offered by OASIS Open, the non-profit standards body, where there's a working group that looks after the Open Data Protocol (OData) standard.
There are various services available at the simple landing page at https://services.odata.org and the one we will use is the OData V4 version, which is available directly at this address:
https://services.odata.org/V4/Northwind/Northwind.svc/
Your task specifically is to list the entity sets available in this service. They should be presented as a single string, following these rules:
Here's a short example of what a list should look like:
Categories,Customers,Suppliers
There are more entity sets than just these three, this is just an example.
Once you have constructed the list, you should hash it and post the hash as a new reply to this discussion thread, as described in Task 0 - Learn to share your task results. This means that to get the hash, you would need to make a call to the hash service like this (based again on the above short example), supplying your SAP Community ID in the appropriate header too:
https://developer-challenge.cfapps.eu10.hana.ondemand.com/v1/hash(value='Categories,Customers,Suppliers')
What is an entity set? It is essentially a collection (a set) of entities. There are two places where an OData service typically details the entity sets on offer. One is the service document, available at the root of the service's base URL. And the other is the metadata document, available at the service's base URL with $metadata appended. Metadata documents contain a wealth of information for an OData service; the entity set details are included, but there's a lot of other information that is included too, information that you must exclude or otherwise ignore. Simpler perhaps would be to take the service document, which has a set of collections (this harks back to the origins of OData, incidentally) which more or less equate to entity sets.
If you request the service document (https://services.odata.org/V4/Northwind/Northwind.svc/) in your browser, you get an XML based representation in response. You can parse this XML with any XML library, or command line tool (such as xmlstarlet or xmllint.
While the service document's XML structure is much simpler than the metadata document, it's still XML, and it's arguably easier these days to avoid XML altogether when doing ad-hoc parsing activities. With OData V2 services, the service document is only available in an XML representation. It's also available in a JSON representation with OData V4 services.
Using a command line HTTP client, for example, to request the service document, we get an entirely different representation.
For example, this invocation of curl:
curl \ --url "https://services.odata.org/V4/Northwind/Northwind.svc/"
returns a JSON representation, that looks like this (redacted for brevity):
{ "@odata.context": "https://services.odata.org/V4/Northwind/Northwind.svc/$metadata", "value": [ { "name": "Categories", "kind": "EntitySet", "url": "Categories" }, { "name": "CustomerDemographics", "kind": "EntitySet", "url": "CustomerDemographics" }, { "name": "Customers", "kind": "EntitySet", "url": "Customers" }, { "name": "Employees", "kind": "EntitySet", "url": "Employees" }, { "name": "Order_Details", "kind": "EntitySet", "url": "Order_Details" } ] }
In case you're interested, the shell pipeline to produce this redacted representation was:
curl \ --silent \ --url "https://services.odata.org/V4/Northwind/Northwind.svc/" \ | jq '.value|=.[:5]'
Once you have a JSON representation of the service document, you can use your favorite language (JavaScript, TypeScript, Python, ABAP, or perhaps jq) to parse out the entity set names, and form them, in alphabetical order, into the comma-separated list that you need.
Of course, if you prefer to parse the XML representation of the service document, then by all means do that.
We get different representations of the service document resource, depending on where we make the request. In the browser, the representation comes back in XML form. Using curl on the command line, the representation is in JSON form. Why do you think that is?
2023 Aug 08 8:08 PM
2023 Aug 08 9:19 PM
2023 Aug 08 11:39 PM - edited 2023 Aug 09 12:21 AM
2023 Aug 09 3:30 AM
2023 Aug 09 8:27 AM
2023 Aug 09 8:58 AM
2023 Aug 09 9:25 AM
2023 Aug 09 9:37 AM
2023 Aug 09 10:44 AM
2023 Aug 09 11:12 AM
2023 Aug 09 12:53 PM - edited 2023 Aug 09 1:41 PM
2023 Aug 09 1:07 PM
2023 Aug 09 1:59 PM
2023 Aug 09 5:00 PM
2023 Aug 09 6:12 PM
2023 Aug 09 8:34 PM
2023 Aug 10 3:24 AM
2023 Aug 10 3:39 AM
2023 Aug 10 7:10 AM
2023 Aug 10 8:30 AM
2023 Aug 10 8:55 AM
2023 Aug 10 10:00 AM
2023 Aug 10 10:03 AM
2023 Aug 10 10:22 AM
2023 Aug 10 10:44 AM
2023 Aug 10 12:34 PM
2023 Aug 10 12:39 PM
2023 Aug 10 1:46 PM
2023 Aug 10 3:53 PM
2023 Aug 10 4:14 PM
2023 Aug 10 4:47 PM
2023 Aug 10 7:18 PM
2023 Aug 11 1:46 PM
2023 Aug 11 3:43 PM
2023 Aug 11 7:34 PM - edited 2023 Aug 11 8:03 PM
2023 Aug 11 7:38 PM
2023 Aug 11 9:43 PM - edited 2023 Aug 16 10:11 PM
2023 Aug 15 2:44 PM
2023 Aug 11 11:28 PM
2023 Aug 11 11:28 PM