Repositoryのアセットを管理する方法について説明します。この章には、次のセクションがあります。再使用に適していると確認されたアセットは、リポジトリに発行されます。発行されたアセットはレジストラによってレビューされ、登録プロセスを進めるアセットが決定されます。図A-1に示すように、レジストラによって受け入れられたアセットは登録ワーク・キューに入ります。Stuffページの「個人の発行」フォルダを使用して、登録に向けたアセットの進捗状況を追跡できます。発行者は、拒否されたアセットおよび拒否の理由(たとえば、重複したアセット)に関する通知を受信します。BPM)およびOERプロセスにより、ビジネスが推進されます。注文の実行、雇用決定のエスカレーション、保持するレコードの決定、または製品の価格設定方法の決定を行う場合、暗黙的または明示的にビジネス・プロセス内で行動していることになります。Managementは、ビジネス・プロセスを作成、実行および最適化するツールの完全なセットです。BPMでは、既存のIT投資が活用されます。BPMは、ライン・オブ・ビジネスの所有者用として特別にチューニングされます。Repositoryには、登録プロセスとガバナンス・プロセスを自動化するために事前に構築されたBPMアセット登録フローがバンドルされています。事前に構築されたBPMアセットの登録フローは、インストールに固有のアセット・タイプ、ライフサイクル・ステージ、カテゴリ分け、ユーザーおよび他のOER構成を使用するように構成できます。登録フローの連鎖により、即時利用可能な幅広い種類のユースケースをサポートできます。Repositoryイベントをサブスクライブすることができます。BPMデザイナを使用して、新しいガバナンス・ワークフローを作成できます。トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールも用意されています。Managementモデリングおよび実装ガイド』を参照してください。Repositoryタスクを自動化するために設計された一連の事前定義済フローが用意されています。このセクションでは、次のトピックについて説明します。ソフトウェア・コンポーネント自動ワークフローには、次のソフトウェア・コンポーネントが含まれます。Repositoryイベント・マネージャイベント・マネージャは、アセット登録イベントをWebサービス・メッセージの形式で発行します。Repositoryアセットの発行、受入れ、登録、および他のガバナンス・プロセスなどを自動化する事前定義済のフローがトリガーされます。Repositoryイベント・マネージャの構成」を参照してください。サブスクリプション・マネージャサブスクリプション・マネージャは、一致するイベントが配信されるWebサービス・エンドポイント(事前定義済のALPBMまたはユーザー定義のエンドポイント)によるイベント・サブスクリプションを管理するXMLベースの構成ファイルです。イベント・マネージャは、EndPointEventSubscription.xmlファイルを使用して、イベントを配信する必要があるエンドポイントに関する情報をロードします。Repositoryイベント・マネージャの構成」を参照してください。JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。MQSeriesなどの外部JMSサーバーを使用するようにイベント・マネージャを構成することもできます。Repository用のJMSサーバーの構成」を参照してください。Monitorイベント・マネージャによって生成されたイベントをモニターするためのツールです。Monitorは、イベント・トラフィックをモニターし、イベント本体やイベント・プロパティなどの情報を出力します。詳細は、A.8項「イベントのモニタリングおよび管理」を参照してください。Repositoryに含まれています。Repositoryとともに提供されている既存のワークフローの変更、および新しいリポジトリ集中型ワークフローの実装を行うことができます。自動ワークフローは、追加設定なしで実行することも、使用環境に合うように調整することもできます。詳細は、A.6項「自動ワークフローの構成」を参照してください。次の自動ワークフローが提供されます。自動割当てルールの構成を可能にすることによってアセットの受入れ、割当て、登録プロセスを自動化する方法を提供するとともに、様々な機関の間のフェデレーテッド・レジストラに関する概念を提供します。詳細は、A.6.4.1項「コミュニティ・フローの構成」を参照してください。コミュニティ・フローを使用したアセットの自動的な受入れおよび登録に加えて、複数のユーザー・ロールを使用したアセットの受入れおよび登録が可能です。詳細は、A.6.4.2項「自動受入れおよび自動登録フローの構成」を参照してください。層と呼ばれる複数の手順でタブ承認プロセスを構築します。アセット承認タブは層単位にグループ化できます。複数層承認フローでは、指定した承認者によってすべてのタブが承認されているかどうかを確認するために各層が追跡されます。層内の最後のタブが承認されると同時に、フロー内では、指定した承認者の次のレベルにアセットを割り当てることによって次の層が開始されます。フロー」を参照してください。状態変更またはメタデータ変更をアクションにワイヤリングできる柔軟なフレームワークを公開します。メタデータ変更フローには、事前にバンドルされた一連のアクションが用意されています。Repositoryフローの形式で開発し、プラグインできます。詳細は、A.6.6項「メタデータ変更フロー」を参照してください。様々な状態のアセットを追跡し、すべての当事者に通知します。時間ベースのエスカレーション・フローには4種類があり、各種を個別に構成できます。詳細は、A.6.7項「時間ベースのエスカレーション・フロー」を参照してください。指定した有効期限より前に期限が切れたアセットや、期限日に期限が切れたアセットを追跡し、すべての当事者に警告通知を送信します。詳細は、A.6.8項「有効期限の検証フロー」を参照してください。Registryに移動します。Utilityの起動」を参照してください。イベント管理ツールトラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールが用意されています。Administratorは、アセット登録イベントの編成をWebサービス・メッセージの形式でアクティブに管理します。Managementプロセスの管理」を参照してください。Managementログ・ビューアを使用すると、プロセス実行エンジンによって記録された情報を読み取ることができます。定義するプロジェクトごとに一連のログ・ファイルが作成されます。Studioログ・ビューアにより、ファイルが読み取られて表示されるため、エンジンの実行をモニターして追跡できます。Managementログ・ビューアの使用」を参照してください。電子メール通知テンプレート自動登録フローでは、多くの状況下で電子メール通知が自動的に送信されます。管理者は、他の電子メール・テンプレートの場合と同じ方法で電子メールの件名や本文などをカスタマイズできます。A.6.9項「電子メール通知テンプレートのカスタマイズ」を参照してください。ワークフロー構成ツール新しい構成ファイルの生成、既存のファイルのリフレッシュ、およびパスワードの暗号化を行うためのワークフロー構成ツールが用意されています。詳細は、A.8項「イベントのモニタリングおよび管理」を参照してください。Repository管理者によるフローの構成およびカスタマイズが必要になる場合がありますが、これは、新しいアセット・タイプ、プロジェクト、カテゴリ分けなどが存在するためです。Repositoryにアクセスし、カスタマイズ可能な新しいファイルを作成できます。既存の構成ファイルのリフレッシュ構成XMLのリフレッシュ・ツールを使用すると、イベント・マネージャを再起動せずに構成XMLファイルをリフレッシュできます。構成ファイルのパスワードの暗号化セキュリティ暗号化パスワード・ツールを使用すると、セキュリティ上の理由により、パスワードを暗号化できます。Repositoryには、A.10項「OERワークフローの操作」に定義されている、登録プロセスとガバナンス・プロセスを自動化するために事前に構築されたBPMアセット登録フローがバンドルされています。Repositoryイベントをサブスクライブすることができます。BPMデザイナを使用して、新しいガバナンス・ワークフローを作成できます。トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールも用意されています。BPMワークフロー・アーカイブは、OERにバンドルされており、<OER_HOME>/core/tools/solutionsにあります。BPMでOERワークフロー・エンジンを初期化することを目的としたOSおよびAntスクリプト(build.xml)とともにworkflow.xmlが含まれています。Antスクリプトは、別のファイルであるbuild.propertiesに依存しています。BPMのインストール、サーバーおよびデータベースの場所を識別します。ワークフロー関連の別のユーティリティは、<OER_HOME>/core/workflow-toolsにあります。通常、これらのツールは、OERイベント・キューのクリアや、最新のワークフロー構成を使用したOBPMのリフレッシュなどのワークフロー・メンテナンスをサポートすることを目的としています。10.3.2にインストールする方法について説明します。内容は次のとおりです。Repositoryワークフローをインストールする前に、次の要件について検討してください。10.3.2をインストールするには、次の手順を実行します。(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エンジンを起動するためのスクリプトがすべて格納されています。Repositoryワークフロー・インストーラを解凍するには、次の手順を実行します。Repositoryワークフロー・インストーラを検索します。BPMがインストールされているサーバー上でzipファイルを/Oracle/Middleware/obpmディレクトリに解凍します。このzipファイルから、OBPM_SetupScriptsとworkflowの2つのディレクトリが作成されます。build.txtファイルも作成されます。build.propertiesファイルの構成ORACLE_HOME\obpm\OBPM_SetupScripts\build.propertiesファイルに正しい値を入力します。表A-1に、build.propertiesファイルにリストされているプロパティと、各プロパティの説明および例を示します。build.propertiesファイルでは、@は、置き換える必要がある値を示します。各スクリプトでは、このプロパティ・ファイルの値が使用されます。注意:パス要素を区切るには、プラットフォームに関係なくフォワード・スラッシュ文字を使用します。RepositoryワークフローをホストするDBAユーザー・アカウントをbuild.propertiesファイルのfuego.fdi.db.admin.id設定で指定する必要があります。このDBAユーザー・アカウントは、Antタスクによってデータベース内に作成される新しいユーザーです。build.propertiesファイルのプロパティ値プロパティ説明bea.homeこのプロパティは、Oracleホーム・ディレクトリの場所を指定します。RepositoryインストールのURIを指定します。URIの一部としてservices/FlashlineRegistryが存在する必要があります。BPMインストールの場所を指定します。BPMプロジェクトの場所を指定します。BPMインストールの場所を採用した場合、次の値は変更されません。{basedir}は、build.propertiesファイル内のfuego.basedirパラメータの値を参照しています。fuego.fdi.idこれは、Fuegoディレクトリ・プロパティ(FDI)です。build.propertiesファイルで示される値を変更しないでください。fuego.fdi.id=aler_fdifuego.fdi.organizationこれは、Fuegoディレクトリ・プロパティ(FDI)です。build.propertiesファイルで示される値を変更しないでください。BPMインストールの新しい管理ユーザーを作成します。Webコンソール・アプリケーションにアクセスするために使用されます。BPMインストールの新しい管理パスワードを定義します。管理ユーザー名およびパスワードは同じものにしないでください。(ディレクトリ)データベースをインストールするマシンを指定します。FDIデータベース・ポートを指定します。FDIデータベースのデータベース管理ユーザーを指定します。インストーラでは、このプロパティを使用してFDIスキーマがインストールされます(次を参照)。FDIデータベースのデータベース・ユーザーのパスワードを指定します。FDIデータベースのデータベース・タイプを指定します。FDIデータベースのSIDを指定します。このプロパティは、Oracleデータベース・タイプに対してのみ適用されます。FDIスキーマのデータベース・ユーザー名を指定します。BPMによって使用される、Oracleデータベース・タイプに固有のプロパティです。新しいユーザー・データベース・アカウントが作成されます。FDIスキーマのデータベース・パスワードを指定する、Oracleデータベース・タイプに固有のプロパティです。fuego.server.db.hostこれら4つのプロパティは、データベースのFuegoエンジン・プロパティを定義します。BPMプロセス・エンジン・データベースをインストールするシステムを指定します。BPMプロセス・エンジン・データベースのポートを指定します。BPMプロセス・エンジン・データベースのデータベース管理ユーザーを指定します。インストーラでは、このプロパティを使用してFDIスキーマがインストールされます(次を参照)。BPMプロセス・エンジン・データベースのデータベース・ユーザーのパスワードを指定します。BPMプロセス・エンジン・データベースのデータベース・タイプを指定します。BPMプロセス・エンジン・データベースのSIDを指定します。このプロパティは、Oracleデータベース・タイプに対してのみ適用されます。XEfuego.fdi.db.user.idmssqlserverおよびdb2データベース・タイプに対してのみ適用できます。FDIスキーマのデータベース・ユーザー名を指定します。BPMによって使用されます。fuego.fdi.db.user.passwordmssqlserverおよびdb2データベース・タイプに対してのみ適用できます。FDIスキーマのデータベース・パスワードを指定します。fuego.fdi.db.databasemssqlserverおよびdb2データベース・タイプに対してのみ適用できます。FDIデータベースのデータベース名を指定します。fuego.server.db.user.idmssqlserverおよびdb2データベース・タイプに対してのみ適用できます。このプロパティは、作成されるプロセス・エンジン・スキーマのデータベース・ユーザー名を指定します。BPMによって使用されます。fuego.server.db.user.passwordmssqlserverおよびdb2データベース・タイプに対してのみ適用できます。BPMプロセス・エンジン・スキーマのデータベース・パスワードを指定します。fuego.server.db.databasemssqlserverおよびdb2データベース・タイプに対してのみ適用できます。BPMプロセス・エンジン・データベースのデータベース名を指定します。BPMプロセス・エンジン・データベースのデータベース管理ユーザー名を指定します。インストーラでは、このプロパティを使用してOracleデータベースのFDIスキーマがインストールされます。BPMプロセス・エンジン・データベースのデータベース・パスワードを指定します。警告:build.propertiesファイルのバックアップ・コピーを作成してください。build.propertiesファイルは、Antスクリプトの実行後に削除されます。setenvファイルの構成ORACLE_HOME\obpm\OBPM_SetupScripts\setenv.batファイル(Windows)または/setenv.shファイル(UNIX)ファイルに正しい値を入力します。表A-2に、setenvファイルのプロパティとその説明を示します。注意:パス要素を区切るには、フォワード・スラッシュ文字(/)を使用します。ヒント:setenvスクリプトをLinuxまたはUNIX環境で実行する場合、正しいプロパティ値を使用してこのスクリプトを編集した後にこのスクリプトに対してdos2unixコマンドを実行してください。setenvファイルのプロパティ値プロパティ説明BEA_HOMEこのプロパティは、Oracleホーム・ディレクトリの場所を指定します。BPMがインストールされている親ディレクトリを指定します。BPMがインストールされている場所を指定します。BEA_HOME/obpm/enterpriseJAVA_HOMEこのプロパティは、システム上のJavaランタイムの場所を指定します。ANTインストールの場所を指定します。workflow.xmlファイルを生成し、新しいユーザー資格証明を使用して編集する必要があります。新しいアセット・タイプを作成するか、ユーザー(aleridがユーザーです)を追加する場合、workflow.xmlにこれらの変更を取得するためにワークフローを再生成する必要があります。URIも更新されます。注意:実行するには、OERが稼働している必要があります。workflow.xmlファイルは、ワークフロー構成の生成ツール(config_gen.bat)を使用して生成できます。Repositoryに接続し、カスタマイズ可能なブートストラップ・ファイルを作成します。workflow.xmlファイルはOracleによって提供されます。このファイルのバックアップ・コピーを作成してください。OERをインストールしたディレクトリに移動し、スクリプトを実行し、生成されたスクリプトをSetupscriptsフォルダにコピーします。workflow.xmlファイルを生成または再生成するには、次の手順を実行します。コマンド・プロンプトから、次のように、repository111/core/workflow-tools/にあるワークフロー構成の生成ツールを実行します。ConfigDir意味は次のとおりです。Edition>/enterprise/server/aler_engineディレクトリにコピーします。任意のXMLエディタを使用してworkflow.xmlファイルを開きます。workflow.xmlファイルの生成の詳細は、A.8.4項「ワークフローの構成」を参照してください。初回の編集では、正しいパスワードとURLをファイルに記載します。後で組織のニーズに合うようにワークフロー・ファイルを構成します。RepositoryインストールのURIと一致するよう変更します。パス参照の末尾にある/services/FlashlineRegistryは変更しません。workflow.xmlファイル内のすべてのユーザー資格証明を正しい値に変更します。JDKを1.6に更新した際に設定したものと同じJDKパスを必ず使用してください。10.3.2のインストール」を参照してください。Repositoryワークフロー構成ファイルworkflow.xmlを暗号化するには、次の手順を実行します。http://<host>:<port>/oer/diag/encryptstrings.jspに移動します。workflow.xmlファイルに対して暗号化を実行します。workflow.xmlファイルを/obpm/enterprise/server/aler_engineにコピーします。workflow.xmlファイルを暗号化するための別の方法は、5.3.3項「ワークフロー構成ファイル」を参照してください。jarを$Oracle_HOME\OBPM_SetupScripts\extディレクトリにコピーします。権限の検証OBPM_SetupScriptsおよびworkflowフォルダの権限を検証し、これらが書込み可能であることを確認してください。設定スクリプトの実行ヒント:Antスクリプトが正常に実行されたら、build.propertiesファイル内に格納されているパスワードに関するセキュリティ上の懸念により、このファイルは削除されます。これを回避することはできないため、予防策としてバックアップを作成します。Webコンソール・アプリケーションに後でログインするために記録する必要があります。setenv.shを使用している場合、このファイル内にDOS文字が存在しないようにdos2unixコマンドを実行する必要がある可能性があります。このファイル内にDOS文字が含まれる場合、問題が発生します。./setenv.shという形式で実行する必要があります。ANT_homeが設定されていることを確認してください。setenv.batまたはsetenv.shファイルを実行するには、次の手順を実行します。コマンドまたはシェル・ウィンドウを開きます。$Oracle_HOME\OBPM_SetupScriptsディレクトリに移動します。次のコマンドを実行します。./setenv.shを実行します。Antホームが設定されていることを確認してください。install-workflowを実行してOBPMワークフロー・エンジン(aler_engineという名前)を初期化します。次のコマンドを実行します。create-fdi次のコマンドを実行します。設定スクリプトが成功したことを確認するには、次の手順を実行します。Enterprise/binディレクトリで、obpmadmcenterを起動します。Centerアプリケーションを開きます。BPMアプリケーションの起動をクリックします。プロセス・アドミニストレータの起動をクリックします。Webコンソール・アプリケーションの資格証明を使用してログインします。これらの資格証明は、build.propertiesファイル内のfuego.fdi.admin.idおよびfuego.fdi.admin.passwordプロパティに指定されています。左側のメニューの「エンジン」リンクを選択します。aler_engineエンジンが、ステータス「停止中」で表示されます。エンジン・アクション列の一番左のアイコンをクリックし、エンジンを起動します。エンジンが実行されると、エンジンのステータスが「準備完了」になります。BPMサービス・エンドポイントが適切にリスニングしていることを確認します。BPMサーバーに接続します。albpmServices/oer_engine/wsリンクをクリックします。リンク先では、StatusChangeEndpointServiceListenerとRefreshConfigServiceListenerの2つのサービスがリストされています。ヒント:ワークフローのAntデプロイメント中にビルドの失敗またはエラーが表示された場合、次の手順に従います。データベースからFDIスキーマ・ユーザーを削除します(build.propertiesファイル内のfuego.fdi.db.schemaに対して指定されているとおり)。データベースからFDIエンジン・ユーザーを削除します(build.propertiesファイル内のfuego.server.db.schemaに対して指定されているとおり)。BPMアプリケーションが実行されておらず、obpmadmcenter.exeが閉じられていることを確認します。setenv.batまたはsetenv.shを実行します。create-fdiコマンドを実行します。install-workflowコマンドを実行します。BPMがインストールされているサーバーのIPアドレスまたは完全修飾ホスト名が含まれるように<sub:host>要素を変更します。Repositoryワークフローがデプロイされます。Repositoryサーバーを再起動する必要があります。BPMに配信されません。パスワードが暗号化されていない場合、<ORACLE_HOME>\user_projects\domains\<oer_domain>\eventing.logファイルに次のログ・メッセージが表示されます。サブスクリプション・データが不十分です。[<ENDPOINT_NAME>]という名前を持つエンドポイントには暗号化パスワードが必要です。Repositoryイベント・マネージャの構成この項では、自動ワークフローを使用する前に完了する必要があるイベント・マネージャの構成について説明します。Repositoryに埋込みのコンポーネントであり、イベント・サブスクリプション、イベント永続性、イベントのフィルタ処理、およびイベント配信を管理します。Repository内で生成されたアセット登録イベントはWebサービス・エンドポイントに配信されます。図A-3に、関連する様々なコンポーネントを示します。JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。WebSphereなどの外部JMSサーバーを使用するようにイベント・マネージャを構成することもできます。この項では、自動ワークフローを使用する前に完了する必要があるイベント・マネージャの構成について説明します。Repositoryイベント・マネージャの構成」を参照してください。イベント・マネージャの構成イベント・マネージャを構成するには、次の手順を実行します。Repository内で有効にする必要があります。次のいずれかを実行できます。Domain>\WEB-INF\classesディレクトリ内のeventing.propertiesファイルでcmee.eventframework.enabled=trueプロパティを有効にします。RepositoryのWebベースのコンソールのシステム設定を使用して有効にします。RepositoryおよびWebサービス・エンドポイントの全体的なパフォーマンスを制御することもできます。これらのプロパティは、イベント・マネージャによって毎秒トリガーされるイベントの数に直接影響します。テストを目的としてレスポンス速度の向上が必要になる場合は、cmee.eventframework.store.sleepのデフォルト値である7200秒をテストのための適切な値に変更する必要があります。Repositoryと同じロギング・フレームワークが使用されます。Domain>\WEB-INF\classesディレクトリにあるlog4fl.propertiesファイルに次のカテゴリを追加します。debug,eventingLog,stdoutイベント・マネージャのサブスクリプション・マネージャを使用してWebサービスのサブスクリプションを構成します。Managementプロセス・エンジンと連携して動作するよう構成されています。この場合は、デフォルト設定のまま実行できるため、この手順はスキップできます。Domain>\WEB-INF\classesディレクトリの下にあるEndPointEventSubscription.xmlファイル内の次の情報の変更が必要になる場合があります。Repository以外のホストで動作している場合。同じホストである場合、デフォルトのままにします。Webサービス・エンドポイントのポートを指定します。Managementがプロセス・エンジンとして使用されている場合、デフォルトのままにします。WebサービスのURIを指定します。Managementがプロセス・エンジンとして使用されている場合、デフォルトのままにします。Managementがプロセス・エンジンとして使用されている場合、デフォルトのままにします。path>/WEB-INF/libにあるmodules.eventing-11.1.1.x.x.jarファイル内のWSDLを参照してください。Managementがプロセス・エンジンとして使用されている場合のみ、使用されます。OBPMのデフォルトのユーザー名/パスワードは、aler_workflow_user/<encrypted_password>です。使用されるデフォルトのパスワード・テキストは、aler_workflow_passです。すべてのイベントが配信されます。Repositoryを再起動して構成の変更内容を反映します。アセット・イベントのトリガーイベント・マネージャの構成後にイベントがトリガーされることを確認するには、次の手順を実行します。Repositoryのアセット・エディタを起動します。Repositoryユーザーズ・ガイド』を参照してください。図A-4に示すように、新しいアセットを作成します。注意:アセット・タイプは「サービス」にする必要があります。「OK」をクリックし、アセットを発行します。Repositoryコンソールに切り替え、図A-5に示すように、コンソールに出力される次のロギング文を確認します。イベント・モニタリング・コンソールイベント・モニタリング・ツールを使用して、配信されるイベントのペイロードを表示できます。イベントのモニターおよび管理方法の詳細は、A.8項「イベントのモニタリングおよび管理」を参照してください。必要に応じて、HarvesterSettings.xmlファイルを構成することにより、<triggerEvent>タグをtrueまたはfalseに設定し、ハーベスタ・タスクごとにBPMワークフロー・イベンティングを有効または無効にできます。Repositoryの基本操作を構成、および特定の機能を有効または無効にします。Integrations」カテゴリの「Eventing」グループの下にあります。WebSphereなどの外部のJMSサーバーを構成するために追加の「イベンティング」プロパティも用意されています。Repository用のJMSサーバーの構成」を参照してください。Repository内で有効にする必要があります。Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。「システム設定」の「検索」ボックスに「Event」と入力し、イベント・マネージャ関連の設定をすべて表示します。「イベント・マネージャの有効化」プロパティcmee.eventframework.enabledの横にある「True」をクリックします。「保存」をクリックします。Repositoryを再起動して構成の変更内容を反映します。次の各項では、イベント・マネージャのパフォーマンスをチューニングするために使用できるオプションの"Eventing"プロパティについて説明します。Repositoryを再起動する必要があります。イベント・マネージャ通知サービス・スレッド・スリープ(秒)1つ以上のイベントをエンドポイントに発行する必要があるときにエンドポイントが使用可能でない場合、イベント・マネージャ通知サービスは、エンドポイントが使用可能になるまでイベントの配信を再試行します。cmee.eventframework.notifier.sleepプロパティは、通知サービスがイベントの配信を再試行するまで待機する時間を秒単位で構成します。Repositoryスレッドがブロックされないように、イベントをJMSサーバーにプッシュする前にメモリーに格納します。cmee.eventframework.store.sleepプロパティは、イベント・マネージャのストア・マネージャ・スレッドが、メモリーに格納されているイベントの次に使用可能なバッチをポーリングするまでスリープする時間を秒単位で指定します。デフォルトのポーリング遅延は16秒です。A.4.4.2.3イベント・マネージャ・ストア配信スリープ(秒)デフォルトでは、イベント・マネージャは、イベントをバッチ単位で配信します。cmee.eventframework.delivery.sleepプロパティは、イベント・マネージャの配信マネージャ・スレッドが、JMSサーバーから次に使用可能なイベントを選択するまでスリープする時間を秒単位で指定します。バッチ間のデフォルトの遅延は13です。RepositoryおよびWebサービス・エンドポイントの全体的なパフォーマンスを制御することもできます。これらのプロパティは、イベント・マネージャによって毎秒トリガーされるイベントの数に直接影響します。テストを目的としたレスポンス速度の向上が必要になる場合は、必要に応じて、cmee.eventframework.delivery.sleepのデフォルト値である13秒をテストのための適切な値に変更する必要があります。イベント・マネージャ配信のバッチ・サイズイベント・マネージャがイベントをバッチ単位で配信する場合、配信されるバッチ・サイズはcmee.eventframework.delivery.batch.sizeプロパティを使用して構成できます。デフォルトのバッチ・サイズは100イベントです。配信対象のイベント数が少ないことをイベント・マネージャが検出すると、使用可能なイベントを配信してから、cmee.eventframework.delivery.sleepプロパティに構成されている時間の間スリープします。サブスクリプション・マネージャの構成サブスクリプション・マネージャは、一致するイベントが配信されるWebサービス・エンドポイントによるイベント・サブスクリプションを管理します。name>\WEB-INF\classes\EndPointEventSubscription.xmlにあります。Webサービス・エンドポイントの構成イベント・マネージャは、EndPointEventSubscription.xmlファイルを使用して、イベントを配信する必要があるWebサービス・エンドポイントに関する情報をロードします。例A-2に示すように、事前定義済のALPBMエンドポイントまたはユーザー定義のWebサービス・エンドポイントのホスト、ポート、URI、ユーザーおよびパスワードを構成する必要があります。--><sub:expression></sub:expression></sub:eventSubscription></sub:EventSubscriptionData>エンドポイントは必要な数を追加でき、様々なホストまたはポート内に配置できます。イベントはロード・バランシングできます。事前定義済の拡張登録フローには、"StatusChangeEndpoint"と呼ばれる1つのエンドポイントのみが含まれます。イベントをフィルタ処理するための式の設定イベントは、式要素に入力した値に基づいてフィルタ処理できます。すべてのイベントを1つのエンドポイントに配信デフォルトの設定では、すべてのイベントが1つのエンドポイントに配信されます。Repository内でトリガーされたすべてのイベントがOOTBエンドポイントに配信されます。次のXMLスニペットは、タイプAssetSubmissionのイベントを1つのエンドポイントに配信する方法を示しています。='urn:com:bea.aler:events:type:AssetSubmission'</sub:expression>また、"OR"演算子を使用して複数のイベント・タイプをフィルタ処理することもできます。='urn:com:bea.aler:events:type:AssetAccepted'次のイベント・タイプがサポートされています。JMSメッセージ・セレクタを使用してフィルタ処理されたイベントを1つのエンドポイントに配信セレクタは、コンテンツ・ベースのルーティングを実行するためにサブスクリプションにフィルタをアタッチする手段です。92構文を使用して定義します。例A-3は、イベントをフィルタ処理するためのフィルタ式を作成するために使用できるフィールドの完全なリストです。これらのフィールドはイベント・マネージャによってJMSメッセージにプロパティとして追加されます。イベントをフィルタ処理するために、これらのフィールドにアクセスするJMSメッセージ・セレクタを作成できます。1JMSメッセージ・セレクタの詳細は、次のWebサイトを参照してください。次に、JMSメッセージ・セレクタの使用例を示します。>"などの記号は、有効なXMLコンテンツではありません。式はXMLファイルで作成され、イベント・マネージャによって解析されるため、使いにくいXML文字はXMLルールを使用して管理する必要があります。500"を使用する必要があります。Repositoryと同じロギング・フレームワークが使用されます。Domain>\WEB-INF\classesディレクトリにあるlog4fl.propertiesファイルに、例A-4に示すカテゴリを追加します。Managementプロセスの管理タスクについて説明します。概要イベント・マネージャでイベントを送信する準備が完了したら、イベントを処理するようプロセス・エンジンを構成する必要があります。Managementプロセス・エンジンをインストールおよび構成するためのオプションが使用可能になります。Managementプロセス・エンジンが正常にインストールされていることを前提としています。Management管理センターを起動する必要があります。Management管理センターを起動するには、次の手順に従います。<ORACLE_HOME>\obpm\enterprise\binディレクトリに移動し、次のファイルの1つをダブルクリックします。(UNIXコンソール・ベース)。(たとえば、http://localhost:8585/webconsole)を指定します。Webアプリケーションの起動オプションをクリックします。使用可能になったら、プロセス・アドミニストレータの起動オプションをクリックします。必要な資格証明を入力するよう求められたら、インストール・プロセス中にFDIユーザー資格証明パネルで使用したBPM管理ユーザー名およびパスワードを入力します。これらの資格証明として推奨される例では、ユーザー名およびパスワードにbpm_adminを使用します。Managementプロセス・エンジンを起動するには、次の手順に従います。Managementプロセス・アドミニストレータ・ページで、図A-7に示すように、ページの左側にある「エンジン」リンクをクリックし、aler_engineプロセス・エンジンを開きます。起動/停止ページの右側にあるエンジン・アクションの下の「起動」アイコンをクリックし、aler_engineを起動します。エンジンが完全に起動するまでに数分かかる場合があります。エンジンのステータスが「準備完了」であることを確認します。Managementプロセス・エンジンが実行されていることを確認したら、これを停止してから再起動すると、最新のworkflow.xmlの変更をロードできます。Managementプロセス・エンジンの参加者を定義する方法について説明します。Managementプロセス・アドミニストレータにログインし、プロセス・エンジンを起動/停止、および他のユーザーを作成できます。Managementプロセス・エンジンがOracleの製品インストーラによってインストールされると、拡張登録フロー・ユーザーとしてaler_workflow_userが作成されます。デフォルトでは、パスワードはaler_workflow_passとして設定されていますが、図A-8に示すように、ナビゲータで「参加者」を選択し、「拡張プロパティ」セクションで「パスワードの変更」をクリックすることにより、プロセス・アドミニストレータでパスワードを変更できます。新しい参加者を管理者のロールで登録することもできます。この新しい参加者は、イベント・マネージャのサブスクリプション・マネージャ・ファイルで構成できます。詳細は、A.4.5項「サブスクリプション・マネージャの構成」を参照してください。Managementプロセス・アドミニストレータを使用してチューニングする必要があります。拡張プロパティ「エンジン」、「<エンジン名>」、エンジン・ノード、「拡張プロパティ」ページに移動します。「拡張プロパティ」ページを示しています。データベース・ランタイム・プロパティ「エンジン」、「<エンジン名>」、「エンジン・データベース構成の編集」ページに移動します。データベース・ランタイム・ページを示しています。メモリーおよび実行スレッド・プロパティ「エンジン」、「<エンジン名>」、「実行」ページに移動します。メモリーおよびスレッド・ページを示しています。Managementスタンドアロン・プロセス・エンジンのフェイルオーバーをサポートするには、環境内でバックアップ・エンジンを構成します。このフェデレーション内のエンジンの1つがPRIMARYとしてマークされ、他のエンジンはこのプライマリ・エンジンのバックアップになります。複数のエンジンをバックアップとして機能するように構成できます。指定したプライマリに障害が発生した場合、これらのバックアップ・エンジンのいずれかがプライマリになります。障害が発生したサーバーがオンラインに戻ると、プライマリとして機能しているサーバーのバックアップとして加わります。Management管理ガイドのエンジンのフェイルオーバーの構成に関する項を参照してください。Managementログ・ビューアを使用すると、プロセス実行エンジンによって記録された情報を読み取ることができます。定義するプロジェクトごとに一連のログ・ファイルが作成されます。Studioログ・ビューアにより、ファイルが読み取られて表示されるため、エンジンの実行をモニターして追跡できます。Home>\binディレクトリ内のobpmlogviewer.exeファイルをダブルクリックします。Repositoryフローのイベント・ログ・メッセージのフィルタ処理ログ・メッセージをフィルタ処理することにより、自動ワークフローで情報メッセージ、デバッグ・メッセージおよび致命的メッセージが記録されるようにすることができます。プロセス・アドミニストレータのプリファレンス設定を使用してプロセス・エンジンの「ログ」ページで「デバッグ」レベルをオンにします。デフォルトでは、このレベルは「警告」に設定されています。「エンジン」、「<エンジン名>」、「ログ」ページに移動します。ロギング・プリファレンス・ページを示しています。Repository自動ワークフローに関する情報のみでなく、他のプロセス・エンジン情報も含む多くの情報が出力されることがわかります。Repositoryフロー関連の情報のみが表示されるようにするには、図A-13に示すように、次の手順に従います。ログ・ビューアで、一番左側にあるリスト・ボックス内の「メッセージ」を選択します。横のリスト・ボックスで「次で始まる」を選択します。テキスト・ボックスに「OER」と入力します。「フィルタの適用」ボタンをクリックします。次に示すように、記録されているすべてのイベント・メッセージに接頭辞の「ALER:」が表示されます。自動ワークフローの構成この項では、OER自動ワークフローの開始方法を示すとともに、様々な高度なユースケースにおけるワークフローの使用について説明します。Repository自動ワークフローの概要」を参照してください。Managementフローがバンドルされています。Managementプロセス・エンジンを起動する前に必要な構成について説明します。Repositoryイベント・マネージャの構成」を参照してください。Managementを使用してカスタマイズすることもできます。この項では、各フローについて詳しく説明するとともに、環境に合うようにフローを調整する方法の例も示します。この項では、拡張登録フローを構成する方法について説明します。新しいワークフローを作成するには、次の手順に従います。Managementプロセスを開きます。新しいワークフローを追加します。Managementのドキュメントを参照してください。プロジェクトをアンデプロイしてからデプロイします。A.6.3項「アセット・イベントのフローへのワイヤリング」の手順に従い、ワークフローをイベントにワイヤリングします。ワークフロー構成ファイルの作成およびカスタマイズこの項では、ワークフロー構成XMLファイルを作成およびカスタマイズする方法について説明します。Repository接続およびレジストラ情報が次のXMLデータからロードされます。レジストラ・ユーザーのパスワードの暗号化セキュリティ暗号化パスワード・ツール(runWfSecurity.bat)を使用すると、ワークフロー構成ファイルに格納されているレジストラのパスワードを暗号化できます。このツールでは、ファイルが再帰的にスキャンされ、検出されたすべてのパスワード要素が暗号化されます。詳細は、A.8.5項「パスワードの暗号化」を参照してください。アセット・イベントのフローへのワイヤリング自動ワークフローは、図A-14に示すように、アセット・イベントのトリガー時に実行される1つ以上のフローにイベントをワイヤリングできるフレキシブルなフレームワークを使用して設計されています。アセット・イベントのフローへのワイヤリング注意:イベントはすべて即時利用可能な事前定義済のフローにワイヤリングされます。ワイヤリングを変更する必要があるのは、新しいフローのカスタマイズが設計される場合のみです。この図には、すべてのイベントやアクションが含まれているわけではありません。すべてのアクションまたはイベントのリストは、A.6.6.2.1項「使用可能なメタデータ変更イベント/状態」およびA.6.6.2.2項「アクションにワイヤリング可能なフロー」を参照してください。コミュニティ・ワークフローの詳細は、A.6.4.1項「コミュニティ・フローの構成」を参照してください。アセット・イベントのフローへのワイヤリングは、ワークフロー構成ファイル内で構成します。Submitted"イベントがトリガーされたときに、ワークフロー構成ファイルに構成されているルールに基づいてアセットを自動的に受け入れるフローがトリガーされることを示しています。</state>この例の構成では、次のイベントが様々なフローにワイヤリングされています。<action>要素には、実行されたフローの名前が含まれます。Acceptフローを実行します。アセットの「accepted」イベントがトリガーされたら、MultiTier1フローを実行します。Tierフローを実行します。Registrationフローを実行します。一部のフローには、入力として必要なパラメータが使用されます。フローごとに異なるパラメータが渡されます。Settings)フローには、<customAccessSettings>がパラメータとして使用されます。次に、アセットが登録されたときにMyCASおよびMyCAS2カスタム・アセット設定が自動的に割り当てられるワイヤリングの例を示します。Repositoryのアセット・エディタを使用して実行される手動でのアセット受入れおよび登録プロセスを自動ワークフローで自動化する方法について説明します。Repositoryユーザーズ・ガイド』を参照してください。注意:リポジトリ・ユーザーが「アセットの発行」リンクを介してアセットを発行する場合は、コミュニティ受入れまたは自動受入れフローを有効にしないでください。Repositoryではサポートされていません。コミュニティ・フローの構成コミュニティ・フローは、自動割当てルールの構成を可能にすることによってアセットの受入れ、割当て、登録プロセスを自動化する方法を提供するとともに、様々な機関の間のフェデレーテッド・レジストラに関する概念を示します。すべてのコミュニティにわたって(システム・レジストラ通知を介して)多数のレジストラを送信するかわりに、システム・レジストラの数を1人または2、3人の個人に制限し、コミュニティの管理レジストラのかわりに自動受入れフローでアセットを受け入れるようにすることができます。コミュニティ・フロー機能により、コミュニティのためにアセット発行を承認する権限を持つ個人にアセット発行を分散できます。コミュニティ・フローを使用して、次のシナリオに対応できます。新しく発行されたアセットに関する多くの通知を単一のレジストラが受け取るのとは対照的に、自動フェデレーテッド・レジストラが受入れをサポートします。アセット受入れが手動であっても、コミュニティ・フローを使用して、事前定義済の承認者へのアセット承認の割当てを自動化できます。事前定義済の承認者の作成は、次の2つの方法で行うことができます。そのアセット内のすべてのタブに対する事前定義済の承認者のリストを作成します。複数層割当て(これは複数層フローと同じですが、コミュニティ内で動作します)を使用します。登録プロセスの自動化。次の条件が満たされると、アセットは自動的に登録されます。複数層プロセス内の最後の層が完了した場合またはどちらかが最初に起こった場合コミュニティはフロー構成内で構成され、アセット・タイプ、プロジェクトの作成などがコミュニティを指すことができます。図A-14に、アセットのコミュニティをフローによって特定する方法、および自動受入れのルールをフローによって特定する方法を示します。自動アセット受入れのフローチャート注意:自動登録の場合も同じフローチャートが適用されます。単純にautoAcceptをautoRegisterに置き換えてください。Repositoryプロジェクトに対するコミュニティの設定プロジェクトに対してコミュニティを定義するには、<producingProjectSettings>要素を使用します。Excellence」コミュニティに対して「Registry」という名前のプロジェクトを作成する方法を示しています。アセット・タイプに対するコミュニティの設定アセット・タイプに対してコミュニティを定義するには、<assetType>要素を使用します。Excellence」コミュニティに対して「Application」という名前のアセット・タイプを作成する方法を示しています。タイプ・マネージャおよびアセット・エディタを使用したアセット・タイプに対するコミュニティの設定workflow.xml内でアセットに対してコミュニティを設定するかわりに、タイプ・マネージャおよびアセット・エディタを使用してアセット・タイプに対してコミュニティを設定できます。タイプ・マネージャで、次の手順に従います。「コミュニティ」フィールドを有効にするアセット・タイプを選択し、「ビューア」タブをクリックします。図A-16に示すように、「グループで表示」ボタンをクリックします。次に、アセット・エディタで、次の手順に従います。タイプ・マネージャで選択したアセット・タイプのアセットを選択します。図A-17に示すように、「概要」タブの「コミュニティ」フィールドで、そのアセットに使用するコミュニティ名を設定します。アセット・エディタの「コミュニティ」フィールドでのコミュニティ名の設定A.6.4.1.2項「アセット・タイプに対するコミュニティの設定」でコミュニティを設定するための手順に従った後、アセット・エディタでアセットのコミュニティ名を設定した場合、アセット・エディタでアセットに設定したコミュニティ名により、workflows.xmlファイルに設定されているコミュニティ名がオーバーライドされます。Excellence」コミュニティを設定する方法を示しています。autoAccept="true">注意:リポジトリ・ユーザーが「アセットの発行」リンクを介してアセットを発行する場合は、コミュニティ受入れまたは自動受入れフローを有効にしないでください。Repositoryではサポートされていません。タブ承認を目的としたアセット割当てのためのコミュニティの構成AssetSubmittedイベントがコミュニティ・フローにワイヤリングされている場合、<approvers>要素には、コミュニティ・フローによって自動的に割り当てられる承認者がリストされます。</approvers>タブ承認フローで<alerid>を使用する手順は、A.6.5.2項「タブ承認のための<alerid>の使用」を参照してください。複数層割当ては複数層フローと同じですが、コミュニティ内で動作します。フロー」を参照してください。注意:コミュニティの複数層構成内で提供されるタブは、すべてのアセット・タイプ内に存在する共通タブである必要があります。Excellence」コミュニティを設定する方法を示しています。専用レジストラを使用するためのコミュニティの構成アセットの受入れ、割当ておよび登録を行うには、レジストラのユーザー名およびパスワードが必要です。コミュニティ・フローでは、アセットが属するコミュニティからレジストラ情報がロードされます。アセットがコミュニティに属していない場合、またはレジストラ情報がコミュニティ内にない場合は、グローバル・レジストラがコミュニティ・フローによって使用されます。コミュニティ・フローによってコミュニティ・タグが取得される優先順位を次に示します(図A-13を参照)。自動受入れおよび自動登録フローの構成コミュニティ・フローを使用してアセットの受入れおよび登録を自動的に行う以外に、図A-13に示すように、次のルールを使用してアセットの受入れおよび登録を行うことができます。注意:リポジトリ・ユーザーが「アセットの発行」リンクを介してアセットを発行する場合は、コミュニティ受入れまたは自動受入れフローを有効にしないでください。Repositoryではサポートされていません。アセット・タイプAssetType要素内のautoAcceptおよびautoRegisterフラグを使用して、アセットの受入れおよび登録を自動的に行うことができます。カテゴリ分け設定デフォルトでは、フローではautoAcceptおよびautoRegisterフラグは検索されません。理由は、これらの参照によってパフォーマンスに影響が及ぶ可能性があるからです。これは、<action>フラグの使用によって有効にすることができます。次の例に示すように、フローでカテゴリ分け設定の使用が必要になる場合は、<action>フラグをtrueに設定する必要があります。しない場合、カテゴリ分け設定は無視されます。発行者ロール発行者ロールを使用して、アセットの受入れおよび登録を自動的に行うことができます。次の構成に指定されているロールが発行者ロールと一致する場合、アセットは自動的に受け入れられます。場合によっては、図A-13に示すように、特定のイベント・トリガーについて一致するルールが複数存在するため、受入れや登録のために自動受入れフローおよび自動登録フローで各ルールを評価する方法に関する階層が存在します。フローでは、次のメタデータ部分がスキャンされ、次の優先度でいずれかのメタデータが検出されると、フローは中断され、そのメタデータ内の設定が使用されます。複数層承認フローにより、層と呼ばれる複数の手順でアセット・タブ承認プロセスを構築します。アセット承認タブは層にグループ化できます。複数層フローでは、指定した承認者によってすべてのタブが承認されているかどうかを確認するために各層が追跡されます。層内の最後のタブが承認されると同時に、複数層フロー内では、指定した承認者の次のレベルにアセットを割り当てることによって次の層が開始されます。ユースケース場合によっては、層と呼ばれる複数の手順でタブ承認用のタブを割り当てる方が望ましいことがあります。文書タブを承認する前にアーキテクチャ・タブを承認する方が望ましいことがあります。理由は、アーキテクチャに関する問題は、文書の専門家が着目する前に修正する必要があるからです。以前のリリースでは、タブ承認は、レジストラが各タブ承認のステータスを手動で追跡してからこのタブを次の層レベルの承認のために割り当てることにより、手動で行われていました。複数層フローの場合、このプロセスはフローによって自動化されます。図A-18に、複数層プロセスのフローを示します。タブ承認のための<alerid>の使用workflow.xmlファイルが生成されると、<allAssetSettings>セクションの下に次のXMLセクションが作成されます。Repository内に作成されるすべてのユーザーです。</alerUsers>ワークフロー管理者としては、アセット・タブの承認に使用する名前別にユーザーを識別し、対応する<alerid>を使用する必要があります。これにより、この<alerid>を、次の複数層承認フローのようにワークフローXMLで使用できます。Excellence」コミュニティでタブ承認者のために複数層フローを構成する方法を示しています。</communities>注意:コミュニティの複数層構成内で提供されるタブは、すべてのアセット・タイプ内に存在する共通タブである必要があります。次の例は、複数層承認のためにアセット・タイプ「Application」のタブを構成する方法を示しています。メタデータ変更フローメタデータ・フローは、アセットのメタデータ要素が変更されるときに1つ以上のアクションを実行するフローのグループです。変更されるメタデータ要素は、1つ以上のフローにワイヤリングされたイベントをトリガーします。イベントをフローにワイヤリングする手順は、A.6.3項「アセット・イベントのフローへのワイヤリング」を参照してください。ユースケースメタデータ変更フローを適用できるいくつかのユースケースを次に示します。Stage」メタデータ要素を「Build」から「Release」に変更する場合は、アセットに対するアクセス制御をより制限するようにカスタム・アクセス設定を変更できます。アセットの「Name」を変更する場合は、サブスクライバに通知できます。Management」承認プロセスで処理できます。Management」には次の処理が含まれます。Management」という名前のタブの承認を解除します。図A-19に、アセット・エディタの「変更の管理」タブを示します。アセット・エディタの「変更の管理」タブアセットをレジストラに割り当てます。「再割当ての理由」フィールドに変更の種類を追加してレジストラをサポートします。メタデータ変更フローの構成この項では、メタデータ変更フローの構成について説明します。使用可能なメタデータ変更イベント/状態メタデータ変更フローにワイヤリングできる状態を次に示します。注意:これらのイベント以外にも、カスタム・カテゴリ分けを含む任意のカテゴリ分け変更をワイヤリングできます。name="urn:com:bea:aler:events:type:MetaDataChange:usageFee">ほとんどのアセット・タイプの場合、usageFeeフィールドはアセット・エディタの「その他」タブにあります。アクションにワイヤリング可能なフローアクションにワイヤリング可能な事前定義済のフローを次に示します。これらのフロー名は、<action>要素内のコンテンツとして表示され、これがイベントの発生時に実行する必要のあるアクションであることを示します。<action>以外のすべての要素は、特定のフローによって使用されるパラメータです。アセットへの1つ以上のカスタム・アクセス設定に適用されます。アセットのアセット・ライフサイクル・ステージを設定します。アセットの分類を設定します。アセットをレジストラに割り当てます。Repositoryに保存します。メタデータ変更をサブスクライバに通知します。メタデータ変更についてレジストラ、サブスクライバ、所有者などに通知します。メタデータ変更について構成済のカスタム・ユーザーに通知します。変更管理プロセスをトリガーします。「変更の管理」タブが承認されるとすぐに、「変更の管理」タブの「再割当ての理由」フィールドをリセットします。アセットの発行時に使用されるコミュニティ受入れフローを呼び出します。アセットの受入れ時に使用されるコミュニティ割当てフローを呼び出します。アセットの受入れ時に使用される多層フローを呼び出します。タブの承認時に使用される多層フローを呼び出します。1つ以上のタブを承認します。1つ以上のタブの承認を解除します。発行者のロールに基づいて1つ以上の構成済のタブを承認します。すべてのタブが承認されたときにアセットを登録するためのフローを呼び出します。アセットをレジストラに割り当てて承認します。このフローでは、コミュニティ・レジストラ(構成されている場合)を使用します。構成されていない場合は、グローバル・レジストラを使用します。タイマー・ベースのフローで使用される状態情報をリセットします。これは、未発行のアセットをタイマー・フローで追跡する場合や、状態が未発行から発行済に変更された場合に役立ちます。これにより、状態情報をリセットできるようになります。リセットしない場合、アセットの状態が未発行に戻ると、ワークフローでは以前に設定されたものと同じ状態を使用します。これは必ずしも望ましい設定とはかぎりません。ResetFlowStateアクションを適切なイベントまたは状態で使用して、状態情報をリセットできます。アセットが登録済の状態の場合に、そのアセットの登録を解除します。Registryに移動するタイマーベースのワークフローです。Repositoryに移動するタイマーベースのワークフローです。Registryに移動します。Utilityの起動」を参照してください。次の構成例では、アセットが登録されたときに「NotifySubscriber」と「ChangeCAS」という名前の2つのフローを呼び出すよう指定しています。<customAccessSettings>要素は、適用する必要のあるCASの名前をフローに通知するChangeCASフローのパラメータです。メタデータ値をチェックするメタデータ変更構成の例メタデータ要素の変更時のみでなく、メタデータ要素が特定の値を使用する場合にもフローを呼び出すことができます。Stage」メタデータ要素を「Build」から「Release」に変更する場合は、カスタム・アクセス設定の1つのセットを適用できます。この値を「Plan」から「Build」に変更する場合は、別のセットを適用できます。ChangeClassificationアセットの分類を設定します。ChangeClassificationでは、次の要素を使用して分類を設定します。ChangeCAS1つ以上のカスタム・アクセス設定をアセットに適用します。ChangeCASでは、次の要素を使用してカスタム・アクセス設定を行います。ChangeAssetLifecycleアセットのアセット・ライフサイクル・ステージを設定します。ChangeAssetLifeCycleでは、次の要素を使用してアセット・ライフサイクルを設定します。ApproveTabActionApproveTabActionフローでは、アセットの1つ以上のタブを承認します。次の構成では、「Overview」および「Taxonomy」タブを承認します。UnapproveTabAction次の要素では、タブのリストを構成して、UnapproveTabActionフローで承認が解除されるようにします。AutoApproveTabActionAutoApproveTabActionフローでは、発行者のロールに基づいてタブを承認します。<allAssetSettings>の下にある次の要素では、発行者のロールに基づいて自動的に承認する必要のあるタブのリストを構成します。この場合、受入れ可能なロールも構成されます。</automation>フローを呼び出すための構成を次に示します。Management」承認プロセスで処理できます。このプロセスには次の処理が含まれます。「変更の管理」タブの承認を解除します。図A-19に、アセット・エディタの「変更の管理」タブを示します。アセットをレジストラに割り当てます。「再割当ての理由」フィールドに変更の種類を追加してレジストラをサポートします。ResetChangeManagementTabこのフローでは、「変更の管理」タブが承認されるとすぐに、「変更の管理」タブの「再割当ての理由」フィールドをリセットします。NotifyCustomUserメタデータ変更について構成済のカスタム・ユーザーに通知します。次に示すように、ユーザーの電子メール・アドレスは、<allAssetSettings>の下にある<customNotification>要素内で構成されます。名前付きタブの承認に基づくフローの呼出し次に示すように、メタデータ変更フローは、特定のタブの承認に基づいて実行できます。時間ベースのエスカレーション・フローでは、様々な状態のアセットを追跡し、すべての当事者に通知します。次の項では、時間ベースのエスカレーション・フローを構成する方法について説明します。時間ベースのエスカレーション・フローには4種類があり、次の各項で説明するように、各種を個別に構成できます。workflow.xml構成ファイルを開き、<notification>要素を探します。<daysBeforeNextNotification>2</daysBeforeNextNotification>timerInterval要素は、フローがトリガーされるまでの間隔を指定します。本番環境では、この要素を"1d"に設定する必要があります。この場合、フローは1日に1回トリガーされます。テストを行う場合は、"1m"または"5m"に設定してフローを毎分または5分ごとにトリガーすることができます。リフレッシュ・ツールを使用してリフレッシュできる他のフィールドの変更とは異なり、このフィールドが変更されるたびにイベント・エンジンを再起動する必要があります。numTimesNotify要素は、時間ベースのエスカレーション・フローで通知を送信する回数を指定します。daysBeforeNextNotification要素は、通知を送信する間隔を日数で指定します。注意:テストの目的で分単位の間隔でフローをトリガーするようにtimerInterval要素が分単位で構成されている場合は、daysBeforeNextNotificationに指定された間隔も分単位であると解釈されます。図A-20に、時間ベースのエスカレーション・フローを示します。未発行のアセットの追跡このフローでは、「未発行」ステータスのアセットを追跡し、アクションを実行するために所有者に通知を送信します。queryOperator="eq"/>action="true"はフローを有効にし、action="false"はフローを無効にします。days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。未発行のアセットを削除できます。queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。未受入れのアセットの追跡このフローでは、「未受入れ」ステータスのアセットを追跡し、アクションを実行するためにレジストラに通知を送信します。queryOperator="eq"/>action="true"はフローを有効にし、action="false"はフローを無効にします。days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。発行済のアセットを未発行にすることができます。queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。未承認のアセットの追跡このフローでは、「未承認」ステータスのアセットを追跡し、アクションを実行するために承認者に通知を送信します。queryOperator="eq"/>action="true"はフローを有効にし、action="false"はフローを無効にします。days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。受入れ済のアセットを未受入れにすることができます。queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。未登録のアセットの追跡このフローでは、「未登録」ステータスのアセットを追跡し、アクションを実行するために承認者に通知を送信します。regressOnInaction="true"queryOperator="eq"/>action="true"はフローを有効にし、action="false"はフローを無効にします。days="10"は、10日前に未発行ステータス状態になったアセットを追跡します。時間ベースのエスカレーション・フローでは、今日の日付を使用して、この属性から値を減算します。regressOnInaction="true"は、アクションが実行されていないアセットを元の状態に戻します。登録済のアセットを未登録にすることができます。queryOperator="eq"の場合は、問合せに日付が使用される場合に等価演算子を使用します。指定可能なその他の値は"lte"、"gte"などです。有効期限の検証フローでは、有効期限より前に期限が切れたアセットや、期限日に期限が切れたアセットを追跡し、すべての当事者に警告通知を送信します。有効期限のX日後に、アセットの登録を解除します。有効期限のY日後に、アセットを非アクティブにします。有効期限のZ日後に、アセットを削除します。<daysBeforeNextNotification>2</daysBeforeNextNotification>timerInterval属性は、フローがトリガーされるまでの間隔を構成します。この属性は"1d"に設定する必要があります。この場合、間隔は1日です。テストを行う場合は、"1m"または"5m"に設定して毎分または5分ごとにトリガーすることができます。リフレッシュ・ツールを使用してリフレッシュできる他のフィールドの変更とは異なり、このフィールドが変更されるたびにイベント・エンジンを再起動する必要があります。numTimesNotify要素は、有効期限の検証フローで通知を送信する回数を指定します。daysBeforeNextNotification要素は、通知を送信する間隔を日数で指定します。</expiration>図A-21に、有効期限の検証フローを示します。有効期限の検証フローチャートアセットの有効期限を設定するには、図A-22に示すように、アセット・エディタの「その他」タブにある「有効期限(yyyy-MM-dd)」フィールドに日付を指定します。次の行では、警告の通知を有効にして、その通知を受け取るユーザーを指定します。contact="99"/注意:days要素により、警告を送信する必要のある、有効期限までの日数を構成します。次の行では、メタデータ変更フローを有効にして、有効期限の10日後にアセットの登録を解除します。次の行では、メタデータ変更フローを有効にして、有効期限の10日後にアセットを非アクティブにします。次の行では、メタデータ変更フローを有効にして、有効期限の10日後にアセットを削除します。電子メール通知テンプレートのカスタマイズ自動登録フローでは、多くの状況下で電子メール通知が自動的に送信されます。新しいフローのための新しい電子メール・テンプレートは5つあります。APIを呼び出します。Repositoryによって置き換えられます。管理者は、他の電子メール・テンプレートの場合と同じ方法で電子メールの件名や本文などをカスタマイズできます。自動ワークフローで使用されるテンプレートを次に示します。アセットに割り当てられたレジストラとユーザーに、メタデータが変更されたことを通知します。アセットに割り当てられたレジストラとユーザーに、登録ステータス<%asset.reg.status%>が<%action.pending.days%>日を超えて変更されていないことを通知します。期限切れのアセットに割り当てられたレジストラとユーザーに、ステータスが変更されたことを通知します。アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が近づいていることを通知します。アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が切れたことを通知します。電子メール・テンプレートの詳細は、第8章「電子メール・テンプレートの使用」を参照してください。電子メール通知のユースケースこの項では、電子メール通知ユースケースを示し、次の電子メール・テンプレートをトリガーする方法について説明します。アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が切れたことを通知します。この電子メール・テンプレートは、アセットが期限切れになるたびにトリガーされます。この電子メール・テンプレートは、拡張ワークフロー構成の一部として作成されます。アセットの有効期限を設定するには、アセット・エディタの「その他」タブにある「有効期限(yyyy-MM-dd)」フィールドに日付を指定します。workflow.xmlには、アセットが期限切れになったときに実行する処理内容を指定するための要素があります。アセットに割り当てられたレジストラとユーザーに、アセット登録ステータスが<%action.pending.days%>日を超えて変更されていないことを通知します。この電子メール・テンプレートは、拡張ワークフロー構成の一部としても作成されます。queryOperator="eq"/>があります。このフローでは、指定した日数の間「受入れ済」ステータスであるアセットを追跡し、アクションを実行するためにレジストラに通知を送信します。regressOnInaction="true"である場合、アクションが実行されていないアセットを元の状態に戻します。受入れ済のアセットを未受入れにすることができます。アセットの通知電子メール・フィールドに指定されている連絡先に、アセットが使用されていることを通知します。この電子メール・テンプレートは、アセットがプロジェクト内で使用されるたびにトリガーされます。この電子メール・テンプレートにより、アセットの「その他」の下にある通知電子メール・テキスト・フィールドに指定されている電子メール・アドレスに通知が送信されます。コンプライアンス・テンプレートがプロジェクトに適用されたときにプロジェクト・リーダーに通知します。この電子メール・テンプレートは、コンプライアンス・テンプレート・タイプがプロジェクトに割り当てられるたびにトリガーされます。コンプライアンス・テンプレート・タイプは、アセット・タイプのアーキタイプの一部です。アセットに割り当てられたレジストラとユーザーに、メタデータが変更されたことを通知します。この電子メール・テンプレートは、拡張ワークフロー構成の一部でもあり、メタデータが変更されるたびにトリガーされます。メタデータ変更フローは複数存在します。詳細は、A.6.6項「メタデータ変更フロー」を参照してください。アセットの新しいバージョンが開発されるたびにサブスクライバに通知します。この電子メール・テンプレートは、新しいアセット・バージョンが開発されるたびにサブスクライバに通知します。新しいバージョンは、「次のバージョン」または「前のバージョン」というリレーションシップに基づいて識別されます。アセットの新しいバージョンが登録されるたびにサブスクライバに通知します。この電子メール・テンプレートは、新しいアセット・バージョンが登録されるたびにサブスクライバに通知します。新しいバージョンは、「次のバージョン」または「前のバージョン」というリレーションシップに基づいて識別されます。アセットに割り当てられたレジストラとユーザーに、アセットの有効期限が近づいていることを通知します。この電子メール・テンプレートは、拡張ワークフロー構成でも使用され、アセットの有効期限が近づくたびにトリガーされます。queryOperator="eq"/>などです。アセットに割り当てられたレジストラとユーザーに、登録ステータス'<%asset.reg.status%>'が<%action.pending.days%>日を超えて変更されていないことを通知します。この電子メール・テンプレートは、ワークフロー構成でも使用され、登録ステータスがワークフロー構成に指定された日数の間変更されない場合にトリガーされます。queryOperator="eq"/>などです。期限切れのアセットに割り当てられたレジストラとユーザーに、ステータスが変更されたことを通知します。この電子メール・テンプレートは、拡張ワークフロー構成でも使用され、期限切れのアセットのステータスが変更されるたびにトリガーされます。アセット使用レコードが再割当てされたことをユーザーに通知します。この電子メール・テンプレートは、複数の場所からトリガーされます。「プロジェクトの詳細」で、次の手順を実行します。プロジェクトの詳細に移動します。ユーザー/使用方法の再割当てをクリックします。使用方法のみ再割当てを選択します。現在のまたは別のプロジェクトを選択します。「次」をクリックします。そのプロジェクトに対応するユーザーのリストが表示されます。使用方法の転送先のユーザーを選択します。この電子メール・テンプレートは、使用方法が転送されたユーザーに通知を送信します。「プロジェクトの編集」で、次の手順に従います。「プロジェクトの編集」をクリックします。「ユーザーの編集」をクリックします。使用レコードがあるユーザーを削除します。使用方法を転送できるユーザーの「割当て」オプションが表示されます。この電子メール・テンプレートは、使用方法が転送されたユーザーに対する通知をトリガーします。Repositoryワークフローに関する次の既知の問題について説明します。workflow-tools/refresh_workflows.shファイルには、ハードコード化されたJDKへのパスが含まれていますが、このパスは無効です。別のJDKを使用している場合、refresh_workflows.shファイルを手動で編集してそのJDKにマップする必要があります。Windowsでファイルを変更し、UNIXでCR/NL文字を処理する方法を理解しないエディタでこのファイルを保存する場合、次のコマンドを実行してLF文字を<file.sh>ファイルから削除する必要があります。Repository用のJMSサーバーを構成する方法について説明します。JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。Repositoryの複数のシステム設定を構成する必要があります。JMSサーバーは使用できません。6.xに用意されているデフォルトのJMS実装を使用する必要があります。6.1.0.5でのJMSプロバイダの構成」を参照してください。Repositoryの基本操作を構成、および特定の機能を有効/無効にできます。イベント・マネージャのJMS関連の設定は、外部統合カテゴリのイベンティング・グループの下にあります。Repository統合ガイド』を参照してください。Repositoryイベント・マネージャの構成」を参照してください。JMSサーバーを無効にする必要があります。外部JMS用のJNDIおよびJMSプロパティも構成する必要があります。注意:次の手順は、単一の外部JMSサーバーを構成するためのものです。Repositoryクラスタ内のJMSサーバーの構成」を参照してください。Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。「システム設定」の「検索」ボックスに「Event」と入力し、イベント・マネージャ関連の設定をすべて表示します。「イベント・マネージャ組込みJMS有効化」プロパティの横にある「False」をクリックし、内部JMSサーバーのプロパティcmee.eventframework.embedded.jms.enabledを無効にします。これにより、イベント・マネージャが外部JMSサーバーを使用するようにします。注意:cmee.eventframework.embedded.jms.enabledプロパティはデフォルトでは表示されません。このプロパティを有効にするには、「システム設定の有効化」ボックスにこのプロパティ名を入力し、「有効化」をクリックします。eventing.propertiesファイルで、次の必須JNDIプロパティを構成します。t3://localhost:7001などです。cmee.eventframework.jndi.userJNDIユーザー名を指定します。cmee.eventframework.jndi.passwordJNDIユーザー名のパスワードを指定します。cmee.eventframework.jndi.context.factoryJNDI初期コンテキスト・ファクトリを指定します。weblogic.jndi.WLInitialContextFactoryなどです。注意:JNDIプロパティはデフォルトでは表示されません。これらのプロパティを有効にするには、「システム設定の有効化」ボックスに各プロパティ名を入力し、「有効化」をクリックします。eventing.propertiesファイルで、次のJMSプロパティを構成します。cmee.eventframework.jms.connection.factoryJMSクライアントによるJMS接続の作成を可能にするためにJMS接続ファクトリを指定します。weblogic.examples.jms.TopicConnectionFactoryなどです。cmee.eventframework.jms.topicJMSサーバーの公開/サブスクライブの宛先タイプであるJMSトピックを指定します。weblogic.examples.jms.TopicConnectionFactoryなどです。注意:JMSプロパティはすべてデフォルトでは表示されません。これらのプロパティを有効にするには、「システム設定の有効化」ボックスに各プロパティ名を入力し、「有効化」をクリックします。「保存」をクリックします。Repositoryを再起動して構成の変更内容を反映します。JMSメッセージ・ヘッダーのプロパティの構成すべてのJMSメッセージには、デフォルトで挿入され、メッセージ・コンシューマで利用できる標準のヘッダー・フィールドがあります。Repositoryのシステム設定を使用して構成できます。A.7.2.1項「外部JMSサーバーの有効化および構成」で説明されているように、「イベンティング」システム設定にアクセスします。eventing.propertiesファイルで、JMSメッセージ・ヘッダーのプロパティを構成します。JMSメッセージの有効期限を秒単位で設定します。設定されている場合、指定した秒数内に未処理のイベントが期限切れになります。デフォルトは0秒です。この場合、メッセージは期限切れになりません。一部の環境では、JMSメッセージがなんらかの理由によって選択されていない場合、これらのメッセージを恒久的に格納できないようにすることを要求するポリシーが設定されています。このプロパティを有効にし、プロパティ値をcmee.eventframework.jms.expirationに設定してください。JMSメッセージ配信モードをPERSISTENTまたはNON-PERSISTENT値に設定します。PERSISTENTに設定されている場合、JMSサーバーはイベントを基礎となるストアに書き込みます。イベントをストアに対して永続化すると信頼性が高くなりますが、パフォーマンスに影響する可能性があります。デフォルトはPERSISTENTです。このプロパティを有効にし、プロパティ値をcmee.eventframework.jms.deliverymodeに設定してください。「保存」をクリックします。Repositoryを再起動して構成の変更内容を反映します。Repositoryを再起動する必要があります。次のその他のシステム設定を構成することもできます。Falseに設定されている場合、内部JMSサブスクライバは有効になりません。この目的は、組込みJMSサーバーを起動するが、外部ツールを使用して特定の永続サブスクライバ名を使用して組込みサーバーに接続し、格納されているイベントをクリーンアップできるようにすることにあります。JMS永続サブスクライバIDを指定します。ALER_JmsSubscriberなどです。プロパティ名はcmee.eventframework.jms.subscribers.client.idです。JMSプロデューサのクライアントIDを指定します。ALER_DeliveryManagerなどです。プロパティ名はcmee.eventframework.jms.producers.client.idです。有効な場合、イベントが初めて生成されるときにイベント・マネージャが初期化されます。このプロパティを有効にする必要があるのは、次のいずれかの場合です。組込みJMSサーバーを初期化するタイミングが原因で起動に関する問題が発生する場合プロパティ名はcmee.eventframework.lazy.loadです。外部JMSサーバーが使用されている場合、外部JMSサーバー関連のJARファイルをWEB-INF\libディレクトリにコピーする必要があります。JMSサーバーではファイルベースのストアを使用してイベントが格納されます。イベントをデータベースに格納するよう指定することもできます。データベース・パラメータを使用するには、単純にWEB-INF\classesディレクトリ内のactivemq.xmlファイルを構成します。Webサービス・エンドポイント用のJMS永続サブスクライバの構成サブスクリプション・マネージャのXMLファイル内でWebサービス・エンドポイントが検出されるたびに、1つの永続サブスクライバが作成されます。これにより、エンドポイントがオンラインでない場合にイベントが格納され、エンドポイントが再度オンラインになったときにイベントを確実に配信できるようになります。JMS仕様に従い、永続サブスクライバ名はJMSサーバー全体にわたって一意である必要があります。イベント・マネージャは、永続サブスクライバ名を次の例に示すようにEndPointEventSubscription.xmlファイル内にある名前フィールドから取得します。name="ALBPMEndpoint">注意:JMSサーバーは永続サブスクライバ名をメッセージ・セレクタに関連付けます。したがって、メッセージ・セレクタが変更される場合、新しい永続サブスクライバ名を指定するか、既存の永続サブスクライバ名を削除する必要があります。Repositoryのイベント・クリーンアップ・ツールを使用できます。JMS固有のツールを使用してこれを行うこともできます。Repositoryインストレーション・ガイド』を参照してください。Repositoryインスタンスごとにクラスタリングを有効にする必要があります。Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。cmee.eventframework.clustering.enabledを「新しいシステム設定の有効化」ボックスに入力し、「有効化」をクリックして、この非表示のプロパティを表示します。「有効クラスタリング」プロパティをTrueに設定します。次の各項で説明されているように、JMSサーバーのタイプに基づいて他の必要なプロパティを設定します。Repositoryのメンバー・インスタンスごとに1つの組込みJMSサーバーが設定されます。Repositoryインスタンスが2つ存在し、それぞれに1つの組込みJMSサーバーがあります。組込みJMSサーバーに対してクラスタリングが有効になったら、server01およびserver02上の組込みJMSサーバーに対して接続URL情報を指定する必要があります。Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。cmee.eventframework.embedded.jms.urlを「新しいシステム設定の有効化」ボックスに入力し、「有効化」をクリックして、この非表示のプロパティを表示します。Repositoryサーバー上の組込みJMSサーバーの接続URLを指定します。意味は次のとおりです。$SERVER_DNS_NAME_OR_IP$は、実際のサーバーのDNS名またはIPアドレスによって置き換えられます。Repositoryサーバーごとに繰り返す必要があります。前述の例を使用して、これは、failover:(tcp://server01:61700,tcp://server02:61700)のように設定できます。Repositoryサーバー上の他のアプリケーションによって使用されないようにする必要があります。「保存」をクリックします。Repositoryインスタンスごとに手順1-4を繰り返します。前述の例を使用して、組込みブローカのURLは、failover:(tcp://server01:61700,tcp://server02:61700)のように設定できます。ヒント:cmee.eventframework.embedded.jms.enabledプロパティをTrueに設定することにより、各組込みJMSサーバーが有効であることを確認してください。外部JMSサーバーの場合、追加構成は必要ありません。次のように、組込みJMSサーバーが無効であることを確認する必要があります。Repositoryの「管理」画面上のサイドバーにある「システム設定」をクリックします。イベント・マネージャ組込みJMS有効化プロパティをFalseに(つまり、cmee.eventframework.embedded.jms.enabledをFalseに)設定します。JMSサーバーは使用できません。6.1.0.5に用意されているデフォルトのJMSプロバイダを使用する必要があります。Repositoryアプリケーションで次の手順をすべて実行します。新しいサービス統合バスを作成します。Integration」を展開し、「Buses」をクリックします。「Buses」ページで、「New」をクリックします。bus」ページで、新しいバスの名前として「alerbus」を入力します。security」オプションの選択を解除します。「次へ」をクリックして、「完了」をクリックします。新たに作成されたalerbusにバス・メンバーを追加します。「Buses」ページで、「alerbus」リンクをクリックします。members」をクリックします。members」ページで、「Add」をクリックします。server」ページで、デフォルトの「Server」オプションをそのまま使用して、「Next」をクリックします。store」オプションをそのまま使用して、「Next」をクリックします。properties」ページで、デフォルト値をそのまま使用して、「Next」をクリックします。Confirmation」ページで、「Finish」をクリックします。「Buses」ページで、「Save」をクリックします。デフォルトのメッセージ・プロバイダでJMSトピック接続ファクトリを作成します。providers」をクリックします。provider」オプションをクリックします。server=server1」にします。factories」オプションをクリックします。factories」ページで、「New」をクリックします。「Administration」ページで、次のようにトピック接続ファクトリを構成します。<nodename>.server1-alerbus「Apply」をクリックし、「Save」をクリックします。デフォルトのメッセージ・プロバイダでJMSトピックを作成します。provider」ページにもう一度移動します。Properties」の下にある「Topics」オプションをクリックします。Topic」ページで、「New」をクリックします。「Administration」ページで、次のようにトピックを構成します。Default.Topic.Space「Apply」をクリックし、「Save」をクリックして変更を保存します。次のように、aler.earアプリケーション・ファイルをデプロイします。Applications」をクリックします。Applications」ページで、「Install」をクリックします。install」ページで、「Browse」をクリックし、aler.earファイルをパスに指定して、「Next」をクリックします。options」ページで、「Next」をクリックします。servers」ページで、「Next」をクリックします。Name」列の「Browse」をクリックします。resources」ページで、「alerEventingTopicCFDefault」を選択し、「Apply」をクリックします。references」ページで、「Next」をクリックします。Name」に「jms/aler/alerEventingTopicDefault」と入力し、「Next」をクリックします。「Summary」ページで「Finish」をクリックします。アプリケーションがインストールされたら、「Save」をクリックし、アプリケーションをマスター構成に保存します。Repositoryアプリケーションで必要なデータベース・ドライバをデプロイします。Repositoryのeventing.propertiesファイルを構成します。Domain>\WEB-INF\classesディレクトリに移動します。テキスト・エディタを使用して、次のようにeventing.propertiesファイルを変更します。cmee.eventframework.jms.topic=jms.alerEventingTopicDefaultcmee.eventframework.jndi.provider.url=iiop\://localhost:2809cmee.eventframework.embedded.jms.enabled=falsecmee.eventframework.jndi.context.factory=com.ibm.websphere.naming.WsnInitialContextFactorycmee.eventframework.jms.connection.factory=jms.alerEventingTopicCFDefaultファイルを保存します。WebSphereアプリケーション・サーバーを再起動して、変更した設定を有効にします。WebSphereログの\WebSphere\AppServer\profiles\AppSrv01\logs\server1で、可能性があるエラーについて確認します。Repositoryでイベントをモニターおよび管理する手順について説明します。Repositoryの一部として用意されている管理ツールについて説明します。拡張登録フロー管理ツールを使用して、次を行います。管理ツールは、次のディレクトリにインストールされます。イベントのモニタリングイベント・マネージャには、イベント・マネージャによって生成されたイベントをモニタリングするためのツールが用意されています。このツールは、イベント・トラフィックを監視し、この項に示すイベント本体やイベント・プロパティなどの情報を出力します。前提条件モニタリング・ツールを起動する前に、次の前提条件を満たす必要があります。Repositoryを実行する必要があります。Repository内に組み込まれたJMSブローカが実行され、モニタリング・ツールがJMSブローカに接続してイベントをモニターできるようにします。外部JMSサーバーが使用される場合、外部JMSサーバーが実行されている必要があり、外部JMSサーバーに接続するために必要なJNDI関連のeventing.propertiesが構成されている必要があります。詳細は、A.7.2項「外部JMSサーバー用の接続プロパティの構成」を参照してください。次のように、コマンド・プロンプトからイベント・モニタリング・ツールを実行します。Repositoryが、D:\bea816\user_projects\domains\oerdomainの下にあるoerdomainという名前のドメインにデプロイされているとします。WEB-INF\classes>は次のようになります。<Oracle_HOME>\user_projects\applications\base_domain\applications\oer_11.1.1.4.0\oer-app\WEB-INF\classesOracle_HOMEは、OER_HOMEインストールの場所を表します。このパスは、このツールがJMSサーバーに接続できるようeventing.propertiesファイルからJMS構成を取得するために必要です。格納されたイベントのクリーンアップ場合によっては、イベント・エンジンによって格納されたすべてのイベントを削除し、永続サブスクリプションのサブスクライブ解除も必要になります。これを行うには、イベント・クリーンアップ・ツールを使用します。前提条件このツールを起動する前に、次の前提条件を満たす必要があります。Repositoryイベント・マネージャが永続サブスクライバを起動しないようにします。理由は、これは、イベント・クリーンアップ・ツールによってサブスクライブ解除されるからです。Repositoryを再起動します。次のように、コマンド・プロンプトからイベント・クリーンアップ・ツールを実行します。Repositoryが、D:\bea816\user_projects\domains\oerdomainの下にあるoerdomainという名前のドメインにデプロイされているとします。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構成を取得するために必要です。Subscriber>は、次のように、EndPointEventSubscription.xml内のイベントのクリーンアップが必要なエンドポイント内の名前属性にあります。Selector>は、EndPointEventSubscription.xmlファイル内のクリーンアップが必要なエンドポイント内の式属性にあります。注意:メッセージ・セレクタが設定されていないか空である場合、このパラメータは省略できます。前述の例を使用して、workflow-toolsディレクトリに移動します。D:\bea816\repositoryXXX\core\workflow-tools>コマンド・プロンプトで、次を入力します。ALBPMEndpointイベント・クリーンアップ・ツールによってコンソールに表示される出力は、次のとおりです。Repositoryに接続してワークフロー構成ファイル(workflow.xml)を生成します。Repositoryから読み取り、これらのエンティティの構成をworkflow.xmlに移入します。これにより、要件に応じてワークフロー構成ファイルをカスタマイズできるようになります。フローを構成およびカスタマイズして新しいアセット・タイプ、プロジェクト、カテゴリ分けなどの追加が必要になる場合があります。自動ワークフローの構成の詳細は、A.6項「自動ワークフローの構成」を参照してください。次のように、コマンド・プロンプトからワークフロー構成の生成ツールを実行します。ConfigDir意味は次のとおりです。構成XMLファイルが作成されたディレクトリ。このファイルが存在する場合は、名前がworkflow.xml.bakに変更されます。ワークフロー構成の生成ツールworkflow.xmlファイルは次のディレクトリに生成する必要があります。Managementエンジンを再起動せずにワークフロー構成ファイルをリフレッシュできます。Managementエンジンを再起動しなくてもエンジンで更新バージョンを使用できるようになります。Managementエンジンが実行されている必要があります。次のように、コマンド・プロンプトからワークフロー構成のリフレッシュ・ツールを実行します。Password意味は次のとおりです。Managementのパスワード(たとえば、aler_workflow_pass)注意:aler_workflow_userは、Oracle製品インストーラによって作成されます。これが、このツールで使用できるデフォルトのユーザーです。パスワードの暗号化セキュリティを高めるために、セキュリティ暗号化パスワード・ツール(runWfSecurity.bat)を使用して、ワークフロー構成ファイルおよびサブスクリプション・サービス・ファイルに格納されているパスワードを暗号化できます。次のように、コマンド・プロンプトからセキュリティ暗号化パスワード・ツールを実行します。destFileName意味は次のとおりです。Webサービス・エンドポイントのイベント・マネージャの拡張この項では、Webサービス・エンドポイントのイベント・マネージャを拡張する方法について説明します。概要この項では、イベント・マネージャによって発行されるイベントを使用するためにWebサービス・エンドポイントを開発する方法について説明するとともに、他の通知サービス・プラグインを使用するためにイベント・マネージャを拡張する方法について説明します。Repositoryイベント・マネージャの構成」を参照してください。Repositoryイベント・マネージャによって発行されたイベントを受け取るためにWebサービス・エンドポイントをプラグインする方法を示します。Webサービス・エンドポイントのプラグイン新しいWebサービス・エンドポイントを作成し、イベントの取得を開始するには、次の手順を実行します。イベント・マネージャによって定義されたWSDL契約を選択します。path>/WEB-INF/libディレクトリにあるmodules.eventing-11.1.1.x.x.jarファイルにバンドルされています。jarファイルを開き、"EventListener.WSDL"という名前のWSDLを探し、このWSDLをファイル・システムに抽出します。このWSDLは、イベント・マネージャによって定義された抽象契約であり、新しいWebサービス・エンドポイントでは、WSDLに定義されている操作を実装する必要があります。図A-29に、WSDLファイルのスナップショットを示します。要件に応じて、ツールまたはテクノロジを使用してWebサービス・エンドポイントの開発を完了させます。Busを使用して、プロキシ・サービスを開発できます。Webサービスの開発を完了させ、Webサービスを実行できるようにします。Webサービス・エンドポイントのホスト、ポートおよびURIなどをサブスクリプション・マネージャ・ファイルに入力できるようイベント・マネージャを構成します。Repositoryイベント・マネージャの構成」を参照してください。Repositoryを起動し、アセット・エディタを使用してイベントをトリガーします。これにより、Webサービス・エンドポイントによるイベントの取得が開始されます。Repositoryにバンドルされているイベント・モニタリング・ツールを使用して、イベント・マネージャによって生成されたイベントをデバッグおよびモニタリングできます。Webサービスの操作この項では、新しいWebサービス・エンドポイントに対して使用可能な操作や、イベント・マネージャで操作を指定する方法について説明します。Repositoryイベント・マネージャは、次の操作をサポートしています。newEventRequestResponseこの操作では、XMLスキーマ・セクションに定義されているイベント・オブジェクトが入力として使用され、ステータスが出力として返されます。ステータスは文字列型として定義されます。ステータスの文字列の先頭がFailureの場合、例外がスローされ、成功するまでイベントの再配信が試行されます。それ以外の場合、レスポンスが記録され、トランスポートの例外が発生しないかぎり、次のイベントが配信されます。newEventRequestResponseStringこの操作では、文字列形式のイベント・データが入力として使用され、ステータスが出力として返されます。ステータスは文字列型として定義されます。ステータスの文字列の先頭がFailureの場合、例外がスローされ、成功するまでイベントの再配信が試行されます。それ以外の場合、レスポンスが記録され、トランスポートの例外が発生しないかぎり、次のイベントが配信されます。newEventRequestこの操作では、XMLスキーマ・セクションに定義されているイベント・オブジェクトが入力として使用され、一方向の操作として定義されます。newEventRequestStringこの操作では、文字列形式のイベント・データが入力として使用され、一方向の操作として定義されます。Managementである場合にのみ使用する必要があります。Managementが認証されます。この呼出しの後にdiscardSessionも呼び出されます。Webサービスの操作の選択イベント・マネージャのサブスクリプション・マネージャを次のように構成することにより、operationName要素に指定されている優先Webサービスの操作を選択できます。Repositoryイベント・マネージャには、デフォルトのSOAP/HTTP通知サービスが含まれます。追加の要件が存在する場合は、図A-30に示すように、新しいプラグインを開発してプラグインできます。新しいプラグインがイベント・マネージャと連携して機能するようにするには、次の手順に従います。Repositoryイベント・マネージャにバンドルされているJavaクラスAbstractEventNotifierを拡張して、新しい通知サービス・プラグインを開発します。path>-app/WEB-INF/libディレクトリにあるmodules-eventing-<oer.version>.jarにバンドルされています。init()およびsendNotification()メソッドをオーバーライドする必要があります。(EventManagerPublicAPIdoc.zip)を参照してください。Bean形式でイベント・データを渡します。これにより、イベント・データを外部Webサービスに送信できるようになります。開発されたクラスを指すようにサブスクリプション・マネージャ・ファイルを構成します。notifierClass要素を次のように変更します。path>/WEB-INF/libディレクトリにコピーして、クラスパスで選択されるようにします。イベント・マネージャを再起動し、アセット・エディタを使用してイベントをトリガーします。新しい通知サービス・プラグインのinit()およびhandle()メソッドが呼び出されます。Repositoryイベント・マネージャとの互換性のないインタフェースまたは契約を持つエンドポイントが存在する可能性があります。Repositoryイベント・マネージャで提供されるWSDLの使用制限があるか、他の相互運用性の問題が存在する可能性があるためです。そのような状況では、次のアプローチを使用できます。イベントXMLデータを受信するイベント通知サービス・プラグインを開発し、サブスクリプション・マネージャに登録します。リモートWebサービスが想定する形式にイベント・データを変換する、新しい通知サービス・プラグインのコードを記述します。リモート・エンドポイントでサポートされているAPIでリモートWebサービスを呼び出します。APIを使用できます。Webサービスを呼び出す場合は、次を使用します。OERワークフローの操作アセット・エディタを使用して、アセットを管理し、値リスト、カテゴリ、リレーションシップ、拒否理由、アーティファクト・ストアおよびベンダーなどのアセットに関連付けられたリソースを構成します。通常、アセット・エディタはWebコンソールから起動します。登録プロセスを経るアセットは、図A-31に示すアセット・エディタ内のファイル・ツリーに表示されているように、複数のフォルダを介して編成および管理されます。ファイル・ツリー」の説明アセットの登録プロセスは、「発行済」フォルダの下にあるレビュー保留中フォルダから開始されます。アセットは、レジストラによって受け入れられるか拒否されると、「発行済」の下にあるレビュー中フォルダに移動します。アセット・エディタのタブにあるデータについて、レジストラによるレビューと承認を待機中の場合、そのアセットは、レビュー中から「登録済」フォルダに移動します。Stuffを使用することで、アセットの進捗状況を追跡できます。登録プロセスには、次のアクションが含まれます。発行アセットがユーザーによって発行され、「発行済」の下のレビュー保留中フォルダに表示されます。発行キューに新しいアセットが入ったことを知らせる自動電子メール・メッセージがレジストラに送信されます。レビューレジストラがアセットと関連情報を検証し、受け入れを決定します。これにより、アセットは作業キューに入ります。レジストラがアセットの拒否を選択する場合もあります。拒否アセットを拒否する場合、レジストラは拒否の理由を入力します。Stuff内の「個人の発行」フォルダ内で拒否済としてマークされます。受入れアセットが受け入れられたら、処理と承認のために1人以上のレジストラに割り当てることができます。Stuffから表示できます。登録のために受け入れられたアセットはレビュー中フォルダに移動し、レジストラまたは上級発行者が登録プロセスを開始します。必要な情報が収集され、アセット・エディタの適切なタブに入力されます。レジストラは、各タブを検証し、ワークフローをモニターします。ワークフローの特定のステージの情報が受入れ可能な場合、レジストラは該当するタブのデータを承認します。承認プロセスに規定の順序はありません。レジストラは任意の順序で任意のステージを承認できます。レジストラは、プロセスの任意のステージの情報を編集することもできます。承認レジストラは、様々なタブのそれぞれに入力された情報について、「管理」タブで組織の基準に基づいて最終的な承認を行います。任意のアセットに関するアセット・エディタのタブの特定の構成は、アセットが発行時に割り当てられるタイプ・テンプレートによって決まります。各タブには、アセットを記述、およびアセットの使用を容易にするために使用されるメタデータの様々な要素があります。Repositoryには、登録プロセスの理解に定義されている、登録プロセスとガバナンス・プロセスを自動化しようとする、事前に構築されたBPMアセット登録フローがバンドルされています。Repositoryイベントをサブスクライブすることができます。OBPMデザイナを使用して、新しいガバナンス・ワークフローを作成できます。トラブルシューティングおよびチューニングを目的としたイベント・モニタリング・ツールやロギング・ツールも用意されています。自動ワークフロー機能の使用の詳細は、A.6項「自動ワークフローの構成」を参照してください。発行の受入れこの手順は、アセット・エディタで実行されます。(適切な権限が必要です。)「発行済」フォルダを開きます。レビュー保留中を開きます。図A-32に示すように、登録するアセットを選択します。アセット・エディタ」の説明オプション:「受入れ」をクリックします。アセットがツリー内の「レビュー中」フォルダに移動し、アセットの下にある各ワークフロー・フォルダにも表示されます。ワークフロー・フォルダは、アセット・エディタのタブに相当します。「受入れおよび割当て」をクリックします。図A-33に示すように、「ユーザーの割当て」ダイアログが表示されます。「<<」および「>>」ボタンを使用して、「使用可能なユーザー」列と「選択したユーザー」列の間で項目を移動します。「OK」をクリックします。アセットがツリー内のレビュー中フォルダに移動し、選択したユーザーに割り当てられます。このユーザーが、アセット・エディタの各タブに必要な情報を入力します。割り当てられたユーザーは、このアセットに割り当てられたことを通知する電子メールを受信することもできます。アセットの登録いくつかのタブはすべてのアセット・タイプに共通ですが、任意のアセットに関するアセット・エディタの特定のタブは、アセットが発行時に割り当てられるタイプ・テンプレートの構成によって決まります。「概要」タブ「概要」タブをクリックします。図A-34に示すように、「概要」タブが表示されます。各フィールドに適切な情報を入力します。図A-35に示すように、「承認」をクリックします。「概要」タブのテキストの色が変更され、「承認」ボタンは「非承認」に変わります。注意:アセット・エディタの「承認」ボタンは、適切な権限を持つユーザーにのみ表示されます。分類タブ「分類」タブをクリックします。図A-36に示すように、分類タブが表示されます。分類タブ」の説明いくつかのカテゴリが表示されます。「分類」セクションの「割当て」ボタンをクリックします。「分類の割当て」ダイアログが表示されます。オプションを使用して、適切な分類を選択します。承認済プロジェクトでの使用がレジストラによって承認されています。学習または情報提供のみを目的とします。プロジェクトでの使用は承認されていません。必須アセットが提供する機能がプロジェクトに必要な場合に必ず使用します。(これは、顧客データへのアクセスや支払処理などを行うWebサービスに特に関係があります。なくとも1つのプロジェクトでデプロイに成功しています。「OK」をクリックします。選択内容が「分類」セクションにリストされます。注意:使用環境を反映するように、デフォルトのカテゴリをカスタマイズできます。分類タブの各セクションについて、このプロセスを繰り返します。「キーワード」セクションのテキスト・ボックスに適切なキーワードを入力します。「追加」をクリックします。図A-37に示すように、この新しいキーワードが「キーワード」リストに表示されます。必要に応じて、他のキーワードを追加します。分類タブが完了したら、「承認」をクリックします。「概要」タブのテキストの色が変更され、「承認」ボタンは「非承認」に変わります。「ドキュメント」タブ「Documentation」タブをクリックします。図A-38に示すように、「ドキュメント」タブが表示されます。提案される多数のドキュメント・タイトルが「ドキュメント」ウィンドウにリストされます。これらの各タイトルに、適切なドキュメントを関連付けることができます。新しいドキュメントをリストに追加できます。新しいドキュメントを追加するには、次の手順を実行します。「追加」をクリックします。図A-39に示すように、「編集」ダイアログが表示されます。「名前」テキスト・ボックスに適切な情報を入力します。「URL」テキスト・ボックスの横にある「編集」ボタンをクリックします。図A-40に示すように、「URLの編集」ダイアログが表示されます。必要に応じて、アーティファクト・ストア・ファイルまたは「外部ファイル」を選択します。使用可能なテキスト・ボックスに必要な情報をすべて入力します。「OK」をクリックします。図A-41に示すように、この新しいドキュメントがリストに表示されます。既存のドキュメントのファイル情報を編集するには、ドキュメントを選択し、「編集」をクリックして、手順4から7を繰り返します。終了したら、図A-42に示すように、「承認」をクリックします。「リレーションシップ」タブ「リレーションシップ」タブをクリックします。「追加」ボタンをクリックします。図A-43に示すように、「リレーションシップの追加」ダイアログが表示されます。「検索」ボタンまたは「アクティブなすべてを表示」ボタンを使用して、ダイアログの「アセット」セクションにアセットを表示します。リストからアセットを選択します。「リレーションシップ・タイプ」リストを使用して、2つのアセット間の適切なリレーションシップを選択します。注意:必要に応じて、リレーションシップの反転ボタンをクリックして、リレーションシップを逆にします。終了したら、「OK」をクリックします。必要に応じてこの手順を繰り返して、他のアセットのリレーションシップを追加します。終了したら、「承認」をクリックします。Repository管理ガイドを参照してください。Repositoryのすべてのアセットに「管理」タブがあります。「管理」を使用して、次のことを行います。済のワークフローを追跡します。他のタブの情報をレビューおよび承認するユーザーを割り当てます。アセットのステータスを変更します。アクティブ非アクティブリタイア削除済アセットのノートとレビューを表示します。図A-44に示すように、「登録」ボタンをクリックして登録プロセスを完了します。登録されたアセットに未承認のタブが含まれる場合があります。タブが承認されると、必ずTabApprovedEventがトリガーされます。このイベントと、タブ名およびその他特定のメタデータが、ワークフローに送られ処理されます。このイベントは、多層ワークフローによって使用されます。この場合、承認されたタブと構成に応じて、承認プロセスの次の層を割り当てる必要があるかどうかがワークフローによって決定されます。ユーザーは、TabApprovedEventイベントを、ChangeAssetLifecycleなどの事前定義済ワークフローにワイヤリングできます。そのため、これはタブ名にも関連付けられます。タブ承認プロセスの完了いくつかのタブはすべてのアセット・タイプに共通ですが、任意のアセットに関するアセット・エディタの特定のタブは、アセットが発行時に割り当てられるタイプ・テンプレートの構成によって決まります。同様に、タブに表示されるメタデータ要素も、タイプ構成によって決まります。特定のタブと要素はタイプによって異なる場合がありますが、どのタブの承認プロセスも、各要素の情報の入力たはレビュー(あるいはその両方)が必要です。タブの「承認」をクリックするたびに、変更の保存を確認するメッセージが表示されます。Stuffリンクをクリックします。Stuffセクションが表示されます。割当済アセットを選択し、タブを承認するアセットを選択します。ページの右下のペインの「編集」ボタンをクリックします。アセット・エディタ・ダイアログが表示されます。承認するタブを選択します。そのタブの情報を確認します。「承認」ボタンをクリックします。変更の保存を促すプロンプトが表示されます。「オプションの選択」ダイアログの「OK」をクリックします。割当済アセット・ページに戻り、リフレッシュして変更内容を確認します。図A-46に示すように、タブ承認ステータス・ペインで、「承認」に1つの項目が表示されます。監査ログ、レビューおよびノートアセットが更新されると、ユーザー、日付およびアクションのレコードが監査ログに表示されます。ログに記録される変更は、次のとおりです。承認タブの完了アセットの「管理」タブにある「ログ」セクションのリストにログ・エントリが追加されます。(「ログ」セクションの「リフレッシュ」ボタンのクリックが必要になる場合があります。)注意:カスタム・データ・フィールドに変更が加えられると、フィールドが変更されたことを示すログが作成されます。その変更の具体的な詳細は空です。「ファイル」メニューの「ノートの追加」をクリックします。図A-47に示すように、「...のノートの追加」ダイアログが表示されます。「...のノートの追加」ダイアログ」の説明テキスト・ボックスに適切な情報を入力します。「OK」をクリックします。アセットの「管理」タブにある「ログ」セクションのリストにノートが追加されます。(「ログ」セクションの「リフレッシュ」ボタンのクリックが必要になる場合があります。Webサービス・エンドポイントを使用した拡張登録フロー機能の使用を素早く開始する方法について説明します。この機能は拡張性が高く、環境に合うように調整できます。Repositoryに埋込みのコンポーネントであり、イベント・サブスクリプション、イベント永続性、イベントのフィルタ処理、およびイベント配信を管理します。Repository内で生成されたイベントはWebサービス・エンドポイントに配信されます。図A-48に、関連する様々なコンポーネントを示します。JMSサーバーの組込みバージョンを使用します。組込みJMSサーバーは、追加構成なしで即時利用可能な状態で実行できるよう構成されています。MQSeriesなどのJavaベースの外部メッセージ・ブローカを使用するようにイベント・マネージャを構成することもできます。Repositoryイベント・マネージャの構成」を参照してください。Repositoryイベント・マネージャの構成のユースケースについて説明します。Managementフローと、デフォルトでイベント・マネージャのサブスクリプション・マネージャに登録されるWebサービス・エンドポイントが用意されています。Managementエンドポイントに配信されます。Repositoryプロセス(アセット登録プロセス、メタデータ変更の追跡、事前に定義されたアクションの実行など)の自動化が試行されます。独自のWebサービス・エンドポイントを記述してイベント・マネージャでサブスクライブし、イベントを固有のビジネス上のニーズに対応させることもできます。Managementのインストールと構成を求められます。Managementが正常にインストールされていることを前提としています。Managementプロセス・エンジンを構成してイベントを処理できるようにする必要があります。Repositoryをインストールすると、プロセス・エンジンをインストールして構成するためのオプションが使用可能になります。この項では、次の手順を実行する前にプロセス・エンジンが正常にインストールされていることを前提としています。Home>\binディレクトリ内のobpmadmcenter.exeファイルをダブルクリックします。Repositoryには、プロセス・エンジンにデプロイされる、事前にバンドルされた自動ワークフローが用意されています。Repositoryプロセス(アセットの発行、受入れ、登録、その他の管理プロセスなど)の自動化を試行する自動ワークフローを実行します。使用可能な自動ワークフローの詳細は、A.6項「自動ワークフローの構成」を参照してください。Managementプロセス・エンジンがインストールされたら、次の手順に従います。ワークフロー構成の生成ツール(config_gen.bat)を使用して、ワークフロー構成ファイル(workflow.xml)を生成します。Repositoryに接続し、カスタマイズ可能なブートストラップ・ファイルを作成します。workflow.xmlファイルの生成の詳細は、A.8.4項「ワークフローの構成」を参照してください。ワークフロー構成ファイル(workflow.xml)を暗号化します。詳細は、第5章「ワークフロー構成ファイル」を参照してください。Edition>/enterprise/server/aler_engineディレクトリにコピーします。任意のXMLエディタを使用してworkflow.xmlファイルを開きます。Repository接続情報(URIやレジストラのユーザー名およびパスワードなど)が次に示すように正しく構成されていることを確認します。</alerconnection>URIには次の形式を使用する必要があります。name>/services/FlashlineRegistryworkflow.xmlファイル内で、次に示すように、アセット・タイプが「Service」であるassetTypeの設定を探します。</allTabs>次に示すように、autoAccept属性を追加し、値をtrueに設定します。Managementプロセス・エンジンが構成されました。Managementプロセス・エンジンが実行されている場合は、これを停止して再起動し、workflow.xmlの最新の変更をロードします。Managementプロセス・エンジンを再起動せずにworkflow.xmlファイルをリフレッシュできます。workflow.xmlファイルのリフレッシュの詳細は、A.8.4.1項「ワークフロー構成ファイルのリフレッシュ」を参照してください。Managementプロセス・エンジンを構成して実行したら、次の手順に従ってアセット発行イベントを処理します。Repositoryのアセット・エディタを起動します。Repositoryユーザーズ・ガイド』を参照してください。図A-31に示すように、「ファイル」→「新規」から新しいアセットを作成します。注意:アセット・タイプは「サービス」にする必要があります。「OK」をクリックし、アセットを発行します。Managementログ・ビューアに切り替えて、イベントが処理されたことを確認します。Home>\binディレクトリ内のobpmlogviewer.exeファイルをダブルクリックします。図A-49に示すように、プロセス・アドミニストレータのプリファレンス設定を使用して、プロセス・エンジンの「ログ」ページで「デバッグ」レベルをオンにします。デフォルトでは、このレベルは「警告」に設定されています。Repository自動ワークフローに関する情報のみでなく、他のプロセス・エンジン情報も含む多くの情報が出力されることがわかります。Repositoryのロギングをフィルタ処理するには、図A-50に示すように、次の手順に従います。ログ・ビューアで、一番左側にあるリスト・ボックス内の「メッセージ」を選択します。横のリスト・ボックスで「次で始まる」を選択します。テキスト・ボックスに「OER」と入力します。「フィルタの適用」ボタンをクリックします。アセットの受入れが完了しました」というメッセージが表示されたら、アセット・エディタに戻り、「表示」→「ツリーのリフレッシュ」コマンドを使用して「管理」タブをリフレッシュします。図A-51に示すように、「承認」セクションが最新のデータで更新されていることを確認します。「管理」タブ」の説明また、図A-52に示すように、「管理」タブの監査ログが更新されていることも確認します。「コミュニティ・フロー」ユースケースコミュニティ・フローは、自動割当てルールの構成を可能にすることによってアセットの受入れ、割当て、登録プロセスを自動化する方法を提供するとともに、様々な機関の間のフェデレーテッド・レジストラに関する概念を示します。すべてのコミュニティにわたって(システム・レジストラ通知を介して)多数のレジストラを送信するかわりに、システム・レジストラの数を1人または2、3人の個人に制限し、コミュニティの管理レジストラのかわりに自動受入れフローでアセットを受け入れるようにすることができます。コミュニティ・フロー機能により、コミュニティのためにアセット発行を承認する権限を持つ個人にアセット発行を分散できます。2つのコミュニティを追加し、各コミュニティについて2つの異なるレジストラを構成できます。次に、作成するプロジェクトまたはアセット・タイプに応じて、特定のアセットをコミュニティに関連付けることができます。コミュニティ・フローでは、レジストラによる手動受入れと同じ方法で、このようなアセットを自動的に受け入れます。reserved.法律上の。