| Oracle® Fusion Middleware Oracle Enterprise Repository管理者ガイド 12c リリース 1 (12.1.3) E59479-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Enterprise Repository管理者ガイド 12c リリース 1 (12.1.3) E59479-02 |
|
前 |
次 |
この章では、Oracle Enterprise Repository (OER)エクスプレス・ワークフローを設定および構成する方法について説明します。
この章の内容は、次の概念をよく理解していることを前提としています。
アセットとアセット・タイプ、アセット発行、アセット登録ステータス、アセット・カテゴリ分け。詳細は、『Oracle Fusion Middleware Oracle Enterprise Repositoryコンセプト・ガイド』を参照してください。
プロジェクトおよびユーザー。詳細は、第1章「基本構成」を参照してください。
Oracle SOA Suiteアプリケーションのデプロイメント。詳細は、Oracle Fusion Middleware Oracle SOA Suite開発者ガイドを参照してください。
|
注意: Oracle BPM Suiteの使用制限付きライセンスがOERに含まれています。このライセンスにより、OERで提供される既存のワークフローを変更できます。このライセンスを使用すると、新しいOER中心のワークフローを作成することもできます。OERを含まないワークフローを作成する場合、Oracle BPM Suiteの完全なライセンスを入手してください。 |
この章には、次のセクションがあります。
この項で説明するエクスプレス・ワークフローを使用するには、Oracle SOA SuiteおよびOracle BPM Suite (どちらもバージョン11.1.1.7以上)が必要です。
|
注意: エクスプレス・ワークフローSCAがデプロイされるSOA Suiteは独自の管理対象サーバーに配置することをお薦めします。エクスプレス・ワークフローは、SOA Suiteを管理サーバーにデプロイするSOA Suite Developer Editionでは正しく機能しない可能性があります。 |
Oracle Enterprise Repositoryのエクスプレス・ワークフローは、共通のアセット・ライフサイクル承認プロセスを自動化するためのメカニズムです。OERには、アセットを初期状態から最終状態まで移行するための一連の機能およびオプションが用意されています。エクスプレス・ワークフローでは、OERアセット・エディタによって提供される次のアクションの組合せを組み込むために、アセット承認プロセスを必要とします。
アセット発行
アセット受入れ
アセット・タブの承認
アセット登録
カテゴリ分けAssetLifeCycleStageおよびClassificationの値の変更も必要です。
より複雑なワークフロー自動化を必要とする組織は、他のツール(Oracle Business Process Management Suiteなど)を使用して外部ワークフローを開発し、REX APIインタフェース(『Oracle Fusion Middleware Oracle Enterprise Repository開発者ガイド』のRepository Extensibility Frameworkの使用に関する項を参照)を使用してOER機能にアクセスすることもできます。
エクスプレス・ワークフローのコンポーネントは次のとおりです。
アセット
プロジェクト
ユーザー
承認フロー
イベントおよびアクション
これらのコンポーネントは、エクスプレス・ワークフローによって次のように関連付けられています。
アセットは作成するプロジェクトとともにリポジトリに発行されます。エクスプレス・ワークフローでは、アセットが持つ作成するプロジェクトは1つのみであることが必要です。
指定された作成するプロジェクトに承認フローが割り当てられており、その承認フローに対してアセット・タイプが指定されている場合、アセットはその発行時または受入れ時に自動的にフローに入ります。プロジェクトには1つの承認フローを割り当てることができ、そのフローは該当するプロジェクト内の関連アセットが発行されるか、受け入れられた場合にのみ開始されます。
承認フローは、アセット・タブのグループ、つまり層で構成されます。層ごとに担当承認者がいます。担当承認者が層内のすべてのタブを承認した場合、アセットは次の層に移ります。
承認フローの設定により次のことが決定されます。
フローをアセット発行時またはアセット受入れ時に開始するかどうか。
指定したタブが承認されたときにアセットを自動的に登録するかどうか。
OER管理者は任意の数の承認フローを作成でき、1つの承認フローを任意の数のプロジェクトに割り当てることができます。アセットは、アセットが登録されたときにカスタム・アクセス設定を適用したり、アセット・ライフサイクル・ステージのカテゴリ分けの値が変更されたときにサブスクライバに通知するなど、個別のイベントに特定のアクションをマップすることによって操作します。
エクスプレス・ワークフローは次のコンポーネントに依存します。
エクスプレス・ワークフローSOAコンポジット・アプリケーション(SCA)
OER Event Manager
エクスプレス・ワークフロー構成ファイル
エクスプレス・ワークフローを構成するには、次の手順を実行します。
OER Express Workflow SOAコンポジット・アプリケーション(SCA)をインストールします。
デプロイしたSCAにイベントを配信するようにOER Event Managerを構成します。
エクスプレス・ワークフローを定義および構成します。
この項では、Oracle Enterprise RepositoryワークフローをOracle BPM 11gおよび12cにインストールする方法について説明します。内容は次のとおりです。
エクスプレス・ワークフローSOAコンポジット・アプリケーションでは、OER Event ManagerからWebサービス・エンドポイントに配信されるイベントをリスニングします。このアプリケーションをインストールするには、インストール済のOracle SOA SuiteおよびOracle BPM Suiteインスタンス(どちらもバージョン11.1.1.7以上)が必要です。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のzipファイルに含まれているコンポジットをアップロードします。
<FMW_Home>/oer/modules/tools/solutions/ディレクトリに移動します。
12.1.3.0.0-ExpressWorkflows.zipファイルを展開します。
sca_OERWorkflows_rev1.0.jarファイルを選択します。
「次」をクリックします。
デフォルトのSOAパーティションを選択します。「次」をクリックします。
「デプロイ」をクリックします。
Event Managerは、イベント・サブスクリプション、イベント永続性、イベント・フィルタ処理およびイベント配信の管理用としてOracle Enterprise Repository内に組み込まれているコンポーネントです。
外部アプリケーションは、アセットのライフサイクル内を移動するときに生成されるイベントをサブスクライブします。エクスプレス・ワークフローにおいてOracle SOA Suiteサーバー・インスタンスにデプロイされたSOAコンポジット・アプリケーションは、OER構成ファイルに定義されているWebサービス・エンドポイントを介してこれらのイベントにアクセスします。
エクスプレス・ワークフローでは次のイベントがサポートされています。
アセット発行
アセット未発行
アセット受入れ
アセット受入れ不可
アセット・タブの承認: 値=<tab name>
すべてのアセット・タブの承認
アセット登録
アセット未登録
アセット・ステータスの変更: 値="DELETED/INACTIVE/RETIRED"
ポリシー・アサーションの変更: 値="pass/fail"
カテゴリ分けの変更: AssetLifecycleStage (すべての変更に影響を与える)
カテゴリ分けの変更: AssetLifecycleStage: 値="stage name"
カテゴリ分けの変更: Classification (すべての変更に影響を与える)
カテゴリ分けの変更: Classification: 値="stage name"
Event Managerは、構成ファイルを使用して、イベントが配信されるWebサービス・エンドポイントに関する情報をロードします。このファイルは、<FMW_HOME>oer/modules/tools/solutionsにあるExpressWorkflows.zipファイルに含まれています。ExpressWorkflows.zipからEndPointEventSubscription.xmlファイルを抽出し、適宜変更した後で<FMW_HOME>/oer/applications/oer/oer-app/WEB-INF/classesディレクトリに貼り付ける必要があります。
このファイルで、イベントを受け取るSCAエンドポイントを追加するには、次の例に示すように、<sub:eventSubscription>要素の新規インスタンスを作成します。
<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="SOACompositeEndpoint">
<!--The host of the SOA Server hosting the composite -->
<sub:host>localhost</sub:host>
<!--The SOA Server listener port -->
<sub:port>9000</sub:port>
<!--The URI of the deployed composite -->
<sub:uri>soa-infra/services/default/OERWorkflows/HandleStatusChange.service</sub:uri>
<!--Unless a custom WSDL Contract is used, the namespace 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\eventNotifier.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 SOA Suite server. Use HTTPS if SSL-enabled -->
<sub:protocol>HTTP</sub:protocol>
<!--The user and password to authenticate the composite deployed on the SOA Suite server. -->
<sub:authenticationData>
<sub:basicAuthentication>
<sub:username>oer_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>
このファイルで、上の例に示すように、エクスプレス・ワークフローSOAコンポジット・エンドポイントのホスト、ポート、ユーザー名およびパスワードを手動で構成する必要があります。上の例は、<FMW_HOME>oer/modules/tools/solutionsディレクトリにある12.1.3.0.0-ExpressWorkflows.zipファイル内のEndPointEventSubscription.xmlから引用したものです。
このファイルに対する変更を有効にするには、OER管理対象サーバーを停止してから再起動する必要があります。この作業は、次にEvent Managerを有効にした後で行います。Event Managerがすでに有効になっている場合は、OERを今すぐ再起動できます。
Event Managerの構成が完了したら、Oracle Enterprise RepositoryでEvent Managerを有効にして、外部Webサービス・エンドポイントにイベントが送信されるようにする必要があります。
Oracle Enterprise Repositoryの「管理」画面のサイドバーにある「システム設定」をクリックします。
システム設定検索にeventと入力して、Event Managerに関連するすべての設定を表示します。
Event Managerの有効化プロパティcmee.eventframework.enabledの横にある「True」をクリックします。
「保存」をクリックします。
Oracle Enterprise Repositoryを再起動して構成の変更を有効にします。
エクスプレス・ワークフローのコンポーネントとそのリレーションシップはXMLファイルで定義および構成されており、OERイベントがエクスプレス・ワークフローSOAコンポジット・アプリケーションのWebサービス・エンドポイントに配信されるたびに、そのアプリケーションによって読み取られます。
このファイル(およびそのXSD)のサンプル・バージョンが、構成手順の完了時に実行されるよう事前定義されたサンプル・ワークフローに付属しています。このサンプル・ファイルは<FMW_HOME>/oer/modules/tools/solutions/12.1.3.0.0-ExpressWorkflows.zipにあります。
このXMLの各種要素の詳細は、13.4項「サンプル・ワークフローの変更」を参照してください。
構成ファイルの設定およびサンプル・ワークフローの有効化
アセット・エディタの起動、アセットの編集およびタブの承認に必要な各権限を持つ新規OERユーザーを作成します。ユーザー、ロールおよび基本アクセス設定の詳細は、第1章「基本構成」を参照してください。
元のサンプル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>
Tier2の承認者として新規OERユーザーのユーザー名を入力します。
<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>
第12章「パスワードの暗号化」の説明に従って、ファイル内のパスワードを暗号化します。
ファイルを保存します。
OERサーバーが稼働中であることを確認してから、<FMW_Home>/oer/modules/tools/solutions/12.1.3.0.0-ExpressWorkflows.zipに含まれているエクスプレス・ワークフロー検証スクリプトを実行してexpressWorkflow.xmlファイルをチェックします。
validateWorkflow.sh -settings [your expressWorkflow.xml file]
次に示すように、Oracle SOA Suiteドメイン内にoerconfigという新規フォルダを作成します。
<FMW_Home>\user_projects\domains\<SOAdomain>\oerconfig
検証後のファイルをExpressWorkflow.xmlという名前でoerconfigフォルダにコピーします。
これで、有効にしたサンプルを使用するエクスプレス・ワークフローの設定および構成が終了しました。13.3項に進み、サンプルを実行することができます。
OERおよびSOAサーバーが稼働している状態で、「サービス」タイプの新規アセットをリポジトリに作成します。
新規アセットの作成
adminユーザーまたはアセット作成権限を持つ任意のユーザーとしてOERにログインします。
アセット・エディタで、「ファイル」メニューから「新規」を選択します。
アセットの新規作成フィールドにアセット名を入力します。
タイプとして「サービス」、初期状態として未発行を選択します。
「OK」をクリックします。新規アセット・タブが表示されます。
「概要」タブで、作成するプロジェクトの共通プロジェクトを選択します。「保存」をクリックします。
サンプルの実行
管理ユーザーとしてOERにログインします。
My Stuffに移動し、新規に作成および発行したアセットがキューに含まれていることを確認します。
アセット・エディタを開き、「概要」、「技術的」および「ドキュメント」の各タブを承認します。アセット・エディタを終了します。
OERからログアウトし、再びログインします。
My Stuffに移動し、サービス・アセットを検索および編集して分類タブを承認します。アセット・エディタを終了します。
OERコンソールで、登録ステータスが「登録済」に設定されたサービス・アセットを名前で検索します。
検索結果にアセットが表示されます。
サンプル・ワークフローを正常に実行できた場合、次の手順に従ってそのワークフローを変更したり、新規ワークフローを作成できます。
インストール済のExpressWorkflow.xmlを新しい場所にコピーし、それを編集して新規プロジェクト、ユーザー、アセット・タイプ、イベントとアクションのマッピングおよび承認フローを追加します。
検証スクリプトを実行して、変更した内容が稼働中のOERインスタンスと互換性があるかどうかを確認します。
インストール済のExpressWorkflow.xmlファイルを新規バージョンに置き換えます。
|
注意: OER Event Managerからエクスプレス・ワークフローSOAコンポジットにイベントが配信されるたびに、インストール済のファイルが読み取られるため、新規にインストールした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>
nameは、既存のOERプロジェクトを表します。指定したプロジェクトがOERインスタンスに存在しない場合は、検証スクリプトによりエラーが生成されます。
approvalFlowは、このプロジェクト内に作成されたアセットを対象として、階層化されたタブの承認フロー(つまり、ガバナンス・フロー)を指定するオプション属性です。作成するプロジェクトにはapprovalFlowを1つ割り当てるか、何も割り当てないかのいずれかです。
assetTypeは、既存のタイプを表します。作成するプロジェクト内で発行された特定タイプのアセットは、プロジェクトに指定されたapprovalFlowおよびそのアセット・タイプに指定されたイベントとアクションのマッピングに必ず従います。
|
注意: アセットに対してExpressWorkflow.xmlファイルで作成するプロジェクトが1つのみ指定されている場合にかぎり、エクスプレス・ワークフローでアセットを管理できます。 |
エクスプレス・ワークフローの承認フローは、ガバナンス・プロセスでアセット・タブが承認されたときの該当アセットの動作を決めるものです。次に、以前に変更した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>
approvalFlow nameは、フロー名を表し、producingProjectのapprovalFlow属性で使用されます。この属性はexpressWorkflow.xmlファイル以外では使用されません。
acceptOnAssetSubmissionは、指定したアセットがその発行時に自動的に受け入れられるようにするか(値="true")、または十分なアクセス権限を持つOERユーザーが手動で受け入れるようにするか(値="false")を決めるオプション属性です。この属性を指定しなかった場合、デフォルト値として"false"が使用されます。
registerOnFlowCompletionは、承認フローに指定されたすべてのタブが承認されたときに、指定したアセットが自動的に登録されるようにする(value="true")かどうかを決めるオプション属性です。この属性を指定しなかった場合、デフォルト値として"false"が使用されます。
<tier>要素内のtier nameは、アセット・タブの組合せを表します。
<tier>要素内のapproverは、最初に指定した層でアセットが受け入れられるか、前の層のすべてのタブが承認されるかのいずれかの時点でアセットが割り当てられる既存のOERユーザーを表します。
<tier>要素内のtab nameは、指定したアセット・タイプに存在する必要があり、特定の層内で承認される特定のアセット・タブを表します。
イベントとアクションのマッピングは、アセットを自動的に受け入れて登録する場合に承認フローのかわりに使用できる方法です。これらのマッピングは指定したアセット・タイプにのみ適用されます。プロジェクト内の各種アセット・タイプにそれぞれ異なるマッピングを使用することも、同じマッピングを使用することもできます。
エクスプレス・ワークフローには、Event Managerによって生成される多数のアセット・ライフサイクル・イベントを認識し、これらのイベントを特定のアセットに対する特定のアクションに関連付けるためのメカニズムがあります。ExpressWorkflow.xmlファイルに必要な構文でサポートされているイベントとアクションの完全なリストについては後述しています。
次のサンプルproducingProject要素について考えます。
<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に承認フローは指定されていません。ただし、「サービス」タイプのアセットに対してイベントとアクションのマッピングが指定されています。1つ目のマッピングにより、「サービス」タイプのアセットはその発行時に自動的に受け入れられます。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に移動します。
