How to create an activity attachment using WebApi in Dynamics 365

Very short post today – just wanted to share with you a piece of code which you can use to create an attachment for any activity in Dynamics 365. This is different from normal attachments, because you are not doing this by adding Annotation, rather ActivityMimeAttachment object. It’s important to remember that when you are migrating data – moving only Annotations will not transfer all Email or Appointments attachments to the new system!

Query Builder Error when exporting solution in Dynamics 365

Solutions in Dynamics 365 are very useful and there is no doubt about that. One of the latest features is possibility to add single fields, views or forms to the solution, not the whole entity with all its dependencies. That allows us to better control what is transferred and deployed on out staging and production environments. Few times I came across the problem, which is caused clearly by this granularity of solutions:

error

Query Builder Error

The specified field does not exist in Microsoft Dynamics 365

Fortunately this error was in on-premise environment, so I was able to check the tracing logs and the problem has become clear:

“attribute with id=’86e616c0-64fc-413c-9957-470272c3f198′ does not exist”

So, apparently, someone has removed some attribute from the system, but somehow it was orphaned in our solution and is causing the export to fail (no doubt – we are trying to export the solution, so system is getting all the metadata, for all the Solution Components and cannot find one of the component). This is very unfortunate, because we cannot see this missing object in the solution view, it’s only in database in SolutionComponentBase table.  In on-premise environment, it’s not a problem – we simply check the id in traces and then go to our database and do:

SELECT FROM SolutionComponentBase  where ObjectId = ‘guid of missing component’

This will get us the failing components from all our solutions. We can remove them on DB level (sic!) but if you are afraid that this is not supported (which it is, but really cannot break anything) you can do it using SDK.

But what if we have online instance without access to the database? We can request Microsoft Support for the traces and then we will know which attribute is failing. But if we are in a hurry, we would have to loop through all Solution Components is our solution, check if it exists in the system and remove it from the solution. I believe that in 99% of cases, the missing component would be an attribute, so here is the code that would help you to get rid of this error:

It simply iterates through all attributes in the solution and tries to retrieve metadata for each one of them. If it fails, it simply removes this component from the solution. That should be enough for most of the cases, but if there will be any other component types missing, you will have to modify the code to check for those missing components (which I described in one of my previous posts). I have prepared a very simple program, that iterates through all of the solution components and tries to retrieve every single type – and if it fails it just removes it from the solution. Feel free to use it for any means necessary:

https://github.com/pawelgradecki/SolutionExportFixer

Dynamics 365 – Create SharePoint folders without GUID

If you have ever come across the problem that Dynamics CRM out-of-the-box documents integration creates SharePoint folders with GUID appended to the record name, you probably wonder if this can be disabled in a supported way. The answer is – yes it can, but you cannot do it using CRM Web Interface. Instead, it can be achieved by using the tool OrgDBOrgSettings which is available alongside all other Dynamics 365 related downloads. Firstly, go to the:

https://www.microsoft.com/download/details.aspx?id=55117

Scroll down and choose CRM2016-Tools-KBXXXXXXX-ENU-amd64.exe. After downloading the tool, extract it to some folder and open Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe.config file. Inside you will have to provide some authentication details – most likely you are not connecting to CRM 4.0, so you can skip OrgDBOrgSettingsTool_CrmService_CrmService, but you should fill:

After you filled in all this information, you can simply run the tool the following way:

 Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Retrieve [/u] <OrgName>

Which (after providing the password) will give you all the settings for the orgname (/u specifies if this is unique name of the organization or friendly name), so for example:

Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Retrieve /u orgname

settings

If you want to update some setting you can run:

Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Update [/u] <OrgName> <SettingName> <Value>

All the settings, with allowed values, are listed here:

https://support.microsoft.com/en-us/help/2691237/orgdborgsettings-tool-for-microsoft-dynamics-crm

I advise every admin/customizer to look through this options, as some of them can completely change the behaviour of CRM.

Back to our initial problem – if we would like to disable appending the GUID after the name of the record, we just have to run:

Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Update /u onedynamics  CreateSPFoldersUsingNameandGuid False

And now all the folders created by Dynamics 365 in SharePoint will not have this ugly GUID after the name of the record (of course you should remember not to have duplicated names for your entity records, otherwise you are asking for trouble).

Making use of transactions in Dynamics 365 Customer Engagement

