My gut feeling pointed to something but I wasn’t sure if you were using the ReFramework. Seeing your execution log now it seems to back that theory up as I am pretty sure you are using the ReFramework. See the following example workflow:
In the example above if an exception occurs in the Get Asset activity, the exception is caught by the Try/Catch block. The execution continues by outputting using the Dictionary’s
Dispatcher.LoginURL key yet it does not exist in the Dictionary because the asset could not be retrieved from Orchestrator and therefore could not be set. This will throw an exception as the key is not defined in the dictionary.
You seem to have a similar problem in your execution.
“Loading asset CWT_EmailSubjPrefix failed: A task was canceled.”
You’re using the
CWT_EmailSubjPrefix asset further down the line. They’re causing these errors:
“Add Email Subject Prefix: The given key was not present in the dictionary.”
“Invoke CWT_SendSummaryEmail workflow: The given key was not present in the dictionary.”
Reaching Orchestrator is not 100%. Your internet might be down, orchestrator might be down, DNS issues might occur, packets might get lost somewhere along the way. There are so many things that could cause problems in retrieving the asset from Orchestrator. This can happen every now and then. Depending on the process you’re automating, its frequency and how you’ve set up the automation this might be neglectable, or not. It’s up to you (and your team) to decide what the best thing is to do in cases when this happens.
My post was written for a broader audience as people might run into the same issue someday. In your case I would like to ask you if the email’s prefix has to be stored in Orchestrator. If not then simply store it in the configuration file. If so, keep things as it is and discuss internally as to if and what retry mechanism you’ll put in place.