この項では、Oracle Business Intelligence Applicationsのセキュリティ機能について説明します。次の主項目が含まれます。
第2.7項「Oracle PeopleSoft Enterprise Applicationsのデータ・セキュリティの統合」
第2.9項「Oracle JD Edwards EnterpriseOneまたはJD Edwards Worldとのセキュリティの統合について」
この項は、次の項目を含んでいます。
第2.1.1項「Oracle Business Enterprise EditionとOracle BI Applicationsのセキュリティの統合について」
第2.1.5項「Oracle Business Intelligenceのプレゼンテーション・サービスのカタログ権限の管理について」
Oracle BI Applicationsでは、Oracle Business Intelligence Enterprise Editionおよび業務系ソース・システムのセキュリティ・モデルとの強力な統合により、適切なユーザーに適切なコンテンツを表示できるようになります。
Oracle BI Applicationsの使用を開始する前に、Oracle Business Intelligence Enterprise Editionのセキュリティ機能を完全に熟知する必要があります。
Oracle Business Intelligence Enterprise Editionのセキュリティ設定は、次のOracle Business Intelligenceコンポーネントで行われます。
Oracle BI管理ツールを使用してビジネス・モデル、表、列およびサブジェクトエリアの権限の設定、データ・アクセシビリティを制限するフィルタの指定、認証オプションの設定などのタスクを実行できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Oracle BIプレゼンテーション・サービス管理を使用して、プレゼンテーション・カタログのオブジェクト(ダッシュボード、ダッシュボード・ページなど)に対する権限の設定などのタスクを実行できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
Oracle Enterprise Manager Fusion Middleware Control
Fusion Middleware Controlを使用して、ポリシー・ストア、アプリケーション・ロールおよび権限を管理し、機能アクセスを決定できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
Oracle WebLogic Server管理コンソール
管理コンソールを使用すると、組込みOracle WebLogic ServerのLDAPでユーザーおよびグループを管理できます。管理コンソールを使用すると、セキュリティの領域を管理し、代替の認証プロバイダを構成することもできます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
Oracle Business Intelligence Enterprise Editionでは、ユーザーは、その名前ではなく、グローバル一意識別子(GUID)によって認識されます。GUIDは、特定のユーザーに対する完全に一意な識別子です。ユーザーの識別にGUIDを使用することにより、ユーザー名とは無関係に、データおよびメタデータを特定のユーザーに対して一意的に保護できるため、より高度なセキュリティが提供されます。
次の2つのベスト・プラクティスを実践して、開発から本番までのライフサイクルの各フェーズでGUIDが一貫して適用されることを保証することをお薦めします。
開発システム、テスト・システムおよび本番システムの間でアイデンティティ・ストアのファンアウト・レプリカを使用するようにして、開発から本番までのライフサイクル全体を通じてユーザーGUIDを一貫して同一にします。
可能なかぎり、個々のユーザーではなくアプリケーション・ロールを使用して、データとメタデータへのアクセスを保護します。
Oracle Business Intelligence Enterprise Editionテスト・サーバーがテストLDAPに対して構成されていて、かつ本番サーバーが企業LDAPに対して構成されているが、テストLDAPが企業LDAPディレクトリのファンアウト・コピーでない場合、システムを正常に動作するためにLDAP GUIDのリフレッシュが必要であることに注意してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のユーザーGUIDの再生成に関する項を参照してください。
Oracle BI Applicationsのセキュリティは、大きく次の3つのレベルに分類できます。
ユーザーレベルのセキュリティ(ユーザーの認証)。ユーザーレベルのセキュリティでは、提供された資格証明に基づいてユーザーのIDが認証および確認されます。詳細は、第2.4項「Oracle BI Applicationsのユーザーレベルのセキュリティ」を参照してください。
オブジェクトレベルのセキュリティ。オブジェクトレベルのセキュリティは、ユーザーのロールに基づいて、ビジネス論理オブジェクトの表示を制御します。プレゼンテーション・カタログで定義されるメタデータ・リポジトリ・オブジェクト(ビジネス・モデル、サブジェクトエリアなど)およびWebオブジェクト(ダッシュボード、ダッシュボード・ページなど)に対してオブジェクトレベルのセキュリティを設定できます。詳細は、第2.3項「Oracle BI Applicationsのオブジェクトレベルのセキュリティ」を参照してください。
データレベルのセキュリティ。データレベルのセキュリティでは、トランザクション・システム内のデータに対するユーザーの対応付けに基づいて、データ(サブジェクトエリア、ダッシュボード、Oracle BI Answersなどにレンダリングされるコンテンツ)の表示が制御されます。詳細は、第2.2項「Oracle BI Applicationsのデータレベルのセキュリティ」を参照してください。
オブジェクトレベルおよびデータレベルのセキュリティは、アプリケーション・ロールを使用してOracle BI Applicationsに実装されます。アプリケーション・ロールは、ユーザーまたはグループに付与される一連の権限を定義します。アプリケーション・ロールは、Oracle Enterprise Manager Fusion Middleware Controlを使用してポリシー・ストアで定義され、LDAPで定義されたグループおよびユーザーから構成されます。アプリケーション・ロールは、通常、データまたはオブジェクトのいずれかと関係があります。たとえば、Oracle BI Applicationsリポジトリ(OracleBIAnalyticsApps.rpd)は、次のアプリケーション・ロールを使用します。
HR組織ベースのセキュリティのアプリケーション・ロールは、データ・セキュリティ・レベルでの人事データへのアクセスを制御するために使用されます。
人事アナリストのアプリケーション・ロールは、オブジェクト・セキュリティ・レベルで人事アナリスト・ロールのプレゼンテーション・レイヤー・オブジェクトの表示を制御するために使用されます。
RPDでアプリケーション・ロールを表示するには、Oracle BI管理ツールで「管理」を選択してから、「アイデンティティ」を選択します。アプリケーション・ロールは、オンライン・モードでIdentity Managerダイアログに表示できます。オフライン・モードでは、権限、フィルタまたは問合せ制限が設定されているアプリケーション・ロールのみが表示されます。このため、Oracle BI Applicationsリポジトリでデータ・アクセス・セキュリティを使用する場合、オンライン・モードで管理ツールを使用することをお薦めします。
アプリケーション・ロールの設定および管理の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。Oracle BI管理ツールのIdentity Managerを使用して、Oracle BIリポジトリにデータ・アクセス・セキュリティを適用する方法は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Oracle BI Applicationsでのアプリケーション・ロールおよびユーザーの標準的な階層構造は、通常、データ・セキュリティのアプリケーション・ロール、オブジェクト・セキュリティ・アプリケーション・ロール、ユーザーの順です。セキュリティを設定する場合、この構造を使用することをお薦めします。
図2-1は、Oracle BI Applicationsのアプリケーション・ロール階層を示しています。
次の方法のいずれかを使用して、アプリケーション・ロールを設定します。
ポリシー・ストアで、ソース・アプリケーション内の既存の職責またはグループと同じ名前のアプリケーション・ロールを作成します。次に、新しいアプリケーション・ロールをOracle BI固有のアプリケーション・ロール・グループのメンバーとして追加します。ユーザーは、OLTPアプリケーション内の各自の職責またはロールに基づいてこのメンバーシップを継承します。
新しいOracle BI固有のソース・アプリケーションの職責(Oracle EBSおよびSiebel CRM Applications)またはロール(PeopleSoft Enterpriseアプリケーション)を追加し、これらの名前がOracle BI Applicationsのオブジェクト・セキュリティ・アプリケーション・ロールと一致することを確認し、OLTPユーザーをこれらの新しいグループに割り当てます。ユーザーは、前の方法で説明した方法と同じ方法でアプリケーション・ロールのメンバーシップを継承します。
JD Edwardsとのユーザーおよびオブジェクトのセキュリティの統合の詳細は、第2.9項「Oracle JD Edwards EnterpriseOneまたはJD Edwards Worldとのセキュリティの統合について」を参照してください。
SiebelまたはOracle EBS基幹業務アプリケーションで、「職責」ビューに進みます。
PeopleSoftアプリケーションで「ロール」ビューに進み、ユーザーのロールを確認します。
JD Edwards EnterpriseOneアプリケーションで、「ユーザー・プロファイル」アプリケーション(P0092)に進み、ユーザーのロールを確認します。
JD Edwards Worldでユーザー情報リビジョン(P0092)に進み、ユーザーのロールを確認します。
個々のユーザーは、割り当てられたアプリケーション・ロールのリストを表示できます。Oracle BIアプリケーションで、usernameとしてサインインをクリックし、「マイ・アカウント」を選択します。ロールおよびカタログ・グループタブをクリックし、アプリケーション・ロールを表示します。プレゼンテーション・サービスで、アプリケーション・ロールは、プレゼンテーション・サービス内のアクション(権限)を実行する機能を制御するために使用されます。
詳細は、ソース・システムのシステム管理者に問い合せてください。
Oracle BIプレゼンテーション・サービスで新しいカタログ権限をアプリケーション・ロールに追加する場合、この変更は、Oracle Business Intelligence環境にすぐには反映されません。カタログ権限を登録するために、管理者とユーザーの両方が次のタスクを実行する必要があります。
Oracle BI管理者で、Oracle BIプレゼンテーション・サービスを介してOracle BI Serverメタデータを再ロードする必要があります。メタデータを再ロードするには、Oracle Business Intelligence Answersで、「管理」を選択してから、「ファイルとメタデータの再ロード」をクリックします。
プレゼンテーション・サービスのカタログ権限の管理の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
そのアプリケーション・ロールに属しているユーザーは、Oracle BIアプリケーションから(または埋込みアプリケーションを使用してOracle BIのダッシュボードを表示している場合はSiebelまたはOracle EBS基幹業務アプリケーションから)ログアウトして、再度ログインする必要があります。
この項では、Oracle BI Applicationsのデータレベルのセキュリティ機能について説明します。内容は次のとおりです。
データレベルのセキュリティは、OLTPアプリケーションのユーザーがレポート内でアクセスできるものを定義します。2人の異なるユーザーが同じレポートを実行しても、異なるデータが表示されます。これは、異なるユーザーに異なるデータを基幹業務アプリケーションのMy Opportunitiesビューが表示する方法に似ています。ただし、レポートの構造は、ユーザーがレポートのサブジェクトエリアへのアクセス権を持っていない場合(この場合、レポートはエラーを表示します)を除いてすべてのユーザーに対して同じです。
表2-1は、Oracle BI Applicationsでサポートされているデータ・セキュリティ・ポリシーを示しています。インストールおよび構成の間、正しいアプリケーション・ロールおよび初期化ブロックが環境に設定されていることを確認する必要があります。
Oracle Business Intelligenceでの初期化ブロックの使用の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』および『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
表 2-1 サポートされるデータ・セキュリティ・ポリシーのサマリー
アプリケーション・ロール | Oracle EBS | PeopleSoft: Financials | PeopleSoft: HCM | PeopleSoft: Projects | PeopleSoft: Procurement and Spend | Siebel |
---|---|---|---|---|---|---|
営業単位組織ベースのセキュリティ |
7.9.3以降でサポート |
7.9.3以降でサポート |
使用不可 |
7.9.6以降でサポート |
7.9.6以降でサポート |
使用不可 |
会社の組織ベースのセキュリティ |
7.9.3でサポート、7.9.4で廃止 |
7.9.3以降でサポート |
7.9.3以降でサポート |
使用不可 |
使用不可 |
使用不可 |
ビジネス・グループ組織ベースのセキュリティ。 |
7.9.3以降でサポート |
使用不可 |
使用不可 |
使用不可 |
使用不可 |
使用不可 |
HR組織ベースのセキュリティ |
7.9.3以降でサポート |
使用不可 |
7.9.3以降でサポートし、7.9.6で拡張されてPeopleSoft部門セキュリティをサポート |
使用不可 |
使用不可 |
使用不可 |
在庫組織ベースのセキュリティ |
7.9.3以降でサポート |
使用不可 |
使用不可 |
使用不可 |
使用不可 |
使用不可 |
Payables Org-based Security |
使用不可 |
7.9.3以降でサポート |
使用不可 |
使用不可 |
なし |
使用不可 |
売掛勘定組織ベースのセキュリティ |
使用不可 |
7.9.3以降でサポート |
使用不可 |
使用不可 |
なし |
使用不可 |
セットIDベースのセキュリティ |
使用不可 |
7.9.3以降でサポート |
7.9.3以降でサポート |
7.9.6以降でサポート |
7.9.6以降でサポート |
使用不可 |
プライマリ従業員/役割階層ベースのセキュリティ |
HRMSに対して7.9.4以降でサポート |
使用不可 |
7.9.3以降でサポート |
使用不可 |
なし |
7.5以降でサポート |
元帳ベースのセキュリティ |
7.9.4以降でサポート |
7.9.4以降でサポート |
使用不可 |
使用不可 |
7.9.6以降でサポート |
使用不可 |
Oracle BI Applicationsのデータレベルのセキュリティは、次に説明するように次の3つの主な手順で実装されます。これらの手順を実行する方法については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
ユーザーのログイン時に組織階層内のユーザーの階層レベルやユーザーの職責などの特定のセキュリティ関連情報を取得する初期化ブロックを設定します。初期化ブロックは、要素データまたは次元データへの行レベルのアクセスを制限するために、各ユーザー・セッションのDimensionIdを取得します。
事前構成済の初期化ブロックの詳細は、第2.2.3項「Oracle BI Applicationsでデータレベルのセキュリティに使用する初期化ブロック」を参照してください。
メタデータの物理レイヤーと論理レイヤーの該当するセキュリティ・テーブルに結合を設定します。
このセキュリティ機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
保護する必要のある各論理テーブルのアプリケーション・ロールごとにデータ・フィルタを設定します。
このセキュリティ機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
初期化ブロックの設定および管理の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
次に示すように、Oracle BIリポジトリの初期化ブロックは、指定されたユーザーのプライマリ役割、プライマリ組織および所有者IDを取得するように設定されます。
認可
この初期化ブロックは、ユーザーが属するすべてのアプリケーション・ロールにユーザーを関連付けるために使用されます。ユーザーの職責またはロールをソースOLTPアプリケーションから取得し、これをOracle BI Applicationsのアプリケーション・ロールと照合し、セッション中にユーザーが適用可能なオブジェクト・セキュリティを決定します。この初期化ブロックによって、GROUPという変数セットがポピュレートされます。
ビジネス・グループ
この初期化ブロックは、ビジネス・グループを、対応するログイン職責のアクセス先のOLTPアプリケーションから取得するために使用されます。この初期化ブロックによって、BUSINESS_GROUPという変数セットがポピュレートされます。この変数セットは、ビジネス・グループ組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
会社
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションから会社を取得するために使用されます。この初期化ブロックによって、COMPANYという変数セットがポピュレートされます。この変数セットは、会社の組織ベースのセキュリティのセキュリティ権限の実施に使用されます。COMPANYは、PeopleSoftビジネス単位にマップされます。
HR組織
この初期化ブロックは、対応するログイン・ユーザーのアクセス先のOLTPアプリケーションからHR組織を取得するために使用されます。この初期化ブロックによって、HR_ORGという変数セットがポピュレートされます。この変数セットは、人事アナリストのセキュリティ権限の実施に使用されます。
在庫組織
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションから在庫組織を取得するために使用されます。この初期化ブロックによって、INV_ORGという変数セットがポピュレートされます。この変数セットは、在庫組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
元帳
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションから元帳を取得するために使用されます。この初期化ブロックによって、LEDGERという変数セットがポピュレートされます。この変数セットは、元帳ベースのセキュリティのセキュリティ権限の実施に使用されます。
営業単位組織
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションから営業単位組織を取得するために使用されます。この初期化ブロックによって、OU_ORGという変数セットがポピュレートされます。この変数セットは、営業単位組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
組織ベースのセキュリティの組織
この初期化ブロックは、現在のユーザーのビジネス単位にレポートする組織を取得するために使用されます。この初期化ブロックによって、ORGANIZATIONという変数セットがポピュレートされます。この変数セットは、プライマリ組織ベースのセキュリティの実施に使用されます。
買掛勘定組織
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションから買掛勘定組織を取得するために使用されます。この初期化ブロックによって、PAYABLE_ORGという変数セットがポピュレートされます。この変数セットは、買掛勘定組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
プライマリ所有者ID
この初期化ブロックは、指定されたユーザーの所有者IDを取得します。この情報をSiebel OLTPから取得し、PR_OWNER_ID変数をポピュレートします。
買掛勘定組織
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションから買掛勘定組織を取得するために使用されます。この初期化ブロックによって、PAYABLE_ORGという変数セットがポピュレートされます。この変数セットは、買掛勘定組織ベースのセキュリティのセキュリティ権限の実施に使用されます。
SetID
この初期化ブロックは、対応するログイン職責のアクセス先のOLTPアプリケーションからセットIDを取得するために使用されます。この初期化ブロックによって、SET_IDという変数セットがポピュレートされます。この変数セットは、セットIDベースのセキュリティのセキュリティ権限の実施に使用されます。
ユーザー階層レベル
この初期化ブロックは、W_POSITION_DHからユーザーのログインに基づいて指定されたユーザーの固定階層レベルを取得します。変数HIER_LEVELをポピュレートします。このブロックによって使用されるSQLは、データ・ウェアハウスに対して実行されます。したがって、このテーブル(W_POSITION_DH)をポピュレートした最後のETL実行時の階層レベルが反映されます。
ユーザーHR組織
この初期化ブロックは、現在のユーザーが属する現在のHR組織を、OLTPアプリケーションから取得するために使用します。この初期化ブロックによって、USER_HR_ORGという変数がポピュレートされます。
表 2-2に、Oracle BI Applicationsで使用されるアプリケーション・ロールと、それらのアプリケーション・ロールが適用されるアプリケーションを示します。一部の選択アプリケーション・ロールの名前は、Siebel CRMアプリケーションおよびOracle EBSアプリケーションの職責ならびにPeopleSoftアプリケーションのロールと同じです。ソース・アプリケーションでこれらの職責またはロールのいずれかを持つユーザーは、Oracle BIアプリケーションへのログイン時、自動的に対応するアプリケーション・ロールのメンバーとなります。ソース・アプリケーションの類似のオブジェクトに基づく他のアプリケーション・ロールは、ユーザーの任意の追加グループに適用する対応するデータ・フィルタが必要な場合、ポリシー・ストアに追加し、次にこれらのデータレベルのアプリケーション・ロールに追加できます。表2-2は、Oracle BI Applicationsでサポートされているアプリケーション・ロールを示しています。
表2-2 Oracle BI Applicationsでのデータレベルのセキュリティ・アプリケーション・ロール
アプリケーション・ロール名 | サポートされるソース・アプリケーション | 説明 | 関連する初期化ブロック名 |
---|---|---|---|
ビジネス・グループ組織ベースのセキュリティ |
Oracle EBS、PeopleSoft HR |
ビジネス・グループは組織構造の最上位レベルであり、通常は、会社全体または主要部署を表すために使用します。1つのビジネス・グループで複数の帳簿セットを使用できます。 |
ビジネス・グループ |
会社の組織ベースのセキュリティ |
PeopleSoft HRおよびFinancials |
このアプリケーション・ロールでは、ログインしているユーザーに関連付けられているGLビジネス単位またはHRビジネス単位に基づいてデータがフィルタされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
会社 |
HR組織ベースのセキュリティ |
PeopleSoft HR |
このアプリケーション・ロールでは、ユーザーが表示する権限があるHR組織に基づいてデータがフィルタされます。このセキュリティは、HR組織階層とともに動作し、ユーザーが表示する権限がある組織およびユーザーに報告する組織へのユーザーによるアクセスを制限します。 |
HR組織 |
人事データのセキュリティ |
Oracle EBS、PeopleSoft HR |
このアプリケーション・ロールは、監督者(W_POSITION_DH)セキュリティに基づいて、HRスタッフが表示する権限を持つすべての組織(自身の組織を除く)および表示する権限を持つ監督者へのアクセス権をHRスタッフに付与します。 |
HR組織 ユーザーHR組織 |
在庫組織ベースのセキュリティ |
Oracle EBS |
在庫組織によって在庫のトランザクションと残高が追跡され、製品またはコンポーネントが製造または配布されることもあります。このアプリケーション・ロールでは、ログインしているユーザーに関連付けられている在庫組織に基づいてデータがフィルタされます。 |
在庫組織 |
元帳ベースのセキュリティ |
Oracle EBS、PeopleSoft Financials |
元帳は基本的に、共通の勘定体系、機能通貨、会計カレンダーおよび会計処理基準を使用するレポート組織になります。このアプリケーション・ロールでは、ログインしているユーザーに関連付けられている元帳に基づいてデータがフィルタされます。 |
元帳 |
営業単位組織ベースのセキュリティ |
Oracle EBS、PeopleSoft Financials、Siebel CRM |
このアプリケーション・ロールでは、ログインしているユーザーに関連付けられている組織に基づいてデータがフィルタされます。 |
営業単位組織 |
買掛勘定組織ベースのセキュリティ |
PeopleSoft Financials |
このアプリケーション・ロールでは、ログインしているユーザーに関連付けられている買掛勘定ビジネス単位に基づいてデータがフィルタされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
買掛勘定組織 |
プライマリ従業員/役割階層ベースのセキュリティ |
Oracle EBS、PeopleSoft HR、PeopleSoft: Procurement and Spend、PeopleSoft Financials、Siebel CRM |
このアプリケーション・ロールでは、管理者は、監督者階層で従業員データ(直接レポート、命令系統上部に報告するレポートなど)を表示できます。 注意: プライマリ従業員/役割階層ベースのセキュリティは、Siebel Service Analyticsでは使用できません。Siebel Service Analyticsで使用できるセキュリティは、プライマリ所有者組織に付与される表示です。 |
ユーザー階層レベル |
プライマリ所有者ベースのセキュリティ |
Siebel CRM |
このアプリケーション・ロールでは、ログインしているユーザーに基づいてデータがフィルタされます。 |
プライマリ所有者ID |
売掛勘定組織ベースのセキュリティ |
PeopleSoft Financials、Siebel CRM |
このアプリケーション・ロールでは、ログインしているユーザーに関連付けられている売掛勘定ビジネス単位に基づいてデータがフィルタされます。このビジネス単位は、PeopleSoftの最上位レベルの主要な構造です。 |
売掛勘定組織 |
セットIDベースのセキュリティ |
PeopleSoft Financials、Oracle EBS |
このアプリケーション・ロールでは、ログインしているユーザーに関連付けられているセットIDに基づいてデータがフィルタされます。 |
セットID |
前の各項で説明したように、Oracle BI Applicationsは、セッション・レベルで各ユーザーに動的に割り当てられたデータレベルのセキュリティのアプリケーション・ロールを管理します。各アプリケーション・ロールには、これに関連付けられた一連のフィルタがあり、各ユーザーが表示できるデータを決定します。ユーザーは、第2.2.3項「Oracle BI Applicationsでデータレベルのセキュリティに使用する初期化ブロック」で説明したように、認可初期化ブロックによってアプリケーション・ロールを割り当てられます。
データ・セキュリティの設計には、次の機能があります。
ドリルダウン。ユーザーは、役割階層の特定の役割でドリルダウンし、階層の次の役割レベルでデータをスライスできます。たとえば、最初のレポートが次のように定義されているとします。
select Top Level Position, Revenue from RevenueStar
次にTopLevelPosition階層のMyPositionの値をドリルダウンすると、レポートは次のようになります。
Select Level8 Position, Revenue, where TopLevelPosition = 'MyPosition'
パーソナライズ・レポート。役割階層の異なるレベルのユーザーは、同じ役割ベースのレポートを使用できますが、それぞれ自分のレベルに対応するデータが表示されます。このようなレポートでは、役割は動的な列です。
たとえば、レポートが次のように定義されているとします。
select Position, Revenue from RevenueStar
階層の最上位レベルのユーザーの論理問合せは、次のようになります。
select Top Level Position, Revenue from RevenueStar
階層の次のレベルのユーザーの論理問合せは、次のようになります。
select Level8 Position, Revenue from RevenueStar
CURRENT役割階層列。CURRENT接頭辞を含む役割階層列には、いつでも現在の役割階層が含まれます。この機能では、ユーザーは、レポート実行時に、現在の従業員の役割を持つ従業員に関連付けられた同じデータを表示できます。このタイプの分析は、As Isと呼ばれます。
追加の役割階層列列EMP_LOGINおよびEMPLOYEE_FULL_NAMEは、役割階層のあらゆるレベルで使用され、特定の役割を持つ従業員に関する追加情報を格納します。論理レイヤーでは、従業員パスおよび役割パスは、ユーザーが役割をドリルダウンしてその役割よりも下位のすべての役割を表示できる役割階層の下の2つのドリルダウン・パスです。また、従業員は、自分にレポートするすべての従業員を表示できます。
この項では、Oracle BI Applicationsのオブジェクトレベルのセキュリティ機能について説明します。内容は次のとおりです。
アプリケーション・ロールによって、サブジェクトエリア、テーブル、カラムなどのメータデータ・オブジェクトへのアクセスが制御されます。たとえば、ある部署のユーザーは、その部署に属するサブジェクトエリアのみ表示できます。
メタデータ・オブジェクトのセキュリティは、Oracle BI管理ツールを使用してOracle BIリポジトリで構成されます。Everyoneアプリケーション・ロールは、すべてのサブジェクトエリアへのアクセスが拒否されます。各サブジェクトエリアは、選択された関連職責に対して明示的な読取りアクセス権を与えるように構成されます。このアクセスは、テーブルとカラムに拡張できます。
注意: Oracle BI Applicationsのデフォルトでは、サブジェクトエリア・レベルのアクセス権のみが構成されています。 |
注意: Siebel CommunicationsおよびFinancial Analyticsの業務アプリケーションには、業種に固有のテーブルとカラムがあり、したがって、他のアプリケーション・ロールからは非表示になります。
Oracle Business Intelligenceは、アプリケーション・ロール内で階層をサポートします。ポリシー・ストアには、子アプリケーション・ロールすべての動作を定義する親アプリケーション・ロールである特定のアプリケーション・ロールがあります。親アプリケーション・ロールの権限は継承によって子アプリケーション・ロールに伝播されます。親アプリケーション・ロールとその目的を表2-3に示します。
ユーザー・セキュリティでは、ユーザー名やパスワードなどの提供された資格証明に基づいてユーザーのIDが認証および確認されます。デフォルトでは、ユーザーレベルのセキュリティは、Oracle Business Intelligence Enterprise Editionでは、埋込みOracle WebLogic Server LDAPサーバーおよびポリシー・ストアで設定されます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください
事前構成済のOracle BI Applicationsのセキュリティ・モデルを拡張して、基幹業務ソース・システムと照合できます。Oracle BI Applicationsを拡張するとき、カスタマイズおよび任意の新規オブジェクトが有効で機能することを確認する必要があります。
リポジトリ・オブジェクトのデータレベルのセキュリティを拡張する一般的なプロセスは、次のとおりです。
次元または要素を保護する必要がある属性を追加することによって、物理テーブルを拡張します(この手順によって、データ・モデルが変更されます)。
要素テーブルまたは次元テーブルの各行の関連属性値をポピュレートします(この手順によって、ETLマッピングが変更されます)。
Oracle BI管理ツールを使用して、各ユーザーがOracle BI Applicationsにログインしたときに、初期化ブロックを作成し、属性値をフェッチし、これらをセッション変数にポピュレートします。初期化ブロックが行単位の初期化ブロックでない場合、初期化ブロックのターゲット・セッション変数を作成できます(この手順によって、Oracle BIリポジトリが変更されます)。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Fusion Middleware Controlを使用して、ポリシー・ストアにアプリケーション・ロールを作成します。Oracle BI Serverを再起動します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
Oracle BI管理ツールをオンライン・モードで使用して、手順1で追加した属性によって保護する必要がある要素テーブルと次元テーブルそれぞれの新しいロールに基づいて、データ・フィルタを設定します(この手順によって、Oracle BIリポジトリが変更されます)。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Oracle BI管理ツールをオンライン・モードで使用して、手順4で作成したアプリケーション・ロールに基づいて、オブジェクト・アクセスを制限します(この手順によって、Oracle BIリポジトリが変更されます)。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
プレゼンテーション・サービス管理を使用して、手順4で作成したアプリケーション・ロールに基づいて、プレゼンテーション・サービスのカタログ権限を設定します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
注意: また、データレベルのセキュリティを拡張するとき、既存のOracle BI Applicationsのセキュリティ・オブジェクトを利用することも可能です。これを行うには、保護された次元の既存のセキュリティ・オブジェクト(初期化ブロック、アプリケーション・ロールなど)をコピーし、これを変更して追加の次元に適用します。アプリケーション・ロールや初期化ブロックのようなセキュリティ・オブジェクトを使用する方法の詳細は、次のリソースを参照してください。
|
この項では、Oracle BI ApplicationsのセキュリティをOracle 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 UPPER(USER_NAME = UPPER('VALUEOF(NQ_SESSION.USER)')))
この項は、次の項目を含んでいます。
営業単位のセキュリティは、セキュリティ・プロファイルをユーザーのIDまたは職責に関連付けることによって確保されます。つまりセキュリティ・プロファイルは、ユーザーのIDまたは職責にアクセスできる組織階層に関連付けられます(図2-2を参照)。ユーザーのIDまたは職責は、システム管理者の職責を使用して定義されます。セキュリティ・プロファイルおよび組織階層は、HRMS管理者の職責を使用して定義されます。
営業単位の割当ては、次のレベルで、示された優先順位でプロファイル・セットを確認することによって決定されます。
ユーザー
職責
アプリケーション
サイト
つまり、ユーザー・レベルおよびサイト・レベルでプロファイルに値が設定されている場合は、ユーザー・レベルで設定されている値が優先されます。
Oracle EBSの営業単位ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
EBS Single Sign-on Integration初期化ブロックで、次のEBS Single Sign-on Integrationセッション変数が初期化されます。
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 BI Serverは、USERに対応する営業単位をFND_USER_RESP_GROUPSから取得します。次のセッション変数が自動的に設定されます。
OU_ORG(行方向の変数)
次に示すように、初期化ブロックOperating Unit Organizationsによってこの変数に値が設定されます
初期化ブロック: Operating Unit Organizations
次のSQLを使用して、初期化ブロックOperating Unit Organizationsによって変数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 UPPER(USER_NAME = UPPER('VALUEOF(NQ_SESSION.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
placeUNION
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 UPPER(USER_NAME) = UPPER('VALUEOF(NQ_SESSION.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ソースでは、在庫組織を複数の職責と関連付けることができます。
Oracle EBSの在庫組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
EBS Single Sign-on Integration初期化ブロックで、次のEBS Single Sign-on Integrationセッション変数が初期化されます。
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 BI Serverは、USERに対応する在庫組織をFND_USER_RESP_GROUPSから取得します。次のセッション変数が自動的に設定されます。
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 UPPER(USER_NAME) = UPPER('VALUEOF(NQ_SESSION.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の元帳ベースのセキュリティは、Oracle BI Applicationsリリース7.9.4で導入されました。これは、会社ベースのセキュリティを置き換え、Oracle EBS GLの帳簿セットをサポートします。
この項は、次の項目を含んでいます。
Oracle EBSリリース11iでは、帳簿セットは基本的に勘定体系、機能通貨および会計カレンダーなどのレポート・コンテキストを定義するレポート・エンティティです。帳簿セットは、ユーザー、職責またはすべての職責のデフォルトとしてサイトに割り当てることができます。各ユーザーは、Oracle Applicationsで指定された職責でアプリケーションにログインする際に、1つの帳簿セットに関連付けられます。元帳ベースのセキュリティでは、ログインしているユーザーに関連付けられている帳簿セットに基づいてデータがフィルタされます。
Oracle EBSリリース12では、帳簿セットは元帳に置き換えられました。元帳によって、通貨、勘定体系、会計カレンダー、元帳処理オプションおよび補助元帳会計処理基準が決められます。ユーザーの職責に割り当てられるデータ・アクセス・セットによって、ユーザーがアクセスできる元帳が制御されます。ユーザーは、1つの職責から複数の元帳にアクセスできる場合があります。元帳ベースのセキュリティでは、ログインしているユーザーに関連付けられている元帳に基づいてデータがフィルタされます。
Oracle EBSの元帳ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle Business Intelligence Enterprise Editionにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
EBS Single Sign-on Integration初期化ブロックで、次のEBS Single Sign-on Integrationセッション変数が初期化されます。
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 EBS 11iを使用している場合は、次のSQLがLedgers初期化ブロックのデータ・ソースとして適用されます。
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 UPPER(USER_NAME) = UPPER('VALUEOF(NQ_SESSION.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))
この項には次のトピックが含まれます:
ビジネス・グループは、組織構造の最上位レベルです。通常は、会社全体または主要部署を表すために使用します。1つのビジネス・グループで複数の帳簿セットを使用できます。
Oracle EBSのビジネス・グループ組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
EBS Single Sign-on Integration初期化ブロックで、次のEBS Single Sign-on Integrationセッション変数が初期化されます。
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 BI 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 = (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 UPPER(USER_NAME) = UPPER('VALUEOF(NQ_SESSION.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のHR組織ベースのセキュリティは、Oracle EBS Human Resourcesで定義された標準HRMS組織のセキュリティをサポートします。Oracle EBS Human Resourcesは、セキュリティ・プロファイルで定義されたセキュリティ・ポリシーに基づいて、組織、役割および給与によるアクセスを制限します。
Oracle EBSのHR組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応するHR組織が取得されます。
FND_USER_RESP_GROUPS
FND_USER
PER_SECURITY_PROFILES
PER_SEC_PROFILE_ASSIGNMENTS
PER_PERSON_LIST
注意: PER_PERSON_LISTテーブルを使用するには、Oracle EBS HRMSセキュリティ・リスト・メンテナンス・プロセスを実行済であることを確認する必要があります。
PER_ALL_ASSIGNMENTS_F
次のセッション変数が自動的に設定されます。
HR_ORG(行方向の変数)
次に示すように、初期化ブロックHR Organizationsによってこの変数に値が設定されます。
初期化ブロック: HR Organizations
次のSQLを使用して、初期化ブロックHR Organizationsによって変数HR_ORGに値が設定されます。実際のSQL問合せは、Multiple Security Group(MSG)が設定されているかどうかに応じて異なります。
MSGが設定されていない場合、次のSQLを使用する必要があります。
SELECT DISTINCT 'HR_ORG' ,TO_CHAR(SEC_DET.ORGANIZATION_ID) FROM ( SELECT 'HR_ORG', ASG.ORGANIZATION_ID FROM FND_USER_RESP_GROUPS URP ,FND_USER USR ,PER_SECURITY_PROFILES PSEC ,PER_PERSON_LIST PER ,PER_ALL_ASSIGNMENTS_F ASG WHERE URP.START_DATE < TRUNC(SYSDATE) AND (CASE WHEN URP.END_DATE IS NULL THEN TRUNC(SYSDATE) ELSE TO_DATE(URP.END_DATE) END) >= TRUNC(SYSDATE) AND USR.USER_NAME = UPPER('VALUEOF(NQ_SESSION.USER)') AND USR.USER_ID = URP.USER_ID AND TRUNC(SYSDATE) BETWEEN URP.START_DATE AND NVL(URP.END_DATE, HR_GENERAL.END_OF_TIME) AND PSEC.SECURITY_PROFILE_ID = FND_PROFILE.VALUE_SPECIFIC('PER_SECURITY_PROFILE_ID', URP.USER_ID, URP.RESPONSIBILITY_ID, URP.RESPONSIBILITY_APPLICATION_ID) AND PER.SECURITY_PROFILE_ID = PSEC.SECURITY_PROFILE_ID AND PER.PERSON_ID = ASG.PERSON_ID AND TRUNC(SYSDATE) BETWEEN ASG.EFFECTIVE_START_DATE AND ASG.EFFECTIVE_END_DATE AND URP.RESPONSIBILITY_ID = DECODE(FND_GLOBAL.RESP_ID, -1, URP.RESPONSIBILITY_ID, NULL, URP.RESPONSIBILITY_ID, FND_GLOBAL.RESP_ID) UNION SELECT DISTINCT 'HR_ORG', ORGANIZATION_ID FROM PER_ALL_ASSIGNMENTS_F ASG, FND_USER USR WHERE ASG.PERSON_ID = USR.EMPLOYEE_ID AND USR.USER_NAME = UPPER('VALUEOF(NQ_SESSION.USER)') AND TRUNC(SYSDATE) BETWEEN ASG.EFFECTIVE_START_DATE AND ASG.EFFECTIVE_END_DATE AND ASG.PRIMARY_FLAG = 'Y' ) SEC_DET
MSGが設定されている場合、次のSQLを使用する必要があります。
SELECT DISTINCT 'HR_ORG', TO_CHAR(PER_ORGANIZATION_LIST.ORGANIZATION_ID) FROM PER_ORGANIZATION_LIST, (SELECT FND_PROFILE.VALUE_SPECIFIC('PER_BUSINESS_GROUP_ID', 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 = (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 = UPPER('VALUEOF(NQ_SESSION.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) ) WHERE PER_ORGANIZATION_LIST.SECURITY_PROFILE_ID = PROFILE_ID
注意: HR組織ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
HR担当者は、組織内部のすべての担当データと、HR担当者自身の組織内の部下のデータを確認する必要があります。HR担当者のデータ・セキュリティのアプリケーション・ロールがこのニーズに応えます。このアプリケーション・ロールのセキュリティ・メカニズムは、次のメタデータ要素を使用します。
HR_ORG変数。この変数は、行単位の初期化ブロックのHR Organizationsによって定義されます。このデータ・セットは、ユーザーが担当するすべての組織およびユーザー自身の組織(USER_HR_ORGで選択された組織と同じ)を格納します。このデータ・セットをポピュレートする問合せは次のとおりです。
注意: 実際のSQL問合せは、Multiple Security Group(MSG)が設定されているかどうかに応じて異なります。
MSGが設定されていない場合、次のSQLが使用されます。
SELECT DISTINCT 'HR_ORG', TO_CHAR(PER_ORGANIZATION_LIST.ORGANIZATION_ID) FROM PER_ORGANIZATION_LIST, (SELECT FND_PROFILE.VALUE_SPECIFIC('PER_BUSINESS_GROUP_ID', 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 = (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 = UPPER('VALUEOF(NQ_SESSION.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) ) WHERE PER_ORGANIZATION_LIST.SECURITY_PROFILE_ID = PROFILE_ID
MSGが設定されている場合、次のSQLが使用されます。
SELECT DISTINCT 'HR_ORG' ,TO_CHAR(SEC_DET.ORGANIZATION_ID) FROM ( SELECT 'HR_ORG', ASG.ORGANIZATION_ID FROM FND_USER_RESP_GROUPS URP, FND_USER USR, PER_SEC_PROFILE_ASSIGNMENTS SASG, PER_SECURITY_PROFILES PSEC, PER_PERSON_LIST PER, PER_ALL_ASSIGNMENTS_F ASG WHERE URP.START_DATE < TRUNC(SYSDATE) AND (CASE WHEN URP.END_DATE IS NULL THEN TRUNC(SYSDATE) ELSE TO_DATE(URP.END_DATE) END) >= TRUNC(SYSDATE) AND USR.USER_NAME = UPPER('VALUEOF(NQ_SESSION.USER)') AND URP.SECURITY_GROUP_ID = SASG.SECURITY_GROUP_ID AND URP.USER_ID = USR.USER_ID AND TRUNC(SYSDATE) BETWEEN URP.START_DATE AND NVL(URP.END_DATE, HR_GENERAL.END_OF_TIME) AND URP.USER_ID = SASG.USER_ID AND URP.RESPONSIBILITY_ID = SASG.RESPONSIBILITY_ID AND URP.RESPONSIBILITY_APPLICATION_ID = SASG.RESPONSIBILITY_APPLICATION_ID AND PSEC.SECURITY_PROFILE_ID = SASG.SECURITY_PROFILE_ID AND PSEC.SECURITY_PROFILE_ID = PER.SECURITY_PROFILE_ID AND PER.PERSON_ID = ASG.PERSON_ID AND TRUNC(SYSDATE) BETWEEN ASG.EFFECTIVE_START_DATE AND ASG.EFFECTIVE_END_DATE AND TRUNC(SYSDATE) BETWEEN SASG.START_DATE AND NVL(SASG.END_DATE, HR_GENERAL.END_OF_TIME) AND URP.RESPONSIBILITY_ID = DECODE(FND_GLOBAL.RESP_ID, -1, URP.RESPONSIBILITY_ID, NULL, URP.RESPONSIBILITY_ID, FND_GLOBAL.RESP_ID) UNION SELECT DISTINCT 'HR_ORG', ORGANIZATION_ID FROM PER_ALL_ASSIGNMENTS_F ASG, FND_USER USR WHERE ASG.PERSON_ID = USR.EMPLOYEE_ID AND USR.USER_NAME = UPPER('VALUEOF(NQ_SESSION.USER)') AND TRUNC(SYSDATE) BETWEEN ASG.EFFECTIVE_START_DATE AND ASG.EFFECTIVE_END_DATE AND ASG.PRIMARY_FLAG= 'Y' ) SEC_DET
USER_HR_ORG変数。この変数は、初期化ブロックのUser HR Organizationsを使用して定義されます。この変数は、ユーザー自身の組織を格納します。この変数をポピュレートする問合せは次のとおりです。
SELECT DISTINCT 'USER_HR_ORG', ORGANIZATION_ID FROM PER_ALL_ASSIGNMENTS_F ASG, FND_USER USR WHERE ASG.PERSON_ID = USR.EMPLOYEE_ID AND USR.USER_NAME = UPPER('VALUEOF(NQ_SESSION.USER)') AND TRUNC(SYSDATE) BETWEEN ASG.EFFECTIVE_START_DATE AND ASG.EFFECTIVE_END_DATE AND ASG.PRIMARY_FLAG= 'Y'
人事アナリストのアプリケーション・ロール。このアプリケーション・ロールに対して定義されたデータ・フィルタは、次のとおりです。
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 - Position Security"."Hierarchy Based Column" = VALUEOF(NQ_ SESSION."USER"))
このフィルタによって、レポートで使用される要素テーブルが従業員組織の次元に結合され、要素レコードの従業員所有者の組織番号が取得されます。この組織がHR組織に含まれる場合、この組織は次にユーザー自身の組織と照合されます。これらが異なる場合は、さらにチェックされることはなく、レコードが選択されます。これらが同一の場合は、従業員階層に基づいて追加フィルタが適用され、この要素レコードの従業員所有者がユーザーの部下の1人であることが確認されます。
従業員ベースのセキュリティによって、レコードのデータ表示が、そのレコードの所有者と、会社の従業員階層内でその所有者にレポートするすべての従業員に制限されます。このセキュリティ・メカニズムでは、データ・ウェアハウス・データベースのデータが使用され、サポートされている他のアプリケーション(Siebel CRMおよびPeopleSoft)とメタデータのコンポーネントが共有されます。デフォルトでは、このタイプのセキュリティではHR分析ファクトのみがサポートされます。このセキュリティ・メカニズムの機能の詳細は、第2.8.2項「Siebel CRM業界向けアプリケーションのプライマリ役割ベースのセキュリティについて」を参照してください。
この項では、Oracle BI Applicationsでデータ・セキュリティをOracle PeopleSoft Enterprise Applicationsに実装する方法について説明します。必要に応じてセキュリティの実装方法を変更できるよう、セキュリティのデフォルト設定の構成を理解しておく必要がある場合は、この項をお読みください。この項には次のトピックが含まれます:
第2.7.2項「PeopleSoft FinancialsおよびPeopleSoft Procurement and Spendに対する営業単位ベースのセキュリティ」
第2.7.3項「PeopleSoft FinancialsおよびPeopleSoft HRに対する会社組織ベースのセキュリティ」
第2.7.4項「PeopleSoft FinancialsおよびPeopleSoft Procurement and Spendに対する元帳ベースのセキュリティ」
第2.7.8項「PeopleSoft HR、PeopleSoft FinancialsおよびPeopleSoft Procurement and Spendに対するSetIDベースのセキュリティ」
Oracle BI Applicationsの認可プロセスでは、ソースのPeopleSoftアプリケーションからユーザーのロールがフェッチされ、そのロールがすべてのOracle BI Applicationsのアプリケーション・ロールと照合されて、ユーザーのセッション時にユーザーの該当するオブジェクト・セキュリティが決定されます。初期化ブロックAuthorizationを使用してロールがフェッチされ、結果セットが特別なセッション変数GROUPに割り当てられます。その後、Oracle BI Serverは、この変数を照合に使用します。初期化ブロックSQLは次のとおりです。
SELECT DISTINCT 'GROUP', ROLENAME FROM PSROLEUSER WHERE ROLEUSER = ''VALUEOF(NQ_SESSION.USER)''
PeopleSoft FinancialsおよびPeopleSoft Procurement and Spendに対する営業単位ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応する営業単位(つまりPeopleSoft Financialsの総勘定元帳ビジネス単位)が取得されます。
PS_SEC_BU_OPR
PS_BUS_UNIT_TBL_GL
PS_INSTALLATION_FS
PS_SEC_BU_CLS
次のセッション変数が自動的に設定されます。
OU_ORG(行方向の変数)
次に示すように、初期化ブロックOperating Unit Organizationsによってこの変数に値が設定されます
初期化ブロック: Operating Unit Organizations
次のSQLを使用して、初期化ブロックOperating Unit Organizationsによって変数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 = ''VALUEOF(NQ_SESSION.USER)''
AND S1.BUSINESS_UNIT = A.BUSINESS_UNIT
AND I.SECURITY_TYPE = 'O'
AND I.BU_SECURITY = 'Y'
placeUNION
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 = ''VALUEOF(NQ_SESSION.USER)''
AND S2.BUSINESS_UNIT = A.BUSINESS_UNIT
AND P.OPRCLASS = S2.OPRCLASS
AND I2.SECURITY_TYPE = 'C'
AND I2.BU_SECURITY = 'Y'
注意: 営業単位ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。
PeopleSoft FinancialsおよびPeopleSoft HRの会社組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応する会社またはビジネス単位が取得されます。
PS_SEC_BU_OPR
PS_BUS_UNIT_TBL_GL
PS_SCRTY_TBL_DEPT
PS_BU_DEPT_VW
PS_BUS_UNIT_TBL_GL
PSOPRDEFN(PeopleSoft HRの場合)
PS_INSTALLATION_FS(PeopleSoft Financialsの場合)
PeopleSoft Financialsの場合、PSOPRDEFN
PeopleSoft Financialsの場合、PS_SEC_BU_CLS
次のセッション変数が自動的に設定されます。
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 = 'VALUEOF(NQ_SESSION.USER)'
AND S1.BUSINESS_UNIT = A.BUSINESS_UNIT
AND I.SECURITY_TYPE = 'O'
placeUNION
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 = 'VALUEOF(NQ_SESSION.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 = 'VALUEOF(NQ_SESSION.USER)'
注意: 会社組織ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。
PeopleSoftの元帳データは、ビジネス単位で保護され共有される参照データです。元帳のテーブルにはSetIDフィールドがあり、PeopleToolのTableSet機能が使用されます。また、元帳データのアクセスは、行レベルのセキュリティによって制御され、これにより、元帳によって制御されているデータの特定の行から個々のユーザーまたはアクセス権のリストを制限するセキュリティを実装できます。元帳ベースのセキュリティでは、ログインしているユーザーに関連付けられている元帳に基づいてデータがフィルタされます。
PeopleSoftアプリケーションに対して元帳ベースのセキュリティを設定した場合、PeopleSoftに対する会社組織ベースのセキュリティも設定する必要があります。元帳ベースのセキュリティによって、総勘定元帳ビジネス単位のデータが自動的に制限されるわけではありません。
PeopleSoft FinancialsおよびPeopleSoft Procurement and Spendに対する元帳ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応する元帳が取得されます。
PS_LED_DEFN_TBL
PS_INSTALLATION_FS
PS_SEC_LEDGER_CLS
PS_LED_GRP_TBL
PSOPRDEFN
PSROLEUSER
PSROLECLASS
次のセッション変数が自動的に設定されます。
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 = 'VALUEOF(NQ_SESSION.USER)'
placeUNION
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 = 'VALUEOF(NQ_SESSION.USER)'
注意: 元帳ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。
PeopleSoft HRのHR組織ベースのセキュリティは、ツリーごとにPeopleSoft部門セキュリティをサポートします。
PeopleSoft HRのHR組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応するHRビジネス単位が取得されます。
PSOPRDEFN
PS_SCRTY_TBL_DEPT
次のセッション変数が自動的に設定されます。
HR_ORG(行方向の変数)
次に示すように、初期化ブロックHR Organizationsによってこの変数に値が設定されます。
初期化ブロック: HR Organizations
次のSQLを使用して、初期化ブロックHR Organizationsによって変数HR_ORGに値が設定されます。
SELECT 'DEPT_ID', DEPT.DEPTID FROM PS_DEPT_TBL DEPT,PSOPRDEFN OPR WHERE DEPT.EFFDT = ( SELECT MAX(DEPT1.EFFDT) FROM PS_DEPT_TBL DEPT1 WHERE DEPT1.SETID = DEPT.SETI AND DEPT1.DEPTID = DEPT.DEPTID) AND (EXISTS ( SELECT 'X' FROM PS_SJT_DEPT SEC, PS_SJT_CLASS_ALL CLS, PS_SJT_OPR_CLS SOC WHERE SEC.SETID = DEPT.SETID AND SEC.DEPTID = DEPT.DEPTID AND CLS.SCRTY_SET_CD = 'PPLJOB' AND CLS.SCRTY_TYPE_CD = '001' AND CLS.TREE = 'Y' AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1 AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2 AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3 AND SOC.OPRID = OPR.OPRID AND SOC.CLASSID = CLS.CLASSID AND SOC.CLASSID = OPR.ROWSECCLASS AND SOC.SEC_RSC_FLG <> '2' ) OR EXISTS ( SELECT 'X' FROM PS_SJT_DEPT SEC, PS_SJT_CLASS_ALL CLS, PS_SJT_OPR_CLS SOC WHERE SEC.SETID = DEPT.SETID AND SEC.DEPTID = DEPT.DEPTID AND CLS.SCRTY_SET_CD = 'DEPT' AND CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1 AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2 AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3 AND CLS.TREE = 'Y' AND SOC.OPRID = OPR.OPRID AND SOC.CLASSID = CLS.CLASSID AND SOC.CLASSID = OPR.ROWSECCLASS AND SOC.SEC_RSC_FLG <> '2' ) OR EXISTS ( SELECT 'X' FROM PS_SJT_DEPT SEC, PS_SJT_CLASS_ALL CLS, PS_SJT_OPR_CLS SOC WHERE SEC.SETID = DEPT.SETID AND SEC.DEPTID = DEPT.DEPTID AND CLS.SCRTY_SET_CD = 'DEPT' AND CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1 AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2 AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3 AND CLS.TREE = 'N' AND SOC.OPRID = OPR.OPRID AND SOC.CLASSID = CLS.CLASSID)) AND OPR.OPRID = 'VALUEOF(NQ_SESSION.USER)'
注意: HR組織ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
PeopleSoft Financialsの買掛勘定組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応する買掛勘定ビジネス単位が取得されます。
PSOPRDEFN
PS_SEC_BU_OPR
PS_SEC_BU_CLS
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 = 'VALUEOF(NQ_SESSION.USER)'
AND s1.BUSINESS_UNIT = a.BUSINESS_UNIT
AND i.SECURITY_TYPE = 'O'
AND i.BU_SECURITY = 'Y'
placeUNION
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 = 'VALUEOF(NQ_SESSION.USER)'
AND s2.BUSINESS_UNIT = a.BUSINESS_UNIT
AND p.OPRCLASS = s2.OPRCLASS
AND i2.SECURITY_TYPE = 'C'
AND i2.BU_SECURITY = 'Y'
注意: 買掛勘定組織ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
PeopleSoft Financialsの売掛勘定組織ベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応する売掛勘定ビジネス単位が取得されます。
PS_SEC_BU_OPR
PS_SEC_BU_CLS
PS_INSTALLATION_FS
PS_BUS_UNIT_TBL_AR
次のセッション変数が自動的に設定されます。
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 = 'VALUEOF(NQ_SESSION.USER)'
AND s1.BUSINESS_UNIT = a.BUSINESS_UNIT AND i.SECURITY_TYPE = 'O'
AND i.BU_SECURITY = 'Y'
placeUNION
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 = 'VALUEOF(NQ_SESSION.USER)'
AND s2.BUSINESS_UNIT = a.BUSINESS_UNIT AND p.OPRCLASS =
s2.OPRCLASS AND i2.SECURITY_TYPE = 'C'
AND i2.BU_SECURITY = 'Y'
注意: 売掛勘定組織ベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。ユーザーが非定型レポートを作成する場合、ユーザーには各自のアクセス権が割り当てられているデータが表示されます。前述のテーブルに関連するレポートについては、ユーザーのアクセスは組織構造における各自の表示モードに該当するデータに制限されます。
PeopleSoft Financials、PeopleSoft HRおよびPeopleSoft Procurement and Spendに対するSetIDベースのセキュリティのシーケンスは、次のとおりです。
ユーザーがOracle BI Applicationsにログインすると、次のセッション変数が自動的に設定されます。
USER(システム変数)
Oracle BI Serverで、次のテーブルからUSERに対応するSetIDが取得されます。
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 = 'VALUEOF(NQ_SESSION.USER)'
AND i.SECURITY_TYPE = 'O'
AND i.SETID_SECURITY = 'Y'
placeUNION
SELECT DISTINCT 'SET_ID', s2.SETID
FROM PS_SEC_SETID_CLS s2, PS_INSTALLATION_FS i2, PSOPRDEFN p
WHERE p.OPRID = 'VALUEOF(NQ_SESSION.USER)'
AND p.OPRCLASS = s2.OPRCLASS
AND i2.SECURITY_TYPE = 'C'
AND i2.SETID_SECURITY = 'Y'
注意: SetIDベースのセキュリティのアプリケーション・ロールには、データ・アクセス権のフィルタがすべて含まれています。
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 = 'VALUEOF(NQ_SESSION.USER)'
placeUNION
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 = 'VALUEOF(NQ_SESSION.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 = 'VALUEOF(NQ_SESSION.USER)'
人事アナリストのアプリケーション・ロール。このアプリケーション・ロールに対して定義されたデータ・フィルタは、次のとおりです。
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 - Position Security"."Hierarchy Based Column" = VALUEOF(NQ_SESSION."USER"))
このフィルタによって、レポートで使用される要素テーブルが従業員組織の次元に結合され、要素レコードの従業員所有者の組織番号が取得されます。この組織がHR組織に含まれる場合、この組織は次にユーザー自身の組織と照合されます。これらが異なる場合は、さらにチェックされることはなく、レコードが選択されます。これらが同一の場合は、従業員階層に基づいて追加フィルタが適用され、この要素レコードの従業員所有者がユーザーの部下の1人であることが確認されます。
従業員ベースのセキュリティによって、レコードのデータ表示が、そのレコードの所有者と、会社の従業員階層内でその所有者にレポートするすべての従業員に制限されます。このセキュリティ・メカニズムでは、Oracle Business Analytics Warehouseデータベースのデータが使用され、サポートされている他のアプリケーション(Oracle EBS、Siebel CRM、PeopleSoftなど)とメタデータのコンポーネントが共有されます。デフォルトでは、このタイプのセキュリティではHR分析ファクトのみがサポートされます。このセキュリティ・メカニズムの機能の詳細は、第2.8.2項「Siebel CRM業界向けアプリケーションのプライマリ役割ベースのセキュリティについて」を参照してください。
この項では、Oracle BI Applicationsのデータ・セキュリティをSiebel CRMに実装する方法について説明します。必要に応じてセキュリティの実装方法を変更できるよう、セキュリティのデフォルト設定の構成を理解しておく必要がある場合は、この項をお読みください。
注意: プライマリ従業員/役割階層ベースのセキュリティは、Siebel Service Analyticsでは使用できません。Siebel Service Analyticsで使用できるセキュリティは、プライマリ所有者組織に付与される表示です。 |
この項には次のトピックが含まれます:
この項では、プライマリ役割ベースのセキュリティについて説明します。内容は次のとおりです。
プライマリ役割ベースのセキュリティによって、要素レコードまたは次元レコードのデータ表示が、そのレコードのプライマリ所有者と、階層内でその所有者の上位の人に制限されます。レコードのプライマリ所有者は、役割または従業員です。プライマリ役割ベースのセキュリティは、W_POSITION_Dに基づき、ゆっくり変化する次元として処理されるW_POSTION_DHという平坦化された階層テーブルを使用します。
Siebel CRMベースのデータの場合、W_POSITION_Dは、Siebel CRMの役割テーブルからポピュレートされます。新しいレコードは、新しい従業員がこの役割にプライマリ従業員として関連付けられるたびに同じ役割に対して作成されます。
結果として、ソース・テーブルの各レコードをW_POSITION_DHの複数のレコードによって表すことが可能ですが、CURRENT_FLGの値がYのレコードはいつでも1つのみです。また、W_POSITION_DHテーブルには、CURRENT接頭辞が含まれている列のセットとCURRENT接頭辞が含まれていない列のセットがあります。CURRENT接頭辞が含まれている列は、いつでも、役割レコードまたは従業員レコードの現在の階層構造を反映します。CURRENT接頭辞が含まれていない列は、EFFECTIVE_START_DTとEFFECTIVE_END_DTの間に、同じ役割レコードまたは従業員レコードの階層構造を反映します。この後者の列セットは、レコードの所有者およびレコード作成時のレコード所有者の上位レベルの管理者に対して要素レコードを表示するために使用されます。これは、後に会社の階層でレコード所有者の役割や管理者が変わっても同様です。
要素は、レコード所有者によってこの次元に結合されます。たとえば、W_REVN_Fは、PR_POSITION_DH_WIDを使用して結合されます。ここで、PR_POSITION_DH_WIDは、ソース・アプリケーションの売上線上のプライマリ役割です。
このアプリケーション・ロールは、リポジトリで次のメタデータ要素を使用します。
HIER_LEVELセッション変数。この変数は、次のSQLを使用して、初期化ブロックUser Hierarchy Levelによってポピュレートされます。ユーザー階層レベルの初期化ブロックの詳細は、第2.2.3項「Oracle BI Applicationsでデータレベルのセキュリティに使用する初期化ブロック」を参照してください。
Select round(FIXED_HIER_LEVEL) FROM VALUEOF(OLAPTBO).W_POSITION_DH WHERE BASE_LOGIN= 'VALUEOF(NQ_SESSION.USER)' AND CURRENT_FLG='Y'
HIER_LEVELの値は、0から17の値です。これは、会社の階層でのユーザーの現在の固定階層レベルを指定します。会社の階層は、Oracle EBSアプリケーションおよびPeopleSoftアプリケーションの従業員階層ツリーならびにSiebelアプリケーションの役割階層ツリーに基づいています。たとえば、従業員階層が完全なツリーの場合、その会社のCEOは、HIER_LEVELの値が17の唯一の従業員です。
Dim - Position Security論理次元。この論理次元は、サポートされる要素テーブルに結合されます。これは、物理テーブルW_POSITION_DHで定義されます。
階層ベース列の論理列。この列は、Dim - Position Security論理次元の論理列です。これは、次のように定義されます。
"INDEXCOL(VALUEOF(NQ_SESSION."HIER_LEVEL"), "Core"."Dim - Position Security"."Current Base Level Login", "Core"."Dim - Position Security"."Current Level 1 Login", "Core"."Dim - Position Security"."Current Level 2 Login", "Core"."Dim - Position Security"."Current Level 3 Login", "Core"."Dim - Position Security"."Current Level 4 Login", "Core"."Dim - Position Security"."Current Level 5 Login", "Core"."Dim - Position Security"."Current Level 6 Login", "Core"."Dim - Position Security"."Current Level 7 Login", "Core"."Dim - Position Security"."Current Level 8 Login", "Core"."Dim - Position Security"."Current Level 9 Login", "Core"."Dim - Position Security"."Current Level 10 Login", "Core"."Dim - Position Security"."Current Level 11 Login", "Core"."Dim - Position Security"."Current Level 12 Login", "Core"."Dim - Position Security"."Current Level 13 Login", "Core"."Dim - Position Security"."Current Level 14 Login", "Core"."Dim - Position Security"."Current Level 15 Login", "Core"."Dim - Position Security"."Current Level 16 Login", "Core"."Dim - Position Security"."Current Top Level Login")"
.
この定義内のIndexCol関数によって、Hierarchy Based ColumnがHIER_LEVELの値に基づいてリスト内の論理カラムの1つにデフォルト設定されます。したがって、HIER_LEVELの値が0の場合、新しい列がリストの最初の列にデフォルト設定され、以後同様に続きます。
次のように定義されたプライマリ従業員/役割階層ベースのセキュリティのアプリケーション・ロールのフィルタ("Core"."Dim - Position Security"."Hierarchy Based Column" = VALUEOF(NQ_SESSION."USER"))。
データ・セキュリティのフィルタを適用するには、ユーザーは、いずれかの職責(SiebelおよびOracle EBSアプリケーションの場合)およびロール(PeopleSoftアプリケーションの場合)に基づいた、プライマリ従業員/役割階層ベースのセキュリティのアプリケーション・ロールのメンバーである必要があります。ユーザーは、第2.2.3項「Oracle BI Applicationsでデータレベルのセキュリティに使用する初期化ブロック」の説明に従って、認可初期化ブロックを使用してユーザーの職責に基づいてこのアプリケーション・ロールに割り当てられます。デフォルトでは、この初期化ブロックは、次の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('VALUEOF(NQ_SESSION.USER)') and U.ROW_ID=P.PER_ID and P.RESP_ID=R.ROW_ID
placeUNION
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 8 then 'Hierarchy Level 8'
when 6 then 'Hierarchy Level 6'
when 7 then 'Hierarchy Level 7'
when 8 then 'Hierarchy Level 8'
when 9 then 'Hierarchy Level 9'
when 10 then 'Hierarchy Level 10'
when 11 then 'Hierarchy Level 11'
when 12 then 'Hierarchy Level 12'
when 13 then 'Hierarchy Level 13'
when 14 then 'Hierarchy Level 14'
when 15 then 'Hierarchy Level 15'
when 16 then 'Hierarchy Level 16'
When 17 then 'Hierarchy Level (Top)'
ELSE'NOGROUP'END from VALUEOF(TBO).S_DUAL
このSQLの最初の部分では、Siebel CRMアプリケーションからユーザーの職責が選択されます。ユーザーは、同じ名前のアプリケーション・ロールに自動的に割り当てられます。
このSQLの2番目の部分では、変数HIER_LEVELに基づいて、階層レベル(ベース)、階層レベル1から16、階層レベル(トップ)などのOracle BI固有のアプリケーション・ロールにユーザーを割り当てます。これらのアプリケーション・ロールは、データ・セキュリティを目的として使用されるのではなく、一部のレポートで定義されるWeb Choose関数とともに、プレゼンテーション・カラムを目的として使用されます。この関数の目的は、複数ユーザーのレポートで、ユーザーの階層レベルに基づいて異なる役割カラムをユーザーに表示できるようにすることです。これは、第2.8.1.2項「プライマリ従業員/役割階層ベースのアプリケーション・ロール」で説明されているIndexCol関数に非常によく似ています。
次の手順は、プライマリ役割ベースのセキュリティを新しい次元テーブルまたは要素テーブルに追加する方法を提供します。例として、次の手順では、W_AGREE_D(アグリーメント)次元を使用します。
プライマリ役割ベースのセキュリティを次元テーブルに追加するには、次のようにします。
管理ツールの物理レイヤーで、基礎となる物理テーブルに結合するW_POSITION_DHに別名を明示的に作成します。
物理レイヤーに結合を構成します。
管理ツールのビジネス・モデルとマッピング・レイヤーで、W_POSITION_DHの別名を次元の論理表ソースに追加します。
新しい論理カラムCURRENT_BASE_LOGIN、CURRENT_LVL1ANC_LOGIなどを論理表に追加して、これらを対応する物理カラムにマップします。
階層カラムHierarchy Based Columnを追加します。
管理ツールで、メニュー・バーから「ツール」、「アイデンティティ」を選択して、セキュリティ・マネージャを開きます。
プライマリ従業員/役割階層ベースのセキュリティのアプリケーション・ロールを右クリックして、「プロパティ」を選択します。
「プロパティ」ダイアログ・ボックスで、「許可」をクリックし、「データ・フィルタ」タブを選択します。
新規フィルタを追加するには、「追加」をクリックします。
新しいダイアログで、「ビジネス モデル」タブを選択して、論理表Dim - Agreementを検索してダブルクリックします。
フィルタのリストに新しいレコードが自動的に追加されます。
「データ・フィルタ」フィールドを選択し、「式ビルダー」ボタンをクリックします。「式ビルダー」にフィルタ条件"Core"."Dim - Customer"."Hierarchy Based Login" = VALUEOF(NQ_SESSION."USER")を追加して、「OK」をクリックします。
「ユーザー/アプリケーション・ロール権限」ダイアログで「OK」をクリックし、「アプリケーション・ロール」ダイアログで「OK」をクリックします。
プライマリ役割ベースのセキュリティ・サポートを要素テーブルに追加するには、次のようにします。
管理ツールの物理レイヤーで、基礎となる物理テーブルをDim_W_POSITION_DH_Position_Hierarchyに結合します。
ここでは、要素テーブルに該当する外部キーがすでに作成されていて、そのキーが正常にポピュレートされていることを前提とします。
論理表をDim - Position Securityに結合します。
管理ツールで、メニュー・バーから「ツール」、「アイデンティティ」を選択して、セキュリティ・マネージャを開きます。
プライマリ従業員/役割階層ベースのセキュリティのアプリケーション・ロールを右クリックして、「プロパティ」を選択します。
「プロパティ」ダイアログ・ボックスで、「許可」をクリックし、「データ・フィルタ」タブを選択します。
新規フィルタを追加するには、「追加」をクリックします。
新しいダイアログ・ボックスで、「ビジネス モデル」タブを選択して、論理表Dim - Agreementを検索してダブルクリックします。
フィルタのリストに新しいレコードが自動的に追加されます。
「データ・フィルタ」フィールドを選択し、「式ビルダー」ボタンをクリックします。「式ビルダー」にフィルタ条件"Core"."Dim - Position Security"."Hierarchy Based Column" = VALUEOF(NQ_SESSION."USER")を追加して、「OK」をクリックします。
「ユーザー/アプリケーション・ロール権限」ダイアログで「OK」をクリックし、「アプリケーション・ロール」ダイアログで「OK」をクリックします。
この項では、CRM業界向けアプリケーションのプライマリ役割ベースのセキュリティについて説明します。内容は次のとおりです。
第2.8.2.2項「Communications, Media, and Energy(CME)Analyticsのセキュリティ設定」
第2.8.2.4項「Pharma Sales AnalyticsおよびPharma Marketing Analyticsのセキュリティ設定」
表2-4は、消費者部門の各ダッシュボードに関連付けられる消費者部門の職責を示しています。
Oracle CME製品ファミリー(Oracle Communications, Media and Energy Sales Analytics、Oracle Communications, Media and Energy Service Analytics、Oracle Communications, Media and Energy Marketing Analytics)では、Siebel基幹業務アプリケーションのセキュリティ・モデルを使用します。つまり、Siebel基幹業務アプリケーションのオブジェクト(メタデータ・オブジェクトとプレゼンテーション・サービス・オブジェクトの両方)へのアクセスを制御するために、Siebel基幹業務アプリケーションの職責(および対応するアプリケーション・ロール)を使用します。このセキュリティ・モデルについては、第2.1項「Oracle BI Applicationsのセキュリティについて」を参照してください。
表2-5に示しているように、基幹業務アプリケーションからの職責に加えて、Oracle Communications, Media, and Energy(CME)では、追加の職責と職責固有のセキュリティが使用されます。
表2-5 CMEの各ダッシュボードに関連付けられるCMEの職責
CMEの職責 | CMEのダッシュボード | ダッシュボードのページ |
---|---|---|
CM Marketing Analyticsユーザー CM Marketing Analytics管理者 |
ロイヤルティ管理 |
|
CM Sales Analyticsユーザー CM Sales Analytics管理者 |
売上管理 |
|
- |
アカウント管理 |
|
CM Service Analyticsユーザー CM Service Analytics管理者 |
アカウント管理 |
|
次のアプリケーションは、Siebel基幹業務アプリケーションのセキュリティ・モデルを使用します。
Financial Analytics製品ファミリー(Finance Sales Analytics、Finance Service Analytics、Finance Marketing Analytics、Finance Institutional Analytics、Finance Retail Analytics)
Insurance Analytics製品ファミリー(Insurance Partner Manager Analytics、Insurance Sales Analytics、Insurance Service Analytics、Insurance Marketing Analytics、Insurance Partner Manager Analytics)
表2-6に示しているように、Siebel基幹業務アプリケーションからの職責に加えて、これらのアプリケーションでは、追加の職責と職責固有のセキュリティが使用されます。
Financial Services製品の場合、Siebel基幹業務アプリケーションのセキュリティ・モデルは次のように拡張されています。
Financial Analyticsユーザー
Financial Analyticsの会計固有オブジェクトへのアクセスを制御するためにSiebel基幹業務アプリケーションの職責とグループとともに使用する必要がある、会計固有の職責(および対応するアプリケーション・ロール)
Insurance Analytics製品ファミリー(Insurance Partner Manager Analytics、Insurance Sales Analytics、Insurance Service Analytics、Insurance Marketing Analytics、Insurance Partner Manager Analytics)のユーザー
InsuranceおよびHealthcare Analytics製品ファミリー(Healthcare Sales Analytics、Healthcare Service Analytics、Healthcare Marketing Analytics、Healthcare Partner Manager Analytics)の保険および健康保険固有オブジェクトへのアクセスを制御するために使用する必要がある、保険固有の職責(および対応するアプリケーション・ロール)
たとえば、営業員にすべての水平方向のセールス職責を提供するときに会計職責のFinancial Analyticsユーザーも含めると、このユーザーは、すべての水平方向のセールス・オブジェクト(ダッシュボード、サブジェクトエリア、プレゼンテーション・レイヤーのフォルダなど)に加えて、会計固有のセールス・オブジェクトもすべて表示できるようになります。同様に、保険および健康保険固有のオブジェクトを表示するためには、Insurance Analytics製品ファミリー(Insurance Partner Manager Analytics、Insurance Sales Analytics、Insurance Service Analytics、Insurance Marketing Analytics、Insurance Partner Manager Analytics)のユーザー職責のいずれかをこのユーザーに追加する必要があります。
Oracle BI Applicationsは、アプリケーション・ロールで階層をサポートし、ポリシー・ストア内の特定のアプリケーション・ロールは、子アプリケーション・ロールすべての動作を定義する親アプリケーション・ロールです。Financial Services Analyticsの場合、親アプリケーション・ロールは、次のとおりです。
会計(Finance)
会計アプリケーションのすべてのアプリケーション・ロールの親アプリケーション・ロール。Financial Analyticsのユーザーは、会計アプリケーション・ロールの子アプリケーション・ロールです。
保険(Insurance)
保険アプリケーションのすべてのアプリケーション・ロールの親アプリケーション・ロール。Insurance Analyticsのユーザーは、保険アプリケーション・ロールの子アプリケーション・ロールです。
親アプリケーション・ロールの権限は継承によって子アプリケーション・ロールに伝播されます。表2-6は、Financial Servicesの親アプリケーション・ロールとその目的を示しています。
注意: Financial Services Analyticsユーザーは、FinanceとInsuranceの両方の子として扱われます。そのため、このユーザーにはFinanceとInsuranceの両方に対するアクセス権があります。Financial Analyticsに加えてOracle Insurance Analytics製品ファミリー(Insurance Partner Manager Analytics、Insurance Sales Analytics、Insurance Service Analytics、Insurance Marketing Analytics、Insurance Partner Manager Analytics)のいずれかを購入した場合、すべての関連ダッシュボードを表示するには、Financial Services Analyticsユーザー職責を使用する必要があります。 |
表2-6は、追加の職責と、Oracle Financial Analytics製品ファミリー(Finance Sales Analytics、Finance Service Analytics、Finance Marketing Analytics、Finance Institutional Analytics、Finance Retail Analytics)、Oracle Insurance Analytics製品ファミリー(Insurance Partner Manager Analytics、Insurance Sales Analytics、Insurance Service Analytics、Insurance Marketing Analytics、Insurance Partner Manager Analytics)およびOracle Healthcare Analytics製品ファミリー(Healthcare Sales Analytics、Healthcare Service Analytics、Healthcare Marketing Analytics、Healthcare Partner Manager Analytics)の職責固有のセキュリティを示しています。
Usage Acceleratorも配置する場合は、表2-13に示すFinancial Services固有のUsage Acceleratorの職責を参照してください。
表2-6 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)のユーザー |
|
Pharma Sales AnalyticsおよびPharma Marketing Analyticsのデータレベルのセキュリティは、PH Executive Analyticsを除くすべてのPharma Analytics職責のSiebel役割IDに基づいています。Siebel役割IDは、常に要素テーブルを使用して解決されます。
データの表示は、管理ロールに対しては制約されません。他の役割の場合、データ表示は、役割IDによって制御されます。Oracle Business Analytics Warehouseは、ユーザー役割ベースのセキュリティ制御に対してW_POSITION_DHテーブルを使用します。ユーザーには、各自の役割で利用可能なデータのみが表示されます。このセキュリティ・モデルは、次のような次元データを排他的に処理するクエリーを除く、すべてのクエリーに適用されます。
期間
製品
招待者状況
表2-7は、Pharma Analyticsの職責と機能を示しています。
表2-7 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 Sales Analytics管理者 |
Rx Sales Analyticsのオプションに対する管理者権限。 |
PH US Call Activity Analyticsユーザー |
Call Activity Analyticsのオプションにアクセスして、ZIPテリトリーのアライメントを実行できるようになります。 |
Oracle Partner Analyticsには、ロールベースの分析の概念が組み込まれています。ロールベースの分析では、ブランド所有者がユーザーに対して、ユーザー固有のロールに基づいてダッシュボードとページを表示できます。たとえば、営業管理者がパイプラインとセールスの効果に関連するダッシュボードを表示できる一方、マーケティング管理者はキャンペーンに関連するダッシュボードを表示できます。Oracle Partner Analyticsには、サブジェクトエリアとデータへのアクセスを制御する柔軟性のあるセキュリティ・メカニズムも組み込まれています。
Oracle Partner Analyticsのロールは、Siebel基幹業務アプリケーションのSiebelの職責にマップされます。この項では、Partner ManagerアプリケーションとPartner Portalアプリケーションの両方のロールおよび関連ダッシュボードならびにページについて説明します。職責のサブジェクトエリアおよびデータレベルのセキュリティの設定についても説明します。
表2-8は、PRM Partner Portalアプリケーションの特定の職責に対するダッシュボードとページ・タブのマッピングを示しています。
表2-8 PRM Partner Portal Analyticsに対する職責
職責 | ダッシュボード | ページ・タブ名 |
---|---|---|
Partner Executive Analyticsユーザー |
パートナーエグゼクティブ |
パイプライン、製品、売上効率、サービス |
Partner Operations Analyticsユーザー |
|
|
Partner Sales Manager Analyticsユーザー |
|
|
Partner Sales Rep Analyticsユーザー |
|
|
Partner Service Manager Analyticsユーザー |
|
|
Partner Service Rep Analyticsユーザー |
|
|
表2-9は、Siebel PRM Partner Managerアプリケーションの特定の職責に対するダッシュボードとページ・タブのマッピングを示しています。
表2-9 PRM Analyticsに対するSiebelの職責
職責 | ダッシュボード | ページ・タブ名 |
---|---|---|
Channel Account Manager Analyticsユーザー |
|
|
Channel Executive Analyticsユーザー |
|
|
Channel Marketing Manager Analyticsユーザー |
|
|
Channel Operations Analyticsユーザー |
|
|
Siebel PRM Analyticsの非定型クエリーは、ユーザーの職責に応じて、Oracle BIアプリケーションのサブジェクトエリアのカラムに基づいてユーザーによって作成されます。職責に基づいたサブジェクトエリアに表示を制限することによって、PRM Analyticsでは、ブランド所有者が柔軟性のある方法でロールベースの分析を実装できるようになります。
表2-10は、Partner Managerの職責に対するサブジェクトエリアの表示を示しています。Xは、サブジェクトエリアがその職責を持つユーザーに対して表示されることを示します。
表2-10 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 |
- |
表2-11は、Partner Portalのロールに対するサブジェクトエリアの表示を示しています。Xは、サブジェクトエリアがその職責を持つユーザーに対して表示されることを示します。
表2-11 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 |
PRM Analyticsでは、ブランド所有者がユーザーの組織または役割に基づいて、セキュリティを制限することも可能です。このセキュリティ・メカニズムでは、あるユーザーが別のユーザーのデータへのアクセス権を持たないことが保証されます。また、あるパートナーが別のパートナーのデータへのアクセス権を持たないことも保証されます。データレベルのセキュリティは、職責に対して管理されます。データレベルの表示を設定する方法の詳細は、第2.2.2項「Oracle BIリポジトリのデータレベルのセキュリティの実装」を参照してください。
表2-12は、Partner ManagerおよびPartner Portalの職責に対する組込みのデータレベルのセキュリティ設定を示しています。
表2-12 Oracle PRMのデータレベルのセキュリティ設定
職責 | データレベルのセキュリティ | タイプ | 備考 |
---|---|---|---|
Channel Executive Analyticsユーザー |
いいえ |
なし |
なし |
Channel Operations Analyticsユーザー |
いいえ |
なし |
なし |
Channel Account Manager Analyticsユーザー |
いいえ |
なし |
なし |
Channel Marketing Manager Analyticsユーザー |
いいえ |
なし |
なし |
Partner Executive Analyticsユーザー |
はい |
組織 |
表示されるレコードは、ユーザーの組織に一致する必要があります。 |
Partner Sales Manager Analyticsユーザー |
はい |
組織 |
表示されるレコードは、ユーザーの組織に一致する必要があります。 |
Partner Sales Rep Analyticsユーザー |
はい |
Position |
表示されるレコードは、ユーザーの役割に一致する必要があります。 |
Partner Service Manager Analyticsユーザー |
はい |
組織 |
表示されるレコードは、ユーザーの組織に一致する必要があります。 |
Partner Service Rep Analyticsユーザー |
はい |
Position |
表示されるレコードは、ユーザーの役割に一致する必要があります。 |
表2-13は、必要になる可能性のある追加のセキュリティ構成と、Oracle Usage Acceleratorのダッシュボードに関連付けられる特定の職責を示しています。
表2-13 Usage Acceleratorの職責とダッシュボード
ユーザーの職責 | データレベルのセキュリティ | ダッシュボード名(ビュー) | ダッシュボードのページ |
---|---|---|---|
Usage Accelerator – Sales Rep |
プライマリ役割データ・レベルのセキュリティ |
スコアカード |
個人スコアカード |
Usage Accelerator–Financial Services営業員 |
- |
アクションプラン |
アカウントカバレッジ コンタクトカバレッジ 商談カバレッジ 金融口座のカバレッジ—Financial Servicesのみ アカウントの達成度 コンタクト達成度 商談の更新 |
Usage Accelerator–営業管理者 |
役割ベースのセキュリティなし |
|
|
Usage Accelerator–Financial Services営業管理者 |
- |
|
|
Usage Accelerator–セールスエグゼクティブ |
役割ベースのセキュリティなし |
|
|
Usage Accelerator–Financial Servicesセールスエグゼクティブ |
- |
アクションプラン |
アカウントカバレッジ(組織) コンタクトカバレッジ(組織) 商談カバレッジ(組織) 金融口座のカバレッジ(組織)—Financial Servicesのみ アカウントの達成度(組織) コンタクト達成度(組織) 商談の更新(組織) |
プライマリ所有者ベースのセキュリティは、プライマリ所有者ベースのセキュリティのアプリケーション・ロールによってサポートされます。このタイプのセキュリティ・メカニズムでは、レコードはそのプライマリ所有者に対してのみ表示できます。デフォルトでは、このタイプのセキュリティはコア・ビジネス・モデルのいくつかの次元に対応しますが、他のテーブルは、プライマリ所有者のソースの「統合 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 = 'VALUEOF(NQ_SESSION.USER)'
ビジネス単位ベースのセキュリティは、プライマリ組織ベースのセキュリティのアプリケーション・ロールによってサポートされます。デフォルトでは、コア、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 = 'VALUEOF(NQ_SESSION.USER)'
この項では、JD Edwards EnterpriseOneに関するすべての情報がJD Edwards Worldにも適用されます。
この項では、Lightweight Directory Access Protocol(LDAP)を使用して、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)とJD Edwards EnterpriseOneをセキュリティ統合する方法について説明します。内容は次のとおりです。
LDAPは、JD Edwards EnterpriseOneとOracle BI EE両方に対してセキュリティ情報の中央リポジトリとして機能できるため、管理者は、両方のシステムに対して一度にセキュリティを構成できます。LDAPサーバーは、認証に必要な資格証明およびJD Edwards EnterpriseOneロールやユーザー・グループなどのユーザー・プロファイル情報を格納します。
ログイン時、Oracle BI EEサーバーは、ユーザーの資格証明をLDAPサーバーに渡し、認証を行います。認証に成功すると、Oracle BI EE初期化ブロックは、グループ名をユーザーのLDAPレコードから取得します。これらのグループ名は、Oracle BI EEセッション変数GROUPに格納され、ポリシー・ストアにあるアプリケーション・ロールのリストと照合され、適切な権限をユーザーに付与します。この情報は、ユーザーのセッション中に使用され、ユーザーがアクセスする権限を持っているアプリケーション、ダッシュボードなどのオブジェクトがどれかを判定します。
同様に、ログイン時JD Edwards EnterpriseOneのセキュリティ・カーネルは、ユーザーの資格証明をLDAPサーバーに渡します。認証に成功すると、JD Edwards EnterpriseOneのセキュリティ・カーネルは、オブジェクトとデータの両方のセキュリティに使用されるユーザーロール関係の情報を取得します。
LDAPは、ユーザーとオブジェクトのセキュリティに対してのみOracle Business Intelligence Enterprise EditionとJD Edwards EnterpriseOneの統合を提供します。LDAPは、統合されたデータのセキュリティ・ソリューションを提供できません。したがって、データのセキュリティを実装するためには、各サーバーでセキュリティを個別に構成する必要があります。このことにより、ユーザー認証をOracle Business Intelligence Enterprise EditionサーバーとJD Edwards EnterpriseOneサーバーの両方で設定する必要があります。
Oracle Business Intelligence Enterprise Editionを構成し、LDAPでユーザーの認証を行えるようにする方法については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』の代替認証プロバイダの設定に関する項を参照してください。
JD Edwards EnterpriseOneを構成し、LDAPでユーザーの認証を行えるようにする方法については、JD Edwards EnterpriseOne Toolsセキュリティ管理ガイドを参照してください。