| Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド 11g リリース1 (11.1.1.7) E59381-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド 11g リリース1 (11.1.1.7) E59381-01 |
|
前 |
次 |
この章では、Oracle Enterprise Repositoryワークフローを設定および構成する方法、および登録プロセスを使用してOracle Enterprise Repositoryのアセットを管理する方法について説明します。
この章には、次のセクションがあります。
再使用に適していると確認されたアセットは、リポジトリに発行されます。発行されたアセットはレジストラによってレビューされ、登録プロセスを進めるアセットが決定されます。
図A-1に示すように、レジストラによって受け入れられたアセットは登録ワーク・キューに入ります。発行者は、My Stuffページの「個人の発行」フォルダを使用して、登録に向けたアセットの進捗状況を追跡できます。発行者は、拒否されたアセットおよび拒否の理由(たとえば、重複したアセット)に関する通知を受信します。
Oracle Business Process Management (Oracle BPM)およびOER
プロセスにより、ビジネスが推進されます。注文の実行、雇用決定のエスカレーション、保持するレコードの決定、または製品の価格設定方法の決定を行う場合、暗黙的または明示的にビジネス・プロセス内で行動していることになります。Oracle Business Process Managementは、ビジネス・プロセスを作成、実行および最適化するツールの完全なセットです。Oracle BPMでは、既存のIT投資が活用されます。また、Oracle BPMは、ライン・オブ・ビジネスの所有者用として特別にチューニングされます。
Oracle Enterprise Repositoryには、登録プロセスとガバナンス・プロセスを自動化するために事前に構築されたBPMアセット登録フローがバンドルされています。事前に構築されたBPMアセットの登録フローは、インストールに固有のアセット・タイプ、ライフサイクル・ステージ、カテゴリ分け、ユーザーおよび他のOER構成を使用するように構成できます。登録フローの連鎖により、即時利用可能な幅広い種類のユースケースをサポートできます。事前に構築されたフローが目的に対して十分ではない場合は、事前定義されたOracle BPMエンドポイントを使用するか、独自のWebサービス・エンドポイントを作成してOracle Enterprise Repositoryイベントをサブスクライブすることができます。Oracle BPMデザイナを使用して、新しいガバナンス・ワークフローを作成できます。また、トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールも用意されています。
Oracle Business Process Managerでのワークフローの開発の詳細は、『Oracle Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド』を参照してください。
Oracle Enterprise Repositoryには、アセットの発行、受入れ、登録、Oracle Enterprise RepositoryとOracle Service Registryの同期、および他のガバナンス・プロセスなどの一般的なOracle Enterprise Repositoryタスクを自動化するために設計された一連の事前定義済フローが用意されています。
このセクションでは、次のトピックについて説明します。
自動ワークフローには、次のソフトウェア・コンポーネントが含まれます。
Oracle Enterprise Repositoryイベント・マネージャ
イベント・マネージャは、アセット登録イベントをWebサービス・メッセージの形式で発行します。これらのイベントにより、Oracle Enterprise Repositoryアセットの発行、受入れ、登録、および他のガバナンス・プロセスなどを自動化する事前定義済のフローがトリガーされます。
詳細は、A.4項「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
サブスクリプション・マネージャは、一致するイベントが配信されるWebサービス・エンドポイント(事前定義済のALPBMまたはユーザー定義のエンドポイント)によるイベント・サブスクリプションを管理するXMLベースの構成ファイルです。イベント・マネージャは、EndPointEventSubscription.xmlファイルを使用して、イベントを配信する必要があるエンドポイントに関する情報をロードします。
詳細は、A.4項「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
イベント・マネージャは、デフォルトで有効になっているApache ActiveMQ JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。ただし、Weblogic Server JMSやIBM MQSeriesなどの外部JMSサーバーを使用するようにイベント・マネージャを構成することもできます。
詳細は、A.7項「Oracle Enterprise Repository用のJMSサーバーの構成」を参照してください。
イベント・マネージャによって生成されたイベントをモニターするためのツールです。Event Monitorは、イベント・トラフィックをモニターし、イベント本体やイベント・プロパティなどの情報を出力します。
詳細は、A.8項「イベントのモニタリングおよび管理」を参照してください。
Oracle Business Process Management
Oracle Business Process Managementは、購入したOracle Enterprise Repositoryに含まれています。Oracle Business Process Managementを使用して、事前に構築された登録フローの実行、Oracle Enterprise Repositoryとともに提供されている既存のワークフローの変更、および新しいリポジトリ集中型ワークフローの実装を行うことができます。
自動ワークフローは、追加設定なしで実行することも、使用環境に合うように調整することもできます。詳細は、A.6項「自動ワークフローの構成」を参照してください。
次の自動ワークフローが提供されます。
コミュニティ割当てフロー: 自動割当てルールの構成を可能にすることによってアセットの受入れ、割当て、登録プロセスを自動化する方法を提供するとともに、様々な機関の間のフェデレーテッド・レジストラに関する概念を提供します。詳細は、A.6.4.1項「コミュニティ・フローの構成」を参照してください。
自動受入れおよび自動登録フロー: コミュニティ・フローを使用したアセットの自動的な受入れおよび登録に加えて、複数のユーザー・ロールを使用したアセットの受入れおよび登録が可能です。詳細は、A.6.4.2項「自動受入れおよび自動登録フローの構成」を参照してください。
複数層承認フロー: 層と呼ばれる複数の手順でタブ承認プロセスを構築します。アセット承認タブは層単位にグループ化できます。また、複数層承認フローでは、指定した承認者によってすべてのタブが承認されているかどうかを確認するために各層が追跡されます。層内の最後のタブが承認されると同時に、フロー内では、指定した承認者の次のレベルにアセットを割り当てることによって次の層が開始されます。詳細は、A.6.5項「複数層自動割当てフロー」を参照してください。
メタデータ変更フロー: 状態変更またはメタデータ変更をアクションにワイヤリングできる柔軟なフレームワークを公開します。メタデータ変更フローには、事前にバンドルされた一連のアクションが用意されています。新しいアクションは、Oracle Enterprise Repositoryフローの形式で開発し、プラグインできます。詳細は、A.6.6項「メタデータ変更フロー」を参照してください。
時間ベースのエスカレーション・フロー: 様々な状態のアセットを追跡し、すべての当事者に通知します。時間ベースのエスカレーション・フローには4種類があり、各種を個別に構成できます。詳細は、A.6.7項「時間ベースのエスカレーション・フロー」を参照してください。
有効期限の検証フロー: 指定した有効期限より前に期限が切れたアセットや、期限日に期限が切れたアセットを追跡し、すべての当事者に警告通知を送信します。詳細は、A.6.8項「有効期限の検証フロー」を参照してください。
AutoSyncAlerToUddiフロー: アセット・ライフサイクル・ステージがステージ4 - 構築からステージ5 -本番に変更されたときに、サービスをOracle Enterprise RepositoryからOracle Service Registryに移動します。詳細は、10.3.1.1項「ワークフローを使用したOracle Registry Repository Exchange Utilityの起動」を参照してください。
トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールが用意されています。
Oracle Business Process Management Process Execution Administratorは、アセット登録イベントの編成をWebサービス・メッセージの形式でアクティブに管理します。詳細は、A.5項「Oracle Business Process Managementプロセスの管理」を参照してください。
Oracle Business Process Managementログ・ビューアを使用すると、プロセス実行エンジンによって記録された情報を読み取ることができます。定義するプロジェクトごとに一連のログ・ファイルが作成されます。Studioログ・ビューアにより、ファイルが読み取られて表示されるため、エンジンの実行をモニターして追跡できます。詳細は、A.5.5項「Oracle Business Process Managementログ・ビューアの使用」を参照してください。
自動登録フローでは、多くの状況下で電子メール通知が自動的に送信されます。管理者は、他の電子メール・テンプレートの場合と同じ方法で電子メールの件名や本文などをカスタマイズできます。A.6.9項「電子メール通知テンプレートのカスタマイズ」を参照してください。
新しい構成ファイルの生成、既存のファイルのリフレッシュ、およびパスワードの暗号化を行うためのワークフロー構成ツールが用意されています。詳細は、A.8項「イベントのモニタリングおよび管理」を参照してください。
Oracle Enterprise Repository管理者によるフローの構成およびカスタマイズが必要になる場合がありますが、これは、新しいアセット・タイプ、プロジェクト、カテゴリ分けなどが存在するためです。構成XMLの生成ツールを使用すると、Oracle Enterprise Repositoryにアクセスし、カスタマイズ可能な新しいファイルを作成できます。
Oracle Enterprise Repositoryには、A.10項「OERワークフローの操作」に定義されている、登録プロセスとガバナンス・プロセスを自動化するために事前に構築されたBPMアセット登録フローがバンドルされています。使い勝手を向上させるために、事前定義されたOracle BPMエンドポイントを使用するか、独自のWebサービス・エンドポイントを作成してOracle Enterprise Repositoryイベントをサブスクライブすることができます。Oracle BPMデザイナを使用して、新しいガバナンス・ワークフローを作成できます。また、トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールも用意されています。
The Oracle BPMワークフロー・アーカイブは、OERにバンドルされており、<OER_HOME>/core/tools/solutionsにあります。このアーカイブには、主にOracle BPMでOERワークフロー・エンジンを初期化することを目的としたOSおよびAntスクリプト(build.xml)とともにworkflow.xmlが含まれています。特に、Antスクリプトは、別のファイルであるbuild.propertiesに依存しています。このファイルは、Oracle BPMのインストール、サーバーおよびデータベースの場所を識別します。
ワークフロー関連の別のユーティリティは、<OER_HOME>/core/workflow-toolsにあります。通常、これらのツールは、OERイベント・キューのクリアや、最新のワークフロー構成を使用したOBPMのリフレッシュなどのワークフロー・メンテナンスをサポートすることを目的としています。
この項では、Oracle Enterprise Repository WorkflowをOracle BPM 10.3.2にインストールする方法について説明します。内容は次のとおりです。
Oracle Enterprise Repositoryワークフローをインストールする前に、次の要件について検討してください。
Apache Antバージョン1.6.5以上
Oracle BPM 10.3.2 Enterpriseインストール
Oracle Enterprise Repository 11g
Oracle Enterprise RepositoryのURLおよびポート番号
選択したデータベース・サーバー内でユーザー、表、索引を作成できるDBAユーザー・アカウント
選択したデータベース・サーバーに適したJDBCドライバ
インストールの実行に必要なDB権限の識別
JDKバージョン1.6以上(非GUIモードでのインストールの場合はJDKバージョン1.5)
最新のホットフィックス・ビルドのダウンロードおよびOracle BPMインストールへの適用
Oracle BPM 10.3.2をインストールするには、次の手順を実行します。
Oracle Business Process Management (Enterprise) 10gR3 (10.3.2)をhttp://www.oracle.com/technetwork/middleware/bpm/downloads/index-100737.htmlからダウンロードします。
Ps4JDKを指すようにJAVA_HOMEを設定します。
BPMインストール・ウィザードを実行し、デフォルトのままにします。インストール・ディレクトリとして/Oracle/Middleware/obpm/enterpriseを入力します。
インストール・ウィザードが終了したら、インストーラの終了を選択し、ウィザードを閉じます。
図A-2に示すように、/Oracle/Middleware/obpm/enterprise/binディレクトリには、BPMエンジンを起動するためのスクリプトがすべて格納されています。
Oracle Enterprise Repositoryワークフロー・インストーラを解凍するには、次の手順を実行します。
Oracle Enterprise Repositoryがインストールされている場所で、ORACLE_HOME/repositoryXXX/core/tools/solutions/11.1.1.x.x-OBPM-Workflow-Management-Scripts.zipディレクトリ内にあるOracle Enterprise Repositoryワークフロー・インストーラを検索します。
Oracle BPMがインストールされているサーバー上でzipファイルを/Oracle/Middleware/obpmディレクトリに解凍します。
このzipファイルから、OBPM_SetupScriptsとworkflowの2つのディレクトリが作成されます。また、build.txtファイルも作成されます。
ORACLE_HOME\obpm\OBPM_SetupScripts\build.propertiesファイルに正しい値を入力します。
表A-1に、build.propertiesファイルにリストされているプロパティと、各プロパティの説明および例を示します。build.propertiesファイルでは、@は、置き換える必要がある値を示します。各スクリプトでは、このプロパティ・ファイルの値が使用されます。
|
注意: パス要素を区切るには、プラットフォームに関係なくフォワード・スラッシュ文字を使用します。 |
データベース・スキーマをAntタスクで正しく作成するには、Oracle Enterprise RepositoryワークフローをホストするDBAユーザー・アカウントをbuild.propertiesファイルのfuego.fdi.db.admin.id設定で指定する必要があります。このDBAユーザー・アカウントは、Antタスクによってデータベース内に作成される新しいユーザーです。
表A-1 build.propertiesファイルのプロパティ値
| プロパティ | 説明 |
|---|---|
|
bea.home |
このプロパティは、Oracleホーム・ディレクトリの場所を指定します。 例: c:/oracleまたは/Oracle/Middleware |
|
oer.uri |
このプロパティは、Oracle Enterprise RepositoryインストールのURIを指定します。また、URIの一部としてservices/FlashlineRegistryが存在する必要があります。 例: http://localhost:1111/oer/services/FlashlineRegistry |
|
fuego.basedir |
このプロパティは、Oracle BPMインストールの場所を指定します。 例: c:/oracle/obpm/enterpriseまたは/opt/oracle/obpm/enterprise |
|
fuego.project |
このプロパティは、Oracle BPMプロジェクトの場所を指定します。推奨どおりにOracle BPMインストールの場所を採用した場合、次の値は変更されません。
注意: {basedir}は、 |
|
fuego.fdi.id |
これは、Fuegoディレクトリ・プロパティ(FDI)です。 例: |
|
fuego.fdi.organization |
これは、Fuegoディレクトリ・プロパティ(FDI)です。 例: |
|
fuego.fdi.admin.id |
Oracle BPMインストールの新しい管理ユーザーを作成します。このユーザー・アカウントは、Oracle BPM Webコンソール・アプリケーションにアクセスするために使用されます。 例: |
|
fuego.fdi.admin.password |
Oracle BPMインストールの新しい管理パスワードを定義します。 注意: 管理ユーザー名およびパスワードは同じものにしないでください。 |
|
fuego.fdi.db.host |
このプロパティは、Oracle BPM FDI (ディレクトリ)データベースをインストールするマシンを指定します。 例: |
|
fuego.fdi.db.port |
このプロパティは、Oracle BPM FDIデータベース・ポートを指定します。 |
|
fuego.fdi.db.admin.id |
このプロパティは、Oracle BPM FDIデータベースのデータベース管理ユーザーを指定します。インストーラでは、このプロパティを使用してFDIスキーマがインストールされます(次を参照)。 |
|
fuego.fdi.db.admin.password |
このプロパティは、Oracle BPM FDIデータベースのデータベース・ユーザーのパスワードを指定します。 |
|
fuego.fdi.db.type |
このプロパティは、Oracle BPM FDIデータベースのデータベース・タイプを指定します。 例: oracle、mssqlserver、db2 |
|
fuego.fdi.db.sid |
このプロパティは、Oracle BPM FDIデータベースのSIDを指定します。このプロパティは、Oracleデータベース・タイプに対してのみ適用されます。 |
|
fuego.fdi.db.schema |
このプロパティは、データベースによって作成されるOracle BPM FDIスキーマのデータベース・ユーザー名を指定します。このプロパティは、実行時にOracle BPMによって使用される、Oracleデータベース・タイプに固有のプロパティです。 新しいユーザー・データベース・アカウントが作成されます。 例: oer_bpm_fdi |
|
fuego.fdi.db.schema.password |
このプロパティは、Oracle BPM FDIスキーマのデータベース・パスワードを指定する、Oracleデータベース・タイプに固有のプロパティです。 |
|
fuego.server.db.host |
これら4つのプロパティは、データベースのFuegoエンジン・プロパティを定義します。 このプロパティは、Oracle BPMプロセス・エンジン・データベースをインストールするシステムを指定します。 例:
|
|
fuego.server.db.port |
このプロパティは、Oracle BPMプロセス・エンジン・データベースのポートを指定します。 |
|
fuego.server.db.admin.id |
このプロパティは、Oracle BPMプロセス・エンジン・データベースのデータベース管理ユーザーを指定します。インストーラでは、このプロパティを使用してFDIスキーマがインストールされます(次を参照)。 |
|
fuego.server.db.admin.password |
このプロパティは、Oracle BPMプロセス・エンジン・データベースのデータベース・ユーザーのパスワードを指定します。 |
|
fuego.server.db.type |
このプロパティは、Oracle BPMプロセス・エンジン・データベースのデータベース・タイプを指定します。 例: oracle、mssqlserver、db2 |
|
fuego.server.db.sid |
このプロパティは、Oracle BPMプロセス・エンジン・データベースのSIDを指定します。このプロパティは、Oracleデータベース・タイプに対してのみ適用されます。 例: XE |
|
fuego.fdi.db.user.id |
mssqlserverおよびdb2データベース・タイプに対してのみ適用できます。 このプロパティは、データベースによって作成されるOracle BPM FDIスキーマのデータベース・ユーザー名を指定します。このプロパティは、実行時にOracle BPMによって使用されます。 |
|
fuego.fdi.db.user.password |
mssqlserverおよびdb2データベース・タイプに対してのみ適用できます。 このプロパティは、Oracle BPM FDIスキーマのデータベース・パスワードを指定します。 |
|
fuego.fdi.db.database |
mssqlserverおよびdb2データベース・タイプに対してのみ適用できます。 このプロパティは、Oracle BPM FDIデータベースのデータベース名を指定します。 |
|
fuego.server.db.user.id |
mssqlserverおよびdb2データベース・タイプに対してのみ適用できます。 このプロパティは、作成されるプロセス・エンジン・スキーマのデータベース・ユーザー名を指定します。このプロパティは、実行時にOracle BPMによって使用されます。 |
|
fuego.server.db.user.password |
mssqlserverおよびdb2データベース・タイプに対してのみ適用できます。 このプロパティは、Oracle BPMプロセス・エンジン・スキーマのデータベース・パスワードを指定します。 |
|
fuego.server.db.database |
mssqlserverおよびdb2データベース・タイプに対してのみ適用できます。 このプロパティは、Oracle BPMプロセス・エンジン・データベースのデータベース名を指定します。 |
|
fuego.server.db.schema |
このプロパティは、Oracle BPMプロセス・エンジン・データベースのデータベース管理ユーザー名を指定します。インストーラでは、このプロパティを使用してOracleデータベースのFDIスキーマがインストールされます。 |
|
fuego.server.db.schema.password |
このプロパティは、Oracleデータベース・タイプのOracle BPMプロセス・エンジン・データベースのデータベース・パスワードを指定します。 |
|
警告: build.propertiesファイルのバックアップ・コピーを作成してください。build.propertiesファイルは、Antスクリプトの実行後に削除されます。 |
ORACLE_HOME\obpm\OBPM_SetupScripts\setenv.batファイル(Windows)または/setenv.shファイル(UNIX)ファイルに正しい値を入力します。表A-2に、setenvファイルのプロパティとその説明を示します。
|
注意: パス要素を区切るには、フォワード・スラッシュ文字(/)を使用します。 |
|
ヒント: setenvスクリプトをLinuxまたはUNIX環境で実行する場合、正しいプロパティ値を使用してこのスクリプトを編集した後にこのスクリプトに対してdos2unixコマンドを実行してください。 |
| プロパティ | 説明 |
|---|---|
|
|
このプロパティは、Oracleホーム・ディレクトリの場所を指定します。 例: |
|
|
このプロパティは、Oracle BPMがインストールされている親ディレクトリを指定します。 例: |
|
|
このプロパティは、Oracle BPMがインストールされている場所を指定します。 例: |
|
|
このプロパティは、システム上のJavaランタイムの場所を指定します。 例: |
|
|
このプロパティは、マシン上のApache ANTインストールの場所を指定します。 例: |
新しいnew workflow.xmlファイルを生成し、新しいユーザー資格証明を使用して編集する必要があります。新しいアセット・タイプを作成するか、ユーザー(aleridがユーザーです)を追加する場合、workflow.xmlにこれらの変更を取得するためにワークフローを再生成する必要があります。また、再生成により、workflow.xmlファイル内のOER URIも更新されます。
|
注意: 実行するには、OERが稼働している必要があります。 |
workflow.xmlファイルは、ワークフロー構成の生成ツール(config_gen.bat)を使用して生成できます。このツールにより、Oracle Enterprise Repositoryに接続し、カスタマイズ可能なブートストラップ・ファイルを作成します。
workflow.xmlファイルはOracleによって提供されます。このファイルのバックアップ・コピーを作成してください。OERをインストールしたディレクトリに移動し、スクリプトを実行し、生成されたスクリプトをSetupscriptsフォルダにコピーします。
workflow.xmlファイルを生成または再生成するには、次の手順を実行します。
コマンド・プロンプトから、次のように、repository111/core/workflow-tools/にあるワークフロー構成の生成ツールを実行します。
> config_gen.bat URI User Password ConfigDir
意味は次のとおりです。
URI = OER URI (次の形式を使用)
http://<host>:<port>/<oer web app name>/services/FlashlineRegistry
例: http://localhost:7001/alerbuild/services/FlashlineRegistry
User = Oracle Enterprise Repositoryのユーザー名
Password = Oracle Enterprise Repositoryのパスワード
ConfigDir = workflow.xmlファイルが作成されたディレクトリ
新しく生成したworkflow.xmlファイルを<Oracle Business Process Management Enterprise Edition>/enterprise/server/aler_engineディレクトリにコピーします。
任意のXMLエディタを使用してworkflow.xmlファイルを開きます。
workflow.xmlファイルの生成の詳細は、A.8.4項「ワークフローの構成」を参照してください。
初回の編集では、正しいパスワードとURLをファイルに記載します。後で組織のニーズに合うようにワークフロー・ファイルを構成します。
ORACLE_HOME/obpm/OBPM_SetupScripts/workflow.xmlにあるworkflow.xmlファイルを編集し、このURIをOracle Enterprise RepositoryインストールのURIと一致するよう変更します。
パス参照の末尾にある/services/FlashlineRegistryは変更しません。
workflow.xmlファイル内のすべてのユーザー資格証明を正しい値に変更します。
Oracle Enterprise Repositoryワークフロー構成ファイルworkflow.xmlを暗号化するには、次の手順を実行します。
http://<host>:<port>/oer/diag/encryptstrings.jspに移動します。
workflow.xmlファイルに対して暗号化を実行します。
workflow.xmlファイルを/obpm/enterprise/server/aler_engineにコピーします。
workflow.xmlファイルを暗号化するための別の方法は、5.3.3項「ワークフロー構成ファイル」を参照してください。
データベースのJDBC jarを$Oracle_HOME\OBPM_SetupScripts\extディレクトリにコピーします。
OBPM_SetupScriptsおよびworkflowフォルダの権限を検証し、これらが書込み可能であることを確認してください。
|
ヒント: Antスクリプトが正常に実行されたら、build.propertiesファイル内に格納されているパスワードに関するセキュリティ上の懸念により、このファイルは削除されます。これを回避することはできないため、予防策としてバックアップを作成します。 |
setenv.shを使用している場合、このファイル内にDOS文字が存在しないようにdos2unixコマンドを実行する必要がある可能性があります。このファイル内にDOS文字が含まれる場合、問題が発生します。
setenv.shは、BASHシェルで. ./setenv.shという形式で実行する必要があります。ANT_homeが設定されていることを確認してください。
setenv.batまたはsetenv.shファイルを実行するには、次の手順を実行します。
コマンドまたはシェル・ウィンドウを開きます。
$Oracle_HOME\OBPM_SetupScriptsディレクトリに移動します。
次のコマンドを実行します。
setenv.bat (Windows)
setenv.sh (UNIX) BASHシェルを使用する場合は、. ./setenv.shを実行します。Antホームが設定されていることを確認してください。
ant create-fdiを実行してOBPMデータベースを初期化してから、ant install-workflowを実行してOBPMワークフロー・エンジン(aler_engineという名前)を初期化します。
次のコマンドを実行します。
ant create-fdi
次のコマンドを実行します。
ant install-workflow
設定スクリプトが成功したことを確認するには、次の手順を実行します。
Enterprise/binディレクトリで、obpmadmcenterを起動します。
Oracle BPM Admin Centerアプリケーションを開きます。
BPMアプリケーションの起動をクリックします。
プロセス・アドミニストレータの起動をクリックします。
WebコンソールのWebインタフェースにアクセスし、Oracle BPM Webコンソール・アプリケーションの資格証明を使用してログインします。
これらの資格証明は、build.propertiesファイル内のfuego.fdi.admin.idおよびfuego.fdi.admin.passwordプロパティに指定されています。
左側のメニューの「エンジン」リンクを選択します。
aler_engineエンジンが、ステータス「停止中」で表示されます。
エンジン・アクション列の一番左のアイコンをクリックし、エンジンを起動します。
エンジンが実行されると、エンジンのステータスが「準備完了」になります。
Oracle BPMサービス・エンドポイントが適切にリスニングしていることを確認します。Webブラウザを使用して、ポート9000 (たとえば、http://localhost:9000/albpmServices/aler_engine/ws)でOracle BPMサーバーに接続します。
albpmServices/oer_engine/wsリンクをクリックします。
リンク先では、StatusChangeEndpointServiceListenerとRefreshConfigServiceListenerの2つのサービスがリストされています。
|
ヒント: ワークフローのAntデプロイメント中にビルドの失敗またはエラーが表示された場合、次の手順に従います。
|
WEB-INF/classes/EndPointEventSubscription.xmlファイル内のOracle Enterprise Repositoryインストールをクリックし、Oracle BPMがインストールされているサーバーのIPアドレスまたは完全修飾ホスト名が含まれるように<sub:host>要素を変更します。
これで、Oracle Enterprise Repositoryワークフローがデプロイされます。
ワークフローを正常に実行するには、xmlファイル内のパスワードを暗号化してから、Oracle Enterprise Repositoryサーバーを再起動する必要があります。EndPointEventSubscription.xml内にクリア・テキストのパスワードがある場合、イベントはOracle BPMに配信されません。
パスワードが暗号化されていない場合、<ORACLE_HOME>\user_projects\domains\<oer_domain>\eventing.logファイルに次のログ・メッセージが表示されます。
サブスクリプション・データが不十分です。[<ENDPOINT_NAME>]という名前を持つエンドポイントには暗号化パスワードが必要です。
この項では、自動ワークフローを使用する前に完了する必要があるイベント・マネージャの構成について説明します。
この項には次のトピックが含まれます:
イベント・マネージャはOracle Enterprise Repositoryに埋込みのコンポーネントであり、イベント・サブスクリプション、イベント永続性、イベントのフィルタ処理、およびイベント配信を管理します。Webサービス・エンドポイントはイベント・マネージャのサブスクリプション・マネージャをサブスクライブでき、Oracle Enterprise Repository内で生成されたアセット登録イベントはWebサービス・エンドポイントに配信されます。
図A-3に、関連する様々なコンポーネントを示します。
イベント・マネージャは、デフォルトで有効になっているApache ActiveMQ JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。ただし、WebLogic ServerやIBM WebSphereなどの外部JMSサーバーを使用するようにイベント・マネージャを構成することもできます。
この項では、自動ワークフローを使用する前に完了する必要があるイベント・マネージャの構成について説明します。
自動ワークフローの構成の詳細は、A.4項「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
イベント・マネージャを構成するには、次の手順を実行します。
イベント・マネージャが外部Webサービス・エンドポイントにイベントを送信できるようにするには、イベント・マネージャをOracle Enterprise Repository内で有効にする必要があります。次のいずれかを実行できます。
<OER Domain>\WEB-INF\classesディレクトリ内のeventing.propertiesファイルでcmee.eventframework.enabled=trueプロパティを有効にします。
または
3-2ページの「イベント・マネージャのシステム設定の構成」で説明されているように、Oracle Enterprise RepositoryのWebベースのコンソールのシステム設定を使用して有効にします。
デフォルトのcmee.eventframework.delivery.sleepおよびcmee.eventframework.store.sleepイベンティング・プロパティ値をチューニングして、Oracle Enterprise RepositoryおよびWebサービス・エンドポイントの全体的なパフォーマンスを制御することもできます。これらのプロパティは、イベント・マネージャによって毎秒トリガーされるイベントの数に直接影響します。たとえば、テストを目的としてレスポンス速度の向上が必要になる場合は、cmee.eventframework.store.sleepのデフォルト値である7200秒をテストのための適切な値に変更する必要があります。
イベント・マネージャでは、Oracle Enterprise Repositoryと同じロギング・フレームワークが使用されます。デフォルトでは、ファイルに記録するようにロギングが有効化されていますが、デバッグ文をコンソールに表示するには、<OER Domain>\WEB-INF\classesディレクトリにあるlog4fl.propertiesファイルに次のカテゴリを追加します。
例A-1 デバッグ文のコンソールへの表示
# eventing subsystem log4j.category.com.bea.infra.event.core= debug,eventingLog,stdout log4j.category.com.bea.infra.event.dm= debug,eventingLog,stdout log4j.category.com.bea.infra.event.facade= debug,eventingLog,stdout log4j.category.com.bea.infra.event.notifier= debug,eventingLog,stdout log4j.category.com.bea.infra.event.store= debug,eventingLog,stdout log4j.category.com.bea.infra.event.sub= debug,eventingLog,stdout
イベント・マネージャのサブスクリプション・マネージャを使用してWebサービスのサブスクリプションを構成します。
|
注意: Oracle Business Process Managementプロセス・エンジンがOracle Enterprise Repositoryと同じマシン上で動作している場合、サブスクリプション・マネージャはその提供時点ではOracle Business Process Managementプロセス・エンジンと連携して動作するよう構成されています。この場合は、デフォルト設定のまま実行できるため、この手順はスキップできます。 |
要件によっては、<OER Domain>\WEB-INF\classesディレクトリの下にあるEndPointEventSubscription.xmlファイル内の次の情報の変更が必要になる場合があります。
Host: Webサービス・エンドポイントがOracle Enterprise Repository以外のホストで動作している場合。
同じホストである場合、デフォルトのままにします。
Port: Webサービス・エンドポイントのポートを指定します。
Oracle Business Process Managementがプロセス・エンジンとして使用されている場合、デフォルトのままにします。
URI: WebサービスのURIを指定します。
Oracle Business Process Managementがプロセス・エンジンとして使用されている場合、デフォルトのままにします。
Operation Name: Oracle Business Process Managementがプロセス・エンジンとして使用されている場合、デフォルトのままにします。使用可能な操作は、<OER Webapp path>/WEB-INF/libにあるmodules.eventing-11.1.1.x.x.jarファイル内のWSDLを参照してください。
User Name/Password: Oracle Business Process Managementがプロセス・エンジンとして使用されている場合のみ、使用されます。
OBPMのデフォルトのユーザー名/パスワードは、aler_workflow_user/<encrypted_password>です。使用されるデフォルトのパスワード・テキストは、aler_workflow_passです。
Expression: デフォルトは空です。つまり、すべてのイベントが配信されます。
Oracle Enterprise Repositoryを再起動して構成の変更内容を反映します。
イベント・マネージャの構成後にイベントがトリガーされることを確認するには、次の手順を実行します。
WebベースのコンソールからOracle Enterprise Repositoryのアセット・エディタを起動します。Oracle Enterprise Repositoryのアセット・エディタの使用の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』を参照してください。
図A-4に示すように、新しいアセットを作成します。
|
注意: アセット・タイプは「サービス」にする必要があります。 |
「OK」をクリックし、アセットを発行します。
アセットが発行された後、Oracle Enterprise Repositoryコンソールに切り替え、図A-5に示すように、コンソールに出力される次のロギング文を確認します。
イベント・モニタリング・ツールを使用して、配信されるイベントのペイロードを表示できます。イベントのモニターおよび管理方法の詳細は、A.8項「イベントのモニタリングおよび管理」を参照してください。
必要に応じて、HarvesterSettings.xmlファイルを構成することにより、<triggerEvent>タグをtrueまたはfalseに設定し、ハーベスタ・タスクごとにBPMワークフロー・イベンティングを有効または無効にできます。
Oracle Enterprise Repositoryのシステム設定セクションを使用して、Oracle Enterprise Repositoryの基本操作を構成、および特定の機能を有効または無効にします。イベント・マネージャ関連の設定は、「External Integrations」カテゴリの「Eventing」グループの下にあります。
システム設定の詳細は、17.5.5項「外部統合設定」を参照してください。
WebLogic ServerやIBM WebSphereなどの外部のJMSサーバーを構成するために追加の「イベンティング」プロパティも用意されています。これらのプロパティの詳細は、A.7項「Oracle Enterprise Repository用のJMSサーバーの構成」を参照してください。
イベント・マネージャが外部Webサービス・エンドポイントにイベントを送信できるようにするには、イベント・マネージャをOracle Enterprise Repository内で有効にする必要があります。
Oracle Enterprise Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。
「システム設定」の「検索」ボックスに「Event」と入力し、イベント・マネージャ関連の設定をすべて表示します。
「イベント・マネージャの有効化」プロパティcmee.eventframework.enabledの横にある「True」をクリックします。
「保存」をクリックします。
Oracle Enterprise Repositoryを再起動して構成の変更内容を反映します。
次の各項では、イベント・マネージャのパフォーマンスをチューニングするために使用できるオプションの"Eventing"プロパティについて説明します。
|
注意: Eventingプロパティの変更後に変更を有効にするには、Oracle Enterprise Repositoryを再起動する必要があります。 |
この項には次のトピックが含まれます:
1つ以上のイベントをエンドポイントに発行する必要があるときにエンドポイントが使用可能でない場合、イベント・マネージャ通知サービスは、エンドポイントが使用可能になるまでイベントの配信を再試行します。cmee.eventframework.notifier.sleepプロパティは、通知サービスがイベントの配信を再試行するまで待機する時間を秒単位で構成します。
イベントがトリガーされると同時に、イベント・マネージャは、Oracle Enterprise Repositoryスレッドがブロックされないように、イベントをJMSサーバーにプッシュする前にメモリーに格納します。cmee.eventframework.store.sleepプロパティは、イベント・マネージャのストア・マネージャ・スレッドが、メモリーに格納されているイベントの次に使用可能なバッチをポーリングするまでスリープする時間を秒単位で指定します。デフォルトのポーリング遅延は16秒です。
デフォルトでは、イベント・マネージャは、イベントをバッチ単位で配信します。cmee.eventframework.delivery.sleepプロパティは、イベント・マネージャの配信マネージャ・スレッドが、JMSサーバーから次に使用可能なイベントを選択するまでスリープする時間を秒単位で指定します。バッチ間のデフォルトの遅延は13です。
|
ヒント: デフォルトのcmee.eventframework.store.sleepおよび |
イベント・マネージャがイベントをバッチ単位で配信する場合、配信されるバッチ・サイズはcmee.eventframework.delivery.batch.sizeプロパティを使用して構成できます。デフォルトのバッチ・サイズは100イベントです。配信対象のイベント数が少ないことをイベント・マネージャが検出すると、使用可能なイベントを配信してから、cmee.eventframework.delivery.sleepプロパティに構成されている時間の間スリープします。
サブスクリプション・マネージャは、一致するイベントが配信されるWebサービス・エンドポイントによるイベント・サブスクリプションを管理します。
サブスクリプション・マネージャ構成ファイルは、<oer webapp name>\WEB-INF\classes\EndPointEventSubscription.xmlにあります。
イベント・マネージャは、EndPointEventSubscription.xmlファイルを使用して、イベントを配信する必要があるWebサービス・エンドポイントに関する情報をロードします。例A-2に示すように、事前定義済のALPBMエンドポイントまたはユーザー定義のWebサービス・エンドポイントのホスト、ポート、URI、ユーザーおよびパスワードを構成する必要があります。
例A-2 Webサービス・エンドポイントの例
<sub:EventSubscriptionData xmlns:sub="http://www.bea.com/infra/events/subscription"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sub:eventSubscription> <!--The name should be unique within this file since this name is passed as the Durable subscriber name to the JMS Server--> <sub:endPoint name="ALBPMEndpoint"> <!--The host of the Webservice Endpoint --> <sub:host>localhost</sub:host> --The port of the Webservice Endpoint --> <sub:port>9000</sub:port> <!--The URI of the Webservice Endpoint --> <!--If you are using ALBPM5.7 uncomment the following line and comment the line after --> <!-- <sub:uri>fuegoServices/ws/StatusChangeEndpointServiceListener</sub:uri> --><sub:uri>albpmServices/aler_engine/ws/StatusChangeEndpointServiceListener</sub:uri> <!--Unless a custom WSDL Contract is used, the namepsace should not be changed --> <sub:targetNamespace>http://www.bea.com/infra/events</sub:targetNamespace> <!--The Webservice operation that is invoked. Please refer to the WSDL in WEB-INF\lib\modules.eventing-11.1.1.x.x.jar for all the available operations--> -Unless a Custom Webservice is implemented, the operation should not be changed if it's ALBPM --> <sub:operationName>newEvent</sub:operationName> <!--Protocol for the Webservice Endpoint. --> <sub:protocol>HTTP</sub:protocol> <!--The user and password to authenticate the ALBPM Webservice. --> <sub:authenticationData> <sub:basicAuthentication> <sub:username>aler_workflow_user</sub:username> <sub:password>******</sub:password> </sub:basicAuthentication> </sub:authenticationData> </sub:endPoint> <!--The Java class that serializes the Event Data. Unless a custom class is written, this value should not be changed.--> <sub:notifierClass>com.bea.infra.event.notifier.plugin.http.DefaultHTTPEventNotifier</sub:notifierClass> <!--This expression filters the Event data and only the matched events are delivered to the Endpoint. The dafault is all the events are delivered. --> <!--Example:- asset_id BETWEEN 50000 AND 50100 --> <sub:expression></sub:expression> </sub:eventSubscription> </sub:EventSubscriptionData>
エンドポイントは必要な数を追加でき、様々なホストまたはポート内に配置できます。また、イベントはロード・バランシングできます。事前定義済の拡張登録フローには、"StatusChangeEndpoint"と呼ばれる1つのエンドポイントのみが含まれます。
イベントは、式要素に入力した値に基づいてフィルタ処理できます。この項には次のトピックが含まれます:
デフォルトの設定では、すべてのイベントが1つのエンドポイントに配信されます。式要素が空である場合、Oracle Enterprise Repository内でトリガーされたすべてのイベントがOOTBエンドポイントに配信されます。
<sub:expression></sub:expression>
次のXMLスニペットは、タイプAssetSubmissionのイベントを1つのエンドポイントに配信する方法を示しています。
<sub:expression> eventdata_name ='urn:com:bea.aler:events:type:AssetSubmission'</sub:expression>
また、"OR"演算子を使用して複数のイベント・タイプをフィルタ処理することもできます。
eventdata_name ='urn:com:bea.aler:events:type:AssetSubmission' OR eventdata_name ='urn:com:bea.aler:events:type:AssetAccepted'
次のイベント・タイプがサポートされています。
urn:com:bea:aler:events:type:AssetSubmission
urn:com:bea:aler:events:type:AssetAccepted
urn:com:bea:aler:events:type:AssetTabApproved
urn:com:bea:aler:events:type:AssetAllTabApproved
urn:com:bea:aler:events:type:AssetRegister
urn:com:bea:aler:events:type:PolicyAssertionChanged
urn:com:bea:aler:events:type:MetaDataChange:name
urn:com:bea:aler:events:type:AssetUnSubmission
urn:com:bea:aler:events:type:AssetUnAccept
urn:com:bea:aler:events:type:AssetUnregister
urn:com:bea:aler:events:type:AssetStatusChanged
urn:com:bea:aler:events:type:MetaDataChange:version
urn:com:bea:aler:events:type:MetaDataChange:description
urn:com:bea:aler:events:type:CategorizationChanged:assetLifecycleStage
urn:com:bea:aler:events:type:CategorizationChanged:classification
urn:com:bea:aler:events:type:MetaDataChange:supported
urn:com:bea:aler:events:type:MetaDataChange:organizational ownership
urn:com:bea:aler:events:type:MetaDataChange:usagefee
セレクタは、コンテンツ・ベースのルーティングを実行するためにサブスクリプションにフィルタをアタッチする手段です。セレクタは、SQL 92構文を使用して定義します。例A-3は、イベントをフィルタ処理するためのフィルタ式を作成するために使用できるフィールドの完全なリストです。これらのフィールドはイベント・マネージャによってJMSメッセージにプロパティとして追加されます。また、イベントをフィルタ処理するために、これらのフィールドにアクセスするJMSメッセージ・セレクタを作成できます。
例A-3 フィルタ式を作成するために使用されるフィールド
submittedby_emailaddress = mrsmith@bea.com asset_description = Test Asset submittedby_name = aler_workflow_user submittedby_id = 99 asset_community = Java eventdata_description = new aler event eventsource_componentname = OER asset_name = TestAsset eventsource_componenttype = OER 10.3 asset_typeid = 154 eventdata_eventid = d0cdac55-c78f-4a29-8aec-6ea9ba8d31f1 eventdata_name = urn:com:bea:aler:events:type:MetaDataChange:name asset_activestatus = ACTIVE eventsource_location = ALERCore asset_id = 50100 eventdata_version = ver1.0 asset_version = 1
JMSメッセージ・セレクタの詳細は、次のWebサイトを参照してください。
次に、JMSメッセージ・セレクタの使用例を示します。
asset_id BETWEEN 50000 AND 50100
eventdata_name = 'urn:com:bea:aler:events:type:AssetSubmission' AND asset_id BETWEEN 50000 AND 50100
asset_name LIKE 'Inventory'
asset_id > 500
|
ヒント: 「次より小さい/次より大きい」を表すために使用される"< >"などの記号は、有効なXMLコンテンツではありません。式はXMLファイルで作成され、イベント・マネージャによって解析されるため、使いにくいXML文字はXMLルールを使用して管理する必要があります。たとえば、"asset_id > 500"と等しい"id > 500"を使用する必要があります。 |
イベント・マネージャでは、Oracle Enterprise Repositoryと同じロギング・フレームワークが使用されます。デフォルトでは、ファイルに記録するようにロギングが有効化されていますが、デバッグ文をコンソールに表示するには、<OER Domain>\WEB-INF\classesディレクトリにあるlog4fl.propertiesファイルに、例A-4に示すカテゴリを追加します。
例A-4イベント・マネージャ・イベントのロギングの構成
# eventing subsystem log4j.category.com.bea.infra.event.core= debug,eventingLog,stdout log4j.category.com.bea.infra.event.dm= debug,eventingLog,stdout log4j.category.com.bea.infra.event.facade= debug,eventingLog,stdout log4j.category.com.bea.infra.event.notifier= debug,eventingLog,stdout log4j.category.com.bea.infra.event.store= debug,eventingLog,stdout log4j.category.com.bea.infra.event.sub= debug,eventingLog,stdout
この項では、Oracle Business Process Managementプロセスの管理タスクについて説明します。
この項には次のトピックが含まれます:
イベント・マネージャでイベントを送信する準備が完了したら、イベントを処理するようプロセス・エンジンを構成する必要があります。Oracle Enterprise Repositoryがインストールされると、Oracle Business Process Managementプロセス・エンジンをインストールおよび構成するためのオプションが使用可能になります。この項では、Oracle Business Process Managementプロセス・エンジンが正常にインストールされていることを前提としています。
Oracle Business Process Managementプロセス・エンジンを起動し、参加者を定義するには、Oracle Business Process Management管理センターを起動する必要があります。
Oracle Business Process Management管理センターを起動するには、次の手順に従います。
<ORACLE_HOME>\obpm\enterprise\binディレクトリに移動し、次のファイルの1つをダブルクリックします。
obpmadmcenter.exe (WindowsまたはUNIX GUIベース)
./startwebconsole.sh (UNIXコンソール・ベース)。次に、ブラウザでhttp://<host>:8585/webconsole (たとえば、http://localhost:8585/webconsole)を指定します。
図A-6に示すように、Admin Centerページで、BPM Webアプリケーションの起動オプションをクリックします。
使用可能になったら、プロセス・アドミニストレータの起動オプションをクリックします。
必要な資格証明を入力するよう求められたら、インストール・プロセス中にFDIユーザー資格証明パネルで使用したBPM管理ユーザー名およびパスワードを入力します。これらの資格証明として推奨される例では、ユーザー名およびパスワードにbpm_adminを使用します。
Oracle Business Process Managementプロセス・エンジンを起動するには、次の手順に従います。
Oracle Business Process Managementプロセス・アドミニストレータ・ページで、図A-7に示すように、ページの左側にある「エンジン」リンクをクリックし、aler_engineプロセス・エンジンを開きます。
ページの右側にあるエンジン・アクションの下の「起動」アイコンをクリックし、aler_engineを起動します。エンジンが完全に起動するまでに数分かかる場合があります。エンジンのステータスが「準備完了」であることを確認します。
Oracle Business Process Managementプロセス・エンジンが実行されていることを確認したら、これを停止してから再起動すると、最新のworkflow.xmlの変更をロードできます。
この項では、Oracle Business Process Managementプロセス・エンジンの参加者を定義する方法について説明します。
FDIユーザー資格証明を使用して、Oracle Business Process Managementプロセス・アドミニストレータにログインし、プロセス・エンジンを起動/停止、および他のユーザーを作成できます。
Oracle Business Process Managementプロセス・エンジンがOracleの製品インストーラによってインストールされると、拡張登録フロー・ユーザーとしてaler_workflow_userが作成されます。デフォルトでは、パスワードはaler_workflow_passとして設定されていますが、図A-8に示すように、ナビゲータで「参加者」を選択し、「拡張プロパティ」セクションで「パスワードの変更」をクリックすることにより、プロセス・アドミニストレータでパスワードを変更できます。
新しい参加者を管理者のロールで登録することもできます。この新しい参加者は、イベント・マネージャのサブスクリプション・マネージャ・ファイルで構成できます。詳細は、A.4.5項「サブスクリプション・マネージャの構成」を参照してください。
次のパラメータは、Oracle Business Process Managementプロセス・アドミニストレータを使用してチューニングする必要があります。
「エンジン」、「<エンジン名>」、エンジン・ノード、「拡張プロパティ」ページに移動します。図A-9は、Oracle Business Process Managementプロセス・アドミニストレータ - 「拡張プロパティ」ページを示しています。
「エンジン」、「<エンジン名>」、「エンジン・データベース構成の編集」ページに移動します。図A-10は、Oracle Business Process Managementプロセス・アドミニストレータ - データベース・ランタイム・ページを示しています。
図A-10 Oracle Business Process Managementプロセス・アドミニストレータ - データベース・ランタイム
「エンジン」、「<エンジン名>」、「実行」ページに移動します。図A-11は、Oracle Business Process Managementプロセス・アドミニストレータ - メモリーおよびスレッド・ページを示しています。
Oracle Business Process Managementスタンドアロン・プロセス・エンジンのフェイルオーバーをサポートするには、環境内でバックアップ・エンジンを構成します。このフェデレーション内のエンジンの1つがPRIMARYとしてマークされ、他のエンジンはこのプライマリ・エンジンのバックアップになります。複数のエンジンをバックアップとして機能するように構成できます。指定したプライマリに障害が発生した場合、これらのバックアップ・エンジンのいずれかがプライマリになります。障害が発生したサーバーがオンラインに戻ると、プライマリとして機能しているサーバーのバックアップとして加わります。
バックアップ・エンジンの構成に関する詳細な手順は、次の場所にあるOracle Business Process Management管理ガイドのエンジンのフェイルオーバーの構成に関する項を参照してください。
http://download.oracle.com/docs/cd/E13165_01/bpm/docs65/admin_guide/index.html
Oracle Business Process Managementログ・ビューアを使用すると、プロセス実行エンジンによって記録された情報を読み取ることができます。定義するプロジェクトごとに一連のログ・ファイルが作成されます。Studioログ・ビューアにより、ファイルが読み取られて表示されるため、エンジンの実行をモニターして追跡できます。
ログ・ビューアを起動するには、<Oracle Business Process Management Enterprise Home>\binディレクトリ内のobpmlogviewer.exeファイルをダブルクリックします。
ログ・メッセージをフィルタ処理することにより、自動ワークフローで情報メッセージ、デバッグ・メッセージおよび致命的メッセージが記録されるようにすることができます。
プロセス・アドミニストレータのプリファレンス設定を使用してプロセス・エンジンの「ログ」ページで「デバッグ」レベルをオンにします。デフォルトでは、このレベルは「警告」に設定されています。
「エンジン」、「<エンジン名>」、「ログ」ページに移動します。図A-12は、Oracle Business Process Managementプロセス・アドミニストレータ - ロギング・プリファレンス・ページを示しています。
デバッグ・レベルをオンにすると、Oracle Enterprise Repository自動ワークフローに関する情報のみでなく、他のプロセス・エンジン情報も含む多くの情報が出力されることがわかります。デバッグ・ロギングをフィルタ処理してOracle Enterprise Repositoryフロー関連の情報のみが表示されるようにするには、図A-13に示すように、次の手順に従います。
ログ・ビューアで、一番左側にあるリスト・ボックス内の「メッセージ」を選択します。
横のリスト・ボックスで「次で始まる」を選択します。
テキスト・ボックスに「OER」と入力します。
「フィルタの適用」ボタンをクリックします。
次に示すように、記録されているすべてのイベント・メッセージに接頭辞の「ALER:」が表示されます。
この項では、OER自動ワークフローの開始方法を示すとともに、様々な高度なユースケースにおけるワークフローの使用について説明します。
この項には次のトピックが含まれます:
|
ヒント: 開始する前に、Oracle Business Process Managementプロセス・エンジンと連携して動作するよう構成されてバンドルされたOracle Business Process Management Webサービス・エンドポイントを使用した拡張登録フロー機能を素早く使用開始できるよう、A.2項「Oracle Enterprise Repository自動ワークフローの概要」を参照してください。 |
Oracle Enterprise Repositoryには、Oracle Enterprise Repositoryアセットの発行、受入れ、登録、および他のガバナンス・プロセスなどのOracle Enterprise Repositoryプロセスの自動化を試行する事前定義済のOracle Business Process Managementフローがバンドルされています。この項では、Oracle Enterprise Repositoryによってトリガーされるアセット・イベントを処理するためにOracle Business Process Managementプロセス・エンジンを起動する前に必要な構成について説明します。フローをトリガーするためのプロセス・エンジンの構成の詳細は、A.4項「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
また、これらのフローは、フレキシブルに使用できるよう設計されており、ワークフロー構成ファイル(workflow.xml)またはOracle Business Process Managementを使用してカスタマイズすることもできます。この項では、各フローについて詳しく説明するとともに、環境に合うようにフローを調整する方法の例も示します。
この項では、拡張登録フローを構成する方法について説明します。新しいワークフローを作成するには、次の手順に従います。
IDEで既存のOracle Business Process Managementプロセスを開きます。
新しいワークフローを追加します。この手順の詳細は、Oracle Business Process Managementのドキュメントを参照してください。
プロジェクトをアンデプロイしてからデプロイします。
A.6.3項「アセット・イベントのフローへのワイヤリング」の手順に従い、ワークフローをイベントにワイヤリングします。
この項では、ワークフロー構成XMLファイルを作成およびカスタマイズする方法について説明します。
ワークフロー構成ファイルにより、Oracle Enterprise Repository接続およびレジストラ情報が次のXMLデータからロードされます。
<alerconnection>
<uri>http://localhost.7001/aler/services/FlashlineRegistry</uri>
<registrar>
<user>admin</user>
<password>******</password>
</registrar>
</alerconnection>
セキュリティ暗号化パスワード・ツール(runWfSecurity.bat)を使用すると、ワークフロー構成ファイルに格納されているレジストラのパスワードを暗号化できます。このツールでは、ファイルが再帰的にスキャンされ、検出されたすべてのパスワード要素が暗号化されます。
詳細は、A.8.5項「パスワードの暗号化」を参照してください。
自動ワークフローは、図A-14に示すように、アセット・イベントのトリガー時に実行される1つ以上のフローにイベントをワイヤリングできるフレキシブルなフレームワークを使用して設計されています。
|
注意:
|
アセット・イベントのフローへのワイヤリングは、ワークフロー構成ファイル内で構成します。たとえば、次の構成スニペットは、"Asset Submitted"イベントがトリガーされたときに、ワークフロー構成ファイルに構成されているルールに基づいてアセットを自動的に受け入れるフローがトリガーされることを示しています。
<!--Community Flows-->
<state name="urn:com:bea:aler:events:type:AssetSubmission">
<action>CommunityAccept</action>
</state>
<!--The Multi_tier Flows-->
<state name="urn:com:bea:aler:events:type:AssetAccepted">
<action>MultiTier_Tier1_Assign</action>
</state>
<state name="urn:com:bea:aler:events:type:AssetTabApproved">
<action>MultiTier_NextTier_Assign</action>
</state>
<!--Asset Registration Status Flows-->
<state name="urn:com:bea:aler:events:type:AssetAllTabApproved">
<action>AllTabApproved_Register</action>
</state>
この例の構成では、次のイベントが様々なフローにワイヤリングされています。<action>要素には、実行されたフローの名前が含まれます。
アセットの「submitted」イベントがトリガーされたら、Community Acceptフローを実行します。
アセットの「accepted」イベントがトリガーされたら、MultiTier1フローを実行します。
タブの「approved」イベントがトリガーされたら、Multi-Tier Next Tierフローを実行します。
「all the tabs approved」イベントがトリガーされたら、Automatic Registrationフローを実行します。
一部のフローには、入力として必要なパラメータが使用されます。フローごとに異なるパラメータが渡されます。たとえば、ChangeCAS (Change Custom Access Settings)フローには、<customAccessSettings>がパラメータとして使用されます。次に、アセットが登録されたときにMyCASおよびMyCAS2カスタム・アセット設定が自動的に割り当てられるワイヤリングの例を示します。
<state name="urn:com:bea:aler:events:type:AssetRegister">
<action>ChangeCAS</action>
<customAccessSettings>
<customAccessSetting>MyCAS</customAccessSetting>
<customAccessSetting>MyCAS2</customAccessSetting>
</customAccessSettings>
</state>
この項では、Oracle Enterprise Repositoryのアセット・エディタを使用して実行される手動でのアセット受入れおよび登録プロセスを自動ワークフローで自動化する方法について説明します。Oracle Enterprise Repositoryのアセット・エディタおよびアセット登録プロセスの使用の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』を参照してください。
|
注意: リポジトリ・ユーザーが「アセットの発行」リンクを介してアセットを発行する場合は、コミュニティ受入れまたは自動受入れフローを有効にしないでください。現在、この構成はOracle Enterprise Repositoryではサポートされていません。 |
コミュニティ・フローは、自動割当てルールの構成を可能にすることによってアセットの受入れ、割当て、登録プロセスを自動化する方法を提供するとともに、様々な機関の間のフェデレーテッド・レジストラに関する概念を示します。すべてのコミュニティにわたって(システム・レジストラ通知を介して)多数のレジストラを送信するかわりに、システム・レジストラの数を1人または2、3人の個人に制限し、コミュニティの管理レジストラのかわりに自動受入れフローでアセットを受け入れるようにすることができます。コミュニティ・フロー機能により、コミュニティのためにアセット発行を承認する権限を持つ個人にアセット発行を分散できます。
コミュニティ・フローを使用して、次のシナリオに対応できます。
新しく発行されたアセットに関する多くの通知を単一のレジストラが受け取るのとは対照的に、自動フェデレーテッド・レジストラが受入れをサポートします。
アセット受入れが手動であっても、コミュニティ・フローを使用して、事前定義済の承認者へのアセット承認の割当てを自動化できます。事前定義済の承認者の作成は、次の2つの方法で行うことができます。
そのアセット内のすべてのタブに対する事前定義済の承認者のリストを作成します。
複数層割当て(これは複数層フローと同じですが、コミュニティ内で動作します)を使用します。
登録プロセスの自動化。次の条件が満たされると、アセットは自動的に登録されます。
すべてのタブが承認される場合
複数層プロセス内の最後の層が完了した場合
またはどちらかが最初に起こった場合
コミュニティはフロー構成内で構成され、アセット・タイプ、プロジェクトの作成などがコミュニティを指すことができます。
図A-14に、アセットのコミュニティをフローによって特定する方法、および自動受入れのルールをフローによって特定する方法を示します。
|
注意: 自動登録の場合も同じフローチャートが適用されます。単純にautoAcceptをautoRegisterに置き換えてください。 |
プロジェクトに対してコミュニティを定義するには、<producingProjectSettings>要素を使用します。次の例は、IDが「40000」である「SOA Center of Excellence」コミュニティに対して「Registry」という名前のプロジェクトを作成する方法を示しています。
<producingProjectSettings> <producingProject name="Registry" community="SOA Center of Excellence id="40000"/> </producingProjectSettings>
アセット・タイプに対してコミュニティを定義するには、<assetType>要素を使用します。次の例は、IDが「158」である「SOA Center of Excellence」コミュニティに対して「Application」という名前のアセット・タイプを作成する方法を示しています。
<assetType name="Application" community="SOA Center of Excellence
id="158">
<allTabs>
workflow.xml内でアセットに対してコミュニティを設定するかわりに、タイプ・マネージャおよびアセット・エディタを使用してアセット・タイプに対してコミュニティを設定できます。
タイプ・マネージャで、次の手順に従います。
「コミュニティ」フィールドを有効にするアセット・タイプを選択し、「ビューア」タブをクリックします。
図A-16に示すように、「グループで表示」ボタンをクリックします。
次に、アセット・エディタで、次の手順に従います。
タイプ・マネージャで選択したアセット・タイプのアセットを選択します。
図A-17に示すように、「概要」タブの「コミュニティ」フィールドで、そのアセットに使用するコミュニティ名を設定します。
A.6.4.1.2項「アセット・タイプに対するコミュニティの設定」でコミュニティを設定するための手順に従った後、アセット・エディタでアセットのコミュニティ名を設定した場合、アセット・エディタでアセットに設定したコミュニティ名により、workflows.xmlファイルに設定されているコミュニティ名がオーバーライドされます。
次の例は、アセットを自動的に受け入れるために「SOA Center of Excellence」コミュニティを設定する方法を示しています。
<communities name="SOA Center of Excellence autoAccept="true">
|
注意: リポジトリ・ユーザーが「アセットの発行」リンクを介してアセットを発行する場合は、コミュニティ受入れまたは自動受入れフローを有効にしないでください。現在、この構成はOracle Enterprise Repositoryではサポートされていません。 |
AssetSubmittedイベントがコミュニティ・フローにワイヤリングされている場合、<approvers>要素には、コミュニティ・フローによって自動的に割り当てられる承認者がリストされます。
<communities name="Java" autoAccept="true">
<approvers>
<alerid>5003</alerid>
<alerid>5004</alerid>
</approvers>
タブ承認フローで<alerid>を使用する手順は、A.6.5.2項「タブ承認のための<alerid>の使用」を参照してください。
複数層割当ては複数層フローと同じですが、コミュニティ内で動作します。複数層フローの詳細は、A.6.5項「複数層自動割当てフロー」を参照してください。
|
注意: コミュニティの複数層構成内で提供されるタブは、すべてのアセット・タイプ内に存在する共通タブである必要があります。 |
次の例は、アセットを自動的に受け入れて登録するために「SOA Center of Excellence」コミュニティを設定する方法を示しています。
<communities name="SOA Center of Excellence autoAccept="true" autoRegister="true">
アセットの受入れ、割当ておよび登録を行うには、レジストラのユーザー名およびパスワードが必要です。コミュニティ・フローでは、アセットが属するコミュニティからレジストラ情報がロードされます。アセットがコミュニティに属していない場合、またはレジストラ情報がコミュニティ内にない場合は、グローバル・レジストラがコミュニティ・フローによって使用されます。
コミュニティ・フローによってコミュニティ・タグが取得される優先順位を次に示します(図A-13を参照)。
受信イベント内のコミュニティ・タグ
受信アセットが属するアセット・タイプ内のコミュニティ・タグ
受信アセットが属する、プロジェクトの作成内のコミュニティ・タグ
コミュニティ・フローを使用してアセットの受入れおよび登録を自動的に行う以外に、図A-13に示すように、次のルールを使用してアセットの受入れおよび登録を行うことができます。
|
注意: リポジトリ・ユーザーが「アセットの発行」リンクを介してアセットを発行する場合は、コミュニティ受入れまたは自動受入れフローを有効にしないでください。現在、この構成はOracle Enterprise Repositoryではサポートされていません。 |
AssetType要素内のautoAcceptおよびautoRegisterフラグを使用して、アセットの受入れおよび登録を自動的に行うことができます。
<assetType name="Application" autoAccept="true" autoRegister="true"
id="158">
<allTabs>
<tab name="Overview"/>
<tab name="Application Lifecycle"/>
</allTabs>
デフォルトでは、フローではautoAcceptおよびautoRegisterフラグは検索されません。理由は、これらの参照によってパフォーマンスに影響が及ぶ可能性があるからです。ただし、これは、<action>フラグの使用によって有効にすることができます。
次の例に示すように、フローでカテゴリ分け設定の使用が必要になる場合は、<action>フラグをtrueに設定する必要があります。しない場合、カテゴリ分け設定は無視されます。
<catgorizationTypeSettings action="true">
<catgorizationType name="AssetFunction" type "100">
<catgorizations name="Application Adapters" autoAccept="false"/>
<catgorizations name="Customer Information Acquisition" autoAccept="false"/>
<catgorizations name="eCommerce Frameworks" autoAccept="false"/>
</catgorizationType>
発行者ロールを使用して、アセットの受入れおよび登録を自動的に行うことができます。次の構成に指定されているロールが発行者ロールと一致する場合、アセットは自動的に受け入れられます。
<automation>
<autoRoles>
<role>admin</role>
<role>accesAdminstrator</role>
</autoRoles>
<autoApprovalTabs>
<tab name="Documentation"/>
</autoApprovalTabs>
</automation>
場合によっては、図A-13に示すように、特定のイベント・トリガーについて一致するルールが複数存在するため、受入れや登録のために自動受入れフローおよび自動登録フローで各ルールを評価する方法に関する階層が存在します。フローでは、次のメタデータ部分がスキャンされ、次の優先度でいずれかのメタデータが検出されると、フローは中断され、そのメタデータ内の設定が使用されます。
フロー構成ファイル内のAssetType設定
受信アセットで検出されたコミュニティ・タグ
フロー構成ファイル内のAssetType設定で検出されたコミュニティ・タグ
フロー構成ファイル内のProducingProject設定で検出されたコミュニティ・タグ
フロー構成ファイル内のカテゴリ分け設定
フロー構成ファイル内のカテゴリ分け設定
フロー構成ファイル内のSubmitterRole設定
複数層承認フローにより、層と呼ばれる複数の手順でアセット・タブ承認プロセスを構築します。アセット承認タブは層にグループ化できます。また、複数層フローでは、指定した承認者によってすべてのタブが承認されているかどうかを確認するために各層が追跡されます。層内の最後のタブが承認されると同時に、複数層フロー内では、指定した承認者の次のレベルにアセットを割り当てることによって次の層が開始されます。
場合によっては、層と呼ばれる複数の手順でタブ承認用のタブを割り当てる方が望ましいことがあります。たとえば、文書タブを承認する前にアーキテクチャ・タブを承認する方が望ましいことがあります。理由は、アーキテクチャに関する問題は、文書の専門家が着目する前に修正する必要があるからです。
以前のリリースでは、タブ承認は、レジストラが各タブ承認のステータスを手動で追跡してからこのタブを次の層レベルの承認のために割り当てることにより、手動で行われていました。複数層フローの場合、このプロセスはフローによって自動化されます。
図A-18に、複数層プロセスのフローを示します。
workflow.xmlファイルが生成されると、<allAssetSettings>セクションの下に次のXMLセクションが作成されます。これらが、Oracle Enterprise Repository内に作成されるすべてのユーザーです。
<alerUsers>
<user name="admin" alerid="99"/>
<user name="allpriv" alerid="50000"/>
<user name="nopriv" alerid="50001"/>
<user name="tier1" alerid="50002"/>
<user name="tier2" alerid="50003"/>
<user name="mrsmith" alerid="50004"/>
</alerUsers>
ワークフロー管理者としては、アセット・タブの承認に使用する名前別にユーザーを識別し、対応する<alerid>を使用する必要があります。これにより、この<alerid>を、次の複数層承認フローのようにワークフローXMLで使用できます。
<tiers>
<tier name="Tier1">
<approvers>
<alerid>50001</alerid>
</approvers>
<tabs>
<tab name="Overview"/>
<tab name="Technical"/>
<tab name="Documentation"/>
</tabs>
</tier>
次の例は、タブを自動的に受け入れるために「SOA Center of Excellence」コミュニティでタブ承認者のために複数層フローを構成する方法を示しています。
<communities name="SOA Center of Excellence autoAccept="true">
<tiers>
<tier name="Tier1">
<approvers>
<alerid>5002</alerid>
</approvers>
<tabs>
<tab name="Overview"/>
<tab name="Taxonomy"/>
</tabs>
</tier>
<tier name="Tier2">
<approvers>
<alerid>5003</alerid>
</approvers>
<tabs>
<tab name="Architecture/">
</tabs>
</tier>
</tiers>
</communities>
|
注意: コミュニティの複数層構成内で提供されるタブは、すべてのアセット・タイプ内に存在する共通タブである必要があります。 |
次の例は、複数層承認のためにアセット・タイプ「Application」のタブを構成する方法を示しています。
<assetType name="Application" id="158">
<allTabs>
<tab name="Oveview"/>
<tab name="Application Lifecycle"/>
<tab name="License Information"/>
<tab name="Certification Tracking"/>
<tab name="Taxonomy"/>
<tab name="Documentation"/>
<tab name="Relationships"/>
<tab name="Support"/>
<tab name="Cost Categories"/>
<tab name="Ownership"/>
<tab name="Technology Stack"/>
<tab name="Operational Information"/>
<tab name="Miscellaneous"/>
</allTabs>
<tiers>
<!--Please change "_CHANGE_TIER1_NAME_" to the name of the Tier-->
<!--Example:- "Tier1"-->
<tier name="Tier1">
<approvers>
<alerid>99</alerid>
</approvers>
<tabs>
<!--Please change "_CHANGE_TABNAME_" to the name of the Tab-->
<!--Example:- "Documentation"-->
<tab name="Overview"/>
<tab name="Taxonomy"/>
</tabs>
</tier>
</tiers>
メタデータ・フローは、アセットのメタデータ要素が変更されるときに1つ以上のアクションを実行するフローのグループです。変更されるメタデータ要素は、1つ以上のフローにワイヤリングされたイベントをトリガーします。イベントをフローにワイヤリングする手順は、A.6.3項「アセット・イベントのフローへのワイヤリング」を参照してください。
メタデータ変更フローを適用できるいくつかのユースケースを次に示します。
アセットの「Asset Lifecycle Stage」メタデータ要素を「Build」から「Release」に変更する場合は、アセットに対するアクセス制御をより制限するようにカスタム・アクセス設定を変更できます。
アセットの「Name」を変更する場合は、サブスクライバに通知できます。
要素のメタデータ要素を変更する場合は、アセットを「Change Management」承認プロセスで処理できます。「Change Management」には次の処理が含まれます。
「Change Management」という名前のタブの承認を解除します。図A-19に、アセット・エディタの「変更の管理」タブを示します。
アセットをレジストラに割り当てます。
「再割当ての理由」フィールドに変更の種類を追加してレジストラをサポートします。
この項では、メタデータ変更フローの構成について説明します。この項には次のトピックが含まれます:
メタデータ変更フローにワイヤリングできる状態を次に示します。
|
注意: これらのイベント以外にも、カスタム・カテゴリ分けを含む任意のカテゴリ分け変更をワイヤリングできます。 |
<state name="urn:com:bea:aler:events:type:MetaDataChange:name"> <state name="urn:com:bea:aler:events:type:MetaDataChange:version"> <state name="urn:com:bea:aler:events:type:MetaDataChange:description"> <state name="urn:com:bea:aler:events:type:CategorizationChanged: assetLifecycleStage"/> <state name="urn:com:bea:aler:events:type:CategorizationChanged:classification"> <state name="urn:com:bea:aler:events:type:MetaDataChange:supported"> <state name="urn:com:bea:aler:events:type:MetaDataChange:organizationalOwnership"> <state name="urn:com:bea:aler:events:type:MetaDataChange:usageFee">
ほとんどのアセット・タイプの場合、usageFeeフィールドはアセット・エディタの「その他」タブにあります。
アクションにワイヤリング可能な事前定義済のフローを次に示します。これらのフロー名は、<action>要素内のコンテンツとして表示され、これがイベントの発生時に実行する必要のあるアクションであることを示します。<action>以外のすべての要素は、特定のフローによって使用されるパラメータです。
ChangeCAS: アセットへの1つ以上のカスタム・アクセス設定に適用されます。
ChangeAssetLifecycle: アセットのアセット・ライフサイクル・ステージを設定します。
ChangeClassification: アセットの分類を設定します。
ReAssignAssetToRegistrar: アセットをレジストラに割り当てます。
AddCommunityTag: アセットの「Community」をOracle Enterprise Repositoryに保存します。
NotifySubscriber: メタデータ変更をサブスクライバに通知します。
NotifyRegistrationActors: メタデータ変更についてレジストラ、サブスクライバ、所有者などに通知します。
NotifyCustomUser: メタデータ変更について構成済のカスタム・ユーザーに通知します。
UnapproveChangeManagementTab: 変更管理プロセスをトリガーします。
ResetChangeManagementTab: 「変更の管理」タブが承認されるとすぐに、「変更の管理」タブの「再割当ての理由」フィールドをリセットします。
CommunityAccept: アセットの発行時に使用されるコミュニティ受入れフローを呼び出します。
CommunityAssign: アセットの受入れ時に使用されるコミュニティ割当てフローを呼び出します。
MultiTier_Tier1_Assign: アセットの受入れ時に使用される多層フローを呼び出します。
MultiTier_NextTier_Assign: タブの承認時に使用される多層フローを呼び出します。
ApproveTabAction: 1つ以上のタブを承認します。
UnapproveTabAction: 1つ以上のタブの承認を解除します。
AutoApproveTabAction: 発行者のロールに基づいて1つ以上の構成済のタブを承認します。
AllTabsApproval_Register: すべてのタブが承認されたときにアセットを登録するためのフローを呼び出します。
ReAssignAssetToRegistrar: アセットをレジストラに割り当てて承認します。このフローでは、コミュニティ・レジストラ(構成されている場合)を使用します。構成されていない場合は、グローバル・レジストラを使用します。
ResetFlowState: タイマー・ベースのフローで使用される状態情報をリセットします。これは、未発行のアセットをタイマー・フローで追跡する場合や、状態が未発行から発行済に変更された場合に役立ちます。これにより、状態情報をリセットできるようになります。リセットしない場合、アセットの状態が未発行に戻ると、ワークフローでは以前に設定されたものと同じ状態を使用します。これは必ずしも望ましい設定とはかぎりません。ResetFlowStateアクションを適切なイベントまたは状態で使用して、状態情報をリセットできます。
UnRegisterAssetAction: アセットが登録済の状態の場合に、そのアセットの登録を解除します。
autoSyncAlerToUddi: サービスをOracle Enterprise RepositoryからOracle Service Registryに移動するタイマーベースのワークフローです。
autoSyncUddiToAler: サービスをOracle Service RegistryからOracle Enterprise Repositoryに移動するタイマーベースのワークフローです。
PublishAssetToUddi: 個々のサービスが登録されるとき、またはサービスのライフサイクルが変更されるときにトリガーされるイベントをワイヤリングして、これらのサービスとそのメタデータをOracle Service Registryに移動します。
このワークフローの詳細は、10.3.1.1項「ワークフローを使用したOracle Registry Repository Exchange Utilityの起動」を参照してください。
次の構成例では、アセットが登録されたときに「NotifySubscriber」と「ChangeCAS」という名前の2つのフローを呼び出すよう指定しています。<customAccessSettings>要素は、適用する必要のあるCASの名前をフローに通知するChangeCASフローのパラメータです。
<state name="urn:com:bea:aler:events:type:AssetRegister">
<action>NotifySubscriber</action>
<action>ChangeCAS</action>
<customAccessSettings>
<customAccessSetting>MyCAS</customAccessSetting>
<customAccessSetting>MyCAS2</customAccessSetting>
</customAccessSettings>
</state>
<state name="urn:com:bea:aler:events:type:AssetUnAccept">
<action>NotifySubscriber</action>
<action>ChangeClassification</action>
<classification>Approved</classification>
</state>
メタデータ要素の変更時のみでなく、メタデータ要素が特定の値を使用する場合にもフローを呼び出すことができます。たとえば、アセットの「Asset Lifecycle Stage」メタデータ要素を「Build」から「Release」に変更する場合は、カスタム・アクセス設定の1つのセットを適用できます。さらに、この値を「Plan」から「Build」に変更する場合は、別のセットを適用できます。次はその例です。
<state
name="urn:com:bea:aler:events:type:CategorizationChanged:AssetLifecycleStage"
value="Stage 4 - Release">
<action>ChangeCAS</action>
<customAccessSettings>
<customAccessSetting>MyCAS</customAccessSetting>
</customAccessSettings>
</state>
<state
name="urn:com:bea:aler:events:type:CategorizationChanged:AssetLifecycleStage"
value="Stage 3 - Build">
<action>ChangeCAS</action>
<customAccessSettings>
<customAccessSetting>MyCAS2</customAccessSetting>
</customAccessSettings>
</state>
アセットの分類を設定します。ChangeClassificationでは、次の要素を使用して分類を設定します。
<state name="urn:com:bea:aler:events:type:AssetRegister">
<action>ChangeClassification</action>
<classification>Approved</classification>
</state>
1つ以上のカスタム・アクセス設定をアセットに適用します。ChangeCASでは、次の要素を使用してカスタム・アクセス設定を行います。
<state name="urn:com:bea:aler:events:type:AssetRegister">
<action>ChangeCAS</action>
<customAccessSettings>
<customAccessSetting>MyCAS</customAccessSetting>
<customAccessSetting>MyCAS2</customAccessSetting>
</customAccessSettings>
</state>
アセットのアセット・ライフサイクル・ステージを設定します。ChangeAssetLifeCycleでは、次の要素を使用してアセット・ライフサイクルを設定します。
<state name="urn:com:bea:aler:events:type:AssetRegister">
<action>ChangeAssetLifeCycle</action>
<assetLifeCycle>Stage 3 - Build</assetLifeCycle>
</state>
ApproveTabActionフローでは、アセットの1つ以上のタブを承認します。次の構成では、「Overview」および「Taxonomy」タブを承認します。
<state name=?urn:com:bea:aler:events:type:MetaDataChange:name?>
<action>ApproveTabAction</action>
<approveTabs>
<tab name="Overview"/>
<tab name="Taxonomy"/>
</approveTabs>
</state>
次の要素では、タブのリストを構成して、UnapproveTabActionフローで承認が解除されるようにします。
<state name="urn:com:bea:aler:events:type:MetaDataChange:name">
<action>UnApproveTabAction</action>
<unapproveTabs>
<tab name="Overview"/>
<tab name="Taxonomy"/>
</unapproveTabs>
</state>
AutoApproveTabActionフローでは、発行者のロールに基づいてタブを承認します。たとえば、<allAssetSettings>の下にある次の要素では、発行者のロールに基づいて自動的に承認する必要のあるタブのリストを構成します。この場合、受入れ可能なロールも構成されます。
<automation>
<autoRoles>
<role>admin</role>
<role>accesAdminstrator</role>
</autoRoles>
<autoApprovalTabs>
<tab name="Documentation"/>
</autoApprovalTabs>
</automation>
フローを呼び出すための構成を次に示します。
<state name="urn:com:bea:aler:events:type:AssetRegister">
<action>AutoApproveTabAction</action>
</state>
要素のメタデータ要素を変更する場合は、アセットを「Change Management」承認プロセスで処理できます。このプロセスには次の処理が含まれます。
「変更の管理」タブの承認を解除します。図A-19に、アセット・エディタの「変更の管理」タブを示します。
アセットをレジストラに割り当てます。
「再割当ての理由」フィールドに変更の種類を追加してレジストラをサポートします。
<state name="urn:com:bea:aler:events:type:MetaDataChange:name"> <action>UnApproveChangeManagementTab</action> </state>
このフローでは、「変更の管理」タブが承認されるとすぐに、「変更の管理」タブの「再割当ての理由」フィールドをリセットします。
<state name="urn:com:bea:aler:events:type:AssetTabApproved">
<action>MultiTier_NextTier_Assign</action>
<action>ResetChangeManagementTab</action>
</state>
メタデータ変更について構成済のカスタム・ユーザーに通知します。次に示すように、ユーザーの電子メール・アドレスは、<allAssetSettings>の下にある<customNotification>要素内で構成されます。
<allAssetSettings>
<notification timerInterval="id">
<customNotification>
<emailAddress>smith@bea.com</emailAddress>
</customNotification>
</notification>
次に示すように、メタデータ変更フローは、特定のタブの承認に基づいて実行できます。
<state name="urn:com:bea:aler:events:type:AssetTabApproved" value ="Overview">
<action>MultiTier_NextTier_Assign</action> <action>ChangeAssetLifecycle</action>
<assetLifecycle>Stage 3 - Build</assetLifecycle>
</state>
時間ベースのエスカレーション・フローでは、様々な状態のアセットを追跡し、すべての当事者に通知します。次の項では、時間ベースのエスカレーション・フローを構成する方法について説明します。時間ベースのエスカレーション・フローには4種類があり、次の各項で説明するように、各種を個別に構成できます。
workflow.xml構成ファイルを開き、<notification>要素を探します。
<notification timerInterval="1d">
<numTimesNotify>10</numTimesNotify>
<daysBeforeNextNotification>2</daysBeforeNextNotification>
timerInterval要素は、フローがトリガーされるまでの間隔を指定します。本番環境では、この要素を"1d"に設定する必要があります。この場合、フローは1日に1回トリガーされます。ただし、テストを行う場合は、"1m"または"5m"に設定してフローを毎分または5分ごとにトリガーすることができます。また、リフレッシュ・ツールを使用してリフレッシュできる他のフィールドの変更とは異なり、このフィールドが変更されるたびにイベント・エンジンを再起動する必要があります。
numTimesNotify要素は、時間ベースのエスカレーション・フローで通知を送信する回数を指定します。
daysBeforeNextNotification要素は、通知を送信する間隔を日数で指定します。
|
注意: テストの目的で分単位の間隔でフローをトリガーするようにtimerInterval要素が分単位で構成されている場合は、daysBeforeNextNotificationに指定された間隔も分単位であると解釈されます。 |
図A-20に、時間ベースのエスカレーション・フローを示します。
このフローでは、「未発行」ステータスのアセットを追跡し、アクションを実行するために所有者に通知を送信します。
<owner_resubmit action="false" days="0" regressOnInaction="true" queryOperator="eq"/>
action="true"はフローを有効にし、action="false"はフローを無効にします。
days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。
regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。たとえば、未発行のアセットを削除できます。
queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。
このフローでは、「未受入れ」ステータスのアセットを追跡し、アクションを実行するためにレジストラに通知を送信します。
<registrar_accept action="false" days="0" regressOnInaction="true" queryOperator="eq"/>
action="true"はフローを有効にし、action="false"はフローを無効にします。
days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。
regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。たとえば、発行済のアセットを未発行にすることができます。
queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。
このフローでは、「未承認」ステータスのアセットを追跡し、アクションを実行するために承認者に通知を送信します。
<assignees_approve action="false" days="0" regressOnInaction="true" queryOperator="eq"/>
action="true"はフローを有効にし、action="false"はフローを無効にします。
days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。
regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。たとえば、受入れ済のアセットを未受入れにすることができます。
queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。
このフローでは、「未登録」ステータスのアセットを追跡し、アクションを実行するために承認者に通知を送信します。
registrar_register action="false" days="0" regressOnInaction="true" queryOperator="eq"/>
action="true"はフローを有効にし、action="false"はフローを無効にします。
days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。
regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。たとえば、登録済のアセットを未登録にすることができます。
queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。
有効期限の検証フローでは、有効期限より前に期限が切れたアセットや、期限日に期限が切れたアセットを追跡し、すべての当事者に警告通知を送信します。有効期限のX日後に、アセットの登録を解除します。有効期限のY日後に、アセットを非アクティブにします。有効期限のZ日後に、アセットを削除します。
<notification timerInterval="1d">
<numTimesNotify>10</numTimesNotify>
<daysBeforeNextNotification>2</daysBeforeNextNotification>
timerInterval属性は、フローがトリガーされるまでの間隔を構成します。この属性は"1d"に設定する必要があります。この場合、間隔は1日です。ただし、テストを行う場合は、"1m"または"5m"に設定して毎分または5分ごとにトリガーすることができます。また、リフレッシュ・ツールを使用してリフレッシュできる他のフィールドの変更とは異なり、このフィールドが変更されるたびにイベント・エンジンを再起動する必要があります。
numTimesNotify要素は、有効期限の検証フローで通知を送信する回数を指定します。
daysBeforeNextNotification要素は、通知を送信する間隔を日数で指定します。
<expiration>
<expiration_warning action="false" days="10" owner="false" subscriber="false" contact="99"/>
<unregister_after_expire action="true" days="10" queryOperator="eq"/>
<inactive_after_expire action="true" days="10" queryOperator="eq"/>
<delete_after_expire action="true" days="10" queryOperator="eq"/>
</expiration>
図A-21に、有効期限の検証フローを示します。
アセットの有効期限を設定するには、図A-22に示すように、アセット・エディタの「その他」タブにある「有効期限(yyyy-MM-dd)」フィールドに日付を指定します。
次の行では、警告の通知を有効にして、その通知を受け取るユーザーを指定します。
<expiration_warning action="false" days="10" owner="false" subscriber="false" contact="99"/
|
注意: days要素により、警告を送信する必要のある、有効期限までの日数を構成します。 |
次の行では、メタデータ変更フローを有効にして、有効期限の10日後にアセットの登録を解除します。
<unregister_after_expire action="true" days="10" queryOperator="eq"/>
次の行では、メタデータ変更フローを有効にして、有効期限の10日後にアセットを非アクティブにします。
<inactive_after_expire action="true" days="10" queryOperator="eq"/>
自動登録フローでは、多くの状況下で電子メール通知が自動的に送信されます。新しいフローのための新しい電子メール・テンプレートは5つあります。電子メール・テンプレートはOracle Enterprise Repository内に格納され、フローでは名前と値のペアを渡してOracle Enterprise Repository APIを呼び出します。この名前と値のペアは、後でOracle Enterprise Repositoryによって置き換えられます。
管理者は、他の電子メール・テンプレートの場合と同じ方法で電子メールの件名や本文などをカスタマイズできます。自動ワークフローで使用されるテンプレートを次に示します。
アセットのメタデータが変更されました: アセットに割り当てられたレジストラとユーザーに、メタデータが変更されたことを通知します。
登録ステータスが変更されていません: アセットに割り当てられたレジストラとユーザーに、登録ステータス<%asset.reg.status%>が<%action.pending.days%>日を超えて変更されていないことを通知します。
期限切れのアセットのステータスが変更されました: 期限切れのアセットに割り当てられたレジストラとユーザーに、ステータスが変更されたことを通知します。
有効期限が近づいています: アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が近づいていることを通知します。
アセットが期限切れになりました: アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が切れたことを通知します。
電子メール・テンプレートの詳細は、第8章「電子メール・テンプレートの使用」を参照してください。
この項では、電子メール通知ユースケースを示し、次の電子メール・テンプレートをトリガーする方法について説明します。
アセットが期限切れになりました: アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が切れたことを通知します。
この電子メール・テンプレートは、アセットが期限切れになるたびにトリガーされます。この電子メール・テンプレートは、拡張ワークフロー構成の一部として作成されます。アセットの有効期限を設定するには、アセット・エディタの「その他」タブにある「有効期限(yyyy-MM-dd)」フィールドに日付を指定します。workflow.xmlには、アセットが期限切れになったときに実行する処理内容を指定するための要素があります。
アセットのステータスが戻されました: アセットに割り当てられたレジストラとユーザーに、アセット登録ステータスが<%action.pending.days%>日を超えて変更されていないことを通知します。
この電子メール・テンプレートは、拡張ワークフロー構成の一部としても作成されます。たとえば、<notification timerInterval="1d">の下には、<registrar_accept action="false" days="5" regressOnInaction="true" queryOperator="eq"/>があります。このフローでは、指定した日数の間「受入れ済」ステータスであるアセットを追跡し、アクションを実行するためにレジストラに通知を送信します。
regressOnInaction="true"である場合、アクションが実行されていないアセットを元の状態に戻します。たとえば、受入れ済のアセットを未受入れにすることができます。
アセットが使用されています: アセットの通知電子メール・フィールドに指定されている連絡先に、アセットが使用されていることを通知します。
この電子メール・テンプレートは、アセットがプロジェクト内で使用されるたびにトリガーされます。この電子メール・テンプレートにより、アセットの「その他」の下にある通知電子メール・テキスト・フィールドに指定されている電子メール・アドレスに通知が送信されます。
コンプライアンス・テンプレートが適用されました: コンプライアンス・テンプレートがプロジェクトに適用されたときにプロジェクト・リーダーに通知します。
この電子メール・テンプレートは、コンプライアンス・テンプレート・タイプがプロジェクトに割り当てられるたびにトリガーされます。コンプライアンス・テンプレート・タイプは、アセット・タイプのアーキタイプの一部です。
アセットのメタデータが変更されました: アセットに割り当てられたレジストラとユーザーに、メタデータが変更されたことを通知します。
この電子メール・テンプレートは、拡張ワークフロー構成の一部でもあり、メタデータが変更されるたびにトリガーされます。メタデータ変更フローは複数存在します。詳細は、A.6.6項「メタデータ変更フロー」を参照してください。
新しいアセット・バージョンが開発中です: アセットの新しいバージョンが開発されるたびにサブスクライバに通知します。
この電子メール・テンプレートは、新しいアセット・バージョンが開発されるたびにサブスクライバに通知します。新しいバージョンは、「次のバージョン」または「前のバージョン」というリレーションシップに基づいて識別されます。
新しいバージョンが登録されました: アセットの新しいバージョンが登録されるたびにサブスクライバに通知します。
この電子メール・テンプレートは、新しいアセット・バージョンが登録されるたびにサブスクライバに通知します。新しいバージョンは、「次のバージョン」または「前のバージョン」というリレーションシップに基づいて識別されます。
有効期限が近づいています: アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が近づいていることを通知します。
この電子メール・テンプレートは、拡張ワークフロー構成でも使用され、アセットの有効期限が近づくたびにトリガーされます。たとえば、<expiration_warning action="false" days="5" owner="false" subscriber="false" contact="admin@example.com" queryOperator="eq"/>などです。
登録ステータスが変更されていません: アセットに割り当てられたレジストラとユーザーに、登録ステータス'<%asset.reg.status%>'が<%action.pending.days%>日を超えて変更されていないことを通知します。
この電子メール・テンプレートは、ワークフロー構成でも使用され、登録ステータスがワークフロー構成に指定された日数の間変更されない場合にトリガーされます。たとえば、<registrar_register action="false" days="5" regressOnInaction="false" queryOperator="eq"/>などです。
期限切れのアセットのステータスが変更されました: 期限切れのアセットに割り当てられたレジストラとユーザーに、ステータスが変更されたことを通知します。
この電子メール・テンプレートは、拡張ワークフロー構成でも使用され、期限切れのアセットのステータスが変更されるたびにトリガーされます。
使用方法が再割当てされました: アセット使用レコードが再割当てされたことをユーザーに通知します。
この電子メール・テンプレートは、複数の場所からトリガーされます。
「プロジェクトの詳細」で、次の手順を実行します。
プロジェクトの詳細に移動します。
ユーザー/使用方法の再割当てをクリックします。
使用方法のみ再割当てを選択します。
現在のまたは別のプロジェクトを選択します。
「次」をクリックします。そのプロジェクトに対応するユーザーのリストが表示されます。
使用方法の転送先のユーザーを選択します。
この電子メール・テンプレートは、使用方法が転送されたユーザーに通知を送信します。
「プロジェクトの編集」で、次の手順に従います。
「プロジェクトの編集」をクリックします。
「ユーザーの編集」をクリックします。
使用レコードがあるユーザーを削除します。使用方法を転送できるユーザーの「割当て」オプションが表示されます。
この電子メール・テンプレートは、使用方法が転送されたユーザーに対する通知をトリガーします。
この項では、Oracle Enterprise Repositoryワークフローに関する次の既知の問題について説明します。
workflow-tools/refresh_workflows.shファイルには、ハードコード化されたJDKへのパスが含まれていますが、このパスは無効です。別のJDKを使用している場合、refresh_workflows.shファイルを手動で編集してそのJDKにマップする必要があります。
Windowsでファイルを変更し、UNIXでCR/NL文字を処理する方法を理解しないエディタでこのファイルを保存する場合、次のコマンドを実行してLF文字を<file.sh>ファイルから削除する必要があります。
cat filename.sh | tr -d '\015' > filename.sh.tmp; mv filename.sh.tmp filename.sh
この項では、Oracle Enterprise Repository用のJMSサーバーを構成する方法について説明します。
この項には次のトピックが含まれます:
イベント・マネージャは、デフォルトで有効になっているApache ActiveMQ JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。ただし、OracleのWeblogic Server JMSまたはIBM WebSphere Application Serverなどの外部JMSサーバーを使用する場合は、Oracle Enterprise Repositoryの複数のシステム設定を構成する必要があります。
|
注意: Oracle Enterprise RepositoryがWebSphere 6.xにデプロイされている場合、ActiveMQとOracle Enterprise Repositoryによって使用されるクラスの競合のため、組込みApache ActiveMQ JMSサーバーは使用できません。したがって、WebSphere 6.xのユーザーは、WebSphere 6.xに用意されているデフォルトのJMS実装を使用する必要があります。A.7.5項「WebSphere 6.1.0.5でのJMSプロバイダの構成」を参照してください。 |
Oracle Enterprise Repositoryのシステム設定セクションを使用して、Oracle Enterprise Repositoryの基本操作を構成、および特定の機能を有効/無効にできます。イベント・マネージャのJMS関連の設定は、外部統合カテゴリのイベンティング・グループの下にあります。システム設定の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repository統合ガイド』を参照してください。追加の「イベンティング」プロパティは、A.4項「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
外部JMS製品を構成するには、内部のApache ActiveMQ JMSサーバーを無効にする必要があります。また、外部JMS用のJNDIおよびJMSプロパティも構成する必要があります。
|
注意: 次の手順は、単一の外部JMSサーバーを構成するためのものです。クラスタ内の複数のJMSサーバーを構成する手順は、A.7.4項「Oracle Enterprise Repositoryクラスタ内のJMSサーバーの構成」を参照してください。 |
Oracle Enterprise Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。
「システム設定」の「検索」ボックスに「Event」と入力し、イベント・マネージャ関連の設定をすべて表示します。
「イベント・マネージャ組込みJMS有効化」プロパティの横にある「False」をクリックし、内部JMSサーバーのプロパティcmee.eventframework.embedded.jms.enabledを無効にします。これにより、イベント・マネージャが外部JMSサーバーを使用するようにします。
|
注意:
|
eventing.propertiesファイルで、次の必須JNDIプロパティを構成します。
JNDI URL: cmee.eventframework.jndi.provider.url
JNDI URLを指定します。たとえば、t3://localhost:7001などです。
JNDI User Name: cmee.eventframework.jndi.user
JNDIユーザー名を指定します。
JNDI Password: cmee.eventframework.jndi.password
JNDIユーザー名のパスワードを指定します。
JNDI Context Factory: cmee.eventframework.jndi.context.factory
JNDI初期コンテキスト・ファクトリを指定します。たとえば、weblogic.jndi.WLInitialContextFactoryなどです。
|
注意: JNDIプロパティはデフォルトでは表示されません。これらのプロパティを有効にするには、「システム設定の有効化」ボックスに各プロパティ名を入力し、「有効化」をクリックします。 |
eventing.propertiesファイルで、次のJMSプロパティを構成します。
JMS Connection Factory: cmee.eventframework.jms.connection.factory
JMSクライアントによるJMS接続の作成を可能にするためにJMS接続ファクトリを指定します。たとえば、weblogic.examples.jms.TopicConnectionFactoryなどです。
JMS Topic: cmee.eventframework.jms.topic
JMSサーバーの公開/サブスクライブの宛先タイプであるJMSトピックを指定します。たとえば、weblogic.examples.jms.TopicConnectionFactoryなどです。
|
注意: JMSプロパティはすべてデフォルトでは表示されません。これらのプロパティを有効にするには、「システム設定の有効化」ボックスに各プロパティ名を入力し、「有効化」をクリックします。 |
「保存」をクリックします。
Oracle Enterprise Repositoryを再起動して構成の変更内容を反映します。
すべてのJMSメッセージには、デフォルトで挿入され、メッセージ・コンシューマで利用できる標準のヘッダー・フィールドがあります。Message ExpirationおよびDelivery Modeヘッダーは、Oracle Enterprise Repositoryのシステム設定を使用して構成できます。
A.7.2.1項「外部JMSサーバーの有効化および構成」で説明されているように、「イベンティング」システム設定にアクセスします。
eventing.propertiesファイルで、JMSメッセージ・ヘッダーのプロパティを構成します。
JMS Message Expiration: JMSメッセージの有効期限を秒単位で設定します。設定されている場合、指定した秒数内に未処理のイベントが期限切れになります。デフォルトは0秒です。この場合、メッセージは期限切れになりません。ただし、一部の環境では、JMSメッセージがなんらかの理由によって選択されていない場合、これらのメッセージを恒久的に格納できないようにすることを要求するポリシーが設定されています。このプロパティを有効にし、プロパティ値をcmee.eventframework.jms.expirationに設定してください。
JMS Delivery Mode: JMSメッセージ配信モードをPERSISTENTまたはNON-PERSISTENT値に設定します。PERSISTENTに設定されている場合、JMSサーバーはイベントを基礎となるストアに書き込みます。イベントをストアに対して永続化すると信頼性が高くなりますが、パフォーマンスに影響する可能性があります。デフォルトはPERSISTENTです。このプロパティを有効にし、プロパティ値をcmee.eventframework.jms.deliverymodeに設定してください。
「保存」をクリックします。
Oracle Enterprise Repositoryを再起動して構成の変更内容を反映します。
|
注意: Eventingプロパティの変更後に変更を有効にするには、Oracle Enterprise Repositoryを再起動する必要があります。 |
次のその他のシステム設定を構成することもできます。
イベント・マネージャJMSサブスクライバの有効化: Falseに設定されている場合、内部JMSサブスクライバは有効になりません。この目的は、組込みJMSサーバーを起動するが、外部ツールを使用して特定の永続サブスクライバ名を使用して組込みサーバーに接続し、格納されているイベントをクリーンアップできるようにすることにあります。
JMSサブスクライバ・クライアントID: JMS永続サブスクライバIDを指定します。たとえば、ALER_JmsSubscriberなどです。プロパティ名はcmee.eventframework.jms.subscribers.client.idです。
JMSプロデューサ・クライアントID: JMSプロデューサのクライアントIDを指定します。たとえば、ALER_DeliveryManagerなどです。プロパティ名はcmee.eventframework.jms.producers.client.idです。
イベント・エンジンの遅延初期化: 有効な場合、イベントが初めて生成されるときにイベント・マネージャが初期化されます。このプロパティを有効にする必要があるのは、次のいずれかの場合です。
JMSサーバーによって多数のイベントが格納されており、Oracle Enterprise Repositoryが起動すると同時にこれらのイベントを処理しないほうがよい場合
組込みJMSサーバーを初期化するタイミングが原因で起動に関する問題が発生する場合
プロパティ名はcmee.eventframework.lazy.loadです。
デフォルトでは、ActiveMQ JMSサーバーではファイルベースのストアを使用してイベントが格納されます。ただし、イベントをデータベースに格納するよう指定することもできます。データベース・パラメータを使用するには、単純にWEB-INF\classesディレクトリ内のactivemq.xmlファイルを構成します。
次に例を示します。
<persistenceAdapter> <journaledJDBC journalLogFiles="5" dataDirectory="../activemq-data" dataSource="#oracle-ds" /> <!-- To use a different datasource, use the following syntax : --> <!-- <journaledJDBC journalLogFiles="5" dataDirectory="../activemq-data" dataSource="#postgres-ds"/> --> <!-- Oracle DataSource Sample Setup --> - <bean id="oracle-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver" /> <property name="url" value="jdbc:oracle:thin:@localhost:1521:AMQDB" /> <property name="username" value="scott" /> <property name="password" value="*****" /> <property name="poolPreparedStatements" value="true" /> </bean>
サブスクリプション・マネージャのXMLファイル内でWebサービス・エンドポイントが検出されるたびに、1つの永続サブスクライバが作成されます。これにより、エンドポイントがオンラインでない場合にイベントが格納され、エンドポイントが再度オンラインになったときにイベントを確実に配信できるようになります。JMS仕様に従い、永続サブスクライバ名はJMSサーバー全体にわたって一意である必要があります。イベント・マネージャは、永続サブスクライバ名を次の例に示すようにEndPointEventSubscription.xmlファイル内にある名前フィールドから取得します。
<sub:EventSubscriptionData
xmlns:sub="http://www.bea.com/infra/events/subscription"
<sub:eventSubscription>
<sub:endPoint name="ALBPMEndpoint">
|
注意: JMSサーバーは永続サブスクライバ名をメッセージ・セレクタに関連付けます。したがって、メッセージ・セレクタが変更される場合、新しい永続サブスクライバ名を指定するか、既存の永続サブスクライバ名を削除する必要があります。7-4ページの「格納されているイベントのクリーンアップ」で説明されているように、Oracle Enterprise Repositoryのイベント・クリーンアップ・ツールを使用できます。また、JMS固有のツールを使用してこれを行うこともできます。 |
|
注意: クラスタ環境におけるOracle Enterprise Repositoryの構成の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryインストレーション・ガイド』を参照してください。 |
Oracle Enterprise Repositoryがクラスタ・モードでデプロイされている場合、使用されているJMSサーバーのタイプ(組込みまたは外部)とは関係なく、Oracle Enterprise Repositoryインスタンスごとにクラスタリングを有効にする必要があります。
Oracle Enterprise Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。
cmee.eventframework.clustering.enabledを「新しいシステム設定の有効化」ボックスに入力し、「有効化」をクリックして、この非表示のプロパティを表示します。
「有効クラスタリング」プロパティをTrueに設定します。
次の各項で説明されているように、JMSサーバーのタイプに基づいて他の必要なプロパティを設定します。
クラスタ環境では、クラスタ内のOracle Enterprise Repositoryのメンバー・インスタンスごとに1つの組込みJMSサーバーが設定されます。たとえば、2ノード・クラスタの場合、server01やserver02などのOracle Enterprise Repositoryインスタンスが2つ存在し、それぞれに1つの組込みJMSサーバーがあります。組込みJMSサーバーに対してクラスタリングが有効になったら、server01およびserver02上の組込みJMSサーバーに対して接続URL情報を指定する必要があります。
Oracle Enterprise Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。
cmee.eventframework.embedded.jms.urlを「新しいシステム設定の有効化」ボックスに入力し、「有効化」をクリックして、この非表示のプロパティを表示します。
「組込みJMSサーバーURL」プロパティで、次の形式を使用して、クラスタリングされたOracle Enterprise Repositoryサーバー上の組込みJMSサーバーの接続URLを指定します。
failover:(tcp:// $SERVER_DNS_NAME_OR_IP$:61700,tcp://$SERVER_DNS_NAME_OR_IP$:61700, …)
意味は次のとおりです。
$SERVER_DNS_NAME_OR_IP$は、実際のサーバーのDNS名またはIPアドレスによって置き換えられます。これらの入力は、指定したクラスタ内のOracle Enterprise Repositoryサーバーごとに繰り返す必要があります。
前述の例を使用して、これは、failover:(tcp://server01:61700,tcp://server02:61700)のように設定できます。
|
注意: ポート61700は組込みJMSサーバーのデフォルトのポートであるため、組込みJMSサーバーに別のポートが構成されていないかぎり、Oracle Enterprise Repositoryサーバー上の他のアプリケーションによって使用されないようにする必要があります。 |
「保存」をクリックします。
指定したクラスタ内のOracle Enterprise Repositoryインスタンスごとに手順1-4を繰り返します。前述の例を使用して、組込みブローカのURLは、failover:(tcp://server01:61700,tcp://server02:61700)のように設定できます。
|
ヒント: cmee.eventframework.embedded.jms.enabledプロパティを |
Oracle Enterprise RepositoryがWebSphere Application Server 6.1.0.5にデプロイされている場合、組込みApache ActiveMQ JMSサーバーは使用できません。したがって、WebSphere 6.1.0.5実装では、WebSphere 6.1.0.5に用意されているデフォルトのJMSプロバイダを使用する必要があります。
WebSphere 6.1.0.5でOracle Enterprise Repository用のJMSプロバイダを構成するには、WebSphere管理コンソールとOracle Enterprise Repositoryアプリケーションで次の手順をすべて実行します。
新しいサービス統合バスを作成します。
ナビゲーション・ペインで、「Service Integration」を展開し、「Buses」をクリックします。
「Buses」ページで、「New」をクリックします。
「Create a new bus」ページで、新しいバスの名前として「alerbus」を入力します。
「Bus security」オプションの選択を解除します。
「次へ」をクリックして、「完了」をクリックします。
新たに作成されたalerbusにバス・メンバーを追加します。
「Buses」ページで、「alerbus」リンクをクリックします。
「Topology」カテゴリの下で、「Bus members」をクリックします。
「Bus members」ページで、「Add」をクリックします。
「Add a new bus member > Select Server, Cluster or WebSphere MQ server」ページで、デフォルトの「Server」オプションをそのまま使用して、「Next」をクリックします。
「Add a new bus member > Select the type of message store」ページで、デフォルトの「File store」オプションをそのまま使用して、「Next」をクリックします。
「Add a new bus member > Provide the message store properties」ページで、デフォルト値をそのまま使用して、「Next」をクリックします。
「Add a new bus member > Confirmation」ページで、「Finish」をクリックします。
「Buses」ページで、「Save」をクリックします。
デフォルトのメッセージ・プロバイダでJMSトピック接続ファクトリを作成します。
ナビゲーション・ペインで、「JMS」を展開し、「JMS providers」をクリックします。
「Default messaging provider」オプションをクリックします。「Scope」は「Node=<nodename>, server=server1」にします。
「JMS providers > Default messaging provider」ページで、「Additional Properties」の下にある「Topic connection factories」オプションをクリックします。
「JMS providers > Default messaging provider > Topic connection factories」ページで、「New」をクリックします。
「Administration」ページで、次のようにトピック接続ファクトリを構成します。
*) Name: alerEventingTopicCFDefault
*) JNDI name: jms.alerEventingTopicCFDefault
*) Bus name: alerbus
*) Client identifier: ALER_JmsProducer
*) Durable subscription home: <nodename>.server1-alerbus
「Apply」をクリックし、「Save」をクリックします。
デフォルトのメッセージ・プロバイダでJMSトピックを作成します。
「JMS providers > Default messaging provider」ページにもう一度移動します。
「Additional Properties」の下にある「Topics」オプションをクリックします。
「JMS providers > Default messaging provider > Topic」ページで、「New」をクリックします。
「Administration」ページで、次のようにトピックを構成します。
*) Name: alerEventingTopicCFDefault
*) JNDI name: jms.alerEventingTopicCFDefault
*) Topic name: alerEventingTopicDefault
*) Bus name: alerbus
*) Topic space: Default.Topic.Space
「Apply」をクリックし、「Save」をクリックして変更を保存します。
次のように、aler.earアプリケーション・ファイルをデプロイします。
ナビゲーション・ペインで、「Applications」を展開し、「Enterprise Applications」をクリックします。
「Enterprise Applications」ページで、「Install」をクリックします。
「Preparing for the application install」ページで、「Browse」をクリックし、aler.earファイルをパスに指定して、「Next」をクリックします。
「Select installation options」ページで、「Next」をクリックします。
「Map modules to servers」ページで、「Next」をクリックします。
「Map resources to resource references」ページで、「Target Resource JNDI Name」列の「Browse」をクリックします。
「Enterprise application > Available resources」ページで、「alerEventingTopicCFDefault」を選択し、「Apply」をクリックします。
「ensuing Map resources to resource references」ページで、「Next」をクリックします。
「Map resource environment entry references to resources」ページで、「Target Resource JNDI Name」に「jms/aler/alerEventingTopicDefault」と入力し、「Next」をクリックします。
「Summary」ページで「Finish」をクリックします。
アプリケーションがインストールされたら、「Save」をクリックし、アプリケーションをマスター構成に保存します。
『Oracle Fusion Middleware Oracle Enterprise Repositoryインストレーション・ガイド』のOracle Business Process Managementプロセス・エンジンおよび自動ワークフローの手動インストールの手順に関する項に従い、web-inf/classesディレクトリにある追加のファイルとOracle Enterprise Repositoryアプリケーションで必要なデータベース・ドライバをデプロイします。
WebSphere設定用のOracle Enterprise Repositoryのeventing.propertiesファイルを構成します。
<OER Domain>\WEB-INF\classesディレクトリに移動します。
テキスト・エディタを使用して、次のようにeventing.propertiesファイルを変更します。
cmee.eventframework.jms.topic=jms.alerEventingTopicDefault cmee.eventframework.jndi.provider.url=iiop\://localhost:2809 cmee.eventframework.embedded.jms.enabled=false cmee.eventframework.jndi.context.factory=com.ibm.websphere.naming.WsnIniti alContextFactory cmee.eventframework.jms.connection.factory=jms.alerEventingTopicCFDefault
ファイルを保存します。
WebSphereアプリケーション・サーバーを再起動して、変更した設定を有効にします。
WebSphereログの\WebSphere\AppServer\profiles\AppSrv01\logs\server1で、可能性があるエラーについて確認します。
この項では、Oracle Enterprise Repositoryでイベントをモニターおよび管理する手順について説明します。
この項には次のトピックが含まれます:
この項では、Oracle Enterprise Repositoryの一部として用意されている管理ツールについて説明します。拡張登録フロー管理ツールを使用して、次を行います。
コマンド行インタフェースを使用したイベントのモニター
イベントのクリーンアップおよびJMS永続サブスクライバのサブスクライブ解除
ワークフロー構成ファイルの生成
最新のワークフロー構成ファイルを使用したOracle Business Process Managementエンジンのリフレッシュ
ワークフロー構成ファイルおよびサブスクリプション・マネージャ・ファイルに格納されているパスワードの暗号化
管理ツールは、次のディレクトリにインストールされます。
<ORACLE_HOME>/repositoryXXX/core/workflow-tools
イベント・マネージャには、イベント・マネージャによって生成されたイベントをモニタリングするためのツールが用意されています。このツールは、イベント・トラフィックを監視し、この項に示すイベント本体やイベント・プロパティなどの情報を出力します。
モニタリング・ツールを起動する前に、次の前提条件を満たす必要があります。
デフォルトの組込みJMSサーバーを使用する場合、cmee.eventframework.enabledシステム設定がtrueに設定された状態でOracle Enterprise Repositoryを実行する必要があります。これにより、Oracle Enterprise Repository内に組み込まれたJMSブローカが実行され、モニタリング・ツールがJMSブローカに接続してイベントをモニターできるようにします。
外部JMSサーバーが使用される場合、外部JMSサーバーが実行されている必要があり、外部JMSサーバーに接続するために必要なJNDI関連のeventing.propertiesが構成されている必要があります。
詳細は、A.7.2項「外部JMSサーバー用の接続プロパティの構成」を参照してください。
次のように、コマンド・プロンプトからイベント・モニタリング・ツールを実行します。
> event_monitor.bat <Path of WEB-INF\classes>
たとえば、Oracle Enterprise Repositoryが、D:\bea816\user_projects\domains\oerdomainの下にあるoerdomainという名前のドメインにデプロイされているとします。
この場合、<Path of WEB-INF\classes>は次のようになります。
<Oracle_HOME>\user_projects\applications\base_domain\applications\oer_11.1.1.4.0\oer-app\WEB-INF\classes
Oracle_HOMEは、OER_HOMEインストールの場所を表します。
このパスは、このツールがJMSサーバーに接続できるようeventing.propertiesファイルからJMS構成を取得するために必要です。
場合によっては、イベント・エンジンによって格納されたすべてのイベントを削除し、永続サブスクリプションのサブスクライブ解除も必要になります。これを行うには、イベント・クリーンアップ・ツールを使用します。
このツールを起動する前に、次の前提条件を満たす必要があります。
Oracle Enterprise Repositoryのcmee.eventframework.jms.subscribers.enabledシステム設定をfalseに設定し、Oracle Enterprise Repositoryイベント・マネージャが永続サブスクライバを起動しないようにします。理由は、これは、イベント・クリーンアップ・ツールによってサブスクライブ解除されるからです。
cmee.eventframework.jms.subscribers.enabledプロパティがfalseに設定された状態でOracle Enterprise Repositoryを再起動します。
次のように、コマンド・プロンプトからイベント・クリーンアップ・ツールを実行します。
> event_clean.bat <Path of WEB-INF\classes> <Name of Durable Subscriber> <Message Selector>
たとえば、Oracle Enterprise Repositoryが、D:\bea816\user_projects\domains\oerdomainの下にあるoerdomainという名前のドメインにデプロイされているとします。
この場合、<Path of WEB-INF\classes>は次のようになります。
<Oracle_HOME>\user_projects\applications\base_domain\applications\oer_11.1.1.4.0\oer-app\WEB-INF\classes
このパスは、このツールがJMSサーバーに接続できるようeventing.propertiesからJMS構成を取得するために必要です。
<Name of Durable Subscriber>は、次のように、EndPointEventSubscription.xml内のイベントのクリーンアップが必要なエンドポイント内の名前属性にあります。
<sub:eventSubscription> <!--The name should be unique within this file since <sub:endPoint name="ALBPMEndpoint">
<Message Selector>は、EndPointEventSubscription.xmlファイル内のクリーンアップが必要なエンドポイント内の式属性にあります。
|
注意: メッセージ・セレクタが設定されていないか空である場合、このパラメータは省略できます。 |
前述の例を使用して、workflow-toolsディレクトリに移動します。
> cd D:\bea816\repositoryXXX\core\workflow-tools>
コマンド・プロンプトで、次を入力します。
> event_clean.bat <ORACLE_HOME>\user_projects\applications\base_domain\applications\oer_11.1.1.4.0\oer-app\WEB-INF\classes ALBPMEndpoint
イベント・クリーンアップ・ツールによってコンソールに表示される出力は、次のとおりです。
ワークフロー構成の生成ツールを使用して、Oracle Enterprise Repositoryに接続してワークフロー構成ファイル(workflow.xml)を生成します。このツールにより、アセット・タイプやカテゴリ分けなどをOracle Enterprise Repositoryから読み取り、これらのエンティティの構成をworkflow.xmlに移入します。これにより、要件に応じてワークフロー構成ファイルをカスタマイズできるようになります。たとえば、フローを構成およびカスタマイズして新しいアセット・タイプ、プロジェクト、カテゴリ分けなどの追加が必要になる場合があります。
自動ワークフローの構成の詳細は、A.6項「自動ワークフローの構成」を参照してください。
次のように、コマンド・プロンプトからワークフロー構成の生成ツールを実行します。
> config_gen.bat URI User Password ConfigDir
意味は次のとおりです。
URI = OER URI (例: http://localhost:7001/alerbuild/services/FlashlineRegistry)
User = OERユーザー名
Password = OERパスワード
ConfigDir = 構成XMLファイルが作成されたディレクトリ。このファイルが存在する場合は、名前がworkflow.xml.bakに変更されます。
workflow.xmlファイルは次のディレクトリに生成する必要があります。
<OBPM Enterprise Home>/server/<OER Workflows Project>/workflow.xml
ワークフロー構成XMLのリフレッシュ・ツールを使用すると、Oracle Business Process Managementエンジンを再起動せずにワークフロー構成ファイルをリフレッシュできます。たとえば、ワークフロー構成XMLファイルが開発中に更新された場合、このツールを実行すると、Oracle Business Process Managementエンジンを再起動しなくてもエンジンで更新バージョンを使用できるようになります。
|
注意: このツールの実行時には、Oracle Business Process Managementエンジンが実行されている必要があります。 |
次のように、コマンド・プロンプトからワークフロー構成のリフレッシュ・ツールを実行します。
> refresh_workflows.bat URI User Password
意味は次のとおりです。
URI = Oracle Business Process ManagementのURI (たとえば、http://localhost:9000/albpmServices/aler_engine/ws/RefreshConfigServiceListener)
User = Oracle Business Process Managementのユーザー名(たとえば、aler_workflow_user)
Password = Oracle Business Process Managementのパスワード(たとえば、aler_workflow_pass)
|
注意: aler_workflow_userは、Oracle製品インストーラによって作成されます。これが、このツールで使用できるデフォルトのユーザーです。 |
セキュリティを高めるために、セキュリティ暗号化パスワード・ツール(runWfSecurity.bat)を使用して、ワークフロー構成ファイルおよびサブスクリプション・サービス・ファイルに格納されているパスワードを暗号化できます。
次のように、コマンド・プロンプトからセキュリティ暗号化パスワード・ツールを実行します。
> runWfSecurity.bat srcFileName destFileName
意味は次のとおりです。
srcFileName = 平文パスワードが含まれるソース構成ファイル
destFileName = 暗号化パスワードが含まれる宛先構成ファイル
この項では、Webサービス・エンドポイントのイベント・マネージャを拡張する方法について説明します。
この項には次のトピックが含まれます:
この項では、イベント・マネージャによって発行されるイベントを使用するためにWebサービス・エンドポイントを開発する方法について説明するとともに、他の通知サービス・プラグインを使用するためにイベント・マネージャを拡張する方法について説明します。イベント・マネージャの構成の詳細は、第A章「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
図A-28に、Oracle Enterprise Repositoryイベント・マネージャによって発行されたイベントを受け取るためにWebサービス・エンドポイントをプラグインする方法を示します。
新しいWebサービス・エンドポイントを作成し、イベントの取得を開始するには、次の手順を実行します。
イベント・マネージャによって定義されたWSDL契約を選択します。これは、<oer Webapp path>/WEB-INF/libディレクトリにあるmodules.eventing-11.1.1.x.x.jarファイルにバンドルされています。
jarファイルを開き、"EventListener.WSDL"という名前のWSDLを探し、このWSDLをファイル・システムに抽出します。このWSDLは、イベント・マネージャによって定義された抽象契約であり、新しいWebサービス・エンドポイントでは、WSDLに定義されている操作を実装する必要があります。
図A-29に、WSDLファイルのスナップショットを示します。
要件に応じて、ツールまたはテクノロジを使用してWebサービス・エンドポイントの開発を完了させます。たとえば、WSDLファイルを指すことによってWebサービスベースのプロキシ・サービスを作成するための機能が用意されているOracle Service Busを使用して、プロキシ・サービスを開発できます。Webサービスの開発を完了させ、Webサービスを実行できるようにします。
Webサービス・エンドポイントのホスト、ポートおよびURIなどをサブスクリプション・マネージャ・ファイルに入力できるようイベント・マネージャを構成します。イベント・マネージャの構成の詳細は、第A章「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
Oracle Enterprise Repositoryを起動し、アセット・エディタを使用してイベントをトリガーします。これにより、Webサービス・エンドポイントによるイベントの取得が開始されます。
Oracle Enterprise Repositoryにバンドルされているイベント・モニタリング・ツールを使用して、イベント・マネージャによって生成されたイベントをデバッグおよびモニタリングできます。
この項では、新しいWebサービス・エンドポイントに対して使用可能な操作や、イベント・マネージャで操作を指定する方法について説明します。
Oracle Enterprise Repositoryイベント・マネージャは、次の操作をサポートしています。
newEventRequestResponse
この操作では、XMLスキーマ・セクションに定義されているイベント・オブジェクトが入力として使用され、ステータスが出力として返されます。ステータスは文字列型として定義されます。また、ステータスの文字列の先頭がFailureの場合、例外がスローされ、成功するまでイベントの再配信が試行されます。それ以外の場合、レスポンスが記録され、トランスポートの例外が発生しないかぎり、次のイベントが配信されます。
newEventRequestResponseString
この操作では、文字列形式のイベント・データが入力として使用され、ステータスが出力として返されます。ステータスは文字列型として定義されます。また、ステータスの文字列の先頭がFailureの場合、例外がスローされ、成功するまでイベントの再配信が試行されます。それ以外の場合、レスポンスが記録され、トランスポートの例外が発生しないかぎり、次のイベントが配信されます。
newEventRequest
この操作では、XMLスキーマ・セクションに定義されているイベント・オブジェクトが入力として使用され、一方向の操作として定義されます。
newEventRequestString
この操作では、文字列形式のイベント・データが入力として使用され、一方向の操作として定義されます。
newEvent
この操作は、プロセス・エンジンがOracle Business Process Managementである場合にのみ使用する必要があります。この操作では、内部的にstartSession操作を呼び出してセッションが開始され、Oracle Business Process Managementが認証されます。また、この呼出しの後にdiscardSessionも呼び出されます。
イベント・マネージャのサブスクリプション・マネージャを次のように構成することにより、operationName要素に指定されている優先Webサービスの操作を選択できます。
<sub:EventSubscriptionData xmlns:sub="http://www.bea.com/infra/events/subscription"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<sub:eventSubscription>
<sub:endPoint name="ALBPMEndpoint">
<sub:host>localhost</sub:host>
<sub:port>9000</sub:port>
<sub:uri>albpmServices/aler_
engine/ws/StatusChangeEndpointServiceListener</sub:uri>
<sub:targetNamespace>http://www.bea.com/infra/events</sub:targetNamespace>
<sub:operationName>newEvent</sub:operationName>
<sub:protocol>HTTP</sub:protocol>
<sub:authenticationData>
<sub:basicAuthentication>
<sub:username>aler_workflow_user</sub:username>
<sub:password>*****</sub:password>
</sub:basicAuthentication>
</sub:authenticationData>
</sub:endPoint> <sub:notifierClass>com.bea.infra.event.notifier.plugin.http.DefaultHTTPEventNotifier</sub:notifierClass>
<sub:expression></sub:expression>
</sub:eventSubscription>
</sub:EventSubscriptionData>
Oracle Enterprise Repositoryイベント・マネージャには、デフォルトのSOAP/HTTP通知サービスが含まれます。追加の要件が存在する場合は、図A-30に示すように、新しいプラグインを開発してプラグインできます。
新しいプラグインがイベント・マネージャと連携して機能するようにするには、次の手順に従います。
Oracle Enterprise Repositoryイベント・マネージャにバンドルされているJavaクラスAbstractEventNotifierを拡張して、新しい通知サービス・プラグインを開発します。このクラスは、<oer Webapp path>-app/WEB-INF/libディレクトリにあるmodules-eventing-<oer.version>.jarにバンドルされています。init()およびsendNotification()メソッドをオーバーライドする必要があります。
これらのメソッドの詳細は、Javadoc (EventManagerPublicAPIdoc.zip)を参照してください。handle()メソッドは、XML Bean形式でイベント・データを渡します。これにより、イベント・データを外部Webサービスに送信できるようになります。
開発されたクラスを指すようにサブスクリプション・マネージャ・ファイルを構成します。notifierClass要素を次のように変更します。
<sub:EventSubscriptionData xmlns:sub="http://www.bea.com/infra/events/subscription"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<sub:eventSubscription>
<sub:endPoint name="ALBPMEndpoint">
<sub:host>localhost</sub:host>
<sub:port>9000</sub:port>
<sub:uri>albpmServices/aler_
engine/ws/StatusChangeEndpointServiceListener</sub:uri>
<sub:targetNamespace>http://www.bea.com/infra/events</sub:targetNamespace>
<sub:operationName>newEvent</sub:operationName>
<sub:protocol>HTTP</sub:protocol>
<sub:authenticationData>
<sub:basicAuthentication>
<sub:username>aler_workflow_user</sub:username>
<sub:password>*****</sub:password>
</sub:basicAuthentication>
</sub:authenticationData>
</sub:endPoint> <sub:notifierClass>com.bea.infra.event.notifier.plugin.http.DefaultHTTPEventNotifier</sub:notifierClass>
<sub:expression></sub:expression>
</sub:eventSubscription>
</sub:EventSubscriptionData>
JARファイルのクラスをバンドルし、<oer Webapp path>/WEB-INF/libディレクトリにコピーして、クラスパスで選択されるようにします。
イベント・マネージャを再起動し、アセット・エディタを使用してイベントをトリガーします。
新しい通知サービス・プラグインのinit()およびhandle()メソッドが呼び出されます。
Oracle Enterprise Repositoryイベント・マネージャとの互換性のないインタフェースまたは契約を持つエンドポイントが存在する可能性があります。これは、エンドポイントの開発に使用されるツールにOracle Enterprise Repositoryイベント・マネージャで提供されるWSDLの使用制限があるか、他の相互運用性の問題が存在する可能性があるためです。そのような状況では、次のアプローチを使用できます。
イベントXMLデータを受信するイベント通知サービス・プラグインを開発し、サブスクリプション・マネージャに登録します。
リモートWebサービスが想定する形式にイベント・データを変換する、新しい通知サービス・プラグインのコードを記述します。
リモート・エンドポイントでサポートされているAPIでリモートWebサービスを呼び出します。
アセット・エディタを使用して、アセットを管理し、値リスト、カテゴリ、リレーションシップ、拒否理由、アーティファクト・ストアおよびベンダーなどのアセットに関連付けられたリソースを構成します。通常、アセット・エディタはWebコンソールから起動します。
登録プロセスを経るアセットは、図A-31に示すアセット・エディタ内のファイル・ツリーに表示されているように、複数のフォルダを介して編成および管理されます。
アセットの登録プロセスは、「発行済」フォルダの下にあるレビュー保留中フォルダから開始されます。アセットは、レジストラによって受け入れられるか拒否されると、「発行済」の下にあるレビュー中フォルダに移動します。
アセット・エディタのタブにあるデータについて、レジストラによるレビューと承認を待機中の場合、そのアセットは、レビュー中から「登録済」フォルダに移動します。「検索」機能を使用して発行済、未発行および登録済アセットにアクセスするか、My Stuffを使用することで、アセットの進捗状況を追跡できます。
登録プロセスには、次のアクションが含まれます。
アセットがユーザーによって発行され、「発行済」の下のレビュー保留中フォルダに表示されます。発行キューに新しいアセットが入ったことを知らせる自動電子メール・メッセージがレジストラに送信されます。
レジストラがアセットと関連情報を検証し、受け入れを決定します。これにより、アセットは作業キューに入ります。レジストラがアセットの拒否を選択する場合もあります。
アセットを拒否する場合、レジストラは拒否の理由を入力します。
発行フォルダから拒否されたアセットは、アセット・エディタから削除され、発行者のMy Stuff内の「個人の発行」フォルダ内で拒否済としてマークされます。
アセットが受け入れられたら、処理と承認のために1人以上のレジストラに割り当てることができます。レジストラは自分に割り当てられたアセットをMy Stuffから表示できます。登録のために受け入れられたアセットはレビュー中フォルダに移動し、レジストラまたは上級発行者が登録プロセスを開始します。必要な情報が収集され、アセット・エディタの適切なタブに入力されます。レジストラは、各タブを検証し、ワークフローをモニターします。ワークフローの特定のステージの情報が受入れ可能な場合、レジストラは該当するタブのデータを承認します。承認プロセスに規定の順序はありません。レジストラは任意の順序で任意のステージを承認できます。また、レジストラは、プロセスの任意のステージの情報を編集することもできます。
レジストラは、様々なタブのそれぞれに入力された情報について、「管理」タブで組織の基準に基づいて最終的な承認を行います。任意のアセットに関するアセット・エディタのタブの特定の構成は、アセットが発行時に割り当てられるタイプ・テンプレートによって決まります。各タブには、アセットを記述、およびアセットの使用を容易にするために使用されるメタデータの様々な要素があります。
この項には次のトピックが含まれます:
Oracle Enterprise Repositoryには、登録プロセスの理解に定義されている、登録プロセスとガバナンス・プロセスを自動化しようとする、事前に構築されたBPMアセット登録フローがバンドルされています。使い勝手を向上させるために、事前定義されたOBPMエンドポイントを使用するか、独自のWebサービス・エンドポイントを作成してOracle Enterprise Repositoryイベントをサブスクライブすることができます。OBPMデザイナを使用して、新しいガバナンス・ワークフローを作成できます。また、トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールも用意されています。
自動ワークフロー機能の使用の詳細は、A.6項「自動ワークフローの構成」を参照してください。
この手順は、アセット・エディタで実行されます。(適切な権限が必要です。)
「発行済」フォルダを開きます。
レビュー保留中を開きます。
図A-32に示すように、登録するアセットを選択します。
オプション:
「受入れ」をクリックします。アセットがツリー内の「レビュー中」フォルダに移動し、アセットの下にある各ワークフロー・フォルダにも表示されます。ワークフロー・フォルダは、アセット・エディタのタブに相当します。
「受入れおよび割当て」をクリックします。図A-33に示すように、「ユーザーの割当て」ダイアログが表示されます。
「<<」および「>>」ボタンを使用して、「使用可能なユーザー」列と「選択したユーザー」列の間で項目を移動します。
「OK」をクリックします。
アセットがツリー内のレビュー中フォルダに移動し、選択したユーザーに割り当てられます。このユーザーが、アセット・エディタの各タブに必要な情報を入力します。割り当てられたユーザーは、このアセットに割り当てられたことを通知する電子メールを受信することもできます。
いくつかのタブはすべてのアセット・タイプに共通ですが、任意のアセットに関するアセット・エディタの特定のタブは、アセットが発行時に割り当てられるタイプ・テンプレートの構成によって決まります。
「概要」タブをクリックします。図A-34に示すように、「概要」タブが表示されます。
各フィールドに適切な情報を入力します。
図A-35に示すように、「承認」をクリックします。
「概要」タブのテキストの色が変更され、「承認」ボタンは「非承認」に変わります。
|
注意: アセット・エディタの「承認」ボタンは、適切な権限を持つユーザーにのみ表示されます。 |
「分類」タブをクリックします。図A-36に示すように、分類タブが表示されます。
いくつかのカテゴリが表示されます。
「分類」セクションの「割当て」ボタンをクリックします。「分類の割当て」ダイアログが表示されます。
オプションを使用して、適切な分類を選択します。
承認済
プロジェクトでの使用がレジストラによって承認されています。
教育
学習または情報提供のみを目的とします。プロジェクトでの使用は承認されていません。
必須
アセットが提供する機能がプロジェクトに必要な場合に必ず使用します。(これは、顧客データへのアクセスや支払処理などを行うWebサービスに特に関係があります。)
Raw
品質または完全性は保証されません。
推奨
承認済、少なくとも1つのプロジェクトでデプロイに成功しています。
「OK」をクリックします。選択内容が「分類」セクションにリストされます。
|
注意: 使用環境を反映するように、デフォルトのカテゴリをカスタマイズできます。 |
分類タブの各セクションについて、このプロセスを繰り返します。
「キーワード」セクションのテキスト・ボックスに適切なキーワードを入力します。
「追加」をクリックします。図A-37に示すように、この新しいキーワードが「キーワード」リストに表示されます。
必要に応じて、他のキーワードを追加します。
分類タブが完了したら、「承認」をクリックします。
「概要」タブのテキストの色が変更され、「承認」ボタンは「非承認」に変わります。
「Documentation」タブをクリックします。図A-38に示すように、「ドキュメント」タブが表示されます。
提案される多数のドキュメント・タイトルが「ドキュメント」ウィンドウにリストされます。これらの各タイトルに、適切なドキュメントを関連付けることができます。また、新しいドキュメントをリストに追加できます。
新しいドキュメントを追加するには、次の手順を実行します。
「追加」をクリックします。図A-39に示すように、「編集」ダイアログが表示されます。
「名前」テキスト・ボックスに適切な情報を入力します。
「URL」テキスト・ボックスの横にある「編集」ボタンをクリックします。図A-40に示すように、「URLの編集」ダイアログが表示されます。
必要に応じて、アーティファクト・ストア・ファイルまたは「外部ファイル」を選択します。
使用可能なテキスト・ボックスに必要な情報をすべて入力します。
「OK」をクリックします。図A-41に示すように、この新しいドキュメントがリストに表示されます。
既存のドキュメントのファイル情報を編集するには、ドキュメントを選択し、「編集」をクリックして、手順4から7を繰り返します。
終了したら、図A-42に示すように、「承認」をクリックします。
「リレーションシップ」タブをクリックします。
「追加」ボタンをクリックします。図A-43に示すように、「リレーションシップの追加」ダイアログが表示されます。
「検索」ボタンまたは「アクティブなすべてを表示」ボタンを使用して、ダイアログの「アセット」セクションにアセットを表示します。
リストからアセットを選択します。
「リレーションシップ・タイプ」リストを使用して、2つのアセット間の適切なリレーションシップを選択します。
|
注意: 必要に応じて、リレーションシップの反転ボタンをクリックして、リレーションシップを逆にします。 |
終了したら、「OK」をクリックします。
必要に応じてこの手順を繰り返して、他のアセットのリレーションシップを追加します。
終了したら、「承認」をクリックします。
リレーションシップの構成の詳細は、Oracle Enterprise Repository管理ガイドを参照してください。
Oracle Enterprise Repositoryのすべてのアセットに「管理」タブがあります。「管理」を使用して、次のことを行います。
アセットの作成済、発行済、受入れ済のワークフローを追跡します。
他のタブの情報をレビューおよび承認するユーザーを割り当てます。
アセットのステータスを変更します。
アクティブ
非アクティブ
リタイア
削除済
アセットのノートとレビューを表示します。
図A-44に示すように、「登録」ボタンをクリックして登録プロセスを完了します。
登録されたアセットに未承認のタブが含まれる場合があります。
タブが承認されると、必ずTabApprovedEventがトリガーされます。このイベントと、タブ名およびその他特定のメタデータが、ワークフローに送られ処理されます。このイベントは、多層ワークフローによって使用されます。この場合、承認されたタブと構成に応じて、承認プロセスの次の層を割り当てる必要があるかどうかがワークフローによって決定されます。
また、ユーザーは、TabApprovedEventイベントを、ChangeAssetLifecycleなどの事前定義済ワークフローにワイヤリングできます。そのため、これはタブ名にも関連付けられます。
いくつかのタブはすべてのアセット・タイプに共通ですが、任意のアセットに関するアセット・エディタの特定のタブは、アセットが発行時に割り当てられるタイプ・テンプレートの構成によって決まります。同様に、タブに表示されるメタデータ要素も、タイプ構成によって決まります。特定のタブと要素はタイプによって異なる場合がありますが、どのタブの承認プロセスも、各要素の情報の入力たはレビュー(あるいはその両方)が必要です。タブの「承認」をクリックするたびに、変更の保存を確認するメッセージが表示されます。
「Oracle Enterprise Repository」画面で、My Stuffリンクをクリックします。My Stuffセクションが表示されます。
割当済アセットを選択し、タブを承認するアセットを選択します。
ページの右下のペインの「編集」ボタンをクリックします。アセット・エディタ・ダイアログが表示されます。
承認するタブを選択します。
そのタブの情報を確認します。
「承認」ボタンをクリックします。変更の保存を促すプロンプトが表示されます。
「オプションの選択」ダイアログの「OK」をクリックします。
割当済アセット・ページに戻り、リフレッシュして変更内容を確認します。図A-46に示すように、タブ承認ステータス・ペインで、「承認」に1つの項目が表示されます。
アセットが更新されると、ユーザー、日付およびアクションのレコードが監査ログに表示されます。ログに記録される変更は、次のとおりです。
アセットの作成
アセットの更新
アセットの登録ステータスの変更
アセットのアクティブ・ステータスの変更
承認タブの完了
アセットの「管理」タブにある「ログ」セクションのリストにログ・エントリが追加されます。(「ログ」セクションの「リフレッシュ」ボタンのクリックが必要になる場合があります。)
|
注意: カスタム・データ・フィールドに変更が加えられると、フィールドが変更されたことを示すログが作成されます。ただし、その変更の具体的な詳細は空です。 |
ノートのアセットへの追加
「ファイル」メニューの「ノートの追加」をクリックします。図A-47に示すように、「...のノートの追加」ダイアログが表示されます。
テキスト・ボックスに適切な情報を入力します。
「OK」をクリックします。アセットの「管理」タブにある「ログ」セクションのリストにノートが追加されます。(「ログ」セクションの「リフレッシュ」ボタンのクリックが必要になる場合があります。)
この項では、Oracle Business Process Managementプロセス・エンジンと連携して動作するよう構成されてバンドルされたOracle Business Process Management Webサービス・エンドポイントを使用した拡張登録フロー機能の使用を素早く開始する方法について説明します。ただし、この機能は拡張性が高く、環境に合うように調整できます。
イベント・マネージャはOracle Enterprise Repositoryに埋込みのコンポーネントであり、イベント・サブスクリプション、イベント永続性、イベントのフィルタ処理、およびイベント配信を管理します。Webサービス・エンドポイントはイベント・マネージャのサブスクリプション・マネージャをサブスクライブでき、Oracle Enterprise Repository内で生成されたイベントはWebサービス・エンドポイントに配信されます。
図A-48に、関連する様々なコンポーネントを示します。
イベント・マネージャは、デフォルトで有効になっているApache ActiveMQ JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。ただし、Weblogic Server JMSやIBM MQSeriesなどのJavaベースの外部メッセージ・ブローカを使用するようにイベント・マネージャを構成することもできます。
イベント・マネージャの構成の詳細は、A.4項「Oracle Enterprise Repositoryイベント・マネージャの構成」を参照してください。
この項では、Oracle Enterprise Repositoryイベント・マネージャの構成のユースケースについて説明します。
Oracle Enterprise Repositoryには、事前にバンドルされたOracle Business Process Managementフローと、デフォルトでイベント・マネージャのサブスクリプション・マネージャに登録されるWebサービス・エンドポイントが用意されています。トリガーされたすべてのイベントはこのOracle Business Process Managementエンドポイントに配信されます。エンドポイントでは、Oracle Enterprise Repositoryプロセス(アセット登録プロセス、メタデータ変更の追跡、事前に定義されたアクションの実行など)の自動化が試行されます。
また、独自のWebサービス・エンドポイントを記述してイベント・マネージャでサブスクライブし、イベントを固有のビジネス上のニーズに対応させることもできます。
Oracle Enterprise Repositoryのインストール時には、Oracle Business Process Managementのインストールと構成を求められます。この項では、Oracle Business Process Managementが正常にインストールされていることを前提としています。
イベント・マネージャでイベントを送信できるようになったら、Oracle Business Process Managementプロセス・エンジンを構成してイベントを処理できるようにする必要があります。Oracle Enterprise Repositoryをインストールすると、プロセス・エンジンをインストールして構成するためのオプションが使用可能になります。この項では、次の手順を実行する前にプロセス・エンジンが正常にインストールされていることを前提としています。
Oracle Business Process Management管理センターを起動するには、<OBPM Enterprise Home>\binディレクトリ内のobpmadmcenter.exeファイルをダブルクリックします。
Oracle Enterprise Repositoryには、プロセス・エンジンにデプロイされる、事前にバンドルされた自動ワークフローが用意されています。Oracle Enterprise Repository内でトリガーされたイベントは、プロセス・エンジンに配信され、Oracle Enterprise Repositoryプロセス(アセットの発行、受入れ、登録、その他の管理プロセスなど)の自動化を試行する自動ワークフローを実行します。
使用可能な自動ワークフローの詳細は、A.6項「自動ワークフローの構成」を参照してください。
Oracle Business Process Managementプロセス・エンジンがインストールされたら、次の手順に従います。
ワークフロー構成の生成ツール(config_gen.bat)を使用して、ワークフロー構成ファイル(workflow.xml)を生成します。このツールにより、Oracle Enterprise Repositoryに接続し、カスタマイズ可能なブートストラップ・ファイルを作成します。workflow.xmlファイルの生成の詳細は、A.8.4項「ワークフローの構成」を参照してください。
ワークフロー構成ファイル(workflow.xml)を暗号化します。詳細は、第5章「ワークフロー構成ファイル」を参照してください。
新しく生成されたworkflow.xmlファイルを<OBPM Enterprise Edition>/enterprise/server/aler_engineディレクトリにコピーします。
任意のXMLエディタを使用してworkflow.xmlファイルを開きます。
Oracle Enterprise Repository接続情報(URIやレジストラのユーザー名およびパスワードなど)が次に示すように正しく構成されていることを確認します。
<alerconnection>
<uri>http://server01.amer.bea.com:7005/aler/services/FlashlineRegistry </uri>
<registrar>
<user>admin</user>
<password>*****</password>
</registrar>
</alerconnection>
URIには次の形式を使用する必要があります。
http://<host>:<port>/<oer web app name>/services/FlashlineRegistry
workflow.xmlファイル内で、次に示すように、アセット・タイプが「Service」であるassetTypeの設定を探します。
<assetType name="Service" community="_CHANGE_COMMUNITY_" id="154">
<allTabs>
<allTabs>
<tab name="Oveview"/>
<tab name="UDDI: Business Entity"/>
<tab name="Taxonomy"/>
<tab name="Architecture"/>
</allTabs>
次に示すように、autoAccept属性を追加し、値をtrueに設定します。
<assetType name="Application" community="_CHANGE_COMMUNITY_" id="154"
autoAccept="true">
<allTabs>
<allTabs>
<tab name="Oveview"/>
<tab name="UDDI: Business Entity"/>
<tab name="Taxonomy"/>
<tab name="Architecture"/>
</allTabs>
これで、タイプが「Service」であるアセットを自動的に受け入れるようにOracle Business Process Managementプロセス・エンジンが構成されました。
Oracle Business Process Managementプロセス・エンジンが実行されている場合は、これを停止して再起動し、workflow.xmlの最新の変更をロードします。
ワークフロー構成のリフレッシュ・ツールを使用すると、Oracle Business Process Managementプロセス・エンジンを再起動せずにworkflow.xmlファイルをリフレッシュできます。workflow.xmlファイルのリフレッシュの詳細は、A.8.4.1項「ワークフロー構成ファイルのリフレッシュ」を参照してください。
Oracle Business Process Managementプロセス・エンジンを構成して実行したら、次の手順に従ってアセット発行イベントを処理します。
WebコンソールからOracle Enterprise Repositoryのアセット・エディタを起動します。
Oracle Enterprise Repositoryのアセット・エディタの使用の詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』を参照してください。
図A-31に示すように、「ファイル」→「新規」から新しいアセットを作成します。
|
注意: アセット・タイプは「サービス」にする必要があります。 |
「OK」をクリックし、アセットを発行します。
アセットが発行されたら、Oracle Business Process Managementログ・ビューアに切り替えて、イベントが処理されたことを確認します。ログ・ビューアを起動するには、<OBPM Enterprise Home>\binディレクトリ内のobpmlogviewer.exeファイルをダブルクリックします。
図A-49に示すように、プロセス・アドミニストレータのプリファレンス設定を使用して、プロセス・エンジンの「ログ」ページで「デバッグ」レベルをオンにします。デフォルトでは、このレベルは「警告」に設定されています。
図A-49 Oracle Business Process Managementプロセス・アドミニストレータ - ロギング・プリファレンス
デバッグ・レベルをオンにすると、Oracle Enterprise Repository自動ワークフローに関する情報のみでなく、他のプロセス・エンジン情報も含む多くの情報が出力されることがわかります。Oracle Enterprise Repositoryのロギングをフィルタ処理するには、図A-50に示すように、次の手順に従います。
ログ・ビューアで、一番左側にあるリスト・ボックス内の「メッセージ」を選択します。
横のリスト・ボックスで「次で始まる」を選択します。
テキスト・ボックスに「OER」と入力します。
「フィルタの適用」ボタンをクリックします。
図A-50 Oracle Business Process Managementログ・ビューア
ログ・ビューアに「OER: アセットの受入れが完了しました」というメッセージが表示されたら、アセット・エディタに戻り、「表示」→「ツリーのリフレッシュ」コマンドを使用して「管理」タブをリフレッシュします。
図A-51に示すように、「承認」セクションが最新のデータで更新されていることを確認します。
図A-51 Oracle Enterprise Repositoryのアセット・エディタ - 「管理」タブ
また、図A-52に示すように、「管理」タブの監査ログが更新されていることも確認します。
図A-52 Oracle Enterprise Repositoryのアセット・エディタ - 監査ログ
コミュニティ・フローは、自動割当てルールの構成を可能にすることによってアセットの受入れ、割当て、登録プロセスを自動化する方法を提供するとともに、様々な機関の間のフェデレーテッド・レジストラに関する概念を示します。すべてのコミュニティにわたって(システム・レジストラ通知を介して)多数のレジストラを送信するかわりに、システム・レジストラの数を1人または2、3人の個人に制限し、コミュニティの管理レジストラのかわりに自動受入れフローでアセットを受け入れるようにすることができます。コミュニティ・フロー機能により、コミュニティのためにアセット発行を承認する権限を持つ個人にアセット発行を分散できます。
たとえば、2つのコミュニティを追加し、各コミュニティについて2つの異なるレジストラを構成できます。次に、作成するプロジェクトまたはアセット・タイプに応じて、特定のアセットをコミュニティに関連付けることができます。コミュニティ・フローでは、レジストラによる手動受入れと同じ方法で、このようなアセットを自動的に受け入れます。
