《Office 365开发入门指南》读书笔记

将一个分散的多服务器上部署的，以及以PC为主的产品，有机的组合到一起，在一个强大的共享云平台上实现，通过世界各地高速及强大的数据中心，研发出了世界领先的云生产力Office 365智能服务及平台

把针对性的办公模块(如办公"三剑客"——Word、Excel、PowerPoint)、内容管理SharePoint、远程沟通Skype for Business、网盘OneDrive、企业邮件Outlook及团队管理Teams等进行有机整合。

Office 2007除了继续支持Office2003及早期版本的二进制文件格式外,还有一种全新的、基于XML的文件格式(通常在默认的文件扩展名后面添加一个x以示区分,如Word 2003的格式是.doc,而Word2007虽然支持.doc,但更推荐用户使用.docx文件格式)。这个格式后来被正式命名为OpenXML技术,微软在经过实践后将其贡献给ECMA,并被ISO和IEC等组织认定为开发文档格式的国际标准。

由于Visual Studio 及.NET自身发展的需要,另一方面是由于Office及开发人员的需要

VBA很好,但它的局限性也比较明显——它主要适合做应用程序内部的自动化,并不适用于与外界系统或网络资源"打交道",同时对于新版Office的一些特殊功能(如Ribbon或Task Pane等)也缺乏支持。

Microsoft Graph

Office Add-ins

SharePoint Add-ins

Office 365 Connectors

2017年3月初发布的Visual Studio 2017家族包括Enterprise、Professional及Community这3个主要版本,值得注意的是,Community这个版本是免费的,而Office365的开发是完全受Community版本支持的。

跨平台的免费开发工具-Visual Studio Code,所谓跨平台,是指这个特殊的Visual Studio不仅可以在Windows系统中运行,还可以在Mac、Linux系统中运行,同时也能很好地支持开源的开发平台,如NodeJS。

Azure提供了一个Visual Studio Community 2017 on Windows 10 Enterprise 的虚拟机模板,为开发人员快速搭建开发环境提供了极大的帮助。使用云端虚拟机的一个好处是随时随地都可以访问它,当然这会产生一定的费用,为了避免费用过高,可以只在使用时启动该虚拟机。

这里所说的桌面应用程序,特指在Windows桌面上直接运行的.NET应用程序,包括Console Application、WPF Application、Windows Forms Application及UWP Application。 虽然它们的表现形式不同,但本质上是类似的。

ts文件是TypeScript文件,而TypeScript是一种自由和开源的编程语言。它是JavaScript的一个严格的超集,并且添加了可选的静态类型和基于类的面向对象编程。TypeScript是著名的Turbo Pascal、Delphi和C#的发明者安德斯·海尔斯伯格的又一力作。

VBA是最早的一个用来扩展Office应用程序的技术,由于其简单易用目功能强大,在全世界范围内拥有数以亿计的用户。VBA很擅长实现上面提到的这种需求,尤其是当数据本身就来自Excel内部的时候。

学习VBA的一个最好的起点就是录制宏。

VSTO是在Visual Studio 2005这个版本中正式引入的,它的好处是可以基于功能强大且已经被证明成功的Microsoft.NET平台进行编程,这意味着可以使用Visual Studio进行快速开发。同时,使用.NET Framework的全部功能可以访问任何想要的资源。VSTO的开发语言有VB.NET和C#两种。

从短期来看,使用VB.NET可能是最简单的,因为绝大部分语法都是一致的。但从长期来看,我建议大家学习一下C#,这是专门为.NET设计的语言。

我们将纯粹面向工作或学校账号的Azure AD 服务端点称为Azure AD 1.0(或称为Azure AD);而将既支持个人账号,也支持企业或学校账号的Azure AD 服务端点称为Azure AD 2.0。

Microsoft Graph采用Azure AD来进行身份验证,所有的服务请求在调用之前都必须取得合法的授权。目前Azure AD支持互联网上最流行的OAuth身份验证方式。

目前官方提供的CodeSample和SDK有10种,但实际上,任何能发起http请求并能解析JSON数据的开发平台和语言都能调用Microsoft Graph。

Microsoft Graph是一套RESTful的接口,它的所有接口都可以通过标准的http方法(GET、POST、PUT、DELETE)直接访问,而且还可以通过改变URL的参数来进行筛选、排序及分页等操作,它返回的数据是标准的JSON格式。这种特性决定了Microsoft Graph是跨开发平台的。

