讀書筆記-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 的本質區別。這種形式可能更加符合機器人的特色——它是按需調用的,並不必定要一直在後臺運行。

更多資訊請關注下方微信公衆號：