Office集成技术路线，轻松实现文档与系统的互联互通
做OA、文档管理系统以及系统集成很多年，和各种版本Office打交道烦恼问题，客户投诉等问题层出不穷。 自从遇见畅写Office一切都变了，颠覆了我这么多年系统集成观念。不能不说技术释放生产力、提升集成系统开发效率，为企业节省成本，关键的客户没有投诉了，客户不需要来回折腾切换浏览器使用系统了。
采用传统的ActiveX控件机制集成Office带来哪些问题？
以下问题就是通过****网站搜索出来的，简单进行了分类检索和统计结果，个别结果估计不是很精确、但数据差别不大。这里不得不说****的搜索功能做的很不赖，要赞一个！大致分为以下几类：
- 未知原因不可用：100多万的问题条目，我相信这不仅仅困扰百万人使用的问题，实际比这个数字恐怕更高。
- 安装失败：这里的安装失败指的是安装控件失败、由于控件对于浏览器要求严格，版本要一致。当然这里面估计也包含在非IE环境下安装ActiveX控件的情况，因为我们研发人员往往高估了最终用户的技术能力，其实他们是不会分辨浏览器的。
- 无法**：正确安装情况下，加载控件的时候无法**，仍然是不可用，这里面包含了200万条目，这里面估计是IE浏览器安全性较高设置的原因，或者控件不支持https的因素导致的吧。
- 无法启动Office：这里的问题就是控件安装和**成功了，就是无法驱动本地Office的情况。
- 无法安装：这个问题条目最多，估计包含了安装失败的问题条目。
- 加载失败：ActiveX的控件不是静态加载的是动态加载的，当浏览器需要关联Office的时候才会去加载控件。这个过程是控件起到连接浏览器与本地Office作用，同时也是比较容易出现问题的时候。对于Office版本、浏览器的版本要求都比较严格，前期做好适配这个环节问题会减少。
Office控件跨平台支持的问题，尤其是支持移动平台的问题一直困扰着大家
- 可怜的只能支持IE浏览器，可是微软都转投Chrome阵营了，国内的浏览器厂商也纷纷优先基于CHrome研发浏览器。
- 移动端支持简直就是噩梦，由于基于安卓OS的手机厂商众多、一只手都数不过来，各自平台上的默认浏览器都是阉割版的浏览器，版本更是多的2只手都无法数过来。
- FireFox浏览器还是比较有点良心，仍然可以采用NPAPI的机制支持插件，可惜需要系统人员重新适配开发插件以适配应用。
反思：为什么在互联网技术发达的今天，为什么不尝试一下创新呢？ 一切都是上云了，我们还在原地踏步
ActiveX早期发展确实解决了我们很多问题，解决了浏览器启动本地程序并且解决了本地程序与系统的通信和数据交互问题。在20年前桌面应用居多，网络应用比较少，因此对于浏览器控件的需求非常强烈。可是随着互联网技术与应用的发展，已经出现了倒置的情况，再按照原来的思路解决问题已经不适应了。我们需要寻找新的技术解决方案替换旧的解决方案，需要进一步释放研发人员的生产力，让他们投入的应用业务创新上去，这些事情需要交给更为专业的厂商去做，效率高、成本低还有服务。
尝试云端Office的方案，有一种柳暗花明又一村感觉
1、兼容微软Office原生文档格式，并能很好的支持浏览和编辑
我们之所以使用浏览器控件启动本地Office，无非就是完成文档预览展现、编辑以及协助我们完成工作流程吗？ 云端Office已经完好的兼容了微软Office原生格式，最初的目的我们达到了，这也是云端Office必须要过得关卡。
2、 告别ActiveX控件的开发，从此告别用户使用控件的烦恼
基于云端的SDK，一切都是采用脚本语言来完成连接和回调，不再需要控件了。告别了原来脚痛医脚、头疼医头的方法。彻底从技术路线上颠覆，给用户营造一个平滑无缝在线处理文档的环境。
3、业务或者表单数据更加无缝的可以和文档实现互操作
这里的互操作指的是数据可以通过云端Office接口插入文档，文档内容可以通过接口*回传给系统或者表单，一切都默默的在线完成，让研发人员更加专注自身业务的处理。
4、技术转换成服务，更加高效推进系统集成效率
无论是采用原来的控件的方式解决问题，还是采用开源的项目配置云端Office自己解决问题也罢。这仍然是停留在非专业的人干专业的事情，既浪费了精力又节约了成本、同时也拖延了项目或者产品交付的周期。在目前人力成本较大的今天，需要改变一下思路。通过集成调用第三方服务的方式都能达到节约成本、提升集成研发效率、完成项目交付需求。这里有个技巧可以分享给大家。
5、案例分享
畅写Office提供了免费的公有云SDK，去百度搜索“畅写Office” ，进入SDK官网，免费提供文档集成服务、文档预览、文档交互等服务，同时也开放了源代码和示例，不仅可以在SDK网站上操作演示、同时也可以参照示例代码几分钟就可以把云端Office集成到项目里面去。关键是免费，可以快速向老板、向客户进行演示。