In
part1 and
part2 of this blog series we looked at scaffolding and building an authentication helper which we can use in a commandlet class. In this part we're going to build our own HTTP message handler and perform some queries against the adminapi.
The code in it's entirety is available on
this Github repository.
Creating a custom HTTP message handler
As we saw previously we now have a valid bearer token which we can use to query the adminapi. We can now create a HTTP request and send it to the API to get a result back. But instead of starting from scratch we're going to reuse the code from the
Microsoft docs and create our own custom message handler which will instantiate and propagate everything we need, as well as injecting the token into the request.
Go into the AuhtenticationHelper class, and append the following code to the end of the class (inside the AuthenticationHelper declaration).
class OAuthMessageHandler : DelegatingHandler
{
AuthenticationHelper _auth = null;
public OAuthMessageHandler(AuthenticationHelper auth, HttpMessageHandler innerHandler) : base(innerHandler)
{
_auth = auth;
}
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
request.Version = HttpVersion.Version11;
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", _auth.AuthResult.AccessToken);
request.Headers.AcceptLanguage.Add(new StringWithQualityHeaderValue("NORWEGIAN-VIKING"));
return base.SendAsync(request, cancellationToken);
}
}
This class inherits from the delegation handler, which takes care of all the basic stuff for us. It has an AuthenticationHelper property which we set in the public constructor, as well as a HTTPMessageHandler which is sent to the base constructor.
Please notice the AcceptLanguage header that has been set. This is not necessary for the GET requests (at the time of writing), but it is required for the POST requests. As you might notice I haven't specified a valid language, and what happens then is that it defaults to english.
If, however, I was to specify nb-NO then the response would be in Norwegian, so there's a nice trick for you.
Next we override the SendAsync method to inject our headers. What we've done here is get the Access token from the AuthResult in the AuthenticationHandler. What this means is the following:
- When the AuthResult property is retrieved it triggers the Authorize() method which uses the AuthContext property.
- When the AuthContext property is retrieved it instantiates a new AuthenticationContext object with the Authority property.
- When the AuthorityProperty is collected the DiscoveryAuthority method is triggered, which retrieves the 401 challenge which gives us the resource and authority based on the service URL set in the public constructor of the AuthenticationHelper class.
This means that everything we need is instantiated and propagated just by setting this one authorization header and accept-language, and it's easy to follow the flow of the code.
Finally we add a public property which will return a new instance of the handler. The handler will be disposed when we complete the request, so we need to make sure that we're instantiating a new one whenever we get it.
public HttpMessageHandler Handler
{
get
{
return new OAuthMessageHandler(this, new HttpClientHandler());
}
}
We are finally ready to actually perform some requests against the admin API.
Sending requests to the adminapi
To send a request we must first add some code to our commandlet. Add the following lines to the end of the ProcessRecord method to perform the request, and then print the response to the console.
using (var httpClient = new HttpClient(auth.Handler))
{
var result = httpClient.GetStringAsync(serverUrl).Result;
Console.WriteLine(result);
Console.ReadLine();
}
Because we're doing this in a script we're not bothering with async requests. We want the result at once, and we're not doing anything before the response is returned.
Once entered, hit [F5] to start debugging. Log in with the credentials of an MSDYN365 admin, and log in.
If this is the first time you've logged in with that user then you will be presented with the following window which you need to approve
This simply says that it will use your authenticated credentials to perform actions on your behalf, and read the directory information (needed to pass claims to MSDYN365).
It looks more severe than it really is, if you're running code that asks you for credentials then this is not the thing you should be worried about.
Once the request is completed the output to your PowerShell window should look like this:
Congratulations! You're using the new adminapi!
Reusing the connection in additional commandlets
When we extend this project to include more commandlets we should try to reuse our connection. To do this we should make a few changes changes to our commandlet.
[Cmdlet(VerbsCommon.Get, "DynamicsInstances")]
public class GetDynamicsInstances : PSCmdlet
{
[Parameter(Mandatory = true)]
[ValidateSet("NorthAmerica", "SouthAmerica", "Canada", "EMEA", "APAC", "Oceania", "Japan", "India", "NorthAmerica2", "UnitedKingdom", IgnoreCase = true)]
public string Location;
private AuthenticationHelper _auth = null;
protected override void ProcessRecord()
{
base.ProcessRecord();
Enum.TryParse(Location, out DataCenterLocations tenantLocation);
var serverUrl = UrlFactory.GetUrl("admin.services", tenantLocation, "/api/v1/instances");
if (SessionState.PSVariable.Get("auth") != null)
{
_auth = SessionState.PSVariable.Get("auth").Value as AuthenticationHelper;
}
else
{
_auth = new AuthenticationHelper(serverUrl);
}
using (var httpClient = new HttpClient(_auth.Handler))
{
var result = httpClient.GetStringAsync(serverUrl).Result;
Console.WriteLine(result);
Console.ReadLine();
}
SessionState.PSVariable.Set("auth", _auth);
}
}
As you can see we've now added a private _auth property to the cmdlet.
In addition we put an if clause that checks whether there is an existing PSVariable named "auth". If that's the case then it is assigned to the _auth property.
If it is not present we instantiate a new AuthenticationHelper object and assign that to the property.
At the end of the class we've added a line which sets a PSVariable named "auth", and we set the object to our AuthenticationHelper object. This will store the instantiated AuthenticationHandler object in the PowerShell session, so we can reuse it while in the same session.
To demonstrate this copy the content of this class, and create a new class named GetDynamicsInstaceTypeInfo.
Paste the code in the new class, and change the following lines:
- Change the cmdlet decoration to say "DynamicsInstanceTypeInfo"
- Change the class name to GetDynamicsInstanceTypeInfo
- Change the trailing part of the serverUrl to "/api/v1/instancetypeinfo"
Next go into the properties of the project, and change the command line arguments to the following
-NoLogo -Command "Import-Module '.\MSDYN365AdminApiAndMore.dll'; Get-DynamicsInstances -Location EMEA; Get-DynamicsInstanceTypeInfo -Location EMEA"
Now, start a new debug session, and log in as you did previously. You will get the same list of instances as you did before, but if you hit return then it will perform a new request to get instance types. This request will complete without re-asking for your credentials, which means we're successfully storing and retrieving the PSVariable in our session.
Extending the authentication class to support MSDYN365 data API
Our authentication helper works great, but we make it even greater by making it able to handle normal MSDYN365 auhtentication as well. The problem we face with this is that to get the WWW-Authenticate headers from the MSDYN365 Customer Engagement API we need to use a different URL path than for the admin services.
Where the admin services uses "/api/aad/challenge", the data API uses "/api/data". This means that we'll have to modify the AuthenticationHelper class to take the complete discovery URL as an input in the public constructor. To do this, we're changing the private _endpoint variable to be of type Uri instead of string, and in the Authority property we just pass in the _endpoint instead of the _endpoint and the path.
The result should look like this:
private Uri _endpoint = null;
private string _resource = null;
private string _authority = null;
private AuthenticationContext _authContext = null;
private AuthenticationResult _authResult = null;
public AuthenticationHelper(Uri endpoint)
{
_endpoint = endpoint;
}
public string Authority
{
get
{
if (_authority == null)
{
DiscoverAuthority(_endpoint);
}
return _authority;
}
}
Now, go into the UrlFactory-class and add a new enum named ApiType, and add Admin and CustomerEngagement as values.
public enum ApiType
{
Admin,
CustomerEngagement
}
Next add a new static method named GetDiscoveryUrl which takes an Uri and an ApiType enum as input, and returns a Uri.
public static Uri GetDiscoveryUrl(Uri serviceUrl, ApiType type)
{
var baseUrl = serviceUrl.GetLeftPart(UriPartial.Authority);
if (type == ApiType.Admin)
{
return new Uri(baseUrl + "/api/aad/challenge");
}
else if (type == ApiType.CustomerEngagement)
{
return new Uri(baseUrl + "/api/data");
}
else
{
throw new Exception($"Enum with name {type.ToString()} does not have discovery address configured");
}
}
This allows us to extend with additional APIs in the future, for example for Operations or Financials.
Now, go back into our commandlet classes and modify the else clause to look like this:
else
{
var discoveryUrl = UrlFactory.GetDiscoveryUrl(serverUrl, ApiType.Admin);
_auth = new AuthenticationHelper(discoveryUrl);
}
Then change the AuthenticationHelper instantiation to take the discoveryUrl as a parameter instead of the serviceUrl. Remember to change this in both of the commandlets.
Finally, change the PSVariable name from just "auth" to "adminauth", remember to do it for both commandlets, in both when you get and set the variable.
We now have an even more flexible project which can support multiple APIs, and store the authenticated connection in the PowerShell session.
Testing MSDYN365 Customer Engagement
To test our new capabilities, add a new class file to the project named "GetDynamicsWhoAmI", and paste in the following code.
[Cmdlet(VerbsCommon.Get, "DynamicsWhoAmI")]
public class GetDynamicsWhoAmI : PSCmdlet
{
[Parameter(Mandatory = true)]
public string Organization;
[Parameter(Mandatory = true)]
[ValidateSet("NorthAmerica", "SouthAmerica", "Canada", "EMEA", "APAC", "Oceania", "Japan", "India", "NorthAmerica2", "UnitedKingdom", IgnoreCase = true)]
public string Location;
protected override void ProcessRecord()
{
base.ProcessRecord();
Enum.TryParse(Location, out DataCenterLocations tenantLocation);
var customerEngagementUrl = UrlFactory.GetUrl(Organization, tenantLocation, "/XRMServices/2011/organization.svc/web");
AuthenticationHelper customerEngagementAuth = null;
if (SessionState.PSVariable.Get("customerengagementauth") != null)
{
customerEngagementAuth = SessionState.PSVariable.Get("customerengagementauth").Value as AuthenticationHelper;
}
else
{
var customerEngagementDiscovery = UrlFactory.GetDiscoveryUrl(customerEngagementUrl, ApiType.CustomerEngagement);
customerEngagementAuth = new AuthenticationHelper(customerEngagementDiscovery);
}
var client = new OrganizationWebProxyClient(customerEngagementUrl, false)
{
HeaderToken = customerEngagementAuth.AuthResult.AccessToken,
SdkClientVersion = "8.2"
};
var whoAmI = client.Execute(new WhoAmIRequest());
foreach (var att in whoAmI.Results)
{
Console.WriteLine($"{att.Key}: {att.Value}");
}
Console.ReadLine();
SessionState.PSVariable.Set("customerengagementauth", customerEngagementAuth);
}
}
What this does is to get a service and discovery URL for the MSDYN365 Customer Engagement URL for the organization specified. Then it instantiates a new AuthenticationHelper based on the discovery URL.
Then, instead of using a normal HTTP request we instantiate a new OrganizationWebProxyClient, and we inject the OAuth token into the HeaderToken. This means we can do Organization requests against the API, and we can use early bound classes if we've created them (
did anyone mention XrmToolBox).
Next we send a new WhoAmIRequest to the service, and we print the values returned to the console.
In addition, we're getting and setting the value as a PSVariable, so we can reuse that as well.
Open up the properties for the project, and inside the debug section change the command line arguments to the following. Remember to change YourOrganizationNameHere to your actual organization name (the X in https://X.crm.dynamics.com), and eventually the location)
-NoLogo -Command "Import-Module '.\MSDYN365AdminApiAndMore.dll'; Get-DynamicsInstances -Location EMEA; Get-DynamicsInstanceTypeInfo -Location EMEA; Get-DynamicsWhoAmI -Organization YourOrganizationNameHere -Location EMEA;"
This will run all of the commandlets we have created so far, so save the changes and hit [F5] to run it.
When it starts it will ask you for credentials just like last time. Provide that and wait for the instance response. When the instances are printed to the console, hit return to start the next query. Now it will not ask you for credentials, it will simply take a few seconds and then return the instance type codes. Hit return again, and now you will get a new window asking you for credentials. This is when the Customer Engagement authentication is instantiated. Fill in the credentials like before, and wait for the response.
If you've done everything correct, you will see the following output in your terminal
Congratulations! You now have the basis for automating almost everything related to your MSDYN365 Customer Engagement environment. Just hit return to end the processing.
The wrap up
So, we now have a new awesome API (with more functions to come), and we have an awesome project which will allow us to write easy-to-use commandlets which can be used to simplify administration (especially for those admins who aren't familiar with the interface) and automate mundane tasks.
Exception handling and unit tests. There really should be more exception handling to this, but I leave that in your capable hands to figure out (or I will update
the project later).
