DevOps ALM automation in Microsoft Dynamics 365 for Finance and Operations

I’ve already written some posts about development Application Lifecycle Management (ALM) for Dynamics 365 for Finance and Operations in the past:

The possibility of doing real CI/CD is one of my favorite MSDyn365FO things, going from “What’s source control?” to “Mandatory source control or die” has been a blessing. I’ll never get tired of saying this.

Plus the post ends with an extra bonus!

More automation!

I’ve already explained in the past how to automate the builds, create the CI builds and create the release pipelines on Azure DevOps, what I want to talk about in this post is about adding a little bit more automation.

Builds

In the build definition go to the “Triggers” tab and enable a scheduled build:

This will automatically trigger the build at the time and days you select. In the example image, every weekday at 16.30h a new build will be launched. But everyday? Nope! What the “Only schedule builds if the source or pipeline has changed” checkbox below the time selector makes is only triggering the build if there’s been any change to the codebase, meaning that if there’s no changeset checked-in during that day no build will be triggered.

Releases

First step done, let’s see what can we do with the releases:

The release pipeline in the image above is the one that launches after the build I’ve created in the first step. For this pipeline I’ve added the following:

The continuous deployment trigger has been enabled, meaning that after the build finishes this release will be automatically run. No need to define a schedule but you could also do that.

As you can see, the schedule screen is exactly the same as in the builds, even the changed pipeline checkbox is there.  You can use any of these two approaches, CD or scheduled release, it’s up to your project or team needs.

With these two small steps you can have your full CI and CD strategy automatized and update a UAT environment each night to have all the changes done during that day ready for testing, with no human interaction!

But I like to add some human touch to it

If you don’t like not knowing if an environment is being updated… well that’s IMPOSSIBLE because LCS will SPAM you to make sure you know what’s going on. But if you don’t want to be completely replaced by robots you can add approvals to your release flow:

Clicking the left lightning + person button on your release you can set the approvers, a person or a group (which is quite practical), and the kind of approval (all or single approver) and the timeout. You will also receive an email with a link to the approval form:

And you can also postpone the deployment! Everything is awesome!

Extra bonus!

A little tip. Imagine you have the following release:

This will update 3 environments, but will also upload the same Deployable Package three times to LCS. Wouldn’t it be nice to have a single upload and that all the deployments used that file? Yes, but we can’t pass the output variable from the upload to other stages 🙁 Yes that’s unfortunately right. But we can do something with a little help from our friend Powershell!

Update a variable in a release

What we need to do is create a variable in the release definition and set its scope to “Release”:

Then, for each stage, we need to enable this checkbox in the agent job:

I explain later why we’re enabling this. We now only need to update this variable after uploading the DP to LCS. Add an inline Powershell step after the upload one and do this:

You need to change the following:

  • Line 2: $assetId= “$(GoldenUpload.FileAssetId)”. Change $(GoldenUpload.FileAssetId) for your output variable name.
  • Line 6: $ReleaseVariableName = ‘axzfileid’. Change axzfileid for your Release variable name.

And you’re done. This script uses Azure DevOps’ REST API to update the variable value with the file id, and we enabled the OAuth token checkbox to allow the usage of this API without having to pass any user credentials. This is not my idea obviously, I’ve done this thanks to this post from Stefan Stranger’s blog.

Now, in the deploy stages you need to retrieve your variable’s value in the following way:

Don’t forget the ( ) or it won’t work!

And with these small changes you can have a release like this:

With a single DP upload to LCS and multiple deployments using the file uploaded in the first stage. With approvals, and delays, and emails, and everything!

And now the bad news

The bad news are that, right now, we can’t automate the deployments in self-service environments. We can’t either do this on a production environment, where we must do this manually.

Invent counting with AI Builder

This past weekend I’ve attended my third 365 Saturday, this time in Barcelona, as a speaker. As you can see in the post title my session has been about creating inventory counting journals using AI with the Power Platform.

The event has been great, but my session has left me with a bittersweet feeling because I haven’t been able to show the full app functionality due to stupid technical issues (which where stupid but were my fault) that I solved in less than two minutes after the session.

