2 インストール前の手順

コネクタのインストール前に必要な手順を次に示します。

注意:

このガイドでは、Webサービス・エンドポイントを公開するターゲット・システムのことをターゲット・システムと呼んでいます。ターゲット・システムとしてACME Webserviceを使用して、構成とコネクタ・オブジェクトについて説明します。

第2.1項「前提条件」
第2.2項「コネクタ・バンドルの構築」
第2.3項「ターゲットWebサービス用のSOAコンポジットの作成」
第2.4項「フォルトの処理」
第2.5項「WebサービスSOAコンポジットのデプロイとテスト」

2.1 前提条件

コネクタWebサービス・クライアントとターゲットWebサービスを使用してSOAコンポジットを構成するための前提条件は次のとおりです。

Webサービス、WSDL、SOAコンポジットおよびBPELプロセス・コンポーネントの知識

WSDLがターゲットWebサービスに対して十分に定義され、スキーマの詳細と操作を公開していること。

Oracle JDeveloper 11g (11.1.1.9.0)とSOA Composite Editor拡張機能(SOAコンポジットを構成してコネクタと接続するため)

注意:

使用しているJDeveloperのバージョンがSOAサーバーと互換性があることを確認してください。JDeveloperは、次のURLからダウンロードできます。

http://www.oracle.com/technetwork/developer-tools/jdev/downloads/jdeveloper111190-2538883.html

SOA Composite Editor拡張機能のダウンロードとインストールの詳細は、次を参照してください。

http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/156082.xml#oracle.sca.modeler

XSL変換(ペイロードの変換のため)

接続の複雑さは、ターゲットWebサービスによって異なります。たとえば、Amazon Webサービスでは、各SOAPリクエストが署名され、その署名がリクエストごとに変わるものと想定されています。この署名は、コンポジットの一部として計算される必要があります。

2.2 コネクタ・バンドルの構築

コネクタ・パッケージには、一連のテンプレートと構築ユーティリティが含まれています。構築ユーティリティは、一連のテンプレートからターゲットWebサービスに固有のOracle Identity Managerアーティファクトを生成するスクリプトです。また、コネクタ・クライアントWebサービスをターゲットWebサービスに接続するために使用できるSOAコンポジット・プロジェクトも生成されます。

注意:

構築ユーティリティを使用して、様々なターゲットWebサービスに固有のコネクタを構築できます。このコネクタのクローニングはサポートされていません。

コネクタを構築するには、次のようにします。

たとえば、コネクタWebservices-11.1.1.5.0のディレクトリをOIM_HOME/server/ConnectorDefaultDirectoryディレクトリに作成します。

コネクタ・インストール・メディア・ディレクトリの内容を、手順1で作成したディレクトリにコピーして解凍します。

表2-1に、コネクタを構築する前のインストール・メディア上のファイルおよびディレクトリを示します。

表2-1 コネクタを構築する前のファイルとディレクトリ

インストール・メディア・ディレクトリのファイル	説明
build-connector.bat build-connector.sh	テンプレートからWebサービス・コネクタ・パッケージを生成するバッチ・ファイル。
bundle/org.identityconnectors.webservices-1.0.112.jar	このJARファイルは、コネクタが現在のリリースで使用しているICFバンドルです。
configuration	このフォルダは空です。
javadoc	このディレクトリには、コネクタで使用されるJava APIに関する情報が含まれます。
lib/ConnectorBuildTools.jar	このJARファイルには、テンプレートからWebサービス・コネクタ・パッケージを生成するクラス・ファイルが含まれています。
resourcesディレクトリにあるファイル	これらの各リソース・バンドルには、コネクタで使用される言語固有の情報が含まれます。コネクタのデプロイメント中に、このファイルはOracle Identity Managerデータベースにコピーされます。注意: リソース・バンドルは、管理およびユーザー・コンソールに表示されるローカライズ・バージョンのテキスト文字列を含むファイルです。これらのテキスト文字列には、GUI要素のラベルおよびメッセージが含まれます。
soa/policyディレクトリにあるファイル: Webservices-oim-integration.jar oimcp_WS_CONNECTOR_OUTBOUND	このディレクトリには、ターゲットWebサービスを呼び出す前にパスワード・フィールドのマスクを解除できるよう、SOAサーバーにデプロイする必要があるカスタム・ポリシーJARが含まれています。 oimcp_WS_CONNECTOR_OUTBOUNDファイルには、パスワード・エントリのマスク解除に使用されるSOAポリシーが含まれています。詳細は、第5.1項「コネクタの保護」を参照してください。
templatesディレクトリにあるファイル	これらのファイルは、ターゲット・システムWebサービスへの接続を完了させるために必要なテンプレート・プロジェクトの一部です。
xml	このフォルダは空です。

次のいずれかのコマンドを実行します

Microsoft Windowsの場合:

build-connector.bat "LONG_CODE" "SHORT_CODE"

UNIXの場合:

sh build-connector.sh "LONG_CODE" "SHORT_CODE"

ここで、LONG_CODEはコネクタのわかりやすい名前、SHORT_CODEはターゲット・システムの簡潔な4文字の名前で、参照名、アダプタ名などに使用されます。

たとえば、LinuxでACME Webserviceのコネクタzipファイルを構築するには、次のコマンドを実行します。

sh build-connector.sh "ACME Web" "ACME"

表2-2に、コネクタを構築した後に生成されるファイルとディレクトリを示します。

表2-2 コネクタを構築した後に生成されるファイルとディレクトリ

インストール・メディア・ディレクトリのファイル	説明
configuration/ACME-CI.xml	このファイルには、コネクタのインストールで使用される構成の情報が含まれます。
soa/project/ACMEWebserviceWSConnectorディレクトリにあるファイルとディレクトリ: ACMEWebserviceWSConnector.jpr classes composite.xml SCA-INF testsuites WebservicesConnectorServiceWrapper.wsdl SConnector.bpel WSConnector.componentType wsdl xsd xsl	これらのファイルとディレクトリがSOAコンポジット・プロジェクトを形成します。このプロジェクトをJDeveloperで開いて、テンプレートをターゲットWebサービスに接続できます。
xml/ACME-ConnectorConfig.xml	このファイルには、コネクタ・コンポーネントの定義が含まれます。リソース・オブジェクトプロセス定義 ITリソース・タイプリコンシリエーション・ルールスケジュール済ジョブ参照定義

インストール・メディア・ディレクトリのファイル

説明

configuration/ACME-CI.xml

このファイルには、コネクタのインストールで使用される構成の情報が含まれます。

soa/project/ACMEWebserviceWSConnectorディレクトリにあるファイルとディレクトリ:

ACMEWebserviceWSConnector.jpr
classes
composite.xml
SCA-INF
testsuites
WebservicesConnectorServiceWrapper.wsdl
SConnector.bpel
WSConnector.componentType
wsdl
xsd
xsl

これらのファイルとディレクトリがSOAコンポジット・プロジェクトを形成します。

このプロジェクトをJDeveloperで開いて、テンプレートをターゲットWebサービスに接続できます。

xml/ACME-ConnectorConfig.xml

このファイルには、コネクタ・コンポーネントの定義が含まれます。

リソース・オブジェクト
プロセス定義
ITリソース・タイプ
リコンシリエーション・ルール
スケジュール済ジョブ
参照定義

2.3 ターゲットWebサービス用のSOAコンポジットの作成

コネクタは、SOAを使用してターゲットWebサービスに接続し、それに対する操作を実行します。SOAコンポジット内の変数は、ターゲット・システムの変数にマップする必要があります。

第2.2項「コネクタ・バンドルの構築」に従ってコネクタを構築した後、生成されたSOAコンポジット・プロジェクトをJDeveloperで開いて、テンプレートをターゲットWebサービスに接続することができます。SOAコンポジットの接続が完了したら、認証用に特定のポリシーとバインディング・プロパティを含めることで、composite.xmlファイルでSOA WebSecurityポリシーを構成できます。

