For existing customers of PrizmDoc who have already done the work to integrate the Viewer into their applications, there is naturally a question about how to, and perhaps more importantly, why migrate to the new PrizmDoc Application Services architecture.

The first thing to know about PrizmDoc Application Services is that there is no requirement that your application migrate to use it. PrizmDoc Application Services makes use of the same RESTful API that your application currently supports, and that won’t change in the future (although we will likely augment this API over time to include more functionality).

However, there are several strong reasons why it’s beneficial to make the switch and use PrizmDoc Application Services:   

• You will know that your application always has the canonical approach to working with the Viewer. No wondering about any odd nuances in the REST APIs that you might be missing.
• PrizmDoc Application Services will always incorporate any changes to the APIs used by the PrizmDoc Server conversion services, relieving your team of having to track those changes for most document viewing tasks.
• Migrating to PrizmDoc Application Services will actually remove significant code from your application, which will reduce your future maintenance costs.
• And perhaps most importantly: we have several ideas on how to utilize PrizmDoc Application Services to add significant functionality to the overall PrizmDoc experience, some of which we’re working on already. Without incorporating PrizmDoc Application Services in your application, you will not be able to take advantage of these new features.

How to Migrate to PrizmDoc Application Services

The work needed to migrate your application to PrizmDoc Application Services can range from simply overriding several routes in your web server’s configuration to having to override several functions from the PrizmDoc Application Services implementation and redirecting them to your own. See which one of the following scenarios best explains your situation:

Scenario 1

If your application has used the web sample code we’ve provided in the past without modifications, then the migration path is simple: install PrizmDoc Application Services and see the help article on how to configure it for your particular web server.

Scenario 2

If you are using a custom storage mechanism for your documents, but not markup files, you might be in a situation where you are using a custom markup id when creating a session. In the previous samples, this is the value of origin.documentMarkupId. If this is the case, you can update your code for creating a session to use the PrizmDoc Application Services ViewingSession API instead of interacting with the PrizmDoc Server. You can provide the same value to source.markupId, allowing PrizmDoc Application Services to use the same custom ids you have used in the past. For more information, see the PrizmDoc Application Services Viewing Session API.

Scenario 3

Things begin to get more complicated if you’ve implemented your own storage mechanism for annotations and/or image stamp files. While PrizmDoc Application Services will be backward compatible with these files when created by our web samples, there’s no way for it to know how you’ve stored your own documents. In this case the only recourse is to override the appropriate calls into PrizmDoc Application Services with calls to your own code to handle persistence.

Note that even in this scenario you can take advantage of most of PrizmDoc Application Services functionality, as you’ll only be overriding a few functions at most.