Using solutions to update your canvas apps is the recommended way but makers do not always have access to solutions. Exporting and importing the canvas apps is the only available option then but that does not mean there is no way to have a more professional update process.
This blog post describes how to improve the process of updating a canvas app. The concepts “Maintenance mode”, “Session timeout” and “Version check” as described in this blog post are used and assumed to be available in the canvas apps.
There are several ways to implement the update process described in this blog post. An example is given at the bottom of this blog post.
Update process
For writing convenience, it is assumed that one canvas app is updated but this update process can also be applied when updating multiple canvas apps. The following steps updates the canvas app:
- Reduce the session timeout.
- By shortening the session timeout, the time to wait between enabling maintenance mode and updating the canvas app is reduced.
- Enable maintenance mode.
- Wait for the amount of time for all possible sessions to timeout. Also take into account the possible sessions from before executing step 1!
- Update the canvas app by importing the new version and updating the related canvas app.
- Change the version of the canvas app.
- Execute a Go/No-Go test.
- Go
- Increase the session timeout.
- Disable maintenance mode.
- No-Go
- Execute a rollback.
- Increase the session timeout.
- Disable maintenance mode.
- Go
To be able to execute a Go/No-Go test, it must be possible to configure which accounts can start the canvas app and ignore the maintenance mode setting. This configuration must be cleared after the Go/No-Go test. No code example is shown for this in the example below.
Communication about the update and how to come to the point of updating (Application Lifecycle Management) is import too of course but no part of this blog post.
Alternative setup
The update process described in the session “Update process” minimizes the amount of API request. The alternative setup described below will result in more API requests but will cancel the need to wait between setting the canvas app in maintenance mode and updating the canvas app.
In the alternative setup, the maintenance mode and version check is executed every time when the session timeout check is executed too. This way, maintenance mode and a version mismatch is not only noticed on app start but also noticed at specific points in the canvas app.
Example
There is a SharePoint list called Settings which has (at least) these columns:
- Title: A default column which is used to contain the setting name. Examples: Maintenance, Timeout and Version
- App: A custom column of type “Single line of text” which is contains the related canvas app.
- Number: A custom column of type “Number” which is used to contain the session timeout in minutes.
- Record status: A custom column of type “Single line of text” which contains the state of the item (record).
- SLoT: A custom column of type “Single line of text” which is used to contain the app version.
- YesNo: A custom column of type Yes/No which is used to set maintenance mode for a canvas app.
When the canvas app is started, the settings are retrieved from the settings list. Below, an example of the code for the checks is given.
*** App.OnStart ***
Set(
glb_AppStart,
Now()
);
Set(
glb_Version,
"1.2.3"
);
*** Start Screen ***
ClearCollect(
coll_Settings,
Filter(
Settings,
('Record status' = "Active") && (App = "...")
)
);
Set(
glb_Settings_Maintenance,
LookUp(
coll_Settings,
Title = "Maintenance",
YesNo
)
);
Set(
glb_Settings_TimeOut,
LookUp(
coll_Settings,
Title = "Timeout",
Number
)
);
Set(
glb_Settings_Version,
LookUp(
coll_Settings,
Title = "Version",
SLoT
)
);
If(
(glb_Version = glb_Settings_Version) && (!glb_Settings_Maintenance),
true, // All is good. Proceed :)
false // Navigate to a screen which shows a message related to trigger (Maintenance mode / Timeout).
)
*** Session timeout check ***
If(
DateDiff(glb_AppStart, Now(), Minutes) < glb_Settings_Timeout,
true, // All is good. Proceed :)
false // Navigate to a screen which shows a message related to trigger (Version mismatch in this case).
)