Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There's a couple of issues going on here. First, when you are using SQL persistence, notifying the workflow of events and having the workflow publish events is persistent and asynchronous and the underlying plumbing of the workflow is transactional...but not in the way you might think.</p> <p>If something horrible happens somewhere in the sequence of events that will eventually cause your workflow to transition to a new state, then the workflow will revert to the state it was in before attempting the activity - this keeps the workflow in a consistent state since being "between states" is a bad idea.</p> <p>Using a transaction scope as you've done above is fine, but you have to remember that the only time transaction scopes actually work is when the classes within the using block are aware of the the transaction scope.</p> <p>What you can do is have your call to "MyMethod" wrap things in a try/catch block. When something goes wrong, you can vote for a rollback... but this still doesn't "un-invoke" the method on your EDES.</p> <p>If you can give some specifics about what you're trying to accomplish at a higher level, there may be some things intrinsic to the WF that might better suit you than trying to shoehorn a transaction scope into the mix.</p> <h2>Edit</h2> <p>I did some digging and found a couple of different places where we are told that <em>there is no API to manipulate the scheduler work queue</em>. Unfortunately for us what this means is that any sort of rollback behavior that we want we're going to have to implement by hand on our own.</p> <p>If I knew more about why you were trying to rollback work queued through an EDES I might be able to suggest some potential architectures for accomplishing your task without re-inventing the wheel (transactions).</p> <p>9 times out of 10 when I run into problems like this where it looks like WF just doesn't support what I'm trying to do, the problem is because I've either kept too much code <em>outside</em> the workflow or tried to put too much code <em>into</em> it and refactoring where my work is done often fixes my problem without requiring me to write new stuff.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload