Updating the WebViewer Version in Salesforce

Summary: Stay up-to-date with WebViewer updates in Salesforce to enhance productivity and user experience with the latest features and performance improvements.

In a recent article, we looked at how to get a simple WebViewer based app running within the Salesforce UI.

In this article, we will look at how to update the version of WebViewer that is used when working within Salesforce. There are good reasons why you might want to do so. WebViewer is being actively developed, so new functionality is being added at each release, whether that is DOCX editing within the browser (which will soon support undo and redo), or simple customization via the Modular UI, or a myriad of other improvements.

Once you have WebViewer running within Salesforce, you can find the version of WebViewer by opening DevTools in the browser (typically by using F12). When WebViewer initializes version info is written to the console.

You can then use the Apryse Change log to find out when that version was released.

It looks as though the version that I currently have installed (10.9.0) is a few months old, and there have been two releases since then, and they contain some great new functionality, so I should probably update my version of WebViewer.

WebViewer is great and it is very functional. As a result, it uses a lot of code to implement that functionality. That’s a problem because Salesforce implements a system that prevents very large files from being uploaded. There are good reasons for that, primarily to avoid large slow uploads from giving other users an unresponsive experience, but it means that it is not possible to upload the WebViewer library directly to Salesforce as a single file.

Don’t be deterred, though: Apryse have a simple system for working around this problem, breaking the large file into a number of smaller ones, allowing you to easily and efficiently upgrade WebViewer as, and when, you wish to.

The clever Developers at Apryse have created a script that initiates a wizard to walk you through the steps of generating files that are small enough to upload to Salesforce. Better still, the wizard allows you to create the minimum set of files that are needed for your app within Salesforce. The parts of the library that you are not going to use are removed, making for simpler, faster deployment.

This article was written with the following versions:

Download the WebViewer.zip file and extract the file into a folder of your choice.

In the next step we will optimize the files that need to be uploaded, but doing so requires us to use some tools that need to be installed. Getting those tools is easy. You just need to call:

Depending on the version of Node that you are using you may get some warnings associated with DevDependencies. You can safely ignore them for now as they do not relate to things that will be shipped.

Now you are ready to start optimizing the WebViewer distribution files. This process is initiated using a script.

This will start a wizard that will lead you through the steps needed to select exactly which parts of the functionality you will need.

If you get an error saying Cannot find module ‘command-line-args’ then you probably need to install the dependencies (see step 2).

The wizard will lead you through a series of questions (these may change over time) and some options are only shown in some situations, but for now they typically are:

Do you want us to backup your files before optimizing? [y/n]

If you are starting from scratch (which is probably the case if you are reading this article) then it is safe to enter n.

Will you be using WebViewer Server? See https://docs.apryse.com/documentation/web/guides/wv-server/ for more info. [y/n]:

For the basic sample, you won’t need the web viewer server, so you can enter n. If, however, you were to extend the app to work with things like CAD files, then you would need the server.

Will you be converting all your documents to XOD? See https://docs.apryse.com/documentation/web/guides/optimize-lib-folder for more info. [y/n]:

XOD is an Apryse proprietary format that is an alternative to PDF. Unless you are using it you can enter n.

Do you need client side office support (docx, pptx, xlsx)? [y/n]:

WebViewer supports viewing of Office files. If you are going to do this in your app, as is the case in the basic sample, then enter y.

Do you need client side office support for legacy office files (doc, ppt, xls)? [y/n]:

WebViewer supports modern and legacy office formats separately. If you need to use the legacy formats, then enter y.

Do you need the full PDF API? See https://docs.apryse.com/documentation/web/guides/optimize-lib-folder]:for more info (most users don't need this option). [y/n]:

The full API is needed for more complex, non-everyday functionality, such as Redaction. The basic sample app supports redaction, so if you are using that then enter y.

Do you want to use the production version of PDFNet.js? The production version does not have type checking and console messages but is much smaller than the development version. [y/n]:

Choose whichever version you prefer.

Do you need to use the content editing feature? (This is for editing content on the page in the viewer) [y/n]:

WebViewer allows you to edit the content of the PDF. If that is required within your app then it should be enabled. The basic sample though doesn’t support this, so enter n.

Do you need to use the office editing feature? (This is for editing docx files in the viewer) [y/n]:

WebViewer has supported the ability to edit DOCX files directly within the browser, and without any additional dependencies. It’s a great feature, so let’s have that available. Enter y.

Do you need to deploy to Salesforce? See https://docs.apryse.com/documentation/web/guides/optimize-lib-folder for more info (most users dont need this option). [y/n]:

Enter y

Would you like to use the web component version of WebViewer (instead of the iframe)? [y/n]:

Salesforce needs the iframe version of WebViewer, so enter n.

Great stuff!

The Wizard now shows you which files will be changed, and asks you to confirm that you want to proceed.

So, enter y to accept that it is correct.

The console will then show lots of output and finally tell you what you need to do next. We will come back to that later.

What has happened behind the scenes, is that a new folder has been created called webviewer-salesforce. This contains a set of zipped files and associated xml files (plus unzipped folders which you don’t need) The script has been designed so that each of the zip files is less than 5MB in size, and therefore small enough to be safely uploaded to Salesforce.

Awesome! Each file contains a facet of the functionality, along with a zipped file and a resource-meta.xml file.

I’m assuming that you already have an app running within Salesforce – if not then check out the previous article, which forms the basis of the screenshots in this article.

Open the source folder for the app within VS Code (or another editor) and navigate to the force-app/main/default/staticresources folder of the project.

That folder is where the GitHub sample holds the WebViewer files that the App needs. If you have built a project from scratch, then it is possible that your files will be located elsewhere, but in that event, you probably also know what you are doing, and can find them.

Now copy the zip files that you have just created, along with the associated resource-meta.xml files and drop them into this folder.

Now deploy those files to your Org. If you are not sure how to do so, then have a quick look at the Getting Started with Salesforce blog. In my case I’m using a scratch-org.

This may take a minute or two, since there are many files to be deployed.

Great head back to the Salesforce UI, reload the App, open DevTools and the WebViewer version will have been updated.

That’s it!

If you need to rerun Optimize, then it is recommended that you delete the folder that you have previously used, and re-extract the WebViewer.zip file into a new folder.

As you are only uploading files to support a subset of the WebViewer fucntionality, it is possible to try to use functionality from the WebViewer UI for which the supporting library files are not available, or cannot be found.

One example of this would be if you try to edit a DOCX file in WebViewer, but when optimizing the files you did not include that as an option, resulting in the various office_edit.zip files not being available.

In that case an error will occur which is visible within DevTools.

If this happens then run the optimize script again and include the functionality that you previously had declined.

Now that you know how to get the latest version of WebViewer, keep an eye out for the updates as they are released. There is lots of great functionality already available and more is under development.

If you run into any problems, or have a request for functionality that is not yet available, then contact us on Discord.