注意:

ベスト・プラクティスとして、各操作でエラーとフォルトを処理する方法を構成できます。詳細は、第2.4項「フォルトの処理」を参照してください。

この項では、次の手順について説明します。

第2.3.1項「パートナ・リンクの構成」
第2.3.2項「作成操作の構成」
第2.3.3項「SPML用の作成操作の構成」
第2.3.4項「削除操作の構成」
第2.3.5項「更新操作の構成」
第2.3.6項「プロビジョニングの有効化操作と無効化操作の構成」
第2.3.7項「検索操作の構成」
第2.3.8項「リコンシリエーションの有効化操作と無効化操作の構成」
第2.3.9項「参照検索操作の構成」
第2.3.10項「パスワードのリセット操作の構成」

2.3.1 パートナ・リンクの構成

操作を構成する前にパートナ・リンクを構成するには、次のようにします。

JDeveloperで、次のディレクトリにあるSOAコンポジット・プロジェクト・ファイルACMEWebserviceWSConnector.jprを開きます。

OIM_HOME/server/ConnectorDefaultDirectory/Webservices-11.1.1.5.0/soa/project/ACMEWebserviceWSConnector

注意:

使用しているJDeveloperのバージョンがSOAサーバーと互換性があることを確認してください。SOA Composite Editor拡張機能もインストールされている必要があります。JDeveloperのバージョン11.1.1.9.0のダウンロードとインストールの詳細は、次を参照してください。

http://www.oracle.com/technetwork/developer-tools/jdev/downloads/jdeveloper111190-2538883.html

composite.xmlファイルを開きます。

構成ファイルには、次のサンプル・スクリーンショットのように、BPELプロセスとパートナ・クライアントの関係が表示されます。

BPELプロセス・コンポーネントをダブルクリックして、ICF操作を表示します。

デフォルトでは、このBPELプロセスはコネクタWSDL (wsdl\WebservicesConnectorService.wsdl)に接続されます。WSDLをダブルクリックすると、コネクタ操作がその入力と出力のスキーマおよび例外とともに表示されます。

注意:

JDeveloper SOAプロジェクト内のWebserviceConnectorServiceスキーマ(xsd/WebservicesConnectorService.xsd)およびwsdlファイル(wsdl/WebservicesConnectorService.wsdl)は変更しないでください。これは、コネクタとのコントラクトが失われ、予想どおりに動作しなくなる可能性があるためです。

BPELプロセスでは、呼び出されたWebサービス・コネクタ操作に基づいて、各ブランチが呼び出されます。

