DEV Community: Rob vanBrandenburg

Dynamics 365 (E-)Commerce development Proof of Concept (2)

Rob vanBrandenburg — Fri, 14 May 2021 19:29:16 +0000

This is a follow up on this post.

Intro

In the first part we saw how we can extend the CRT to include additional fields in the extension properties, and how to surface that in your own 'Dynamics 365 Commerce - Ecom' custom module.
In this section I'm going to add that field to the 'Add to cart' process.
If you recall, we added an 'Is Warranty' flag to the product table, and we want to produce a message to the end user when they add this item to their cart. It will inform them that the item does not have warranty, and asks them to confirm that they want to buy it.

Setup

Since we are going to add logic to the cart (buybox), we need to be able to mimic adding items to the cart. However, that is not easy when you don't have a full blown Ecom site linked to your dev box.
I think technically it should be possible by setting up a page mock, but I could not get this to work.

However, you can actually use your Test environment's Ecom site for this.
By configuring your .env file to use your Test environment's Ecom site and server, you can use all the site's functionality and data setup while running your Ecom mods locally.

To do this, point all the variables in your .env file to the test environment.
Then when you access https://:4000 it will render test site and all its data, but loads the code locally.
We'll see further below that we use a custom theme to extend the functionality, and by specifying the theme in our url (with a parameter) we can run the custom code.

Implementation

Since I want to add a dialog/message box to the 'add to cart' process, I initially thought I had to change the buybox module.
However Sam Jarawan from Micsrosoft pointed to an easier solution:

This poses the question; how do we override this?

If you must change any logic in a component, you can use the command-line interface (CLI) add-component-override command to override the component for a selected theme.

See here

First we need to either create or extend a theme.

Create a new theme using the CLI. (You do this in your Visual Code terminal window):

yarn mdsyn365 add-theme itk

Then modify the theme definition so it extends the standard Fabrikam theme:

Make sure to include the styles per here.

Now that we have a theme, we can add our component override to it:

yarn msdyn365 add-component-override itk AddToCart

The command above will copy the component to our themes' "views\components" folder:

You will need to update the imports, as the default paths are no longer valid.
From:

To:

Lets make sure that our new code is executed, and that we can do something when an item is added to the cart. For testing we add a simple alert to the code:

We start the local server:

yarn start

Then fire up the browser, navigate to a PDP page, make sure you select the new theme by modifying the URL, and add the item to the bag:

Beauty! It works!

Next step: Use the new field in the alert message.

To do this, we modify the code in our component override :

If we now access the pdp page again using our theme, and add the item to the cart, we see this:
(Make sure you use an item that does NOT have the custom warranty flag set)

Then if we test again, but this time using an item that does have the custom warranty flag set, we do not get the message.

The code needs to be adjusted to actually add, or not add the item to the cart based on the user's response, but the example at least shows the concept.

Rob.

D365 F&O and PowerApps (2)

Rob vanBrandenburg — Wed, 12 May 2021 12:54:44 +0000

Introduction

This is part 2 of using PowerApps with Microsoft Dynamics 365 Finance and Operations. Part 1 is here

This is going to be a short post, as there is not much to it.
As seen in part 1, you can link to a (canvas) PowerApp from the D365 F&O UI by using the 'PowerApp' button.
However, you can also 'embed' the (canvas) PowerApp in the UI, but this has to be done through actual F&O development.

First, this doesn't make a lot of sense. The whole idea of the NoCode/LowCode PowerApps is that you do NOT need a developer (and consequent downtime and deployment).
But since the option is there, I figured I'd try it out.

The official documentation is here:
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/get-started/embed-power-apps#developer-modeling-a-canvas-app-on-a-form

Disclaimer: I know the example below makes no business sense. I'm showing sales order lines in the PowerApp that are already present in the F&O form that I add the App to. But since I already had the App from part 1, I figured I'd just reuse it to show the concept.

Adding the App to a screen (form)

The actual dev task is very simple. For this example we will be adding the App from part 1 in a new tab in the 'Sales Orders' inquiry form. ('Retail and Commerce -> Inquiries and Reports -> Sales Orders').

The form name is 'MCRSalesTableOrderHistory', so we first create an extension to that form in Visual Studio.
Then we simply add a tab page, and add a 'PowerAppsHost' control to the page.
In the properties we set the AppId and the field that we want to pass to the App as the key. (Review Part 1 for details)

The scaling of the App in the UI is pretty terrible. I manually set the height and width in the control's properties, but it still renders it with a very tiny font.
I have not tried to modify the actual App to use a larger font, but in my opinion this should not be necessary.
In any case, it does work, the order lines of the order I selected in the main grid are displayed in the PowerApp.

Here you see where I set the properties to try and make it bigger (did not work):

Conclusion

You can add embedded PowerApps directly to the F&O UI. It works. However, I have trouble finding a scenario where you would want to do this.
The only thing I can think of is when you have a PowerApp that serves up data/functionality of an external (non-F&O) system.
But still the rendering in the UI looks pretty bad.

D365 F&O and PowerApps (1)

Rob vanBrandenburg — Thu, 06 May 2021 15:57:11 +0000

Introduction

