{"id":5464,"date":"2020-01-02T15:27:11","date_gmt":"2020-01-02T15:27:11","guid":{"rendered":"https:\/\/patrickmouwen.com\/process\/d365-retail-apis-part-ii-how-to-know-exactly-what-happens-inside-d365-retail-copy\/"},"modified":"2024-01-26T11:54:41","modified_gmt":"2024-01-26T11:54:41","slug":"d365-retail-apis-part-iii-how-to-use-the-d365-retail-apis","status":"publish","type":"post","link":"https:\/\/patrickmouwen.com\/technicalint\/d365-retail-apis-part-iii-how-to-use-the-d365-retail-apis\/","title":{"rendered":"D365 Retail APIs Part III: How to use the Retail APIs from Power Automate (Flow) and Logic App"},"content":{"rendered":"\n
\n <\/div>\n\n\n\n

After walking through the overall D365 Retail API Architecture in part I and II of this series on the D365 Retail APIs, it’s now time to enable anyone to actually use the Retail APIs. To allow this, this blog post will contain all details on how to construct a request to most of the 400 out-of-box D365 Retail APIs – Beyond that, I’ve included a step-by-step instruction on how to use any of the Retail APIs from Microsoft Power Automate (Flow).<\/p>\n\n\n\n

But before we can really get things rolling, we first need to apply some additional D365 setup and we need to choose the right security pattern. So that’s where I’ll start this blog post.<\/p>\n\n\n\n

Note: to effectively consume the content of this blog post, please ensure to familiarise with the content of Part I<\/a> and Part II<\/a>.<\/p>\n\n\n\n\n\n\n\n

1 – Security<\/strong><\/h2>\n\n\n\n

In Retail world, we’re utilising a variety of sales channels which are operated by a variety of users: in general, 3 types of users can be recognised:<\/p>\n\n\n\n

  1. Employees<\/strong>: in-store POS systems and Call Center applications are operated by Retail employees.<\/li>
  2. Named consumers<\/strong>: consumers unveiling details on their identity (name, address etc.) while making purchases via Social media, e-com platforms, consumer apps etc.<\/li>
  3. Anonymous consumers<\/strong>: guests making purchases without consent on saving information about their identity<\/li><\/ol>\n\n\n\n

    Looking at privacy and data security in general, it is crucial to restrict access to the 400+ D365 Retail API end points for use by each of the 3 categories of users. For example, we certainly do not want the guest visitors on our e-com website to be able to retrieve information from other customers on loyalty points, purchasing history or product recommendations. At the same time, we don’t want our self-checkout consumers to apply manual discounts :). In summary, we need a mechanism to make our Retail end points (which are the gateways to our Data and Business logic) available to only those users who are allowed to use them.<\/p>\n\n\n\n

    If you look inside Retail Server as we’ve done in Part II<\/a>, you’ll find that each of these end points have a special attribute called “CommerceAuthorization” (see picture 1 below). This attribute basically lists the 1 or multiple “Commerce Roles” which are allowed to use the end point.<\/p>\n\n\n\n

    \"D365<\/a>
    Picture 1<\/strong> – CommerceAuthorization Attribute on a Retail Server ODATA end point<\/figcaption><\/figure>\n\n\n\n

    These “Commerce Roles” are very much in line with the user groups we acknowledged earlier:<\/p>\n\n\n\n

    1. Role 1 – Anonymous<\/strong>: this role represents our anonymous customers. It will be of no surprise that only a few D365 Retail APIs are exposed to be used anonymously<\/li>
    2. Role 2 – Customer<\/strong>: this role represents our named consumers<\/li>
    3. Role 3 – Employee<\/strong>: this role represents our Retail staff<\/li>
    4. Role 4 – Application<\/strong>: this generic role is designed for 3rd party applications which do not operate on behalf of a specific user (Customer or Employee)<\/li><\/ol>\n\n\n\n

      Picture 2 below depicts the purpose of Commerce Roles in a bit more detail. As you can see in this picture, every D365 Retail API is enabled for 1 or multiple roles. Since the Customer<\/em> and Employee<\/em> role are built around a known identity (from a consumer or staff member respectively), both roles build upon the use of ID Tokens<\/a><\/em>. In short, ID tokens contain encrypted details on a person’s identity (name, account number etc.) In case of Employees (in-store!) the encrypted ID Token contains the Employee number and Password which we know are used for logging into MPOS\/CPOS.<\/p>\n\n\n\n

      Last but not least, picture 2 highlights the Commerce Role Application<\/em>. This is the role we’ll focus on in the remainder of this blog post as it can be used for integrating any 3rd party application (e-com platforms, 3rd party POS systems, Apps etc.). As visible in picture 2, the Application role works by Access tokens<\/em>. This is exactly the type of authentication most of you will recognise from the very commonly used D365 F&O (backend) APIs. Remember: similar to the D365 F&O backend APIs, the D365 Retail APIs are also based on ODATA, so there’s not much of a difference on how to consume them as you will see below.<\/p>\n\n\n\n

      \"\"<\/a>
      Picture 2<\/strong> – The purpose of Commerce Roles<\/figcaption><\/figure>\n\n\n\n

      2 – Azure Setup<\/strong><\/h2>\n\n\n\n

      In order to allow an external application to make requests to the D365 Retail APIs, we need to register the application in our Azure Active Directory (1) and allow access to D365 for this application (2). Let’s start with the Azure side of things. Here’s how to register the application:<\/p>\n\n\n\n

      STEP 1 – <\/strong>Register the Application<\/p>\n\n\n\n