ターゲットWSDLをインポートして定義することで、作成などの操作のパートナ・リンク(http://<machine-name>:<port-number>//spml-xsd/SPMLService?WSDL)を含めます。

composite.xmlファイルで、ACMEUserServiceがすべての操作とともに示されます。
プロジェクトを保存します。

2.3.2 作成操作の構成

SOAサーバーにターゲットをデプロイします。

第2.3.1項「パートナ・リンクの構成」で説明されている手順を実行したら、SOAコンポジットで次のように作成操作を構成できます。

2.3.3 SPML用の作成操作の構成

Service Provisioning Markup Language (SPML)は、Directory Service Markup Language (DSML)の概念に基づくXMLベースのフレームワークで、協力組織間のユーザー、リソースおよびサービス・プロビジョニング情報を交換するためのものです。

SPML用の作成操作を構成する前に、次の手順を実行します。

ターゲットWebサービス(ACME Webserviceなど)のSPMLバージョンに応じて、SPMLおよびDSML XML Schema Definition (XSD)ファイルを使用します。SPMLおよびDSML XSDについては、付録D「サンプルXSD」を参照してください。
- SPMLについてテストするには、ターゲットがすでにserver/apps/oim.earに配置され、OIMのoim_server1からの初回アクセス時に自動デプロイされている必要があります。WSDLパスはhttp://<machine-name>:14000/spml-xsd/SPMLService?WSDLです。SPMLの動作は非同期のため、OIMはターゲットからのレスポンスを待ちません。
- 非SPMLターゲットについてテストするには、添付としてターゲットを使用します。SOAサーバーにこのターゲットをデプロイします。
ターゲットWebサービスで想定されている構文にあわせて、XSDファイルを変更します。
SPML WSDLを使用して、別々のWebサービス・テスト・ツール(SOAP UIなど)で操作をテストします。テスト・ツールを使用して操作を実行できることを確認します。

デフォルトでSPMLサービスに対してWSDLを使用できない場合は、次のリンクを使用して独自のWSDLを作成できます。

http://<machine-name>:<port-number>/spml-xsd/SPMLService?WSDL
第2.3.1項「パートナ・リンクの構成」で説明されている手順に従って、JDeveloperで、WSDLを使用してSOAコンポジットにパートナ・リンクを作成します。
SPMLおよびDSML XSDファイルをプロジェクト内に保持し、これらのファイルに対するインポートおよび参照が正しく構成されていることを確認します。

次のサンプルCreateUser SPMLリクエストを考えてみます。

サンプルCreateUser SPMLリクエストの作成操作を構成するには、次のようにします。

Invokeアクティビティを編集して、ターゲットのCreateUser操作を呼び出し、変数を追加します。
Invokeアクティビティの前にTransformアクティビティをドロップします。

不必要なAssignアクティビティがあれば削除します。ソース変数をCreateOp_inputVariableに設定し、ターゲット変数をInvokeCreate(前の手順で作成したInvokeアクティビティの入力変数)に設定します。
マッパー・ファイル名を指定し、「OK」をクリックします。ファイルが編集用に開きます。
for-eachコンストラクトを使用して、userAccount属性をループします。
「ソース」タブに切り替えて、属性のXSL変換コードを表示します。choose-whenコンストラクトを使用して属性名を確認し、値を割り当てます。

次に、サンプル・コードを示します。このサンプルでは、firstNameはコネクタWebサービスから受け取った属性名です。nameはfirstnameに変換されます。これは、手順1の直前のサンプルSPMLリクエストに示されているようにSPMLターゲットによって使用される属性名です。同様に、whenノードを追加することで、その他の属性(lastNameなど)のマッピングも行うことができます。
```
<xsl:for-each select="/types:create/userAccount/*">
  <xsl:choose>
    <xsl:when test='(name() = "firstName") and /types:create/userAccount/firstName'>
      <dsml:attr>
        <xsl:attribute name="name">
          <xsl:text disable-output-escaping="no">firstname</xsl:text>
        </xsl:attribute>
        <dsml:value>
          <xsl:value-of select="/types:create/userAccount/firstName"/>
        </dsml:value>
      </dsml:attr>
    </xsl:when>
    <xsl:when test='name() = "lastName" and /types:create/userAccount/lastName'>
    ...
    ...
    ...
    </xsl:when>
  </xsl:choose>
</xsl:for-each>
```
コネクタは、出力Replyとして、ターゲットで作成されたユーザーのUIDを予期します。この例では、次の作成レスポンスを受け取ります。
レスポンスからaccountIdを読み取り、リプライでUIDとして送信するためには、別の変換が必要になります。InvokeアクティビティとCreateOpReplyアクティビティの間に、もう1つのTransformアクティビティをドロップします。
ソース変数をInvokeの出力として設定し、ターゲット変数をReplyの出力変数として設定します。
変換ページで、次のようにします。
- for-eachループをdsml:attrに適用します。
- 次のサンプル・スクリーンショットに示すように、等号とif行をUIDにドロップし、それらをリンクします。
- dsml:valueをcreateResponseのUIDに適用します。
等号ボックスをダブルクリックして編集し、2番目のパラメータをaccountIdとして設定します。

変換ファイルのソースは、次のようになります。

<types:createResponse>
  <xsl:for-each select="/spml:addResponse/spml:pso/spml:data/dsml:attr">
    <xsl:if test='@name = "accountId"'>
      <uid>
        <xsl:value-of select="dsml:value"/>
      </uid>
    </xsl:if>
  </xsl:for-each>
</types:createResponse>

割当てとプロジェクトを保存します。

プロジェクトをコンパイルしてデプロイできます。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。

2.3.4 削除操作の構成

第2.3.1項「パートナ・リンクの構成」で説明されている手順を実行したら、次の手順を使用して、SOAコンポジットで削除操作を構成できます。削除するユーザーのUIDは、Oracle Identity ManagerからSOAコンポジットへの入力です。この入力は、ターゲットWebサービスで削除するユーザーのUnique Idにマップする必要があります。

InvokeDelete操作を削除操作用の適切なパートナ・リンクにリンクします。
このInvokeアクティビティに対する操作および入力/出力変数を指定し、「OK」をクリックします。
コンポーネント・パレットから、AssignアクティビティをInvokeアクティビティの前にドラッグします。
Assignアクティビティを編集して、削除操作の入力変数をマップします。
割当ての編集ウィンドウで、DeleteOp_InputVariableのフィールドをターゲット操作のInput変数の対応するフィールドにマップします。
変数がマップされたら、プロジェクトをコンパイルしてデプロイします。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。

2.3.5 更新操作の構成

SOAコンポジットで更新操作を構成する前に、次の手順を実行します。

ターゲットWebサービスが複数の属性の同時更新をサポートしているかどうか確認します。
ターゲットWebサービスが1度に1つの属性の更新のみサポートしている場合は、Design Consoleでプロセス定義からFORM_NAME Updatedプロセス・タスクを削除します。

詳細は、第3.2.7項「属性の一括更新タスクの削除」を参照してください。
第2.3.1項「パートナ・リンクの構成」で説明されている手順に従って、JDeveloperで、WSDLを使用してSOAコンポジットにパートナ・リンクを作成します。

ターゲットWebサービスが複数の属性の同時更新をサポートしていることを前提として、次のように更新操作を構成できます。

InvokeUpdate操作を更新操作用の適切なパートナ・リンクにリンクします。
このInvokeアクティビティに対する操作および入力/出力変数を指定し、「OK」をクリックします。
TransformアクティビティをInvokeにドロップします。ソース変数をUpdateOp_InputVariableとして設定し、ターゲット変数を前の手順で設定したInvokeアクティビティの入力変数として設定します。
翻訳マッパー・ファイルを開きます。「if」コンストラクトをターゲット変数にドラッグします。
updatedAttributeの下にある「name」を「if」コンストラクトに、「value」をターゲット変数にマップします。

ソースに切り替えます。次に、サンプル・ソースを示します。

<xsl:if test="/types:update/updatedAttribute/name">
  <firstName>
    <xsl:value-of select="/types:update/updatedAttribute/value"/>
  </firstName>
</xsl:if>

Lookup.ACME.UM.ProvAttrMap参照定義のコネクタ・フィールドのデコード値を確認します。

サンプルの属性名first nameの場合、デコード値はFirstNameです。

次のようにソースを変更します。

<xsl:if test='/types:update/updatedAttribute/name = "FirstName"'>
  <firstName>
    <xsl:value-of select="/types:update/updatedAttribute/updatedAttribute[name = 'FirstName']/value"/>
  </firstName>
</xsl:if>

手順5から8に従って、その他の属性を追加します。

カスタム属性の場合、すでに属性がLookup.ACME.UM.ProvAttrMap参照定義に含まれていることを確認します。詳細は、第5.2.3項「更新操作用のカスタム属性の追加」を参照してください。
ターゲットから更新されたユーザーのUIDが返された場合は、AssignアクティビティをInvokeの後にドロップし、戻り値をupdateResponse uidにマップします。それ以外の場合は、updateOp入力変数のuidをupdateResponse uidにマップします。
プロジェクトを保存します。

プロジェクトをコンパイルしてデプロイできます。Enterprise Managerから操作をテストします。

2.3.6 プロビジョニングの有効化操作と無効化操作の構成

前提条件として、第2.3.5項「更新操作の構成」で説明されているように、更新操作を構成し、変換XSLファイルを作成します。ActiveまたはInactiveの値を持つことができるターゲット変数Statusを検討してください。

SOAコンポジットでプロビジョニングの有効化操作または無効化操作を構成するには、次のようにします。

次のサンプル・スクリーンショットに示すように、if、chooseおよびwhenコンストラクトをターゲット変数にドロップします。
updatedAttributeの下にある「name」を「if」およびwhenコンストラクトにドラッグします。
ターゲット変数「status」を右クリックし、2つのテキスト値をActiveとInactiveに設定します。

「ソース」タブに切り替えて、属性のXSL変換コードを表示します。次のようにコードを変更します。

<xsl:if test='/types:update/updatedAttribute/name = "__ENABLE__"'>
  <xsl:choose>
    <xsl:when test='/types:update/updatedAttribute[name = "__ENABLE__"]/value = "true"'>
      <status>
        <xsl:text disable-output-escaping="no">Active</xsl:text>
      </status>
    </xsl:when>
    <xsl:when test='/types:update/updatedAttribute[name = "__ENABLE__"]/value = "false"'>
      <status>
        <xsl:text disable-output-escaping="no">Inactive</xsl:text>
      </status>
    </xsl:when>
  </xsl:choose>
</xsl:if>

プロジェクトを保存します。

プロジェクトをコンパイルしてデプロイできます。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。

2.3.7 検索操作の構成

信頼できるソースまたはターゲット・リソースのユーザー・リコンシリエーション・スケジュール済ジョブがOracle Identity Managerから実行されると、検索ブランチが呼び出されます。この操作は、ターゲットWebサービスからユーザーのリストとその属性をフェッチします。このリストは、Oracle Identity Managerに返されるuserSearchRecordsのリストに変換されます。

2.3.7.1 SOAコンポジットでの単純な子表の値のマッピング

SOAコンポジットで単純な子表の値をマップできます。これを行うには、検索変換で、子表の値に対して次のマッピングを実行します。

子表値に「for each」ループを追加し、その子表値をmultivaluedAttributeの「values」属性にマップします。

たとえば、この場合は「Group」が子表であり、各groupがmultivaluedAttributeの「values」要素にマップされます。

smpl_chld_tbl_map.gifについては周囲のテキストで説明しています。

このマッピングでは、値は次のようになります。

<multivaluedAttributes>
            <name>
              <xsl:text disable-output-escaping="no">Group</xsl:text>
            </name>
            <xsl:for-each select="tns:Groups/group">
              <values>
                <xsl:value-of select="."/>
              </values>
            </xsl:for-each>
          </multivaluedAttributes>

2.3.8 リコンシリエーションの有効化操作と無効化操作の構成

前提条件として、第2.3.7項「検索操作の構成」で説明されているように、検索操作を構成し、変換XSLファイルを作成します。ActiveまたはInactiveの値を持つことができるターゲット変数Statusを検討してください。

SOAコンポジットでリコンシリエーションの有効化操作または無効化操作を構成するには、次のようにします。

Status属性のリコンシリエーションの場合、__ENABLE__という名前のotherAttributesを移入します。

たとえば、ターゲット・ユーザーのstatusがActiveまたはInactiveのいずれかである場合、次のXSLコードをStatus属性のマッピングに使用できます。

<otherAttributes>
   <name>
      <xsl:text disable-output-escaping="no">__ENABLE__</xsl:text>
   </name>
   <xsl:choose>
      <xsl:when test='userAccount/status = "Active"'>
          <value>
              <xsl:text disable-output-escaping="no">true</xsl:text>
          </value>
      </xsl:when>
      <xsl:when test='userAccount/status = "Inactive"'>
          <value>
              <xsl:text disable-output-escaping="no">false</xsl:text>
          </value>
      </xsl:when>
   </xsl:choose>
</otherAttributes>

「ソース」タブのサンプル・スクリーンショットを次に示します。

オブジェクト・ステータスは、Oracle Identity Managerで「有効」または「無効」として反映されます。

注意:

参照定義、プロセス・フォーム、リコンシリエーション・フィールド・マッピングおよびプロファイル内のエントリについては、__ENABLE__属性用の追加は必要はありません。それらはデフォルトで構成されます。

プロジェクトを保存します。

プロジェクトをコンパイルしてデプロイできます。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。

2.3.9 参照検索操作の構成

Webサービス・コネクタの参照スケジュール済ジョブがOracle Identity Managerから実行されると、参照検索ブランチが呼び出されます。参照検索操作は、objectClassをスケジュール済タスク・パラメータとして渡される入力として受け入れ、lookupEntriesのリスト(名前と値のペアのリスト)を返します。出力内の名前と値のリストは、それぞれ参照定義のデコード値とコード・キー値として設定されます。

第2.3.1項「パートナ・リンクの構成」で説明されている手順を実行したら、次のように参照検索操作を構成できます。

InvokeLookupSearch操作を参照検索操作用の適切なパートナ・リンクにリンクします。
InvokeLookupSearchアクティビティに対する操作および入力/出力変数を指定し、「OK」をクリックします。
ターゲットWebサービスから受け取った出力は、コネクタが認識する規則(名前と値のペアのリスト)に変換される必要があります。これを行うには、コンポーネント・パレットからTransformアクティビティをドラッグし、InvokeLookupSearchアクティビティの下にドロップします。
Transformアクティビティを編集します。
変換の編集ウィンドウで、ソース変数とターゲット変数を追加します。次に、マッパー・ファイル名を指定して、「OK」をクリックします。
指定したマッパー・ファイル名を持つXSLファイルが作成され、開きます。入力変数は左側に、出力構造は右側に表示されます。「OK」をクリックします。
ソース変数とターゲット変数を開いて、マッピングの前に構造を確認します。
参照検索レスポンスを適切にマップします。返された変数がlookupEntriesに接続されると、JDeveloperがAutoMap機能を使用して自動的に変数をマップします。

AutoMap機能は、ソース要素をターゲットWebサービスの類似の名前に自動的にマップし、役割のリストをフェッチするために、lookupEntriesの前にfor-each文を含めます。これが適切でない場合は、マッピングを手動でマップして変換します。「ソース」タブに切り替えて、XSL変換コードを直接更新することもできます。「OK」をクリックします。
変換マッピングを確認したら、プロジェクトを保存します。
Oracle Identity Manager Design Consoleで、参照検索スケジュール済ジョブの結果として移入される、空の参照定義を作成します。
これに応じて、スケジュール済タスクを構成します。この参照の参照名とObjectTypeを指定します。

lookupSearchの出力は、次のように変換されます。

スケジュール済ジョブを実行すると、参照定義は次のように移入されます。
SOAコンポジットを構築してデプロイします。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。

2.3.10 パスワードのリセット操作の構成

この項では、SOAコンポジットからパスワード・リセット操作を構成する方法について説明します。マッピングを構成したら、パスワード・フィールドを復号化するためのカスタム・アウトバウンド・ポリシーが適用されます。Oracle Identity Managerから送信される機密フィールドは暗号化されます。また、アウトバウンド・ポリシーによって、Enterprise ManagerのSOAPペイロードでパスワード・フィールドがクリア・テキストで表示されていないことが確認されます。

第2.3.1項「パートナ・リンクの構成」で説明されている手順を実行したら、次のようにパスワードのリセット操作を構成できます。

InvokeResetPassword操作をパスワードのリセット操作用の適切なパートナ・リンクにリンクします。
このInvokeアクティビティに対する操作および入力/出力変数を指定し、「OK」をクリックします。
コンポーネント・パレットから、AssignアクティビティをInvokeアクティビティの前にドラッグします。
ResetPasswordAssignアクティビティを編集して、パスワードのリセット操作の入力変数をマップします。
デフォルトでは、ResetPasswordOp_InputVariableのuidフィールドは、ResetPasswordOp_OutputVariableのuidフィールドにマップされます。
割当ての編集ウィンドウで、ResetPasswordOp_InputVariableのフィールドを、更新する必要がある新しいパスワードのターゲットWebサービスペイロードにマップします。
ResetPasswordOp_InputVariableのuidフィールドをターゲットWebサービスの対応するUnique Idフィールドにマップします。
変数がマップされたら、カスタム・アウトバウンド・ポリシーを構成します。

この手順の詳細は、第5.1.1項「パスワードの処理」を参照してください。
コンポジットで、password.field.xpath.locationsプロパティを指定します。

このプロパティは、ResetPasswordAssignアクティビティから取得できます。
target.payload.namespacesプロパティを指定します。

このプロパティは、BPELソースにあるパスワード・フィールドの対応するネームスペースです。

注意:
target.payload.namespaceプロパティのネームスペースに引用符が含まれていないことを確認してください。
SOAコンポジットを構築してデプロイします。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。

2.4 フォルトの処理

フォルト処理は、SOAコンポジットの構成における重要な側面です。フォルトやエラーが発生した場合、ターゲットWebサービスからコネクタとOracle Identity Managerに適切なレスポンスを提供する必要があります。これは、SOAコンポジット・レベルで構成します。なぜなら、ターゲットWebサービスの操作によってスローされたリモート・フォルトは、対応するコネクタ固有のフォルトにマップされる必要があるからです。

次の表に、コネクタWebサービス(WebserviceConnectorService) WSDLで定義されているフォルトを示します。

フォルト	説明	このフォルトをスローする可能性がある操作
AlreadyExistsException	アカウントがターゲットWebサービスにすでに存在します。	作成
UnknownUidException	渡された一意のIDが無効であるか、ターゲットWebサービスに存在しません。	作成を除くすべての操作
ConnectionBrokenException	ターゲットWebサービス・エンドポイントに到達できません。	すべての操作
ConnectorException	その他のフォルト。	すべての操作

作成操作のために、SOAコンポジットでフォルト処理を構成するには、次のようにします。

2.4.1 Catchブロックを使用したフォルト処理

ターゲットWebサービスの操作がレスポンスを送信せずにフォルトをスローする場合に備えて、SOAコンポジットでCatchブロックを追加することにより、フォルト処理を構成できます。削除操作の手順は次のとおりです。

ScopeアクティビティをBPELプロセスにドラッグして、Invoke操作をスコーピングします。
スコープ・コンテキストでアラーム・アイコンをクリックして、Catch文を追加します。

Catchブロックを構成するには、ターゲットWebサービスの操作によってスローされるフォルトのタイプを指定します。
対応するコネクタ固有のフォルト・タイプをスローするため、ThrowアクティビティをCatchブロックに追加します。

Throwアクティビティの構成の詳細は、前の手順(手順10以降)を参照してください。

2.5 WebサービスSOAコンポジットのデプロイとテスト

SOAコンポジットの準備ができたら、JDeveloperを使用してSOAサーバーに対して構築とデプロイを行うことができます。この手順を実行するには、次のようにします。

(オプション)機密データをOracle Identity Managerからコンポジットに、コンポジットからターゲットWebサービスに渡す必要がある場合、第5.1項「コネクタの保護」で説明されているように、アウトバウンド・ポリシーを構成できます。
次のサンプル・スクリーンショットに示すように、構成されたSOAコンポジットをSOAサーバーにデプロイします。
Enterprise Managerからコンポジットをテストします。これは、URL (たとえば、http://adminhost:adminport/em)に移動するか、Enterprise Managerコンソールから行います。