Office Web Apps was introduced with SharePoint 2010 as a service used to provide browser-based access to Office documents. Office Web Apps (OWA) 2013 modifies the service architecture significantly, enabling the exposure of document interactions through a browser to be customized and expanded within SharePoint as well as outside of SharePoint.
With this architecture change, we need to review the capabilities from a new perspective and question how we can best leverage this service. To start, we need to understand the new architecture changes. From there, how do we manage the health of OWA and apply updates? How do we leverage OWA to build additional capabilities into our applications? How do we expand OWA capabilities? What are the differences in OWA on-prem and OWA Office 365?
In this session, we'll be answering these questions and more. We'll look at the new 2013 architecture and understand how to deploy the service on-prem and manage it properly. We will then look at how to extend the service and take advantage of the new capabilities in both our SharePoint and non-SharePoint solutions. You'll leave the session with a deeper understanding of OWA capabilities, and ready to incorporate OWA into your solution architectures!
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Introducing Office Web Apps as a Tool for Developing Content Rich Applications
1. INTRODUCING OFFICE WEB APPS AS A TOOL
FOR DEVELOPING CONTENT RICH APPLICATIONS
Ryan McIntyre
MCITP, MCPD
Director, Portals & Collaboration
@ryanmcintyre
4. View & Edit Documents While
Mobile
• Frustrated with available apps and additional licensing
• Owns Office and wants to leverage existing platforms
• Look at how to extend OWA to support their needs
10. OWA vs Excel Services
Excel Web App
• Separate farm
• Create/Edit in browser
• Limited BI
• /_layouts/15/xlviewer.aspx?id=
Excel Services
• Dedicated Service Application within
SharePoint farm
• Requires Enterprise
• Supports BI
• External data connections
• PivotChart/PivotTable
• Power View
• /_layouts/15/WopiFrame2.aspx?sourcedoc=
Disable Excel Web App: New-SPWOPISuppressionSetting
Excel Services Compared to Excel Web App: http://bit.ly/1bAWC42
11.
12.
13.
14. 2010 vs 2013
2010
• Simple architecture
• Separate install
• View & Edit Office
documents in a browser
2013
• Dedicated farm
• Licensing enforcement
• Additional Office features
•
•
•
•
Track changes
Comments
Co-authoring
Others
• Create New documents
• Extensible
28. Applying Patches & Updates
• Standard MSI patching
• Server has to be disconnected from farm to be able to
patch it
• Use PowerShell - Remove-OfficeWebAppsMachine / New-OfficeWebAppsMachine
• In place major version upgrades are not supported
• Previous Office Web Apps Server installation has to be removed before new version can be
installed
• Schema will be kept intact within major version, but
not necessarily with cross major versions
• Upgraded Office Web Apps server will work with older WOPI host
29. Patching Process for Minimal Downtime
Office Web
App
NLB
Office Web Apps Farm
Patched Office Web Apps
Farm
32. Extension Points
• Scenario: Programmatically create a new Word document using Word
Web App and save in a library
• Scenario: Open and edit an Office document using OWA behind the
scenes based on an action initiated by a user in our application
34. Custom WOPI Host
Store documents in non-SharePoint environment and
provide access to users through WOPI
1. Two required (minimum) REST endpoints
1.
2.
2.
3.
4.
5.
GET file information - CheckFileInfo
GET file stream - GetFile
Discovery XML located at /hosting/discovery
Access token
Unique IDs for files
Wrap it up in a page
35. Custom WOPI Client
Use our OWA farm to display non-Office
documents
1. Discovery XML used when WOPI binding created from the host
1. Defines our Apps and Actions
2. Create the viewer page (aspx)
3. Deploy (e.g. Simple IIS website)
4. Bind from WOPI host (New-SPWOPIBinding)
37. Call to Actions
• Read MSDN docs
• Read Wictor’s blog series for WOPI Client
• http://bit.ly/1bILKlN
• WOPI Host sample from Shawn Cicoria
• http://bit.ly/1gtsYm1
• Create O365 demo tenant
• Install a farm locally or on Azure, and play
39. Thank You!
• MS-WOPI Specification: http://bit.ly/18XJOak
• Taxonomy workshop plug (contact me if interested)
ryan.mcintyre@neudesic.com
@ryanmcintyre
http://blog.randomdust.com
Notes de l'éditeur
Business model of mobile staff and BYOD
OWA is not Outlook Web Access, used by ExchangeSimply stated, view or edit a document in the browser
OWA
Excel Services
Can use one or the other, set by New-SPWOPISuppressionSetting, not both
Search results previewCSWP hover panelWOPI frame
Show demo on phone
Image from http://farm6.staticflickr.com/5199/7369580478_92ccf6bfbd_c.jpg
This slide is explaining how to perform Office Web App level patching with minimal or no-downtime. Since Office Web Apps implementation is basically stateless, we can move the traffic between old and new versions of the farm. <click>So – what we first need is to have clear plan on what needs to be performed for OS and for Office Web Apps. Having that documented and obviously tested before starting to perform these steps in production.<click>We first take away one of the existing servers from Office Web Apps farm and path that with latest patches. When server is removed from the Office Web Apps farm, we update the NBL pools as well to ensure that there’s no end user traffic landing on this server, until it’s patched.<click>Then we create completely new office Web Apps farm using that particular server by running the New-OfficeWebAppFarm command<click>After that we’ll take following server from the farm, patch it and move it over to newly created patched farm and update the NLB accordingly<click>When we have enough servers patched, we can then move the traffic from NLB to point on the new patched farm. This will basically redirect all new requests coming to Office Web Apps farm to new patched environment. Since Office Web Apps is basically stateless, there’s really no implications for the end users. When requests are landing to new farm, they will just re-convert the Office documents what are being viewed to browser format and they will server the content properly. Starting from this moment, we are serving content using the patched farm.<click>Then we patch the existing servers and move the over one-by-one<click>Until we have final server left, where we can then delete the old farm and move that one over to the new farm side and we have patched then whole farm. Then when there’s again requirements to patch the server, either OS or Office Web Apps, we can perform the same process again. Key point here is to notice that we were able to patch and update the farm without any service breaks. There could have been some slowness during the process for the end users, but still the service it self was up and running without actual breaks. Obviously this means some coordination and strict process to follow, but due the simplicity of the Office Web Apps infrastructure, we can achieve this relatively easily.
<<Possible demo>>
<<Possible demo>>
Re-introduce Contoso’s problemsThey now have some optionsDoes this relate to your company or clients?What are your takeaways?