Tag: C#

The C# programming language

Azure AD

Get group members with Azure AD Graph Client Library

When using the latest (2.1.0) version of the Azure AD Graph Client Library, it is not trivial to figure out how to get a group’s members. Even with the code samples there is still some trickery needed. This post shows you how. It assumes you’ve got the authentication part figured out already, of course.

A few comments are in place.

  1. The creation of the ActiveDirectoryClient on line 2 is ‘hidden’ in the helper method CreateClient(). Not relevant here.
  2. We retrieve a matching user by doing comparison on the Email field. Change this to anything you like.
  3. We use the very convenient ExecuteSingleAsync() since we know we only want one, and don’t care about paging results.
  4. IMPORTANT we cast the user (on line 6) to an IUserFetcher, this enables us to retrieve (paged) results of all group members.
  5. On line 9 we use a simple LINQ filter (OfType()) to get only users. Group members can be of type groups and principals too, but we don’t care about them.

If you need other samples, take a look at this page on Github, it contains a lot of relevant sample code.


Multithreading in CRM

For anyone doing batch processing in Microsoft Dynamics CRM; you’ve most likely experienced how painfully slow it is compared to custom-built solutions. At least that’s how I approached it when I first started working with CRM 2011. Always being performance centric I was curious to see exactly how fast I could get it to run. Said and done, I put together a few samples.

But first a few words…

There are several issues one needs to be aware of. For one, every object written to the database needs to be serialized to SOAP and then deserialized, before being stored in the database. That means the following steps has to happen under the hood:

  1. Establish http connection
  2. Serialize object to SOAP
  3. Send the object(s) over the wire
  4. Deserialize object to SOAP
  5. Establish database connection
  6. Store data in database.

As you can see, there are many steps, which means many opportunities for optimization.

First attempt

This simply uses the ExecuteMultipleRequest, which is a built-in feature. You simply write many objects to the database at once. Done deal, here’s some sample code:

Second attempt

According to the CRM documentation you can have multiple threads running at once. I figured I’d give it a try. But, in order to not make the http connection back to the CRM server act as a bottle neck I figured I should create a unique context per thread. That way I can parallelize all the way back to the CRM server. Note the use of the ServiceConfigurationInstanceMode property on the context. Here’s the sample code:

Some code pointers:

  • Line 10: create a bunch of threads in a for-loop
  • Line 12: create a CRM context per thread
  • Line 18: create an ExecuteMultipleRequest for use by one thread
  • Line 28: Add items to the ExecuteMultipleRequest
  • Line 34: Insert all items in the ExecuteMultipleRequest
  • Line 38: Add the task to a list
  • Line 40: wait for all tasks to finish.

The sample code above uses:

  • The ExecuteMultipleRequest inside each thread loop
  • Multiple threads
  • One CRM context per thread

By utilizing all three concepts above I have managed to do 100 000 inserts in just under 7 minutes.

.NetCodeReactive Extensions

Using Rx in ASP.NET

I recently started an ASP.NET MVC 5 project, and having used Reactive Extensions (Rx) for five years in other projects I was really keen on using Rx in my ASP.NET code also. The question was how? Well, after some tinkering I figured it all out.

Asynchronous action methods

The first thing we’ll take advantage of is the fact that action methods in controllers can be asynchronous. Instead of declaring your action method like this:

You type:

That alone frees up the web server by asynchronously waiting for the response to ‘come back’. This means it can serve other requests in the meantime. The next step is of course converting an observable Rx chain like this:

into an ActionResult . Well, to do that we need an extension method. Basically, we want to convert an IObservable<T> to a  Task<T> . The reason is of course to match the action method’s return type.

Error handling

Also, we need to incorporate error handling, so that any exceptions are handled and the appropriate return value is used. In general I always prefer to have generic (“catch-all”) error handling in place, and then, if needed, we can customize it for specific cases. That way no errors slip through.

How to use it

I decided to use optional parameters for the error handling. Here’s what the default use of my extension method looks like:

You could also write:

And if you want to do specific error handling, you could do:

The extension method

As you can see from the code above you can specify an optional scheduler, as well as a custom timeout period.

Source code

The full source code is available on Github.