While reviewing existing Microsoft Dynamics 365 Online implementations, I have noticed a repeating assumption by which Custom Workflow Activity, executing within an a-synchronous process, is not subjected to the sandbox 2 minutes execution timeout limitation.
This false assumption led to wrong architectural designs in which long running processes are assigned to be handled by CWA components.
As this article states, Custom Workflow Activity code registered to work in sandbox mode is subjected to the 2 min. execution timeout limit, just like Plug-in code. If you want to test this declaration yourself, just put a Sleep statement in your CWA code and get the following exception for both sync. and a-sync. processes:
The plug-in execution failed because the operation has timed-out at the Sandbox Host
So here are my tips regarding the Sandbox timeout limitation:
In general, If you don’t handle exceptions, your business logic may disgracefully break and your users/clients might experience some ugly ass raw exceptions.
While handling exceptions, you can single out timeout exception by testing the exception status:
catch (WebException exception)
{
string str = string.Empty;
if (exception.Response != null)
{
using (StreamReader reader = new StreamReader(exception.Response.GetResponseStream()))
{
str = reader.ReadToEnd();
}
exception.Response.Close();
}
if (exception.Status == WebExceptionStatus.Timeout)
{
throw new InvalidPluginExecutionException(
“The timeout elapsed while attempting to process the request.”, exception);
}
throw new InvalidPluginExecutionException(String.Format(CultureInfo.InvariantCulture,
“A Web exception occurred while attempting to process the request. {0}: {1}”, exception.Message, str), exception);
}
Tracing all incoming parameters values (as this article suggests) can help you better diagnose your CWA operations.
Run the following FetchXML query to get statistics about your component. Replace the name attribute value with your component name.
Note the averageexecutetimeinmilliseconds and failurecount results – it might indicate that your business logic is failing or close to failure.
<fetch>
<entity name=”plugintypestatistic”>
<attribute name=”averageexecutetimeinmilliseconds” />
<attribute name=”failurecount” />
<attribute name=”failurepercent” />
<attribute name=”crashpercent” />
<attribute name=”crashcount” />
<link-entity name=”plugintype” from=”plugintypeid” alias=”PluginType” to=”plugintypeid”>
<attribute name=”isworkflowactivity”></attribute>
<attribute name=”typename”></attribute>
<filter>
<condition attribute=”name” operator=”eq” value=”MyProject.Workflows.ProcessSomething“></condition>
</filter>
</link-entity>
</entity>
</fetch>
