2016年9月4日 星期日

Create Azure WebJob using C# (使用C#開發 Azure WebJob 執行背景工作)

WebJobs 是一項 Azure App Service 功能,可讓您在與 Web 應用程式、API 應用程式或行動應用程式相同的內容中執行程式或指令碼,舉個簡單例子來說,以往我們要排程一個簡單的exe應用程式,固定一段時間執行一次,或者是每隔10min執行一次,通常的做法會寫一個exe,然後在Windows上直接設定OS的排程去執行此應用程式,或者是在此應用程式中,自己寫Timer去控制執行某段功能的時間,但主要的EXE還是執行在您的機器上,有著諸多的限制。

現在換一個想法,假設我們想要排程的應用程式可以放在雲端上,透過簡單的排程或是自己寫的邏輯,就可以達到這樣的效果,這樣不是很方便嗎? 沒錯Azure WebJob 就是這樣的一個服務,最簡單的方式就是把你的應用程式,例如:exe,包成zip檔,上傳到App Service Web ,然後設定一下就可以了,No Code的設定方式可參考以下Azure官方介紹:https://azure.microsoft.com/zh-tw/documentation/articles/web-sites-create-web-jobs/

但假設透過Azure上的排程器工作集合,免費的排程是有一些條件限制的,假設要比較多的排程功能,可能需要一些費用的產生,排程器工作集合有不同的收費等級。

image

因此如果我們將程式部署上去之前,背景執行的執行相關工作由程式自行控制,那麼也不失是另一種折衷的方式,這時就要使用到 WebJob SDK。以下這段話是微軟官方的介紹:WebJobs SDK 的目的是為了簡化您為 WebJob 可執行的一般工作 (例如影像處理、佇列處理、RSS 彙總、檔案維護及傳送電子郵件) 撰寫的程式碼。WebJobs SDK 具有內建功能,用於處理 Azure 儲存體和服務匯流排、工作排程和處理錯誤,以及許多其他常見案例。此外,它已被設計成可延伸。WebJobs SDK 是開放原始碼,並且有擴充功能的開放原始碼儲存機制

WebJobs SDK 包含下列元件:

  • NuGet 封裝:新增至 Visual Studio 主控台應用程式專案的 NuGet 封裝,會利用 WebJobs SDK 屬性修飾方法,提供一個程式碼使用的架構。

  • 儀表板:Azure App Service 中包含部分的 WebJobs SDK,該部份項目可針對使用 NuGet 封裝的程式提供豐富的監控和診斷功能,無需撰寫程式碼就可以使用這些監視和診斷功能。

當針對WebJob SDK有些概念後,以下亞當斯就來介紹一下使用C#搭配WebJobs SDK開發WebJob的簡易方式和步驟:

1.新增專案時,選取Azure WebJob專案範本:

image

2.當專案建立完成時,在Program.cs中會自動加入JobHost的物件,JobHost 物件是一組背景功能的容器,JobHost 物件可監視功能、注意可觸發功能的事件,以及發生觸發事件時執行功能。

image

3.在Functions.cs中加入以下這段我們想要自行定義的程式碼,宣告方法為非同步工作,並且在方法上加上:NoAutomaticTrigger的Attribute,程式中我們使用While搭配await Task.Delay(TimeSpan.FromSeconds(10))讓每10秒去重複執行一次。

image

4.當寫好我們預計要固定執行的方法之後,要回到Program.cs,針對指定的方法去呼叫,程式碼如下:

var host = new JobHost();                       
host.CallAsync(typeof(Functions).GetMethod("ProcessMethod"));
host.RunAndBlock();

5.最後再測試執行之前,我們要先設定好App.Config中的兩個連線字串,分別為:AzureWebJobsDashboard、AzureWebJobsStorage,將這兩個連線設定,指到雲端上的某一個儲存體即可!

<add name="AzureWebJobsDashboard" connectionString="DefaultEndpointsProtocol=https;AccountName=xxx;AccountKey=xxx />
<add name="AzureWebJobsStorage" connectionString="DefaultEndpointsProtocol=https;AccountName=xxx;AccountKey=xxx />

6. 最後,將專案Compiler,並且直接執行進行測試,可看到執行起來的結果如下,偵測到ProcessMethod方法開始執行,然後根據自訂邏輯每10秒執行一次功能,輸出counter到畫面中。

