I have a workflow with a number of compensatable activities. If one of these activities cancels I would like to restart/resume the workflow from the activity that failed.
I am thinking of bookmarking and persisting in the cancellation handlers
Is this even possible?
As a rule of thumb I always persist just before state changing activities so the option to redo is always available.
Related
Many examples of using event scheduling in Corda -- including it's own reference implementation of the Interest Rate Swap contract -- rely on SchedulableState mechanism. Unfortunately there is not much information available in the Corda documentation regarding the use of the scheduler in a real business context. Reliable execution of scheduled business events is important, and, as a party who depends on a CorDapp to automatically trigger scheduled events in order to fulfil my contractual obligations, I'd like to implement robust controls for whether things that had been scheduled have actually run. For example, it is possible to envisage a situation whereby a scheduled flow kicked off, but then ended prematurely due to a bug in the code or node misconfiguration without achieving its indented purpose. The question therefore is what CorDapp designer and/or node operator could do to ensure reliable execution of scheduled activities?
SchedulableState normally is used to represent recurring events.
Please check out this HeartBeat sample: https://github.com/corda/samples/tree/release-V4/heartbeat
You can think of monthly payment or a paycheck that is reoccured every month.
I have been trying out axon recently and read lots of stuff. From what I understand, the concept of event sourcing says that system state is rebuilt from the event store, while CQRS updates a view model that can be queried with the command side side is not queryable.
I will like to implement rebuilding of state myself each time the UI requests for some information. I've implemented the event processor and seen its replay capabilities. However I can't seem to find any evidence that axon allows for replays triggered on user demand. Therefore I'm asking here if its possible to personally trigger a replay to build a DAO required by the UI or axon only supports the CQRS way of doing it.
When axon does a replay (when token is deleted), does it read from the snapshot table (if implemented), then from the event table or does it always start from the beginning of time?
Dropping the token manually is currently the way to go if you want your query side to be rebuilt.
So, if you'd like to trigger a replay, you'd have to add a component which does that for you.
This might be a tricky process as well, since you'd probably not want any other parties trying to access your view(s) while they're rebuilding.
Take note that for this you do need to put your event handling components in a TrackingEventProcessor, otherwise it will have no recollection of how much of the events it has handled or not in the form of a TrackingToken.
The snapshot table is meant for your aggregates to ease the loading process. When you've set up axon to use the (Caching)EventSourcingRepository, it will first load an aggregate based on a snapshot and then source the remaining events.
So, to answer your second question: when you drop the token, it will read from the domain event entry table from the beginning of time.
Hope this helps!
Update
For those looking for replay support in Axon Framework, it is recommended to look at this page of the Reference Guide. It describes the replay support constructed for Streaming Event Processsors (like the TrackingEventProcessor).
I am using windows workflow service and have a need to know when a workflow instance is Idle. Using http://code.msdn.microsoft.com/Windows-Workflow-b9d5ccb7 as a resource, I have created a TrackingParticipant and am being "notified" when certain states occurs, e.g. Idle, Completed, Persisted, Resumed, Unloaded, Deleted, etc.
What I expected was that, only when the workflow instance is finished processing the current activities, that the state goes to Idle. However, it seems to go to Idle even if there is more processing for the workflow instance to perform. For example, I might see consecutive "Idle" states for the same workflow instance. As such, the "Idle" state is not very helpful for me in determining when the workflow instance is no longer processing any activities.
The "Unloaded" state, however, appears to give me what I want. The "Unloaed" state (as far as I can tell) only occurs when the workflow instance has no other activities to perform.
So my question is: Is it safe to rely on the "Unloaded" state to determine if the workflow instance is no longer processing any activities or is there some other technique I should use?
Thanks for your help,
Eric
I have created a simple workflow start-->createoredit-->automaticactivity-->End. automatic activity doesnt do anything, i have default code in the script area of automati activity FinishActivity "Automatic Activity Finished" alone in the script area.
When i trigger the workflow, automatic activity is not started and performed, it is assigned to "NTAUTHORITY SYSTEM" with the state "Assigned" (In the Global Work List)
Whenever i restart the "Tridion Workflow Agent" service or whenever some other automatic activity assigned via workflow, automatic activity start performed.
I dont see any error message also in the event log.
Could anyone help me on this? I am using SDL Tridion 2011 SP1.
The first activity must always be a manual activity. If you need to have the first activity automated then you need to rely on the event system for this.
EDIT: I see you wrote the question to add the first activity to be manual.
When an automatic activity gets stuck in Assigned state, it usually means there is a script error. There could also be something with the connectors between activities in your Visio design. Check that everything us properly connected. Try deleting the link between automaticactivity to End and recreating it again.
Check that the "Tridion Content Manager Workflow Agent" windows service is running. This fixed it for us.
I have a workflow service that links a Workflow Foundation 4 process with an application database which stores records that show what step our users must complete next. In the event of a non-resumable error in the workflow, it will make it so that the workflow is unable to be resumed, but the database entries that are in the application still exist, so there is a "disconnect" between workflow state and our application state.
What I would like to do is create another instance of the failed workflow, but get it into sync with the application database entries. That would entail going to an arbitrary entry point in the workflow based on the application database entries that exist.
Is it possible to do this? Are there any pitfalls to doing so? Is there a better way to manage the workflow to application dependency?
The workflow would look something like this:
Start the workflow. This creates an application db record that tracks the progress of the process and a db record that shows the user what needs to be done next.
The user "works" the step, which does a call into the workflow service (using receive/sendreply), updating the db record with the outcome of the work, and moving to the next step in the workflow.
Step 2 repeats with all the various steps creating db records to be worked, then updating those records with the results of being worked and creating new db records to be worked, until the process completes.
The question I'm trying to answer is if the user gets to a certain step in the process and the workflow engine fails so that the workflow instance is not resumable, how might I use the application db entries to "restart" the process to re-enter the process, skipping to the point of failure (assuming we had resolved the issue that caused the failure in the first place). This would eliminate the user having to "redo" work that had already been done, and stay in the process.
What I thought was that if there was a way of looking at the application database records that have been created to determine where the process had died, if I could "skip" previously finished steps and move to the point in the workflow that failed based on those db records, I could "resume" the process (from the user's point of view) without causing rework.
I'm just starting out with Workflow and I've been watching some videos on channel9 at MSDN and I came across one that may help you out.
It talks about using Bookmarks and some Task based-API by Ron Jacobs.
Check it out at: Workflow TV - WF4 Workflow Episodes - a Task Based API
It sounds like what you want to implement is Compensation- that is, custom rollback functionality built into a transaction. Here's the start of the Transaction and Compensation activity documentation:
http://msdn.microsoft.com/en-us/library/ee358756.aspx
You can use the Compensate activity to do database cleanup after a failed transaction.