You can now use Microsoft PowerApps with D365 Finance and Operations. (D365 Supply Chain Management, Finance, Commerce)
I always struggled with finding a business case for doing this. Why not just customize F&O?
But I actually came up with a scenario that I think could be useful.
Read on if you are interested.

Business Case

Sometimes you want to quickly see what items are on a sales order. You don't need all the bells and whistles, dates, categories, what have you. You just want to see what's on that order as far as items/products go.
Right now, you will need to go to the 'All Sales Orders' screen, select the order from the grid, then go to the lines, wait until all the stuff you DON'T need is loaded, and then discover you selected the wrong order, and have to start all over again.

What if I could just bring up a super simple screen that ONLY shows the item, description and qty for the order I selected?
Enter PowerApps.

This posts outlines the steps to complete the above scenario. Let's get started.

I got most of the info from the link below, and the helpful
"Finance and Operations Insider Program" Yammer community.
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/get-started/embed-power-apps#adding-an-embedded-canvas-app-from-power-apps-to-a-page

Creating the App

To create your App, make your way to make.powerapps.com and log in.
First we need to create a connection, select the 'Connections' node in the left pane and select 'New connection':

Select the FinOps connector and click 'Create':

Now we can create our app.
Click on 'Apps' in the left pane and create a canvas app:

You can either start with a 'Table' (Entity) and have a base layout generated based on the data (you do this by clicking on the right arrow) - or start with a blank app.
Since we're building a super simple app, I'm starting with a blank app:

First we add our data source. Click on the 'Data' icon on the left, then "Add Data". Drop down the 'Connectors' section and select the F&O connection you just created:

This will list the available F&O instances in the 'Choose a dataset' window that comes up. Select the one you want to connect to, and then select the table (= F&O Data Entity - ) you want to connect to.
In this example we want to see sales order lines, so we're picking the 'CDSSalesOrderLinesV2' table, and click 'Connect':

Provide an app Name, hit 'CTRL-S' to save, hit the 'back' arrow once saved, and close the Data pane.

Now let's add some data to our form.
Select the 'Insert' tab and click 'Data table', then select the data source you just added:

As you add this, the app will actually load the data, so be patient.
It shows a set of default fields on the grid with their data.
We will change these fields so the grid has the ones we need.

Bring up the tree view by first clicking on the hamburger menu, and then the 'Tree view' node.
You can close the hamburger menu now if you want more space, the tree view will remain on screen.

Expand the 'DataTable' node, and delete the fields you don't want (I'm only leaving the sales order number column at this point)

To add the fields you want, select the 'DataTable' in the tree view, then select 'Edit fields' on the properties pane on the right:

In the pane that comes up you can select the fields you need. For now, add the product name and number, and the quantity:

Now we have our very basic app.

Filtering the rows

As it sits now, the app now shows ALL sales Order lines.
When we call the app from F&O, we only want to show the lines for the selected order.
We need to implement some logic that filters the rows.
This section has info on that:
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/get-started/embed-power-apps#building-a-canvas-app-that-uses-data-that-is-sent-from-finance-and-operations-apps

When we add the app to F&O, we can specify which field is going to be passed to the app when the app is started from F&O.
The framework will put this value in a parameter called 'EntityId'.
Parameter 'cmp' is passed with the Legal Entity value.
When the app starts we want to use that parameter, and put it in a variable so we can filter the records using that variable.
For our scenario, that will be the sales order number.

First step for this is to put the parameter in a variable.
Sample code for that is in the article linked above, so let's implement this (with a small change).

In the tree view, select the 'App' node.
Make sure that the 'OnStart' event is selected in the top left.
Expand the formula section so we have more room to put the code.
Then enter the code snippet below. Note that variable names are case sensitive.

If(!IsBlank(Param("EntityId")), Set(FinOpsInput, Param("EntityId")), Set(FinOpsInput, "EMPTY"));
If(!IsBlank(Param("cmp")), Set(FinOpsInput, Param("cmp")), Set(FinOpsLegalEntity, ""));
Notify("EntityId parameter: " & FinOpsInput);

TIP: For testing/debugging it is useful to provide some output when the app is called. That's why we are putting the 'Notify' command in the code, so we can verify that the proper value is passed from F&O.

The next step is to actually filter the content in the view, using the new 'EntityId' variable.
Click on the DataTable in the tree view, and enter the code below in the formula window:

Filter(CDSSalesOrderLinesV2,'Sales order (SalesOrderNumber)' = FinOpsInput)

You have probably noticed that annoying red 'X' shown in the table view. I think this is due to the naming of the sales order field on the entity. It makes the code generate an incorrect field name.
To further investigate and fix, click on the down-arrow next to the error, and select 'Get help for this error':

It tells us that it does not like the Sales Order field in the grid:

Click in the 'Text' field and delete everything so only 'ThisItem' is left.
Then enter a period, and the field list will pop up.
If you scroll down, then you'll find that the field name is NOT just 'Sales Order', but actually
'Sales order (SalesOrderNumber)'

Just select that one and the error will go away.

That should be it for our app. Hit CTRL-S to save it again.

In order to use the app in F&O, we first need to publish it.
Easy enough, just click 'File' in the top left, and hit the big 'Publish' button.