image

2015年9月4日 星期五

SharePoint 2103 Folder or File Limit Lenght (SharePoint文件庫中檔案或資料夾的長度限制)

在SharePoint 2013的文件庫或是清單中,有一些比較常見的限制,例如:Item : 30,000,000 per list…等等,但是說明中並沒有列出文件庫的資料夾或是檔案的長度限制,而這邊實際測試的結果,當資料夾(包含巢狀式結構)的長度大於260的話,就無法繼續新增下去!

SPFolder

檔案同樣也是,在巢狀式結構中,檔案名稱所對應的路徑假設大於260的話

SPFile

參考資料:

Software boundaries and limits for SharePoint 2013

2015年9月2日 星期三

Office使用RMS發生The operation being requested was not performed because the user has not been authenticated.

當使用Office文件,嘗試使用Word 然後想要去使用RMS執行限制存取,可以在檔案-->資訊-->保護文件—>限制存取—>連線至數位版權管理伺服器

image

但發生了以下的錯誤訊息:The operation being requested was not performed because the user has not been authenticated.

image

解決問題的方式為將此RMS的授權和驗證的WS路徑,加入到瀏覽器的Local Intranet Zone中即可!

image

2015年9月1日 星期二

SharePoint How to avoid restart Application pools when use Update-SPSolution (SharePoint 使用Update-SPSolution時避免啟動Application pools on IIS)

開發好的SP客製化專案(以WebPart為例來說),封裝完成為WSP,在SharePoint部署上去之後,假設需要更新的話,可以使用Update-SPSolution 指令來進行WebPart的更新,指令參考如下:

Update-SPSolution -Identity MyWP.wsp -LiteralPath D:\MyWP.wsp –GACDeployment

但是此時會遇到一個問題,假設我們一開始是把此WebPart部署到SharePoint-80這一個WebApplication,但是當執行Update-SPSolution時,系統並不會只是單純的SharePoint-80單一Web Application Restart,而是會預設將此Server上所有的Application Pool全部進行:停止—>啟用,如下圖所示:

image

原因是因為所有預設開發專案並且封裝WSP時,有一個封裝屬性:ResetWebServerModeOnUpgrade預設值是:StartStop,此時將會影響所有此Server上的Web Application連帶影響其他的應用程式!

那麼該如何來解決執行Update-SPSolution時避免去重新啟動所有的Application Pool呢? 執行步驟如下:

1. 開啟客製化的專案,開啟專案中的Package.Template.xml

image

2. 設定以下三個屬性值:ResetWebServer="FALSE" 、ResetWebServerModeOnUpgrade="Recycle" 、DeploymentServerType="WebFrontEnd",如下圖所示:

image

3. 此時重新打包封裝,並且針對更新後的WSP進行部署!

Update-SPSolution -Identity MyWP.wsp -LiteralPath D:\MyWP.wsp –GACDeployment

此時就可以IIS檢視,可以發現執行Update-SPSolution並不會將Application Pool停止了! Good!

image

 

參考資料:

https://msdn.microsoft.com/en-us/library/ms412929.aspx
http://blog.mastykarz.nl/optimizing-deploying-sharepoint-packages-minimize-impact-farm-availability/

2015年8月13日 星期四

SharePoint 2013 Custom Search MySite Note (在SharePoint中搜尋MySite注意事項)

這兩天在寫客製化Custom Search API,需求是去搜尋MySite的People資料,且Profile資料中有自訂的欄位,不過一直遇到一個問題就是:明明Profile欄位建立,也設定了Search的Metadata,但是結果就是搜尋不到!

因此去查詢Search的編目紀錄檔,發現有一個Warning,點進去一看

咦! MySite不在編目範圍中?? (註:開發環境是朋友建立的,因此一開始並不清楚預先的設定)

image

也就是說,MySite的SiteCollection下目前不在編目範圍中,因此回到MySite的網站設定—>搜尋—>搜尋與離線可用性

image

將"是否允許此網站顯示在搜尋結果中"改設定為:是!!

image

再回到Search重新Craw一次,上述的警示訊息就不見了,且搜尋的項目結果,也抓到了,雖然是一個小小的設定,但是因為是在MySite的網站中,所以大概稍微紀錄一下這次的Issue。

imageimage