patrickmouwen: D365 Retail APIs Part II: How to know exactly what happens inside D365 Retail
In any of our D365 Implementation Projects, Solution Prototyping is one of the most important aspects of the implementation. On the one hand this Prototyping serves a common Requirement to find a solution which stays closest to Standard D365 – A Requirement often raised by small to medium sized Retailers. On the other hand, Prototyping let us fully understand D365 Retail which allows us to write the best designs for Custom solutions – An exercise which is often required for the bigger Retailers.
Solution Prototyping is most commonly done from ‘Sea level‘: by setting up D365 Retail in different ways to support variations to a Process which are then evaluated (often in playbacks to Business key users) against Process maps and related Requirements. I think this is a very good and effective way to make progress in a project while still making the right Design Decisions.
However, there are cases in which this ‘Sea level’ approach is either very time consuming or not giving you the confidence that you’ve completely bottomed out the D365 Retail capabilities to support a certain process. You probably recognise this from working on complex Processes which are Retail/Omni related, D365 MPOS/commerce customisations or Retail Integrations. For these cases, you need another approach which I’ve named the ‘Engine Room‘ approach: this approach first descends into the ‘Engine Room’ of D365 for Retail to know exactly what happens there before you work yourself up to ‘Sea level’ again to pick the best Solution for your Use Case. In this blog post, I’ll unveil all the tricks to be able to do this quickly and effectively.
Note: please ensure to familiarise with the D365 Retail API Architecture as per Part I of this series on D365 Retail APIs before you read any further.
1 – Approach
Picture 1 below depicts my ‘Engine Room’ approach:
2 – Setup
2.1 – Trick 1: IIS Setup and Fiddler
Note: only a apply this trick on a D365 DEV box!
#StepReference1RDP into the D365 VM Use the admin account + password available through LCS2Follow these steps to install (if not already installed) and configure Fiddler on the VM. Link 3 Open Internet Information Services (IIS)4Navigate to the Application Pool for Retail Server > Advanced settings -> Change Identity from “Network Service” to the admin account (requires password to be entered).
Note: this is the admin account which is available for the environment on LCS and which is used to RDP into the environment5If you’re working with CPOS, this is sufficient to be able to intercept all end-to-end CPOS>Retail Server>RTS traffic. If you’re working with the SharePoint or Commerce storefront, then repeat step 4 for the Application Pool representing the storefront6I’d recommend to reboot the environment after above steps2.2 – Trick 2: Install and Setup .NET Reflector
#StepReference1RDP into the D365 VM (with the admin account + password available through LCS) 2 Download and install .NET Reflector (run as Administrator) Link
Note: this tool is not free, but has a 14-day trial – I prefer the standalone edition – There’s also an Add-In for Visual Studio 3Open Internet Information Services (IIS) – Navigate to Sites and select RetailServer. Click right mouse button > Explore.
This will open Windows Explorer for the folder which hosts the RetailServer website4Double click on the Bin folder and copy the path to the foldere.g. K:\RetailServer\WebRoot\bin5Open .NET Reflector and click File > Open Assembly – Paste the path to the RetailServer folder as copied in the previous step into the File name textbox. Click Open to open the path6Select one of the DLLs and click to select all DLLs – Click Open to open the DLLS7Navigate to the following entry:
This entry represents the Retail Sever “External mailbox” (Retail ODATA end points) – You’ll recognise all Retail operations here!
This will always be your starting point for any analysis, so keep this entry in mind (!)3 – Analyse a Real-life example: create a Customer through the D365 Retail APIs
In Part I of this series on D365 Retail APIs I used Microsoft Forms to create a Customer into the D365 backend utilising the D365 Retail APIs in real time. Now, we’ll dive into the ‘Engine Room‘ of for this process of customer creation. As you’ll see this will unveil all aspects of Customer sign up including how the Retail Setup and Parameters in the D365 backend guide this process.
3.1 Intercept the D365 Retail communication with Fiddler
Now we have all the entry points for analysis, let’s dive into related Retail Server Business Logic underpinning the request from Cloud Pos to Retail Server:
For the ones who are ‘lost in the woods’ after reading this long blog post, see below an overview of the full E2E ‘Call stack’ for creating a Customer into D365 backend in real time… Yeah.. this WHOLE process happens under 200ms once the Retail Server and Real Time Service are ‘warm booted’… I think it’s simply amazing. What a master piece of art Microsoft have created here !
I hope this blog posts give you a kick start in performing any ‘Engine Room’ analysis against D365 Retail. I always learn a lot on how things are really done inside D365 retail when I follow this approach!
Het bericht D365 Retail APIs Part II: How to know exactly what happens inside D365 Retail verscheen eerst op Patrick Mouwen.
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|powerobjects: How to Configure a Point of Sale in D365 for Retail in a Day||Blog bot||Dynamics CRM: Blogs||0||17.03.2018 02:19|
|patrickmouwen: Dynamics AX Retail: how to automate processes and interfaces in a combined way||Blog bot||DAX Blogs||0||23.12.2015 23:11|
|Опции темы||Поиск в этой теме|