(Check out the SAP Developer Challenge - APIs blog post for everything you need to know about the challenge to which this task relates!)
You've made various read-only requests so far; now it's time to create some data.
Background
For this task we return briefly to the Northbreeze service from Task 2. Until now, mostly due to the nature of the deliberate simplicity of the tasks in this Developer Challenge, the actions you've been performing from an HTTP perspective have been read-only.
This time you'll write some data, albeit data that won't last long (the Northbreeze service runs in-memory and has been set up not to use a permanent persistence layer). Then you'll read it back, with a minor difference, to examine what the response looks like. It's that response, compressed, that you'll need for the hash.
The Northwind service traditionally has products, which you've encountered already. Those products are organized into categories, of which there are just a few. A category (taking the first one) looks like this:
{ "CategoryID": 1, "CategoryName": "Beverages", "Description": "Soft drinks, coffees, teas, beers, and ales" }
You can get a feel for the distribution of products across categories by asking for the count of products by category ID which is expressed like this (showing the path, with whitespace, for easier reading):
/odata/v4/northbreeze/Products
?$apply=groupby(
(Category_CategoryID),
aggregate($count as productcount)
)This returns a response that looks like this:
{ "@odata.context": "$metadata#Products(Category_CategoryID,productcount)", "value": [ { "productcount@odata.type": "#Decimal", "productcount": 12, "Category_CategoryID": 1, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 12, "Category_CategoryID": 2, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 13, "Category_CategoryID": 3, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 10, "Category_CategoryID": 4, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 7, "Category_CategoryID": 5, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 6, "Category_CategoryID": 6, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 5, "Category_CategoryID": 7, "@odata.id": null }, { "productcount@odata.type": "#Decimal", "productcount": 12, "Category_CategoryID": 8, "@odata.id": null } ]}
As you can see, the OData V4 aggregate facilities, and CAP's support for them, is pretty neat!
Your task
Your task is to create a new category, and then request it. In other words, you must contruct an appropriate HTTP request to form an OData CREATE operation, to add a new category entity into the entity set. You can see from above that a category has just three properties:
- CategoryID - this is the key and must be an integer value
- CategoryName - a short name for the category
- Description - a brief summary of what the category is
You must supply the following values for these properties when creating your new category:
- CategoryID - your SAP Community ID number (see the Hints and tips section)
- CategoryName - your SAP Community ID in lower case
- Description - the static text August Developer Challenge
You can tell that the CategoryID property must be a number, because of how it's defined in the OData service's metadata document.
Once you've created your new category, you must then construct an appropriate HTTP request to form an OData READ operation to request a representation of your category. There are some important points here:
- you must use an OData READ operation and not an OData QUERY operation
- you must exclude the Description property, i.e. you should request (and expect) only the category properties CategoryID and CategoryName
- the representation of the response must be in JSON
The representation of the response is the value you need to hash and share as a new reply to this discussion thread, as always, and as described in Task 0. Note that you'll have to URL encode the entire value, as you will be sending it within the value=('...') part of the hash service URL.
You should ensure that the order of the properties in the JSON object structure returned is sorted (it should already be, but double check or just add that processing to whatever mechanism you build to do this) and that there is no extraneous whitespace in the structure at all.
Here's an example of what a response representation will look like - note the single line and no whitespace, and that the CategoryName value is all lower case:
{"@odata.context":"some-context-specification","CategoryID":53,"CategoryName":"qmacro"}
Hints and tips
You already know about your SAP Community ID. For example, qmacro is the SAP Community ID for DJ Adams. To get your SAP Community ID number, which is unique, just go to your profile page, and get the number from your profile page's URL. For example, the profile page for DJ Adams is at https://groups.community.sap.com/t5/user/viewprofilepage/user-id/53 and looks like this:
You can see the SAP Community ID number in the URL - it's 53. Go to your profile page and get the number from the resulting URL for your profile.
What about the OData READ vs OData QUERY operation question? Both use the same HTTP method (GET) but the structure of the data returned is different. Given that the data and its structure is what you need to ensure is correct before hashing it, it's important you think about how you would request that single new category.
For discussion
What is the definition of the CategoryID property, according to the metadata document?
What is the difference between the result of an OData QUERY operation and the result of an OData READ operation? How does this relate to OData's origins? What is the significant difference in data structure returned?
Did you try to request a different representation of your category, such as XML? What happened?