开发人员的应用程序需要访问哪些Microsoft Graph资源才能得到认证呢?答案是:在Azure AD中对应用程序进行注册,并且申请权限。

目前Microsoft Graph的应用程序注册有两种方式,一种是注册Azure AD应用程序,仅适用于开发人员希望用户能授权访问其工作或学习账号的情况;另一种是注册Azure AD2.0应用程序,适用于开发人员既希望用户能授权访问其工作或学习账号,也能授权访问其个人账号的情况。前者也称为Azure AD 1.0。从趋势上来说,后者将逐渐全面取代前者,成为日后主要的方式。但就目前而言,Azure AD2.0中所提供的服务数量还没有Azure AD1.0多。

一种是Web应用/API,另一种是"本机"应用。前者指的是网站或服务站点,后者指的是桌面应用或移动应用。如果选择前者,需要提供登录URL,并填写对应网站真正的登录路径;如果选择后者,则需要提供重定向URL,这个地址可以随便填写,如http://localhost。

委派指的是代理当前用户进行操作,所以需要用户进行交互式授权。而"应用程序权限"则与具体的某个用户无关,是直接授予应用程序的权限。

(1)Azure AD2.0应用程序既支持访问工作或学习账号,也支持访问个人账号。 (2)注册Azure AD2.0应用程序不需要访问目标用户的AzureAD,是在一个独立的平台注册的。也就是说,这种应用程序是Multi Tenant模式的,有更高的复用性。 (3)Azure AD2.0应用程序的权限是动态申请的,有利于应用程序升级,并且能够简化部署和管理。 (4)微软为Azure AD 2.0应用程序提供了更高级的开发工具支持,在大部分开发平台都提供了SDK。

由世纪互联运营的一个云服务,单从技术角度来看,它基本保持了与国际版的同步。但是由于两个版本在本质上是完全独立的,其中最关键的就是账号系统是分开的,因此从使用角度来看,不管是用户还是开发人员,都会有小小的差异。就应用程序的注册而言,中国版Office 365有几个特点:一是注册地址与国际版不同;二是目前仅支持Azure AD 1.0;三是功能和用法与国际版略有差异。

OAuth认证一般分为以下3个步骤 (1)客户端代表用户发起认证请求(通常是/authorize这个地址),然后会跳转到Office 365的登录页面,让用户输入账号和密码。 (2)如果用户提供了正确的账号和密码并确认授权,Azure AD会向注册应用程序时提供的回调地址(redirectURL)POST一个请求,附上一个code,应用程序需要继续用这个code发起一个请求,申请访问令牌(通常是/token这个地址)。 (3)客户端得到令牌(Access-Token),就可以代表用户访问Microsoft Graph的资源(通常是放在 Update请求的头部里面)。需要注意的是,通常令牌都是有一定时限的,Micrsoft Graph的令牌默认为1小时内接有效。过期前可以通过一定的方式刷新令牌。

而Office Add-in则是为所有Office 365&Office开发人员准备的盛宴,它用来扩展Office 365&Office的功能,也就是我们所说的"插件"。用户可以随时为自己及周围的同事定制一些有意思的功能,它们在本机的客户端(PC&Mac)、云端的在线版本(Office Online)及手机的App中都能运行,并且能给用户带来一致的体验。还可以进一步将这个插件发布到Office Store中,让全世界数以亿计的Office 365&Office用户都可以使用它。

(1)面向Office 365的订阅用户,也面向Office 2013或Office 2016的本地用户。但后者可能在某些细节功能上略有差异。 (2)Office Add-in的开发采用了全新的技术架构(Web Add-in,后面会专门介绍),其主要目的在于实现"一次编写,处处运行"。 (3)Office Add-in拥有一个成熟的生态环境,有庞大的用户群体(据不完全统计,地球上1/7的人在使用Office),既有Office Store,也有配套的技术社区。

WebAdd-in是一个有益的补充(使用它并不意味着要抛弃此前的VBA和VSTO),也是跨平台和移动化的需要。

Web Add-in是由两个部分组成的,首先是用来声明Add-in的Manifest文件,这是一个标准的XML文件;其次是一个标准的Web应用程序,所有的功能都是在Web应用程序中实现的,对于具体用什么技术来实现没有要求,其核心是调用Office.js这个脚本文件完成与Office应用程序的交互。

掌握一门Web应用开发技术(不论是微软的ASP.NET、ASP.NET Core,还是PHP、Nodjs、Python等,都是可以的)。

掌握Web应用程序的托管技术(既可以部署在自己的托管服务器上,也可以部署在微软的Azure App Service 中)。

