2016年5月30日 星期一

[教育訓練] 微軟ALM教育訓練 – VSTS

2016/5/30假恆毅教育訓練中心舉辦的『ALM與DevOps課程』由微軟主辦,集英信誠承辦。

這個課程舉辦了很多次了,每次和學員討論軟體開發流程與DevOps相關的實務議題時,都有不少的新發現與收穫,很是有趣。

2016年5月28日 星期六

關於bot framework (2) - 建立一個最基本的bot(v1舊版)

在瞭解了bot framework的架構之後,我們來看看如何建立一個最基本的bot。

前面提到過,微軟提供了一個簡單但完整的visual studio project template,你可以從底下這邊找到:http://aka.ms/bf-bc-vstemplate 

下載後的檔案是Bot Application.zip,請依照指示複製到 %USERPROFILE%\Documents\Visual Studio 2015\Templates\ProjectTemplates\Visual C#  資料夾底下。

完成之後,你開啟VS2015,會看到:

這表示你可以開發Bot了,但先別急,請先用MS Account登入,到https://dev.botframework.com/bots/new 註冊一個bot

註冊時,你會發現需要填一堆資料,其中要留意endpoint,這個地方要填寫https開頭的WebAPI位置,由於我們還沒有建立好這個WebAPI網站,因此先隨意填寫一個假的即可(但別忘了建立好WebSite之後要回來改):

另外,底下有個Config info那一欄,主要是填寫一個你自己取的bot識別碼,用來識別你的bot,只要是唯一值即可(此欄位未來不得修改):

欄位都填寫完成之後,按下底下的Register,建立一個bot,完成後你會看到底下畫面:

注意上圖中紅框的Details部分,因為Endpoint我們剛才是亂填的(為了先建立一個bot),所以待會把WebAPI寫好,把網站上傳到azure web app之後,要來改這個位置。

還記得我們剛才安裝好了bot template嗎?

回到VS2015,我們利用安裝好的template建立一個專案,建立好之後,找到該專案的Web.Config:

其中的AppId和AppSecret,就是你剛才建立好的Bot的Details畫面上的內容: (app secret要按一下show才看得到唷)

更新好Web.config之後,我們打開範本中的WebApi看一下:

你會發現當有人傳遞訊息給我們的Bot,他會以post的方式傳入MessagesController,我們可以透過Message物件取得,我們把程式碼稍微改一下:

public async Task Post([FromBody]Message message)
{
    if (message.Type == "Message")
    {
        // calculate something for us to return
        int length = (message.Text ?? string.Empty).Length;

        // return our reply to the user
        return message.CreateReplyMessage("你剛才說了..."+ message.Text);
    }
    else
    {
        return HandleSystemMessage(message);
    }
}

 

接著,請把修改好的網站上傳到我們預先建立好的azure web sites(什麼?還沒建立,那先趕快建立一個),完成之後,你就可以回頭去更新Bot的Endpoint這個配置了:

更新好了之後,你可以先在底下做一個簡單的測試:

你會發現輸入『測試』,Bot會回一個JSON,其中的text屬性是"你剛才說了...測試",…這表示你的bot已經可以順利回話了…

還記得我們前面說過嗎? Microsoft bot framework除了可以幫助我們建立bot的對談引擎之外,另一個好處是具有bot connector,這個機制讓我們可以輕易地讓我們寫好的bot串接到各種不同的UI,例如skype、FB、Slack…而最基本的UI,當然是Web介面。

因此我們就立刻看看,如何讓我們的bot可以以Web介面跟用戶對談。

要實現這個功能,請在bot管理畫面上,找到下圖中的Channels,在Web Chat項目上面點選Edit:

之後會看到底下畫面:

請點選 Generate Web Chat secret,接著會出現底下畫面:

如此一來,你就可以透過上圖中的Embed template把你的bot嵌入到你的網頁當中囉。在bot管理主畫面上,你也可以透過Get bot embed codes來取得嵌入碼:

點選後會出現底下畫面,你可以透過embed code與secret組出一個URL,該URL就是你的Bot位置:

當用戶連結到你的Bot, 實際對談的畫面如下:

透過這樣的方式開啟的對談,用戶是匿名的身分。改天,我們再來談裡面的程式碼,以及如何將bot串接到Skype等其他的對談介面上。

