ヘッダーをスキップ

Oracle Self-Service Human Resourcesセルフ・サービス機能実装ガイド
リリース11i
B25738-01		目次へ
目次		前のページへ
戻る		次のページへ
次へ

SSHRおよびユーザー・アクセス

ユーザー・アクセスの概要

SSHRでは、オラクル人事管理システムのアプリケーションと同じセキュリティ・メカニズムを使用します。ユーザー・プロファイル、セキュリティ・プロファイル、職責およびメニュー構成を定義することによって、SSHRの使用者、アクセス可能な情報およびアクセス方法を制御できます。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のセキュリティ概要に関する説明

このドキュメントでは、SSHRユーザーのアクセスおよびセキュリティに関する主要概念を説明し、企業のニーズにあわせてその主要概念を適用する方法を説明します。

SSHRでのユーザー・アクセスの管理

次の項では、SSHRおよびユーザー・アクセスに関してよくある質問に回答し、機能の概要を説明します。

人事部門は、各ユーザーが使用可能なセルフ・サービス・アクティビティをどのように管理できますか?

標準のOracle Applicationsで使用するセキュリティ管理（職責、メニューおよびセキュリティ・プロファイル）は、セルフ・サービス・ユーザーにも適用されます。シードされているSSHRメニュー（「従業員セルフ・サービス」、「マネージャ・セルフ・サービス」および「派遣就業者セルフ・サービス」）には、様々なユーザーを対象にした機能が集められています。従業員機能の操作対象は、現在のセルフ・サービス・ユーザーのレコードのみに制限されており、マネージャ機能のユーザーは、対象となる従業員と就業者のリストから個人を選択して、必要な機能を実行できます。各メニュー項目に対応するシード済SSHR職責は、本番使用を目的としていませんが、製品に付属する機能の検索に役立ちます。ユーザーは、独自のメニューと職責を様々に構成し、適切なセキュリティ・プロファイルと組み合せ、各ユーザー・グループを特定の機能と従業員グループに制限できます。パーソナライズ・フレームワークとOracle Workflow Builderツールを使用すると、特定機能に対するユーザーのアクセスを柔軟に管理でき、ユーザーのトランザクションがデータベースにコミットされる前に承認を求めることができます。また、ベース製品を構成して、ユーザーのアクセスを管理することもできます。たとえば、福利厚生適格プロファイルと登録要件によって、従業員が福利厚生登録機能内から選択できる福利厚生を決定できます。

従業員情報へのアクセスをどのように管理できますか?

ユーザーによるアクセスが可能なセルフ・サービス機能の管理に加えて、ユーザーによるアクセスが可能な従業員レコードを管理することもできます。従業員がアクセスできるのは自分自身の個人情報のみです。マネージャと人事担当者は、選択した従業員の個人情報にアクセスできます。このアクセスは、各ユーザー・グループが特定の従業員グループにアクセスするように制限するセキュリティ・プロファイルによって管理されます。マネージャがセルフ・サービス・メニューから機能を選択すると、部下の従業員と就業者のリストが階層に表示されます。適切な場合は、他のビジネス・グループまたは組織の従業員と就業者の検索をマネージャに許可できます。また、必要な場合は、このアクセスを表示のみに制限し、マネージャが自分のビジネス・グループ外の従業員に関するトランザクションを実行できないようにすることもできます。

従業員が自分の個人情報を第三者に公開する場合はどのようにしますか?

特定の状況（別の職階に応募した後など）では、従業員が自分の個人情報を第三者（異動先のマネージャなど）に公開することが必要な場合があります。この場合、従業員は従業員情報のリリース機能を使用して、異動先のマネージャが自分の個人情報にアクセスできるようにします。

SSHRではどのようにユーザーを作成しますか?

標準のOracle手順に従ってユーザーを作成し、そのユーザーにセルフ・サービス職責を追加することでセルフ・サービス可能にできます。あるいは、バッチ・プロセスを使用すると、複数のユーザーを一度に作成できます。バッチ・プロセスは、最初のインストール後または新規採用プロセスで大量のアカウントを作成する必要がある場合に特に役立ちます。

SSHRおよびユーザー・アクセス

ユーザー・アクセスおよびセキュリティ

次に、オラクル人事管理システムで使用される標準のセキュリティ・メカニズムの概要を示し、このメカニズムをOracle SSHRに関連付ける方法について説明します。

職責

職責は、ユーザーによるアクセスが可能な機能（機能へのユーザー・アクセス）を制御するユーザー・アクセス構成の下位レベル要素と、処理を実行できるユーザーの種類（「個人情報へのユーザー・アクセス」を参照）を結合します。

SSHR職責の定義方法は、オラクル人事管理システム・アプリケーションに対する職責の定義方法と同じです。

注意: 職責を定義するときは、Oracle Self-Service Web Applicationsでその職責が使用可能であることを確認してください。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』の職責に関する説明

管理者は、SSHRの職責所有権機能を使用して、所有しているすべての職責のリストを表示できます。この機能を使用すると、所有している各職責にアクセスできる個人のリストを表示し、必要に応じて職責へのアクセス権限を取り消すことができます。

関連項目: 職責所有権

個人情報へのユーザー・アクセス

SSHRのプライマリ・ユーザーは、マネージャと従業員（マネージャ以外）の2つの主要なグループに分類できます。

従業員（マネージャ以外）

従業員と就業者がアクセスできるのは、自分自身のレコードのみです。

マネージャ

マネージャは、「入力プロセス」ページで選択した他の従業員と就業者のレコードを処理できます。「入力プロセス」ページでは、次のようにビューの切替えが可能です。

注意: プロファイル・オプション「HR: 派遣就業者の拡張ロール」が「Yes」に設定されている場合は、派遣就業者が他の従業員を管理できるようになります。

個人検索

「入力プロセス」ページを使用すると、マネージャは、基礎となるセキュリティ・プロファイル内の従業員の基本検索ができます。あるいは、「拡張検索」ページにアクセスして、さらに詳細な検索基準を適用できます。

マネージャは、表示されたリスト内の従業員と就業者を直接処理したり、後で参照するためにリストに追加できます。

注意: マネージャのセキュリティ・プロファイルは、従業員情報のリリース機能を使用可能にすることで拡張できます。

関連項目: 従業員情報のリリース

一部の機能を使用すると、マネージャと人事担当者は、退職した従業員を検索できます。

関連項目:

この拡張検索機能は機能パラメータで制御されます。

関連項目: メニュー機能パラメータの説明

構成オプション

特定の機能を必要に応じて除外することにより、担当検索機能へのユーザー・アクセスを制御できます。たとえば、個人検索機能を非表示にすることで、マネージャが処理できるレコードを、階層に表示された従業員と就業者のレコードのみに制限できます。

関連項目: ユーザー・アクセスおよびメニューの定義

プロファイル・オプションを割り当てることで、マネージャによる従業員と就業者の検索方法も制御できます。たとえば、「HR: 複数ビジネス・グループ間」プロファイル・オプションを適用すると、マネージャは複数のビジネス・グループにわたる検索が可能になります。さらに、「HR: SSHRでの複数国別仕様間のトランザクション制限」プロファイルを「Yes」に設定すると、他の国別仕様内の従業員と就業者の名前が使用不可になります。

セキュリティ・プロファイル

