作者部落格

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 的本質區別。這種形式可能更加符合機器人的特點——它是按需呼叫的,並不一定要一直在後臺執行。

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