The main message is there isn’t a “one size fits all”, and there are lots of approaches, all of which are valid and highly cost-effective, in the right situation. This blog post explores a few of these approaches by looking at the technology building blocks an App typically needs - i.e. a user interface, data storage, business logic, and possibly process implementation. DevOps is also considered for completeness.
1. User Interface.
It wouldn’t be an App without some form of user interface. Starting with the quickest and simplest, PowerApps provide a mobile-ready mechanism to get data into a SharePoint list but are very limited.
Assuming SharePoint list is still the destination for the data, and a more complex form is required the next step up is to use a Nintex Form.
For large or complex forms where flexibility is required then a bespoke form built as an SPFx web part is the best choice. These can use the Office UI fabric providing a native SharePoint look and feel and will follow the SharePoint ‘theme’.
Interestingly, although the time required to produce a simple form increases as you move through these technologies, the opposite happens on a large complex form and it can be faster to develop large complex forms with SPFx.
2. Storing Content.
The simplest option is to use a SharePoint list. These are easy to access and simple to change and If PowerApps or Nintex forms is the choice of forms technology, then this is the only choice.
For SPFx based forms the options increase to include either SQL tables or a document database. Where the database schema is pretty much fixed then SQL tables are probably the right approach and will give good transactional processing ability. Where the data schema is changing, something we see a lot of in agile projects, then a document database such as Azure CosmosDB is a more flexible and faster option. Documents (JSON packets) are stored directly. Beware however that once the system is live it’s harder to modify data across all documents.
3. Implementing Business Logic
More complex business logic will need to go beyond client-side code, and this is achieved by calling a web service. For the Microsoft world, this means calling an Azure function, possibly via the runtime automation service if the run time is expected to exceed 10 minutes. These functions can use elevated privileges when calling back into the Office 365 subject to the App authentication.
4. Process Implementation
It feels like this blog post is going to go out of date rather quickly as this is a fast-moving area. A few years ago, third-party products dominated process implementation, or workflow, and of these Nintex was one of the favourites being embedded in SharePoint. Moving forward to today and Microsoft are rapidly building out the capabilities of Flow – their own workflow tool. At present only Nintex provides extensive task management and can handle long-running workflows, they have also introduced new products to keep ahead of the game including a very comprehensive tool to document your processes called ProMapp and a robotics engine called FoxTrot to drive workflows from a spreadsheet.
Just a quick piece on this since, if you end up building SPFx web parts, a lot of the DevOps tooling is supplied for you including Yeomen and Gulp. Source control is up to you, BitBucket is our favourite. The main issue to beware of is that SPFx web parts are deployed tenancy wide (so too are Termsets). This makes testing on the same tenancy tricky once you’ve gone live and the best advice, we can give here is to get a second tenancy for testing.
Author: Paul Turnbull, Managing Director at Deltascheme