Me while fixing the issue AFTER the session

Anyway, thanks to all the people that came to my session and I’m sorry for that. Thanks to the organizers too, as well as the rest of the speakers and the Axazure team.

Counting with AI

So… what was my session about? Nothing original at all. If you’ve seen the 2019 MBAS opening keynote there was a part about a Pepsi distributor that was using AI Builder to scan their store displays and analyze how sales were performing (more or less). My PowerApp uses AI Builder to count objects (you’ll see which objects later) and with that, create an inventory counting journal on Dynamics 365 for Whatever-you-know-the-ERP.

But in the end, my main intention with the session was showing that we can use all the Power Platform with MSDy365FO, not only Power BI, and that it can help in our projects. Because in AX world we’re sometimes like:

I saw this on twitter and I added the logos, but I don’t remember where I stole it from 🙁

AI Builder

AI Builder is a tool for the Power Platform which adds AI functionality to PowerApps and Flow. And it’s really really really simple to set up and use.

Right now AI Builder consists of 4 different models:

  • Prediction: answers binary questions like “Will the customer renew the subscription?” or “Which customer will not pay on time?”.
  • Text classification: data extraction from texts. You get a sentiment % as an answer, 95% Good, 76% Quick, etc.
  • Form processing: data extraction in key-value pairs. Like getting info from an invoice or document (it must always be the same invoice or document).
  • Object detection: detects objects in images. That’s the model I used.

Of these four models only the prediction one is in GA, while the others are in preview. There’s also 5 pre-trained models available:

If you want to know more about AI Builder, there’s a hands-on-lab with all the needed resources to create your App using any of the four models.

Also, if you need a PowerApps environment sign for a PowerApps Community Plan to get a free environment where you’ll be able to use everything you need to and test Flow and PowerApps (and the CDS). If you haven’t signed up yet it’s the right time to do it (any time would be right).

AI 101

To explain how does this work, first I need to explain some AI and ML basics. But real basic, like, as basic as possible so I could explain it in front of an audience. If you want to see this better explained see this Channel 9 video about models, it’s from where I learnt everything I know.

In classic development when you solve a problem you basically get input data and your created function through a process and get a result as an output. The equivalent to this in machine learning is that you get input and solutions through a process and you get a function that will solve the problem related to the solutions you entered. This function is your ML model.

What else you need to know about models? Well, basically that the amount of data you feed the model with is directly proportional to the quality of the answers/solutions you’ll get. In AI Builder’s case, the object detection model asks for a minimum of 15 images. With 15 images you get a shitty model, it will detect the object you’re trying to detect, but it will detect almost anything as your object because the sample is too small.

The PatatApp

This is my app’s name, a joke using the Spanish name for Potato (Patata) and App.

Why this name? Well, I’m actually counting potatoes with the app. Why potatoes? I love them, they’re versatile (you can make omelette, fries, vodka, etc.) and because counting pallets is BOOOORING.

What my PowerApp does is detect potatoes in an image. Then I can choose between using an existing journal or creating a new one, then select an item, fill in its inventory dimensions and finally create the line in that journal in AX. I’ve made a short video showing it.

Simple, right? I detect 3 potatoes using AI Builder, then select a legal entity, create a new journal and select an item with its dimensions. Finally the line is created in the journal and it can be seen in MSDyn365FO.

No sorcery or magic at all. (Oh, I hate the “magic” thing when speaking about development, or anything, because it makes it look like its been done with no effort. End of my rant). To create the journal header and the line I’m using two Flows that get the data from the PowerApp and create it into Dynamics 365:

See? No magic, just a flow.

My colleague Hugo de Jesús suggested to use the Patch function on the data source but: 1) The app was finished 2) He told me the week before the event. But it would probably have worked as well.

As you can see it’s a really simple app, I had a first working version in four hours, with AI Builder and the Flows it’s really quick.

Shitty model vs. Not-so-shitty model

I want to end with real facts and important data. Remember the minimum number of images AI Builder asks for? It’s 15. This is what happens when your model consists of 20 images of lonely potatoes:

   

If your model sucks you will still detect all the potatoes in an image, but literally everything will be a potato.

