/TECH
When I started working in SharePoint nearly 3 years ago, I noticed a severe lack of looping functionality built-in to InfoPath or SharePoint itself. This was irritating because when I started work, I was still a student learning C++ and there loops are life-blood. So, what was a programmer to do in a designer's system?
The place I noticed the greatest need for looping was actually in the workflows that our custom forms used to notify approvers. And when I arrived to the SharePoint team, workflows were done in such a way that it would start when the form was created and keep running, waiting for changes before proceeding, and finishing when the form reached its completed state. The real problem occurred when there was a issue with a form and the process had to be reset. This meant terminating the workflow, making the changes, and then restarting the workflow. Even then, the workflow had to go through each of the steps again, even if the change affected only the last step. Wouldn't it be nice if it could keep checking everything until it was actually complete? Yeah, like you can with a loop.
This is when I noticed that the SharePoint team didn't utilize the option that a workflow would run when an item was changed. There were reasons, good reasons for this, but if it's there we should at least understand why we weren't using it for that workflow. The first form I worked on I discovered a really good reason not to use the on change option: if your workflow changes a field/column for the item it is running on and then completes, it detects there was a change to the item and the workflow is triggered again. Welcome to the infinite loop of SharePoint. The workflow in question had to first set the form's Status and then emailed the next person in the process (me). Because it finished so quickly, the Status change was detected as a change and the workflow triggered again. And again. And again. And again. And it proceeded to send me a constant stream of emails while I frantically tried to stop the loop. 15 seconds later I was deleting the 60+ emails I had received.
But this only occurred because something was being modified in the current item by the workflow. I quickly learned that it is better to handle changes in the form template as much as possible. To solve the problem however, I employed another workflow feature: Wait for Duration. This enabled me to change the field, wait, and then send the email a couple minutes later. By having it wait the event handler no longer saw the change as recent enough to start the workflow again. The problem with this solution was that it slowed down the process. And I still had to worry about workflows spamming because several processes I work with use more than one workflow and often one of those has to make changes to the item. In these cases I employ a flag for each email to mark which ones have been sent already. The flag can be added to the library or content type directly, but I prefer to add it to the template. This is because InfoPath forms have a much more powerful rule system built in than the ones that libraries and workflows can do. An excellent example of using these flags is actually in a process I'm currently working on.
Workflows that trigger on-change were essentially the "loop" I was looking for. We also discovered that this method reduced the server load significantly, an unintended benefit. Ever since then my boss has asked me that when I'm rebuilding a workflow that if I can change a workflow to triggering on change that I should.
The best practice in my opinion is to assess what needs to be accomplished to see if the on-change workflow fits your process. In my case, most situations benefit from the on-change style workflow.
Oh, and always test the workflow by having it send to yourself first. You really don't want to have to explain yourself to your boss's boss as to why you flooded his inbox with God knows how many emails.
Until next time:
Work hard. Play harder.
When I started working in SharePoint nearly 3 years ago, I noticed a severe lack of looping functionality built-in to InfoPath or SharePoint itself. This was irritating because when I started work, I was still a student learning C++ and there loops are life-blood. So, what was a programmer to do in a designer's system?
The place I noticed the greatest need for looping was actually in the workflows that our custom forms used to notify approvers. And when I arrived to the SharePoint team, workflows were done in such a way that it would start when the form was created and keep running, waiting for changes before proceeding, and finishing when the form reached its completed state. The real problem occurred when there was a issue with a form and the process had to be reset. This meant terminating the workflow, making the changes, and then restarting the workflow. Even then, the workflow had to go through each of the steps again, even if the change affected only the last step. Wouldn't it be nice if it could keep checking everything until it was actually complete? Yeah, like you can with a loop.
This is when I noticed that the SharePoint team didn't utilize the option that a workflow would run when an item was changed. There were reasons, good reasons for this, but if it's there we should at least understand why we weren't using it for that workflow. The first form I worked on I discovered a really good reason not to use the on change option: if your workflow changes a field/column for the item it is running on and then completes, it detects there was a change to the item and the workflow is triggered again. Welcome to the infinite loop of SharePoint. The workflow in question had to first set the form's Status and then emailed the next person in the process (me). Because it finished so quickly, the Status change was detected as a change and the workflow triggered again. And again. And again. And again. And it proceeded to send me a constant stream of emails while I frantically tried to stop the loop. 15 seconds later I was deleting the 60+ emails I had received.
But this only occurred because something was being modified in the current item by the workflow. I quickly learned that it is better to handle changes in the form template as much as possible. To solve the problem however, I employed another workflow feature: Wait for Duration. This enabled me to change the field, wait, and then send the email a couple minutes later. By having it wait the event handler no longer saw the change as recent enough to start the workflow again. The problem with this solution was that it slowed down the process. And I still had to worry about workflows spamming because several processes I work with use more than one workflow and often one of those has to make changes to the item. In these cases I employ a flag for each email to mark which ones have been sent already. The flag can be added to the library or content type directly, but I prefer to add it to the template. This is because InfoPath forms have a much more powerful rule system built in than the ones that libraries and workflows can do. An excellent example of using these flags is actually in a process I'm currently working on.
Workflows that trigger on-change were essentially the "loop" I was looking for. We also discovered that this method reduced the server load significantly, an unintended benefit. Ever since then my boss has asked me that when I'm rebuilding a workflow that if I can change a workflow to triggering on change that I should.
The best practice in my opinion is to assess what needs to be accomplished to see if the on-change workflow fits your process. In my case, most situations benefit from the on-change style workflow.
Oh, and always test the workflow by having it send to yourself first. You really don't want to have to explain yourself to your boss's boss as to why you flooded his inbox with God knows how many emails.
Until next time:
Work hard. Play harder.
No comments:
Post a Comment