SSHRでは、セキュリティ・プロファイルを使用して、ユーザーによる個人レコードへのアクセスを制御します。たとえば、セキュリティ・プロファイルによって、マネージャは部門内の全従業員と全就業者のレコードにアクセスできます。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のセキュリティ・プロファイルに関する説明

従業員（マネージャ以外）および派遣就業者

従業員機能によって、ユーザーがアクセスできるのは自分自身のレコードのみに制限されているため、従業員（マネージャ以外）の職責については、対応するビジネス・グループに対してデフォルトの「全表示」セキュリティ・プロファイルを使用できます。

マネージャ

マネージャによる検索機能へのアクセスを可能にするには、適切なセキュリティ・プロファイルの作成が必要です。ほとんどのSSHRマネージャにとって最も適切なセキュリティ・プロファイルは、管理者階層に基づくプロファイルです。このタイプのセキュリティ・プロファイルによって、管理者階層または管理者アサイメント階層（現在のユーザーから始まる）に基づいた従業員のリストが動的に生成されます。このタイプのプロファイルの利点は、単一のセキュリティ・プロファイルを設定し、複数のユーザーに対して使用できることです。管理者セキュリティを有効にするには、「セキュリティ・プロファイル」ウィンドウで「管理者による制限(個人ベース)」または「管理者アサイメントによる制限(アサイメントベース)」のいずれかのオプションを選択します。この場合、マネージャは、少なくとも1つのアサイメントを持つ個人（管理者）のレコードを表示でき、その個人の直接レポートも表示できます。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』の管理者階層別のセキュリティ・プロファイルに関する説明

個々のアサイメントに基づいて管理者階層を構築することもできます。これは、SSHRマネージャが特定のアサイメントの管理者である場合のみ個人のレコードを表示および更新できることを意味します。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のアサイメント・レベルのセキュリティに関する説明

複数アサイメント

マネージャが従業員と就業者の複数アサイメントを表示および更新できるようにする場合は、SSHRシステム・プロファイル「HR: SSHRでの複数アサイメント使用可能」を使用します。

注意: アサイメント・ベースのセキュリティを使用している場合は、このプロファイル・オプションを使用可能にする必要があります。

このプロファイルを「No」に設定すると、マネージャはプライマリ・アサイメントのみ表示および更新できます。このプロファイルを「Yes」に設定すると、マネージャは、セキュリティ階層全体で自分にレポートしているアサイメントのみを表示および更新できます。

注意: 「セキュリティ・プロファイル」ウィンドウのユーザー・ベース・セキュリティ・タブで「プライマリ・アサイメントのみ」チェック・ボックスを選択すると、マネージャがプライマリ・アサイメント情報のみ表示および更新するように制限できます。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のセキュリティ・プロファイルの定義に関する説明

または、SSHRマネージャ職責に対して検索機能を使用不可にすることもできます。この場合は、「全表示」セキュリティ・プロファイルをユーザーに割り当てることができます。

リリース情報

リリース情報機能によって、セキュリティ・プロファイルに表示される個人のリストを補足できます。ユーザーは、この機能を使用して、他のユーザー（セキュリティ・プロファイル外のユーザー）によるレコードへのアクセスを可能にできます。同様に、マネージャは、リリース情報機能を使用して、別のマネージャ（セキュリティ・プロファイル外のマネージャ）による従業員レコードへのアクセスを可能にできます。

この機能の典型的な使用例として、ある従業員が別の組織への異動を希望している場合を考えてみます。異動先のマネージャは、異動の前に、その従業員の不就業履歴を検討する必要があります。しかし、このマネージャは、その従業員の現行ビジネス・グループに属していないため、人事管理システムのセキュリティ・アクセスによってアクセスが制限されています。つまり、定義されているセキュリティ・プロファイルによって、マネージャは「個人検索」からその従業員のデータにアクセスできません。リリース情報機能を使用すると、アクセス権限を付与する従業員は、すべての組織とビジネス・グループからそのマネージャの名前を検索してアクセス権限を付与できます。これによって、マネージャはその従業員の不就業履歴を表示できます。ただし、このマネージャに次の条件を満たす職責があることを確認する必要があります。

企業内のマネージャに対して、部下の従業員と同じように権限付与先の従業員の権限を持たせる場合は、そのマネージャが主要なマネージャ・セルフ・サービス職責で使用するセキュリティ・プロファイルの権限付与アクセスを許可をオンにできます。または、権限付与先の従業員に対するマネージャの機能を制限することもできます。たとえば、マネージャが表示できるビューを制限し、退職などの機能は使用できないようにします。これを行うには、主要なセキュリティ・プロファイルの権限付与アクセスを許可チェック・ボックスをオフにし、使用可能な機能を制限した別のセキュリティ・プロファイルの権限付与アクセスを許可チェック・ボックスをオンにします。

関連項目: リリース情報

機能へのユーザー・アクセス

機能セキュリティを使用すると、特定の機能へのユーザー・アクセスを制御できます。機能はメニューに結び付けられてから、職責に結び付けられます。

ナビゲーション・パス

SSHRユーザーの従来のナビゲーション・パスは、ユーザー・メニューから機能（「個人情報」や「マネージャの変更」など）を直接選択します。SSHR 4.2以降は、この方法をサポートしながら、「処理」ページを使用する新しいナビゲーション・パスも導入しています。

「処理」ページからの機能へのアクセス

ユーザーは、メニューから特定の機能を選択するかわりに、個人の処理機能（従業員と就業者用）またはマネージャ処理機能（マネージャ用）のいずれかを選択します。SSHRでは、使用可能な機能のコンテキスト依存リストを表示します。

個人の処理

「処理」ページには、従業員または就業者が使用できる機能のリストが表示されます。このコンテキスト依存リストを生成するために、SSHRでは、「HR: 個人の処理メニュー」プロファイル・オプションに定義されているサブメニューを取得し、ユーザーのビジネス・グループの国別仕様コードと一致しない国別仕様機能を除外します。

マネージャ処理

マネージャの場合は、最初に「入力プロセス」ページが表示されます。このページから従業員のアサイメントを選択できます。次に、「処理」ページに進むと、選択した従業員または就業者に対して使用可能な機能のリストが表示されます。SSHRでは、「HR: マネージャ処理メニュー」プロファイル・オプションに定義されているサブメニューを取得し、選択した個人のビジネス・グループの国別仕様コードと一致しない国別仕様機能を除外することによって、機能のリストを導出します。

注意: マネージャが最初に自分自身のレコードを選択した場合、サブメニューは「HR: 個人の処理メニュー」プロファイル・オプションを使用して導出されます。

メニューからの機能への直接アクセス

マネージャ

ユーザーがメニューから直接選択したマネージャ機能は、最初に「入力プロセス」ページで表示されます。このページから処理対象の従業員を選択できます。次に、「有効日」ページを介して、機能に対応するWebページが表示されます。

注意: ユーザーが個人を選択すると、データ・セキュリティが開始します。機能固有の国別仕様が、選択した個人が属する国別仕様と異なる場合は、エラー・メッセージが表示されます。

その他の従業員

ユーザーがメニューから直接選択した従業員機能は、必要な場合は「有効日」ページを介して、その機能に対応するWebページに表示されます。

注意: ユーザーが機能を選択すると、データ・セキュリティがチェックされます。機能固有の国別仕様が、ユーザーが属する国別仕様と異なる場合は、エラー・メッセージが表示されます。

国別仕様機能

