The Package Deployer is a great way to move solutions between environments consistently while enabling you to do things like custom tasks and migrating data at the same time.
I hadn’t looked into the data facilities of the Package Deployer but had a project where we were doing more and more manual data imports (small files) so decided to take the leap and see how it works.
There is some good and some bad.
I’ve been working with a customer doing some SharePoint integration with Dynamics365 and when we went to do the first step (which is the simplest) of turning it on. I then went to access the Document Management section of the Account entity only to find that it was gone and not there.
This was a bummer.
In working to get this back, there are two solutions I looked at, both worked.
There is a great article here on how to add the Navigation link back in for Documents. I had never done this before, so this was interesting to do. The directions here are straightforward and easy to follow;
This workaround is a little more involved. But I have
One of the best parts about the JSON Schema evaluation is the simple use of Regular Expressions to validate your data. JSON Schema lets you embed any regular expression into the properties that you create using relatively simple syntax.
In this example, I have a property (called record-id) that uses a regular expression to only allow alphabet characters, spaces, underscores and dashes.
"record-id": {
"$id": "#/record/record-id",
"type": "string",
"title": "A unique identifier, used by the institution to identify the complaint in their source platform.",
"default": "",
"maxLength": 100,
"examples": [
"RECORD-12_345 Y"
],
"pattern": "^(?=.*[a-zA-Z])(?=.*[0-9])[a-zA-Z0-9 _-]+$"
}
What’s great about this is that I can supply defaults and examples to what is being asked, simplifying the task and documentation for the user.
I love this because I’m not an expert at Regular Expression design and if I were to implement this in my own code outside of JSON-Schema – you’re looking at 4 – 5 lines of code on it’s own making my life a lot
I had the opportunity to use the Data Export service in Dynamics365 a few weeks ago. There is a good explanation of the service here and when the implementation is up and running it does a great job of synchronizing data between Dynamics365 and an Azure SQL database.
There were a few gotchas I ran into that I thought I’d write down.
The trickiest part of the initial implementation is setting up the connection to your environment.
To get started, if you haven’t already visited the JSON-Schema site, you can do so here. Much of what I am writing on here, is there.
In defining your schema, there are a few elements I want to highlight in the below definition that starts off any JSON-Schema file.
"definitions": {},
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.365concepts.com/json-schema.json",
"type": "object",
"title": "My JSON Data File",
"required": [
"id",
"people"
],
"additionalProperties": false,
In this document, we have indicated that it will be an object. JSON-Schema supports many attributes one of which is object that allows us to create individual properties on the objects themselves.
The #id property is largely up to you, but take note of the #schema parameter as this is the specification that are binding to that outlines what you can and can’t do within it.
From there you have the standard title and