plugin

Use Plugin Tracing to identify Plugin time-out issues

priyeshwagh777 CRM with .NET Web Applications , ,

In Dynamics plugin implementations, you might have lengthy complex plugins that makes calls to Dynamics several times. I agree that calls to Dynamics should be as less as possible and use Link Entity as much as possible and the plugin should be well designed to handle such lengthy executions.

However, there are instances where these plugins are probably updating some fields that in-turn trigger some other sync processes and the execution begins to take longer than it should.

At times, such lengthy executions result in the plugin timing out. In case of Dynamics 365 Online, the timeout is 2 minutes and you can’t change it. (In on-premise, you can)

actualError

And now, you need to know what’s taking so long! So I want to propose a method which proved effective for me to identify this.

First, in case you are looking to work with Tracing for plugins, here’s a great blog on the same – Debugging Your Plug-ins with the Plug-in Trace Log

Add DateTime to Trace Logs

One of the best approaches to identify what portion of the plugin execution is actually taking time to process is to keep adding Trace logs and that too, with a timestamp!
timestampInCode

This will give you an idea of what part of your plugin is taking long to execute and will give you a fair idea if anything needs to be redesigned.

Set these traces at the very beginning of your plugin and at all necessary places as well as the very end to cover execution cycle well.

And your logs will actually record the time when that operation was hit.

timingsRecorded.png

So now, you have an idea of how the 2 mins are spent and maybe start troubleshooting in that direction.

Hope this quick tip helps!

Advertisement

Modified By (Delegate) & Created By (Delegate) in D365

priyeshwagh777 CRM with .NET Web Applications, Customizations, Dynamics 365, dynamics 365 administration, dynamics 365 customization , ,

These fields which are everywhere but you don’t really pay attention to really mean something worth.

So if you feel you want to get hold of someone for modifying a record. Maybe also take a look at Modified By (Delegate) just in case so that the actual user might be someone else who wanted to do another thing on that record. 🙂

Impersonation is one of the basic aspects of a plugin step that you need to carefully design to let another user (usually Admins for most implementations) make the plugin run under their context instead of giving more security roles/privileges to every other new user.

Well, same goes for Created By & Created By (Delegate) also!

Modified By

Usually, when you update something on a record, the Modified By is updated as expected. But notice that Modified By (Delegate) is not updated.
noDelegate.png

That’s because you are the rightful owner of the record and there’s no other person involved.

But what is someone else is modifying the record (who don’t have access to that record)?

In that case, Modified On (Delegate) field is populated with the name of that user. In such scenarios, Modified By (Delegate) user is the one who caused changes to the record.

delegatedUser

Why Modified By (Delegate) was populated

The reason this was populated was because the record was updated through a plugin by a user who doesn’t have Write access to the record.

But because the user invoked a plugin which was Impersonating as a User who has rights to the records, the record was successfully updated. And this, the actual user who called the plugin is the one who will be populated in the Modified By (Delegate) field.

impersonatingOtherUser

Hope this quick tip helps!

Quickly get the right .NET Framework version to work with CoreAssemblies 9.0.2.x

priyeshwagh777 CRM with .NET Web Applications, Dynamics 365 CE, dynamics 365 customization , , , , ,

Plugin development is a hassle if you don’t start of with getting the correct assemblies in place before you start writing your plugin code.

Best way is to get all of that from the NuGet Manager in VS. Preferably, we all pick the latest version from the NuGet Manager and pick Microsoft.CmSdk.CoreAssemblies. With 9.0.2.x version for v9 D365 environments, you might need to be careful with the .NET Framework version too. So, here’s a quick post about that.

Let’s say you pick Microsoft.CmSdk.CoreAssemblies

coreAssemblies

While installing, you get the below error
error

This is because your VS Project might not be on or might not have the correct .NET framework installed. If you go to Project properties, you can check that.

What version do you need?

Nuget.org will tell you about the version of .NET Framework required for that assembly.
correctVersion

Getting .NET 4.6.2

You can download among the different versions of Developer Packs available across your VS versions from the link below –

Link: https://dotnet.microsoft.com/download/visual-studio-sdks?utm_source=getdotnetsdk&utm_medium=referral

Once you have the correct version, 4.6.2 in this case, you can simply select that Developer Pack and download.

Alternatively, you can also click on Install other frameworks… to get to the link (note that 4.6.2 is not yet installed for me)
installOtherFrameworks

Once you see the downloaded Setup in your browser as shown below, simply run it –
downloadedPack

It sets up like a typical Windows application. Once done, you can check your project properties and select the .NET Framework version you installed.
4.6.2NowInstalled

Re-install Assembly

And when you now try to re-install the assembly, it should be successful and you’ll get all the references you need in your plugin.
successfullyInstalled

Hope this will help! 🙂

Delete Async Plugin Logs if plugin succeeds, save D365 storage space

priyeshwagh777 CRM with .NET Web Applications, Dynamics 365, dynamics 365 customization , , , ,

Let’s see how we can efficiently manage D365 storage without bloating the storage with data that you might not need.

In my opinion, we don’t really need to know that the background process was successful or not, we typically care for what failed.

So, from an Asynchronous plugin standpoint, the logs in D365 is registered in the System Jobs and they create a ton of System Events if you are Importing data in D365 and your Async process is on the create of such records.

sysjobs

Check your Async plugin step

  1. Now, you can preserve this storage space by choosing to Delete the Async plugin logs.
  2. In the screenshot below, you can see an option to ‘Delete AsyncOperation is StatusCode = Successful’
    deletelog

In this case, the System Jobs for the will not be created, thus, saving you valuable storage space if your plugin is run frequently.

Hope this helps.