Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド 11g リリース1 (11.1.1.7) E59381-01 |
|
前 |
次 |
この章では、Oracle Enterprise Repository (OER) 11g エクスプレス・ワークフローの設定および構成方法について説明します。
この章には、次のセクションがあります。
この章では、次の概念を十分に理解していると想定します。
アセットおよびアセット・タイプ、アセット発行、アセット登録ステータス、アセット・カテゴリ分け(『Oracle Fusion Middleware Oracle Enterprise Repositoryユーザーズ・ガイド』)
プロジェクトおよびユーザー(『Oracle Fusion Middleware Oracle Enterprise Repository構成ガイド』)
Oracle SOA Suiteアプリケーション・デプロイメント(『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』)
この項で説明するとおり、エクスプレス・ワークフローでは次のものが必要です。
OER PS6 (11.1.1.7)、パッチ17420982適用済
Oracle SOA Suite + Oracle BPM Suite、どちらも11.1.1.7
注意: 専用の管理対象サーバーに、エクスプレス・ワークフローSCAをデプロイできる独自のSOA Suiteを用意することをお薦めします。エクスプレス・ワークフローは、SOA Suiteを管理サーバーにデプロイするSOA Suiteの開発者エディションでは、正しく機能しないことがあります。 |
Oracle Enterprise Repositoryのエクスプレス・ワークフローは、一般的なアセットのライフサイクル承認プロセスを自動化するためのメカニズムです。OERでは、アセットを初期状態から最終状態に移すための一連の機能とオプションを提供しています。エクスプレス・ワークフローでは、OERアセット・エディタで可能なアクションの組合せを組み込むためのアセット承認プロセスが必要です。
アセットの発行
アセットの受入れ
アセット・タブの承認
アセットの登録
AssetLifeCycleStageおよび分類のカテゴリ分けに対する値の変更も必要です。
より複雑なワークフローの自動化を必要とする組織では、『Oracle® Fusion Middleware Oracle Enterprise Repository統合ガイド』のIV部に示すように、Oracle Business Process Management Suiteなどの他のツールを使用して外部ワークフローを開発し、REX APIインタフェースを使用してOERの機能にアクセスできます。
エクスプレス・ワークフローには、次のコンポーネントが組み込まれています。
アセット
プロジェクト
ユーザー
承認フロー
イベントおよびアクション
これらのコンポーネントは、次のように、エクスプレス・ワークフローで関連付けられています。
アセットはリポジトリに発行され、同時にプロジェクトを作成します。エクスプレス・ワークフローでは、アセットが作成するプロジェクトは1つのみである必要があります。
プロジェクトの作成にフローの承認が割り当てられており、アセットのタイプが承認フローで識別される場合、アセットを発行または受け入れると自動的にフローに進みます。プロジェクトで許可される承認フローは1つのみであり、そのプロジェクトに関連するアセットが発行された場合または受け入れられた場合にのみ開始されます。
承認フローはアセット・タブのグループと層で構成されます。それぞれの層には承認者が割り当てられています。アセットは、割り当てられた承認者が層内のタブをすべて承認すると、次の層に移動します。
承認フローには、次のことを決定する設定があります。
アセット発行または受入れの時点でフローを開始するかどうか。
指定のタブが承認されたときにアセットが自動的に登録されるかどうか。
OER管理者は任意の数の承認フローを作成でき、承認フローには任意の数のプロジェクトを割り当てられます。アセットは、アセットが登録されたときにカスタム・アクセス設定をアセットに割り当てる、あるいはアセットのライフサイクル・ステージのカテゴリ分けの値が変更したときにサブスクライバに通知するなど、特定のアクションを個別のイベントにマップして操作します。
エクスプレス・ワークフローは次のコンポーネントに依存しています。
エクスプレス・ワークフローSOAコンポジット・アプリケーション(SCA)
OERイベント・マネージャ
エクスプレス・ワークフロー構成ファイル
ここでは、構成に関連する手順を示します。
OERエクスプレス・ワークフローSOAコンポジット・アプリケーション(SCA)のインストール
デプロイ済SCAへイベントを配信するOERイベント・マネージャの構成
エクスプレス・ワークフローの定義および構成
この項では、Oracle Enterprise Repository WorkflowをOracle BPM 10.3.2にインストールする方法について説明します。内容は次のとおりです。
エクスプレス・ワークフローSOAコンポジット・アプリケーションは、OERイベント・マネージャからそのWebサービス・エンドポイントへのイベント配信をリスニングします。このアプリケーションのインストールには、Oracle SOA Suite 11g R1以降のインスタンスおよびBPM Suiteをインストールしておく必要があります。SOA SuiteおよびBPM Suiteサーバーに追加の構成は必要ありません。
注意: 続行する前に、「soa-infra」→「SOA管理」→「共通プロパティ」のペイロードの検証がfalseに設定されていることを確認します。 |
WebLogic Serverでのエクスプレス・ワークフローSOAコンポジット・アプリケーションのデプロイ
SOA Suite Enterprise Managerコンソールにログインします(通常はhttp://<soaserver_hostname>:<soaserver_port>/emなど)。
左側のメニューから、「SOA」を展開します。
「soa-infra」をクリックします。
「デプロイ済コンポジット」タブを選択します。
「デプロイ…」をクリックします。
「アーカイブの選択」ウィンドウが表示されます。
「アーカイブまたは展開済ディレクトリ」で適切なオプションを選択します。
ExpressWorkflowsパッチで配信されたコンポジットをアップロードします。
「次」をクリックします。
デフォルトのSOAパーティションを選択します。「次」をクリックします。
「デプロイ」をクリックします。
イベント・マネージャはOracle Enterprise Repositoryに埋込みのコンポーネントであり、イベント・サブスクリプション、イベント永続性、イベントのフィルタ処理、およびイベント配信を管理します。
アセットがライフサイクルを進むと、外部アプリケーションが生成されたイベントにサブスクライブします。エクスプレス・ワークフローの場合、Oracle SOA Suiteサーバー・インスタンスにデプロイされたSOAコンポジット・アプリケーションが、OER構成ファイルで定義されたWebサービス・エンドポイントを介してこれらのイベントにアクセスします。OERイベントにアクセスする他のアプリケーションのオプションの詳細は、『Oracle Fusion Middleware Oracle Enterprise Repository構成ガイド』の第9.4章を参照してください。
エクスプレス・ワークフローは次のイベントをサポートしています。
アセットの発行
アセット未発行
アセット受入れ
アセット受入れ不可
アセット・タブの承認: 値=<tab name>
すべてのアセット・タブの承認
アセット登録済
アセット登録解除
アセット・ステータス変更: 値="DELETED/INACTIVE/RETIRED
ポリシー・アサーション変更: 値="pass/fail"
カテゴリ分け変更:AssetLifecycleStage (どの変更にも有効)
カテゴリ分け変更:AssetLifecycleStage: 値="stage name"
カテゴリ分け変更:Classification (どの変更にも有効)
カテゴリ分け変更:Classification: 値="stage name"
イベント・マネージャは構成ファイルを使用して、イベントを配信するWebサービスのエンドポイントに関する情報をロードします。このファイルはOERのインストール、<oer webapp name>\WEB-INF\classes\EndPointEventSubscription.xmlにあります。
例: C:\ofm_wls1036\user_projects\applications\oer_domain\applications\oer_11.1.1.7.0\oer-app\WEB-INF\classes\ EndPointEventSubscription.xml
このファイルで、イベントを受け取るようにSCAエンドポイントを追加するには、次の例に示すように、に<sub:eventSubscription>要素の新規インスタンスを作成します。
このファイルでは、前述の例1に示すように、エクスプレス・ワークフローSOAコンポジット・エンドポイントのホスト、ポート、ユーザー名、およびパスワードを手動で構成する必要があります。その他のタグにあるコメントは、内容の概略を示します。前述の例は、サンプル・ファイル<OERHome>\repository111\core\express-workflows-config\EndPointEventSubscription.xmlのエクスプレス・ワークフローパッチにあります。
注意: パスワードはOERで提供される2つの暗号化ツールのいずれかを使用して暗号化する必要があります。『Oracle Fusion Middleware Oracle Enterprise Repository構成ガイド』の暗号化パスワードの生成に関する項を参照してください。 |
このファイルの変更は、次にイベント・マネージャを有効化した後にOERを停止し、再起動するまで反映されません。イベント・マネージャが有効化されている場合は、この時点でOERサーバーを再起動できます。
イベント・マネージャの構成が完了したら、Oracle Enterprise Repositoryでイベント・マネージャを有効化して、外部Webサービスのエンドポイントへのイベント送信を許可する必要があります。
Oracle Enterprise Repositoryの「管理」画面のサイドバーで「システム設定」をクリックします。
「システム設定」の「検索」に「event」と入力して、イベント・マネージャ関連の設定をすべて表示します。
「イベント・マネージャの有効化」プロパティcmee.eventframework.enabledの横にある「True」をクリックします。
「保存」をクリックします。
Oracle Enterprise Repositoryを再起動して構成の変更内容を反映します。
エクスプレス・ワークフローコンポーネントとそのリレーションシップはXMLファイルで定義および構成され、OERイベントがアプリケーションのWebサービス・エンドポイントに配信される場合は常にこのファイルがエクスプレス・ワークフローSOAコンポジット・アプリケーションで読み込まれます。
このファイルのサンプル・バージョン(およびそのXSD)は、構成手順が完了したときに実行する事前構成のサンプル・ワークフローとともに提供されます。OERのインストールでは、このサンプル・ファイルは<OERHome>\repository111\core\express-workflows-config\expressWorkflow.xmlにあります。
このXMLの各種要素の詳細な説明は、「サンプル・ワークフローの変更」の項に記載されています。ここではファイルを構成し、サンプル・ワークフローを有効化します。
構成ファイルの設定およびサンプル・ワークフローの有効化
アセット・エディタを起動し、アセットを編集し、タブを承認するアクセス権限を持つOERユーザーを新規に作成します。『Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド』のユーザー、ロール、および基本アクセス権限の設定に関する項を参照してください。
元のサンプルExpressWorkflow.xmlを新しいファイル名で保存します。
ExpressWorkflow.xmlの編集: <oerConnection>タグ内でOERサーバーのホスト: ポートと管理ユーザーのクリア・テキストのパスワードを入力します。
<oerConnection> <uri>http://[OERHOST:PORT]/oer/services/FlashlineRegistry</uri> <registrar> <username>admin</username> <password>[your admin password]</password> </registrar>
新規OERユーザーのユーザー名を第2層の承認者として入力します。
<approvalFlow name="Flow1" acceptOnAssetSubmission="true" registerOnFlowCompletion="true"> <tiers> <tier name="Tier1"> <approvers> <oeruser> <username>admin</username> </oeruser> </approvers> <tabs> <tab name="Overview"/> <tab name="Technical"/> <tab name="Documentation"/> </tabs> </tier> <tier name="Tier2"> <approvers> <oeruser> <username>[Your New Username]</username> </oeruser> </approvers> <tabs> <tab name="Taxonomy"/> </tabs> </tier>
『Oracle® Fusion Middleware Oracle Enterprise Repository構成ガイド』の暗号化パスワードの生成に関する項にあるとおり、ファイル内でパスワードを暗号化します。
ファイルを保存します。
OERサーバーが実行されていることを確認し、エクスプレス・ワークフロー検証スクリプト(<OERHome>\repository111\core\express-workflows-config\validateWorkflow.sh)を実行してexpressWorkflow.xmlファイルを確認します。
validateWorkflow.sh -settings [使用中のexpressWorkflow.xmlファイル]
次のように、Oracle SOA Suiteドメインにoerconfigと呼ばれる新規フォルダを作成します。
<SOAHome>\user_projects\domains\<SOAdomain>\oerconfig
検証したファイルをExpressWorkflow.xmlという名前でoerconfigフォルダにコピーします。
この時点でサンプルが有効化され、エクスプレス・ワークフローの設定および構成が完了しました。これで次の項に進み、サンプルを実行できます。
OERサーバーおよびSOAサーバーの実行中に、リポジトリに「サービス」タイプの新規アセットを作成します。
アセットの新規作成
管理者またはアセット作成の権限を持つユーザーとしてOERにログインします。
アセット・エディタで「ファイル」→「新規」を選択します。
「アセットの新規作成」ダイアログでアセット名を入力します。
「サービス」タイプと初期状態の未発行を選択します。
「OK」をクリックします。新しいアセット・タブが表示されます。
「概要」タブでプロジェクトの作成の共通プロジェクトを選択します。「保存」をクリックします。
サンプルの実行
管理ユーザーとしてOERにログインします。
My Stuffに進むと、新しく作成し、発行されたアセットがキューに表示されます。
アセット・エディタを開き、「概要」、「技術的」、および「ドキュメント」のタブを承認します。アセット・エディタを終了します。
ログアウトし、新たに作成したユーザーとしてOERに再度ログインします。
My Stuffに進み、「サービス」アセットを検索して編集し、分類タブを承認します。アセット・エディタを終了します。
OERコンソールで「登録ステータス」が「登録済」になっているサービス・アセットを名前で検索します。
検索結果に次のアセットが表示されます。
サンプル・ワークフローの実行が完了したら、次のようにこれを変更するか、新たにワークフローを作成することができます。
インストール済のExpressWorkflow.xmlを新しい場所にコピーし、これを編集して新規プロジェクト、ユーザー、アセット・タイプ、イベント/アクションのマッピング、および承認フローを追加します。
検証スクリプトを実行して、変更内容が実行中のOERインスタンスに対応していることを確認します。
インストール済のExpressWorkflow.xmlファイルを新しいバージョンと置き換えます。
注意: エクスプレス・ワークフローSOAコンポジットでは、OERイベント・マネージャからイベントを受け取るたびにインストール済ファイルを読み取るため、新たにインストールしたExpressWorkflow.xmlバージョンの変更内容はすぐに反映され、再起動は必要ありません。 |
ExpressWorkflow.xmlファイルは、次を実行できるように変更しました。
OERサーバー・インスタンスの識別
OER管理ユーザーの暗号化パスワードを提供
承認フローFlow1内アセット・タブの第2層の承認者名の変更
ここでは、共通プロジェクトを作成するためのデフォルトのExpressWorkflow.xmlファイルの一部を示します。
<producingProject name="Common Project" approvalFlow="Flow1"/> <assetTypes> <assetType name="Business Process"/> <assetType name="Composite"/> <assetType name="Service"/> </assetTypes> </producingProject>
名前は既存のOERプロジェクトを示します。検証スクリプトにより、指定したプロジェクトがOERインスタンスにない場合はエラーが生成されます。
approvalFlowはオプションの属性であり、このプロジェクト内に作成したアセットの階層化したタブの承認、またはガバナンス・フローを指定します。作成するプロジェクトには、approvalFlowが1つ含まれるか、あるいはまったく含まれません。
assetTypeは既存のタイプを示します。プロジェクトの作成で発行した指定タイプのアセットはすべて、プロジェクトに指定したapprovalFlowおよびそのアセット・タイプに指定したイベント/アクションのマッピングに従います。
注意: アセットはExpressWorkflow.xmlファイルで作成するプロジェクトが1つのみ指定されている場合、ExpressWorkflowで管理されます。 |
エクスプレス・ワークフロー承認フローでは、ガバナンス・プロセスの間にアセット・タブが承認されるように、指定したアセットの動作を決定します。ここでは、変更したExpressWorkflow.xmlの一部を示します。
<approvalFlow name="Flow1" acceptOnAssetSubmission="true" registerOnFlowCompletion="true"> <tiers> <tier name="Tier1"> <approvers> <oeruser> <username>admin</username> </oeruser> </approvers> <tabs> <tab name="Overview"/> <tab name="Technical"/> <tab name="Documentation"/> </tabs> </tier> <tier name="Tier2"> <approvers> <oeruser> <username>[Your New Username]</username> </oeruser> </approvers> <tabs> <tab name="Taxonomy"/> </tabs> </tier>
名前はフローを識別し、producingProjectのapprovalFlow属性で使用されます。この属性はexpressWorkflow.xmlファイル以外では使用されません。
acceptOnAssetSubmissionは、指定したアセットが発行のときに自動的に受け入れられる(値=「true」)、または十分なアクセス権のあるOERユーザーによって手動で受け入れられる(値=「false」)かを決定するオプションの属性です。この属性が指定されていない場合、デフォルト値は「false」です。
registerOnFlowCompletionは、承認フローで指定したすべてのタグが承認済(値=「true」)のとき、指定したアセットを自動的に登録するかどうかを決定するオプションの属性です。この属性が指定されていない場合、デフォルト値は「false」です。
層名はアセット・タブの組合せを示します。
層の承認者とは、最初に指定した層でアセットを受け入れたとき、または前の層のすべてのタブを承認したときに、アセットが割り当てられる既存のOERユーザーを示します。
層のタブ名は、特定の層で承認される、指定したアセット・タイプに固有のアセット・タブを示します。
イベント/アクション間のマッピングは、アセットの自動受入および登録のための承認フローを指定するための、代替の方法を提供します。これらのマッピングは、指定したアセット・タイプにのみ適用されます。1つのプロジェクト内の複数のアセット・タイプについて、異なる(または同一の)マッピングが可能です。
エクスプレス・ワークフローは、イベント・マネージャで生成される多数のアセット・ライフサイクル・イベントを識別し、これらのイベントを特定のアセットの特定のアクションに関連付けるメカニズムを提供しています。サポートされるイベントとアクションの完全なリストは、ExpressWorkflow.xmlファイルに必要な次の構文に含まれています。
次のプロジェクトの作成のサンプルを調査します。
<producingProject name="Project1"/> <assetTypes> <assetType name="Service"> <events> <event name="urn:com:bea:aler:events:type:AssetSubmission"> <actions> <action name="AcceptAsset" /> </actions> </event> <event name="urn:com:bea:aler:events:type:AssetTabApproved"> <actions> <action name="RegisterAsset" /> <tabs> <tab name="Management Review" /> </tabs> </action> </actions> </event> </events> </assetType> </assetTypes> </producingProject>
前述の例では、Project1に承認フローが指定されていません。ただし、assetType「サービス」ではイベント/アクション間のマッピングを指定しています。最初のマッピングで、「サービス」タイプのアセットが発行時に自動的に受け入れられます。2つ目は、管理レビュー・タグが承認されるとアセットが登録されます。
次の例では、expressWorkflow.xmlファイルのデフォルトから「サービス」タイプのアセットを承認フローのFlow1で登録するとき、カスタム・アクセス設定をそのタイプのアセットに自動的に適用します。
<producingProject name="Project2" approvalFlow="Flow1"/> <assetType name="Service"> <event name="urn:com:bea:aler:events:type:AssetRegistered"> <action>ChangeCAS</action> <customAccessSettings> <customAccessSetting>[YourSetting]<customAccessSetting/> </customAccessSettings> <assetLifecycle/> </event> </assetType> </producingProject>
カスタム・アクセス設定はガバナンス・コミュニティ内でアセットの可視性の制御に使用されるため、この例の設定は、承認プロセスの完了後に潜在的なコンシューマに対してアセットを公開することに多く使用されます。
一般的に、プロジェクトの作成では承認フローの指定、または特定のアセット・タイプのイベント/アクション間のマッピングの指定、あるいはその両方が可能です。ただし、両方を使用する場合は、承認フローの層で承認のためにタブを指定するとき、およびイベント/アクション間のマッピングで「承認」タブを指定するときに重複やルールの複雑化を避けるよう注意する必要があります。
エクスプレス・ワークフローでサポートされているイベントとアクションのリストを次に示します。
サポートされているイベント
urn:com:bea:aler:events:type:AssetSubmission
urn:com:bea:aler:events:type:AssetUnSubmission
urn:com:bea:aler:events:type:AssetAccepted
urn:com:bea:aler:events:type:AssetUnAccept
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:AssetUnregister
urn:com:bea:aler:events:type:PolicyAssertionChanged
urn:com:bea:aler:events:type:CategorizationChanged:assetLifecycleStage
urn:com:bea:aler:events:type:CategorizationChanged:classification
サポートされるアクション
ChangeCAS: アセットへの1つ以上のカスタム・アクセス設定に適用されます。
ChangeAssetLifecycle: アセットのアセット・ライフサイクル・ステージを設定します。
ChangeClassification: アセットの分類を設定します。
ReAssignAssetToRegistrar: アセットをレジストラに割り当てます。
NotifySubscriber: メタデータ変更をサブスクライバに通知します。
ApproveTab: 1つ以上のタブを承認します。
UnapproveTab: 1つ以上のタブを承認しません。
AcceptAsset: アセットを受け入れます。
UnacceptAsset: アセットを受入れ不可にします。
RegisterAsset: アセットが登録済の状態の場合にアセットを登録解除します。
UnRegisterAsset: アセットが登録済の状態の場合にアセットの登録を解除します。
PublishAssetToUddi: 個々のサービスが登録されるとき、またはサービスのライフサイクルが変更されるときにトリガーされるイベントをワイヤリングして、これらのサービスとそのメタデータをOracle Service Registryに移動します。