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

作者博客

Office 365 开发概览系列 - 随笔分类 - 陈希章 - 博客园  https://www.cnblogs.com/chenxizhang/category/967796.html

第一章 概述

Office365的服务端整合

在有Office 365之前,我们有着广受欢迎的Office客户端套件,以及功能强大的Office服务器产品群(包括Exchanqe Server、SharePoint Server和Lync Server等)。我们将一个分散的多服务器上部署的，以及以PC为主的产品，有机的组合到一起，在一个强大的共享云平台上实现，通过世界各地高速及强大的数据中心，研发出了世界领先的云生产力Office 365智能服务及平台。

Office 365的客户端整合

Office 365的世界观是赋能于员工,打造更智能的生产力,而对应的方法论就是把针对性的办公模块(如办公"三剑客"——Word、Excel、PowerPoint)、内容管理SharePoint、远程沟通Skype for Business、网盘OneDrive、企业邮件Outlook及团队管理Teams等进行有机整合。Office365是人类历史上很好地体现整体性的一款Saas应用。

Openxml技术在Office客户端的首次使用

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

为何会推出VSTO工具

为什么会推出VSTO这套工具呢?我认为一方面是由于Visual Studio 及.NET自身发展的需要,另一方面是由于Office及开发人员的需要。VBA很好,但它的局限性也比较明显——它主要适合做应用程序内部的自动化,并不适用于与外界系统或网络资源"打交道",同时对于新版Office的一些特殊功能(如Ribbon或Task Pane等)也缺乏支持。

Office 365的四种开发场景

（1）Microsoft Graph

通过Microsoft Graph,可以让用户的自定义应用系统(无论是Web应用、桌面应用,还是移动App)通过统一的、RESTful的接口访问授权用户的Office 365资源。展开一点来说,一方面,用户的应用可以使用Office 365提供的ldentity服务,简化和统一身份验证环节;另一方面,用户能直接将Office 365的功能无缝集成到自己的应用中去,免费享受到微软强大的基础投资带来的好处。

（2）Office Add-ins

Add-ins对于Office开发人员来说并不是新事物。前面已经提到了VBA可以做Add-in(通常是通用的功能,与具体的文档无关,并且需要保存为特殊格式,如.xlam或.xla,称为Excel Add-in),VSTO也可以做Add-in(称为COM Add-in)。暂且将这两种Add-in称为传统的Add-in。它们需要在本地安装和部署。

Office365的Add-in指的是基于新一代的Web技术推出的Add-in开发能力,可以将它们称为Web Add-in。那么为什么会推出Web Add-in这种新的开发模式呢?其原因主要有以下两个方面。

第一,Web Add-in采用了集中部署的策略,开发人员可以在一个统一的位置维护其代码并进行更新,用户也可以实现一次订购多处运行,不需要在不同的设备上对其——进行安装。

第二，,我们希望在移动设备上也能使用这些Add-in,不必为移动设备再单独做一次开发。

（3）SharePoint Add-ins

之所以单独讲解SharePoint的Add-ins,是因为它区别于Office Add-ins,指的是服务器端开发,二者在开发模式及要求的能力方面不太一样。但在我看来,SharePoint的开发人员向Office365转型会比传统Office开发人员容易。原因在于,SharePoint的开发虽然也经历过不同的历史阶段(如从最早的WSP到后来的Farm Solution,再到Sandbox Solution,再到SharePoint 2013横空出世推出了App的模型),但其核心还是Web开发,所以有这种经验和基础的开发人员,在如今"云优先、移动优先"的大背景下有着先天的优势,更何况新的Add-in开发模式进一步标准化了,从逻辑上来说可能会更加容易。

（4）Office 365 Connectors

Connector(连接器)是一个全新的事物。目前在Outlook Modern Groups及最新平台发布的Microsoft Teams中起着连接外部应用系统或信息源的作用。

VSTS的免费版本

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

VSTS的开源版本

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

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

第二章 Microsoft Graph开发

Microsoft Graph

