Advanced Registration Flow のコンフィグレーションと管理

Advanced Registration Flow のコンフィグレーション

この節では、以下の内容に関する情報を取り上げます。

Advanced Registration Flow の概要

Oracle Enterprise Repository には、Oracle Enterprise Repository のアセットの送信、受け入れ、登録、およびその他の管理プロセスの自動化を試行するビルド済みの Oracle Business Process Management フローがバンドルされています。この節では、Oracle Business Process Management Process Engine を起動して、Oracle Enterprise Repository でトリガされるアセット イベントを処理する前に行う必要のあるコンフィグレーションについて説明します。フローをトリガするための Process Engine のコンフィグレーションの詳細については、「Oracle Enterprise Repository Event Manager のコンフィグレーション」を参照してください。

このフローの設計には柔軟性があり、ワークフロー コンフィグレーション ファイル (workflow.xml) または Oracle Business Process Management を使用してカスタマイズできます。この節では、それぞれのフローについても詳しく説明しており、使用環境に合わせた調整の例を挙げています。

この章では、Advanced Registration Flow のコンフィグレーションの方法について説明します。新しいワークフローを作成するには、次の手順に従います。

ワークフロー コンフィグレーション ファイルの作成とカスタマイズ

この節では、ワークフロー コンフィグレーション XML ファイルを作成およびカスタマイズする方法について説明します。

ワークフロー コンフィグレーション ファイルの生成

Generate Workflow Config ツール (config_gen.bat) を使用して workflow.xml ファイルを生成します。このツールは、Oracle Enterprise Repository に接続し、カスタマイズ可能なブートストラップ ファイルを作成します。workflow.xml ファイルの生成の詳細については、「ワークフロー コンフィグレーション ファイルの生成」を参照してください。

Oracle Enterprise Repository の接続とレジストラの定義

ワークフロー コンフィグレーション ファイルによって、Oracle Enterprise Repository の接続とレジストラの情報が次の XML データからロードされます。

<alerconnection>
  <uri>http://localhost.7001/aler/services/FlashlineRegistry</uri>
  <registrar>
    <user>admin</user>
    <password>n0pa55w0rd</password>
  </registrar>
</alerconnection>

レジストラ ユーザのパスワードの暗号化

Security Encrypt Password ツール (runWfSecurity.bat) を使用すると、ワークフロー コンフィグレーション ファイルに格納されているレジストラのパスワードを暗号化できます。このツールは、ファイルを繰り返しスキャンし、見つかったすべてのパスワード要素を暗号化します。

詳細については、「パスワードの暗号化」を参照してください。

フローへのアセット イベントの関連付け

図 5-1 に示すように、Advanced Registration Flow は、アセット イベントがトリガされると実行される 1 つまたは複数のフローにイベントを関連付けることのできる柔軟性の高いフレームワークで設計されています。

フローへのアセット イベントの関連付けは、ワークフロー コンフィグレーション ファイル内でコンフィグレーションされます。たとえば、次のコンフィグレーション コードは、「Asset Submitted (アセットの送信完了)」イベントがトリガされると、ワークフロー コンフィグレーション ファイルでコンフィグレーションされているルールに基づいてアセットを自動的に受け入れるフローをそのイベントがトリガすることを示しています。

  <!--コミュニティ フロー-->
  <state name="urn:com:bea:aler:events:type:AssetSubmission">
    <action>CommunityAccept</action> 
  </state>

  <!--多層フロー-->
  <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>

  <!--アセット登録状態フロー-->
  <state name="urn:com:bea:aler:events:type:AssetAllTabApproved">
    <action>AllTabApproved_Register</action> 
  </state>

このサンプル コンフィグレーションでは、以下のイベントがそれぞれのフローに関連付けられます。<action> 要素には、実行されるフローの名前が記述されます。

一部のフローでは、入力パラメータを使用します。個別のフローに渡されるパラメータはそれぞれ異なります。たとえば、ChangeCAS (カスタム アクセス設定の変更) フローでは、パラメータとして <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 Asset Editor で行う手動のアセットの受け入れと登録のプロセスを Advanced Registration Flow で自動化する方法について説明します。Oracle Enterprise Repository Asset Editor を使用する方法とアセット登録プロセスについては、『Oracle Enterprise Repository Registrar Guide』を参照してください。

コミュニティ フローのコンフィグレーション

コミュニティ フローは、自動割り当てルールのコンフィグレーションを許可することによってアセットの受け入れ、割り当て、および登録のプロセスを自動化する方法を提供し、さまざまな権限間の「フェデレーション レジストラ」の概念を導入します。システム レジストラ通知を使用してすべてのコミュニティに多数のレジストラを送信するのではなく、システム レジストラを 1 つまたはいくつかのコミュニティに制限し、コミュニティのレジストラの代わりに自動受け入れフローによってアセットの受け入れを行うことができます。コミュニティ フロー機能では、コミュニティのアセットの送信を承認する権限を持つコミュニティにアセットの送信を配布できます。

コミュニティ フローは、以下のシナリオで使用できます。

コミュニティはフロー コンフィグレーション内でコンフィグレーションされ、アセットの種類や生成プロジェクトなどはコミュニティを参照することができます。

図 5-2 は、アセット用のコミュニティをフローによって配置する方法と、自動受け入れのルールをフローによって配置する方法を示しています。

Oracle Enterprise Repository プロジェクト用のコミュニティの設定

<producingProjectSettings> 要素を使用して、プロジェクト用のコミュニティを定義します。次の例は、「SOA Center of Excellence」コミュニティの「Registry」という名前のプロジェクト (ID は 40000) の作成を示しています。

<producingProjectSettings>
   <producingProject name=”Registry” community=”SOA Center of Excellence
   id=”40000”/>
</producingProjectSettings>

アセットの種類用のコミュニティの設定

<assetType> 要素を使用して、アセットの種類用のコミュニティを定義します。次の例は、「SOA Center of Excellence」コミュニティの「Application」という名前のアセットの種類 (ID は 158) の作成を示しています。

  <assetType name=”Application” community=”SOA Center of Excellence
  id=”158”>
    <allTabs>

Type Manager と Asset Editor を使用したアセット用のコミュニティの設定

workflow.xml でアセット用のコミュニティを設定する代わりに、Type Manager と Asset Editor を使用して、アセットの種類用のコミュニティを設定することができます。

Type Manager の場合は、次の手順に従います。

次に、Asset Editor の場合は、次の手順に従います。

「アセットの種類用のコミュニティの設定」のコミュニティの設定手順に従い、Asset Editor でアセットのコミュニティ名を設定した場合は、そのコミュニティ名によって workflows.xml ファイルに設定されたコミュニティ名がオーバーライドされます。

アセットを自動的に受け入れるコミュニティのコンフィグレーション

次の例は、アセットを自動的に受け入れる「SOA Center of Excellence」コミュニティを設定する方法を示しています。

  <communities name=”SOA Center of Excellence autoAccept=”true”>

アセットを割り当ててタブ承認を行うコミュニティのコンフィグレーション

AssetSubmitted イベントがコミュニティ フローに関連付けられている場合は、そのコミュニティ フローによって自動的に割り当てられる承認者のリストが<approvers> 要素で作成されます。

  <communities name=”Java” autoAccept=”true”>
    <approvers>
      <alerid>5003</alerid>
      <alerid>5004</alerid>
    </approvers>

タブ承認フローにおける <alerid> の使い方については、「タブ承認での <alerid> の使用」を参照してください。

多層を使用してアセットを割り当ててタブ承認を行うコミュニティのコンフィグレーション

多層割り当ては多層フローと同じですが、これはコミュニティ内で機能します。多層フローの詳細については、「多層自動割り当てフロー」を参照してください。

アセットを自動的に登録するコミュニティのコンフィグレーション

次の例は、アセットを自動的に受け入れて登録する「SOA Center of Excellence」コミュニティを設定する方法を示しています。

  <communities name=”SOA Center of Excellence autoAccept=”true”
   autoRegister=”true”>

専用のレジストラを備えたコミュニティのコンフィグレーション

アセットの受け入れ、割り当て、および登録にはレジストラのユーザ名とパスワードが必要です。コミュニティ フローでは、アセットが属するコミュニティからレジストラ情報をロードします。アセットがコミュニティに属していない場合や、レジストラ情報がコミュニティに見つからない場合は、コミュニティ フローによってグローバル レジストラが使用されます。

コミュニティ フローによってコミュニティ タグを取得する優先順位を次に示します (図 5-1 を参照)。

自動受け入れおよび自動登録フローのコンフィグレーション

コミュニティ フローを使用してアセットを自動的に受け入れて登録するだけでなく、以下のルールを使用してアセットの受け入れおよび登録を行うことができます (図 5-1 を参照)。

アセットの種類

AssetType 要素内の autoAccept フラグと autoRegister フラグを使用すると、アセットを自動的に受け取るか、または登録することができます。

  <assetType name=”Application” autoAccept=”true” autoRegister=”true”
  id=”158”>
    <allTabs>
      <tab name=”Overview”/>
      <tab name=”Application Lifecycle”/>
    </allTabs>

Categorization の設定

検索はパフォーマンスに影響を与える可能性があるため、デフォルトでは、フローで autoAccept フラグと autoRegister フラグを検索することはありません。ただし、<action> フラグを使用してこの検索を有効にすることができます。

