Install on your existing Azure resources

Already have an Azure web app, an Azure SQL database and a storage account? DocView Capture can use them. Nothing new is created in Azure, and DocView stays out of everything else they hold:

• in the database, all DocView's tables go in a schema of their own, for example docview;
• in the storage account, DocView's files go in a container of their own, or a folder in a container you already use;
• the DocView Worker, which reads, classifies and exports the batches, runs inside the web app as a WebJob, so you need no second app.

To create everything new instead, see Install on Microsoft Azure.

What you need

Step 1: Fill in the settings file

Copy deploy\azure\existing\docview.settings.json from the release and fill it in. It holds:

Important: The filled-in file can hold passwords. Keep it private and don't commit it to source control.

Step 2: Run the script

.\deploy\azure\existing\Deploy-DocViewToExistingAzure.ps1 -SettingsFile .\docview.settings.json -Package .\DocViewCapture-AppService-1.6.0.zip

The script:

1. checks the settings and writes them as App Service settings to docview.settings.appsettings.json;
2. with the Azure CLI signed in, applies them to the web app, switches on 64-bit, Always On, Web sockets and HTTPS only, and gives the web app a managed identity;
3. deploys the package (the web app and its DocView Worker WebJob) and waits until DocView reports it is ready;
4. prints the web app's address, the setup token, and the commands that give the web app's identity access to the database and storage.

To only write the settings, add -SettingsOnly. Without the Azure CLI, the script writes the settings and tells you what to do in the portal:

1. Web app › Configuration › Application settings › Advanced edit: paste the content of docview.settings.appsettings.json, select OK, then Save.
2. Configuration › General settings: Platform 64 Bit, Always on On, Web sockets On, then Save.
3. Deployment Center, or https://<web app>.scm.azurewebsites.net/ZipDeployUI: deploy DocViewCapture-AppService-<version>.zip.

Step 3: Give the web app access (managed identity)

When the database and storage use the managed identity, give it access once.

Database: connect to the database as a Microsoft Entra administrator, for example with the query editor in the portal, and run:

CREATE USER [my-existing-webapp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_owner ADD MEMBER [my-existing-webapp];

If DocView may not be db_owner, create its schema yourself and give it the rights on that schema only:

CREATE SCHEMA docview AUTHORIZATION dbo;
GRANT CREATE TABLE TO [my-existing-webapp];
GRANT ALTER, CONTROL ON SCHEMA::docview TO [my-existing-webapp];

Storage: give the web app's identity the role Storage Blob Data Contributor on the storage account or on the container (storage account › Access control (IAM) › Add role assignment).

Step 4: Finish in the browser

Open https://<web app>.azurewebsites.net. The first start creates DocView's tables in its schema and can take a minute.

• With a firstRun.adminPassword: sign in as DocView. Then remove the Bootstrap__AdminPassword setting from the web app; it is only used once.
• Without it: open /setup, enter the setup token the script printed, and create the administrator. The database and storage steps show what the settings chose; you can't change them there.

Check that the DocView Worker runs under Administration › DocView Workers. In the portal, the web app's WebJobs shows DocViewWorker: Running.

DocView Workers and OmniRead that scale by themselves (Container Apps)

Instead of the DocView Worker WebJob, the DocView Worker, and optionally DocView OmniRead, can run in Azure Container Apps. They start when there is work and stop when there is none, so you pay only while they run. Container Apps also gives each subscription a free monthly allowance. The web app then only serves the screens, and a Free or Basic plan is enough.

Templates: deploy/azure/existing/container-apps/worker.yaml and omniread.yaml. You need a container registry (Azure Container Registry, Basic) with the two images, and a Container Apps environment with workload profiles (OmniRead needs 4 vCPU and 8 GiB). Give the web app Cloud__OmniReadUrls (OmniRead's internal address) and Cloud__OmniReadKey; DocView records them by itself.

Things to know:

• Exports go to DocView's storage. A container's own disk is temporary, so Batch Setups export with DocView storage (files under exports/ in the storage account) or to SFTP, SQL or REST, not to a folder. New Batch Setups do this by themselves when DocView's storage is in the cloud.
• The first batch after a quiet time waits for a DocView Worker to start, about a minute (OmniRead: two to three minutes the first time, while its models download).
• Mailbox and watched-folder imports and scheduled tasks run in the DocView Worker: they run only while a DocView Worker is running. Keep one DocView Worker running (minimum 1) if you use them.

Changing settings later

All DocView's deployment settings are ordinary App Service settings, so change them under Configuration:

Upgrading

Run the script again with the new package. The settings stay as they are. DocView upgrades its tables in its schema when it starts.

Linux web apps

The package is for Windows web apps. A Linux web app (Web App for Containers) runs DocView's container image instead (docview-capture-web, from your registry). Use the same settings as above, written with __, and run the DocView Worker image as a second container app or web app. See Install with Docker.

Troubleshooting