Recently we were bulk updating our records, which would trigger an asynchronous plugin registered on its update. We were using the wonderful Bulk Data Updater (XrmToolBox) plugin for it. We realized if we are updating too many records at once say e.g. 100 Batch Size (total 5K records to be processed), we are getting below exception.
The plug-in execution failed because no Sandbox Hosts are currently available. Please check that you have a Sandbox server configured and that it is running.System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: The plug-in execution failed because no Sandbox Hosts are currently available. Please check that you have a Sandbox server configured and that it is running. Microsoft.Xrm.RemotePlugin.Grpc.ExceptionHandlers.SandboxFabricHostCommunicationException: Error communicating with Sandbox Host
We than updated the Execution settings to process with a Batch Size of 5 with an interval of 60 seconds. This fixed the issue for us.
Recently we started getting the below error on the form load of the Work Order Service Task record, that also only in specific environments, and there was no changes made there.
Error Details:
Event Name: onload
Function Name: OnLoad
Web Resource Name: msdyn_/WorkOrderServiceTask/WorkOrderServiceTask.js
Solution Name: msdyn_FieldService_patch_update
Publisher Name: microsoftdynamics
From the error message also it was clear it was the error in the out-of-the-box javascript.
On raising the Microsoft Support Ticket, we were immediately informed that it was because of a change in the function definitions in the .js files along with its associated handlers which was done to prevent object definition collisions in the web resources.
This applied to forms of the below tables
Work Order (msdyn_workorder)
Work Order Service Task (msdyn_workorderservicetask)
We recently got the below error in one of our cloud flows, the requirement was to fetch the distinct work orders that have notes with attachments associated with them.
A resource of type ‘Microsoft.Dynamics.CRM.annotation’ was found in a resource set that otherwise has entries of type Microsoft.Dynamics.CRM.msdyn_workorder’. In OData, all entries in a resource set must have a common base type.
This occurs if we try using the aggeration in the Fetch XML queries in the List rows action.
The solution was to rewrite the fetch xml query without using aggregation.
And then next if we want to get the distinct values, we can use the Union function for that.
Here,
we are first adding the GUIDs to the varLstWorkOrderGUID array variable using Append to array variable action
And then applying the Union function – to remove the duplicate from the array.
Recently for one of our plugins, that moves attachments to the Azure Blob Storage, we got the below exception.
BlobFileName: WFU000069107_Inside Install – CFC__2024_03_03_12_24_05_179_temp.jpg Caught Exception: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. System.FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. at System.Convert.FromBase64_Decode(Char* startInputPtr, Int32 inputLength, Byte* startDestPtr, Int32 destLength) at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
We were getting errors while trying to use the FromBase64ToString method to decode the Base64 encoded string into its original byte array.
Seemed there were some issues with the image uploaded, even from the browser when trying to download we were getting the below exception.
The solution was to check if it is a valid Base64 encoded string before converting it to a byte array and if not skip it and process other attachments in the plugin.
Recently in one of our Plugins, which was using Azure.Storage.Blobs and Azure.Storage.Common libraries to move attachments from notes to Azure Blob Storage suddenly started throwing the below exception. The Plugin had been working fine and had been deployed long back to the production environment.
System.TypeInitializationException: The type initializer for ‘Azure.Response’ threw an exception. —> System.IO.FileNotFoundException: Could not load file or assembly ‘System.Memory.Data, Version=1.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ or one of its dependencies. The system cannot find the file specified.
We raised the Microsoft Support for it and were informed that the reason for this was there was a platform update over that particular weekend to stop loading the “System.Memory.Data” assembly on the plugin server. And as we hadn’t included that assembly in our package (ILMerge), we started getting the exception.
Nishant Rana's Weblog 