We will need the App's ID in order to add it to F&O.
Close the App Editor tab to get back to the main PowerApps site.
Select your new app from the list, and then click 'Details':

Copy the App ID from the details page, we'll need that in the next step:

Add the App to F&O

Now let's add the app to F&O.
As outlined at the top we want to be able to call this from the 'All Sales Orders' screen, so let's open that up, and click on the "PowerApps" button, then 'Add an app':

In the window that pops up, enter a name for the app, your AppID that you copied above, and select the sales order number as the key to be passed to the App:

Click 'insert' and hit F5 to reload the page.

When the page reloads you should now see your app under the 'PowerApps' button in F&O:

To test it, first select a sales order from the grid, then click the PowerApps button and select your app.
If everything went well, it should show the sales ID in the notification and the sales lines in the grid:

Tips

Couple tips:

If you are making changes to the app, make sure to publish the app before testing.
Sometimes it is hard to know if the updated app is executed or not. I usually change something simple, like the text in a header to make sure that the latest version is executed.
If you want to remove the app from F&O, or edit the F&O settings, right-click on the PowerApps button and select 'Personalize: PowerApps'. This will bring up a screen where you can edit or delete (remove) the app:

There is also a way to embed a PowerApp into the F&O UI directly via F&O development. See part 2 for details on that.

Hope this was useful.
Rob

D365 F&O / PowerBI overview

Rob vanBrandenburg — Mon, 19 Apr 2021 11:12:58 +0000

D365 F&O / PowerBI overview

‘Microsoft Dynamics 365 for Finance and Operations’ (“F&O” to us mere mortals) has some nice features to do reporting with PowerBI.
However, I’ve found the options, requirements and possible deployments extremely confusing.

This article tries to summarize the whole ‘ecosystem’ (always wanted to use that word) – and explain what is what.

Special thanks go to Tom Higginbotham at Microsoft for answering my relentless stream of questions and providing extremely useful guidance.

The info might be a bit haphazard, and I might revise it several times, but we have to start somewhere, right ?

Here we go:

Tier 1 vs Tier 2 servers

There was a lot of confusion (on my part) to determine if a tier 1 (‘OneBox’) or tier 2 (Test/Sandbox) environment was required.

This document explains the tier-1 / tier-2 issue:

https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/analytics/power-bi-embedded-integration?toc=/fin-and-ops/toc.json

Some specifics from the doc:
The Power BI Embedded service is automatically deployed and configured for all cloud-hosted, multi-box deployments. Because the service relies on Microsoft Azure services, application analytical workspaces and reports are unavailable in one-box environments.

The Microsoft Dynamics 365 team is working on a solution that will enable analytical workspaces in one-box environments without requiring that customers host their own instance of the Power BI Embedded service RvB: they are referring to the setup with a separate Azure DB to host the Entity Store (AXDW)

Can I customize the Power BI embedded reports?
Yes. To customize the Power BI embedded reports, just install Power BI Desktop in a one-box environment, and follow the steps in Author and distribute Power BI reports with Entity store.

PowerBI ‘Integration’ vs ‘Embedded’ PowerBI’

There are 2 ways to use PowerBI with F&O – you can mix and match these 2 methods:

PowerBI integration :
This is where you link F&O to your PowerBI subscription. This is setup through System Admin -> Setup -> PowerBI.com Integration.
This allows you to add reports/tiles/dashboards from PowerBI.com to Analytical workspaces.
When an existing report on PowerBI.com is “integrated” into D365F&O, it is done so from one of the 3 options on a Workspace:

These reports can contain both F&O data and other data sources (EntityStore / DataLake)

Note: DataSource on report will need to be manually changed when deployed to TEST or PROD environmentThe ‘Open Report Catalog’ and ‘Open Dashboard Catalog’ will add the respective items as Links to the Links list on the right-hand side of the Workspace. Example:

"Open Tile Catalog" will show the list of tiles from Dashboards on PowerBI.com and add them to the designated pane on the Workspace.

Embedded PowerBI : https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/analytics/add-analytics-tab-workspaces

Snippet from the above article:
Prerequisites:
An analytical report (.pbix file) that was created by using Microsoft Power BI Desktop, and that has a data model that is sourced from the Entity store database.

This will require you (the developer) to add an ‘analytics’ tab to an existing (or new) workspace – much like the standard analytics tabs that contain PowerBI reports.
Since a prerequisite for PowerBI Embedded reports is to use the Entity Store, these can only contain F&O data.

A Tier 2 (or Higher) environment may not necessarily have the embedded Power BI components activated by default. To have it activated requires the submission of a Service Request in LCS as an “Other” request type. This is noted in the following: https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/lifecycle-services/submit-request-dynamics-service-engineering-team?toc=/fin-and-ops/toc.json#create-service-requests

Scroll down in the article a bit and you will see as the last point under Other request:

Microsoft has rolled out the ability for a user to edit an embedded Power BI report within the F&O browser client. When the user has an embedded Power BI report displayed, there’s the following option:

This feature is described here: https://docs.microsoft.com/en-us/business-applications-release-notes/October18/dynamics365-finance-operations/edit-analytical-workspaces

When this is selected, the Power BI editing experience is turned on:

