Name __Display name Category ---- -------------- -------- 22565422120 Gift Card Departments AW007-08 Black Diamond Quicksilver II Carabiners AW009-08 Black Diamond Quicksilver II SaleItems AW013-08 Petzl Spirit Adventure Works Catalog ...
Adding Features
Features need to be exported in a special format. Different products in a given catalog may have different features and even have different number of them. Azure solves this by requiring features as a comma separated list of name value pairs:
PSObject is a dynamic type that you can modify on the fly. First, I extracted a collection of features into a new Features property. Then I applied features to become new properties on the product object. CSV export will be able to pick it up transparently. I hope.
CSV
It should now be easy to export the list as CSV. There’s a caveat though.
Both ConvertTo-CSV and Export-CSV will happily export the list for you but will normalize every record to the common set of fields.
You won’t see the features in the list. Here’s a trick to get every product in the export have its own features:
Instead of piping the entire set to the ConvertTo-CSV, I basically processed the list one by one in the foreach loop. I also removed the type info and the CSV headers. Azure doesn’t need labels anyway. Works like a charm!
There’s one more thing that I needed to do for Azure Recommendations API to absorb the catalog. As you could tell, the catalog format is not exactly CSV. Every line can have different number of fields basically. Neither does Azure backend use CSV parsing to read it.
The double quotes in the export above were taken literally. Azure would think that the SKU # is "AW007-08", for example. And then the commas in the descriptions where messing up the parsing as well. My next post will be about the Recommendations API itself and I will write more about it, but here’s the final version that produces a clean catalog export ready to go:
I was playing with Azure Cognitive Services and figured that I would switch to my @epam.com account for the next prototype. I needed to re-sign-up. This is my story.
Login
Microsoft’s live.com OAuth can integrate with your ADFS for a single sign-on experience:
I opted in for my work account, authenticated, and went ahead to enable the services I needed.
Verification
To enable Cognitive Service APIs on this account I needed to activate my Azure subscription. Microsoft will challenge your identity twice.
First, it’s the code verification that you can do by sending yourself a text. My form was pre-populated with the Belarus country code (+375). I quickly dismissed it as probably an old attribute on my AD profile. You see, I lived in Minsk (Belarus) before I moved to the states a good while ago but not every enterprise system got the memo. No big deal. Typed in my cell phone and got the activation code.
Then it’s the identify verification by card:
My postal code is again pre-populated with the one from the past. This time, however, I wasn’t able to use my current address:
What do you do when an online form tries to outsmart you? I, personally, try to outsmart it back:
Guess what, Microsoft engineers are very diligent. The validation also runs server-side and the form comes back with an error:
Sigh… My US street address and the city of Marietta were gladly accepted. It’s the postal code format and length validation that failed. Why so serious? A better solution would probably be to ask for a country as part of the address form and validate against it. Or maybe trust the SSO challenge that I went through when logging in and just collect my card?
Anyway. I guess I will keep using my personal account with Azure for now and will wait for out IT to find the field in my profile that ties me to my home country.