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 03 9:39 AM
2023 Aug 03 9:47 AM
2023 Aug 03 9:56 AM - edited 2023 Aug 03 9:57 AM
2023 Aug 03 11:26 AM
2023 Aug 03 11:57 AM
2023 Aug 03 12:02 PM
2023 Aug 03 12:04 PM - edited 2023 Aug 03 4:07 PM
2023 Aug 03 12:41 PM
you might want to check again through the precise instructions in Task 0 regarding posting a reply with your hash, @cguttikonda24 🙂
2023 Aug 03 1:07 PM - edited 2023 Aug 03 4:04 PM
Hello DJ @qmacro
What did I missing in generating the hash as per the Task-0.
Used the same endpoint with the value of all entities in alphabetical order and passed the community id as a header.
2023 Aug 03 1:30 PM
Your CommunityId is public (cguttikonda24), you don't have to obscure it, but the entities you should 😉
2023 Aug 03 1:37 PM
2023 Aug 03 3:35 PM
2023 Aug 03 3:34 PM
2023 Aug 03 4:07 PM
2023 Aug 03 12:18 PM
2023 Aug 03 12:35 PM
2023 Aug 03 12:42 PM
2023 Aug 03 12:45 PM
For those that have posted hashes already ( @ajmaradiaga @tobiasz_h @VenugopalA @SandipAgarwalla @UweFetzer_se38 @Eurey @emiliocampo ) ... and anyone, really ... what are your thoughts on the question in the "For discussion" section? Any guesses or ideas why?
2023 Aug 03 12:55 PM
2023 Aug 03 1:04 PM
2023 Aug 03 2:15 PM
I agree with @UweFetzer_se38... when using a browser, e.g. Firefox, it will send the following header - Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8. curl sends by default Accept: */*. You can see this when specifying the --verbose option, e.g. curl --verbose "https://services.odata.org/V4/Northwind/Northwind.svc/"
2023 Aug 03 3:55 PM
Yep, as you, @tobiasz_h and @ajmaradiaga have mentioned, it's all down to content negotiation. See this post (wow, that I wrote 20 years ago now) https://qmacro.org/blog/posts/2003/02/28/'conneg'-and-the-duality-of-weblogs./ for some background.
2023 Aug 04 4:19 AM - edited 2023 Aug 04 4:52 AM
Thanks DJ for sharing another great blog.
In my case, I use Google's chrome browser, there is application/xml in the default rule of Accept attribute in the request header that why I got the XML content back.
btw, I completed this task via terminal, jq and Linux commands. That was so much fun indeed.
2023 Aug 04 6:53 AM
2023 Aug 03 1:14 PM
2023 Aug 03 1:24 PM
2023 Aug 03 2:26 PM
2023 Aug 03 2:56 PM
2023 Aug 03 3:01 PM
2023 Aug 03 4:08 PM - edited 2023 Aug 17 2:11 PM
2023 Aug 03 4:13 PM
2023 Aug 03 4:41 PM
If you want to solve this (and maybe one of the coming) tasks with ABAP, this blog post may help you: Ho To: Migrating from zjson to /ui2/cl_json
2023 Aug 03 5:57 PM
2023 Aug 03 6:13 PM
2023 Aug 03 6:23 PM
2023 Aug 03 6:27 PM
2023 Aug 03 7:29 PM
2023 Aug 04 6:56 AM - edited 2023 Aug 04 6:56 AM
If anyone is interested my Python solutions are available here: https://github.com/ceedee666/sap-dev-challenge-apis-in-python
2023 Aug 04 7:24 AM