Currently I see the parallel activity in WF 4.0 get completed either both the branches are completed or a certain condition is met but the activity I'm looking for should behave like this if any of the branch is completed the control has to transfer to the following activity without cancelling the other branch activity. Is there any activity in WF 4.0 should satisfy this need? or I have to create a custom activity for this purpose?
There is no activity that does this. The Parallel waits for all banches to complete or the CompletionCondition return true but then other branches a canceled as you describe.
What should happen to the other branches when the first is finished? They are scheduled so you have to do something with them or the scheduler will not see the "Parallel" activity as finished. That remains true even if you create your own activity.
Related
I have a scheduled state, which invokes scheduled activity. As per states generated and logs, we found scheduler activity stops because of breaking errors and now new state has been created after it. Is it possible to run the scheduler back from the day it stopped. Is it possible to run a flow on a backdate in Corda, given we have access to all the nodes and network.
It's not possible to run the scheduler in a backdated way, e.g. by changing the system clock.
To understand why we need to understand how the scheduler in Corda works.
The scheduling system doesn't loop over the system time to work out when it should run, but instead kicks off the activity once a particular time has elapsed, e.g. if you scheduled the task to run tomorrow at 13:00 at 12:00 today, a timer for 25 hours would be kicked off.
Once that scheduled activity has run, a new timer is calculated and kicked off.
If the node goes down, as soon as it comes back up, it'll work out if any scheduled tasks have been missed and if so, run them immediately. Any future dated scheduled tasks have their timers recalculated.
The best advice would be to run those errored tasks manually.
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
Basic details: Workflow version 4, IIS hosted, App Fabric installed with persistence and tracking set up.
lets take this example. I have a list of X machines to do work against. in the initial workflow i do some validation on the list it self, then, in a foreach activity against the list, fire up a different workflow to do some actual work in the machines. This new workflow can take anywhere from 10 minutes to 2 weeks to complete depending on many factors.
My question is, what happens when the initial list is 200 or 2000 machines and i am spinning up that many instances of workflows on a server? Is there a maximum that will be allowed to run? If so, what happens in the original workflow that is looping through the list when it hits this maximum? Is this the way i should be handling a situation like this?
Workflow services are throttled by the same settings as WCF. That means that additional workflows exceeding the limits will be scheduled but will remain in the queue until they can be started.
See the links below for more info:
Throttling workflow services in WF4
Question: Workflow Service
stops responding after 464 messages
I have a scenario and want to use multiple ReceiveAndSendReply activities running in parallel situation, each of them will be put in an infinite while loop to make sure all activities are always running and listening. So I used a parallel activity to pack all those ReceiveAndSendReply, and each ReceiveAndSendReply was put in a While activity with condition set to true. And of cause, I put some activities with business logic between Receive activity and SendReplyToRecieve activity.
Now I have a problem if it takes a long time to process a request in one branch, then during that time all other branches will be blocked. Any request for other Receive activities will not be processed, and both client, which include the one called long time run service and the other one who called other service during server process long time run service process, will also get exceptions.
Did anybody have an idea to fix it? Sorry since I am new user, can put post image of my workflow.
The workflow runtime is single treaded in that a given workflow instance only executes on a single thread at any given moment. So while your workflow is busy doing work it can't react to other incoming messages. Normally this isn't a problem as workflow's normally aren't compute intensive and doing async IO is real easy. One thing that might help is adding Delay activities with a real short timeout. They cause the workflow to pause letting it start processing the next request. Also make sure you put as few activities as you can between the Receive and the SendReply and add a short delay right after the SendReply.
I am trying to model a notification system where an event occurs during a time period (start date and end date). If the time period has been exceeded, the user is required to either update the time period or set a flag that the event has been i) cancelled, ii) completed, or iii) closed. If today is one day past the event's scheduled completion date, the manager is emailed. If two days, the manager and their supervisor is emailed. If > two days, the manager, their supervisor, and the company owner is emailed. Every day after that it emails the three of them that the event is delinquent. Events can be scheduled any time in the future so the process needs to simply track when the event is Pending, Active, Delinquent (past the end date), Cancelled, Closed, or Complete.
I have started building workflow as a WorkFlow Service application hosted in Windows Server AppFabric because it appears that that is the best way to persist this long-running workflow. I have also started using the WF State Machine Activity Pack CTP 1 as it seemed the best way to model these different event states.
I am uncertain how to model this process as well as get the process to persist and continue running in the background to monitor the event's state and behave as outlined above. I think I have all the states modeled correctly in the state machine. I am still trying to figure out the transitions from one state to another Any guidance is appreciated.
State Machines run in a burst of execution. There is really nothing to "run" while the workflow is persisted. I suspect what you mean is how will the workflow "wake up" when the timeout is exceeded.
The answer is that the Delay activity will create a durable timer. The AppFabric Workflow Management service periodically asks the persistence layer if there are runnable workflow instances - that is instances which have crashed or where a durable timer has expired.
Eventually the timer will be expired and the Workflow will be loaded and the Delay activity bookmark will be resumed.