Again, this is only for the embedded Power BI reports. While these are PBIX resource files in Visual Studio, once deployed they are sourced on the Power BI Embedded Service (within the F&O subscription).

An embedded Power BI report can either be a Tab on a Workspace, such as this one in the Fixed Asset Management workspace:

Or, it can be an entire Workspace, such as CFO Overview/Financial Insights:

Or, it is a Form that is loaded via a menu item, such as Procurement and Sourcing > Inquiries and Reports > Purchase Performance > Purchase and Spend Analysis:

These would be the UI options should a new/custom Analytical Report be created, in a Tier 1 Sandbox.

Summary:

Embedded PowerBI
- No additional license needed
- Can only contain D365FO data (Entity Store)
- Ability to drill down to D365FO screens
- Requires F&O development / code deployment (but can be edited from UI in future release)
PowerBI via link or ‘Report Catalog’
- Pulls from PowerBI service
- Requires additional PowerBi license
- Cannot drill down to F&O screens
- Can contain D365FO and external data

In order to develop the “PowerBi Embedded“ reports, you need a tier 1 environment (probably 1 per developer, like any other F&O development task)

in order to deploy and run/test the reports (by an end-user) – you will need a Tier 2 environment. (so you could use any tier 2 TEST/UAT environment for this).

Dynamics 365 (E-)Commerce development Proof of Concept (1)

Rob vanBrandenburg — Thu, 15 Apr 2021 13:45:43 +0000

Part 2 now available.

Intro.

Microsoft has now a full-blown web store front end. In the ever-changing and ever confusing product naming this is currently called Dynamics 365 Ecommerce, which is part of Dynamics 365 Commerce.
Dynamics 365 Commerce was formerly known as D365 Retail, which was formerly part of D365 Finance and Operations, which was formerly known as Dynamics AX. Confused yet? Join the club.

Ok, done with my usual MS product naming complaint, let’s get down to business.

In this article I’ll use:

‘D365F&O’ or ‘F&O’ for the ‘backend’ ERP system. Also referred to (in retail/commerce context) as ‘HQ’
For the website/shop components I’ll use ‘Ecommerce’ or ‘Ecom’
When referring to the retail development components around retail server, Commerce Scale Unit, POS, etc, I’ll use ‘RetailSDK’.

I’ll try to keep it consistent to keep confusion to a minimum.

Note: All the D365F&O and RetailSDK development (i.e. the CRT extension) was done with Visual Studio 2017.
The Ecom development was done with Visual Studio Code.

MS actually has some good documentation available on the architecture of the products, so I won’t get into that. However, it is not always clear on how all these pieces fit together.

In order to educate myself, and also to try out a request from a customer, I decided to see if I can complete this requirement:

“When a user adds an item to a cart on the Ecom site, the app should check if the item is marked as a warranty item. If it does, it should show a popup.”

Seems fairly straightforward, yes?

Steps and components to modify.

The following steps need to be taken to build this:

D365F&O backend (HQ) development
- Add ‘warranty’ field to InventTable
D365 Commerce Data Exchange (CDX) development
- Add field to channel DB
- Add field to CDX process that takes data from the D365 HQ to the channel DB
D365 Commerce / RetailSDK development
- Extend CRT: Expose new field to CRT API (Commerce Run Time)
D365 Ecom development
- Surface new field to Ecom site. (To keep things ‘simple’ I initially just create a new module and see if I can get to the field value)

1. D365F&O backend (HQ) development

This is super simple. Just extend the InventTable, and add the field to it. I created a new EDT that extends the YesNo Enum and added it as a new field to the extended table:

2. D365 Commerce Data Exchange (CDX) development

Here we implement the logic that is going to take the new field (and its value) and copy that to the channel DB. (This is the DB that POS/Ecom uses).
I used this doc for guidance:
https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/cdx-extensibility#cdx-sample---pull-new-columns-to-an-existing-table

First we need to create a resource file that is going to add our field to an existing Retail Scheduler Job.
Standard F&O has a job ‘1040’ which handles products, and has InventTable in it, so it makes sense to add it there:

Then we need to Subscribe to the ‘registerCDXSeedDataExtension’ delegate (it’s all in the link above):

We build the project, and then run ‘Initialize commerce scheduler’ (Delete configuration = ‘yes’) in F&O.
When done, check the subjob:

Extend Channel DB

Now that we have all that setup, we need to create the field in the Channel DB, so that the CDX has a spot to save the data. Details can be found here:
https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/channel-db-extensions

The way it works is that we need to create a table in the [ext] schema in the Channel DB with the same name as the table we are extending (InventTable), and the same primary index.

You will need to write an SQL query that does this for you. The easiest way to do this is to find the table you want to extend in the AX schema using SQL Server Management Studio. Then right-click on the table and select 'Script table as' -> 'CREATE To' -> New Query Editor window.
In the new query window you edit the query to only use the [EXT] Schema instead of [AX], then remove all fields except the key fields used in the primary index, and add your extension field(s):

/****** Object:  Table [ext].[INVENTTABLE]    Script Date: 3/25/2021 11:42:05 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [ext].[INVENTTABLE](
[RECID] [bigint] NOT NULL,
[ITEMID] [nvarchar](100) NOT NULL,
[ITKISWARRANTY] [int] NOT NULL,
[DATAAREAID] [nvarchar](4) NOT NULL,
[ROWVERSION] [timestamp] NOT NULL,
 CONSTRAINT [I_ITKINVENTTABLEEXTENSION_PRIMKEY] PRIMARY KEY CLUSTERED 
(
[ITEMID] ASC,
[DATAAREAID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY])
GO
ALTER TABLE [ext].[INVENTTABLE] ADD  CONSTRAINT [DF_INVENTTABLE_ITEMID]  DEFAULT ('') FOR [ITEMID]
GO
GRANT INSERT ON [ext].[INVENTTABLE] TO [DataSyncUsersRole];
GO
GRANT DELETE ON [ext].[INVENTTABLE] TO [DataSyncUsersRole];
GO
GRANT UPDATE ON [ext].[INVENTTABLE] TO [DataSyncUsersRole];
GO
GRANT SELECT ON [ext].[INVENTTABLE] TO [DataSyncUsersRole];
GO

Deployment of extended table script.

I have not tested the deployment (yet) in a tier 2 environment, but the script needs to be part of your deployable package. See here:
https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/retail-sdk/retail-sdk-packaging#database-scripts

3. D365 Commerce / RetailSDK development

Now that we have our field in the Channel DB, we need to expose it in the CRT API.
I used this scenario as an example:
https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/commerce-runtime-extensibility#scenario

This is where things get complicated and I spent a LOT of time trying to figure it out.

In short: Ecom calls the retail API (hosted on the Retail server, which is part of the Scale Unit).
The Retail API basically is just a pass-through to the CRT API.
The key thing is that you need to know what CRT API is called for the process you want to modify.

For example, when product data is read from the Channel DB before it is added to your cart, that’s what we need to extend, as that is where we need to ‘add’ our new field.
I don’t think there is a direct relation or documentation that explains that Ecom Data Action ‘A’ calls which Retail API ‘B’, which calls CRT API ‘C’.

To keep things simple I just started with the Ecom ‘SimpleProduct’ action, and through trial and error (and checking the Commerce Server Event log), I figured out that it called the CRT ‘GetProductsDataRequest’ API.
So that means that I should add a post-trigger to the CRT ‘GetProductsDataRequest’ API.

The code below is by no means ‘production ready’, it is just POC code to test this out. If you have any remarks/corrections, then please comment below.

tip: In order to have your request trigger executed, you need to copy the compiled DLL to your retailservers' 'ext' folder ('K:\RetailServer\WebRoot\bin\Ext' in my case), and add the name of the DLL to the 'CommerceRuntime.Ext.config' file in the same directory. Then restart IIS to make sure the new DLL gets picked up.

What we are doing is that when the standard API has collected the product data, we implement a ‘post’ trigger that uses the retrieved ItemId to get the record from our extension table.
Once found, the result is added to the response as an ‘extension property’:

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.Dynamics.Commerce.Runtime;
using Microsoft.Dynamics.Commerce.Runtime.Data;
using Microsoft.Dynamics.Commerce.Runtime.DataModel;
using Microsoft.Dynamics.Commerce.Runtime.Messages;
using Microsoft.Dynamics.Commerce.Runtime.DataServices.Messages;

namespace ITK.Commerce.Runtime.GetProductsExtended
{
    /// <summary>
    /// Class that implements a post trigger for the GetProductsDataRequest request type.
    /// </summary>
    public class ITKGetProductsDataRequestTrigger : IRequestTriggerAsync
    {
        /// <summary>
        /// Gets the supported request for this trigger
        /// </summary>
        public IEnumerable<Type> SupportedRequestTypes
        {
            get
            {
                return new[] { typeof(GetProductsDataRequest) };
            }
        }

        public async Task OnExecuted(Request request, Response response)
        {
            ThrowIf.Null(request, "request");
            ThrowIf.Null(response, "response");

            EntityDataServiceResponse<SimpleProduct> resp = response as EntityDataServiceResponse<SimpleProduct>;

            SimpleProduct item = resp.PagedEntityCollection.Results[0];

            var query = new SqlPagedQuery(QueryResultSettings.SingleRecord)
            {
                DatabaseSchema = "ext",
                Select = new ColumnSet(new string[] { "ITKISWARRANTY" }),
                From = "INVENTTABLE",
                Where = "ITEMID = @itemId AND DATAAREAID = @dataAreaId"
            };

            query.Parameters["@itemId"] = item.ItemId;
            query.Parameters["@dataAreaId"] = request.RequestContext.GetChannelConfiguration().InventLocationDataAreaId;
            using (var dataBaseContext = new DatabaseContext(request.RequestContext))
            {
                var extensionResponse = await dataBaseContext.ReadEntityAsync<ExtensionsEntity>(query).ConfigureAwait(false);
                ExtensionsEntity extensions = extensionResponse.FirstOrDefault();

                var itkIsWarranty = extensions != null ? extensions.GetProperty("ITKISWARRANTY") : null;
                if (itkIsWarranty != null)
                {
                    item.SetProperty("ITKISWARRANTY", itkIsWarranty);
                }
            }

        }

        /// <summary>
        /// Pre trigger code.
        /// </summary>
        /// <param name="request">The request.</param>
        public async Task OnExecuting(Request request)
        {
            // Stub only to handle async signature.
            await Task.CompletedTask;
        }
    }
}

I spent a lot of time trying to figure out if I now needed to extend the Retail Server API, as the documentation states that the Retail Server API calls CRT.
I’ll save you all the things I tried and looked into: it’s not needed.
The retail server API will ‘automagically’ expose the new field. (Through the extension properties framework – recall that we added the field value as a property to the response in the ‘post’ trigger above).

To make sure this all worked, and without having to worry about anything related to Ecom, I decided to create a console app that calls the retail API to make sure my new field is being returned.
See here: https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/consume-retail-server-api
And more specifically here (don’t skip the previous link though – you need those steps): https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/consume-retail-server-api#access-the-retail-server-apis-by-using-a-console-application

There was also a section in the documentation that said that we needed to (re)generate TypeScript Proxies. However, for this scenario that is not required, since we only extended an existing API.
If you create a new crt API, then you also need to create a new Retail API to call your CRT API, and you need to generate the proxies.

Code for the console app below. The parts that are commented out can be used if you extend the ‘GetProductPartsDataRequest’ API:

using Microsoft.Dynamics.Commerce.RetailProxy;
using Microsoft.Dynamics.Commerce.RetailProxy.Authentication;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
using System;
using System.Collections;
using System.Collections.Generic;
using System.Configuration;
using System.Threading.Tasks;

namespace ITKCommerceConsApp
{
    class ITKCallRetailApi
    {
        private static string clientId;
        private static string clientSecret;
        private static Uri retailServerUrl;
        private static string resource;
        private static string operatingUnitNumber;
        private static Uri authority;

        private static void GetConfiguration()
        {
            clientId = ConfigurationManager.AppSettings["aadClientId"];
            clientSecret = ConfigurationManager.AppSettings["aadClientSecret"];
            authority = new Uri(ConfigurationManager.AppSettings["aadAuthority"]);
            retailServerUrl = new Uri(ConfigurationManager.AppSettings["retailServerUrl"]);
            operatingUnitNumber = ConfigurationManager.AppSettings["operatingUnitNumber"];
            resource = ConfigurationManager.AppSettings["resource"];
        }

        private static async Task<ManagerFactory> CreateManagerFactory()
        {
            Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext authenticationContext =
                new Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext(authority.ToString(), false);
            AuthenticationResult authResult = null;
            authResult = await authenticationContext.AcquireTokenAsync(resource,
                                                                        new ClientCredential(clientId, clientSecret));
            ClientCredentialsToken clientCredentialsToken = new ClientCredentialsToken(authResult.AccessToken);
            RetailServerContext retailServerContext = RetailServerContext.Create(retailServerUrl,
                                                                          operatingUnitNumber,
                                                                          clientCredentialsToken);
            ManagerFactory factory = ManagerFactory.Create(retailServerContext);

            return factory;
        }

        private static async Task<Microsoft.Dynamics.Commerce.RetailProxy.PagedResult<SalesOrder>> ITKGetOrderHistory(string customerId)
        {
            QueryResultSettings querySettings = new QueryResultSettings
            {
                Paging = new PagingInfo() { Top = 10, Skip = 10 }
            };

            ManagerFactory managerFactory = await CreateManagerFactory();
            ICustomerManager customerManager = managerFactory.GetManager<ICustomerManager>();
            return await customerManager.GetOrderHistory(customerId, querySettings);
        }

        private static async Task<Microsoft.Dynamics.Commerce.RetailProxy.PagedResult<SimpleProduct>>
            ITKGetProduct(long productRecId)
        {
            QueryResultSettings querySettings = new QueryResultSettings
            {
                Paging = new PagingInfo() { Top = 10, Skip = 0 }
            };

            ManagerFactory managerFactory = await CreateManagerFactory();
            IProductManager productManager = managerFactory.GetManager<IProductManager>();

            List<long> productIds = new List<long>();
            productIds.Add(productRecId); 

            // 68719478279 is he recid of the channel I'm using for testing (Fabrikam Online Store)
            return await productManager.GetByIds(68719478279, productIds, querySettings);


            // Code below is working when using a CRT trigger extension for GetProductPartsDataRequest
            /*
            QueryResultSettings querySettings = new QueryResultSettings
            {
                Paging = new PagingInfo() { Top = 10, Skip = 0 }
            };

            ProductLookupClause productLookupClause = new ProductLookupClause();
            productLookupClause.ItemId = productId;

            System.Collections.ObjectModel.ObservableCollection<ProductLookupClause> lookupClauseList = 
                new System.Collections.ObjectModel.ObservableCollection<ProductLookupClause>();

            lookupClauseList.Add(productLookupClause);

            List<IObservable<ProductLookupClause>> productLookupClauseList = new List<IObservable<ProductLookupClause>>();
            productLookupClauseList.Add(productLookupClause as IObservable<ProductLookupClause>);

            ProductSearchCriteria productSearchCriteria = new ProductSearchCriteria();

            productSearchCriteria.ItemIds = lookupClauseList;
            //NOTE: ProjectionDomain/Context is required when calling productManager.Search
            ProjectionDomain projectionDomain = new ProjectionDomain();
            projectionDomain.ChannelId = 68719478278; 
            productSearchCriteria.Context = projectionDomain;

            ManagerFactory managerFactory = await CreateManagerFactory();
            IProductManager productManager = managerFactory.GetManager<IProductManager>();

            return await productManager.Search(productSearchCriteria, querySettings);
            */
        }
        static void Main(string[] args)
        {
            GetConfiguration();

            // Code that is commented out below can be used to call sales order history
            /*
            Microsoft.Dynamics.Commerce.RetailProxy.PagedResult<SalesOrder> orderHistory = Task.Run(async() => await ITKGetOrderHistory("2001")).Result;
            IEnumerator orderEnum = orderHistory.Results.GetEnumerator();

            while (orderEnum.MoveNext())
            {
                SalesOrder order = orderEnum.Current as SalesOrder;
                Console.WriteLine(order.SalesId);
            }
            */

            // For the Fabrikam Online Store item 91009 is 'Round Oversized Sunglasses"
            Microsoft.Dynamics.Commerce.RetailProxy.PagedResult<SimpleProduct> itkProducts = 
                Task.Run(async () => await ITKGetProduct(68719498121)).Result; //This is the recid of the product in the ECORESPRODUCT table

            IEnumerator resultEnum = itkProducts.Results.GetEnumerator();

            while (resultEnum.MoveNext())
            {
                SimpleProduct item = resultEnum.Current as SimpleProduct;
                Console.WriteLine(item.RecordId);
                Console.WriteLine(item.Description);
                Console.WriteLine();
            }


            Console.WriteLine("Press Enter");
            Console.ReadLine();
        }
    }
}

