Finding Active SDK Message Processing Steps with PowerShell

Code Vanguard has built out several Dynamics-centered build and release pipelines for various projects in service to the federal government. A lot of our build and release process is around normalizing these environments. Since production data lives on these instances, its not so easy as to just reset them. Thus, we’ve built out a whole set of automated actions that we can use on release to bring them back into conformity.

Recently, a client needed us to extend this functionality to be able to analyze which SDK message processing steps were enabled in a CRM. Additionally, they needed to be able to turn them on or off, depending on the type of deployment.

While doing this, we found that simply finding the steps was not as easy as we first assumed. We wanted to take the time to write this blog post to explain the gotcha that we got hung up on, and what we learned from it.

Finding the Steps

Originally, our plan was to:

1. Query for the solution of interest by name using the CRM Service client.
2. Query all of the SDK Message Processing Steps where the step’s solution ID is the same as the solution ID we found in the first step

When doing this, the query consistently returned no steps returned, even though we knew that there were steps registered to that solution.

So, we decided to work backward. We instead queried for a step we knew to be in the solution. Then, we took the solution ID from that step and queried for the solution with that ID. With that, we landed on the crux of the problem: When steps are registered and published, they are no longer children of the solution that registered them. They instead become part of a solution called Active. When you want to query for all of the registered steps in a CRM instance, you must query using the ID of the Active solution.

According to Microsoft:

“The Active solution represents the current published unmanaged customizations that define the behavior of the application.”

Additionally, their documentation tells us that the active solution reliably has the same ID: FD140AAE-4DF4-11DD-BD17-0019B9312238. Thus, it’s easy to write a script that to find the active solution that will work against all CRM instances.

Below is the PowerShell we ended up using to find the active steps. This script uses the $crmService that we created using the CRM Service Client script we wrote last week.

# Define constants
$STEP_LOGICAL_NAME = "sdkmessageprocessingstep";
$ACTIVE_SOLUTION_ID = "FD140AAE-4DF4-11DD-BD17-0019B9312238";

## Fields
$NAME = "name";
$SOLUTION_ID = "solutionid"
$STATE_CODE = "statecode";
$STATUS_CODE = "statuscode";

$query = New-Object -TypeName Microsoft.Xrm.Sdk.Query.QueryExpression -ArgumentList $STEP_LOGICAL_NAME;
$query.ColumnSet.AddColumn($NAME);
$query.ColumnSet.AddColumn($SOLUTION_ID);
$query.ColumnSet.AddColumn($STATE_CODE);
$query.ColumnSet.AddColumn($STATUS_CODE);
$query.Criteria.AddCondition($SOLUTION_ID, [Microsoft.Xrm.Sdk.Query.ConditionOperator]::Equal, $ACTIVE_SOLUTION_ID);

# Execute Query
Write-Host "Retrieving steps"  
$results = $crmService.RetrieveMultiple($query); # CRM Service created in previous post
$records = $results.Entities;

Using this script, we were able to retrieve all of the SDK Message Processing Steps and process them.

Keep a look out for future posts about configuring Dynamics CRM with PowerShell! And if you’d like Code Vanguard to help your organization with its DevOps process, feel free to reach out to us!

Check out some of our other posts about Dynamics CRM!