2010-01-19 43 views
2

當某些日期發生或滿足某些業務條件時,我們需要能夠發送自動電子郵件。我們正在建立這個系統來處理現有的ASP.NET網站。我和其中一位開發者聊了一下,並討論了一些問題。在ASP.NET中執行批量處理頁面

注意事項:

  • 所有我們需要的信息在ASP.NET網站已經建模
  • 有所需的郵件生成這也是該網站的一些業務邏輯已經

我們認爲理想的解決方案是安排一個單獨的可執行文件,該文件計劃在夜間運行並執行處理和電子郵件。該解決方案有兩個主要問題:

  • 如果網站被更新(業務邏輯或模式),但可執行文件意外丟失,則可執行文件可以停止發送電子郵件,或者更糟的是,基於過時的邏輯將送給他們。
  • 我們希望使用類似this使用用戶控件到模板中的電子郵件,我不相信這是可能的ASP.NET網站

的第一個問題之外本來可以避免與構建和部署腳本(我們現在正在研究),但我認爲我們不能解決第二個問題。

因此,我們決定的解決方案是有一個由SSIS定期調用的ASP.NET頁面,並執行一定數量的處理(例如30秒)然後返回。我知道ASP.NET頁面並不是進行這種處理的理想場所,但這似乎最符合我們的要求。我們考慮產生一個新的線程(不是來自工作者池)進行處理,但決定如果我們這樣做了,我們就不能使用返回的頁面來表示成功或失敗。通過在頁面的生命週期內處理,我們可以使用頁面內容來指示處理過程如何進行。

所以問題是: 這個設置有什麼技術問題嗎?

很顯然,如果您嘗試過這樣的事情,任何成功/失敗的報告將不勝感激。同樣可以提出其他建議。

乾杯,

回答

3

不要使用asp.net線程來做到這一點。如果網站正在生成您需要的一些信息以創建或觸發電子郵件發送,那麼網站會將一些信息寫入文件或數據庫。

創建一個Windows服務或計劃進程,它從該文件或數據庫收集所需信息,並在完全獨立的進程/線程上運行電子郵件發送進程。

您想避免的是由於流程處理程序中的限制導致您的站點崩潰或電子郵件崩潰。根據您在問題標題中使用「bulk」這個詞,兩者需要彼此獨立。

0

聽起來像你應該創建一個工作線程來完成這項工作。

+0

爲什麼您認爲在單獨的線程中處理會比在頁面生命週期中處理更好?從我的閱讀中,只要應用程序在IIS應用程序池中循環使用,您創建的任何線程都會死亡。所以通過將它保持在頁面生命週期中,我們希望避免這種情況發生。 – David

0
+0

我相信,如果AppPool被回收(處於非活動狀態,或者服務器重新啓動),這種類型的系統將停止工作。所以如果你想確保它始終在運行,你需要有一個外部定時系統從你的網站請求一個頁面。在這種情況下,你可能會有外部計時器直接觸發動作(少一件事就會出錯)。 (http://www.codeproject.com/KB/aspnet/ASPNETService.aspx)建議您在第三方可用性檢查器上註冊您的站點以確保頻繁的請求。但我認爲這是一個可怕的解決方案。 – David

2

我認爲你應該沒問題。我們在公司使用類似的方法好幾年,並沒有遇到很多問題。有時需要一個多小時才能完成該過程。最近我們將第二個線程(如你所說)移動到一個單獨的服務器上。

1

把電子郵件和網站耦合在一起可以工作,但它不是一個很好的設計,並且從長遠來看將會爲您提供更多的維護。你可以通過做一些事情來解決你所說的問題。

  1. 將通用業務邏輯移至Web服務或通用庫。您的網站和可執行文件/ WCF服務都可以使用它,並集中了邏輯。如果您正在複製和粘貼代碼,則知道存在問題;)

  2. 如果您需要模板郵件程序,可以調用ASP.Net類爲您動態創建頁面(請參閱BuildManager類,以及blog posts like this one。如果郵件程序不依賴於頁面事件(它似乎沒有),那麼你的可執行文件不應該有任何問題從你的網站程序集加載一個Page類,動態構建它,並填寫內容

這顯然代表工作顯著量,但會導致一個更靈活的解決方案適合你。

0

當某些業務條件滿足時,您可以並且應該在域邏輯(它意味着您的asp.net應用程序)中構建消息正文(模板化消息正文),並將其發送給只應發送消息的外部服務。所有消息都會有適當的信息。

對於「當某些日期出現」情況下,你可以使用後臺任務簡單的解決方案(看克雷格答案),做與上面相同:解析模板,建立信息和快速發送到指定的服務。

當然,你應該這樣做安全,然後應用程序池重新啓動不會破壞你的任務。