Sunday, 11 March 2018

Evolution of SharePoint Solution Design Principles

Overview: Over the past couple of years I have strict rules I use when developing full SharePoint applications on SPO, SP2013, and SP2016.

Hypothesis: Since SPO does not allow FTC and many large enterprises have been trying top remove FTC (governance preparing to move to O365) I follow the basic concept of using no FTC on any WFE's. Small single pages and applications are merely JS injection changes. I'm talking about large applications.

JS injection is my biggest tool to bend SP. In the old days, I used WSP's. When JS won't cover the tasks. I deploy my code thru a custom XML driven console or PnP, I also have an old XML driven PowerShell script for deploying the code to each environment. This allows me to store our code in TFS or GIT. package and deploy to multiple DRAP environments.

I use C# consoles that are generally XML driven calling the CSOM API for provisioning sites and then the actual application is also XML driven. I also have XML driven content for automated testing in lower environments or seed data needed for production setup.

Lastly, if I need a transaction database I use Provider Host Apps (Add-ins), I also would use a server-based WCF for any long-running processing that I want to fire from the web.

Workflows, I tend to use what the customer has Ninetex or K2 I have seen a fair amount. Most workflows are pretty basic once the client's actual need has been clarified and the business process work out so I keep it simple.

Reporting, still use the SSASA, SRS and SSIS and a mix in between if I can. Basic SharePoint KPI's are my first choice. I have integrated other products like Tableau.

Timer Jobs, I use C# consoles and log to a central place. I read the server performance to ensure I don't destroy the farm when using multi-threading. I fire off using windows scheduled task (or equiv i.e. ControlM).