SAP Developer Challenge - APIs - Task 1 - List the Northwind entity sets

[qmacro]

(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.

Background

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

Your task specifically is to list the entity sets available in this service. They should be presented as a single string, following these rules:

• the entity set names should be exactly as specified in the service
• you should keep whatever case the entity set names are written in
• the entity sets should be listed in alphabetical order
• they should be comma-separated, with no spaces

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')

Hints and tips

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.

For discussion

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?

[devrajsinghr]

dc2d24d5327a63dcdab286246006bfb2d89ad18378093ec356d694ddb3e68dbe

I am assuming my community id is my user name - devrajsingh (Initially I used my sap user id which was Pxxxxxx)

[qmacro]

Great that you're catching up, kudos! But double check the instructions on how to reply with your hash 🙂

[Cmdd]

93433ca3b7a90aaf60dd7be5b712cbe91d10d6500636e8694c3f0e4fdc2c6559

[naveen1241]

26f9e7aeb6f5398e00c5e9da610d9a12ebb522089ea98ed4ab253987275281f9

[jagadish]

a9e458284230bf4c71bf5dc17aac2a6d9459792464faac36b736aea0f552e240

[bugsanderrrors]

e6b68de037e9eda0ea9ab516a21974bf77cb7fc0017ff946176ac55aae121e56

[Flavio]

d6d7903a27ac1086a468b9fb954cce7873a79c5f27d3a47fb0cced3f122d041e

[andrew_chiam]

29115899c32af99454ef408a903237dbd9d95b0f8223e5fd22a85c0593cc1e5c

[Nidhi]

e0e4ae9542901372c3cdd30c0eeb5f2155312908aa94fb0454b436dae7175cbc

[adrian-ngo]

473d525eb74d0fd4934fc41b0c7580cb747cf3e35404deb8e1fbb63fc66b48de

[OlgenH]

35cf6f0fc98cc925ecd14860dbcfbd898026af783018fc55ecd88d4f0a510ad0

[kunalsahi85]

d553c40e17c5a6b0d2dbbb0d403132808a2d6ace5457e179c2a6f47d6842cd7e

[p330068]

6b129571c79d00cb1ee77d09444bbf4ab0afb067d1209d39b29f84537aaf4a55

[Jagtar]

63d01b810078e12bda07dd7d19f6fd4b28bcd6dd22023a665d05b6084c146edb

[Jagtar]

The different representations is because it have option in json and xml as return . Why multiple option is because may be few few application need in xml or json and other reason may be few people are comfortable in json and other in xml

[qmacro]

Hey @Jagtar . While what you say is true, that's not the reason why specific representations are returned here in different contexts. Some of the other participants have given their thoughts on this too in this thread.

[JJAIMES]

b1ef24140520b6b951a78ed2461d315a53b5821b29142be0b3b0839e5f99330e

[FabienHenique]

7b025f40dc99e979760b2bab8a8f6387d540e48ad8a5fd1585f2f478df766584

[sainithesh21]

4220d943bdc718f93db4e559ee85d068ebefe3e43bcef503fba5b3669131e03c

[priyankaG]

8fcc5decf11fe37f3ab7f5dc8763e8571d447dd96891fd6e81b3e8563388f40e

[ALEJONO]

c1503d5aa9e44b3740410588df46670bbd2a8f1d2f7b14d0595c20702ac46a78

[qmacro]

Hey everyone! The challenge to which this task belongs is now officially closed. Head over to the original blog post SAP Developer Challenge – APIs to check out the closing info and final statistics, and to see your name in lights! 🎉  And we thank you all for participating, you made this challenge great!

[r5luga]

5300ec90e2dbdc39dafc889c74ca60216554a83b6cecdc8f9eb4e845ace98183

[buz]

72f4c26b78f16ff05e5e2b5e93ec7304479c912b23aa99733705099d090e7c5b

[gsanroman]

4cd5162ff1b71777fdd94b9c42567878a63864fd4c0d0fcadf54a49d3fdd8f36

[kurtjacobs]

47dc56bbb116ec7ed3f500849f08e5a0d7daa1e1efece2d06bf0e58bb9bdf29d