Microsoft Graph是一套RESTful的接口,它的所有接口都可以通过标准的http方法(GET、POST、PUT、DELETE)直接访问,而且还可以通过改变URL的参数来进行筛选、排序及分页等操作,它返回的数据是标准的JSON格式。这种特性决定了Microsoft Graph是跨开发平台的。目前官方提供的CodeSample和SDK有10种,但实际上,任何能发起http请求并能解析JSON数据的开发平台和语言都能调用Microsoft Graph。

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

我们将纯粹面向工作或学校账号的Azure AD 服务端点称为Azure AD 1.0(或称为Azure AD);而将既支持个人账号,也支持企业或学校账号的Azure AD 服务端点称为Azure AD 2.0。那么开发人员的应用程序需要访问哪些Microsoft Graph资源才能得到认证呢?答案是:在Azure AD中对应用程序进行注册,并且申请权限。

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

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

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

Azure AD2.0将会逐渐成为主流

它有以下几个优势。

(1)Azure AD2.0应用程序既支持访问工作或学习账号,也支持访问个人账号。

(2)注册Azure AD2.0应用程序不需要访问目标用户的AzureAD,是在一个独立的平台注册的。也就是说,这种应用程序是Multi Tenant模式的,有更高的复用性。

(3)Azure AD2.0应用程序的权限是动态申请的,有利于应用程序升级,并且能够简化部署和管理。

(4)微软为Azure AD 2.0应用程序提供了更高级的开发工具支持,在大部分开发平台都提供了SDK。

中国版Office 365

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

桌面应用程序

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

Oauth认证

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 Add-in开发概述

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

总的来说,Office Add-in的开发有以下3个特点。

(1)面向Office 365的订阅用户,也面向Office 2013或Office 2016的本地用户。但后者可能在某些细节功能上略有差异。

(2)Office Add-in的开发采用了全新的技术架构(Web Add-in,后面会专门介绍),其主要目的在于实现"一次编写,处处运行"。

(3)Office Add-in拥有一个成熟的生态环境,有庞大的用户群体(据不完全统计,地球上1/7的人在使用Office),既有Office Store,也有配套的技术社区。

Web Add-in技术架构

相较之前的VBA(Visual Basic for Application)和VSTO(Visual Studio Tools for Office)开发,我们将这一代的Office Add-in开发技术称为"Web Add-in",顾名思义,就是使用最普遍的Web技术来进行Office Add-in的开发。这一方面降低了技术的门槛,因为如果开发者已经有了Web的开发经验,就很容易上手,无须特别学习;但另一方面也拾高了技术的门槛,对于一些早期的Office 插件开发者来说,这是一个不太熟悉的领域,要学的新东西太多,可能会增加他们的转换成本。无论如何,WebAdd-in是一个有益的补充(使用它并不意味着要抛弃此前的VBA和VSTO),也是跨平台和移动化的需要。

从技术的角度来看,Web Add-in确实与早期有较大差异。Web Add-in是由两个部分组成的,首先是用来声明Add-in的Manifest文件,这是一个标准的XML文件;其次是一个标准的Web应用程序,所有的功能都是在Web应用程序中实现的,对于具体用什么技术来实现没有要求,其核心是调用Office.js这个脚本文件完成与Office应用程序的交互。采用这种结构,有利于开发和部署的分离。通常来说,开发好的Web应用可以部署到任何地方,而给Offce管理员或用户的只是Manifest文件。

如果要谈Web Add-in的技术架构,需要做到以下几点。

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

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

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

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

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

Office Add-in能做什么

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

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

还有一些技术细节,有兴趣的读者可以了解一下。

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

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

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

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

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

TypeScript

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

VBA

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

学习VBA的一个最好的起点就是录制宏。就本案例而言,即使是VBA的初学者,也可以尝试一步步地输入数据并生成图表。

VSTO

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

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

Web Add-in

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的账号,就可以免费使用这个插件。

详解Office Add-in清单文件

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

其实是一个标准的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。

Office Web Add-in 的适用场景

很多人不了解Office Web Add-in的适用场景,前面详细对照了三种为Office开发Add-in的技术和表现形式,这里再总结一下新的Web Add-in的适用场景。

(1)开发人员本身对于网络开发比较熟悉。

(2)希望这个插件能够跨平台使用。

(3)希望更加方便地进行集中部署和更新。

(4)这个插件的功能除了Office内部的操作外,还有大量的外部资源访问。