了解如何将Manifest文件分发给用户(既可以将文件发给用户,也可以集中在Office365中部署,还可以发布到Office Store中)。值得注意的是,Web Add-in对于运行的环境也有一定的要求,具体可以参考 https://dev.office.com/docs/add-ins/overview/requirements-for-running-office-add-ins,这里特别要讲解的是浏览器兼容容性。

)如果Web Add-in是在Windows中运行的,则必须至少安装IE11即使不将其设置为默认浏览器。

不论Web Add-in是在Windows中运行还是在Macos中运行,只接受将5种浏览器设置为默认浏览器:IE 11(或更高版本)、最新版本的Microsoft Edge、Chrome、Firefox及Safari。

为Office客户端添加新功能。例如,单击某个工具栏按钮后,调用外部的服务来处理文档或邮件。这种插件通常会注册一些命令(Add-in command),并关联到Office Ribbon区域,当用户单击后,可以直接根据当前上下文(Office Context)进行操作;或者打开一个任务面板(Task Pane),提供一个界面,让用户可以进一步根据需求进行操作。

为Office文档添加新的内容。主要是指在Excel和PowerPoint中,可以为文档插入一些特殊的对象,如地图、图表和可视化元素等。

创建自定义的Ribbon按钮和选项卡来扩展Office原生果面。

使用HTML和JavaScript技术创建交互界面和逻辑。

可以搭配业界流行的JavaCript框架(包括jQuery、Angular及TypeScript)使用,简化开发。

使用HTTP和AJAX技术调用外部服务。

如果使用ASP.NET和PHP等技术,可以运行服务器代码和逻辑。

Web Add-in 是从Office 2013开始支持新的开发模式的,它具有划时代的意义。主要在于利用业界标准的Web开发技术进行Add-in开发,不仅同时具有跨平台和设备的先天优势,而且集中化部署也降低了运维的复杂性。

在开发工具方面,Visual Studio仍然提供了非常好用的模板,但Visual Studio Code可能是一个更好的选择,尤其是在准备学习和使用基于NodeJS来开发Office Add-in时。

Script Lab,它可以在不离开Excel界面的情况下,快速开始学习Web Add-in的开发。这个插件本身就是一个非常典型的Add-in的范例,是由微软内部开发的,它提供了很多样例代码,可以帮助开发者熟悉全新的、基于JavaScript的对象模型。只要拥有Offce365的账号,就可以免费使用这个插件。

主要由两部分组成：清单文件和真正要用来执行的网站。

其实是一个标准的XML文件,它有固定Schema。目前来说,最新版本的清单文件必须指定"http://schemas.microsoft.com/office/appforoffice/1.1"作为Schema,否则某些功能可能无法正常使用。当然,指定Schema不需要手动去做,毕竟不管是用Visual Studio的项目模板,还是用其他开发工具(如Visual Studio Code),清单文件都是自动生成的,而且默认已经指定了1.1这个版本。

清单文件中的根元素是OfficeApp,这里会指定几个namespace,但同时会有一个至关重要的属性——xsitype

目前支持以下三种类型的Office Add-in。 (1)ContentADD,这是内容应用,主要在Excel和PowerPoint中使用。通过这类Add-in,可以为宿主程序添加自定义的内容元素,如一个自定义地图。 (2)TaskPaneApp,这果应用最广的类型,通过这类Add-in,可以为宿主程序添加自定义的功能。例如,通过一个自定义菜单执行某些操作。 (3)MailApp,这是专门用于Outlook的Add-in。

(1)开发人员本身对于网络开发比较熟悉。 (2)希望这个插件能够跨平台使用。 (3)希望更加方便地进行集中部署和更新。 (4)这个插件的功能除了Office内部的操作外,还有大量的外部资源访问。 (5)用户能随时访问网络,并且网络条件有保障。 (6)用户对于运行速度的敏感度不是很高,并不是说Web Add-in的运行速度慢,而是因为Web Add-in开发中的很多操作都是异步执行的,所以会造成感觉上运行慢的体验。

VBA是直接运行在Office进程(如Excel)中的,它算是一个脚本,会有主程序动态加载、编译运行。一旦运行结束,就会程放资源。VSTO则更为复杂,因为它是用.NET开发出来的托管代码,所以它本身不能通过宿主程序直接运行,而是需要宿主程序(其实是COM)通过平台调用的方式(Interop)发起一个指令,然后由.NET CLR加载Add-in的组件,这个组件既需要操作Excel的资源,又需要通过平台调用的方式反过来调用COM。而现在的Web Add-in是通过一个独立的浏览器进程(如IE)来运行的。

