In my ServiceNow workflow for a catalog item, I have a stage for customer acceptance. When the customer rejects the item, it triggers a workflow event and rolls back the workflow to the point where it's waiting for a state again. Or at least, that's the idea. But no matter what I'm doing, the rolled back workflow skips the "Wait for condition" activity immediately.
This is a screenshot of the workflow section in question.
What am I doing wrong?
I know this is an old post but perhaps the below suggestion can help in similar cases:
The thing wit 'Wait for Condition' is that once it has been evaluated, it will not be checked again until there has been a new update to the record on which the workflow runs.
I assume this could be the cause here, one you roll back, if the record itself does not get updated, it skips that activity. You can easily check if that was the case by adding some activity after the roll back to e.g. set a worknote on the record or just 'run script' with the setForceUpdate() function (this updates the record without changing any fields values).
I'm not 100% sure it is the fix to the above problem as there could be many other factors involved and only small part of WF was posted, but definitely something worth checking.
I hope you found the solution by now!
Related
I have a question regarding workflow in Kanban. Can I have two activities in my name in the "in progress" column? For example, I started the activity 'A' but not concluded and will continue at another time, then I get the activity 'B.' Makes sense to have activities A and B in the "in progress," but I'm doing only one.
I am a certified Kanban Coaching Professional, and this would be my advice:
Sure you can. Kanban itself won't say whether you can or not, it depends on how you use Kanban. The WIP limits might prevent you from starting another task, in which case you should do some or any of the following:
Discuss the issue with the team, perhaps it is ok to raise the WIP limit (or even temporarily breach it)? Perhaps you can solve the impediments together and continue working on the original task.
Perhaps you can "swarm" or help someone else with something else on the board. I usually like to start from the right-hand-side of the board and see if I can help some other item move closer to done.
You can also treat this as "slack" time, and work on improving the process, learning a new skill, or checking emails, or some of the other tasks that everyone has to do that are not directly related to the value stream. "Preparing for working on the item" is what a lot of people consider doing, but is usually just cheating against the WIP limits.
I'm wondering exactly what logic should be contained when applying an event to a state while replaying events using some event sourcing solution.
Specifically, I'm wondering about validation, say I've got entity which can be in one of the following status:
Logged
Active
Close
Cancelled
and the progress needs to be Logged->Active->Close or Logged->Active->Cancelled, we cannot jump from Logged to Close directly for example.
Now, I understand, the validation should be contained in commands: UpdateState would check if the entity current state allows transition to desired one, and would produce appropriate event StatusUpdated which would be persisted into the event store.
Question is, what should I do when replaying it back? Should I just update the status, or should I perform same validation (so that if status transition requirements change it won't be possible to load some previously updated entities unless we add some additional logic), to ensure we won't end up with entities that do not satisfy our current logic?
PS. I think I've got problems grasping it because in my understanding events are essentialy just about 'announcing' something that happened already (and the sender state is already modified) so that interesting parties can react accordingly. And in case of events loading/replaying, you need to alter said state instead of actually 'announce' anything...
You do not need to perform any validation when replaying the event stream.
Commands model things that will be done in the future: You ask the system do to something for you. It's up to the system to decide whether to do it or not, e.g. based on business rules and validation.
Events in contrast model things that have already happened. As in the reality, you can not change the past.
So, this means, when an event gets persisted, it was in consequence of a command which was taken as valid at the point in time when it was processed. Replaying an event stream simply means to have a look at what happened in the past, and you can not change this.
Hence, you do not need to run any validation again.
Moreover, this means that if one day your business logic changes, all the things (business accidents!) that happened in the past still have happened, so they must not change. Hence you are not allowed to use any validation logic, as it may be another one today than when it was when you stored the events.
And again: You can not (and should not) change the past :-)
Example
Supposed you have a way of validating credit card numbers. A customer comes to your shop, pays, you consider his / her card as valid given your current set of rules, and everything is fine.
Then, one day the credit card institute changes the way credit card numbers are calculated, and hence you have another validation algorithm.
When you now play back your past events, the payment had happened, with or without the new validation rules - and you can not change the fact that it had happened! If you wanted to you had to create a new transaction to send money back to the customer. Again, this would result in a new event, not in a changed one from the past.
So, to cut a long story short: Don't validate events against anything. They are valid by definition, as they had happened before.
Any event stream that's been written to the event store should be valid to be played back without introducing any logic in the event handlers. If you needed to change your transitioning process, you'd need to look at doing some sort of conversion, along the lines of this example.
Regarding your last point. Event sourcing is a technique for persisting and restoring the state of an entity using a historical record of ordered events. It just so happens that when you're saving the entity, you can also publish these events for any interested parties to consume.
I want to schedule a recurring action in my Activity (I am using Activities and Places design pattern). When my user leaves a place associated with this activity, how quickly can I expect this action to stop? Will the inclusion of the recurring action somehow affect the way an Activity is disposed of?
I don't need an immediate guarantee. If an activity is disposed of normally, it's acceptable in my use case.
It is your responsibility to cancel anything that you started in your activity, if you need/want so.
With a Scheduler.RepeatingCommand, you'd have to keep the command around and, in the activity's onStop, set a flag on it so that the next time it's run it exits early and returns false.
Firstly I am new WF (v4), but I can see the benefits, it's just the learning curve that is holding me back at the moment so I need your help.
Take my scenario, I have a business requirement to send a series of emails at various intervals. So I have created a sequential workflow in a workflow service with the appropriate delays between each mail send. The workflow is started by a Recieve call. This part seems to work fine.
However I want a have a second Receive call that effectively stops workflow so no more emails sent.
To try and achieve this I configured a Pick control with 2 branches. Branch 1 has a Receive with StartEmails which starts my delayed sequence of emails as describe before. Branch 2 contains a second Receive 'StopEmails, however my breakpoint never gets hit on the StopEmails Receive. I beleieve I have setup the correct correlation and CanCreatedInstance is set to false.
Is it that I can't make a second call while the first branch is in a delay (waiting) state?
Any pointers would be appreciated.
After a little more digging on SO, I believe I found my answer. see this post Workflow foundation 4.0 message correlation and error reporting
I was correct in my thinking that it was the delay in my first branch was what was blocking my second Receive request from being executed. Replacing my Pick with a Parallel container solved the problem. Makes sense when you think about it!
Parallel container to the rescue!
Is it possible to cancel a long running activity while still keep the whole workflow alive. The workflow itself is hosted in WorkflowApplication.
The real user case is we've got a long running activity which polls the price from an external web service, and once it gets the price the activity should complete and the workflow will move to its next step. However, the price is something nice to have but not mandatory, so in some cases we want to cancel the polling activity and let the WF carry on its execution.
So the question is how can I notify a running workflow to cancel (actually skip) its current activity.. if this is not possible at all, can someone please share your thoughts and point me the right direction to achieve this goal.
Thanks a lot.
Dan
You can do this using a Pick activity. Use one PickBranch trigger to poll for the price and add a skip polling bookmarked activity to the other branch. Whatever branch completes first continue and the other will be canceled.