Recently we got the below error “Forbidden” for one of our flows that was using the Dataverse connection.
After some analysis, we found the root cause of the error.
The Dataverse connection reference was created using the Service Principal but it was not added as an Application User (with appropriate security role) in that environment.
Adding the corresponding Application User used for the Dataverse connection fixed the issue for us.
The content describes invoking a Webhook from a custom Azure-Aware Plugin, registered through a plugin registration tool. It includes code to invoke the Webhook using the IServiceEndPointNotificationService interface and a sample code snippet. The process involves updating a case record and provides guidance on the execution context and handling exceptions.
Below is our cloud flow that we have registered as a webhook through the plugin registration tool.
Below is our Webhook registered, note down the ServiceEndpointId.
Below is our code to invoke the Webhook, it uses the same interface, and we IServiceEndPointNotificationService need to provide ServiceEndpointId to it.
We have this registered in the Update message of the Incident.
Let us update a case record and see it in action.
Sample Code –
public class CallWebhookPlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
IPluginExecutionContext context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
IServiceEndpointNotificationService webHookService =
(IServiceEndpointNotificationService)serviceProvider.GetService(typeof(IServiceEndpointNotificationService));
try
{
tracingService.Trace("Posting the execution context to the Webhook.");
// pass the GUID (ServiceEndpointId) of the Webhook
webHookService.Execute(new EntityReference("serviceendpoint",
new Guid("7b88a3c7-d2b5-ee11-a569-0022481c0ba7"))
, context);
tracingService.Trace("Passed Successfully.");
}
catch (Exception e)
{
tracingService.Trace("Exception: {0}", e.ToString());
throw;
}
}
Let us fetch 5000 contact records using List Rows, and then update it using Apply To Each.
It took around – 37 minutes
Now let us enable concurrencycontrol for Apply To Each action, and let it run under 20 (default) degree of parallelism.
This time it took around 4 minutes.
Let us increase it to the maximum this time, i.e. 50.
This time it took around 2:45 minutes.
Thus Concurrency Control option can help in processing records faster by processing records in parallel instead of one by one by using parallel threads. However, if the ordering of the way records need to be processed is critical, then we need to be careful before using it and also at times it can cause the API’s request limit to be hit.
We might below error in our flow – BadRequest. Http request failed as there is an error: ‘Cannot write more bytes to the buffer than the configured maximum buffer size: 104857600.’.
We might see some of the custom actions not appearing in the Actions list inside the Perform Action step of the workflow.
This is because the Custom Action would be using one of the following parameter types, which is not supported for Perform Action like
Picklist (Optionset)
Entity
Entity Collection
E.g. we have the following actions defined few are bound to the Contact table, some are Global, and have different types specified as either Input or output parameter.
Out of the above actions defined, we can see only the following actions listed inside the perform actions step of the workflow.
The action which has input as Entity Reference are the ones listed, as it is one of the supported types. For the unsupported types, if used as an output parameter, the actions are listed.