Pragmatic approach to push update of Add-In when via SharePoint UI fails

In previous blogpost, I recalled on a malforming COTS Add-In. Once the supplier delivered a fix, our SharePoint IT Operations team executed a change to update the Add-In version in the SharePoint environment. First upload the new version to the SharePoint AppCatalog, and next update the installed Add-In in the using SharePoint site(s). Both steps can be done via the SharePoint GUI, the second via the 'Get It' capability. The operations teams verified the deployment approach first in the acceptance environment, and validated that the problem with Add-In was resolved. All well. However, during the change execution in the productive environment, a problem was raised on the 'Get It' step to update the Add-In installation in the using site: Sorry apps are turned off. if you know who runs the server tell them to enable apps. I first told them to verify that both App Management Service and Subscription Settings Services were (still) enabled on the SharePoint webapplication. On the positive answer, I then concluded the problem to be likely as a glitch in the SharePoint site. The Add-In itself namely was unlikely to have a deployment problem, as we earlier successful updated the deployed installation in the acceptance farm. Thinking out-of-the-box, I next advised the IT Operations team to retry the Add-In update through PowerShell iso via the SharePoint GUI. Either it would work, or otherwise a bigger chance of getting meaningful error information. In our case, the former was true: via PowerShell the Add-In update was successful pushed in the using SharePoint site.

PowerShell snippet:

 $web = Get-SPWeb ‘https://<site-url>’
 $appPackage = Import-SPAppPackage -Path ‘<Add-In deployment package>.app’ -Site $web.Site -Source ‘CorporateCatalog’  -Confirm:$false
 $curAppInstall = Get-SPAppInstance -Web $web | where Title -eq ‘<Add-In title>’
 
 Update-SPAppInstance -Identity $curAppInstall -App $appPackage -ErrorAction SilentlyContinue -ErrorVariable err
 if($err)
 {
     $err[0].Exception
 }

Pragmatic approach to display maintenance message on malfunctioning Add-In

One of the promises of the SharePoint Add-In model is that one can purchase packaged / of-the-shelf Add-Ins to install and use in your SharePoint sites. This promise is picked up by the SharePoint community - although in lesser amount as what Microsoft was expecting. One of the selling charms of using pre-packaged software Add-Ins is that your organization is not self responsible for maintenance, and this is delegated to the supplier. However, this loss of technical ownership also implies that you are dependent on the external supplier to fix their Add-In in case of issue, you cannot call in your own troops to resolve the problem. When such a faulty Add-In is prominent present in your SharePoint site, this is rather confronting: the end-users are visually notified and remembered of the malfunctioning behavior. In case the Add-In is added as a shared AppPart, you can mitigate this effect by temporary hide the AppPart from the page. But in case the Add-In is potentially added by individual users to a personalizable page, this is undoable: you don't want to traverse all the personalized instances of the page, check whether the AppPart is present in that instance, and if so hide or delete the AppPart and save + checkin the modified page instance. And then later when a fix of the Add-In is delivered + tested, redo the same to make it visible again.

So what to do then, to avoid the embarishing user experience with the faulty Add-In? As often in these 'modern Apps' days, it is javascript to the rescue. Ultimately on browser level, every Add-In is included in it's own isolated iframe on the containing SharePoint page. Through javascript the iframe containing the faulty Add-In can runtime be located in the DOM, and if found on-the-fly have it's src modified to refer to a maintenance page instead. The javascript snippet can be inserted via a ScriptEditor added in the shared part of the SharePoint page, and easily removed again once the Add-In behavior is recovered.

Code snippet:

function displayMaintenanceMessage() {
    var addInIframe = 
         document.querySelector('iframe[src*="<identifying part in Add-In start url>"]');
    if (addInIframe != null) {
        addInIframe.src = '/StyleLibrary/snippets/MaintenanceMode.aspx';
    } else {
        setTimeout(displayMaintenanceMessage, 1000);
    }
}

displayMaintenanceMessage();