5

I've written a custom workflow activity against CRM 2013. You don't need to understand what it does. The problem I have is that despite instantiating the ITracingService, any tracing content that I generate using the Trace(...) method is obfuscated at runtime for real-time workflows only. In other words, if I run my workflow asynchronously and (deliberately) throw an Exception, I get to see the trace log in the corresponding system job record. If I simply switch the workflow to be "real-time" (synchronous) then I still get an exception and I still get any custom exception text, but of course there is no corresponding systemjob generated for realtime workflows so, like a plug-in, I am seeking my Trace output in the downloadable log file that is presented when an exception occurs. In this case, my Traces are not visible but I get what appears to be Microsoft's trace log from (perhaps) the parent context that hosts the workflow - you can see that it is referencing the steps in my workflow process definition:

[Microsoft.Crm.ObjectModel: Microsoft.Crm.Extensibility.InternalOperationPlugin]
[46f6cf4c-14ae-4f1e-98a1-eae99a37e95c: ExecuteWorkflow]
Starting sync workflow 'MyTestWorkflow', Id: ca8782b1-7ca4-e311-a055-6c3be5be5f78
Entering CreateStep1_step: 
Entering CustomActivityStep2_step: 
Sync workflow '__Test' terminated with error 'Unexpected exception from plug-in (Execute): My.Test.WF.DoSomething: System.NullReferenceException: Object reference not set to an instance of an object.'

In my assembly My.Test.WF.DoSomething I access the Tracing Service at invocation and immediately start writing via the Trace() method, e.g. 

_trace.Trace("Starting Greg's custom code...");

This is only an example, but the point is, my tracing works when asynchronous but is "lost" when synchronous.

Any ideas?

Greg Owens
  • 3,878
  • 1
  • 18
  • 42
  • 1
    Have you looked at the process sessions on the workflow form? Is that where you are finding the trace log or is from the real-time error dialogue box? – Bvrce Mar 06 '14 at 13:19
  • Well who knew...! Yes, for a synchronous (realtime) workflow my trace does get surfaced there too. Not what I expected even after all this time of working with CRM! I'd still rather it were in the downloadable log file, but this at least confirms that the traces aren't just going into a black hole. I was finding the traces from the dialog that pops up when an exception occurs ("Download Log File" button). Any ideas why the behaviour differs from a plug-in? – Greg Owens Mar 06 '14 at 15:07
  • My best guess is that maybe synchronous custom workflow activities exception messages are obfuscated as they are likely to be seen by the user. – Bvrce Mar 06 '14 at 15:34
  • No more so than a plug-in though, right? – Greg Owens Mar 06 '14 at 16:00
  • Certainly a synchronous plug-in. Is a synchronous plug-in exception message available anywhere else? If it is only available from the error message box it makes sense that Microsoft decided to include the full exception message. – Bvrce Mar 06 '14 at 16:10
  • The anser below is not true for synchronous workflows did you find the real answer for this? I have the same issue. – Goca Jun 11 '15 at 18:09
  • It certainly was true at the time as I checked - maybe behaviour has changed with the upgrade to CRM Online 2015? Not in a position to check this right now unfortunately. – Greg Owens Jun 11 '15 at 21:19

2 Answers2

2

The process sessions section on the corresponding workflow designer form contains the full exception message.

Bvrce
  • 2,170
  • 2
  • 27
  • 45
  • 1
    This is not true, it only contains the exception and the trace if is a asynchronous workflow but if is synchronous it only contains the exception not the trace. – Goca Jun 11 '15 at 18:03
0

The problem is that the full exception message does not contains the trace created through the ITracingService Trace method, just contains the exception that's been thrown by the platform, no user traces are included in the comments tab of the process section.

I think the best approach for development purpose is to use a StringBuilder instead of ITracingService and throw the exception using StringBuider.toString() as the message. As for production release, perhaps the best approach is to use a custom entity to trace the errors in runtime, or not use custom workflows activities on synchronous workflows at all.

Cheers.

Nicolás Brandl
  • 151
  • 4