ほとんどのSSHR機能はグローバルで、すべての国別仕様の従業員に対して使用できます。ただし、一部の機能は国別仕様に固有であるため、対応する国別仕様の従業員に制限する必要があります。

SSHRでは、FNDデータ・セキュリティを使用してこの制限を適用します。データ・セキュリティ・オブジェクトは個人と国別仕様の組合せで定義され、データ・セキュリティ・メニューは事前定義の機能に対して作成されています。データ・セキュリティ・メニューには、グローバル機能用と各国別仕様コード用があります。事前定義された機能は、グローバル機能用のデータ・セキュリティ・メニューまたは国別仕様コード用の1つ以上のデータ・セキュリティ・メニューのいずれかに必要に応じて関連付けられます。

データ・セキュリティの権限付与は、各データ・セキュリティ・メニューを適切な国別仕様コード（グローバル・メニューの場合はすべての国別仕様コード）に関連付けて事前定義されています。各権限付与によって、ビジネス・グループ内で対応する国別仕様コードを持つ個人に対して、対応するデータ・セキュリティ・メニューに関連した機能を使用可能にすることができます。

たとえば、グローバルなデータ・セキュリティ・メニューにある機能はすべての従業員が使用できますが、米国のデータ・セキュリティ・メニューにある機能を使用できるのは、米国ビジネス・グループの従業員のみです。

事前定義された機能で使用可能なデータ・セキュリティ・メニューの他に、カスタム機能を付加できる一連のデータ・セキュリティ・メニューがあります。データ・セキュリティの権限付与はすでに行われています。

関連項目: データ・セキュリティ・メニュー

ユーザーと職責

SSHRユーザーの定義方法は、オラクル人事管理システム・アプリケーションに対するユーザーの定義方法と同じです。

関連項目: 『Oracle Applicationsシステム管理者ガイド』の「ユーザー」ウィンドウに関する説明

ただし、「ユーザー」ウィンドウの「個人」フィールドは、専門ユーザー・インタフェースとSSHRとの間のリンクとして機能するため、SSHRにとっては特に重要です。このフィールドによって、ユーザー名が正しい個人レコードにリンクされます。たとえば、ユーザーを作成してSSHR職責を割り当てる場合は、「個人」フィールドにユーザー名を入力すると、正しい従業員レコードのみがSSHRに表示されます。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』の職責に関する説明

新規ユーザー登録

新規ユーザー登録機能を使用すると、新規ユーザーは、自分自身の詳細情報を登録し、SSHR用に独自のユーザーを作成できます。また、ユーザーがWebページでボタンをクリックするとユーザー名が生成されるユーザー・フックも追加できます。

新規ユーザー登録機能は、従業員と従業員以外の両方に対して使用可能にできます。従業員以外の登録フォームは、通常、Oracle Advanced Benefitsとともに使用します。

関連項目: 新規ユーザー登録

ユーザー・プロファイル

ユーザー・プロファイルを適用して、SSHRアプリケーションの実行方法を制御します。プロファイル・オプションは、サイト・レベル、アプリケーション・レベル、職責レベルおよびユーザー・レベルで設定できます。各プロファイル・オプションは、各モジュールのセクション内に指定されています。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のユーザー・プロファイルに関する説明

機能へのユーザー・アクセス

マネージャ機能および従業員機能

ユーザー・メニューに機能を追加したり削除することによって、従業員、就業者およびマネージャがアクセスできる機能を制御できます。たとえば、退職機能をマネージャ・メニューにのみ表示することによって、従業員によるこの機能へのアクセスを制限できます。

関連項目: ユーザー・アクセスおよびメニューの定義

セルフ・サービス処理のアクセス・ロール

アクセス・ロールによって、ルーティングされたトランザクション（セルフ・サービス処理など）を表示または更新する権限が指定されます。セルフ・サービス処理のアクセス・ロールは、「ロールの保守」ウィンドウで管理します。

SSHRには、セルフ・サービス処理での更新権限を管理するアクセス・ロールの作成に使用できる事前定義済の2種類のタイプが用意されています。

デフォルトでは、すべてのユーザーが処理を更新できます。「SSHR更新許可」タイプを使用してロールを定義し、あるユーザーに割り当てると、他のユーザーは処理を更新できなくなります。「SSHR更新不可」タイプを使用してロールを定義し、あるユーザーに割り当てると、他のユーザーは処理を更新できます。

同じ導入で両方のタイプを使用することはできません。大多数のユーザーに更新権限が必要かどうかに応じて、どちらのタイプを使用するかを決定します。大多数のユーザーに更新権限が必要な場合は、更新不可タイプを使用して、権限が不要なユーザーの編集権限を削除します。ほとんどのユーザーに更新権限が不要な場合は、更新許可タイプを使用して、権限が必要なユーザーに編集権限を付与します。組織に40,000名の従業員がいて、そのうち80名にセルフ・サービス処理の更新権限が必要な場合は、39,920名の権限を否認するのではなく、80名に権限を付与するほうが合理的です。

注意: 職階管理および予算計画機能でも、ロール・タイプを使用してルーティングと承認のロールを設定します。事前定義の「ライン・マネージャ」、「HRマネージャ」または「予算計画マネージャ」ロール・タイプは、セルフ・サービス処理では使用しないでください。

関連項目: 『Oracle HRMSユーザーズ・ガイド（日本仕様）』のトランザクションのワークフロー・ロールの定義に関する説明

セルフ・サービスのメニューおよびユーザー・アクセス

SSHRでは、最上位メニュー、サブメニュー、非表示サブメニューおよびデータ・セキュリティ・メニューの4つのタイプのメニューを使用します。この後の項で、各メニューについて詳しく説明します。

事前定義のメニューは、SSHRパッチが適用されるたびに上書きされるため、メニューに加えた変更は失われます。このため、従業員用に少なくとも1つ、マネージャ用に少なくとも1つの最上位メニューを作成する必要があります。

注意: 各メニューにすべての従業員機能とマネージャ機能を追加した後で、職責に対してメニュー除外を定義してユーザー・グループから特定の機能を除外すると、同じメニューをいくつも構成せずに済みます。

関連項目: SSHR用メニューの定義

メニューのタイプ

最上位メニュー

最上位メニューは、ユーザーがSSHRにログインしたときにメニューに表示される選択肢を定義します。たとえば、従業員セルフ・サービス職責の最上位メニューは「従業員セルフ・サービス」メニューです。

関連項目: ユーザー・アクセスおよびメニューの定義

サブメニュー

サブメニューは、最上位メニューの機能を論理グループにグループ化します。たとえば、専門詳細機能は、「マネージャ専門詳細」サブメニューにグループ化されます。SSHRの事前定義のサブメニューは、次のとおりです。

非表示サブメニュー

プロンプトを定義せずにサブメニューを最上位メニューに結び付けると、機能を職責に割り当てるのみで、ユーザーには表示されないようにできます。つまり、ユーザーはこれらの機能を直接選択できません。SSHRの事前定義の非表示サブメニューは、次のとおりです。

SSHRでは、これらのサブメニューを使用して、他の場所で機能を使用できるかどうかを決定します。たとえば、マネージャ入力プロセス・サブメニューでは、マネージャ入力プロセス・ページに表示するタブ・リージョンが制御されます。「マネージャ処理」メニューでは、「処理」ページでマネージャが他の従業員に対して実行できる機能が制御されます。「個人の処理」メニューでは、「個人の処理」ページでユーザーが使用できる機能が制御されます。このメニューでは、マネージャが自分自身のレコードを選択したときに「処理」ページから使用できる機能も制御されます。