总体来说,向云迁移是一个必然的趋势,这个过程不仅是一个技术层面的决策,还牵涉到信息架构的规划、工作文化的重塑等,如果真能跨出这一步,或许能帮助企业在互联网时代真正实现转型。

从功能上来说,由于SharePoint Server的更新周期一般是3年,因此,虽然SharePoint Online和SharePoint Server是一个研发团队(其中有很大一部分团队成员就在江苏苏州的研发中心),但都是先做SharePoint Online 上的改进和创新,然后等一段时间,再视情况整合到SharePoint Server中。

微软对于客户的承诺是,将一直保留本地SharePoint Server版本,提供给客户多种选择,经过大量的实践,他们发现尤其对于中大型企业来说,混合架构可能是更好的选择,而这也正是微软Office365平台的一个优势。 有关混合部署及其使用场景,可以参考 https://technet.microsoft.com/zh-cn/library/mt844709(v=office.16).aspx

这个功能最早出现在SharePoint Server 2013中,它是从MySite功能演化过来的,并且借鉴了个人版OneDrive的一些经验。

OneDrive for Business 的成功出乎很多人的意料,但从基于互联网思维的角度来看,这又是必然的。2017年12月,它被正式认定为企业级文件共享和协作解决方案的领导者。

SharePoint Online 不支持服务器场和沙箱解决方案,但仍然支持用户直接在浏览器中定制和"开发"页面(可以写少量的脚本、改样式),以及通过SharePoint Designer进行定制(网页的高级定制、工作流定制等)

SharePoint Add-in开发,允许开发人员独立开发一个Web应用,然后以iframe方式嵌入SharePoint的页面或网站中。

SharePoint Framework开发,允许开发人员使用全新的客户端开发手段,定制Web Part和Extension。这是一个非常大的创新。

如果需要通过编程访问SharePoint的资源,如列表、文档库等,除了继续使SharePoint Online提供的RESTAPI之外,现在也支持Microsoft Graph中直接访问(有限支持)。

一个新的开发框架于2016年开始浮出水面,它叫作SharePoint Framework(SPFx)。产品组之所以会提出这套框架,主要是因为SharePoint本身在不断发展,另外很重要的一点也是来自客户和开发人员的反馈——微软需要有全新的一套框架来重新定义SharePoint的开发。具体而言,希望能用更加原生的Web开发技术来实现,并且与SharePoint有更加自然的融合。

(1)在当前用户的上下文和浏览器的连接中运行。不像SharePoint Add-in一样使用IFrame,也不是将JavaScript直接嵌入页面当中(安全风险较高,也可能由于用户浏览器的设置而失效)。
(2)控件直接在页面DOM中呈现。
(3)控件支持响应式呈现,以适应不同尺寸的界面。
(4)允许开发人员更好地访问生命周期,其中包括呈现、加载、序列化和反序列化、配置更改等。
(5)未指定框架。可以使用喜欢的任何JavaScript 框架,如React、Handlebars、Knockout、Angular 等。
(6)工具链基于npm、ypeScript、Yeoman、webpack和gulp等常见开放源代码客户端开发工具。
(7)提供可靠的性能表现,与SharePoint Add-in相比,有了极大的提升。
(8)最终用户可以在所有网站上使用用户管理员(或其代理)批准的SPFX客户端解决方案,其中包括自助式团队、组或个人网站。
(9)SPFx Web 部件可添加到经典页面和新式页面中,同时支持SharePoint Online和SharePoint Server。

SPFx适合以下两个场景的开发。 (1)客户端Web部件,可以用JavaScript实现所有的界面,并将其应用到任何SharePoint页面中。 (2)扩展程序(Extensions),包括修改页面逻辑的ApplicationCustomizers、为字段提供定制的FieldCustomizers,以及为列表或文档库添加自定义菜单和命令的CommandSets。

由于以往业务应用开发过分依赖专业性技术,带来的问题就是周期长、成本高,而业务用户很多时候都是在干等着,无法及时响应市场和客户的需求;与此同时,因为只有少数人能够从事这类工作,大量业务用户的能力其实是被闲置了,这将导致企业的整体效能下降。业务移动化是一个趋势,但由于多平台都需要单独开发和维护,又进一步加剧了前面两个问题的严重性。