To recap:

The extension executes a separate query to get the referenced record from the '[ext].Inventtable' extension table.
Then the new field(s) get added to the entity that is returned:

Snippet from the CRT extension class 'ITKGetProductsDataRequestTrigger.cs':

 var itkIsWarranty = extensions != null ? extensions.GetProperty("ITKISWARRANTY") : null;
                if (itkIsWarranty != null)
                {
                    item.SetProperty("ITKISWARRANTY", itkIsWarranty);
                }

Then these can be accessed from the client / caller like this:

4. D365 Ecom development

Surface new field to Ecom site.

(To keep things ‘simple’ I initially just create a new module and see if I can get to the field value).

To get started with this I used Sam Jarawan’s (Microsoft) excellent Ecom development starter guide.
I setup my E-Com development environment and linked it to a ‘regular’ D365F&O Cloud Hosted Environment (CHE). This is just a regular F&O dev box.
The environment does NOT have an E-Com website linked to it, but we don’t need that for our purpose. It does have a retail server, and that’s all we need at the moment. (After all, that’s where we built our CRT extension explained above).

Follow Sam’s doc to create a new ‘product-feature’ module. For this POC I did the bare minimum, but you can follow along the doc for a good idea on how things stick together.

In our example above, we extended the ‘GetProductsDataRequest’, which is called by the Ecom ‘get-simple-product’ action.

