Wednesday, 28 March 2018

TFS Scrum for SharePoint Projects

Great information on TFS for Scrum, Agile & CMMI from Microsoft.  My preference is to use Scrum with a couple of twists from Agile and external tooling.

Tip:  I use User Stories extensively in SCRUM and with TFS all the testing and automation fits in brilliantly.  CI/CD is a choice between TFS build and TeamCity.  Also, my acceptance criteria are always written using gherkin language to ensure consistency.

Below are a few posts that are a couple of years old outlining Agile and Scrum for SharePoint projects:
Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum

Friday, 23 March 2018

An approach to building transactional systems in SharePoint

Overview:  It is common with modern SharePoint development to store transaction high volume data inside a SQL database and expose the application data using WebAPI or a WCF.  The application, e.g. SPA's, Angular or SharePoint pages itself merely calls the "web service" and viola you have an application that is fast and complex with the SharePoint world.

Problem:  When the WCF/WebAPI goes to the database we use a single account (single account principal).  This is an age-old problem in BI, and web applications.  The solution options are to have the security in the database, or each user needs to have a SQL login. 

Initial Hypothesis:  Generally in the last 20 years the majority of application go for the single principal data access approach.  This means there is no logging in SQL natively and you need to pass in the user's context (usually a username or email address).

My Solution:  I use the single access account principal, so I connect using the same account (either encrypt or use something like Azure Vault, in the old days this was the web.config entry with a username and password.  Each request needs to be unique so I pass in the username with the request, and my queries have users and roles and using these relationships I can validate that my user has rights to perform CRUD operations.  I am a huge fan of SQL 2016, as its performance is miles ahead of SQL 2014 and it supports "TemporalTables".  Now with other older SQL instances, you could build your own database logging (tomb tables is what I use to refer to it as).  Worth noting is that Entity Framework does not support Temporal Tables yet, but surely this will come. 
This solution provides a flexible, fast HA (assuming AOAG) transaction secured system with non-repudiation and full logging.  Overall I find this a great approach to building out complex solutions for my clients. 

This approach also provides an easy re-usable API that can be used to allow other applications and business partners to integrate with the solution.  It also allows for a mobile application UI to be easily added as the API are already in place.

Note: Temporal Tables have been available since SQL 2016 and are available on Azure SQL.

Sunday, 18 March 2018

101 PowerApps for SharePoint on-prem.

Overview:  Microsoft PowerApps is easy and can be used to build robust applications.  It is common for organisations to have data store on-prem and in the post, I look at the Infrastructure to have a Power App that uses data stored on SharePoint 2016 on-prem.

PowerApps can create forms from:
SharePoint: Replace lists on a form
Desktop (think this is being removed by MS)
Online at (Preferred option to build an application from scratch)

Either choose the phone or tablet layout for your application/form.
Do not confuse with SharePoint MS Forms.  SharePoint forms are for basic forms (replaces FOSL), very limited usage whereas PowerApps are the replacement for InfoPath.

PowerApps works nicely with Flows.  Note:  I believe Visio will be able to create Flows with.
Formula-based programming like Excel.
Can also hook to Azure Functions.
Link InfoPath, you can save the PoerApps files to move them around.

Setup PowerApp using O365
Install the "On-prem. data gateway for Microsoft PowerApps" to communicate with on-prem.  Configure the outbound firewall to allow traffic thru
Connect to SharePoint 2016
Laura Rogers presented at SPC2018 on PowerApps

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).

Now the new world with SPFx....

Saturday, 10 March 2018

SharePoint Tooling 2018

On a development/local machine, I have complied this list of tools that I'm likely to use but it completely depends on the development project, approach, and technologies used.  This post lists tools I commonly use as of March 2018:

SharePoint Tools:
  1. SharePoint Inspect
  2. SharePoint Designer
  3. Visual Studio 2017
  4. SharePoint Search Query Tool (CodePlex now PnP)
  5. SharePoint Manager
  6. CAML Builder
Developer Tools:
  1. NodeJS
  2. NPM
  3. Yeoman, 
  4. GULP
  5. Webpack
Design Tools:
  1. Balsamiq (My favourite) - Screens and interaction flow
  2. Updated 2019/12/01 - online drawing tool
  3. Axure - Prototyping
  4. Figma
  5. Microsoft Blend - Screens and interaction flow
  6. Visio - Architecture
  7. MS Access to ERD design
Other Tools:
  1. Visual Studio or Visual Studio Code
  2. SnagIT - Basic video recording with audio and annotate screenshots.
  3. Office & OneNote
  4. NotePad++, add the compare dll plugin
  5. Grammarly
  6. Slack or Teams
  7. Yopmail - useful for creating accounts for testing
  8. BrowserStack
  1. Wireshark
  2. Fiddler
  3. DeveloperTool IE & Chrome
  4. Burp
  5. Telnet
  6. Postman
Source Control:
  1. TFS
  2. TFS online
  3. GIT