(5)用户能随时访问网络,并且网络条件有保障。

(6)用户对于运行速度的敏感度不是很高,并不是说Web Add-in的运行速度慢,而是因为Web Add-in开发中的很多操作都是异步执行的,所以会造成感觉上运行慢的体验。

Office Web Add-in 的工作原理是什么

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

第四章 SharePoint Online开发

向云迁移

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

混合部署

从功能上来说,由于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

OneDrive for Business

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

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

开发模式的变化

最后来谈一下SharePoint所支持的开发模式方面的变化,尤其是在SharePoint Online部分。

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

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

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

另外,如果需要通过编程访问SharePoint的资源,如列表、文档库等,除了继续使SharePoint

Online提供的RESTAPI之外,现在也支持Microsoft Graph中直接访问(有限支持)。

SPFx

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

值得高兴的是,SharePoint Framework框架也基本实现了上面的承诺。

SharePoint Framework的主要特性

(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。

SharePoint Framework 能做什么

目前来说,SPFx适合以下两个场景的开发。

(1)客户端Web部件,可以用JavaScript实现所有的界面,并将其应用到任何SharePoint页面中。

(2)扩展程序(Extensions),包括修改页面逻辑的ApplicationCustomizers、为字段提供定制的FieldCustomizers,以及为列表或文档库添加自定义菜单和命令的CommandSets。

第五章 随需应变

业务移动化的挑战

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

微软随需应变的核心理念

作为业务主干应用系统这一层,大部分企业都已经建设完毕,这些都是比较标准也比较复杂的系统。今天要谈论的业务应用,更多的是偏向前台创新应用和差异化应用。而所谓的随需应变,就是让更多的业务人员拥有构建面向主题的业务应用的能力,并且能随时根据捕捉到的信息进行调整,以达到快速响应变化的目标。

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

PowerApps

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

(1)基于一个保存在OneDrive for Business个人网盘中的Excel文件创建业务应用。

(2)基于SharePoint Online的列表创建轻业务应用。

(3)基于Dynamics 365创建自定义应用。

(4)将PowerApps应用集成到Microsoft Teams中。

替代InfoPath

Infopath也有它自身的问题,而且对于SharePoint的版本有所依赖。进入SharePoint Online时代后,就已经不再使用Intopath了,但直到现在才揭院了它的替代方案，那就是PowerApps。

使用网关

PowerApps默认支持上百种数据源,尤其是对云端的Saas应用有极好的支持。但是,假设用户的数据不在支持列表中,或者数据在公司内部的服务器中,能否一样享受到PowerApps带来的好处呢?答案是肯定的,PowerApps通过一个网关(Gateway)技术,可以在用户授权的情况下安全地连接到用户私有的数据。

Microsoft Flow

微软在企业级领域有Biztalk这样的BPM服务器,也有Workflow Foundation这样的系统层面的工作流能力,在SharePoint Server中内置了Workflow Foundation的支持。与此同时,在云平台蓬勃发展的当下,又重新开发和打造了一个全新的流程平台——Microsoft Flow。它既有类似于IFTTT的强大和灵 活架构,也继承了微软多年的企业级服务的基因,在团队协作、与企业内部应用集成及安全性等方面有自己的特点。

Microsoft Flow可以做什么

(1)通过Microsoft Flow实现将特定邮件的附件自动保存到SharePoint Online 文档库中。

(2)实现周期性执行的流程。

(3)实现用户手工启动的流程。

(4)在PowerApps中操作引发的流程。

(5)通过PowerBI警报引发的流程。

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

Common Data Service(CDS)

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中一个默认的连接器。

第六章 展望

人工智能与算法

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

微软将通过以下两个方面来实现这一目标。

(1)将AI带给每一个开发人员——使用微软认知服务,开发人员可以构建识别手势、用多种语言翻译文本、解构视频以实现更快地搜索、编辑实时字幕,甚至定制数据以识别类别中的图像。

(2)用AI重新定义微软——将AI注入我们所提供的每一个产品和服务中,从Xbox到Windows,从Bing到Office。

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

Tell me

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

Microsoft Bot Framework

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

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

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

更多资讯请关注下方微信公众号：