dynamicscli - a nodejs CLI application and client framework for working with online Microsoft Dynamics applications. The application will not currently authenticate with on-premise systems.
dynamicscli uses the ODatav4 REST data api which means that you must register the application with Azure Active Directory to allow the CLI to connect to the server. Registering is easy to do, but you need Admin access to create the registration. You can use any application registration that allows your userid access to the data and has an application id.
dynamics-client two personalities:
dynamicscli is written in scalajs which is much like typescript but with extensive type-safety.
Why nodejs? nodejs has an extensive array of web oriented resources and is lightweight on memory while still being fast enough. You could also use the client framework for CRM web applications directly. You can also use it for hot-reload, local development that seamlessly integrates with CRM so you get easy development of new CRM UI extensions. Running a nodejs instance on azure also means that you can deploy dynamicscli to azure and have a continuously running Dynamics platform processing platform ready to go.
Currently, you need to build the solution from github. We will publish the CLI progarm on npm shortly.
npm i -g dynamics-client
The script can be run, assuming it is on the path:
If you need to run directly with node,
node /path/to/dynamicscli <args
Dynamics connection parameters should be placed in a json file. The default is crm.json. The file should look like below. Some typical values are also shown but you must find the values that match your application.
"tenant" : "<yourorgname>.onmicrosoft.com""authorityHostUrl" : """username" : "<userid>@<tenant>""password" : "<yourpassword>""applicationId" : "<appid>""dataUrl": "https://<yourorgname>.api.crm.dynamics.com/api/data/v8.2/""acquireTokenResource": "https://<yourorg>.crm.dynamics.com"
Your password can also be in the environment variable
DYNAMICS_PASSWORD as you should avoid passwords in config files that may get checked into version control.
The above shows the domain name to be
<yourorg>.onmicrosoft.com but the domain varies, It could be
dataUrl can be obtained from Developers page in the CRM application's Settings area.
applicationId can only be obtained from our Azure Active Directory application's registration page. Sometimes, applicationId is called clientId.
authorityHostUrl should only be changed if you know that you should change it, otherwise, leave it the same as the value above.
Some information can be inferred if left out. For example, the tenant can be inferred from username and the dataUrl can be inferred from acquireTokenResource but its best to specify them directly.
Once you have created your connection file, use it with the
-c <connectionfile> option. If you connect to several organizations just name the connection file after the organization e.g. myorg1.json or myorg2.json then use it
The general CLI usage is
dynamics command [subcommand] [opts].
dynamics --help to print out help and see the commands.
Some of the things you can do with the CLI include:
See dynamics-client for details.
Ingredients for packaging up parts of a solution deployment are here so you can create your own scripted solution deployer by just creating a directory and a standard script.
All work sponsored by The Trapelo Group.
MIT license. See the LICENSE file.
Copyright 2017 The Trapelo Group.