データ・セキュリティ・メニュー

SSHRでは、データ・セキュリティ・メニューを使用して、グローバルな機能および特定の国別仕様用の機能を決定します。

SSHRのデータ・セキュリティ・メニューは、次のとおりです。

従業員用メニュー（マネージャ以外）

新しい従業員メニューを作成し、個人の処理機能を使用する場合は、新規メニューに次のサブメニューを追加する必要があります。

派遣就業者が新規従業員メニューを使用する予定の場合は、「個人の処理メニュー」のかわりに「派遣就業者個人処理メニュー」を追加してください。

次の機能も新規メニューに追加する必要があります。

新規従業員メニューを使用する職責に対する次のプロファイル・オプションの値が、前述の選択した個人の処理サブメニュー名と一致していることも確認する必要があります。

マネージャ用メニュー

新しいマネージャ・メニューを作成し、マネージャ処理機能を使用する場合は、新規メニューに次のサブメニューを追加する必要があります。

派遣就業者が新規マネージャ・メニューを使用する予定の場合は、「個人の処理メニュー」のかわりに「派遣就業者個人処理メニュー」を追加してください。

次の機能も新規メニューに追加する必要があります。

新規マネージャ・メニューを使用する職責に対する次のプロファイル・オプションの値が、前述の選択したマネージャ処理サブメニュー名および個人の処理サブメニュー名と一致していることも確認する必要があります。

事前定義のセルフ・サービス職責とユーザー・メニュー

SSHRモジュールには、事前定義の職責からアクセスでき、それぞれに対応する最上位メニューがあります。

このバージョンのSSHRでは、次の事前定義の職責が用意されています。

US連邦政府の事前定義の職責は、次のとおりです。

HR Foundationアプリケーションの事前定義の職責は、次のとおりです。

OSSWA（Oracle Self-Service Web Applications）で提供される追加の職責は、次のとおりです。

注意: これらの職責は、開始時にのみ使用する目的で提供されています。事前定義のSSHR職責とメニューを例として使用して、独自の職責とメニューを作成してください。独自に作成しておかないと、アップグレード時に変更内容が失われる可能性があります。

関連項目: ユーザー・アクセスおよびセキュリティ

ユーザー・メニュー

SSHRには、事前定義の最上位メニューがいくつか用意されています。

SSHRには、事前定義のUS連邦政府の最上位メニューがいくつか用意されています。

「従業員セルフ・サービス」メニューには、従業員が自分自身のレコードに対して実行できる機能（例: 個人情報詳細機能）が含まれています。「マネージャ・セルフ・サービス」メニューには、従業員メニューと同じ機能に加えて、部下に対して実行できるその他の機能が含まれています。

「人事担当者」メニューは、従業員に関する要約情報を参照する人事担当者が使用できます。

管理目的で次のメニューを使用することもできます。

関連項目: セルフ・サービスのメニュー

機能のナビゲーション・オプション

従業員とマネージャはともに、2つの方法で機能にアクセスできます。前述のメニューを使用し、対応するメニュー・オプションを使用して機能を選択する方法、あるいは「マネージャ処理」または「個人の処理」メニューから「処理」ページを表示し、使用可能な処理リストから機能を選択する方法があります。

国別仕様メニュー

SSHRには、国に固有の機能にアクセスできる国別仕様メニューが用意されています。

関連項目: セルフ・サービスのメニュー

職責所有権

職責所有権機能を使用すると、管理者または導入担当者は所有している職責のリストを表示できます。職責リストを拡張すると、各職責に結び付けられているメニューと機能が表示されます。職責リストから、各職責にアクセスできる組織内（使用中のHRセキュリティ・アクセス環境内）および組織外（使用中のHRセキュリティ・アクセス環境外）のユーザー数を確認できます。ユーザー数をクリックすると、職責にアクセスできる各ユーザーのユーザーIDとその他の情報を表示できます。必要に応じて、セルフ・サービス・ページで直接アクセス権限を取り消すことができます。職責へのアクセス権限を取り消すと、影響を受けるユーザーは変更通知を受け取ります。

注意: 通知が生成されるときにビジネス・イベントもトリガーされます。このビジネス・イベントに加入し、職責アクセスを終了させるApplication Program Interface（API）をコールできます。

関連項目: 『Oracle Workflow開発者ガイド』のイベント加入に関する説明

職責所有権機能を補助的なセキュリティ手段として使用すると、特定の職責にアクセスできる組織外のユーザー数を検討および制限できます。また、監査目的で、各職責にアクセスできるユーザー数を監視することもできます。

メニューおよび機能名

このモジュールは、次のメニューと機能からアクセスできます。

ユーザー・メニュー名 機能名
職責所有権 職責所有権

ワークフロー

このモジュールのワークフロー詳細は、次のとおりです。

ワークフロー・プロセス表示名

適用不可

構成可能なワークフロー属性

適用不可

構成可能なプロファイル・オプション

適用不可

追加の構成手順

  1. 職責所有権機能を使用する前に、データ・セキュリティ権限付与を作成して職責をユーザーにリンクする必要があります。

    関連項目: 職責所有権のデータ付与の作成

    関連項目: 『Oracle Applicationsシステム管理者ガイド』のデータ付与の作成に関する説明

  2. 次のビジネス・イベントに加入するためのコードを作成する必要があります。

    このコードは、職責割当を終了させるfnd_user_resp_groups_api.update_assignment APIをトリガーする必要があります。

    関連項目: ビジネス・イベント加入用のサンプル・コード（職責所有権）

ビジネス・イベント加入用のサンプル・コード（職責所有権）

職責所有権機能を使用している場合は、次のビジネス・イベントに加入するためのPL/SQLコードを作成する必要があります。

注意: このコードは、職責割当を終了させる次のApplication Program Interface（API）をコールする必要があります。

サンプルコードは次のとおりです。このコードを基にして独自のコードを作成できます。

コード・パッケージ・ヘッダー

SET VERIFY OFF
WHENEVER OSERROR  EXIT FAILURE ROLLBACK;
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
SET SCAN OFF;
REM ---------------------------------------------------------------------------+
REM Name        : cust_resp_owner_bevent (HEADER)
REM File        : cust_resp_owner_bevent.pkh
REM Description : Used to revoke fnd_users' responsibility
REM
REM Change List
REM -----------+
REM
REM Version Date        Author      Bug       Description of Change
REM -------+-----------+----------+---------+--------------------------+
REM 01-JAN-2005         Developer             Created
REM --------------------------------------------------------------------------+

CREATE OR REPLACE PACKAGE cust_resp_owner_bevent AUTHID CURRENT_USER AS

FUNCTION revoke_access_wfevent_subscrb
( p_subscription_guid  in raw,
  p_event              in out NOCOPY wf_event_t)
RETURN VARCHAR2;

END cust_resp_owner_bevent;

/
--sho err;
commit;
exit;

コード・パッケージ・ボディ

Set Verify Off
whenever sqlerror exit failure rollback;
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
REM ---------------------------------------------------------------------------
REM Name        : cust_resp_owner_bevent (BODY)
REM File        : cust_resp_owner_bevent.pkb
REM Description : Used to revoke fnd_users' responsibility.
REM
REM Change List
REM -----------
REM
REM Version Date        Author     Version    Description of Change
REM -------+-----------+----------+---------+---------------------------------
REM 01-JAN-2005         Developer  115.0      Created.
REM --------------------------------------------------------------------------+