DISCLAIMER: the part below is how I currently think it works, I could be wrong in some of my assumptions, but in the end I had a working POC, so I can’t be all that wrong 😊

Using the generated/modified ‘product-feature’ module example from the doc mentioned above:

File ‘Product-feature.tsx’:
Here we reference ‘productsDataAction’:

class ProductFeature extends React.PureComponent<IProductFeatureProps<IProductFeatureData>> {
    public render(): JSX.Element | null {
        const {
            config,
            data: { productsDataAction }
        } = this.props;

This is executed when we load the module, as this references this:

File ‘Product-feature.data.tsx’:

export interface IProductFeatureData {
    productsDataAction: AsyncResult<SimpleProduct>[];
}

This tells me that the return object is of type 'SimpleProduct'.

File ‘Product-feature.definition.json’:

"dataActions": {    
        "productsDataAction": {
            "path": "@msdyn365-commerce-modules/retail-actions/dist/lib/get-simple-products",
            "runOn": "server"
        }

This is where my 'productDataAction' is mapped to the actual E-Com data action.
Looking at the file referenced in product-feature.definition.json ("@msdyn365-commerce-modules/retail-actions/dist/lib/get-simple-products"):

This led me to find that this called the Retail API with ‘ProductManager.GetByIds’, so to recap the full stack:

E-Com DataAction: get-simple-products
Retail Server API: ProductManager.GetByIds
CRT: POST Request Trigger GetProductsDataRequest
- Response = EntityDataServiceResponse

Here are the E-Com changes I made to get this to work:
product-feature.data.ts:
Added the data action:

/*---------------------------------------------------------------------------------------------
 *  Copyright (c) Microsoft Corporation. All rights reserved.
 *  Licensed under the MIT License. See License.txt in the project root for license information.
 *--------------------------------------------------------------------------------------------*/
import { AsyncResult, SimpleProduct } from '@msdyn365-commerce/retail-proxy';

export interface IProductFeatureData {
    productsDataAction: AsyncResult<SimpleProduct>[];
}

Product-feature-definition.json:
Reference the data action that I added in 'product-feature.data.ts:'

{
    "$type": "contentModule",
    "friendlyName": "product-feature",
    "name": "product-feature",
    "description": "Custom Product Feature Module",
    "categories": ["product-feature"],
    "tags": ["Additional tags go here"],
    "dataActions": {    
        "productsDataAction": {
            "path": "@msdyn365-commerce-modules/retail-actions/dist/lib/get-simple-products",
            "runOn": "server"
        }    
    },    
    "config": {
        "productTitle": {
            "friendlyName": "Product Title",
            "description": "The Product Title",
            "type": "string"
        },
        "productDetails": {
            "friendlyName": "Product Details",
            "description": "Product Details",
            "type": "richText"
        },
        "productPrice": {
            "friendlyName": "Product Price",
            "description": "Product Price",
            "type": "string"
        }
    },
    "resources": {
        "resourceKey": {
            "comment": "resource description",
            "value": "resource value from product-feature.definition.json"
        }
    }
}

Product-feature.tsx
Here we process the data as it comes back from the API call. The interesting stuff happens of course with the warranty field, as that is what we added as a new field. The other fields in here are fields that were already part of this API call.
You can see that the field and value are passed as extension properties, ‘key’ being the field name and ‘value’ being the actual value of the field:

/*---------------------------------------------------------------------------------------------
 *  Copyright (c) Microsoft Corporation. All rights reserved.
 *  Licensed under the MIT License. See License.txt in the project root for license information.
 *--------------------------------------------------------------------------------------------*/

import * as React from 'react';

import { IProductFeatureData } from './product-feature.data';
import { IProductFeatureProps } from './product-feature.props.autogenerated';

export interface IProductFeatureViewProps extends IProductFeatureProps<IProductFeatureData> {
    productName: string;
    productInfo: string;
    productPrice: string;
    productWarranty: string;
}

/**
 *
 * ProductFeature component
 * @extends {React.PureComponent<IProductFeatureProps<IProductFeatureData>>}
 */
class ProductFeature extends React.PureComponent<IProductFeatureProps<IProductFeatureData>> {
    public render(): JSX.Element | null {
        const {
            config,
            data: { productsDataAction }
        } = this.props;

        // Set default values
        let ProductName = config.productTitle ? config.productTitle : 'No product title defined.';
        let ProductInfo = config.productDetails ? config.productDetails : 'No product details defined.';
        let ProductPrice = '130';
        let ProductWarranty = 'No Value';
        // If we get the product details from the retail server, then we use that

        if (productsDataAction && productsDataAction.length) {
            ProductName =
                productsDataAction[0].result && productsDataAction[0].result.Name
                    ? productsDataAction[0].result.Name
                    : 'No product data from Retail Server';
            ProductInfo =
                productsDataAction[0].result && productsDataAction[0].result.Description
                    ? productsDataAction[0].result.Description
                    : 'No product data from Retail Server';
            ProductPrice =
                productsDataAction[0].result && productsDataAction[0].result.Price
                    ? `$${productsDataAction[0].result.Price}`
                    : 'No product data from Retail Server';
            if (productsDataAction[0].result && productsDataAction[0].result.ExtensionProperties) {
                ProductWarranty = 'Result and result properties returned';
                let i = 0;
                while (i < productsDataAction[0].result.ExtensionProperties.length) {
                    if (productsDataAction[0].result.ExtensionProperties[i].Key === 'ITKISWARRANTY') {
                        if (productsDataAction[0].result.ExtensionProperties[i].Value) {
                            ProductWarranty = JSON.stringify(productsDataAction[0].result.ExtensionProperties[i].Value?.IntegerValue);
                        } else {
                            ProductWarranty = 'Warranty not specified for item';
                        }
                        i++;
                    }
                }
            }
        }
        const ProductFeatureViewProps = {
            ...this.props,
            productName: ProductName,
            productInfo: ProductInfo,
            productPrice: ProductPrice,
            productWarranty: ProductWarranty
        };
        return this.props.renderView(ProductFeatureViewProps);
    }
}

export default ProductFeature;

product-feature-view.tsx:
And finally we modify the view to show our handy work:

/*!
 * Copyright (c) Microsoft Corporation.
 * All rights reserved. See LICENSE in the project root for license information.
 */

import * as React from 'react';
import { IProductFeatureViewProps } from './product-feature';

export default (props: IProductFeatureViewProps) => {
    return (
        <div className='row'>
            <h2>Product Title: {props.productName}</h2>
            <h2>Product Description: {props.productInfo}</h2>
            <h2>Product Price: {props.productPrice}</h2>
            <h2>Product Warranty: {props.productWarranty}</h2>
        </div>
    );
};

Now that we have it all setup, let’s see if it works:

The nice thing is that due to the way I wrote the code in the 'product-feature.tsx' file, is that right away I know if the data is pulled from the retail server or not.
So now, let’s change the warranty field on our item in F&O (I added it to the UI):

Now we run Retail Scheduler Job 1040 (Products) to push the update to the Channel DB, wait until the updates are applied, and then check again:
Success!

Note: initially the update did not show. I was thinking (hoping) it might be a caching issue, and indeed after I killed and restarted the yarn command, it showed the update:

This is by no means a complete how to, but hopefully it can provide some value.