所谓的随需应变,就是让更多的业务人员拥有构建面向主题的业务应用的能力,并且能随时根据捕捉到的信息进行调整,以达到快速响应变化的目标。

Office365平台目前已经内置了很多强大的服务,如大家耳熟能详的邮件服务、在线协作平台、视频会议平台等;同时还针对业务应用提供了创新性服务。例如,PowerApps可以快速根据数据源(最简单的做法是基于SharePoint的列表)构建跨平台移动业务应用,用于收集并处理数据;Microsoft Flow可以在异构系统之间建立业务流程;PowerBI则提出了全新的数据呈现技术,彻底改变了开发人员与数据交互的方式,使开发人员能够洞察先机,然后利用从数据中获得的信息引导用户回到PowerApps中进行操作,或者触发某个Microsoft Flow的流程进行响应。这是一个不断送代的过程,也可以称之为闭环,这也是随需应变最核心的理念。

PowerApps可以根据数据模型快速生成移动优先和云优先的业务应用,这个应用中如果需要实现业务流程,可以通过Flow来解决,而最终产生的大量数据则通过Power BI来展现,或者根据数据的规则发起新的流程或应用操作。它们形成了一个闭环,可以满足不断优化的、随需应变的业务需求。最重要的一个前提是,这一切都是由业务用户自己来做的,无须编程。

(1)基于一个保存在OneDrive for Business个人网盘中的Excel文件创建业务应用。 (2)基于SharePoint Online的列表创建轻业务应用。 (3)基于Dynamics 365创建自定义应用。 (4)将PowerApps应用集成到Microsoft Teams中。

替代InfoPath

网关

微软在企业级领域有Biztalk这样的BPM服务器,也有Workflow Foundation这样的系统层面的工作流能力,在SharePoint Server中内置了Workflow Foundation的支持。

在云平台蓬勃发展的当下,又重新开发和打造了一个全新的流程平台——Microsoft Flow

继承了微软多年的企业级服务的基因,在团队协作、与企业内部应用集成及安全性等方面有自己的特点。

可以做什么

截至目前,Microsoft Flow的移动App还只是测试版,除了微软员工可以使用dog food版本,以及部分国家的App Store可以下载外,中国地区还不能下载。

CDS(Common Data Service,通用数据服务)是一个创新性的基础功能,这是微软试图打造的一个全新的、基于Saas模式的数据服务平台)。一方面是为了整合 Office 365和Dynamics 365的数据(虽然现在还没有做到),另一方面是为了支撑以FowerApps、Microsoft Flow及Power BI为核心的商业应用服务。

CDS最早是作为PowerApps的一部分进行开发的,所以到目前为止,CDS的管理界面都集成在PowerApps中,每个PowerApps的环境可以对应一个CDS数据库,CDS正式GA的时间是2016年10月。

PowerApps是与CDS结合得最好的一个应用,对于PowerApps来说,CDS是一种更好的数据源,在实体之间定义的关系能被自动识别出来,并且生成对应的下拉框。Common Data Service 是PowerApps中一个默认的连接器。

人工智能的核心是算法,基础是数据,表现形式为机器人。几乎可以肯定的是,算法会越来越复杂,属于真正的高科技领域;而应用程序则会越来越简单,以后也许中小学生也能做自己的机器人程序。

实现方案

微软的人工智能总体框架和战略是：智能来自于数据，服务于决策。

Office 365用户使用这些最新版的Office客户端应用程序时,将拥有一个全新的体验——再也不需要记住自己想要的功能在哪个菜单下面,或者在哪个Tab里面,取而代之的是可以在一个固定的位置,用自然语言查找所需的功能。只需按下"Alt+Q"组合键,然后输入想做的情,Office应用程序就能理解用户的想法,并且告诉用户用什么功能来实现。

Web App Bot。这种类型将在Azure中创建一个App Service来运行用户的Bot,并且通过模板和自动化配置极大地简化开发过程。

Bot Channels Registration。这种类型支持用户将Bot应用部署到自己选择的其他位置(可以是用户的数据中心,也可以是其他的云平台),然后通过Azure来做Channel的注册和对接。

Functions Bot。这种类型将在Azure中创建一个Azure Function App来运行Bot,同样也会有模板和自动化配置来简化开发。它与Web App Bot的区别在于,它的计费是按照具体的使用次数,而不是虚拟机的启用时间来算的——事实上,这也正是Azure Function App和Web App 的本质区别。这种形式可能更加符合机器人的特点——它是按需调用的,并不一定要一直在后台运行。