2016年5月27日 星期五

關於Skype Bot (1) - 建立

在前幾天的文章中提到過,如何建立一個WebAPI來串接LineBot。

除了Line之外,Skype也是現在在商業上,相當普遍常用的IM與通訊機制,而Skype目前提供的Bot相關API,也比Line來的完整一些,在China目前Skype也大致上通暢沒有被屏蔽。

因此我們接著來看,如何建立一個SkypeBot。概念上差不多,我們依舊需要為其建立一個WebSite(WebAPI),作為接收訊息的管道。建議您先建立一個空的Azure Web SIte,待會申請SkypeBot時我們就會用到。

接著,你必須要用Microsoft Account(像是hotmail, Outlook.com…etc.)在底下網址註冊一個SkypeBot: https://developer.microsoft.com/en-us/skype/bots/manage (意即,該網址必須用Microsoft Account登入)

你會看一個註冊skype bot的畫面:

填寫資料的時候,有一些地方要注意…

  1. 其中填寫Messaging Webhook 這個URL的位置,要放你寫好的WebAPI的位置,由於沒有填寫他不會讓你申請,因此你得先把這個網站的網址準備好(也可以隨便寫一個啦),然後再申請Skypebot。填寫時留意,網址一樣要用https開頭。
  2. Microsoft Application ID這個欄位,要放你建立好的Microsoft Application,什麼是Microsoft Application? 如何建立? 你可以在登入MS Account之後,透過底下這個位置來建立一個Application:
    https://apps.dev.microsoft.com/#/appList
  3. 建立上述的應用程式之後,你會取得一個像是GUID的應用程式識別碼,接著,你必須進一步的產生應用程式密碼(點選下圖中的『產生新密碼』):
  4. 完成後,取得的資料類似:
    2de7ff45-cfed-4fff-b2d2-3fe0d0b6abc1

    cb4kccqGYKqfbVOLYMXe7As
    這就是你待會會在WebAPI網站中會用到的OAuthApplicationId和OAuthApplicationSecret

把相關資料填寫完畢之後,會得到一個SkypeBot,大致上畫面如下:

如果稍加留意,會發現其實SkypeBot的ID就是你剛才提供的MS Application ID。如果不知道其意義也不打緊,反正先把bot搞定。

接著,你可以自行撰寫SkypeBot的接收訊息和回復訊息的程式碼,當然是寫在你剛才建立好的那個WebAPI網站,相關的撰寫方式可以參考這邊:
https://developer.microsoft.com/en-us/skype/bots/docs/tutorials/simple-csharp 

老實說他沒有LineBot那麼好寫,但算是簡單了,如果你懶得照tutorial走一次,你可以從底下網址下載一個.zip檔案(這是tutorial寫好的成品):
https://devportalassets.azureedge.net/files/MessagingQuickStartWebApp.zip
將其解壓縮之後,你會看到這是一個asp.net的webapi網站,請在VS2015中開啟該網站的web.config,把底下的資料替換成剛才我們取得的資料:
<appSettings>
  <add key="Skype.Bots.Messaging.BotId" value="28:填寫你的BotID" />
  <add key="Skype.Bots.Messaging.MessagingServiceBaseUrl" value="https://apis.skype.com" />
  <add key="Skype.Bots.Messaging.OAuthEndpoint" value="https://login.microsoftonline.com/common/oauth2/v2.0/token" />
  <add key="Skype.Bots.Messaging.OAuthApplicationId" value="2de7ff45-cfed-4fff-b2d2-3fe0d0b6abc1" />
  <add key="Skype.Bots.Messaging.OAuthApplicationSecret" value="cb4kccqGYKqfbVOLYMXe7As" />
</appSettings>

請留意,上面的Skype.Bots.Messaging.BotId,是包含 "28:" 這幾個字的。這28是啥意思? 不告訴你,但文件中有寫。

Note: The 28: prefix indicates the user type, in this case it specifies that it is a Bot and not a regular user.

完成該WebSite的Web.config更新之後,我們把該WebSite部署到azure雲端WebApp,然後更新一下我們在SkypeBot中註冊的Messaging Webhook位置:

注意這個位置必須是https開頭(使用azure web app就有這個好處,內建支援https,很讚),你會留意到上面的的 /v1/echo 這個位置,這是我們剛才下載的那個.zip中的範例程式碼WebAPI的位置,也就是說,skypeBot收到的訊息,會傳遞到這個位置上。你可以先看看裡面的code,其中的程式碼,以後再跟大家解釋。

完成設定之後,你可以在你註冊的SkypeBot管理畫面上,找到底下這個URL,用戶可以透過這個URL將你的SkypeBot加入為好友:

當用戶加入該Bot時,會出現底下的畫面,提示用戶Bot會取得用戶的基本資料:

當用戶按下Add to Contacts之後,我們的Bot就跟用戶成為朋友了,這時,會出現底下第一行的訊息,當bot發現用戶跟他做朋友之後,會主動跟用戶說話:

但因為目前我們的Bot只會Echo,所以不管用戶說什麼,他就…Echo回去…

But…Bot就這樣成了。

2016年5月23日 星期一

關於LineBot (1) - 用c#建立一個LineBot

注意,本篇部分內容已過時,新版Line bot申請流程,請參考這篇

前面說過,不知道發生了什麼事情,全球幾個大廠幾乎在同一個時間announce各家的機器人技術或介面,包含Microsoft 的bot API,還有FB、Line…到最近的Google,總之突然間,原本封閉的IM突然都支援建構bot了…這會是巧合嗎? 我猜並不是…

但不管如何,對技術人員來說,如何串接各家的bot,是一個重點。

C#程式設計師要怎麼連結Line最近提供的API呢? 其實很簡單,只有幾個動作,首先,你必須申請LineBot開發帳號,申請的位置在底下這裡:
https://business.line.me/zh-hant/products/4/introduction (已過時)
(更新: 新版的Line Bot叫做 Messaging API ,申請位置位於 https://business.line.me/zh-hant/services/bot)

更新2 : 新版Line bot申請流程,請參考這篇

相關的新聞訊息可以參考這邊:
https://business.line.me/news/3/detail (已過時)

申請的過程不是我們想講的重點,請自行上去申請,申請時建議您申請 Developer Trial:

完成申請之後,在LineBot管理畫面,你會得到底下幾組關鍵的資料,包含Channel ID, Secret, 以及MID (新版的重點應該是Channel Access Token):

有了這些資料你就可以建立一個LineBot來收發line訊息了。你測試的時候,可以先透過上面的QR Code將這個LineBot帳號加為好友,以便於後續的測試。另外,上面有一個CallbackURL,就是接收訊息用的URL。

透過C#該如何開發呢? (btw, 本篇沒用到Microsoft bot framework,雖然都是介紹bot,但和先前介紹的bot framework無關,是剛好順手寫一下這系列)

基本上只需要呼叫Line提供的REST API就可以發送Line訊息,而接收訊息我們只需要建立一個WebAPI即可,如果你想自己K一下document,相關的資料可以參考底下這邊:
https://developers.line.me/bot-api/overview (舊版)
https://developers.line.me/messaging-api/overview (新版請參考這裡)

K完文件,你會發現他已經有Java、Ruby、以及Perl的SDK,真是貼心啊,對,偏偏就是沒有.NET的。

可能官方覺得REST API已經太簡單了,.NET 開發人員應該都能自己搞定才對。這讓人有點不是很愉快,為了簡化我們團隊的開發,我順手寫了一個LineBotSDK放上nuget。在各位沒有更好的選擇前,可以將就點用…

接著,就來看看如何透過C#開發LineBot。
(底下開始是Line V1舊版,V2新版請參考更新後的文章,分別在 這裡這裡)

首先,為了接收訊息,請用ASP.NET建立一個空白的專案,並在其中建立一個chatController:

接著,請在專案中透過unget安裝LineBotSDK套件(選最新穩定版…寫這篇文的時候,應該是0.0.7):
(聲明:這個套件是提供我們開發團隊自己使用的,目前是僅支援發送訊息和取得訊息內容的alpha版本,未來Line應該會(也應該要)提供官方的SDK,因此請自行斟酌使用。)
安裝完成之後,我們先來看看如何發送訊息,其實程式碼只有底下這樣:

      

    //LineBot Helper
    LineBot.LineBotHelper LineBotHelper = new LineBot.LineBotHelper(
            "你的Channel ID", "你的Channel Secret", "你的MID");   

    //發送訊息
    var ret = LineBotHelper.SendMessage(
        new List<string>() { 發送對象ID }, 發送訊息); 
}