I then trained a second version of the model with 40 images of potatoes with people, cats, other vegetables, etc. The result is much better, and it still detects potatoes:

         

I want to thank cazapelusas for drawing all the lovely potatoes and redesigning the PowerApp, you should have seen V1. Please adopt a graphic designer, your life will be prettier.

No potatoes were harmed during the making of this PowerApp.

Setup Entity Store’s export to Azure Data Lake storage

It’s easy to start this post, because many people can ask:

What’s a Data Lake?

Fishing in a Data Lake. By cazapelusas.

A Data Lake is not an Azure product but a term referring to a place where data is stored, regardless of whether it’s structured or unstructured. Its only purpose is storing the data ready to be consumed by other systems. It’s like a lake that stores the water of its tributaries, but instead of water with data.

In Azure the Data Lake is a Blob storage which holds the data. And this data can come from Microsoft Dynamics 365 for Finance or Supply Chain Management (I’ll go crazy with the name changes of Axapta 7) or from other sources.

Currently, and since PU23, #MSDyn365FO (#MSDyn365F ? or #MSDyn365SCM ?) officially supports exporting the Entity Store to Azure Data Lake storage Gen1, but compatibility with Data Lake Storage Gen2 is on the works in a private program with Data Feeds that will allow us to export entities and tables (YES!) in near real time. If you want to know more check the Data Management, Data Entities, OData and Integrations Yammer group in the Insider Program (if you still haven’t joined, you should).

Comparison vs. BYOD

The first thing we must notice is the price. Storage is cheaper than a database, even if it’s a single SaaS DB on Azure SQL. For example, a 1GB Blob storage account on Azure costs $21.6/month.

And the simplest Gen 4 with 1 vCore Azure SQL database costs $190.36/month. Almost 10 times more.

And what about performance? This comes from observation, not a real performance test, but data is transferred real fast. And it’s fast because in a Data Lake data is sent raw, there’s no data transformation until it’s consumed (ETL for a DB, ELT for a Data Lake) so there’s less time spent until data reaches its destiny. This doesn’t have a real impact for small sets of data but it does for large ones.

Setup

The process to export the Entity Store to a Data Lake is pretty simple and it’s well documented (but not updated) on the docs. I’ll explain step by step.

Create a storage account on Azure

On Azure go to or search in the top bar for Storage accounts and add a new one with a setup like the one in the pics below:

Make sure to disable Gen2 storage:

And you can go to review & create. When the account is ready go to Access Keys and copy the connection string:

Azure Key Vault

The next step is creating a Key Vault. For this step you need to select the same region as your Dynamics 365 instance:

When the Key Vault is ready go to the resource and create a new secret. Paste the connection string from the storage account into the value and press create:

Create an AAD App Registration

Now we’ll create an AAD App. Give it a name, select the supported account types you need and fill the URL with the base URL of your #MSDyn365FO instance:

Click register and now we must add the Azure Key Vault API to the app as in the image below:

Select the API and add the delegated user_impersonation permission:

Don’t forget to press the button you can see above to grant privileges (must be done by an Azure admin). Now go to secrets and create a new one, give it a name and copy the secret value. When you close the tab you will not be able to recover that secret anymore so copy it and save it somewhere until we need it.

Setup the Key Vault

Go back to the Key Vault we created in the second step and go to Access policies. Add a new one:

You have to select Get and List for Key and Secret permissions:

Now press Select principal and here add the AAD App created in the third step:

Add it and don’t forget to save in the access policies screen!!

Set up MSDyn365F… and O or and SCM or whatever its name is this month

Navigate to System Administration -> Setup -> System parameters and go to the Data Connections tab. Here there’s 4 fields for the key vault. The Application ID field corresponds to the Application ID of the AAD App (pretty obvious) and the Application Secret is the secret from the AAD App. This part is easy and clear.

The DNS name is the url on your Key Vault and the Secret name field is the name of your Key Vault’s secret where you pasted the storage account connection string.

Once all these fields are complete you can press Test Azure Key Vault and Test Azure Storage and, if you followed all steps correctly, you should see the following messages:

If any of the validations don’t succeed I’d just delete all resources and start from scratch, probably a secret mismatch.
Now, the two buttons you see next to the setup fields:
  • Enable Data Lake integration: will enable the full push of the entity store to the storage account you have just created and which is the main purpose of this post.
  • Trickle update Data Lake: will make updates after data is changed (Trickle Feed).

Setup Entity Store

Now we just need to go to the Entity Store (under System Administration -> Setup -> Entity Store) and enable the refresh of the entities we’d like to hydrate the Data Lake (I love this, it looks like it’s the correct technical word to use when feeding the Data Lake):

And done, our data is now being pushed to an Azure Blob:

The entities are saved each in a folder, and inside each folder there another folder for each measure of that entity and a CSV file with the data in it.

Now this can be consumed in Power BI with the blob connector, or feed Azure Data Factory or whatever you can think about, because that’s the purpose of the Data Lake.

 

Manually deploy Retail packages for Microsoft Dynamics 365 for Finance and Operations

First Microsoft Dynamics 365 for Finance and Operations Retail post! I hope more will come.

As you might know, one of the setbacks of the database refresh from production in LCS is that some data doesn’t get copied. This is a safety feature that prevents, among others, that emails are sent or batches run accidentally after a DB restore.

Remember that it’s a good idea to have a SQL query/script that changes all endpoints, passwords, enables users, etc. that you can run after a prod DB refresh, just like it was done with AX2009/2012. Just F5 it in SSMS and the environment will be ready to use and to export to your dev boxes.

Another thing that doesn’t get moved after a DB refresh are storage specific files, ER XLSX, DocuValue files and the self-service Retail installers.

Retail packages

Retail packages are the executable files used to install MPOS on the… well, on the points of sale (POS). These files are stored in an Azure blob storage which is specific to each environment, so after the DB refresh there’s no self service packages in the target environment because the reference was to the production blob:

Microsoft’s official fix for this is applying a binary package that will recreate the EXE files in the VM’s storage where the Deployable Package is run. And as you all know this is time consuming and while you can run it outside working hours you can fix it in less than 10 minutes.

The workaround

Ahhh “workaround”… it’s such a beautiful word with so many different meanings… And this workaround has a restriction: it only applies to dev boxes and Tier 2+ regular environments, this can’t be done on self-service environments as we don’t have access to the AOS VM.

What we need to do is log into the AOS VM using the RDP and go to the service volume (usually K on dev, G on Tier 2+). There should be a folder called DeployablePackages, if you have applied any, otherwise just go with the official fix. However, if the folder doesn’t exist this can probably be done in another way, which is using the files from the install drive, but I haven’t tried.

Sort the files by date modified (newer first) and inside the first folder you should see another folder called RetailSelfService:

And inside this folder you’ll see 3 more folders, Packages, Scripts and ServiceModel. Inside the Packages folders there’s the EXE files and inside the Scripts folder the scripts (obviously Mr. Obvious), open it and the open the Upgrade folder and you’ll find a PowerShell script called UpdateRetailSelfService. You need to run this script in PowerShell as an administrator. It will take between 3 and 5 minutes and when it’s done the packages will be uploaded to the environment’s storage and appear in the Retail Parameters form.

That doesn’t work for me!

There’s a case in which the installers will not be restored: if you have no setup done for Retail. Why? The PowerShell script runs a SQL query that will check for the following:

  • Has Channel data in Channel DB
  • Has any Channel data in AOS
  • Has transaction data in AOS
  • Has transaction data in Channel DB
  • Has Channel DB extensions

If none of the above conditions is met the script will not upload the installers to the blob. But we can do something! Yes, you can go and configure a Channel DB for instance. But what if you don’t feel like doing it?

Remember the UpdateRetailSelfService script I talked about before? Edit it and comment the following lines:

This will make the script skip the check and will deploy the installers.

That’s pretty dirty, right? Yes.

What about self-service environments?

I’m sure this can be also done modifying a Deployable Package that contains the Retail packages (the one for a monthly version update), leaving Retail only in the DefaultTopologyData.xml file, and even editing the script if needed. But I haven’t tried. Any volunteers?