CREATE OR REPLACE PACKAGE BODY cust_resp_owner_bevent AS
--
--private procedure called by remove_resp
--this is a sample of how u can achieve the action
--
PROCEDURE archive_data
  (p_user_id  IN  NUMBER,
   p_user_name IN VARCHAR2,
   p_resp_id IN NUMBER,
   p_resp_appl_id IN NUMBER,
   p_security_group_id IN NUMBER,
   p_justification IN VARCHAR2,
   p_status IN VARCHAR2) IS

  l_login_person_id number;

BEGIN

  l_login_person_id := fnd_global.user_id;

  INSERT INTO CUST_RESP_OWNER_ARCHIVE
     (REVOKE_ID,
      USER_ID,
      RESPONSIBILITY_ID,
      REVOKE_JUSTIFICATION,
      REVOKE_DATE,
      REVOKED_BY,
      STATUS)
  VALUES
     (CUST_RESP_OWNER_ARCHIVE_S.nextval,
      p_user_id,
      p_resp_id,
      p_justification,
      sysdate,
      l_login_person_id,
      p_status);

EXCEPTION
  WHEN OTHERS THEN
    NULL;

END archive_data;

--
--private procedure called by revoke_access_wfevent_subscrb
--
PROCEDURE remove_resp
  (p_user_id  IN  NUMBER,
   p_resp_id IN NUMBER,
   p_resp_appl_id IN NUMBER,
   p_security_group_id IN NUMBER,
   p_error OUT VARCHAR2,
   p_justification IN VARCHAR2) IS

  cursor csr_user_name(v_user_id in number) is
  select user_name
  from fnd_user
  where user_id = v_user_id;

  cursor csr_user_resp_groups is
  select description
    from fnd_user_resp_groups
   where user_id = p_user_id
     and responsibility_id = p_resp_id;

  l_user_name fnd_user.user_name%type;
  l_owner_name fnd_user.user_name%type;
  l_description varchar(2000);
  l_login_person_id number;

BEGIN

  l_login_person_id := fnd_global.user_id;

  OPEN csr_user_name(p_user_id);
  FETCH csr_user_name into l_user_name;
  CLOSE csr_user_name;

  OPEN csr_user_name(l_login_person_id);
  FETCH csr_user_name into l_owner_name;
  CLOSE csr_user_name;

  OPEN csr_user_resp_groups;
  FETCH csr_user_resp_groups into l_description;
  CLOSE csr_user_resp_groups;

  BEGIN
    Fnd_User_Resp_Groups_Api.update_assignment(
      USER_ID => p_user_id,
      RESPONSIBILITY_ID => p_resp_id,
      RESPONSIBILITY_APPLICATION_ID  => p_resp_appl_id,
      SECURITY_GROUP_ID => p_security_group_id,
      START_DATE => SYSDATE - 2,
      END_DATE => SYSDATE - 1,
      DESCRIPTION => substr('RO:'||l_owner_name||':'||l_description,1,240)
      );

    p_error := 'Status  SUCCESSFUL!';

  EXCEPTION
    WHEN OTHERS THEN
      p_error := SQLERRM;
  END;

  --Helpdesk.remove_resp
  --  (p_username => l_user_name,
  --   resp_code => to_char(p_resp_id),
  --   p_error => p_error,
  --   p_description => substr('RO:'||l_owner_name||':'||l_description,1,240));

  archive_data(
    P_USER_ID => p_user_id,
    P_USER_NAME => l_user_name,
    P_RESP_ID => p_resp_id,
    P_RESP_APPL_ID  => p_resp_appl_id,
    P_SECURITY_GROUP_ID => p_security_group_id,
    p_justification => p_justification,
    p_status => p_error
    );

EXCEPTION
  WHEN OTHERS THEN
    NULL;
END remove_resp;

-- ---------------------------------------------------------------------------+
-- revoke_access_wfevent_subscrb is called by the workflow business event
-- oracle.apps.per.selfservice.respowner.revoke_access
-- ---------------------------------------------------------------------------+

FUNCTION revoke_access_wfevent_subscrb
( p_subscription_guid  in raw,
  p_event              in out NOCOPY wf_event_t)
RETURN VARCHAR2

IS

I number := 0;
usrIdCnt number := 0;
l_error varchar2(2000) := null;

BEGIN
usrIdCnt := to_number(p_event.GetValueForParameter('USER_COUNT'));

FOR I IN 1 .. usrIdCnt LOOP

  remove_resp
   (p_user_id => to_number(p_event.GetValueForParameter('USER_ID'||to_char(I)))
   ,p_resp_id => to_number(p_event.GetValueForParameter('RESP_ID'))
   ,p_resp_appl_id => to_number(p_event.GetValueForParameter('RESP_APPL_ID'))
   ,p_security_group_id => to_number(p_event.GetValueForParameter
                                  ('SECURITY_GROUP_ID'))
   ,p_error => l_error
   ,p_justification => p_event.GetValueForParameter('MESSAGE'));

END LOOP;

COMMIT;

RETURN 'SUCCESS';

EXCEPTION
 WHEN OTHERS THEN
   WF_CORE.CONTEXT('PER_RESPOWNER_UTIL_SS', 'revoke_access_wfevent_subscrb', p_event.getEventName(), p_subscription_guid);
     WF_EVENT.setErrorInfo(p_event, l_error);
     RETURN 'ERROR';
END revoke_access_wfevent_subscrb;

END cust_resp_owner_bevent;

/
show errors;
commit;
exit;

PL/SQLの使用方法の詳細は、『Oracle Applications開発者ガイド』のアプリケーションにおけるPL/SQLの使用方法の概要に関する説明を参照してください。

職責所有権のデータ付与の作成

データ付与によって、データ・セキュリティ・システムのデータへのアクセスを制御できます。データ付与の作成では、データベース・オブジェクトへのアクセス権限をユーザーに付与します。職責所有権機能の場合は、データ付与を使用して職責所有権をユーザーに付与します。次の図に、データ付与の概念を示します。

テキストで説明されている画像

データ付与では、ユーザー（被付与者）を特定のデータ・セット・インスタンス（データ・オブジェクトの行）にリンクします。さらに、機能セットをユーザーにリンクします。これによって、そのユーザーによる特定機能（この場合は職責所有権機能）へのアクセスが可能になります。

データ付与を他の目的に使用する方法については、『Oracle Applicationsシステム管理者ガイド』のデータ・セキュリティの概要に関する説明を参照してください。