我們建立了一個LineBotHelper,提供Channel ID、Channel Secret、MID等訊息,接著就可以透過SendMessage方法發送訊息。

如果你需要LineBotHelper幫你記錄一些log,可以透過提供Application Insights的InstrumentationKey,LineBotHelper會幫你紀錄實際送出的JSON以及LineAPI的Response,像是:

LineBotHelper.AppInsightsInstrumentationKey = "你的InstrumentationKey ";

接著,我們來看如何接收訊息,當有訊息傳遞給我們的LineBot時,LineBot會呼叫你設定的CallbackURL,因此,我們先得先建立這個CallbackURL,先在chatController中,改寫Post Method,撰寫一個接收post訊息用的的method:

      
// POST: api/chat
[HttpPost]
public HttpResponseMessage Post()
{
    LineBot.LineBotHelper LineBotHelper = new LineBot.LineBotHelper(
            "你的Channel ID", "你的Channel Secret", "你的MID");

    //Get  Post RawData
    string postData = Request.Content.ReadAsStringAsync().Result;

    //取得LineBot接收到的訊息
    var ReceivedMessage = LineBotHelper.GetReceivedMessage(postData);

    //發送訊息
    var ret = LineBotHelper.SendMessage(
        new List<string>() { ReceivedMessage.result[0].content.from },
            "你剛才說了 " + ReceivedMessage.result[0].content.text);
            
    //如果給200,LineBot訊息就不會重送
    return Request.CreateResponse(HttpStatusCode.OK, ret);
}

就只有上面這樣。

我們在程式碼中,先透過Request.Content.ReadAsStringAsync().Result取得完整的Post資料,丟給LineBotHelper取得Parsing後的Message,該Message就是用戶送給你的LineBot的訊息,其中ReceivedMessage.result[0].content.from是用戶ID,ReceivedMessage.result[0].content.text是用戶傳送的訊息。

我們接著把一樣的訊息透過SendMessage Echo回去,that’s it。一個簡單的LineBot就這樣成了…