I believe that if you have ever written a CRM plugin, you are aware of the event execution pipeline (https://msdn.microsoft.com/en-us/library/gg327941.aspx) and that the operation is run in transaction which means that if there will be any exception, the whole transaction will be rolled back. Pre-operation plugins and Post-Operation plugins are also run in transaction, so if there will be an exception raised by the plugin, changes will not be reflected in CRM. This includes not only chaning attributes for the entity that the plugin is running on – create/update/delete changes on any other entities are also rolled back. This is really convenient – we can perform a bunch of operations and we are sure that even if anything goes wrong during Post-Operation, everything will be changed back to the original state.

The usage of transactions can be embraced even more by using custom Actions and ExecuteTransactionRequest. Custom  Actions can also be run with a rollback option (which can be enabled or disabled on Action configuration page). ExecuteTransactionRequest allows to group different OrganizationRequests and send them in bulk to the server – they will be run in single transaction.

Ok, but how this transactional behaviour works in real world? To make it easier to understand for you I created a custom entity “new_lock” and prepared a very simple CRM plugin:

public void Execute(IServiceProvider serviceProvider)
{
    var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
    var service = factory.CreateOrganizationService(null);
    var @lock = new Entity("new_lock");
    @lock.Id = new Guid("590424F1-611F-E711-80D2-00155D010402");
    @lock["new_name"] = "lockme";
    service.Update(@lock);
    Thread.Sleep(30 * 1000);
}

I registered this plugin on Create message of the Contact entity. As you can see it simply retrieves the “new_lock” record and updates its name to some different value and then waits 30 seconds. Let’s open this record in a browser:

Now, let’s create a Contact (using a different browser window). After clicking “Save” you will notice that the loader starts but the data is not getting saved. That’s ok because our plugin is running in the background and it takes about 30 seconds to finish. If you try to save the opened “new_lock” record with some different name, you will notice that… you can’t do this:

This is the principal idea of transactions – by creating a Contact we opened a transaction and “locked” the “new_lock” record by updating it. Before the transaction is finished nothing can write to this record. After 30 seconds, our contact is created and the “new_lock” is updated with the new value. Is this a value from the plugin or from what we have entered on the form? Well it’s the second option, because we updated the value after the transaction has done it (it does not matter that it waited 30 seconds after that).

How can we make use of that transactional behaviour of CRM? I believe that a very cool feature that we can develop is proper auto-numbering. It’s pretty well known problem which is usually handled by some custom counter entity. The algorithm usually works like that:

  1. Run plugin on create of numbered entity
  2. Retrieve Counter
  3. Assign current value of counter to entity record
  4. Update counter with the next value
  5. Plugin ends

If you don’t have many users or some custom apps creating entities, you will probably never run into any concurrency problems. But imagine what will happen if you have two concurrent calls and both retrieved value of the counter before point 3 was fulfiled. This means that both records will have the same number and counter will be increased only by 1. Some may say – ok let’s use standard locking, we can have a static object to lock on and before plugin starts it’s core logic, the running thread must obtain the lock. That would work flawlessly on single-frontend-server environments. But what happens if there are more application servers for CRM? You cannot synchronize threads between different servers…

Knowing what we already know about transactions, we can easily modify this scenario to:

  1. Run plugin on create of numbered entity
  2. Retrieve Counter
  3. Update some dummy counter property to some dummy value (here we will lock the counter for usage only for this transaction)
  4. Retrieve Counter (now we are sure nobody will modify its value)
  5. Assign current value of counter to entity record
  6. Update counter with the next value
  7. Plugin ends (and any concurrent operations start from point 3)

This should work even on multi-server environments, because the transactions are locked on database level. Very simplified code (so pardon the style) can look like this:

public class TransactionPlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        var service = factory.CreateOrganizationService(null);

        var counter = GetCounter(service);
        counter["new_name"] = "lockme";
        service.Update(counter);

        //now counter is locked

        //we have to get it again to prevent race conditions
        counter = GetCounter(service);

        var target = (Entity)context.InputParameters["Target"];
        target["new_number"] = counter["new_nextnumber"];

        counter["new_nextnumber"] = (int)counter["new_nextnumber"] + 1;
        service.Update(counter);
        //after finishing the transaction, concurrent executes can go on from the lock
    }

    private Entity GetCounter(IOrganizationService service)
    {
        //return some counter
    }
}

 

UPDATE 21.07.2017

I prepared more detailed code for autonumbering plugin, which I have successfully used in my projects. The plugin works on Pre-Create of Account.

As you can see I’m retrieving my “new_lock” entity by its name using QueryExpression and after locking it with Update, I’m retrieving it again using Retrieve message. It is very important, because the following code will not work correctly:

If you try to run that, you will discover that you have a lot of duplicates. The reason is that the second RetrieveMultiple gets exactly the same value as the first one, so if we already obtained counter and some other thread will modify its value – this change will be not reflected. This is very important, so make sure you are not falling for this trap – for me this feature is quite surprising, QueryExpression results seem to be cached somehow in plugin context. What is even more interesting the following version will work flawlessly:

So simply replacing service.RetrieveMultiple with RetrieveMultipleRequest causes the results to be retrieved from the database, not from some kind of cache. That is something you should probably be aware of when implementing your own solution.

Disable columns in editable grid

Editable grids are a long awaited feature of Dynamics 365. Without any fancy coding, they allow to provide users a nice and easy to use interface, for updating multiple records in an Excel-like experience. We can easily create a subgrid on the form, configure it to use an Editable grid as control and we are good to go, we can edit all the grid columns.

Przechwytywanie

But what if we would like to edit only some of the columns of the grid, not all of them? This is not configurable, either we have an editable grid with all the columns editable, or we don’t have editable grid at all. The only way of handling this with configuration is enabling Field Security Profile – if user will not have privilege to update the field, it will appear as disabled for him. Fortunately there are quite a few client SDK features, that will allow us to achieve our goal with a little bit of JavaScript. First, we should register a function for OnRecordSelect event on our grid:

Przechwytywanie

And my gridRowSelected function looks like that:

This function basically gets all attributes for the selected row and for specified attribute (in my case it was “odx_monthid”) disables the grid cell. Effects are the following:

Przechwytywanie

Great, so only Month column is currently not editable, but we can still edit Amount column. The only drawback of this solution is that this “lock” on the field is shown only when you click on the row (because we registered the function to be fired on OnRowSelect event). Couldn’t it be fired for OnLoad of the form? Unfortunately, according to MSDN documentation:

we cannot run this, when form loads, because the internals of the grid are not yet loaded. Still it is quite an acceptable workaround. Maybe in future releases, editable grid will receive some more features like configuration of disabled columns.