Today I got the following message… “Could you just fix the reports on this AX 2012 environment… It is broken”
Then I tried to validate the report configuration I got the following error:
The SQL Server Reporting Services server name [servername] does not exist or the Web service URL is not valid.
OK… First test:
Can I browse to the report URLs in System Administration – Business Intelligence – Reporting Services – Report Servers.
No I could not, from the AX Server. it worked from the SQL Server so I checked the firewall on the SSRS Server and added port 80.
I still get the same issue when validating. So I opened the Microsoft Dynamics AX 2012 Management Shell as an administrator and ran Test-AXReportServerConfiguration
What… I opened the port and I can browse to the URLs. Apparently the as scripts tests for Remote Admin Ports so when I open those ports using this netsh command
netsh.exe firewall set service type=REMOTEADMIN mode=ENABLE scope=ALL
Om Shownotes ser konstiga ut (exempelvis om alla länkar saknas. Det ska finnas MASSOR med länkar) så finns de på webben här också: https://www.enlitenpoddomit.se
Avsnitt 385 spelades in den 27 september och därför så handlar dagens avsnitt om:
INTRO: – Alla har haft en vecka… David har fått kakor. Björn har inte lagat mat, men lagt golv i garaget. Johan har haft autopilot vecka.
Today I got a question from one of my colleagues… The needed to sent a complete AIF port specification to an external service provider and the XSD (XML Schema Description) the could find only contained the internal AX Types and it specifically lacked the information about maximum length for the fields.
Since I am not a developer and I am not that knowledgeable in the AOT I reached out to a couple of out developers. Thet is when I learned about Shared Types Schema . This contains the complete list of types and it also acts as sort of a translation table for the regular XSD and which is merged the exploring the service.
Not to self (once I forget this): The reason for having all the extended types in the original XSD is because we are able to change the field setup in AX and having it propagate to the entire system.
To get to the XSD for the AIF port you go to the port (System Administration – Setup – Services and Application Integration Framework). Select the port, verify that Customize Document is checked and clock Data Policies
Click on View Schema
Here you can see the XSD for the port. If you click Imported Schema you will open up the Shared Types Schema. Save both the regular Schema and the Shared Schema and send it to whoever needs it
This time we are interviewing Adrià Ariste Santacreu who is a technical architect and Microsoft Business Applications MVP working out of Madrid. Adrià also wrote the ultimate guide to application lifecycle management for D365 FO. In this talk we discuss the evolution of Dynamics 365 for Finance and Operations, the importance of community and look forward on what the future have in store when it comes to the convergence of ERP and CRM.
Yesterday I looked into an issue for one of my customers. In one of their environments they where not able to activate Data Events for any of their entities. The Activate button was completely grayed out and the “Active Data Events” and “Inactive Data Events” tabs did not exist
This is an environment where we are currently running a PoC for DualWrite so I just “assumed” that I had configured PowerPlatform correctly (you know what we say about assumptions)
Turns out I had not followed my own advice and done the PowerPlatform configuration from LCS… Instead I did the linking from within FnO, in the DataManagement workspace.
The solution was to go through the linking wizard in LCS and then the tabs showed up
Note that the change to the Business Events Screen is not instant… I had to have it sitting over night to have the tabs show up
As a little vacation treat, we give you an episode about Microservices in relation to Dynamics 365 for Finance and Sypply Chain. Which services are available, and when should you use them,
We also discuss the design choices and the pros and cons.
This is a (probably the first) post to try to sort out my experiences around setting up a DataVerse connection to a Finance and Operations environment and figuring out how this interacts with Power Platform Admin Center, LCS and DualWrite.
Background
DualWrite is Microsofts go-to solution for integrating Dynamics 365 CE and Dynamics 365 FnO. It uses Dataverse and PowerPlatform extensively which means that we are, in all essences, merging two separate products into one, which creates some challenges.
Since Microsoft is in the middle of a “Convergence” transition when it comes to managing these things I realize that this is a moving target at the moment, which is why I will need to come back to this this eventually.
This article will address some of the challenges that we have experienced, setting up DualWrite.
Since my primary focus is FnO I will start there.
There are a lot of clues to the fact that Microsoft sees PowerPlatform and DataVerse as an integral part of Dynamics 365 for Finance and Operations. The first one you will notice is that you get the option to create a Power Platform environment when you create a new FnO environment. Another lead is that none of the microservice add-ins that you can deploy from LCS are available to deploy it you have not connected your environment to Power Platform.
There are two different ways to create the DualWrite setup. Setting up a new, empty Environment when deploying a new FnO environment or linking your FnO environment to an existing CRM/CE environment. Please remember that, if you have an existing CRM environment with existing customizations (of a highly customized FnO environment) you should probably think about setting up a proof of concept to evaluate how to handle customizations. Keep in mind that the out-of-box mappings for DualWrite are created for vanilla environments.
Initial Setup
When setting up a new Finance and Operations environment you get the option of also setting up a new connected DataVerse environment. You will not get the option to connect an existing environment. You are able to opt out of this setup at the time of deployment if you want.
Regardless of what you choose the environment will be created and connected from the Power Platform side. On the LCS side there is no indication of any DataVerse environment.
Connecting to PowerPlatform
NOTE: This decision is IRREVERSIBLE. Once you have linked your FnO environment to a Power Platform environment there is no supported way to unlink it.
Once the environment is set up LCS offers an option to set up the DataVerse Connection. You can use the one provisioned for you, if you are not using CRM or if you are not planning to use DualWrite to interface with CRM, or you can link it to your existing Dynamics 365 for Sales (CRM) environment. Even though the connection is done to your existing/live CRM environment the operation should be safe since the Power Platform are being deployed to another “partition” of the environment. I know, the message in the upper right corner looks a bit scarry…
This operation only enabled the install of add-ins, DualWrite still needs to be set up from within FnO when you are ready for it.
Lessons Learned
Since Microsoft is currently moving the management experience of Dynamics 365 for Finance and Operations environments to the Power Platform Admin Center, all of this is a changing scenario and I think what we are seeing is a transition to what is about to come.
Key Take-Aways
Do a gradual rollout, starting with some entities
If there is data that does not need to be synchronized, a different solution such as virtual entities or PowerApps could be an idea
I have learned that it is important to read the fine print… otherwise you will miss things. This happened to me and a colleague the other day.
In Dynamics 365 for Finance and Operations, Microsoft add new features all the time. These are controlled in Feature Management workspace where you can also read up on the new features to understand important impact.
A cool feature is that there is a Data Entity in the Data Management Framework which exports and imports the feature set for a given environment and enables moving feature settings from one environment to another making easier to manage the lifecycle of your features and sync them with for instance releases
Now comes the part that I completely missed (which in hindsight is quite obvious):
There is a column called Enable Date, which I thought meant “The date the feature was enabled”, what it actually means “The date the feature is enabled”… notice the subtle difference?? I did not 🙁
What the column actually does is to set a schedule for when the feature will be enable. When you use DMF to import a list of feature settings with this field set means that you will schedule the enablement of the feature. It is a great feature but might cause some issues if you are not aware of it. Especially for features that can not be turned off.
