Integrating with Office for the web
- Need register : Office 365 Cloud Storage Partner Program.
- WOPI REST API used
- PDF not supported
The Office 365 - Cloud Storage Partner Program is intended for independent software vendors whose business is cloud storage. It is not open to Office 365 customers directly.
You can integrate with Office for the web to enable your users to view and edit Excel, PowerPoint, and Word files directly in the browser.
If you deliver a web-based experience that allows your users to store Office files or includes Office files as a key part of your solution, you now have the opportunity to integrate Office for the web into your experience. This integration works directly against files stored by you. Your users won’t need a separate storage solution to view and edit Office files.
Participants in the Office 365 - Cloud Storage Partner Program must support document editing and multi-user co-authoring.
You can make viewing available in two ways:
By using the high-fidelity previews in Office for the web as an integrated part of your experience. For example, you can use these previews in a light box view of a Word document.
By offering to show Office files in a full-page interactive preview. Depending on your solution, this might be useful for file browsing or showing read-only files to users or in cases where users don’t have a license to edit files in Office for the web.
Editing is a core part of Office for the web integration. When you integrate with Office for the web, your users can edit Excel, PowerPoint, and Word files directly in the browser. In addition, users can edit documents collaboratively with other users using Office. In order to edit documents, users require an Office license.
Read XML from Office for the web that describes the capabilities of Office for the web. This is called WOPI discovery.
Implement REST endpoints that Office for the web uses to learn about, fetch, and update files. To do this, you implement the server side of the WOPI protocol.
Provide an HTML page (or pages) that wrap Office for the web. This page is called the host page.
The following figure shows the WOPI protocol workflow.
To do this, you will need to ensure that your solution meets a few basic requirements.
Authentication is handled by passing Office for the web an access token that you generate. Assign this token a reasonable expiration date. Also, we recommend that tokens be valid for a single user against a single file, to help mitigate the risk of token leaks.
Office for the web does support multiuser authoring scenarios if all users are using Office for the web. However, you are responsible for managing conflicts that may come from applications other than Office for the web, either with some form of file locking, or by using another type of conflict resolution.
Ensure that files are represented by a persistent ID. This ID must be URL-safe because it might be passed as part of the URL at different times. Also, the ID must not change when the file is renamed, moved, or edited. This ensures an uninterrupted editing experience for your users.
You should have a mechanism by which users can clearly identify file versions through the REST APIs. Because files are cached to improve viewing performance, file versions are extremely helpful. Without them, users can’t easily determine whether they have the latest version of the file.
Office for the web is designed to work for enterprises that have strict security requirements. To make sure your integration is as secure as possible, ensure that:
All traffic is SSL encrypted.
Initial requests to Office for the web are made by using POST, where the access token is in the body of the POST request.
Office for the web identity can be established by using a public proof key to decrypt part of the WOPI requests. Also, the Office for the web file cache indexes stored file contents by using a SHA256 hash as the cache key. You can pass Office for the web the hash value using the SHA256 property in the CheckFileInfo response. If not provided, Office for the web will generate a cache key from the file ID and version. To ensure that users can’t force a cache collision and view the wrong file, no user-provided information is used to generate the cache key.
Business users require an Office 365 subscription to edit files in Office for the web. The simplest way to implement this is to have users sign in with a Microsoft account or other valid identity. This establishes that they have the correct subscription. To limit the number of times a user needs to sign in, Office for the web first checks for a cookie.
If you’re interested in integrating your solution with Office for the web, take a moment to register at Office 365 Cloud Storage Partner Program.