| Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド リリース7.9.4 E06112-01 |
|
 戻る |
 次へ |
この章では、Oracle Business Intelligence Applicationsのセキュリティ機能について説明します。この章の内容は次のとおりです。
Oracle Business Intelligence Applicationsでは、業務系ソース・システムのセキュリティ・モデルとの強力な統合により、適切なユーザーに適切なコンテンツを表示できるようになります。Oracle BI Applicationsには多くのセキュリティ・オプションが用意されており、管理者はこれらのセキュリティ・オプションを利用して、重要なビジネス・データを適切なユーザーに対して認証し、表示できます。
Oracle BI Applicationsのセキュリティは、大きく次の3つのカテゴリーに分類できます。
ユーザー・セキュリティ（ユーザーの認証）
オブジェクト・セキュリティ
データ・セキュリティ
ユーザー・セキュリティでは、提供された資格証明に基づいてユーザーのIDが認証および確認されます。オブジェクト・セキュリティでは、ユーザーのロールに基づいて、ビジネス論理オブジェクト（メタデータ・リポジトリに定義されたサブジェクトエリア、プレゼンテーションテーブルなど）およびWebオブジェクト（Presentation Catalogに定義されたDashboard、Answersなど）の表示が制御されます。ユーザー・ロールの例には、金融アナリストなどがあります。データ・セキュリティでは、OLTPシステム内のデータに対するユーザーの対応付けに基づいて、データ（サブジェクトエリア、Dashboards、Answersにレンダリングされるコンテンツ）の表示が制御されます。例として、ビジネス単位ベースのセキュリティがあります。
データ・セキュリティとオブジェクト・セキュリティは、セキュリティ・グループを使用してOracle BI Applicationsに実装されます。これらのセキュリティ・グループは、Oracle Business Intelligence Administration Toolのセキュリティ・マネージャを使用して定義されます（メニュー: Manage」→「Security」）。Oracle BI Applicationsのセキュリティ・グループとユーザーの標準的な構造は、次の図に示すように、データ・セキュリティ・グループ、オブジェクト・セキュリティ・グループ、ユーザーの順に階層になります。
セキュリティ・グループとユーザー間のワイヤリングの詳細は様々で、実際の実装に応じて決定する必要があります。
Oracle BI Applicationsでは、ユーザーのOracle Business Intelligenceのセキュリティ・プロファイルと、ソース・アプリケーションのセキュリティ・プロファイルとの整合性が調整されます。この調整は、次のいずれかの方法によって実行されます。
Oracle Business Intelligenceアプリケーション・リポジトリに、ソース・アプリケーション内の既存の職責またはグループと同じ名前のセキュリティ・グループを作成します。これらのセキュリティ・グループは、Oracle Business Intelligence固有のセキュリティ・グループ（役割ベースまたは組織ベースのセキュリティ）にメンバーとして追加され、ユーザーは、OLTPアプリケーション内の各自の職責またはロールに基づいてこのメンバーシップを継承します。
ソース・アプリケーションに、新しいOracle Business Intelligence固有の職責（Oracle EBSおよびSiebel CRM Applications）またはロール（PeopleSoftアプリケーション）を追加します。このとき、これらの名前がOracle BI Applicationsのオブジェクト・セキュリティ・グループと一致するようにし、これらの新しいグループにOLTPユーザーを割り当てます。ユーザーは、最初のシナリオで説明した同じ方法でセキュリティ・グループのメンバーシップを継承します。
注意: セキュリティのメカニズムが機能するように、ユーザーは常に、Oracle Business Intelligenceリポジトリではなく、基幹業務アプリケーション・データベースまたはLDAPなどのディレクトリ・サービスに作成する必要があります。ユーザーをRPDに作成すると、セキュリティ・メカニズムは機能しません。Oracle E-Business SuiteおよびPeopleSoftアプリケーションとの統合の詳細は、第7.2項「Oracle E-Business Suiteとのデータ・セキュリティの統合」および第7.3項「Oracle PeopleSoft Enterprise Applicationsとのデータ・セキュリティの統合」を参照してください。
管理者がユーザーの職責を確認する方法は2通りあります。
SiebelまたはOracle E-Business Suiteの基幹業務アプリケーションで、「Responsibilities」ビューに進みます。
PeopleSoftアプリケーションで「Roles」ビューに進み、ユーザーのロールを確認します。
Oracle Business Intelligenceアプリケーションで、「設定/個人情報」リンクをクリックします。ユーザーのPresentation Servicesグループのメンバーシップが、Webページの下部に表示されます。これらはPresentation Servicesカタログにのみ定義されているPresentation Servicesグループで、通常は操作を実行する権限の制御に使用されます。Presentation Servicesグループの名前がOracle BI Serverセキュリティ・グループと同じで、ユーザーがOracle BI Serverセキュリティ・グループのメンバーである場合、このユーザーは自動的に対応するPresentationグループのメンバーになります。
Oracle BI Webでユーザーに新しい職責を追加した場合、この変更はOracle BI環境にすぐには反映されません。新しいユーザー職責を登録するには、管理者とユーザーの両方が次のタスクを実行する必要があります。
Oracle BI Administratorで、Oracle BI Presentation Servicesを介してOracle BI Serverメタデータを再ロードする必要があります。
次に、Oracle Business Intelligenceアプリケーションから、または埋込みアプリケーションを使用してOracle Business Intelligenceのダッシュボードを表示している場合はSiebelまたはOracle E-Business Suite基幹業務アプリケーションからログアウトして、再度ログインする必要があります。
ユーザーAdministratorおよびグループAdministratorsはそれぞれ特殊なユーザーおよびグループで、いずれの制限も適用されることはなく、SiebelまたはOracle E-Business Suiteデータベースを使用することはありません。ユーザーSADMIN（パスワードSADMIN）も特殊なユーザーで、Administratorに似ています。
Administratorグループは、スーパーグループAdministratorsのメンバーとして設定されるため、このグループのメンバーに制限はありません。
注意: 本稼働に移行する前に、デフォルトのパスワードを変更してください。
Administratorグループは、スーパーグループAdministratorsのメンバーとして設定されるため、このグループのメンバーに制限はありません。
この項では、Oracle BI ApplicationsのセキュリティをOracle E-Business Suite（EBS）に実装する方法について説明します。必要に応じてセキュリティの実装方法を変更できるよう、セキュリティのデフォルトの構成を理解しておく必要がある場合は、この項をお読みください。この項の内容は次のとおりです。
Oracle BI Applicationsの認可プロセスでは、ソースのOracle EBSアプリケーションからユーザーの職責がフェッチされ、すべてのOracle BI Applicationsセキュリティ・グループと照合されて、ユーザーのセッション時にユーザーの該当するオブジェクト・セキュリティが決定されます。初期化ブロック"Authorization"を使用してロールがフェッチされ、結果セットが特別なセッション変数GROUPに割り当てられます。初期化ブロックのSQLは次のとおりです。
SELECT DISTINCT 'GROUP', RESPONSIBILITY_NAME FROM
FND_USER ,FND_USER_RESP_GROUPS, FND_RESPONSIBILITY_VL
WHERE
FND_USER.user_id=FND_USER_RESP_GROUPS.user_id
AND FND_USER_RESP_GROUPS.RESPONSIBILITY_ID = FND_RESPONSIBILITY_VL.RESPONSIBILITY_ID
AND FND_USER_RESP_GROUPS.RESPONSIBILITY_APPLICATION_ID = FND_RESPONSIBILITY_VL.APPLICATION_ID AND
FND_USER_RESP_GROUPS.START_DATE < SYSDATE AND
(CASE WHEN FND_USER_RESP_GROUPS.END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(FND_USER_RESP_GROUPS.end_Date) END) >= SYSDATE
AND FND_USER.user_id = = (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER')
このリリースのOracle BI Applicationsでは、Oracle EBSとの次のデータ・セキュリティの統合がサポートされています。
Oracle EBSに対する営業単位ベースのセキュリティ（詳細は、第7.2.2項「Oracle EBSの営業単位ベースのセキュリティ」を参照）。
Oracle EBSに対する在庫組織ベースのセキュリティ（詳細は、第7.2.3項「Oracle EBSの在庫組織ベースのセキュリティ」を参照）。
Oracle EBSに対する会社組織ベースのセキュリティ（詳細は、第7.2.4項「Oracle EBSの会社組織ベースのセキュリティ」を参照）。
元帳ベースのセキュリティ（詳細は、第7.2.4項「Oracle EBSの会社組織ベースのセキュリティ」を参照）。
Oracle EBSに対するビジネス・グループ組織ベースのセキュリティ（詳細は、第7.2.6項「Oracle EBSのビジネス・グループ組織ベースのセキュリティ」を参照）。
Oracle EBS - HRMSアプリケーションに対するプライマリ従業員/役割階層ベースのセキュリティ（詳細は、第7.5.1項「プライマリ役割ベースのセキュリティ」を参照）。
Oracle BI Applicationsリリース7.9.4では、EBSに対する総勘定元帳フレックス・フィールドやHRセキュリティ・プロファイルベースのセキュリティはサポートされていません。
この項では、Oracle EBSの営業単位ベースのセキュリティについて説明します。
営業単位のセキュリティは、セキュリティ・プロファイルをユーザーのIDまたは職責に関連付けることによって確保されます。つまりセキュリティ・プロファイルは、ユーザーのIDまたは職責にアクセスできる組織階層に関連付けられます（次の図を参照）。ユーザーのIDまたは職責は、システム管理者の職責を使用して定義されます。セキュリティ・プロファイルおよび組織階層は、HRMS管理者の職責を使用して定義されます。
営業単位の次元は、ユーザー/職責/アプリケーション/サイトの各レベルに設定されているプロファイルを（順番どおりに）確認することで決定されます。つまり、ユーザー・レベルおよびサイト・レベルでプロファイルに値が設定されている場合は、ユーザー・レベルで設定されている値が優先されます。
使用されるプロファイルは次のとおりです。
MO: セキュリティ・プロファイル
割り当てられるセキュリティ・プロファイルに応じて、そのセキュリティ・プロファイルに関連付けられている営業単位がユーザーからアクセス可能になります。
MO: 営業単位
(1)がNULLに設定されている（4つのいずれのレベルも設定されていない）場合、プロファイル「MO: 営業単位」が使用されます（1つの「MO: 営業単位」は1つの営業単位にのみ割り当てることができますが、「MO: セキュリティ・プロファイル」にはセキュリティ・プロファイルが含まれるため、複数の営業単位に割り当てることができます）。
営業単位の次元は基本的にユーザー保護の次元であり、次の機能があります。
レポートにアクセスするユーザーのコンテキストを確認します。
ユーザーがアクセスできる営業単位を決定します。
コンテンツを表示します。
Oracle EBS R12以降、営業単位が1つの職責のみに固定されることはなくなりました。ユーザーは引き続き「購買, Visionオペレーション（USA）」としてログインし、「Visionドイツ」の購入オーダーを作成できます。これは、営業単位が購入オーダー画面に値リストとして表示されるようになり、表示される値リストの値が2つのプロファイルに応じて変わるためです。
この項では、Oracle EBSの営業単位ベースのセキュリティについて説明します。
Oracle EBSの営業単位ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
"EBS Single Sign-on Integration"初期化ブロックで、次のEBSシングル・サインオン統合セッション変数が初期化されます。
EBS_SSO_INTEGRATION_MODE
このセッション変数は2つの指定可能な値IntegratedまたはNot Integratedで初期化され、Oracle BI ApplicationsをEBS SSOと統合するかどうかが示されます。
"EBS Security Context"初期化ブロックで次のセッション変数がポピュレートされます。
OLTP_EBS_RESP_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はOracle EBSのユーザーのセッションの職責で初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
OLTP_EBS_RESP_APPL_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はEBSのユーザー・セッションの職責アプリケーションで初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
Oracle Business Intelligence Serverで、FND_USER_RESP_GROUPSからUSERに対応する帳簿セットが取得されます。次のセッション変数が自動的に設定されます。
OU_ORG（行方向の変数）
次に示すように、初期化ブロック"Operating Unit Org"によってこの変数に値が設定されます。
初期化ブロック -- "Operating Unit Org"
次のSQLを使用して、初期化ブロック"Operating Unit Org"によって変数OU_ORGに値が設定されます。
SELECT DISTINCT 'OU_ORG', TO_CHAR(PER_ORGANIZATION_LIST.ORGANIZATION_ID)
FROM PER_ORGANIZATION_LIST,
(SELECT FND_PROFILE.VALUE_SPECIFIC('XLA_MO_SECURITY_PROFILE_LEVEL', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID) PROFILE_ID
FROM (SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID
FROM FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE
AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE
AND USER_ID = (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER')
AND RESPONSIBILITY_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN
VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END)))
WHERE PER_ORGANIZATION_LIST.SECURITY_PROFILE_ID = PROFILE_ID
UNION
SELECT DISTINCT 'OU_ORG', FND_PROFILE.VALUE_SPECIFIC('ORG_ID', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID) ORGANIZATION_ID
FROM (SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID
FROM FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE
AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE
AND USER_ID = (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER')
AND RESPONSIBILITY_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END))
この項では、Oracle EBSの在庫組織ベースのセキュリティについて説明します。
理論上、在庫組織のセキュリティは、現在のユーザーではなく現在ログインしている職責に基づいて適用されます。
ただしEBSでは、在庫組織V1が職責R1とR2に関連付けられている場合、V1にはこれら2つの職責からしかアクセスできません。画面で職責が定義されていない別の在庫組織V2には、すべての職責からアクセスできます。このフォームにレコードが入力されるたびに、ORG_ACCESSテーブルに行が1つ挿入されます。これはUNIONベースのクエリーBIS_ORGANIZATIONS_Vによるものであり、理想的には、在庫組織の保護ビューの定義は次のようになる必要があります。
SELECT 'INV_ORG', BIS_ORGANIZATIONS_V.ID FROM BIS_ORGANIZATIONS_V WHERE RESPONSIBILITY_ID = :RESPONSIBILITY_ID
これにより、ログインしている職責からアクセス可能な在庫組織のリストが提示されます。BI EEでセキュリティがユーザー・レベルとして設定されている場合、BIクエリーはセキュアです。これは、BIクエリーではユーザーからアクセス可能なすべての職責がチェックされた後、ORG_ACCESSに対してクエリーを実行して、これらの職責からアクセス可能なすべての在庫組織と、明示的にはいずれの職責にも割り当てられていない（つまりだれもがアクセス可能な）在庫組織すべてがチェックされるためです。この在庫組織の結合リストがクエリーに適用されます。このため、特定の在庫組織に特定の職責が（ORG ACCESSフォームを使用して）明示的に付与されている場合、その職責がログイン・ユーザーに割り当てられないと、これらの在庫組織はそのユーザーに対して表示されなくなります。
Oracle EBSの在庫組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
"EBS Single Sign-on Integration"初期化ブロックで、次のEBSシングル・サインオン統合セッション変数が初期化されます。
EBS_SSO_INTEGRATION_MODE
このセッション変数は2つの指定可能な値IntegratedまたはNot Integratedで初期化され、Oracle BI ApplicationsをEBS SSOと統合するかどうかが示されます。
"EBS Security Context"初期化ブロックで次のセッション変数がポピュレートされます。
OLTP_EBS_RESP_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はOracle EBSのユーザーのセッションの職責で初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
OLTP_EBS_RESP_APPL_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はEBSのユーザー・セッションの職責アプリケーションで初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
Oracle Business Intelligence Serverで、FND_USER_RESP_GROUPSからUSERに対応する帳簿セットが取得されます。次のセッション変数が自動的に設定されます。
INV_ORG（行方向の変数）
次に示すように、初期化ブロック"Inventory Organizations"によってこの変数に値が設定されます。
初期化ブロック -- "Inventory Organizations"
次のSQLを使用して、初期化ブロック"Inventory Organizations"によって変数INV_ORGに値が設定されます。
SELECT DISTINCT 'INV_ORG', BIS_ORGANIZATIONS_V.ID
FROM FND_USER_RESP_GROUPS, BIS_ORGANIZATIONS_V
WHERE FND_USER_RESP_GROUPS.RESPONSIBILITY_ID = BIS_ORGANIZATIONS_V.RESPONSIBILITY_ID
AND FND_USER_RESP_GROUPS.START_DATE < SYSDATE
AND (CASE WHEN FND_USER_RESP_GROUPS.END_DATE IS NULL THEN SYSDATE ELSE
AND FND_USER_RESP_GROUPS.USER_ID = (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER')
AND RESPONSIBILITY_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN
VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) =
'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END)
EBSに対する会社組織ベースのセキュリティは、リリース7.9.3で導入されました。これは、リリース7.9.4では元帳セキュリティに置き換えられます。
この項では、Oracle EBSの元帳組織ベースのセキュリティについて説明します。
Oracle E-Business Suiteでは、帳簿セットは基本的に共通の勘定体系、機能通貨および会計カレンダーを使用するレポート組織になります。会社組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられている帳簿セットに基づいてデータがフィルターされます。
Oracle EBSの会社組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
"EBS Single Sign-on Integration"初期化ブロックで、次のEBSシングル・サインオン統合セッション変数が初期化されます。
EBS_SSO_INTEGRATION_MODE
このセッション変数は2つの指定可能な値IntegratedまたはNot Integratedで初期化され、Oracle BI ApplicationsをEBS SSOと統合するかどうかが示されます。
"EBS Security Context"初期化ブロックで次のセッション変数がポピュレートされます。
OLTP_EBS_RESP_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はOracle EBSのユーザーのセッションの職責で初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
OLTP_EBS_RESP_APPL_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はEBSのユーザー・セッションの職責アプリケーションで初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
Oracle Business Intelligence Serverで、FND_USER_RESP_GROUPSからUSERおよびOLTP_EBS_RESP_IDに対応する帳簿セットが取得されます。次のセッション変数が自動的に設定されます。
COMPANY（行方向の変数）
次に示すように、初期化ブロック"Companies"によってこの変数に値が設定されます。
初期化ブロック -- "Companies"
次のSQLを使用して、初期化ブロック"Companies"によって変数COMPANYに値が設定されます。
SELECT DISTINCT 'COMPANY', FND_PROFILE.VALUE_SPECIFIC('GL_SET_OF_BKS_ID', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID)
FROM (SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID FROM FND_USER_RESP_GROUPS WHERE START_DATE < SYSDATE AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE AND USER_ID IN (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER')
AND RESPONSIBILITY_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END))
"Company Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
Oracle EBSに対する元帳ベースのセキュリティは、Oracle BI Applicationsリリース7.9.4で導入されました。これは、会社ベースのセキュリティに置き換わるもので、E-Business Suiteリリース11iのEBS GL帳簿セットのセキュリティ・モデルおよびE-Business Suiteリリース12のEBSデータ・アクセス・セット・モデルをサポートします。
Oracle EBSリリース11iでは、帳簿セットは基本的に勘定体系、機能通貨および会計カレンダーなどのレポート・コンテキストを定義するレポート・エンティティです。帳簿セットは、ユーザー、職責またはすべての職責のデフォルトとしてサイトに割り当てることができます。各ユーザーは、Oracle Applicationsで指定された職責でアプリケーションにログオンする際に、1つの帳簿セットに関連付けられます。元帳ベースのセキュリティでは、ログイン・ユーザーに関連付けられている帳簿セットに基づいてデータがフィルターされます。
Oracle EBSリリース12では、帳簿セットは元帳に置き換えられました。元帳によって、通貨、勘定体系、会計カレンダー、元帳処理オプションおよび補助元帳会計処理基準が決められます。ユーザーの職責に割り当てられるデータ・アクセス・セットによって、ユーザーがアクセスできる元帳が制御されます。ユーザーは、1つの職責から複数の元帳にアクセスできる場合があります。元帳ベースのセキュリティでは、ログイン・ユーザーに関連付けられている元帳に基づいてデータがフィルターされます。
Oracle EBSのソース固有の手順は次のとおりです。
ユーザーがOracle Business Intelligence Enterprise Editionにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
"EBS Single Sign-on Integration"初期化ブロックで、次のEBSシングル・サインオン統合セッション変数が初期化されます。
EBS_SSO_INTEGRATION_MODE
このセッション変数は2つの指定可能な値IntegratedまたはNot Integratedで初期化され、Oracle BI ApplicationsをEBS SSOと統合するかどうかが示されます。
"EBS Security Context"初期化ブロックで次のセッション変数がポピュレートされます。
OLTP_EBS_RESP_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はOracle EBSのユーザーのセッションの職責で初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
OLTP_EBS_RESP_APPL_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はEBSのユーザー・セッションの職責アプリケーションで初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
このセッション変数は、別の初期化ブロック"Ledgers"で初期化されます。この初期化ブロックでは、テーブルFND_USER_RESP_GROUPSおよびプロシージャFND_PROFILEを使用して、USER、OLTP_EBS_RESP_IDおよびOLTP_EBS_RESP_APPL_IDに対応する元帳（EBSでは本来は帳簿セット）を取得します。
行方向の変数:
LEDGER（行方向の変数）
Oracle BIサーバーで、OLTPからUSERとOLTP_EBS_RESP_IDに対応する帳簿セットまたは元帳が取得されます。"Ledgers"初期化ブロックで次のセッション変数がポピュレートされます。
次に示すように、Ledgers初期化ブロックはOracle EBSのリリースに応じて設定する必要があります。
EBSリリース12以降を使用している場合は、初期化ブロックのデータ・ソースとして次のSQLを使用してください。
SELECT DISTINCT 'LEDGER', TO_CHAR(GAL.LEDGER_ID)
FROM GL_ACCESS_SET_LEDGERS GAL, (SELECT FND_PROFILE.VALUE_SPECIFIC('GL_ACCESS_SET_ID',USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID) PROFILE_VALUE
FROM (SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID
FROM FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE
TO_DATE(END_DATE) END) >= SYSDATE AND USER_ID = (CASE WHEN
'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_USER_ID) ELSE (SELECT USER_ID FROM FND_USER WHERE
USER_NAME = 'OPERATIONS') END) AND RESPONSIBILITY_ID = (CASE WHEN
'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN
'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END)
))WHERE GAL.ACCESS_SET_ID = PROFILE_VALUE
Oracle BI Applicationsリリース7.9.4に同梱されているリポジトリ・ファイルには、"Ledger"初期化ブロックにEBSリリース12バージョンのSQLが含まれています。
Oracle EBS 11iに対してBIアプリケーションを実行している場合は、"Ledger"初期化ブロックのデータ・ソースとして次のSQLを使用してください。
SELECT DISTINCT 'LEDGER', FND_PROFILE.VALUE_SPECIFIC('GL_SET_OF_BKS_ID', USER_ID,
RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID)
FROM (SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID FROM
FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE
AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE
AND USER_ID IN (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_USER_ID) ELSE (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER') END)
AND RESPONSIBILITY_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN
VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END))
この項では、Oracle EBSのビジネス・グループ組織ベースのセキュリティについて説明します。
ビジネス・グループは組織構造の最上位レベルであり、通常は、企業全体または主要部署を表すために使用します。1つのビジネス・グループで複数の帳簿セットを使用できます。
Oracle EBSのビジネス・グループ組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
"EBS Single Sign-on Integration"初期化ブロックで、次のEBSシングル・サインオン統合セッション変数が初期化されます。
EBS_SSO_INTEGRATION_MODE
このセッション変数は2つの指定可能な値IntegratedまたはNot Integratedで初期化され、Oracle BI ApplicationsをEBS SSOと統合するかどうかが示されます。
"EBS Security Context"初期化ブロックで次のセッション変数がポピュレートされます。
OLTP_EBS_RESP_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はOracle EBSのユーザーのセッションの職責で初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
OLTP_EBS_RESP_APPL_ID
このセッション変数は、Oracle BI ApplicationsがEBSと統合されている場合はEBSのユーザー・セッションの職責アプリケーションで初期化され、統合されていない場合は無作為のデフォルト値に設定されて無視されます。
Oracle Business Intelligence Serverで、FND_USER_RESP_GROUPSからUSERおよびOLTP_EBS_RESP_IDに対応する帳簿セットが取得されます。次のセッション変数が自動的に設定されます。
BUSINESS_GROUP（行方向の変数）
次に示すように、初期化ブロック"Business Groups"によってこの変数に値が設定されます。
初期化ブロック -- "Business Groups"
次のSQLを使用して、初期化ブロック"Business Groups"によって変数INV_ORGに値が設定されます。
SELECT DISTINCT 'BUSINESS_GROUP', TO_CHAR(FND_PROFILE.VALUE_SPECIFIC('PER_BUSINESS_GROUP_ID', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID))
FROM (SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID FROM FND_USER_RESP_GROUPS WHERE START_DATE < SYSDATE AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE AND USER_ID = (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER')
AND RESPONSIBILITY_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE) = 'Integrated' THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END))
"Business Group Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
従業員ベースのセキュリティによって、レコードのデータ表示が、そのレコードの所有者と、企業の従業員階層内でその所有者からレポートされるすべての従業員に制限されます。このセキュリティ・メカニズムでは、データ・ウェアハウス・データベースのデータが使用され、サポートされている他のアプリケーション（Siebel CRMおよびPeopleSoft）とメタデータのコンポーネントが共有されます。デフォルトでは、このタイプのセキュリティではHR分析ファクトのみがサポートされます。このセキュリティ・メカニズムの機能の詳細は、第7.5.2項「CRM垂直統合型アプリケーションのプライマリ役割ベースのセキュリティ」を参照してください。
この項では、Oracle Business Intelligence ApplicationsのセキュリティをOracle PeopleSoft Enterprise Applicationsに実装する方法について説明します。必要に応じてセキュリティの実装方法を変更できるよう、セキュリティのデフォルトの構成を理解しておく必要がある場合は、この項をお読みください。この項の内容は次のとおりです。
第7.3.3項「PeopleSoft FinancialsまたはPeopleSoft HRの会社組織ベースのセキュリティについて」
第7.3.4項「Oracle PeopleSoft Enterprise Applicationsの元帳ベースのセキュリティについて」
Oracle BI Applicationsの認可プロセスでは、ソースのPeopleSoftアプリケーションからユーザーのロールがフェッチされ、すべてのOracle BI Applicationsセキュリティ・グループと照合されて、ユーザーのセッション時にユーザーの該当するオブジェクト・セキュリティが決定されます。初期化ブロック"Authorization"を使用してロールがフェッチされ、結果セットが特別なセッション変数GROUPに割り当てられます。このセッション変数は、後でOracle Business Intelligence Serverによって一致が検査されます。初期化ブロックのSQLは次のとおりです。
SELECT DISTINCT
'GROUP', ROLENAME
FROM
PSROLEUSER
WHERE
ROLEUSER = ':USER'
Oracle Business Intelligence Applicationsでは、次のタイプのデータ・セキュリティが提供されます。
PeopleSoft Financialsの営業単位ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、次のテーブルからUSERに対応する営業単位（つまりPeopleSoft Financialsの総勘定元帳ビジネス単位）が取得されます。
PS_SEC_BU_OPR
PS_BUS_UNIT_TBL_GL
PS_INSTALLATION_FS
次のセッション変数が自動的に設定されます。
OU_ORG（行方向の変数）
次に示すように、初期化ブロック"Operating Unit Organizations"によってこの変数に値が設定されます
初期化ブロック -- "Operating Unit Org"
次のSQLを使用して、初期化ブロック"Operating Unit Org"によって変数OU_ORGに値が設定されます。
SELECT DISTINCT 'OU_ORG', S1.BUSINESS_UNIT
FROM PS_SEC_BU_OPR S1, PS_BUS_UNIT_TBL_GL A, PS_INSTALLATION_FS I
WHERE S1.OPRID = ':USER'
AND S1.BUSINESS_UNIT = A.BUSINESS_UNIT
AND I.SECURITY_TYPE = 'O'
AND I.BU_SECURITY = 'Y'
UNION
SELECT DISTINCT 'OU_ORG', S2.BUSINESS_UNIT
FROM PS_SEC_BU_CLS S2,
PS_BUS_UNIT_TBL_GL A,
PS_INSTALLATION_FS I2,
PSOPRDEFN P
WHERE P.OPRID = ':USER'
AND S2.BUSINESS_UNIT = A.BUSINESS_UNIT
AND P.OPRCLASS = S2.OPRCLASS
AND I2.SECURITY_TYPE = 'C'
AND I2.BU_SECURITY = 'Y'
"Operating Unit Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
PeopleSoft FinancialsまたはPeopleSoft HRの会社組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、次のテーブルからUSERに対応する会社またはビジネス単位が取得されます。
PS_SEC_BU_OPR
PS_BUS_UNIT_TBL_GL
PS_INSTALLATION_FS（PeopleSoft Financialsの場合）
PS_SCRTY_TBL_DEPT
PS_BU_DEPT_VW
PS_BUS_UNIT_TBL_GL
PSOPRDEFN（PeopleSoft HRの場合）
次のセッション変数が自動的に設定されます。
COMPANY（行方向の変数）
次に示すように、初期化ブロック"Companies"によってこの変数に値が設定されます。
初期化ブロック -- "Companies"
次のSQLを使用して、初期化ブロック"Companies"によって変数COMPANYに値が設定されます。
PeopleSoft Financialsの場合:
SELECT DISTINCT 'COMPANY', S1.BUSINESS_UNIT
FROM PS_SEC_BU_OPR S1, PS_BUS_UNIT_TBL_GL A, PS_INSTALLATION_FS I
WHERE S1.OPRID = ':USER'
AND S1.BUSINESS_UNIT = A.BUSINESS_UNIT
AND I.SECURITY_TYPE = 'O'
UNION
SELECT DISTINCT 'COMPANY', S2.BUSINESS_UNIT
FROM PS_SEC_BU_CLS S2,
PS_BUS_UNIT_TBL_GL A,
PS_INSTALLATION_FS I2,
PSOPRDEFN P
WHERE P.OPRID = ':USER'
AND S2.BUSINESS_UNIT = A.BUSINESS_UNIT
AND P.OPRCLASS = S2.OPRCLASS
AND I2.SECURITY_TYPE = 'C'
AND I2.BU_SECURITY = 'Y'
PeopleSoft HRの場合:
SELECT DISTINCT 'COMPANY',C.BUSINESS_UNIT
FROM PSOPRDEFN A, PS_SCRTY_TBL_DEPT B, PS_BU_DEPT_VW C, PS_BUS_UNIT_TBL_GL D
WHERE
A.ROWSECCLASS = B.ROWSECCLASS AND
B.ACCESS_CD = 'Y' AND
B.DEPTID = C.DEPTID AND
C.BUSINESS_UNIT = D.BUSINESS_UNIT AND
A.OPRID = ':USER'
"Company Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
PeopleSoft Enterprise Applicationsに対する元帳ベースのセキュリティは、リリース7.9.4で導入されました。PeopleSoftの元帳は、ビジネス単位で保護され共有される参照データです。元帳のテーブルにはsetIDフィールドがあり、PeopleToolのTableSet機能が使用されます。また、元帳データへのアクセスは、行レベルのセキュリティで制御されます。行レベルのサポートにより、元帳によって制御されているデータの特定の行から個々のユーザーまたはアクセス権のリストを制限するセキュリティを実装できます。元帳ベースのセキュリティでは、ログイン・ユーザーに関連付けられている元帳に基づいてデータがフィルターされます。元帳へのアクセスは、PeopleSoft TableSetおよび行ベースのセキュリティによって制限されます。
PeopleSoft Financialsの元帳ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、USERに対応する元帳が取得されます。
次のセッション変数が自動的に設定されます。
LEDGER（行方向の変数）
次に示すように、この変数に値を設定する初期化ブロック"Ledgers"が設定されます。
SELECT DISTINCT'LEDGER', LG.SETID || SO.LEDGER
FROM PS_SEC_LEDGER_OPR SO, PS_LED_DEFN_TBL LG, PS_INSTALLATION_FS IFS
WHERE SO.LEDGER = LG.LEDGER AND IFS.SECURITY_TYPE = 'O'
AND IFS.LEDGER_SECURITY = 'Y' AND SO.OPRID = ':USER'
UNION
SELECT distinct 'LEDGER', LG.SETID || SC.LEDGER
FROM PS_SEC_LEDGER_CLS SC, PS_LED_GRP_TBL LG, PSOPRDEFN OP, PSROLEUSER ORL, PSROLECLASS RCL, PS_INSTALLATION_FS IFS
WHERE SC.LEDGER_GROUP = LG.LEDGER_GROUP AND SC.OPRCLASS = RCL.CLASSID AND OP.OPRID = ORL.ROLEUSER
AND ORL.ROLENAME = RCL.ROLENAME and IFS.SECURITY_TYPE = 'C' AND IFS.LEDGER_SECURITY = 'Y' AND OP.OPRID = ':USER'
PeopleSoftアプリケーションに対して元帳のセキュリティを設定した場合、PoepleSoftに対する会社組織ベースのセキュリティも設定する必要があります。元帳ベースのセキュリティによって、総勘定元帳ビジネス単位のデータが自動的に制限されるわけではありません。
PeopleSoft HRのHR組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、次のテーブルからUSERに対応するHRビジネス単位が取得されます。
PSOPRDEFN
PS_SCRTY_TBL_DEPT
PS_BU_DEPT_VW
PS_BUS_UNIT_TBL_HR
次のセッション変数が自動的に設定されます。
HR_ORG（行方向の変数）
次に示すように、初期化ブロック"HR Organizations"によってこの変数に値が設定されます。
初期化ブロック -- "HR Organizations"
次のSQLを使用して、初期化ブロック"HR Organizations"によって変数HR_ORGに値が設定されます。
SELECT DISTINCT 'HR_ORG', C.BUSINESS_UNIT
FROM PSOPRDEFN A, PS_SCRTY_TBL_DEPT B, PS_BU_DEPT_VW C, PS_BUS_UNIT_TBL_HR D
WHERE
A.ROWSECCLASS = B.ROWSECCLASS AND
B.ACCESS_CD = 'Y' AND
B.DEPTID = C.DEPTID AND
C.BUSINESS_UNIT = D.BUSINESS_UNIT AND
A.OPRID = ':USER'
"HR Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
PeopleSoft Financialsの買掛勘定組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、次のテーブルからUSERに対応するHRビジネス単位が取得されます。
PSOPRDEFN
PS_SEC_BU_OPR
PS_SEC_BU_CLR
PS_INSTALLATION_FS
PS_BUS_UNIT_TBL_AP
次のセッション変数が自動的に設定されます。
PAYABLES_ORG（行方向の変数）
次に示すように、初期化ブロック"Payables Organizations"によってこの変数に値が設定されます。
初期化ブロック -- "Payables Organizations"
次のSQLを使用して、初期化ブロック"Payables Organizations"によって変数PAYABLES_ORGに値が設定されます。
SELECT DISTINCT 'PAYABLES_ORG', s1.BUSINESS_UNIT
FROM PS_SEC_BU_OPR s1, PS_BUS_UNIT_TBL_AP a, PS_INSTALLATION_FS i
WHERE s1.OPRID = ':USER'
AND s1.BUSINESS_UNIT = a.BUSINESS_UNIT
AND i.SECURITY_TYPE = 'O'
AND i.BU_SECURITY = 'Y'
UNION
SELECT DISTINCT 'PAYABLES_ORG', s2.BUSINESS_UNIT
FROM PS_SEC_BU_CLS s2, PS_BUS_UNIT_TBL_AP a, PS_INSTALLATION_FS i2, PSOPRDEFN p
WHERE p.OPRID = ':USER'
AND s2.BUSINESS_UNIT = a.BUSINESS_UNIT
AND p.OPRCLASS = s2.OPRCLASS
AND i2.SECURITY_TYPE = 'C'
AND i2.BU_SECURITY = 'Y'
"Payables Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
PeopleSoft Financialsの売掛勘定組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、次のテーブルからUSERに対応するHRビジネス単位が取得されます。
PSOPRDEFN
PS_SEC_BU_OPR
PS_SEC_BU_CLR
PS_INSTALLATION_FS
PS_BUS_UNIT_TBL_AP
次のセッション変数が自動的に設定されます。
RECEIVABLES_ORG（行方向の変数）
次に示すように、初期化ブロック"Receivables Organizations"によってこの変数に値が設定されます。
初期化ブロック -- "Receivables Organizations"
次のSQLを使用して、初期化ブロック"Receivables Organizations"によって変数RECEIVABLES_ORGに値が設定されます。
SELECT DISTINCT 'RECEIVABLES_ORG', s1.BUSINESS_UNIT
FROM PS_SEC_BU_OPR s1, PS_BUS_UNIT_TBL_AR a, PS_INSTALLATION_FS i
WHERE s1.OPRID = ':USER'
AND s1.BUSINESS_UNIT = a.BUSINESS_UNIT AND i.SECURITY_TYPE = 'O'
AND i.BU_SECURITY = 'Y'
UNION
SELECT DISTINCT 'RECEIVABLES_ORG', s2.BUSINESS_UNIT
FROM PS_SEC_BU_CLS s2, PS_BUS_UNIT_TBL_AR a, PS_INSTALLATION_FS i2, PSOPRDEFN p
WHERE p.OPRID = ':USER'
AND s2.BUSINESS_UNIT = a.BUSINESS_UNIT AND p.OPRCLASS = s2.OPRCLASS AND i2.SECURITY_TYPE = 'C'
AND i2.BU_SECURITY = 'Y'
"Receivables Org-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
PeopleSoft FinancialsのセットIDベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER（システム変数）
Oracle BI Serverで、次のテーブルからUSERに対応するセットIDが取得されます。
PS_SEC_SETID_OPR
PS_SEC_SETID_CLS
PS_INSTALLATION_FS
PSOPRDEFN
次のセッション変数が自動的に設定されます。
SET_ID（行方向の変数）
次のSQLを使用して、初期化ブロック"Set ID"によって変数SET_IDに値が設定されます。
PeopleSoft Financialsの場合:
SELECT DISTINCT 'SET_ID', s1.SETID
FROM PS_SEC_SETID_OPR s1, PS_INSTALLATION_FS i
WHERE s1.OPRID = ':USER'
AND i.SECURITY_TYPE = 'O'
AND i.SETID_SECURITY = 'Y'
UNION
SELECT DISTINCT 'SET_ID', s2.SETID
FROM PS_SEC_SETID_CLS s2, PS_INSTALLATION_FS i2, PSOPRDEFN p
WHERE p.OPRID = ':USER'
AND p.OPRCLASS = s2.OPRCLASS
AND i2.SECURITY_TYPE = 'C'
AND i2.SETID_SECURITY = 'Y'
"Set ID-based Security"セキュリティ・グループには、データ・アクセス権のフィルターがすべて含まれています。実装時、顧客はこのセキュリティ・グループに関連付けるユーザーまたはグループを決定する必要があります。
HR担当者は、組織内部のすべての担当データと、HR担当者自身の組織内の部下社員のデータを確認する必要があります。HR担当者のデータ・セキュリティ・グループがこのニーズに応えます。このグループのセキュリティ・メカニズムでは、次のメタデータ要素が使用されます。
変数HR_ORG。行方向の初期化ブロック"HR Organizations"によって定義される変数です。このデータセットには、ユーザーが担当するすべての組織と、ユーザー自身の組織（USER_HR_ORGで選択したものと同じ）が格納されます。このデータセットにポピュレートするクエリーは次のとおりです。
SELECT DISTINCT
'HR_ORG',
C.BUSINESS_UNIT
FROM
PSOPRDEFN A, PS_SCRTY_TBL_DEPT B, PS_BU_DEPT_VW C, PS_BUS_UNIT_TBL_HR D
WHERE
A.ROWSECCLASS = B.ROWSECCLASS AND
B.ACCESS_CD = 'Y' AND
B.DEPTID = C.DEPTID AND
C.BUSINESS_UNIT = D.BUSINESS_UNIT AND
A.OPRID = ':USER'
UNION
SELECT DISTINCT 'HR_ORG', FINAL_JOB.BUSINESS_UNIT
FROM (
SELECT X.EMPLID, MAX(X.BUSINESS_UNIT) BUSINESS_UNIT FROM
(
SELECT A.EMPLID, A.EMPL_RCD, A.EFFDT,EFFSEQ, A.JOB_INDICATOR,A.EMPL_STATUS, A.BUSINESS_UNIT
FROM PS_JOB A ,
(SELECT EMPLID, MAX(EFFDT) MAX_EFFDT
FROM PS_JOB
WHERE
JOB_INDICATOR = 'P' AND EMPL_STATUS IN ('A', 'L', 'P', 'W')
GROUP BY EMPLID) B
WHERE
A.EMPLID = B.EMPLID
AND A.EFFDT = B.MAX_EFFDT
AND A.JOB_INDICATOR = 'P' AND A.EMPL_STATUS IN ('A', 'L', 'P', 'W')
AND A.EFFSEQ = (SELECT MAX (C.EFFSEQ)
FROM PS_JOB C
WHERE
C.EMPLID = A.EMPLID AND
C.EMPL_RCD = A.EMPL_RCD AND
C.EFFDT = A.EFFDT AND
C.JOB_INDICATOR = 'P' AND C.EMPL_STATUS IN ('A', 'L', 'P', 'W'))
) X
GROUP BY X.EMPLID
) FINAL_JOB, PSOPRDEFN
WHERE
FINAL_JOB.EMPLID = PSOPRDEFN.EMPLID AND
PSOPRDEFN.OPRID = ':USER'
変数USER_HR_ORG。初期化ブロック"User HR Organizations"を使用して定義されます。この変数には、ユーザー自身の組織が格納されます。この変数にポピュレートするクエリーは次のとおりです。
SELECT DISTINCT FINAL_JOB.BUSINESS_UNIT
FROM (
SELECT X.EMPLID, MAX(X.BUSINESS_UNIT) BUSINESS_UNIT FROM
(
SELECT A.EMPLID, A.EMPL_RCD, A.EFFDT,EFFSEQ, A.JOB_INDICATOR, A.EMPL_STATUS, A.BUSINESS_UNIT
FROM PS_JOB A ,
(SELECT EMPLID, MAX(EFFDT) MAX_EFFDT
FROM PS_JOB
WHERE
JOB_INDICATOR = 'P' AND EMPL_STATUS IN ('A', 'L', 'P', 'W')
GROUP BY EMPLID) B
WHERE
A.EMPLID = B.EMPLID
AND A.EFFDT = B.MAX_EFFDT
AND A.JOB_INDICATOR = 'P' AND A.EMPL_STATUS IN ('A', 'L', 'P', 'W')
AND A.EFFSEQ = (SELECT MAX (C.EFFSEQ)
FROM PS_JOB C
WHERE
C.EMPLID = A.EMPLID AND
C.EMPL_RCD = A.EMPL_RCD AND
C.EFFDT = A.EFFDT AND
C.JOB_INDICATOR = 'P' AND C.EMPL_STATUS IN ('A', 'L', 'P', 'W'))
) X
GROUP BY X.EMPLID
) FINAL_JOB, PSOPRDEFN
WHERE
FINAL_JOB.EMPLID = PSOPRDEFN.EMPLID AND
PSOPRDEFN.OPRID = ':USER'
セキュリティ・グループ"Human Resources Analyst"。このグループに定義されるデータ・フィルターは次のとおりです。
Core."Dim - Employee Organization"."Employee Organization Number" = VALUEOF(NQ_SESSION."HR_ORG") AND (Core."Dim - Employee Organization"."Employee Organization Number" <> VALUEOF(NQ_SESSION."USER_HR_ORG") OR Core."Dim - Security Dimension"."Hierarchy Based Column" = VALUEOF(NQ_SESSION."USER"))
このフィルターによって、レポートで使用される要素が従業員組織の次元に結合され、要素レコードの従業員所有者の組織番号が取得されます。この組織がHR_ORGに含まれる場合、この組織は次にユーザー自身の組織と比較されます。これらが異なる場合は、さらにチェックされることはなく、レコードが選択されます。これらが同一の場合は、従業員階層に基づいて追加フィルターが適用され、この要素レコードの従業員所有者がユーザーの部下社員の1人であることが確認されます。
従業員ベースのセキュリティによって、レコードのデータ表示が、そのレコードの所有者と、企業の従業員階層内でその所有者からレポートされるすべての従業員に制限されます。このセキュリティ・メカニズムでは、データ・ウェアハウス・データベースのデータが使用され、サポートされている他のアプリケーション（Oracle EBS、Siebel CRMなど）とメタデータのコンポーネントが共有されます。デフォルトでは、このタイプのセキュリティではHR分析ファクトのみがサポートされます。このセキュリティ・メカニズムの機能の詳細は、第7.5.2項「CRM垂直統合型アプリケーションのプライマリ役割ベースのセキュリティ」を参照してください。
オブジェクトレベルのセキュリティでは、主にメタデータおよびPresentation Servicesオブジェクトなど、様々なAnalyticsオブジェクトへのアクセスが制御されます。
リポジトリ・グループによって、サブジェクトエリア、テーブル、カラムなどのメータデータ・オブジェクトへのアクセスが制御されます。
メタデータ・オブジェクトのセキュリティは、Oracle BI Administration Toolを使用してAnalyticsリポジトリ（OracleBIAnalyticsApps.rpd）で構成されます。ユーザー・グループEveryoneは、すべてのサブジェクトエリアへのアクセスが否認されます。各サブジェクトエリアは、選択された関連職責に対して明示的な読取りアクセス権を与えるように構成されます。このアクセスは、テーブルおよびカラム・レベルに拡張できます。
|
注意: 製品の出荷時には、サブジェクトエリア・レベルのアクセス権のみが構成されています。 |
この明示的な構成ルールの例外が通信業界向けアプリケーション（Communications）および財務管理業務の分析用アプリケーション（Financial Analytics）で、これらのアプリケーションについては、これら2つの業種に固有のテーブルやカラムが、通常のSiebel基幹業務アプリケーションのサブジェクトエリア全体に散在します。これらの業種固有のメタデータ・オブジェクトは、他のグループに対しては非表示になります。
Oracle Business Intelligenceでは、リポジトリのグループ内の階層がサポートされます。Analyticsリポジトリには、すべての子グループの動作を定義する親グループがあります。親グループの権限は継承によって子グループに伝播されます。親グループとその目的を表7-1に示します。
ダッシュボードやページなどのPresentation Servicesオブジェクトは、Siebelの職責と同じ名前を持つPresentation Servicesグループを使用して制御されます。ダッシュボードおよびページへのアクセスは、Presentation Servicesグループを使用して制御されます。Presentation ServicesグループField Sales Representative Analyticsに属するユーザーとしてログオンした場合、パイプラインダッシュボード内には「概要」、「予想」および「詳細データ」ページのみが表示されます。同様に、ダッシュボード内の少なくとも1ページにアクセスできるダッシュボードのみが表示されます。これらのグループは、Oracle BI Webインターフェイスでカスタマイズされます。
Oracle Siebel基幹業務アプリケーションと統合されたOracle Business Intelligenceの場合、Presentation Servicesのセキュリティでは次の方式が利用されています。
Presentation Servicesのセキュリティは、アプリケーションごとに表7-1に含まれるグループに対して事前設定されています。
Presentation Servicesの各ダッシュボードへのアクセス権は、関連するSiebel基幹業務アプリケーションの各ビューへのアクセス権と一致します。Siebel基幹業務アプリケーションでは、ビューは職責によって制御されます。一方、Oracle Business Intelligence Presentation Servicesでは、グループごとのダッシュボードへのアクセスがWeb管理によって制御されます。2つのアクセス設定が一致しないと、次の両方の状況が生じる可能性があります。
Siebel基幹業務アプリケーションの特定のビューにアクセスできるユーザーが、対応するダッシュボードにアクセスできない場合、ダッシュボードへのアクセス権がないことを示すエラー・メッセージを受け取ります。
ユーザーが、アクセス権のないサブジェクトエリアに基づくレポートが含まれるダッシュボードにアクセスしようとすると、レポートの含まれないダッシュボードが表示されます。
この項では、Oracle BI ApplicationsのセキュリティをSiebel CRMのセキュリティと統合する方法について説明します。この項の内容は次のとおりです。
この項では、プライマリ役割ベースのセキュリティについて説明します。この項の内容は次のとおりです。
このタイプのセキュリティでは、要素（または次元）レコードのデータ表示が、このレコードのプライマリ所有者と階層内のプライマリ所有者より上位に制限されます。レコードのプライマリ所有者は、役割（Siebel CRMアプリケーションの商談および収益レコードの場合など）であったり、従業員（Oracle EBSアプリケーションの給与支払レコードの場合など）であったりします。プライマリ役割ベースのセキュリティでは、W_POSTION_DHというフラット化された階層テーブルが使用されます。このテーブルは、W_POSITION_Dに基づいており、タイプ2の緩やかに変化する次元として扱われます。Siebel CRMベースのデータの場合、このテーブル（W_POSITION_D）は、役割テーブルからポピュレートされるため、プライマリ従業員として新しい従業員がこの役割に関連付けられるたびに、同じ役割について新しいレコードが作成されます。Oracle EBSおよびPeopleSoftがソースであるデータの場合、このテーブルは従業員テーブル（Oracle EBSの場合は特にPER_ALL_PEOPLE_F、JTF_RESOURCES）からポピュレートされるため、この従業員の階層構造またはこの従業員の役割が変更されるたびに、同じ従業員について新しいレコードが作成されます。
このため、ソース・テーブル内の各レコードが、このテーブル（W_POSITION_DH）内の複数のレコードで表される場合がありますが、常に1つのレコードのみに'Y'としてCURRENT_FLGの値を指定できます。また、W_POSITION_DHテーブルには、プレフィックスCURRENTが付いたカラム・セットが1つと、プレフィックスCURRENTの付いていないカラム・セットが1つ含まれます。プレフィックスCURRENTが付いたカラムは常に、対象の役割（または従業員レコード）の現在の階層構造を示します。プレフィックスCURRENTの付いていないカラムは、EFFECTIVE_START_DTからEFFECTIVE_END_DTまでの期間の、同じ役割（または従業員レコード）の階層構造を示します。後者のカラム・セットは、AS WASタイプのセキュリティに使用されます。つまり、レコードの所有者とそれより上位レベルの管理者（レコード作成時点の）に対して、企業階層内の所有者の役割または管理者が変更された後であっても要素レコードが表示されます。
要素は、レコード所有者を介してこの次元に結合されます。たとえば、W_REVN_FはPR_POSITION_DH_WIDを使用して結合されます。ここで、PR_POSITION_DH_WIDは、ソース・アプリケーションの収益のプライマリ役割です。別の例として、W_PAYROLL_FはEMP_POSTN_DH_WIDを使用して結合されます。ここで、EMP_POSTN_DH_WIDは、この給与支払レコードの従業員所有者です。
プライマリ役割ベースのセキュリティでは、レコード所有者と、レコード所有者の階層チェーン内でレコード所有者より上位の従業員のみがレコードを表示できます。プライマリ役割ベースのセキュリティでは、リポジトリで次のメタデータ要素が使用されます。
セッション変数HIER_LEVEL。これは、次のSQLを使用して、初期化ブロック"User Hierarchy Level"によってポピュレートされます。
Select round(FIXED_HIER_LEVEL) FROM VALUEOF(OLAPTBO).W_POSITION_DH WHERE BASE_LOGIN= ':USER' AND CURRENT_FLG='Y'
HIER_LEVELの値は0〜9までの数値で、これによって企業の役割（または従業員）階層内のユーザーのレベルが指定されます。たとえば、従業員階層が完全なツリーの場合、企業のCEOは、HIER_LEVELの値が9の唯一の従業員です。
プライマリ役割/従業員ベースのセキュリティでサポートされる要素に結合される論理次元"Dim - Security"。この論理次元は、物理テーブルW_POSITION_DHで定義されます。
"Hierarchy Based Column"という、この次元の論理カラム。これは次のように定義されます。
"INDEXCOL(VALUEOF(NQ_SESSION."HIER_LEVEL"), "Core"."Dim - Security Dimension"."Current Base Level Login", "Core"."Dim - Security Dimension"."Current Level 1 Login", "Core"."Dim - Security Dimension"."Current Level 2 Login", "Core"."Dim - Security Dimension"."Current Level 3 Login", "Core"."Dim - Security Dimension"."Current Level 4 Login", "Core"."Dim - Security Dimension"."Current Level 5 Login", "Core"."Dim - Security Dimension"."Current Level 6 Login", "Core"."Dim - Security Dimension"."Current Level 7 Login", "Core"."Dim - Security Dimension"."Current Level 8 Login", "Core"."Dim - Security Dimension"."Current Top Level Login")".
この定義内のIndexCol関数によって、Hierarchy Based ColumnがHIER_LEVELの値に基づいてリスト内の論理カラムの1つにデフォルト設定されます。このため、たとえばHIER_LEVELが0の場合、新しいカラムがリストの最初のカラムにデフォルト設定されます。
次のように定義されたセキュリティ・グループ"Primary Employee/Position Hierarchy-based Security"のフィルタ。("Core"."Dim - Security Dimension"."Hierarchy Based Column" = VALUEOF(NQ_SESSION."USER")),
データ・セキュリティのフィルタを適用するには、ユーザーは、いずれかの職責（SiebelおよびOracle EBSアプリケーションの場合）またはロール（PeopleSoftアプリケーションの場合）に基づいた、セキュリティ・グループ"Primary Employee/Position Hierarchy-based Security"のメンバーである必要があります。ユーザーは、第7.6.3項「Oracle BI Applicationsのセキュリティに使用する初期化ブロック」で定義されている初期化ブロックAuthorizationを使用して、ユーザーの職責に基づいてこのセキュリティ・グループに割り当てられます。デフォルトでは、この初期化ブロックは次のSQLを使用してポピュレートされます。
Select 'GROUP', R.NAME
from VALUEOF(TBO).S_RESP R, VALUEOF(TBO).S_PER_RESP P, VALUEOF(TBO).S_USER U
where U.LOGIN=Upper(':USER') and U.ROW_ID=P.PER_ID and P.RESP_ID=R.ROW_ID
UNION
select 'GROUP', CASE VALUEOF(NQ_SESSION.HIER_LEVEL)
WHEN 0 THEN 'Hierarchy Level (Base)'
when 1 then 'Hierarchy Level 1'
when 2 then 'Hierarchy Level 2'
when 3 then 'Hierarchy Level 3'
when 4 then 'Hierarchy Level 4'
when 5 then 'Hierarchy Level 5'
when 6 then 'Hierarchy Level 6'
when 7 then 'Hierarchy Level 7'
when 8 then 'Hierarchy Level 8'
When 9 then 'Hierarchy Level (Top)'
ELSE 'NOGROUP' END from VALUEOF(TBO).S_DUAL
このSQLの最初の部分では、Siebel CRMアプリケーションからユーザーの職責が選択されます。ユーザーは、Oracle Business Intelligenceリポジトリ内と同じ名前のセキュリティ・グループに自動的に割り当てられます。
このSQLの2つ目の部分では、ユーザーが、変数HIER_LEVELに基づいて、Oracle Business Intelligence固有のセキュリティ・グループ"Hierarchy Level (Base)"から"Hierarchy Level (Top)"に割り当てられます。これらのセキュリティ・グループは、データ・セキュリティを目的として使用されるのではなく、一部のレポートで定義されるWeb Choose関数とともに、プレゼンテーションカラムを目的としてのみ使用されます。この関数の目的は、複数ユーザーのレポートで、ユーザーの階層レベルに基づいて異なる役割カラムをユーザーに表示できるようにすることです。これは、前述のIndexCol関数によく似ています。
Oracle Business Intelligenceの新しい次元または要素にプライマリ役割ベースのセキュリティを追加できます。例として、次のタスクでは次元W_AGREE_D（アグリーメント）を使用します。
次元にセキュリティ・サポートを追加するには:
基礎となる物理テーブルに結合するW_POSITION_DHに別名を明示的に作成します。
物理レイヤーに結合を構成します。
W_POSITION_DHの別名を次元の論理テーブル・ソースに追加します。
新しい論理カラムCURRENT_BASE_LOGIN、CURRENT_LVL1ANC_LOGIなどを論理テーブルに追加して、これらのカラムを対応する物理カラムにマップします。
前述の第3.2項で説明したように定義した階層カラム"Hierarchy Based Column"を追加します。
Oracle BI Administratorで「管理/セキュリティ」を使用して、セキュリティ・グループの画面を開きます。
グループ"Primary Employee/Position Hierarchy-based Security"を右クリックして、「プロパティ」を選択します。
「プロパティ」ダイアログ・ボックスで、「許可」ボックスをクリックして、「フィルター」タブを選択します。
新しいフィルターを追加するには、「追加」ボタンをクリックします。
新しいウィンドウで、「ビジネス モデル」タブを選択して、論理テーブルDim - Agreementを見つけます。
フィルターのリストに新しいレコードが自動的に追加されます。
省略記号のボックスをクリックし、セキュリティ・フィルター式ビルダーにフィルター条件"Core"."Dim - Customer"."Hierarchy Based Login" = VALUEOF(NQ_SESSION."USER")を追加して、「OK」をクリックします。
要素にセキュリティ・サポートを追加するには:
基礎となる物理テーブルをDim_W_POSITION_DH_Position_Hierarchyに結合します。
ここでは、要素テーブルに該当する外部キーがすでに作成されていて、そのキーが正常にポピュレートされていることを前提とします。
論理テーブルをDim - Security次元に結合します。
Oracle BI Administratorで「管理/セキュリティ」を使用して、セキュリティ・グループの画面を開きます。
グループ"Primary Employee/Position Hierarchy-based Security"を右クリックして、「プロパティ」を選択します。
「プロパティ」ダイアログ・ボックスで、「許可」ボックスをクリックして、「フィルター」タブを選択します。
新しいフィルターを追加するには、「追加」ボタンをクリックします。
新しいウィンドウで、「ビジネス モデル」タブを選択して、論理テーブルDim - Agreementを見つけます。
フィルターのリストに新しいレコードが自動的に追加されます。
省略記号のボックスをクリックし、セキュリティ・フィルター式ビルダーに条件"Core"."Dim - Security Dimension"."Hierarchy Based Column" = VALUEOF(NQ_SESSION."USER")を追加して、「OK」をクリックします。
この項では、CRM垂直統合型アプリケーションのプライマリ役割ベースのセキュリティについて説明します。この項の内容は次のとおりです。
第7.5.2.3項「Communications, Media, and Energy（CME）Analyticsのセキュリティ設定」
第7.5.2.5項「Oracle Pharma Sales AnalyticsおよびOracle Pharma Marketing Analyticsのセキュリティ設定」
Oracle Siebel基幹業務アプリケーションには、Oracle Siebel Sales、Oracle Siebel ServiceおよびOracle Siebel Partner Relationship Managementが含まれます。ここでは、Siebel基幹業務アプリケーションSiebel ERM Analyticsに必要となる場合がある追加のセキュリティ構成について説明します。Siebel ERM Analyticsは、HR、Partner ManagerおよびPartner Portal Analyticsに分けられます。
Oracle Partner Analyticsには、ロールベースの分析の概念が組み込まれています。ロールベースの分析では、ブランド所有者がユーザーに対して、ユーザー固有のロールに基づいてダッシュボードとページを表示できます。たとえば、営業管理者がパイプラインとセールスの効果に関連するダッシュボードを表示できる一方、マーケティング管理者はキャンペーンに関連するダッシュボードを表示できます。Oracle Partner Analyticsには、サブジェクトエリアとデータへのアクセスを制御する柔軟性のあるセキュリティ・メカニズムも組み込まれています。
Analyticsのロールは、Siebel基幹業務アプリケーションのSiebel職責にマップされます。ここでは、Partner ManagerアプリケーションおよびPartner Portalアプリケーションの両方について、ロールとそれに関連付けられるダッシュボードおよびページについて説明します。職責に対するサブジェクトエリアとデータレベルのセキュリティ設定についても説明します。
表7-2は、Siebel PRM Partner Managerアプリケーションの特定の職責に対するダッシュボードとページ・タブのマッピングを示しています。
表7-2 PRM Analyticsに対するSiebelの職責
| 職責 | ダッシュボード | ページ・タブ名 |
|---|---|---|
|
Channel Account Manager Analyticsユーザー |
チャネル顧客 |
概要 |
|
チャネル顧客 |
セールス |
|
|
チャネル営業 |
製品 |
|
|
チャネル営業 |
セールス |
|
|
チャネルサービス |
製品 |
|
|
チャネルサービス |
サービス |
|
|
チャネルトレーニング |
トレーニングプロファイル |
|
|
Channel Executive Analyticsユーザー |
チャネル顧客 |
顧客プロファイル |
|
チャネルエグゼクティブ |
顧客満足度 |
|
|
チャネルエグゼクティブ |
パイプライン |
|
|
チャネルエグゼクティブ |
製品 |
|
|
チャネルエグゼクティブ |
プログラム |
|
|
チャネルエグゼクティブ |
収益 |
|
|
チャネルエグゼクティブ |
サービス |
|
|
チャネルセグメンテーション |
チャネル混合 |
|
|
チャネルセグメンテーション |
パートナーのテリトリー |
|
|
チャネルセグメンテーション |
パートナー認定レベル |
|
|
チャネルセグメンテーション |
パートナータイプ |
|
|
Channel Marketing Manager Analyticsユーザー |
チャネル顧客 |
概要 |
|
チャネル顧客 |
セールス |
|
|
顧客マーケティング |
効果 |
|
|
顧客マーケティング |
反応 |
|
|
顧客マーケティング |
ROI |
|
|
Channel Operations Analyticsユーザー |
チャネルの商取引 |
オーダー |
|
チャネルの商取引 |
概要 |
|
|
チャネルの商取引 |
見積り |
|
|
チャネルの商取引 |
製品 |
|
|
チャネル顧客 |
概要 |
|
|
チャネル顧客 |
セールス |
|
|
チャネル顧客 |
サービス |
|
|
チャネルマーケティング |
効果 |
|
|
チャネルマーケティング |
概要 |
|
|
チャネル営業 |
マージン |
|
|
チャネル営業 |
パイプライン |
|
|
チャネル営業 |
収益 |
|
|
チャネル営業 |
セールスサイクル |
|
|
チャネル営業 |
成約数 |
|
|
チャネルセグメンテーション |
パートナーのテリトリー |
|
|
チャネルセグメンテーション |
パートナー認定レベル |
|
|
チャネルセグメンテーション |
パートナータイプ |
|
|
チャネルサービス |
顧客満足度 |
|
|
チャネルサービス |
概要 |
|
|
チャネルサービス |
製品 |
|
|
チャネルサービス |
解決時間 |
|
|
チャネルサービス |
サービスリクエスト |
|
|
チャネルトレーニング |
概要 |
|
|
チャネルトレーニング |
実績 |
表7-3は、Siebel PRM Partner Portalアプリケーションの特定の職責に対するダッシュボードとページ・タブのマッピングを示しています。
表7-3 PRM Partner Portal Analyticsに対する職責
| 職責 | ダッシュボード | ページ・タブ名 |
|---|---|---|
|
Partner Executive Analyticsユーザー |
パートナーエグゼクティブ |
パイプライン |
|
パートナーエグゼクティブ |
製品 |
|
|
パートナーエグゼクティブ |
セールス効果 |
|
|
パートナーエグゼクティブ |
サービス |
|
|
Partner Operations Analyticsユーザー |
パートナーの商取引 |
概要 |
|
パートナーの商取引 |
製品 |
|
|
パートナーのマーケティング |
概要 |
|
|
パートナーのマーケティング |
ROI |
|
|
パートナーの売上 |
パイプライン |
|
|
パートナーの売上 |
収益 |
|
|
パートナーサービス |
顧客満足度 |
|
|
パートナーサービス |
概要 |
|
|
パートナーサービス |
サービスリクエスト |
|
|
パートナーのトレーニング |
研修 |
|
|
Partner Sales Manager Analyticsユーザー |
パートナーの商取引 |
オーダー |
|
パートナーの商取引 |
概要 |
|
|
パートナーの商取引 |
見積り |
|
|
パートナーの売上 |
パイプライン |
|
|
パートナーの売上 |
収益 |
|
|
パートナーの売上 |
部下社員 |
|
|
パートナーのトレーニング |
部下社員 |
|
|
Partner Sales Rep Analyticsユーザー |
パートナーの商取引 |
オーダー |
|
パートナーの商取引 |
概要 |
|
|
パートナーの商取引 |
見積り |
|
|
パートナーの売上 |
パイプライン |
|
|
パートナーの売上 |
収益 |
|
|
パートナーの売上 |
部下社員 |
|
|
パートナーのトレーニング |
部下社員 |
|
|
Partner Service Manager Analyticsユーザー |
パートナーサービス |
顧客満足度 |
|
パートナーサービス |
概要 |
|
|
パートナーサービス |
サービスリクエスト |
|
|
パートナーサービス |
部下社員 |
|
|
パートナーのトレーニング |
部下社員 |
|
|
Partner Service Rep Analyticsユーザー |
パートナーサービス |
概要 |
|
パートナーサービス |
サービスリクエスト |
|
|
パートナーサービス |
部下社員 |
|
|
パートナーのトレーニング |
部下社員 |
Siebel PRM Analyticsの非定型クエリーは、ユーザーの職責に応じて、Oracle Business Intelligenceアプリケーションのサブジェクトエリアのカラムに基づいてユーザーによって作成されます。職責に基づいたサブジェクトエリアに表示を制限することによって、Oracle Siebel PRM Analyticsでは、ブランド所有者が柔軟性のある方法でロールベースの分析を実装できるようになります。
表7-4は、Partner Managerの職責に対するサブジェクトエリアの表示を示しています。Xは、サブジェクトエリアがその職責を持つユーザーに対して表示されることを示します。
表7-4 PRM Partner Manager Analyticsに対する職責
| Subject Area | Channel Executive Analyticsユーザー | Channel Operations Analyticsユーザー | Channel Account Manager Analyticsユーザー | Channel Marketing Manager Analyticsユーザー |
|---|---|---|---|---|
|
活動 |
X |
X |
X |
X |
|
資産 |
X |
X |
X |
|
|
キャンペーン |
X |
X |
X |
X |
|
消費者 |
X |
X |
X |
X |
|
顧客満足度 |
X |
X |
X |
|
|
顧客 |
X |
X |
X |
X |
|
オーダー |
X |
X |
X |
X |
|
パートナーのトレーニング |
X |
X |
X |
|
|
パートナー |
X |
X |
X |
X |
|
パイプライン |
X |
X |
X |
X |
|
価格決定 |
X |
X |
X |
X |
|
製品 |
X |
X |
X |
X |
|
リアルタイムの活動 |
||||
|
リアルタイム資産 |
||||
|
サービスリクエスト |
X |
X |
X |
表7-5は、Partner Portalのロールに対するサブジェクトエリアの表示を示しています。Xは、サブジェクトエリアがその職責を持つユーザーに対して表示されることを示します。
表7-5 PRM Partner Portalに対するサブジェクトエリアの表示
| Subject Area | Partner Executive Analyticsユーザー | Partner Operations Manager Analyticsユーザー | Partner Sales Manager Analyticsユーザー | Partner Sales Rep Analyticsユーザー | Partner Service Manager Analyticsユーザー | Partner Service Rep Analyticsユーザー |
|---|---|---|---|---|---|---|
|
活動 |
X |
X |
X |
X |
X |
X |
|
資産 |
X |
X |
X |
X |
||
|
キャンペーン |
X |
X |
||||
|
消費者 |
X |
X |
||||
|
顧客満足度 |
X |
X |
X |
X |
||
|
顧客 |
X |
X |
X |
X |
X |
X |
|
オーダー |
X |
X |
X |
X |
X |
X |
|
パートナーのトレーニング |
X |
X |
X |
X |
X |
X |
|
パートナー |
X |
X |
||||
|
パイプライン |
X |
X |
X |
X |
||
|
価格決定 |
||||||
|
製品 |
X |
X |
X |
X |
X |
X |
|
リアルタイムの活動 |
||||||
|
リアルタイム資産 |
||||||
|
サービスリクエスト |
X |
X |
X |
X |
Oracle PRM Analyticsでは、ブランド所有者は、ユーザーの組織または役割に基づいてセキュリティを制限することもできます。このセキュリティ・メカニズムでは、ユーザーは別のユーザーのデータにはアクセスできません。また、パートナーは別のパートナーのデータにはアクセスできません。データレベルのセキュリティは、職責に対して管理されます。データレベルの表示の設定の詳細は、第7.6.2項「Oracle BI Applications Repositoryのデータレベルのセキュリティの実装」を参照してください。パートナーのサービス担当者および営業員を組織ベースのセキュリティに変更するには、第7.5.4項「役割の変更に対するOracle Business Intelligenceの埋込みサポート」の手順に従ってください。
表7-6は、Partner ManagerおよびPartner Portalの職責に対する組込みのデータレベルのセキュリティ設定を示しています。
表7-6 Oracle PRMのデータレベルのセキュリティ設定
| 職責 | データレベルのセキュリティ | タイプ | 備考 |
|---|---|---|---|
|
Channel Executive Analyticsユーザー |
いいえ |
N/A |
N/A |
|
Channel Operations Analyticsユーザー |
いいえ |
N/A |
N/A |
|
Channel Account Manager Analyticsユーザー |
いいえ |
N/A |
N/A |
|
Channel Marketing Manager Analyticsユーザー |
いいえ |
N/A |
N/A |
|
Partner Executive Analyticsユーザー |
はい |
組織 |
表示されるレコードは、ユーザーの組織に一致する必要があります。 |
|
Partner Sales Manager Analyticsユーザー |
はい |
組織 |
表示されるレコードは、ユーザーの組織に一致する必要があります。 |
|
Partner Sales Rep Analyticsユーザー |
はい |
Position |
表示されるレコードは、ユーザーの役割に一致する必要があります。 |
|
Partner Service Manager Analyticsユーザー |
はい |
組織 |
表示されるレコードは、ユーザーの組織に一致する必要があります。 |
|
Partner Service Rep Analyticsユーザー |
はい |
Position |
表示されるレコードは、ユーザーの役割に一致する必要があります。 |
表7-7は、消費者部門の各ダッシュボードに関連付けられる消費者部門の職責を示しています。
OracleのCME製品ファミリー（Oracle Communications、Media and Energy Sales Analytics、Oracle Communications、Media and Energy Service Analytics、Oracle Communications、Media and Energy Marketing Analytics）では、Oracle Siebel基幹業務アプリケーションのセキュリティ・モデルが適用されます。つまり、Oracle Siebel基幹業務アプリケーションのオブジェクト（メタデータ・オブジェクトおよびPresentation Servicesオブジェクトの両方）へのアクセスの制御に、Oracle Siebel基幹業務アプリケーションの職責（および対応するリポジトリとPresentation Servicesグループ）が使用されます。このセキュリティ・モデルは、第7.1項「Oracle Business Intelligence Applicationsのセキュリティのタイプ」で説明しています。
表7-8に示しているように、基幹業務アプリケーションからの職責に加えて、Oracle Communications, Media, and Energy（CME）では、追加の職責と職責固有のセキュリティが使用されます。
表7-8 CMEの各ダッシュボードに関連付けられるCMEの職責
| CMEの職責 | CMEのダッシュボード | ダッシュボードのページ |
|---|---|---|
|
CM Marketing Analyticsユーザー CM Marketing Analytics管理者 |
ロイヤルティ管理 |
|
|
CM Sales Analyticsユーザー CM Sales Analytics管理者 |
売上管理 |
|
|
アカウント管理 |
|
|
|
CM Service Analyticsユーザー CM Service Analytics管理者 |
アカウント管理 |
|
次のアプリケーションが、Oracle Siebel基幹業務アプリケーションのセキュリティ・モデルに適用されます。
Financial Analytics製品ファミリー（Finance Sales Analytics、Finance Service Analytics、Finance Marketing Analytics、Finance Institutional Analytics、Finance Retail Analytics）
Insurance Analytics製品ファミリー（Oracle Insurance Partner Manager Analytics、Oracle Insurance Sales Analytics、Oracle Insurance Service Analytics、Oracle Insurance Marketing Analytics、Oracle Insurance Partner Manager Analytics）
Healthcare Analytics製品ファミリー（Oracle Healthcare Sales Analytics、Oracle Healthcare Service Analytics、Oracle Healthcare Marketing Analytics、Oracle Healthcare Partner Manager Analytics）
表7-9に示しているように、Siebel基幹業務アプリケーションからの職責に加えて、これらのアプリケーションでは、追加の職責と職責固有のセキュリティが使用されます。
Financial Services製品の場合、Oracle Siebel基幹業務アプリケーションのセキュリティ・モデルは次のように拡張されています。
Financial Analyticsユーザー
Financial Analyticsの会計固有オブジェクトへのアクセスを制御するためにOracle Siebel基幹業務アプリケーションの職責とグループとともに使用する必要がある、会計固有の職責（および対応するリポジトリとPresentation Servicesグループ）
Oracle Insurance Analytics製品ファミリー（Oracle Insurance Partner Manager Analytics、Oracle Insurance Sales Analytics、Oracle Insurance Service Analytics、Oracle Insurance Marketing Analytics、Oracle Insurance Partner Manager Analytics）のユーザー
InsuranceおよびHealthcare Analytics製品ファミリー（Oracle Healthcare Sales Analytics、Oracle Healthcare Service Analytics、Oracle Healthcare Marketing Analytics、Oracle Healthcare Partner Manager Analytics）の保険および健康保険固有オブジェクトへのアクセスを制御するために使用する必要がある、保険固有の職責（および対応するリポジトリとPresentation Servicesグループ）
たとえば、営業員にすべての水平方向のセールス職責を提供するときに会計職責のFinancial Analyticsユーザーも含めると、このユーザーは、すべての水平方向のセールス・オブジェクト（ダッシュボード、サブジェクトエリア、プレゼンテーション・レイヤーのフォルダなど）に加えて、会計固有のセールス・オブジェクトもすべて表示できるようになります。同様に、保険および健康保険固有のオブジェクトを表示するには、Oracle Insurance Analytics製品ファミリー（Oracle Insurance Partner Manager Analytics、Oracle Insurance Sales Analytics、Oracle Insurance Service Analytics、Oracle Insurance Marketing Analytics、Oracle Insurance Partner Manager Analytics）のユーザー職責のいずれかをこのユーザーに追加する必要があります。
Oracle Business Intelligenceではリポジトリ・グループの階層がサポートされます。Oracle Business Intelligenceリポジトリ内の特定のグループが、すべての子グループの動作を定義する親グループになります。Financial Services Analyticsの場合、親グループは次のとおりです。
Finance
会計アプリケーションのすべてのグループの親グループ。Financial Analyticsユーザーは、Financeグループの子グループです。
Insurance
保険アプリケーションのすべてのグループの親グループ。Insurance Analyticsユーザーは、Insuranceグループの子グループです。
親グループの権限は継承によって子グループに伝播されます。表7-9は、Financial Servicesの親グループとその目的を示しています。
|
注意: Financial Services Analyticsユーザーは、FinanceとInsuranceの両方の子として扱われます。そのため、このユーザーにはFinanceとInsuranceの両方に対するアクセス権があります。Financial Analyticsに加えてOracle Insurance Analytics製品ファミリー（Oracle Insurance Partner Manager Analytics、Oracle Insurance Sales Analytics、Oracle Insurance Service Analytics、Oracle Insurance Marketing Analytics、Oracle Insurance Partner Manager Analytics）のいずれかを購入した場合、すべての関連ダッシュボードを表示するには、Financial Services Analyticsユーザー職責を使用する必要があります。 |
表7-9は、追加の職責と、Oracle Financial Analytics製品ファミリー（Finance Sales Analytics、Finance Service Analytics、Finance Marketing Analytics、Finance Institutional Analytics、Finance Retail Analytics）、Oracle Insurance Analytics製品ファミリー（Oracle Insurance Partner Manager Analytics、Oracle Insurance Sales Analytics、Oracle Insurance Service Analytics、Oracle Insurance Marketing Analytics、Oracle Insurance Partner Manager Analytics）およびHealthcare Analytics製品ファミリー（Oracle Healthcare Sales Analytics、Oracle Healthcare Service Analytics、Oracle Healthcare Marketing Analytics、Oracle Healthcare Partner Manager Analytics）の職責固有のセキュリティを示しています。
Usage Acceleratorも配置する場合は、表7-11に示すFinancial Services固有のUsage Acceleratorの職責を参照してください。
表7-9 Financial Servicesのダッシュボードの表示に必要なFinancial Servicesの職責
| Financial Servicesの職責 | ダッシュボード |
|---|---|
|
Financial Analyticsユーザー |
クレジット |
|
クレジット・カード |
|
|
プライベートバンキング |
|
|
リテール金融 |
|
|
企業および商業金融 |
|
|
投資保有証券 |
|
|
別口勘定の管理 |
|
|
資産管理 |
|
|
法人営業 |
|
|
投資銀行 |
|
|
ファイナンスマーケティング |
|
|
ファイナンスエグゼクティブ |
|
|
いずれかのOracle Insurance Analytics製品ファミリー（Oracle Insurance Partner Manager Analytics、Oracle Insurance Sales Analytics、Oracle Insurance Service Analytics、Oracle Insurance Marketing Analytics、Oracle Insurance Partner Manager Analytics）のユーザー |
保険売上 |
|
保険サービス |
|
|
保険マーケティング |
|
|
保険エグゼクティブ |
|
|
保険クレーム |
|
|
健康保険プラン売上 |
|
|
健康保険プランサービス |
|
|
ヘルスプランマーケティング |
|
|
健康保険プランエグゼクティブ |
|
|
保険エージェント/代理店 |
Oracle Pharma Sales AnalyticsおよびOracle Pharma Marketing Analyticsのデータレベルのセキュリティは、PH Executive Analyticsを除くすべてのPharma Analytics職責のSiebel役割IDに基づいています。Siebel役割IDは、常に要素テーブルを使用して解決されます。
データの表示は、管理ロールに対しては制約されません。その他のロールに対しては役割IDによって制御されます。Oracle Business Analytics Warehouseでは、ユーザーの役割ベースのセキュリティ制御にテーブルW_POSITION_DHが使用されます。ユーザーには、各自の役割で利用可能なデータのみが表示されます。このセキュリティ・モデルは、次のような次元データのみを排他的に処理するクエリーを除く、すべてのクエリーに適用されます。
期間
製品
招待者状況
表7-10は、Pharma Analyticsの職責と機能を示しています。
表7-10 Pharma Analyticsの職責と機能
| 職責 | 使用 |
|---|---|
|
LS管理者 |
Pharma Analyticsのすべてのオプションに対する管理者権限。 |
|
PH Call Activity Analytics管理者 |
Call Activity Analyticsのオプションに対する管理者権限。 |
|
PH EMEA Call Activity Analyticsユーザー |
Pharmaサブジェクトエリアに対してPresentation Servicesで地域ベースの指標を使用できるようになります。 Analyticsリリース7.7では、すべてのレポート・カラムで役割ベースの階層が使用されます。これより前のリリースのレポート・カラムでは、アライメントベースのセールス階層が使用されていました。地域ベースのアライメントのページはすべてレポートから削除されています。そのため、地域ベースの役割階層を使用する場合は、代替階層を保持するようにレポートを再構成する必要があります。 |
|
PH EMEA Executive Analyticsユーザー |
Pharmaサブジェクトエリアに対してPresentation Servicesで地域ベースの指標を使用できるようになります。 Analyticsリリース7.7では、すべてのレポート・カラムで役割ベースの階層が使用されます。これより前のリリースのレポート・カラムでは、アライメントベースのセールス階層が使用されていました。地域ベースのアライメントのページはすべてレポートから削除されています。そのため、地域ベースの役割階層を使用する場合は、代替階層を保持するようにレポートを再構成する必要があります。 |
|
PH EMEA Marketing Analyticsユーザー |
Pharmaサブジェクトエリアに対してPresentation Servicesで地域ベースの指標を使用できるようになります。 Analyticsリリース7.7では、すべてのレポート・カラムで役割ベースの階層が使用されます。これより前のリリースのレポート・カラムでは、アライメントベースのセールス階層が使用されていました。地域ベースのアライメントのページはすべてレポートから削除されています。そのため、地域ベースの役割階層を使用する場合は、代替階層を保持するようにレポートを再構成する必要があります。 |
|
PH EMEA Sales Analyticsユーザー |
Pharmaサブジェクトエリアに対してPresentation Servicesで地域ベースの指標を使用できるようになります。 Analyticsリリース7.7では、すべてのレポート・カラムで役割ベースの階層が使用されます。これより前のリリースのレポート・カラムでは、アライメントベースのセールス階層が使用されていました。地域ベースのアライメントのページはすべてレポートから削除されています。そのため、地域ベースの役割階層を使用する場合は、代替階層を保持するようにレポートを再構成する必要があります。 |
|
PH Executive Analytics管理者 |
ZIPテリトリーに関するすべてのPharma Analyticsオプションへの無制限のアクセス。 |
|
PH Marketing Analytics管理者 |
Pharma ROI、訪問活動損益レポート、「製薬プロモーションの効果」サブジェクトエリアおよび「医学教育効果」サブジェクトエリアに対する管理者権限。 |
|
PH Medical Education Analytics管理者 |
Medical Education Analyticsのオプションに対する管理者権限。 |
|
PH Medical Education Analyticsユーザー |
Medical Education Analyticsのオプションへのアクセスを有効にします。 |
|
PH Disconnected Analytics管理者 |
PH Disconnected Manager AnalyticsユーザーおよびSales Rep Analyticsのダッシュボードに対する管理者権限。 |
|
PH Disconnected Analyticsユーザー |
Pharma Disconnected Analyticsのホームページを有効にします。これにより、Sales Rep Analyticsのオプションの一部として営業員ダッシュボードにアクセスできるようになります。 |
|
PH Disconnected Manager Analytics管理者 |
PH Disconnected Manager AnalyticsユーザーおよびDistrict Manager Analyticsのダッシュボードに対する管理者権限。 |
|
PH Disconnected Manager Analyticsユーザー |
Pharma Disconnected Analyticsのホームページを有効にします。これにより、Sales Rep Analyticsのオプションの一部として「地区管理者」ダッシュボードにアクセスできるようになります。 |
|
PH Sales Analytics管理者 |
Rx Sales Analyticsのオプションに対する管理者権限。 |
|
PH US Call Activity Analyticsユーザー |
Call Activity Analyticsのオプションにアクセスして、ZIPテリトリーのアライメントを実行できるようになります。 |
|
PH US Executive Analyticsユーザー |
ZIPベースのテリトリーに関するすべてのPharma Disconnected Analyticsオプションへの無制限のアクセス。 |
表7-11は、必要になる可能性のある追加のセキュリティ構成と、Oracle Usage Acceleratorアプリケーションのダッシュボードに関連付けられる特定の職責を示しています。
表7-11 Usage Acceleratorの職責とダッシュボード
| ユーザーの職責 | データ・レベルのセキュリティ | ダッシュボード名（ビュー） | ダッシュボードのページ |
|---|---|---|---|
|
Usage Accelerator – Sales Rep |
プライマリ役割データ・レベルのセキュリティ |
スコアカード |
個人スコアカード |
|
Usage Accelerator–Financial Services営業員 |
アクションプラン |
アカウントカバレッジ、コンタクトカバレッジ、商談カバレッジ、金融口座のカバレッジ—Financial Servicesのみ、アカウントの達成度、コンタクト達成度、商談の更新 |
|
|
Usage Accelerator–営業管理者 |
役割ベースのセキュリティなし |
スコアカード |
チームスコアカード、個人スコアカード |
|
アクションプラン |
アカウントカバレッジ（チーム）、コンタクトカバレッジ（チーム）、商談カバレッジ（チーム）、金融口座のカバレッジ（チーム）—Financial Servicesのみ、アカウントの達成度（チーム）、コンタクト達成度（チーム）、商談の更新（チーム） |
||
|
Usage Accelerator–Financial Services営業管理者 |
補償内容 |
アカウントカバレッジ、アカウントカバレッジ（チーム）、コンタクトカバレッジ、商談カバレッジ、金融口座のカバレッジ—Financial Servicesのみ |
|
|
達成度 |
アカウントの達成度、コンタクト達成度 |
||
|
商談の更新 |
商談の更新 |
||
|
ユーザー選定 |
有効なユーザー、アプリケーションの使用状況—Financial Servicesを除く、アプリケーションの使用状況—Financial Servicesのみ* |
||
|
Usage Accelerator–セールスエグゼクティブ |
役割ベースのセキュリティなし |
スコアカード |
組織スコアカード、個人スコアカード |
|
Usage Accelerator–Financial Servicesセールスエグゼクティブ |
アクションプラン |
アカウントカバレッジ（組織）、コンタクトカバレッジ（組織）、商談カバレッジ（組織）、金融口座のカバレッジ（組織）—Financial Servicesのみ、アカウントの達成度（組織）、コンタクト達成度（組織）、商談の更新（組織） |
|
|
Usage Accelerator – Administrator |
補償内容 |
アカウントカバレッジ、コンタクトカバレッジ、商談カバレッジ、金融口座のカバレッジ—Financial Servicesのみ |
|
|
Usage Accelerator–Financial Services管理者 |
達成度 |
アカウントの達成度、コンタクト達成度 |
|
|
商談の更新 |
商談の更新 |
||
|
ユーザー選定 |
有効なユーザー、アプリケーションの使用状況（Financial Servicesを除く）、アプリケーションの使用状況—Financial Servicesのみ アプリケーションの使用状況ダッシュボードの名前は同様に表示されますが、アプリケーションの使用状況—Financial Servicesのみのバージョンは、他のダッシュボードとは異なります。 |
この項では、チーム・ベースの表示について説明します。この項の内容は次のとおりです。
チーム・ベースの表示によって、Oracle Business Intelligenceユーザーは、ユーザーまたはユーザーの部下社員が属するチームに基づいて1つのエンティティ（商談など）のすべてのレコードにアクセスできるようになります。これは、Siebelトランザクション・アプリケーションに実装されているチームの表示モードによく似ています。
この項では、商談をエンティティの例として使用して、チーム・ベースの表示を実装する方法を示します。同じ概念を他のエンティティにも使用できます。
|
注意: このタイプのデータ・セキュリティは、デフォルトでインストールされているメタデータではサポートされません。この項で説明しているように、Oracle BI Applicationsでは、必要なETLマッピングの一部のみがInformaticaリポジトリに用意されています。この項の例では、デフォルトでは備わっていないメタデータをコード化し、アプリケーションに追加できる十分な情報が提供されています。 |
Siebelトランザクション・アプリケーションでは、ユーザーは「チーム」ビューで、自分がメンバーであるチームのレコードを表示できます。Oracle Business IntelligenceユーザーがOracle BI Application Data Warehouseにクエリーを実行する場合は、同様のビューが必要になります。この表示モードでは、ユーザー（またはこのユーザーにレポートする他のユーザー）が属するチームのレコードがクエリーによって返されます。
Oracle BI Applications管理者は、選択したエンティティに対応するフィルターが含まれる、チームベースの表示用の特別なグループを作成します。管理者は、この表示フィルターを適用する必要があるユーザーをこのグループに割り当てます。この構成により、関連付けられているエンティティに対してユーザーが発行するすべてのクエリーに表示フィルターが強制的に適用されるため、適切な行セットのみがユーザーに返されるようになります。
チームベースの表示の実装の設計には、Oracle Business Analytics Warehouseでポピュレートされる特別な表示モード・テーブルが必要です。これらのテーブルは、特別なETLマッピングによってポピュレートされ、分析クエリーのフィルター条件の定義に使用されます。
以降の項では、チーム・ベースの表示の実装が必要なエンティティの例として商談を使用します。同じ概念を他のエンティティにも使用できます。
W_PARTY_LOGINテーブル（出荷時のアプリケーションに含まれている）によって、すべてのエンティティに使用される役割階層情報がデコードされます。次の表に、W_PARTY_LOGINテーブルの構造を示します。
表7-12 W_PARTY_LOGINテーブルの構造
| カラム | 説明 |
|---|---|
|
PARTY_ID |
ユーザーのparty_id（役割）。 |
|
LOGIN |
親の役割のlogin_id（すべてのレベルの親を含む）。 |
|
PARTY_TYPE |
役割パーティ・タイプは'P'、組織パーティ・タイプは'O'、従業員パーティ・タイプは'E'。 |
このテーブルのトランザクション・ソースは、S_PARTY_RPT_RELです。position_idと、その親の任意のレベルのログインとの可能なペアはすべて、ETLの実行時にソース・テーブルから選択され、このテーブルに挿入されます。同じテーブルが他のパーティ・オブジェクト（組織など）の階層リレーションシップの格納に使用されています。このため、これらの異なるレコード・セットを区別するためにparty_typeカラムが追加されています。
各オブジェクトに関連付けられたチームのメンバー（役割）を格納するために、エンティティごとに1つのテーブルが必要です。次に商談の例を示します。次の表は、W_OPTY_PARTYテーブルの構造を示しています。
このテーブルのトランザクション・ソースは、S_OPTY_POSTNです。このテーブルの単位は、ソース・テーブルの単位と同じです。これらのテーブルとW_OPTY_D（表示フィルターに必要なOracle Business Analytics Warehouseのテーブル）のリレーションシップを次の図に示します。
|
注意: W_OPTY_D（表示に必要なエンティティのテーブル）とW_PARTY_LOGINテーブルのリレーションシップはM:Mです。そのため、前述の結合を使用するフィルターでは商談の行が重複して含まれることになるので、集計でエラーが発生します。 |
この問題を回避するために、パーティ・テーブルを事前結合して、重複した行をフィルターする必要があります。これら両方のテーブルが結合され、テーブルW_OPTY_LOGIN（出荷時のアプリケーションには含まれない）にOPTY_IDとLOGINの固有のセットが指定されます。次の表に、W_OPTY_LOGINテーブルの構造を示します。
これは、次のSQLを使用して実行されます。
SELECT W_PARTY_LOGIN.LOGIN, W_OPTY_PARTY.OPTY_ID
FROM W_PARTY_LOGIN, W_OPTY_PARTY
WHERE W_OPTY_PARTY.PARTY_ID = W_PARTY_LOGIN.PARTY_ID AND
W_PARTY_LOGIN.PARTY_TYPE = 'P' /*For only position records */
GROUP BY LOGIN, OPTY_ID
W_OPTY_DテーブルとW_OPTY_LOGINテーブルのリレーションシップは1対多であるため、フィルターに使用できます。次の図に、これを示します。
その他の次元（または要素）のチーム表示モードのセキュリティをサポートするには、同様の交差テーブルを作成する必要があります。必要に応じて、W_OPTY_LOGINと同様の方法で次のいずれか（または複数）のテーブルを作成する必要があります。
W_ACT_LOGIN（活動の場合）
W_CON_LOGIN（担当者の場合）
W_HHOLD_LOGIN（世帯の場合）
W_ORDER_LOGIN（オーダーの場合）
W_ORG_LOGIN（口座の場合）
W_PROG_LOGIN（プログラムの場合）
W_QUOTE_LOGIN（見積りの場合）
W_RESP_LOGIN（応答の場合）
W_SEG_LOGIN（セグメントの場合）
W_SR_LOGIN（サービスリクエストの場合）
対応するマッピングを作成できるように、これらのテーブルを、DACリポジトリ（カスタム・コンテナの下）とETLリポジトリの両方に作成する必要があります。
W_OPTY_LOGINテーブルを使用して、W_OPTY_Dのデータを保護する方法を示しました。チームの表示モードを使用して要素テーブルW_REVN_Fを保護する場合は、次のいずれかのオプションを選択できます。
Opportunity Dimension (Dim – Opportunity).Loginフィールドを使用して、"Fact – Revenue"にフィルターを定義します。この場合、すべての収益レポートは、グループのそのテーブルから句によって選択されているフィールドがない場合でも、商談次元に結合されます。
W_OPTY_LOGINを使用して、収益要素（Fact – Revenue）に直接フィルターを作成します。ただし、この場合、OPTY_IDをW_REVN_Fに追加する必要があるため、W_OPTY_LOGINに直接結合できます。
この項では、ETLの設計について説明します。
データ・モデルの項で説明したテーブルにポピュレートするには、ETLルーチンのセットを使用します。標準のアプリケーションには、次のテーブルにポピュレートするための表示マッピングがあります。
共通のパーティ・ログイン・テーブル:
W_PARTY_LOGIN
エンティティ・パーティのテーブル:
W_OPTY_PARTY（商談の場合）
W_ACT_PARTY（活動の場合）
W_CON_PARTY（担当者の場合）
W_HHOLD_PARTY（世帯の場合）
W_ORDER_PARTY（オーダーの場合）
W_ORG_PARTY（口座の場合）
W_PROG_PARTY（プログラムの場合）
W_QUOTE_PARTY（見積りの場合）
W_RESP_PARTY（応答の場合）
W_SEG_PARTY（セグメントの場合）
W_SR_PARTY（サービスリクエストの場合）
これらのテーブルのポピュレートに使用する標準のETLマッピングを次に示します。これらのマッピングはInformaticaリポジトリにあります。
VisibilityAccountParty
VisibilityActivityParty
VisibilityContactParty
VisibilityHouseHoldParty
VisibilityOpportunityParty
VisibilityOrderParty
VisibilityProgramParty
VisibilityQuoteParty
VisibilityResponseParty
VisibilitySegmentParty
VisibilityServiceRequestParty
VisibilityPartyLogin
チームから役割が削除された場合は、これらのテーブル内のレコードを削除する必要があります。これは、対応するソース・テーブルで削除を追跡し、削除された行の情報を使用して実行する必要があります。削除されたすべての行を、ターゲット・テーブルからETLプロセスによって削除する必要があります。
行を削除するマッピングはInformaticaリポジトリにあり、次のとおりです。
VisibilityAccountParty_LoadDeletedRows
VisibilityActivityParty_LoadDeletedRows
VisibilityContactParty_LoadDeletedRows
VisibilityHouseHoldParty_LoadDeletedRows
VisibilityOpportunityParty_LoadDeletedRows
VisibilityOrderParty_LoadDeletedRows
VisibilityProgramParty_LoadDeletedRows
VisibilityQuoteParty_LoadDeletedRows
VisibilityResponseParty_LoadDeletedRows
VisibilitySegmentParty_LoadDeletedRows
W_<エンティティ>_LOGINにポピュレートするETLマッピングは標準のOracle Business Intelligence Applicationsには用意されていませんが、データ・モデルの項に示したSQLを使用して簡単に作成できます。
イメージ・テーブルによっては、OLTPデータの変更時に自動更新する必要があるものがあります。この場合、次に示すようにいつくかのトリガーを有効にする必要があります。
Applications Data Warehouseでは、事前設定された表示モード・テーブルはデフォルトでアクティブになっています。所属する組織でいずれの表示関連のデータ・ウェアハウス・テーブルも使用しない場合は、DACクライアントの「Design」ビューの「Tables/Related Tables」画面でこれらのテーブルを非アクティブ化する必要があります。チームの表示モードを有効にするためにこれらのテーブルをアクティブのままにしておく場合は、オプションのテーブルにも削除トリガーを作成する必要があります。
Data Warehouse Configuratorを使用して削除トリガーを作成する場合、削除トリガーを有効にするオプションのテーブルを含めることを選択できます。また、トリガー文を直接実行することも、ファイルに書き込んでデータベース管理者に実行してもらうこともできます。
削除トリガーを作成するには:
DACメニュー・バーで、「Tools」→「ETL Management」→「Configure」を選択します。
「Create Delete Triggers in Transaction Database」チェック・ボックスを選択します。
「Delete Triggers」タブがアクティブになります。
「Create Triggers」を選択します。
トリガーを作成するトランザクション・データベースを選択します。
（オプション）「Include optional triggers」チェック・ボックスを選択し、オプションのテーブルを含めます。
「Start」をクリックします。
前述の表示モード・テーブルおよび対応するタスクはすべて、DACメタデータにすでにインポートされています。これらのテーブルをOLTPテーブル（削除の場合）と同期化するためのタスクもすべて自動的に追加されます。これらの各テーブル（W_OPTY_LOGINなど）は、対応する要素テーブル（この場合はW_OPTY_D）の関連テーブルとしてリストされます。要素をサブジェクトエリアに追加する場合、これらのタスクは実行プランに自動的に追加されます。その他の交差テーブル（W_OPTY_LOGINなど）の場合、これらのテーブルはすでにDACで作成したと見なされるため、次の手順を実行して、実行プランに追加し、ETLの実行時にポピュレートされるようにする必要があります。
これらのテーブルにポピュレートするためのETLワークフローをタスク・リストにインポートします。
各テーブルを関連テーブルとして対応する要素または次元に追加します。
前述の表示モード・テーブルおよび対応するタスクはすべて、DACメタデータにすでにインポートされています。これらのテーブルをOLTPテーブル（削除の場合）と同期化するためのタスクもすべて自動的に追加されます。これらの各テーブル（W_OPTY_LOGINなど）は、対応する要素テーブル（この場合はW_OPTY_D）の関連テーブルとしてリストされます。要素をサブジェクトエリアに追加する場合、これらのタスクは実行プランに自動的に追加されます。その他の交差テーブル（W_OPTY_LOGINなど）の場合、これらのテーブルはすでにDACで作成したと見なされるため、次の手順を実行して、実行プランに追加し、ETLの実行時にポピュレートされるようにする必要があります。
これらのテーブルにポピュレートするためのETLワークフローをタスク・リストにインポートします。
各テーブルを関連テーブルとして対応する要素または次元に追加します。
Oracle Business Intelligence Applicationsで提供されるメタデータでは、プライマリ役割ベースのセキュリティが、セキュリティ・グループPrimary Employee/Position Hierarchy-based Securityを使用して実装されます。このタイプのセキュリティをユーザーに適用するには、（OLTPの）1つ以上のユーザーの職責をこのグループに追加する必要があります。これは、Oracle BI Applicationsリリース7.9.0、7.9.1および7.9.2で実行していたもの、およびリリース7.9の『Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド』の「Oracle BI Applicationsの統合セキュリティ」で説明されているものとは異なります。このセキュリティ・グループは、レコード（要素または次元）のプライマリ役割所有者とW_POSITION_DHに格納されている役割階層に基づいています。
チームベースのセキュリティは、前述のW_<エンティティ>_LOGINテーブルに基づいています。チームベースのセキュリティを有効にするには、いくつかのメタデータ要素を追加して、いくつかの標準要素を変更する必要があります。
チームベースのセキュリティを有効にするには:
「Physical」レイヤーで、次の手順を実行します。
物理レイヤーに、新しいW_<エンティティ>_LOGINテーブルをインポートします。
テーブルW_<エンティティ>_LOGINを、対応する次元または要素に結合します。たとえば、W_OPTY_LOGINをW_OPTY_Dに結合します。
「Logical」レイヤーで、次の手順を実行します。
保護するテーブルが次元の場合、対応する次元の論理テーブルソースにW_<エンティティ>_LOGINテーブルを追加します。
保護するテーブルが要素の場合、W_<エンティティ>_LOGINテーブルに基づいて新しい論理次元を作成します。たとえば、Dim – Team Security（商談）を作成します。
論理レイヤーにLOGINカラムを論理カラムとして配置します。
セキュリティ・フィルターについて、次の手順を実行します。
チームベースのセキュリティの新しいユーザー・グループを作成します（Team Position Based Securityなど）。
チームベースの表示のセキュリティ・フィルターを適用するユーザーは、ユーザーの職責のうち少なくとも1つをこのグループの一部として持つ必要があります。グループ名をダブルクリックし、「追加/削除」ボタンをクリックすることによって、グループに職責を追加できます。
要素テーブルまたは次元テーブルそれぞれにフィルターを作成します。次のスクリーンショットは、「ユーザー/グループの役割」ダイアログの「フィルター」タブを示しています。ここでは、要素テーブルと次元テーブルの両方にフィルターが指定されています。
このTeam Visibilityグループのメンバーであるユーザーは、既存のPrimary Employee/Position Hierarchy-based Securityのメンバーであってはいけません。後者のグループのフィルターはより制限的であり、2つのフィルターは1つのOR条件でグループ化されるため、後者のグループのフィルターではデータセットには何も追加されません。
Siebel CRMアプリケーションでは、ユーザーは、「ユーザー設定」/「役割の変更」画面の「役割の変更」ボタンをクリックすることによって同じセッション中に新しい役割を担うことができます。この画面でユーザーは、「従業員/役割」画面ですでに自分に関連付けられている一連の役割から選択できます。現在、ユーザーがOLTPアプリケーションで役割を変更する場合、Oracle Business Intelligenceの埋込みレポートのデータは、引き続きプライマリ役割によってフィルターされ、選択した新しい役割でフィルターされることはありません。この項では、ユーザーが新しい役割を使用してOLTPアプリケーションからOracle Business Intelligenceのダッシュボードにシームレスに接続し、この別の役割で表示可能なすべてのデータを表示できるようにする方法について説明します。この場合のデータ・セキュリティでは、新しい役割のプライマリ所有者のログインでフィルターが実行されます。
この拡張機能では、次の手順を実行する必要があります。
Oracle Business Intelligence Enterprise Edition環境で、RunAsオプションを設定します。
この手順は、『Oracle Business Intelligence Presentation Services管理ガイド』の第8章の「代理ユーザーの承認について」で説明しています。このドキュメントは、次のアドレスから入手可能です。
http://www.oracle.com/technology/documentation/bi_ee.html
この機能によって、ユーザーは、プロキシ（偽名を使用するユーザー）とターゲット・ユーザーおよびそのログインをリストしているテーブルに基づいて、他のOracle Business Intelligenceユーザーの名前を使用できます。この情報は、物理テーブルに格納することも、S_PARTY_PERの役割間の関連付けを使用して動的にポピュレートされるビューに格納することもできます。このビューの定義は、インストール・ディレクトリ（\\installdirectory\EmbeddedAnaltyics\Proxy_View.sql）にあります。
新しい役割とOracle BIサーバーが通信するように、Siebel CRMアプリケーションを構成します。
この手順では、実行しているSiebel CRMアプリケーション（Universal Agent、Marketingなど）に2つの新しい機能を追加する必要があります。これらの機能の目的は、次のとおりです。
「役割の変更」ボタンによって選択した新しい役割の取得
新しい役割のプライマリ従業員のログインの検索
このログインを新しいセッション変数ActPosLoginに渡す
これらのレコードが格納されているsifファイルは、インストール・ディレクトリにあります。これらのsifファイルを（Siebel Toolsを使用して）Siebel Repositoryにインポートし、対応するプロジェクトをsrfファイルに再コンパイルする必要があります。sifファイルは、eScript（\\installdirectory\EmbeddedAnalytics\EScript）およびVB Script（\\installdirectory\EmbeddedAnalytics\VB Script）で利用できます。いずれかを適宜選択して使用できます。使用しているアプリケーションがSiebel Universal Agentではない場合、独自のアプリケーションに同様のレコードをSiebel Toolsで直接作成できます。次の手順を実行する必要があります。
Siebel Toolsで、「詳細」→「アプリケーション」→<使用しているアプリケーション>→「アプリケーション・サーバー・スクリプト」に移動します。
\\installdirectory\EmbeddedAnalytics（EscriptおよびVB Scriptディレクトリの下）にあるサンプル・ファイルに定義されているように、Application_Startという新しいスクリプトを作成します。
既存の埋込みダッシュボードに新しいシンボリックURLパラメータを追加します。
この最後の手順では、各埋込みダッシュボードの「シンボリックURL」画面に新しいパラメータを追加します。新しいパラメータはRUNASといいます。
OLTPアプリケーションで、「統合管理」→「シンボリックURL」に移動します。
「シンボリックURL管理」を選択します。
この新しい機能でサポートするダッシュボードを検索します。
次のように、「パラメータ」でRUNASという新しいパラメータを追加します。
i. ArgType: プロファイル属性
ii. ArgumentValue: ActPosLogin
RUNASパラメータは最初の段落で説明したプロキシ機能に必要であり、ActPosLoginは、2つ目の段落でSiebel Repositoryに追加した新しいメタデータによって追加、ポピュレートされる新しい変数です。
ビジネス単位のセキュリティは、Primary Org-Based Securityという名前のセキュリティ・グループによってサポートされます。デフォルトでインストールした場合、コア、Workforce Analyticsおよび売上予想のビジネス・モデルのいくつかの次元のみがこのデータ・セキュリティ・タイプに対応します。他の要素および次元は、それらのカラムVIS_PR_BU_IDがポピュレートされている場合に、このセキュリティ・グループに追加できます。
このセキュリティ・グループのセキュリティ・フィルターは、次のように定義されます。
"Core"."Dim - Order"."VIS_PR_BU_ID" = VALUEOF(NQ_SESSION."ORGANIZATION")
セッション変数ORGANIZATIONは行方向の変数で、初期化ブロックOrgs for Org-Based Securityを使用して初期化されます。この初期化ブロックによって、Siebel OLTPデータソースに対して次のSQLが実行され、ORGANIZATION変数がポピュレートされます。
select distinct 'ORGANIZATION', PRR.SUB_PARTY_ID
from VALUEOF(TBO).S_POSTN P, VALUEOF(TBO).S_USER U, VALUEOF(TBO).S_PARTY_PER PP, VALUEOF(TBO).S_PARTY_RPT_REL PRR
where U.ROW_ID=PP.PERSON_ID and P.ROW_ID=PP.PARTY_ID and PRR.PARTY_ID = P.BU_ID and PRR.PARTY_TYPE_CD = 'Organization' and U.LOGIN = ':USER'
プライマリ所有者のセキュリティは、Primary Owner-Based Securityという名前のセキュリティ・グループによってサポートされます。このタイプのセキュリティ・メカニズムでは、レコードはそのプライマリ所有者しか表示できません。デフォルトでインストールした場合、このタイプのセキュリティはコア・ビジネス・モデルのいくつかの次元に対応しますが、他のテーブルは、プライマリ所有者のソースの「統合 ID」カラムがある場合に追加できます。
このセキュリティ・グループのセキュリティ・フィルターは、次のように定義されます。
"Core"."Dim - Activity"."VIS_PR_OWN_ID" = VALUEOF(NQ_SESSION."PR_OWNER_ID")
セッション変数PR_OWNER_IDは単一値の変数であり、初期化ブロックPrimary Owner IDによってポピュレートされます。この初期化ブロックによって、Siebel OLTPデータソースに対して次のSQLが実行され、この変数がポピュレートされます。
select PAR_ROW_ID
from VALUEOF(TBO).S_USER
where LOGIN = ':USER'
この項では、Oracle BI Applicationsのデータレベルのセキュリティ機能について説明します。この項の内容は次のとおりです。
データレベルのセキュリティでは、OLTPアプリケーション（Oracle E-Business Suite、Siebel（CRM）、PeopleSoftなど）でユーザーがレポート内でアクセス可能なデータが定義されます。2人の異なるユーザーによって実行された場合、同じレポートでも異なるデータが表示される場合があります。これは、基幹業務アプリケーションの「商談（個人）」ビューで、異なるユーザーに異なるデータが表示されるしくみと似ています。ただし、レポートの構造はすべてのユーザーに対して同じです（ユーザーがレポート内の特定のカラムにアクセスできない場合を除きます。この場合、そのカラムはこのユーザーには表示されません）。別の例として、Vision USAの調達管理者は、米国内で発生する調達の詳細のみを表示できます（この組織が地理的なテリトリーを基に調達組織の境界を明確に設定していることが前提です）。同様に、アジア太平洋の調達管理者は、アジア太平洋地域の調達データのみを表示できます。
これらの管理者が"Procurement Manager"（調達管理者）グループに属している場合でも、2人に表示される実際のデータは各自のアクセス制御によって異なります。これは重要な要件であり、すべての基幹（HCM、SCM、FII、CRMなど）にあてはまります。
Siebel Analyticsの初期リリース以降では、次のタイプのデータ・セキュリティがソリューションでサポートされていました。
Siebel CRMアプリケーションのプライマリ役割ベースのセキュリティ。
Siebel CRMアプリケーションのプライマリ所有者ベースのセキュリティ。
Siebel CRMアプリケーションのビジネス単位ベースのセキュリティ。
リリース7.9.0のOracle BI Applicationsでは、次のタイプのデータ・セキュリティが導入されました。
Oracle EBSの営業単位組織ベースのセキュリティ。
Oracle EBSの在庫組織ベースのセキュリティ。
Siebel CRM Applicationsの役割ベースのセキュリティは、緩やかに変化する役割階層およびAS IS/AS WASタイプの分析をサポートするように拡張されました。
リリース7.9.3のOracle BI Applicationsでは、次のように機能が拡張されました。
EBS、PeopleSoft FinancialsおよびPeopleSoft HCMの会社組織ベースのセキュリティ。
EBSのビジネス・グループ組織ベースのセキュリティ。
PeopleSoft FinancialsおよびPeopleSoft HCMの営業単位組織ベースのセキュリティ。
PeopleSoft FinancialsおよびPeopleSoft HCMのセットIDベースのセキュリティ。
リリース7.9.4のOracle BI Applicationsでは、会社組織ベースのセキュリティが次のものに置き換えられました。
EBS、PeopleSoft FinancialsおよびPeopleSoft HCMの元帳セキュリティ。
次のデータ・セキュリティ・タイプはサポートされていませんが、将来のリリースには含まれる予定です。
総勘定元帳フレックス・フィールド（EBS用）
次に、これらのセキュリティ・グループと、Oracle Business Intelligence Enterprise Edition Applicationのリリースが異なれば、これらのセキュリティ・グループによってサポートされるソース・アプリケーションも異なることを示す概要チャートを示します。インストール時および構成時に、顧客は適切なセキュリティ・グループと初期化ブロックが各ソースおよび各リリースに対して設定されていることを確認する必要があります。次に示すソースとリリースのマトリックスから外れているセキュリティ・グループは、それに対応する初期化ブロックとともに無効にする必要があります。セキュリティ・グループとその初期化ブロックの詳細は、このチャートの次の部分で説明しています。
表7-15 Oracle Business Intelligence Applicationsの異なるリリースによってサポートされるセキュリティ・グループとソース・アプリケーションの概要
| Oracle EBS | PeopleSoft Financials | PeopleSoft HR | Siebel | |
|---|---|---|---|---|
|
Operating Unit Org-based Security |
7.9以降でサポート |
7.9以降でサポート |
7.5以降でサポート |
|
|
Inventory Org-based Security |
7.9以降でサポート |
|||
|
Company Org-based Security |
7.9.3でサポート、7.9.4で廃止 |
7.9.3でサポート |
7.9.3でサポート |
|
|
Business Group Org-based Security |
7.9.3以降でサポート |
|||
|
HR Org-based Security |
7.9.3以降でサポート |
|||
|
Payables Org-based Security |
7.9.3以降でサポート |
|||
|
Receivables Org-based Security |
7.9.3以降でサポート |
|||
|
SET ID-based security |
7.9.3以降でサポート |
7.9.3以降でサポート |
||
|
Position-based security |
HRMSに対して7.9.4以降でサポート |
7.9.3以降でサポート |
7.5以降でサポート |
|
|
Ledger-based security |
7.9.4以降でサポート |
7.9.4以降でサポート |
Oracle BI Applicationsのデータレベルのセキュリティは、次の3つの主な手順で実装されます。
ユーザーのログイン時に組織階層内のユーザーの階層レベルやユーザーの職責などの特定のセキュリティ関連情報を取得する、初期化ブロックを設定します。
第7.6.3項「Oracle BI Applicationsのセキュリティに使用する初期化ブロック」を参照してください。
メタデータの物理レイヤーと論理レイヤーの該当するセキュリティ・テーブルに結合を設定します。
保護する必要のある各論理テーブルのセキュリティ・グループごとにフィルターを設定します。
従業員/役割ベースのセキュリティについては、第7.5.1項「プライマリ役割ベースのセキュリティ」、組織ベースのセキュリティについては、第7.2項「Oracle E-Business Suiteとのデータ・セキュリティの統合」および第7.3項「Oracle PeopleSoft Enterprise Applicationsとのデータ・セキュリティの統合」を参照してください。
次に示すように、Oracle Business Intelligenceリポジトリの初期化ブロックは、指定されたユーザーのプライマリ役割、プライマリ組織および所有者IDを取得するように設定されます。
Authorization
この初期化ブロックは、ユーザーを、ユーザーが属するすべてのセキュリティ・グループに関連付けるために使用します。この初期化ブロックでは、ユーザーの職責またはロールをソースOLTPアプリケーションから取得し、Oracle BI Applicationsのセキュリティ・グループと照合して、セッション時にユーザーに適用されるオブジェクト・セキュリティを決定します。この初期化ブロックによって、GROUPという変数セットがポピュレートされます。
Business Groups
この初期化ブロックは、対応するログイン職責からアクセスできるビジネス・グループを、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、BUSINESS_GROUPという変数セットがポピュレートされます。この変数セットは、ビジネス・グループ組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
Companies
この初期化ブロックは、対応するログイン職責からアクセスできる企業を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、COMPANYという変数セットがポピュレートされます。この変数セットは、会社組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
HR Organizations
この初期化ブロックは、対応するログイン・ユーザーからアクセスできるHR組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、HR_ORGという変数セットがポピュレートされます。この変数セットは、HRアナリストのセキュリティ権限の実施に使用されます。
Inventory Organizations
この初期化ブロックは、対応するログイン職責からアクセスできる在庫組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、INV_ORGという変数セットがポピュレートされます。この変数セットは、在庫組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
Ledgers
この初期化ブロックは、対応するログイン職責からアクセスできる元帳を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、LEDGERという変数セットがポピュレートされます。この変数セットは、元帳ベースのセキュリティのセキュリティ権限の実施に使用されます。
Operating Unit Organizations
この初期化ブロックは、対応するログイン職責からアクセスできる営業単位組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、OU_ORGという変数セットがポピュレートされます。この変数セットは、営業単位組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
Orgs for Org-Based Security
この初期化ブロックは、現在のユーザーのビジネス単位に対する組織のレポートを、Siebel CRM OLTPアプリケーションから取得するために使用します。
この初期化ブロックによって、ORGANIZATIONという変数セットがポピュレートされます。この変数セットは、プライマリ組織ベースのセキュリティの実施に使用されます。
Payable Organizations
この初期化ブロックは、対応するログイン職責からアクセスできる買掛勘定組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、PAYABLE_ORGという変数セットがポピュレートされます。この変数セットは、買掛勘定組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
Primary Owner ID
この初期化ブロックは、指定されたユーザーの所有者IDを取得します。この初期化ブロックによって、Siebel OLTPから情報が取得され、PR_OWNER_ID変数がポピュレートされます。
Receivable Organizations
この初期化ブロックは、対応するログイン職責からアクセスできる買掛勘定組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、PAYABLE_ORGという変数セットがポピュレートされます。この変数セットは、買掛勘定組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
Set ID
この初期化ブロックは、対応するログイン職責からアクセスできるセットIDを、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、SET_IDという変数セットがポピュレートされます。この変数セットは、セットIDベースのセキュリティのセキュリティ権限の実施に使用されます。
User Hierarchy Level
この初期化ブロックは、ユーザーのログインに基づいて、指定されたユーザーの固定階層レベルをW_POSITION_DHから取得します。これによって変数HIER_LEVELがポピュレートされます。このブロックで使用されるSQLは、データ・ウェアハウスに対して実行されます。このため、ここではこのテーブル（W_POSITION_DH）がポピュレートされた前回のETL実行時の階層レベルが反映されます。
User HR Organizations
この初期化ブロックは、現在のユーザーが属する現在のHR組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、USER_HR_ORGという変数がポピュレートされます。
次の表に、Oracle Business Intelligence Applicationsで使用されるセキュリティ・グループと、それらのセキュリティ・グループが適用されるアプリケーションを示します。一部のセキュリティ・グループの名前は職責（Siebel CRMアプリケーションおよびOracle EBSアプリケーションの場合）またはロール（PeopleSoftアプリケーションの場合）と同じで、これらのいずれかのセキュリティ・グループのメンバーとして追加されています。ソース・アプリケーションでこれらの職責またはロールのいずれかを持つユーザーは、Analyticsアプリケーションへのログイン時、自動的に対応するデータ・セキュリティ・グループのメンバーとなります。ソース・アプリケーションの同様のオブジェクトに基づくその他のセキュリティ・グループは、対応するデータ・フィルターを追加のユーザー・グループに適用する必要がある場合に、Analyticsリポジトリに追加して、これらのデータ・セキュリティ・グループに追加できます。
表7-16 Oracle BI Applicationsのデータ・セキュリティ・グループ
| セキュリティ・グループ名 | アプリケーション | 説明 |
|---|---|---|
|
Business Group Org-based Security |
Oracle E-Business Suite |
ビジネス・グループは組織構造の最上位レベルであり、通常は、企業全体または主要部署を表すために使用します。1つのビジネス・グループで複数の帳簿セットを使用できます。 |
|
Company Org-based Security |
PeopleSoft |
会社組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられている総勘定元帳ビジネス単位に基づいてデータがフィルターされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
|
HR Org-based Security |
PeopleSoft |
HR組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられているHRビジネス単位に基づいてデータがフィルターされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
|
Human Resources Analyst |
PeopleSoft |
HRアナリストには、特別な表示要件があります。HRアナリストは、組織内部のすべての担当データと、HRアナリスト自身の組織内の部下社員のデータを確認する必要があります。これは、この要件に対処するための特別なセキュリティ・グループです。 |
|
Operating Unit Org-based Security |
Oracle E-Business Suite |
月次および年次の会計レポートは、1つの法人にのみ属することができる営業単位によって作成されます。営業単位のセキュリティは、セキュリティ・プロファイルをユーザーのIDまたは職責に関連付けることによって確保されます。つまりセキュリティ・プロファイルは、ユーザーのIDまたは職責にアクセスできる組織階層に関連付けられます。営業単位組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられている営業単位に基づいてデータがフィルターされます。 |
|
Payables Org-based Security |
PeopleSoft |
買掛勘定組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられている買掛勘定ビジネス単位に基づいてデータがフィルターされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
|
Primary Employee/Position Hierarchy-based Security |
該当なし |
従業員/役割ベースのセキュリティでは、レコード所有者と、レコード所有者の階層チェーン内でレコード所有者より上位の従業員のみがレコードを表示できます。 |
|
Primary Org-Based Security |
Siebel CRM |
ログイン・ユーザーに関連付けられている組織に基づいてデータがフィルターされます。 |
|
Primary Owner-Based Security |
Siebel CRM |
ログイン・ユーザーに基づいてデータがフィルターされます。 |
|
Primary Position-Based Security（廃止） |
該当なし |
新しいPrimary Employee/Position Hierarchy-based Securityを使用してください。 |
|
Receivables Org-based Security |
PeopleSoft |
売掛勘定組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられている売掛勘定ビジネス単位に基づいてデータがフィルターされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
|
SET ID-based Security |
PeopleSoft |
セットIDベースのセキュリティでは、ログイン・ユーザーに関連付けられているセットIDに基づいてデータがフィルターされます。 |
|
Inventory Org-based Security |
Oracle E-Business Suite |
在庫組織によって在庫のトランザクションと残高が追跡され、製品またはコンポーネントが製造または配布されることもあります。在庫組織ベースのセキュリティでは、ログイン・ユーザーに関連付けられている在庫組織に基づいてデータがフィルターされます。 |
|
Ledger-based Security |
Oracle E-Business Suite |
元帳は基本的に、共通の勘定体系、機能通貨、会計カレンダーおよび会計処理基準を使用するレポート組織になります。元帳ベースのセキュリティでは、ログイン・ユーザーに関連付けられている元帳に基づいてデータがフィルターされます。 |