職責所有権のデータ付与を作成する手順

  1. 最初に、職責の所有権を付与する必要があるユーザーを識別します。このユーザーは、人事マネージャ、財務マネージャ、システム管理者など、管理ロールを持つユーザーです。

  2. 機能管理者職責を使用して付与を作成します。

  1. 「付与」タブを選択します。

  2. 「付与」ページで、「付与の作成」をクリックして作成プロセスを開始し、データ付与を定義します。

  3. 「名前」フィールドに、付与を説明する名前を入力します（例: <職責名>-所有権）。摘要を入力することもできます。

  4. 付与の有効日を指定します。

    「セキュリティ・コンテキスト」リージョンにナビゲートし、付与に適用するコンテキストを定義します。

  5. 「被付与者タイプ」フィールドで、「特定のユーザー」を選択します。

  6. 「被付与者」フィールドに、職責の所有者として指定する個人のユーザーIDを入力します。

    「データ・セキュリティ」リージョンにナビゲートします。

  7. 「オブジェクト」フィールドに、次の提供オブジェクトを入力します。

  8. 職責所有権機能用に、オブジェクト表の特定インスタンスへのアクセス権限を付与するデータ・セットを作成する必要があります。このオプション（インスタンス）を選択した後、次のページに進んでそのインスタンスの情報を入力します。

  9. データ・セット・インスタンスは、3つの情報セグメントで構成されています。情報を入力し、残りのフィールドはブランクのままにします。

    主キー 例
    職責ID 50101
    アプリケーションID 800
    セキュリティ・グループID 0

    注意: データ・セットの情報を確認するには、「ユーザー」ウィンドウでユーザーを問い合せ、「職責」ブロックから「ヘルプ」→「診断」→「検査」の順に選択します。「フィールドおよび変数の値の検査」ウィンドウで次のフィールドを問い合せます。

  10. 「セット」フィールドに、提供オブジェクト・セットPRIMARY_OWNERを入力します。

    注意: この機能セットは、職責所有権機能で使用するために提供されています。

    この場合、機能セットは職責所有権機能が含まれるデータ・セキュリティ・メニューです。

  11. 「終了」をクリックしてデータ付与作成プロセスを完了します。これで、指定された所有者がSSHRにログインし、職責所有権機能を使用して各職責へのアクセスを管理および制御できるようになります。

    関連項目: 職責所有権

検討および保守する必要がある各職責についてステップ1から11を繰り返します。

SSHRユーザー・アカウント

ユーザー・アカウントのバッチ作成

すべてのオラクル人事管理システム・ユーザーは、ユーザー名、パスワードおよび職責を登録する必要があります。ユーザー・アカウントの作成または削除は、作業に時間がかかる場合があります。特に、職責をセキュリティ・プロファイルとメニューに関連付けてユーザー・アクセスを制限している場合は、時間がかかります。

オラクル人事管理システム・アプリケーションでは、大量のユーザー・アカウント・グループの作成と管理を自動化するために、一連のコンカレント・プログラムが用意されています。このプログラムは、最初のインストール時に大量のユーザー・アカウントを作成する必要がある場合、新規採用者のユーザー・アカウントを管理する場合、または退職従業員のユーザー・アカウントを管理する場合に役立ちます。

注意: 先日付の有効日を指定したユーザーの作成はサポートされていません。

コンカレント・プログラムは次のとおりです。

ただし、コンカレント・プログラムを使用する前に、企業独自のビジネス・ルールを反映したカスタム・ロジックを記述する必要があります。これを行うために、ユーザー・フックhr_user_acct_apiが用意されています。

次のパッケージにユーザー・フック・コードのサンプルがあります。

バッチ・ユーザー作成プロセスの機能

バッチ・ユーザー作成プロセスで作成されるのは、新規職責またはバッチに作成した新規職責のプロファイル・オプションの値のみです。これは、オラクル人事管理システム・アプリケーション専用の機能です。バッチ・プロセスでは、セキュリティ・プロファイルは作成されません。ただし、オラクル人事管理システムでは、セキュリティ・プロファイルを作成すると、そのセキュリティ・プロファイルをバッチ・プロセスでユーザーに作成した新規職責に割り当てることができます。バッチ・プロセスでは、職責またはユーザーのセキュリティ属性は作成されません。

職責名の付いたEメールIDを使用することが考えられます。たとえば、EメールID JSMITHをマネージャ・セルフ・サービス職責に関連付けると、JSMITH_MSSとなります。オラクル人事管理システムでマネージャにセキュリティ・プロファイルを設定した場合は、そのセキュリティ・プロファイル名をユーザー、職責およびセキュリティ・プロファイルに関連付けることができます。たとえば、セキュリティ・プロファイル名がSEC_PFの場合は、JSMITH_MSS_SEC_PFとなります。

バッチ・プロセス用のテンプレート職責を作成できます。テンプレート職責を作成する場合または事前定義のマネージャ・セルフ・サービス職責を使用する場合は、ユーザー・フックで作成した新規職責をコード化し、そのテンプレート職責の属性を継承できます。次に、APIの連絡エリアhr_user_acct_utilityに値を設定して、テンプレート職責の属性を上書きできます。

ユーザー・アカウントの作成

コンカレント・プログラムを使用したバッチ・ユーザー・アカウントの作成

ユーザーのバッチを作成するには、最初に、独自のカスタム・ロジックを使用してユーザー・フックを記述する必要があります。

関連項目: バッチ・ユーザー・アカウント作成のためのユーザー・フックの記述

ユーザー・フックを作成した後は、一連のコンカレント・プログラムを実行して、ユーザーのバッチ作成を継続して管理できます。

コンカレント・プログラムは「要求の発行」ウィンドウから実行します。

コンカレント・プログラムを使用してユーザー・アカウントのバッチを作成する手順

  1. ユーザー・アカウント従業員抽出プロセスを実行します。

    このプログラムは、従業員レコードを抽出し、作成または無効にするユーザー・アカウントのバッチ・ファイルを作成します。

  2. Data Pumpエンジンを実行します。

    このプログラムは、従業員抽出プロセスのバッチを使用して人事システムAPIをコールし、ユーザー・アカウントを作成または無効にします。

  3. Data Pumpバッチ例外レポートを発行します。

    このプログラムはData Pumpエンジンでのエラーをレポートします。

ユーザー・アカウント従業員抽出プロセス

この抽出プロセスでは、Data Pumpエンジンで使用する出力レコードを作成します。Data Pumpエンジンでは、hr_user_acct_apiをコールして、ユーザー・アカウントを作成または無効にします。

バッチ名は、HR_PUMP_BATCH_HEADERS表に記述されます。抽出された従業員レコードは、HR_PUMP_BATCH_LINES表に記述されます。バッチ・ライン表には一般的な属性が定義されていますが、Data Pumpは、各APIに対して、そのAPIのパラメータを反映したビューをHR_PUMP_BATCH_LINES表に生成します。

hr_user_acct_api用に調整した特別なビューは次のとおりです。

注意: バッチ名には、実行タイプや日付範囲または別のパラメータなどを使用して、理解しやすい名前を付けてください。実行する従業員Data PumpプロセスおよびData Pumpバッチ例外レポート・プロセスで選択するバッチは、バッチ名によってのみ識別できます。

ユーザー・アカウント従業員抽出プロセスを実行する手順

  1. ユーザー・アカウント従業員抽出プロセス・コンカレント・プログラムにアクセスします。

  2. バッチを識別するバッチ名を入力します。

  3. 次の日付入力パラメータを入力します。

  4. 次の組織入力パラメータを入力します。

    注意: 「組織」パラメータに入力した値は、「組織階層」、「組織階層バージョン」および「上位組織」の各パラメータに入力した値によって上書きされます。これらのパラメータは常に優先され、「組織」パラメータに入力された値を置換し、セットとして機能します。

  5. 値リストから処理オプションを選択して、「実行タイプ」入力パラメータを入力します。処理オプションは次のとおりです。

    注意: データベースから抽出された各従業員または就業者は、hr_pump_batch_line表に記録されます。hrdpv_create_user_acctビューは、作成したユーザー・アカウントをhr_pump_batch_line表にマップするために定義されています。hrdpv_update_user_acctビューは、無効にしたユーザー・アカウントをhr_pump_batch_line表にマップするために定義されています。hr_pump_batch_lines表で使用する一般的な名前ではなくAPIの列名を使用してレコードを識別するため、これらのビューにアクセスできます。

