Monday, November 9, 2015

Abstract Away SharePoint 2013 Workflows

 

I guess you could say I am a workflow guy.  I have always been drawn to the idea of automation and the ultimate drive for efficiency.  When I get home, the lights turn on, my thermostat sets itself, and my home entertainment system turns on and tunes to Fox News so I can get in a good laugh for the day.  All of this happens without me lifting a finger. If I do need something done, I just yell at Alexa to do it for me.  Who doesn’t like things being done for them anyway?? But we aren’t here to talk about my sweet home automation setup (maybe we should be?), we are here to talk about applying the abstraction principle to your workflows to gain the ultimate efficiency.

Abstraction?

What is abstraction anyway?  There is a good chance that if you build workflows on a regular basis in SharePoint, you don’t write much compiled code so this word means nothing.  Abstraction is easy to understand, however. By definition, abstraction is a technique for managing complexity of computer systems.  You use abstraction to make something very complex, easier to digest.  You also use abstraction to ensure that you don’t have to write duplicate code (or create additional workflow actions).  How exactly can we apply this “idea” to a workflow anyway and is it necessary?

When we think about SharePoint workflows to begin with, the workflow actions are already being abstracted.  If you consider the wait for field change in current item event in a Nintex workflow, you are seeing the very top layer that is easy to understandimageSo what we are really looking at when we look at this action is similar to the view layer of this picture below.  This view layer represents the user interface for the workflow action.  Right below that view layer, there is real stuff happening that you aren’t seeing.  For the purpose of building the workflow, you don’t NEED to see what's happening.  To be accurate too, we are really seeing control abstraction with a series of sub-routines that are parameterized.  I won’t get too geeky on you though…

imageLets see an example already!

If we look at the Nintex workflow below, there is 4 simple steps.  In steps 1 and 3, however, there is some serious stuff occurring.     

image

The 1st step of that workflow initiates a secondary workflow to build some dictionaries, crunch some numbers, and assign a couple tasks to people all the same time.  I have abstracted this information away from the primary workflow to make the overall process easier to digest and understand.  This example, however is only on a small scale. One workflow I am working on now, for instance, looks like a spider web going down the screen for 5 scrolls.  If I built that entire sub-workflow into the primary workflow along with the rest of the actions I abstracted, not only would debugging suck, it looks bad.

image

Why do this?

There is two primary benefits in abstracting bigger workflows like this.

First is testing.  When you have a really massive workflow.  Its insane to think you would have to run the entire workflow to check to see if a piece at the end needs fixed.  You will waste so much time you might as well get a dose of Fox News humor while you wait an hour for the workflow to finish itself (for the record, I hate all news stations but Fox at least makes me laugh).

Second is reusability.  By abstracting my calculations in the above manner, I can reuse this as many times as I need to in the primary workflow (or really any other workflow).  If you have ever built a large workflow, you can’t tell me you haven't had to reuse the same actions you used earlier in the workflow.  By having the mindset you will be abstracting away the bigger stuff in the workflow, it makes you rethink the entire structure of things you will need to reuse.

That’s all folks

So in conclusion, abstracting large workflows into small, manageable pieces, you can help you build something that not only is really easy to test, but will change your entire mindset of structuring your next workflow.  There is a caveat to all of this, however.  You have to know when to abstract and when to build just one workflow.  It really doesn’t make much sense to create 50 secondary workflows in a primary workflow.  Remember, we are trying to break up something really massive into smaller, easier to manage pieces.  Not create the need for another server in your farm.  On your next big workflow, take abstraction for a spin and let me know how it ends up.