我們家的 User 很喜歡系統發 Mail 通知他們一些事情, 可能這樣會讓他們覺得系統很聰明吧 , 所以, 這段時間 Alert 就寫了一堆 XD

一樣, 也是寫一些簡單的心得 :

- Alert 只能發出純文字的內容, 不能夾檔, 也不能用 HTML 去寫, 所以 Alert 不能跟 Notifications 一樣漂亮

- Alert 的觸發可以分成 Schedule 與 Event, Schedule 就是自己訂時間, 系統就依照 SQL 把串出來的資料寄出. Event 就是利用 DB Trigger 的方式觸發, 不過預設的 DB Trigger 是針對整個 Table, 如果需要針對特定欄位做觸發, 就需要自己手動去 Trigger 加條件. Alert 產生的 DB Trigger 有 Naming Rule, 所以很好分 : ALR_<TABLE_NAME>_<字尾>, 字尾就看你是 After Insert = IAR, After Update = UAR 來決定

- Event 的 Alert SQL 都必須要加上 XXX.ROWID = :ROWID, 這樣才能夠正確判斷出是哪一筆資料觸發了 Event

- 如果要針對同一個 Table 發出兩封不同的 Alert, 好像是因為 Trigger 無法區分, 會造成兩封會有衝突 (有一封會一直有 Error), 在沒找到解法前, 我的做法是 :
    A. 對個別的情況先寫各別的 DB Trigger, 把相關資料寫到 Temp Table
    B. Alert 的 Event 再針對 Temp Table 做監看即可

- 發出的信也可以分成兩種 : Detail 與 Summary, Detail 就是 SQL 串出幾筆, Mail 就寄出幾筆, Summary 就是可以有表頭表身, 那表身像表格, 標題是可以重複的. 我個人比較喜歡把 Event 的 Alert 發成 Detail, 而 Schedule 的 Alert 發成 Summary

- Summary 的表身資料, 每一行的最前面都必須要空兩格, 我也不知道為什麼, 只知道不空的話前兩個字會被截斷

- 每一封 Alert 都要設定 Actions (Mail內容), Action Sets, Alert Details, Alert Details 是比較容易被忘記的, 因為裡面的 Installations 沒有指定 APPS 的 OU 的話, 是不會正常動作的

- 如果內容有純數字資料, 建議去 Alert Details 裡定義最長長度, 這樣格式比較好抓不會亂跑
arrow
arrow
    全站熱搜

    Aloz 發表在 痞客邦 留言(3) 人氣()