Data Pumpエンジン

Data Pumpエンジンは、hr_user_acct_apiをコールしてデータ検証およびロード操作を実行します。従業員データはhr_pump_batch_lines表に記録されます。

注意: Data Pumpエンジン・プロセスを実行する前に、ユーザー・アカウント従業員抽出プロセスを実行する必要があります。Data Pumpエンジンは、ユーザー・アカウント従業員抽出プロセスで作成されるバッチIDに依存しています。

Data Pumpエンジン・コンカレント・プログラムを実行する手順

  1. Data Pumpエンジン・コンカレント・プログラムにアクセスします。

  2. 次のパラメータを入力します。

    関連項目: 『Oracle HRMSインプリメンテーション・ガイド』のOracle HRMS Data Pumpに関する説明

従業員Data Pump例外レポート

各個人レコードは、各バッチ・ラインに記録されます。Data Pump例外レポートには、エラーがバッチ・ヘッダーから発生したか、またはバッチ・ラインから発生したかが表示されます。例外レポートのPerson IDから、エラーが発生している個人レコードを識別できます。

注意: Data Pumpエンジン・プロセスおよびData Pumpバッチ例外レポート・プロセスを実行する前に、ユーザー・アカウント従業員抽出プロセスを実行する必要があります。Data Pumpエンジン・プロセスおよびData Pumpバッチ例外レポート・プロセスは、ユーザー・アカウント従業員抽出プロセスで作成されるバッチIDに依存しています。

Data Pumpバッチ例外レポートを実行する手順

  1. Data Pumpプロセス例外レポート・コンカレント・プログラムにアクセスします。

    注意: Data Pumpエンジン・プロセスとData Pumpバッチ例外レポート・プロセスは、続けて実行できます。『Oracle Applicationsシステム管理者ガイド』のコンカレント・プロセスの概要に関する説明を参照してください。

    関連項目: 『Oracle HRMSインプリメンテーション・ガイド』のOracle HRMS Data Pumpに関する説明

バッチ・ユーザー・アカウント作成のためのユーザー・フックの記述

ユーザー・フックを記述する前に、ユーザーの数を考慮した上で、ユーザー名書式の標準、職責および企業のセキュリティ・プロファイルを作成する必要があります。標準を定義して、セキュリティ・プロファイルまたは必要なセキュリティ・グループを作成した後、ユーザー・フックの記述を開始できます。

バッチ・プロセス用のテンプレート職責を作成できます。テンプレート職責を作成する場合または事前定義のマネージャ・セルフ・サービス職責を使用する場合は、ユーザー・フックで作成した新規職責をコード化し、そのテンプレート職責の属性を継承できます。次に、APIの連絡エリアhr_user_acct_utilityに値を設定して、テンプレート職責の属性を上書きできます。

次のパッケージにユーザー・フック・コードのサンプルがあります。

ユーザー・フックを記述するための前提条件を設定する手順

  1. オラクル人事管理システムでセキュリティ・プロファイルを作成し、ユーザー名書式標準を使用してセキュリティ・プロファイルおよび職責をユーザー・フック・コードの新規ユーザーに関連付けます。

  2. 「セキュリティ・グループを使用可能にする」プロファイル・オプションを使用して、セキュリティ・プロファイルを管理するセキュリティ・グループを導入します。セキュリティ・グループの導入によって、複数のセキュリティ・プロファイルを単一の職責に関連付けることができます。

    注意: ユーザー・フックを記述する前に、「セキュリティ・リストの修正」コンカレント・プロセスを実行してください。これによって、セキュリティ・プロファイルが確実に動作します。

    注意: Oracle Self-Service Web Applications用に定義されている職責でセキュリティ・グループを使用する予定がある場合、またはOracle Self-Service Web Applications用に新規職責を作成する予定がある場合は、「セキュリティ・グループを使用可能にする」プロファイル・オプションをOracle Self Service Web Applicationsのアプリケーション・レベルで設定してください。

  3. 「ゲスト・ユーザー・パスワード」プロファイル・オプションを設定して、Oracle Applicationsでゲスト・ユーザー・アカウントを設定します。<ユーザー名/パスワード>の書式で指定する必要があります。データベース管理者の職責を持つユーザーが、ゲスト・ユーザー・アカウントを取得および検証できます。

  4. システム管理者の職責でシステム・プロファイル・オプション値の定義を使用して、セキュリティ・プロファイルをサイト・レベルまたはアプリケーション・レベルで設定します。バッチ・プロセスではセキュリティ・プロファイル・オプション値を職責レベルまたはユーザー・レベルで設定できるため、この設定が必要です。

    注意: サンプル・ユーザー・フックの名前はhrhksmpl.pkbです。各コード・ブロックはドキュメント化されています。$PER_TOP/patch/115/sqlディレクトリにもサンプルのコピーが格納されています。

    関連項目: 『Oracle HRMSインプリメンテーション・ガイド』のAPIユーザー・フックに関する説明

    関連項目: 『Oracle HRMSインプリメンテーション・ガイド』のサンプル・コードに関する説明

バッチ・プロセスで更新される表

バッチ・プロセスによって、次のFND表にレコードが挿入されます。

バッチ・プロセスによってユーザーの定義フォームの機能が自動化され、次のFND表にレコードが挿入されます。

注意: バッチ・プロセスでは、ユーザーのセキュリティ属性を作成できません。

バッチ・プロセスによって職責の定義フォームの機能が自動化され、次のFND表にレコードが挿入されます。

注意: バッチ・プロセスでは、職責のセキュリティ属性を作成できません。

バッチ・プロセスによってプロファイル・オプション値フォームの機能が自動化され、次のFND表にレコードが挿入されます。

ユーザー独自のカスタム・ビジネス・ロジックのバッチ・ユーザー・フックを記述する手順

  1. ユーザーのバッチを作成するには、次のAPIのユーザー・フックにPL/SQLプログラムを記述する必要があります。

    このAPIには2つのプロシージャがあります。

ユーザーAPIを作成するプロシージャを設定する手順

  1. プロセスの中で従業員や就業者の新規ユーザー・アカウントを作成するときに使用するユーザー名、パスワード、職責およびプロファイルをAPIに伝えるPL/SQLプログラムを記述します。

    ユーザー・プロシージャ作成時のユーザー・フック・ポイントは2つあります。

    PL/SQLプログラムには前処理フックを使用します。これらの値は、プログラムによってグローバル変数またはhr_user_acct_utilityのレコード構造に入力されます。

    注意: 新規ユーザー・アカウントにはパスワードを指定できます。また、APIで任意の文字列を生成することもできます。この場合、文字列は8文字の英数字書式になります。

  2. APIでパスワードを生成する場合は、後処理フックにPL/SQLプログラムを記述します。新規ユーザー・アカウントのパスワードは、システム管理者がアクセスできるファイルに保存する必要があります。これは、APIで作成されたパスワードは、データベースのFND_USER表に保存されるときに暗号化されるため、システム管理者のアクセスが必要となります。初期パスワードを従業員に通知できるように、パスワードは、暗号化される前に取得する必要があります。

    注意: パスワードを自分で指定する場合は、この後処理フック・ポイントへのユーザー・フックの記述は不要になります。

