Big enterprises usually have multiple SharePoint OnPrem farms spread across the globe and not to mention the fact that these multiple farms have a lot of site collections, sites and lists/libraries. At AgilePoint, we do work with a lot of big enterprises and often times one of the topic of discussions is how can I maximize the reuse and minimize the maintenance of these workflows. It is not uncommon for clients to have more than 10K site collections and numerous list and libraries across those site collections all of which might need to use same or similar workflows
There are multiple aspects to this discussion which I have listed down my take on how AgilePoint NX shines compared to a lot of competitors out there
Deployment Architecture: For such huge scale implementations, it is next to impossible for clients to imagine deploying the same workflow to more than 10K site collections on each of the farms. This is where AgilePoint’s distributed deployment architecture excels. AgilePoint NX server can be installed outside of SharePoint farms and the single AgilePoint NX farm can serve workflow request from multiple SharePoint farms which are geographically distributed. The actual workflow resides on AgilePoint side so there is no need to do deployment of these workflows in individual site collection. All that goes on the SharePoint OnPrem server is four standard solution files on a site collection level
- AgilePoint Workflow Launcher – This is a single step SharePoint workflow which makes gets kicked off based on a SharePoint event like add/update document and is pretty much standard SharePoint behavior and configuration. All this SharePoint workflow does is to read the configuration from a centralized SP List which tells that for this library and the specified event (add/update doc) which workflow needs to be kicked off and it make an API call to AgilePoint to pass in context of the list/library alongwith metadata in case workflow has to use metadata for some routing.
- AgilePoint Dashboard – This is a webpart where you can manage your workflow tasks and open forms.
- AgilePoint Configuration List – This is a config list which tells which AgilePoint server you need to connect to and also stores the list and workflow association row which is nothing but a small XML based structure stored as string.
- AgilePoint ListForm – This is optional component which is utilized for dynamic rendering of SharePoint ListForm UI in task forms provided you decide to use standard SharePoint ListForm as UI instead of eForms. However this is not very commonly used as eForms provides a much more richer UI so we will ignore this during our discussion and assume eForms as the UI.
So as you can see from above list, the individual workflows never get deployed on SharePoint farm itself. This keeps architecture clean and result is easier management of workflows where if you make change to workflow on AgilePoint server, it becomes available on all SharePoint lists across farms immediately.
Here is a quick view of network topology for a typical installation in a org with multiple SP Farms
Centrally Hosted Regional Deployment, Shared AgilePoint Server Instance
I had explained the department level multi tenancy in my other blog post mentioned below
Independent Scaling of Environments: As mentioned in previous point, one AgilePoint farms can serve request from multiple SP farms. That means you can scale your SharePoint farms independent of AgilePoint farm and they do not bear a 1:1 relationship which otherwise could have been a huge investment for big enterprises.
License and Pricing Advantage: Since one AgilePoint farms can serve request from multiple SP farms, you do not have to invest in AgilePoint license each time to add a server in a SharePoint farm. So if a client has 20 servers spread across 7-8 SP farms, they might still support that with 2-3 server AgilePoint farm with lot lesser price compared of SharePoint Add-Ons which will need additional licensing for each node they add to SP Farm.
Reusable and Generic Doc Approval Workflow Patterns: Now with all of the above topics out of the way, I would like to spend most of the time discussing how you could reduce your development and maintenance effort.
A lot of times when people talk about such big deployments, there is quite a lot of interest around how can I increase re-usability of workflows where same workflow can work against multiple lists across site collection or even farms. However the way I look at it is that this has to be further broken down into 2 sub categories i.e. reusable workflow and generic approval workflows
Reusable Workflow: Often times you want to design forms which show very specific data on tasks forms and some of which might come from SharePoint List/Library metadata for e.g. if your list has a amount field and a department field and you wish to show that on the approval forms, this app became very specific to certain scenario where it used certain custom metadata elements on the form. You however still might have say 500 libraries which have same metadata columns across say 7 farms. Can you reuse the same workflow? The answer is yes. I had covered that in one of my other blog posts
Generic Document Approval Workflows: The kind of reusable workflow scenario I described above is not generic enough as it shows some custom metadata columns on the task form i.e amount, department etc. because if I associate this on a library which does not have these columns and when user opens the task form, these fields would be rendered blank and might not even make sense. Even worse can be the fact that if any workflow routing logic depended on those non-existing fields it might take the non-desired route unless you handled the blank condition in condition builder explicitly.
However what you would find is that most document approval workflow approval UI can be kept quite generic where you show standard fields like document name, uploaded date, requester, approver comments etc. If you desire to have mass scale deployment of same workflow you can decide to keep specific metadata columns out of the task UI. You can ofcourse decide to render or hide certain fields conditionally using forms rule builder which too would be a decent approach provided you don’t end up with a whole lot of permutation and combinations of such rules. If the # of permutation and combinations are manageable, you can even conditionally show some custom fields but I am not a huge fan of overdoing that as there can be numerous permutations across say 100K libraries.
Now assuming you have a generic workflow, the next obvious question is how can I reduce my effort of going to each one of them and setup virtual association between SharePoint event and AgilePoint workflow as explained in the “Deployment Architecture” section above. Just the first time setup across say 100K list/libraries can be significant work in that case even though you do not have to manage it afterwards.
Typically this can be addressed easily by writing a workflow association utility where you could do some sort of bulk association using both SharePoint and AgilePoint API’s but personally I feel this is a perfect place to bring in the power of content type based workflows. For SharePoint OnPrem, AgilePoint does support associating workflows at content type level which can avoid the need of associating workflows on each of the list/library.
Now you can ofcourse do site collection level content types but in such a huge farm with 30-40K site collections it can still be significant. This is where I feel the content type hub feature from SharePoint comes in handy. Using this feature you could create a web application designated as content type hub and associate that with managed metadata and then define your content types in one single place. AgilePoint workflows can be associated right at the source of these content types in content type hub as for us it is just like any other web app where AgilePoint four standard features are activated and these content types are visible in all the other web apps and site collections.
This way you are managing workflow association just at the content type hub level and even if you had 5-10 separate farms with 30-40K site collections and 100K lists wanting to use this generic workflow, you had to manage association just in that 5-10 content hub which is ofcourse doable manually and that too if you remember is a one time deal. This way you can avoid writing customized and auto workflow association utility.
The great thing about this feature in SharePoint is that if you inherit from this content type in individual site collections and create a new content type, it carries over the default workflow association but also gives you flexibility of changing the workflow association in a particular site collection if a need arises.
In order to read more about the content type hub feature, please refer to following articles
http://www.c-sharpcorner.com/UploadFile/40e97e/create-content-type-hub-in-sharepoint-2013/
It does not have to be an either an or pattern. You would perhaps not have one single generic workflow but some logical combination of workflows all of which can be reusable for their specific use case scenario.
We have bigger enterprises already using SharePoint content type hub feature and saving tons of effort using the AgilePoint content type level workflow initiation capabilities with it so definitely a feature which needs to be considered with large number of list and libraries. Again the preference might differ from org to org but in my opinion this is an effective strategy for larger deployments.
There are ofcourse a lot of other advantages AgilePoint NX brings in terms of scalability, performance for large scale deployments and has a proven track record over the years and it would be difficult to cover all of them in this article but hopefully the above mentioned key points give a sense of how AgilePoint can excel in a large scale SharePoint deployment.