背景
前段时间,做了一个关于如何集成Office365的调研,探索如何将它集成到应用里面,方便多人的协同工作,这种应用场景特别在内部审计平台使用特别多,一些文档需要被不同角色查看,评论以及审批。
技术方案简介
通过快速的调研,发现已经有比较成熟的方案,其中之一就是微软定义的WOPI
接口,只要严格按照其定义的规范,并实现其接口,就可以很快实现Office365的集成。
上面架构图,摘取至http://wopi.readthedocs.io/en/latest/overview.html,简单讲讲,整个技术方案,共有三个子系统:
- 自建的前端业务系统
- 自建的WOPI服务 - WOPI是微软的web application open platform interface-Web应用程序开放平台接口
- Office online
我们可以通过iframe的方式把office online内嵌到业务系统,并且回调我们的WOPI服务进行相应的文档操作。
界面
界面的原型,通过iframe的方式,把office 365内嵌到了我们的业务页面,我们可以在这个页面上,多人协同对底稿进行查看和编辑。
样例代码如下:
1 | class Office extends Component { |
对前端应用来说,最需要知道的就是请求的API URL,e.g:
1 | https://word-view.officeapps-df.live.com/wv/wordviewerframe.aspx?WOPISrc={your_wopi_service_dns}/wopi/files/ |
视具体情况,请根据Wopi Discovery选择合适的API:
https://wopi.readthedocs.io/en/latest/discovery.html
交互图
接下来就是具体的交互流程了, 我们先来到了业务系统,然后前端系统会在调用后端服务,获取相应的信息,比如access token还有即将访问的URL, 然后当用户查看或者编辑底稿的时候,前端系统会调用office365,它又会根据我们传的url参数,回调WOPI服务,进行一些列的操作,比如,它会调用API获取相应的文档基本信息,然后再发一次API请求获取文档的具体内容,最后就可以实现文档的在线查看和编辑,并且把结果通过WOPI的服务进行保存。
WOPI服务端接口如下:
1 | @RestController |
在WopiProtocalService
里面包含了具体对接口的实现:
1 | @Service |
具体实现细节,请参加如下代码库:
WOPI架构特点
- 数据存放在内部存储系统(私有云或者内部数据中心),信息更加安全。
- 自建WOPI服务,服务化,易于重用,且稳定可控。
- 实现了WOPI协议,理论上可以集成所有Office在线应用,支持在线协作,扩展性好。
- 解决方案成熟,微软官方推荐和提供支持。
WOPI开发依赖
- 需要购买Office的开发者账号(个人的话,可以申请一年期的免费账号:https://developer.microsoft.com/en-us/office/profile/
)。 - WOPI服务测试、上线需要等待微软团队将URL加入白名单(测试环境大约需要1到3周的时间,才能完成白名单)。
- 上线流程需要通过微软安全、性能等测试流程。
具体流程请参加:https://wopi.readthedocs.io/en/latest/build_test_ship/settings.html