ユーザーAPIを更新するプロシージャを設定する手順

ユーザーAPIを更新するプロシージャは、従業員の無効化に使用されます。このAPIは、FND_USER表およびFND_USER_RESP_GROUPS表の従業員レコードを終了するAPIであり、その他の更新目的には使用されません。

ユーザー・プロシージャ更新時のユーザー・フック・ポイントは2つあります。

残りのステップを実行する手順

  1. ユーザー・フックの記述後に作成したカスタム・パッケージをコンパイルします。

  2. パッケージのコンパイル後、カスタム・パッケージ・プロシージャを適切なAPIユーザー・フックに登録およびリンクします。

    関連項目: 『Oracle HRMSインプリメンテーション・ガイド』のAPIユーザー・フックに関する説明

    次のコードは、カスタム・パッケージおよびプロシージャを登録およびリンクするサンプル・スクリプトです。

    サンプル・コード

    DECLARE

 ln_api_hook_call_id NUMBER;

 ln_object_version_number NUMBER;

 ln_api_hook_id NUMBER;



  BEGIN



 -- get api_hook_id for the seeded before process user hook package procedure

 SELECT ahk.api_hook_id

 INTO  ln_api_hook_id

 FROM  hr_api_hooks ahk

   ,hr_api_modules ahm

 WHERE ahm.module_name = 'CREATE_USER_ACCT'

 AND ahm.api_module_type = 'BP'

 AND ahk.hook_package = 'HR_USER_ACCT_BK1'

 AND ahk.hook_procedure = 'CREATE_USER_ACCT_B'

 AND ahk.api_hook_type = 'BP'

 AND ahk.api_module_id = ahm.api_module_id;



 -- insert a row into HR_API_HOOK_CALLS for before process user hook custom package procedure



 hr_api_hook_call_api.create_api_hook_call(

  p_effective_date => to_date('02/02/2000', 'DD/MM/YYYY'),

  p_api_hook_id   => ln_api_hook_id,

  p_api_hook_call_type => 'PP',

  p_sequence   => 1,

  p_enabled_flag  => 'Y',

  p_call_package  => 'MY_USER_ACCT', -- your custom package name

  p_call_procedure => 'CREATE_USER_ACCT_B', -- your custom package procedure name

  p_api_hook_call_id  => ln_api_hook_call_id,

  p_object_version_number => ln_object_version_number

 );





 -- get api_hook_id for the seeded after process user hook package procedure

 SELECT ahk.api_hook_id

 INTO  ln_api_hook_id

 FROM  hr_api_hooks ahk

   ,hr_api_modules ahm

 WHERE ahm.module_name = 'CREATE_USER_ACCT'

 AND ahm.api_module_type = 'BP'

 AND ahk.hook_package = 'HR_USER_ACCT_BK1'

 AND ahk.hook_procedure = 'CREATE_USER_ACCT_A'

 AND ahk.api_hook_type = 'AP'

 AND ahk.api_module_id = ahm.api_module_id;





 -- insert a row in HR_API_HOOK_CALLS for after process user hook custom package procedure

 hr_api_hook_call_api.create_api_hook_call(

  p_effective_date => to_date('02/02/2000', 'DD/MM/YYYY'),

  p_api_hook_id   => ln_api_hook_id,

  p_api_hook_call_type => 'PP',

  p_sequence   => 1,

  p_enabled_flag  => 'Y',

  p_call_package  => 'MY_USER_ACCT',

  p_call_procedure => 'CREATE_USER_ACCT_A',

  p_api_hook_call_id  => ln_api_hook_call_id,

  p_object_version_number => ln_object_version_number

 );



  EXCEPTION

 when others then

  dbms_output.put_line('Error in seeding user hook procedures: ' || sqlerrm);

  END;



  /

  commit;

  exit;

    ユーザー・フック・プリプロセッサの実行

    カスタム・パッケージ・プロシージャをAPIに登録およびリンクした後、ユーザー・フック・プリプロセッサ・プログラムを実行してください。これを行うには、$PER_TOP/patch/115/sqlディレクトリにあるhrahkone.sqlを実行します。ただし、スクリプトを実行する前にHR_USER_ACCT_APIの内部api_module_idを把握している必要があります。内部api_module_idを検索するには、次のスクリプトを実行してください。

      SELECT api_module_id

  ,api_module_type

  ,module_name

 FROM  hr_api_modules

 WHERE module_package = 'HR_USER_ACCT_API';

    次のような結果が表示されます。

     API_MODULE_ID API_MODULE_TYPE     MODULE_NAME

 --------------------------------------------------------

      383 BP                       CREATE_USER_ACCT

      384 BP                       UPDATE_USER_ACCT

    注意: 実際のapi_module_idは、前述の例とは異なります。

    hrahkone.sqlを実行するときは、ユーザー独自のAPIモジュールIDを使用します。UPDATE_USER_ACCTフック・ポイント用に顧客固有のパッケージがある場合は、hrahkone.sqlを2回実行する必要があります。1回目はCREATE_USER_ACCTフック・コール用api_module_idのため、2回目はUPDATE_USER_ACCTフック・コール用です。

  3. プリプロセッサ・プログラムの実行後、カスタム・パッケージで発行するメッセージについて新しいメッセージ・テキストを入力します。メッセージ・テキストを作成するには、Oracle Applicationsのアプリケーション開発者職責を使用します。

  4. セキュリティ・グループを使用してセキュリティ・プロファイルを管理する場合は、アプリケーション・レベルが正しく設定されていることを確認します。たとえば、SSHRでは、アプリケーション・レベルをOracle Self Service Web Applicationsに設定する必要があります。職責を別の人事管理システム・アプリケーションに関連付ける必要がある場合は、セキュリティ・プロファイル・オプションをそのアプリケーション・レベルに設定します。

    これによって、per_sec_ profile_ assignments表およびfnd_user_resp_groups表が更新されます。

  5. 「セキュリティ・グループを使用可能にする」プロファイル・オプションが「Yes」に設定されていることを確認します。

  6. Data Pumpエラー・パラメータを設定します。これらのパラメータは、Data Pumpエンジン・プロセスの様々な面を制御します。

    関連項目: 『Oracle HRMSインプリメンテーション・ガイド』のOracle HRMS Data Pumpに関する説明

    注意: 実行時に記録されるすべてのエラーを確認するには、MAX_ERRORS_ALLOWEDパラメータを設定する必要があります。このパラメータによって、エンジンが処理を停止するまでに発行されるエラー数が制御されます。デフォルト値は20またはチャンク・サイズです。このパラメータ値を設定しない場合は、20個のエラーが発行された後に処理が停止します。

  7. 次の3つのプログラムを実行して、カスタム・パッケージをテストします。最初にユーザー・アカウント従業員抽出コンカレント・プログラムを実行して、抽出された従業員のバッチを作成します。次に、Data Pumpエンジン・コンカレント・プログラムを実行してバッチを処理し、Data Pumpバッチ例外を実行します。

    必要な場合はエラーを修正後、バッチを再度実行できます。

    注意: Pipemonユーティリティを使用すると、コードのデバッグに役立ちます。

    関連項目: コンカレント・プログラムを使用したユーザーのバッチ作成

目次   |   戻る   |   先頭へ   |   次へ

Oracleロゴ
Copyright © 2002, 2006, Oracle. All rights reserved.