這是多組織訪問的第二篇文章,翻譯自Anil Passi的Multi Org R12
我們都知道,在Oracle Release 12中多組織模型(Multi Org)會被改變, 它被叫作多組織訪問控制(Multi Org Access Control, MOAC). 我會告訴你做出這樣改變的原因以及這將會如何的影響到你. 我也會告訴你如何一點也不影響到你現有的設置[如果你不想使用 MOAC- 多組織訪問控制的話]
如果你對EBS R12中的多組織不宵熟悉的話,你可以先看EBS Multi Org 基礎. 那會向你解釋在R12中當前的多組織模型是如何工作的.請參考鏈接瞭解R12中的多組織訪問控制 : Whitepaper on User Group Site
業務上這樣改變的理由
-----------------------------------------
四年前,我被要求設計一個具有以下需求的應付票據(Payables Invoice)掃描程序:
1. 我的客戶有100個以上的法人實體(legal entities)和組織單元(organization units).
2. 他們想在一箇中心的地方收取所有的紙質應付票據. 更有效的, 對所有的法人實體/組織單元,所收到的票據都只有一個地址.
3. 所有的票據都在這個中心地方掃描.
4. 掃描的圖像通過一個隊列被班加羅爾的團隊輸入到系統中
這樣,就出現了些問題:
--------------------------
掃描的票據首先應該根據Operating Uint來排序.
爲什麼呢? 因爲, 對於每一個OU,都有一個不同的 "Payables Clerk" 的職責. 這個可憐的錄入員要根據錄入票據所屬的OU來選擇職責. 而且,你也不能強制的要求供應商以XML的形式來過賬到你的系統中,所以錄入員必須要保證每一張紙製的票據都被錄入到正確的組織機構/OU中.
Oracle EBS Release 12 是如何來拯救他的呢?
在 R12中, 那個錄入員不再是一個"可憐的錄入員", 因爲他不必再根據不同的法人實體來改變職責, 這就是Oracle EBS R12設計的強大之處,它迎合了當今共享服務解決方案的需求.
這是否就意味着應付錄入職責能訪問所有的OU呢?
如果你的業務有這樣的需求,那麼在R12中就能夠做到這樣,你可以把一個組織機構層次中的節點或者是Operating Unit列表賦予你的職責, 或者說,你現在可以給一個職責賦予多個Operating Unit,這可以通過組織機構層次或者組織機構列表.
這聽起來非常像 HR Security Profiles, 我們可以看看鏈接 Oracle HRMS Security Profiles ?
是的,實際上R12中的Multi-org模型就是用的是Security Profiles. 如果你看了上面那個鏈接,你就會對HRMS中的Security Profile有一個更清晰的認識.
這就意味着,一個security profile會作爲一個profile選項附加到職責中?
是的.
如果我不想實現這個增強的功能呢? 這會破壞我現有的多組織(multi org)設置嗎?
Oracle在升級時有她的高明之處. 除非你啓用了Security Profile的特性,否則你的Multi-org將會和R12以前的版本一樣工作.
R12中的多組織訪問控制依然會填充org_Id列嗎?
當然,每一條數據依然和一個單獨的org綁定.
我們能重用爲HRMS定義的security profiles嗎?
我建議你保持Multi-org Security Profile和HRMS Security Profile二者的獨立性, HR Security Profiles 也迎合當今的潮流和不同的HR相關屬性來保持一定的地位,但我們知道這一次Multi-Org將會勝出.
現在我們回去應付錄入中,當錄入一張票據時,他們是如何給每個票據指定一個正確的OU呢?
這是通過在窗口中輸入OU項的值來實現的,在R12之前的版本中這個項是隱藏的,但是現在在所有用到多組織安全配置的窗體中這個值都是可輸入的.
在R12中,用戶會輸入一個附加項嗎?
不完全是,如果你想,你可以根據職責來指定一個默認的OU, 這也是在Profile中實現的.
這個Progile的名字是 [我目前還不知道], 但是它確實存在, 所以我才說了.
所以, 我們會有兩個新的profile選項?
沒錯,一個是用於附加的Surity Profile,另一個用於默認的ORG.
運行dbms_client_info.set_client_info(101)後會發生什麼?
這將成爲一個冗餘的功能,在R12中我們使用包mo_global,這個包在11.5.10中已經存在,而且如果你打開它,你會發現它用的是行級別的安全控制. 從技術上來說我認爲 dbms_client_info.set_client_info 還會繼續工作下去,但是如果你啓用了MultiOrg Security特性後,這將產生無法估計的結果.
這將會如何影響我的客製化?
聲明 1 :- 如果你對client-info進行硬編碼,那很顯然的將不能繼續工作
聲明 2 :- 同樣的, 如果你過去用fnd_profile.org_Id, 那將也不能工作.
如果你決定不在R12中啓用多組織訪問控制(Multi Org Access Control)的話,那麼以上兩個聲明則不成立.