Categorization の設定をフローで使用する必要がある場合は、次の例に示すように、<action> フラグを true に設定する必要があります。この設定を行わない場合、Categorization の設定は無視されます。

  <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>

衝突の解決と優先順位

複数のルールが特定のイベント トリガに一致する場合もあるため、受け入れや登録などのための自動受け入れおよび自動登録フローによるそれぞれのルールの評価を示す階層が存在します (図 5-1 を参照)。このフローでは、以下の順序でメタデータをスキャンし、メタデータが見つかるとすぐにスキャンを中断してそのメタデータの設定を使用します。

多層自動割り当てフロー

多層フローは、「層」と呼ばれる複数の手順でアセット タブ承認プロセスを構成します。アセット承認タブは複数の層に分類できます。多層フローでは、それぞれの層を追跡し、指定の承認者によってすべてのタブが承認されるかどうかを検証します。ある層の最後のタブが承認されるとすぐに、次のレベルの指定の承認者にアセットを割り当てて、次の層の検証が開始されます。

使用例

図 5-5 は、多層プロセスのフローを示しています。

タブ承認での <alerid> の使用

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>
      <!--「_CHANGE_TIER1_NAME_」を層の名前に変更してください-->
      <!--例 :- Tier1-->
      <tier name=”Tier1”>
        <approvers>
          <alerid>99</alerid>
        </approvers>
        <tabs>
        <!--「_CHANGE_TABNAME_」をタブの名前に変更してください-->
        <!--例 :- Documentation-->
          <tab name=”Overview”>
          <tab name=”Taxonomy”>
        </tabs>
      </tier>
    </tiers>

メタデータ変更フロー

メタデータ フローは、アセットのメタデータ要素が変更されるときに 1 つまたは複数のアクションを実行するフローの集まりです。変更されるメタデータ要素は、1 つまたは複数のフローに関連付けられたイベントをトリガします。イベントをフローに関連付ける方法については、「フローへのアセット イベントの関連付け」を参照してください。

使用例

メタデータ変更フローを適用できるいくつかの使用例を次に示します。

メタデータ変更フローのコンフィグレーション

使用可能なメタデータ変更イベントおよび状態

メタデータ変更フローに関連付けることのできる、使用可能な状態を以下に示します。

  <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 フィールドは Asset Editor の [Miscellaneous] タブにあります。

アクションに関連付けることのできる使用可能なフロー

あらかじめ定義されているフローのうち、アクションに関連付けることのできるものを以下に示します。これらのフローの名前は、<action> 要素内のコンテンツとして表示されます。この要素は、イベントの発生時に実行する必要のあるアクションを示します。<action> 以外のすべての要素は、特定のフローによって使用されるパラメータです。

メタデータ変更のコンフィグレーション例

次のサンプル コンフィグレーションでは、アセットが登録されたときに「NotifySubscriber」と「ChangeCAS」という 2 つのフローを呼び出すように指定します。<customAccessSettings> 要素は、ChangeCAS フローのパラメータです。このパラメータは、適用する必要のある CAS の名前をフローに通知します。

  <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>

メタデータ値を確認するメタデータ変更のコンフィグレーション例

メタデータ要素の変更時だけでなく、メタデータ要素が特定の値を使用する場合にもフローを呼び出すことができます。たとえば、アセットの「アセット ライフサイクル ステージ」メタデータ要素を「ビルド」から「リリース」に変更する場合は、カスタム アクセス設定の 1 つのセットを適用できます。さらに、メタデータ要素の値を「プラン」から「ビルド」に変更すると、別のセットを適用できます。次に例を示します。

  <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

アセットの分類を設定します。ChangeClassification では、次の要素を使用して分類を設定します。

  <state name=”urn:com:bea:aler:events:type:AssetRegister”>
    <action>ChangeClassification</action>
    <classification>Approved</classification>
  </state>

ChangeCAS

1 つまたは複数のカスタム アクセス設定をアセットに適用します。ChangeCAS では、次の要素を使用してカスタム アクセス設定を行います。

  <state name=”urn:com:bea:aler:events:type:AssetRegister”>
    <action>ChangeCAS</action>
    <customAccessSettings>
      <customAccessSetting>MyCAS</customAccessSetting>
      <customAccessSetting>MyCAS2</customAccessSetting>
    </customAccessSettings>
  </state>

ChangeAssetLifecycle

アセットのアセット ライフサイクル ステージを設定します。ChangeAssetLifeCycle では、次の要素を使用してアセット ライフサイクルを設定します。

  <state name=”urn:com:bea:aler:events:type:AssetRegister”>
    <action>ChangeAssetLifeCycle</action>
    <assetLifeCycle>Stage 3 - Build</assetLifeCycle>
  </state>