別忘了,要把這個專案部署到internet上的WebSite上,並且把該URL填入你的LineBot的CallbackURL。 (留意CallbackURL必須是 https://…)

就這樣,你的LineBot可以跟客戶說話囉…

2016年5月22日 星期日

關於bot framework (1) - 緣起

微軟在2016年的Build釋出了bot framework,但如果我跟你說,我曾經參與一個團隊,在約莫兩三年前,有一段時間我們主要的工作就是開發自動化訊息對談的Chat Bot,並且試著將相關的語意分析(像是我們後面會提到的LUIS)應用在商業環境中…我猜想你應該也不會覺得有何奇怪,畢竟,Siri早就已經出現很久,而Chat Bot也並非真的是一個很艱深的技術。

但真正有趣的是,2016年,像是大家聯合起來了一樣,FB、Microsoft、Google幾個大廠都針對bot有一些發表,而IM(像是line)也開始迫不及待的紛紛開放對外串接的API,讓我不免開始覺得,是不是大家後面有一些什麼沒有說的計畫?

過去我們在開發bot的時候,最困難的其實是語意分析,這個部份有不少論文在討論,也有open source的資源可以使用。語意分析讓程式可以拆解一段用戶輸入的對話,把對話中的主要文字分段,然後確認名詞、動詞…等詞性,並且分析語句的態度,是問句? 或是祈使句? 或是其他…

這個機制的目的是讓程式可以知道用戶說話(打字)的意思。目前這個機制在整個微軟提供的bot framework解決方案中,是屬於LUIS的功能。

而MS提供的這整個bot framework,則是一個範圍很廣的開發框架(其實嚴格說起來不只是框架了,以LUIS來說,它其實是一個獨立的Web服務),這整套框架和服務,讓Developer可以用比較簡便的方式,建立一個能與終端用戶(end-user)對話的虛擬人物,範疇包括取得用戶輸入的語句訊息、判斷用戶的語意、決定機器人要說的訊息、呈現程式判斷後要輸出的訊息,以及整個開發的程式碼骨架…等等。

使用bot framework的好處在於,開發人員不需要再自行建立自己的對話介面,bot framework提供了一個asp.net的專案範本(其實本質上是一個asp.net WebApi專案),讓你可以輕鬆的開始撰寫訊息對談引擎。

該範本可以從這裡取得,可以參考這邊的使用方式說明:
http://docs.botframework.com/connector/getstarted/#overview

除了訊息對談引擎之外,這個對談機器人(Chat bot)當然還需要一個與用戶對談的操作介面,bot framework選擇的方式,是透過bot connector,讓你可以將前述asp.net專案範本所撰寫出來的對談引擎,串接到各式各樣的終端用戶介面,目前預設支援的包含底下(右邊channels):

簡單的說,你可以透過bot framework中的asp.net專案範本,撰寫出上圖左上角的bot web service,該web service負責處理對談訊息內容的接收與送出,而bot framework架構中的bot connector,負責將你的訊息串接到前端的各種UI。因此,你的bot可以和用戶以Skype、Facebook、Slack…或是其他各式各樣的IM(我想未來會陸續支援)來直接對談。甚至也可以透過Web、簡訊、email內容作為對談的操作介面。

因此,你無須花費心思在處理對談前端UI的開發或串接,這部分bot framework透過connector幫你處理掉了。你可以專注在終端用戶的訊息敲進來之後,你要怎麼判斷用戶的意思(這部分可以透過LUIS來開發),並且把對應的訊息送出去即可。

但真實用戶與bot對談可能會是天南地北的,現階段要透過LUIS來理解所有用戶輸入的訊息,基本上是不可能的,人工智慧尚未發展到可以理解所有人所有訊息的情況(所以你有時候跟Siri對談,還是會覺得在鬼打牆),因此,就商業上來說,使用chat bot搭配LUIS語意分析來達成所有的需求(例如線上客服、購物、填寫請假單…etc),在目前似乎稍微不切實際,畢竟用戶如果突然天馬行空的說一些什麼,bot根本不可能聽懂。

因此,在bot framework中,有另一個機制稱為FormFlow,它和LUIS企圖判斷用戶的語意的做法稍微不同,它縮限用戶可以輸入的文字,聚焦在特定的範圍內,讓用戶只能透過選擇或輸入特定關鍵字的方式與bot對談,藉此達成一些基本的需求,像是前面提到的,填寫單據、基本的troubleshooting、購物…等,就可以在bot上方便的實現。

所以,整個bot framework我們可以切成幾塊來看,分別是:

  1. 開發對談引擎的asp.net WebAPI框架範本
  2. 幫助你串接各種對談UI的Bot Connector
  3. 可以識別用戶語意的LUIS
  4. 提供簡易對談機制的FormFlow

當然,Bot Builder(就是這整個framework)中還有一些特定的功能與SDK,我們如果後面討論到的時候會順便跟大家介紹,後面,我們就來看看怎麼使用上面這些資源,來建立對談機器人。

2016年5月15日 星期日

Azure Remote App (2) - 建立你自己的Collection

對企業來說,穩定的價值遠大於新潮時髦的技術與介面…不幸的是,對升遷來說,就不一定是…

使用RemoteApp這樣的功能,最常見的情境是把自己開發的傳統Desktop應用程式發佈給企業(或外部)的用戶來使用,也有少數的情況是把Office Word/Excel之類的應用程式發佈給特定的用戶使用。

要達成這樣的效果,首先,你必須先建立一個VM。該VM有一些要求,細節你可以參考底下這裡:
https://azure.microsoft.com/zh-tw/documentation/articles/remoteapp-imageoptions/

而最簡單的方式,就是採用既有的範本來建立這個VM,你可以使用底下這兩個範本(重點在於它已經安裝了遠端桌面工作階段主機 (RDSH):

建立好該VM之後,你要先把你想發佈給用戶使用的desktop application安裝上去,幾乎絕大部分的應用程式(只要能裝的上去VM且正常執行),就可以發佈給用戶來使用,需要注意的細節在這裡:

https://azure.microsoft.com/zh-tw/documentation/articles/remoteapp-appreqs/

如果你是安裝透過.NET開發的WPF/Windows應用程式,隨便裝在哪一個目錄下都行,我習慣安裝在根目錄,留意未來當你發佈給用戶使用時,可能會同時有個用戶執行這個程式,因此,與用戶有關的個人資料的儲存,最好不要透過實體硬碟來儲存,可以用.NET中的IsolatedStorage來做儲存相對比較理想。

當你把特定的Windows應用程式安裝在該Azure VM上之後,可以用不同的帳號透過RDP執行看看,如果能正常執行,大致上就沒問題了。

準備好VM之後,我們要把VM變成適合RemoteApp Collection用的Image,你應該會在桌面上看到一個圖示:

執行它,最後按下Y,Enter。這會將這台VM變成適合RemoteApp Collection的Image:

完成Sysprep之後,請把該VM擷取成Image:

擷取完成之後,你的VM會消失,並且在Image下找到:

接著,我們到RemoteApp畫面,把剛才的VM Image變成RemoteApp 範本Image:

將VM Image匯入:

這個匯入動作需要一點時間:

有了範本Image之後,我們就可以開始建立一個新的RemoteApp Collection了:

建立的動作也會需要一點時間:

基本上我是看完一個電影,才建立完的:

建立完成之後,點選進去,即可設定用戶:

接著你可以切換到發行選單中,選擇哪些應用程式可以讓用戶使用:

就這樣,被你選擇的應用程式,可以在iPad/iPhone/Android/Windows/Mac…等環境使用囉…

2016年5月14日 星期六

Azure Remote App (1) - 在iPad/iPhone上執行Windows/WPF應用程式?

主流和非主流,有時候只是時間的差異…

故事是這樣的,2003年開始,我們寫了非常多的Web應用程式,對,那一年是ASP.NET 1.1剛出來的時候。接著,從2005年ASP.NET 2.0出現之後,這種現象完全沒有退燒的趨勢,台灣有一段時間大家卯起來寫Web應用程式,不論是ERP、CRM還是什麼想的出來的企業應用,通通企圖改寫成Web,當時,這絕對是一種潮流…

不過,企業中有太多太多的應用,不可能通通透過Web的方式來實現(一直到現在都是如此…)。因此,還是有很多很小或很大的應用程式,是透過傳統的Windows/WPF方式來開發的。

然後,突然有一天,iPad/iPhone幾乎佔領了台灣高階主管的世界,居於企業核心地位的高階主管們,完全聽不懂(不想聽懂)為何iPad無法執行Windows/WPF應用程式,他心裡的iPad…是無敵的…

詭異的需求,常常就是這樣來的。

所幸高階主管們其實不太key-in,他們擅長做的事,需要用的應用程式,大多都是滑鼠點點點就可以搞定的。

而企業內IT人員的天職就是滿足具有無窮想像力的高階用戶的各種期待…iPad上怎麼運行WPF應用程式呢? 答案當然是,不可能。

就算是也是假的…但假的只要能夠用,也並非不是個辦法…

所以…azure remote app出現了。

原本我覺得這東西有點OOXX,但沒想到經過幾次耐不住客戶要求在iPad上運行傳統windows應用程式的需求之後,實際捲起袖子用了一會兒,發現它也並非難登大雅之堂。畢竟在iPad上能夠看到Windows應用程式(看似)變成一個App,還可以點點點,完成需要執行的工作,其實也還挺不錯的。

Azure Remote App

Azure Remote App是啥呢? 他是Azure中的一個服務,基本上就是一台VM,然後讓iPad(包含iPhone/Android/Windows 7,8, 9 ,10,11或其他設備)透過遠端桌面連線的方式連上,去運行VM上的某一個Application的技術。

一點都不新潮。
但,還真的能用。

如果你下載了最新版在iPad上的RDP遠端桌面連線,會發現新增的選單裡,有一個Azure RemoteApp的選項:

點選該選項之後,你可以用Azure AD組織帳號或Microsoft Account(像是hotmail帳號)登入,如果該帳號具有某個RemoteApp VM(稱作Collection)的存取權限,就會顯示出該Collection上能夠使用的App清單:

上面列出的程式全是傳統的Windows應用程式。當你點選清單中的某一個App,該App就會被運行起來,像是在iPad中被執行的App一般(下圖是一台iPad Mini,其中執行的是Windows的小畫家):

說穿了這沒什麼,就是遠端桌面連線。不過該支援的拖曳、觸控、卷軸、輸入法…etc.一個也沒少,當然,由於是RDP,所以運行起來不會真的跟一個iPad App一樣。

但iPad上能不能運行傳統的Windows應用程式? 這樣…勉強算可以吧。

和一般的RDP不同,透過ipad的遠端桌面連線App配合Azure RemoteApp,用戶端並非直接遙控整個桌面,而是只能運行特定的應用程式。這其實是個優點而非缺點,因為在先前提到的需求和情境下,用戶大多只需要在iPad上運行特定的應用程式,你給他整個桌面,他反而會覺得麻煩,不好控制。

更進一步的說,如果你把Windows/WPF應用程式設計的現代化一點,按鈕大小放大一點,多一點拖曳或觸控功能(WPF要做到這點並不難),那這個App在iPad上運行的效果其實會挺不錯。

就算不想調整已經寫好的windows應用程式,透過這樣的方式讓老掉牙的Windows Application能夠在iPad上直接使用,勉勉強強可以滿足高階主管們的需要,只要不要有太多輸入,其實還算是可以接受。

而iPad只是被支援的一種用戶端,其實用戶可以用Android/Windowws/iOS/MAC/PC等不同的用戶端連上使用,使用方式幾乎都一樣,Microsoft把用戶端作的挺過得去,不至於有太糟的用戶體驗。

應用情境

而這帶給了現代IT/MIS另一種可能性。

其實早在虛擬化技術被廣泛用在企業內的時候,某種terminal時代的影子就又回來了。然後這幾年又開始雲端化,行動化,企業用戶甚至更能接受用一個thin client搭配雲端的虛擬機,來運行企業內的應用系統。這使得Azure RemoteApp這樣的構想不一定不切實際,你留意看看他的road map:

https://azure.microsoft.com/zh-tw/documentation/articles/remoteapp-roadmap/

我很期待有一天,開啟瀏覽器,就能夠透過azure remote app運行企業內各式各樣的(windows)系統,不需要改版、不需要web化,需要大量運算資源的應用系統,也能夠透過一個瀏覽器就可以運行。

所有在Web上不容易做到的工作,都可以透過RemoteApp來完成,而用戶依舊可以透過瀏覽器來執行,透過行動裝置來運行。更有趣的是,如果你擁有多種平台的不同設備(例如MAC/Windows/iOS…etc),都可以執行一樣的應用程式。

例如現在我常常在公司或家裡用Windows透過Azure RemoteApp執行流程簽核系統、在外面乘車的時候,繼續用iPad執行同一個系統,當然,事實上根本就是運行在雲端的VM上,用戶端的裝置只是呈現畫面而已。

安全性

更有趣的是,企業有另一個可能會喜歡這個機制的因素,那就是安全性。

所有應用程式都運行在伺服器端,這表示企業可以中央集權式的管理,沒有什麼需要開VPN或是設備遺失所擔心等用戶端資料外洩的問題,因為東西其實徹頭徹尾在雲端上(或企業內的伺服器),用戶端就是一個RDP而已。如果用戶離職,直接把他的帳號關閉,他什麼資料也留不下來。

Azure Remote App現在可以搭配Azure AD,以企業AD的方式來控管用戶的使用權限,也可以透過microsoft account的方式來管理外部用戶的授權。

未來的發展

坦白說,未來的發展我們無法預測,微軟這兩年的改變讓平台之間的界線越來越模糊,如今你可以在windows上面Run Bash,可以用Visual Studio寫Android,可以在微軟的雲端CI系統中Build各式各樣的應用程式,現在在iOS上面看到WPF應用程式,其實也沒什麼…

我不知道在這個『看似』Web和App已經主導開發了的時代,還有多少企業在寫WPF或Windows應用程式,但如果你想要在iPad/iPhone上面運行WPF,Azure RemoteApp算是一個可以撐著用的選擇。

我自己有在用嗎? 有的,而且我也開給不少客戶使用。令人訝異的是,只有一兩位客戶問我,為什麼這個iPad App的操作畫面長的跟Windows好像…

(下一篇,我們再介紹怎麼搭建你自己的Azure RemoteApp)