ApproveTabAction

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

次の要素では、タブのリストをコンフィグレーションして、UnapproveTabAction フローで承認が解除されるようにします。

  <state name=”urn:com:bea:aler:events:type:MetaDataChange:name”>
    <action>UnApproveTabAction</action>
    <unapproveTabs>
      <Tab name=”Overview”>
      <Tab name=”Taxonomy”>
    </unapproveTabs>
  </state>

AutoApproveTabAction

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>

UnapproveChangeManagementTab

要素のメタデータ要素を変更する場合は、アセットを「変更管理」承認プロセスで処理することができます。このプロセスには以下の処理が含まれます。

ResetChangeManagementTab

このフローでは、[Change Management] タブが承認されるとすぐに、そのタブの [Reason for reassignment] フィールドをリセットします。

  <state name=”urn:com:bea:aler:events:type:AssetTabApproved”>
    <action>MultiTier_NextTier_Assign</action>
    <action>ResetChangeManagementTab</action>
  </state>

NotifyCustomUser

メタデータ変更についてコンフィグレーション済みのカスタム ユーザに通知します。次に示すように、ユーザの電子メール アドレスは、<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>

図 5-8 は、時間ベースのエスカレーション フローを示しています。

未送信のアセットの追跡

このフローでは、「未送信」状態のアセットを追跡し、オーナーに通知を送信してアクションを実行します。

  <owner_resubmit action=”false” days=”0” regressOnInaction=”true” queryOperator=”eq”/>

未受け入れのアセットの追跡

このフローでは、「未受け入れ」状態のアセットを追跡し、レジストラに通知を送信してアクションを実行します。

  <registrar_accept action=”false” days=”0” regressOnInaction=”true” queryOperator=”eq”/>

未承認のアセットの追跡

このフローでは、「未承認」状態のアセットを追跡し、承認者に通知を送信してアクションを実行します。

  <assignees_approve action=”false” days=”0” regressOnInaction=”true” queryOperator=”eq”/>

登録解除済みのアセットの追跡

このフローでは、「登録解除済み」状態のアセットを追跡し、承認者に通知を送信してアクションを実行します。

  <registrar_register action=”false” days=”0” regressOnInaction=”true” queryOperator=”eq”/>

検証の有効期限フロー

検証の有効期限フローでは、有効期限前および有効期限当日に期限の切れるアセットを追跡し、関連するすべての担当者に警告の通知を送信します。有効期限の X 日後に、フローはアセットの登録を解除します。有効期限の Y 日後に、フローはアセットを非アクティブにします。有効期限の Z 日後に、フローはアセットを削除します。

  <notification timerInterval=”1d”>
    <numTimesNotify>10</numTimesNotify>
    <daysBeforeNextNotification>2</daysBeforeNextNotification>

図 5-9 は、検証の有効期限フローを示しています。

アセットの有効期限を設定するには、図 5-10 に示す Asset Editor の [Miscellaneous] タブにある [Expiration Date (YYYY-MM-DD)] フィールドに日付を指定します。

アセット有効期限の警告の通知

次に示す行では、警告の通知を有効にして、その通知を受け取るユーザを指定します。

<expiration_warning action=”false” days=”10” owner=”false” subscriber=”false” contact=”99”/

有効期限後のアセットの登録の解除

次に示す行では、メタデータ変更フローを有効にして、有効期限の 10 日後にアセットの登録を解除します。

  <unregister_after_expire action=”true” days=”10” queryOperator=”eq”/>

有効期限後の非アクティブ化

次に示す行では、メタデータ変更フローを有効にして、有効期限の 10 日後にアセットを非アクティブにします。

  <inactive_after_expire action=”true” days=”10” queryOperator=”eq”/>

有効期限後のアセットの削除

次に示す行では、メタデータ変更フローを有効にして、有効期限の 10 日後にアセットを削除します。

  <delete_after_expire action=”true” days=”10” queryOperator=”eq”/>

電子メール通知テンプレートのカスタマイズ

自動登録フローでは、さまざまな状況で自動的に電子メール通知が送信されます。新しいフローのための新しい電子メール テンプレートは 5 つあります。電子メール テンプレートは Oracle Enterprise Repository 内に格納され、フローでは名前と値のペアを渡して Oracle Enterprise Repository API を呼び出します。この名前と値のペアは、後から Oracle Enterprise Repository によって置き換えられます。

管理者は、他の電子メール テンプレートの場合と同様に、電子メールの件名や本文などをカスタマイズできます。Advanced Registration Flow で使用されるテンプレートを以下に示します。

電子メール テンプレートの詳細については、『Oracle Enterprise Repository Administration Guide』を参照してください。