Oracle Paymentsインプリメンテーション・ガイド リリース12 E06000-01

目次

前へ

次へ

Oracle Paymentsと外部支払システムの併用

支払システム統合の概要

この章では、Oracle Paymentsを外部支払システムに統合する方法について説明します。

Oracle Paymentsのアーキテクチャには、インバウンド（資金取得）とアウトバウンド（支出）の両方の取引処理について、第三者支払システムとの統合が考慮されています。

資金取得フローでは、外部支払システムは、2種類（ゲートウェイまたはプロセッサ）のいずれかです。ゲートウェイ・モデルの支払システムでは、すべての取引がオンラインで、支払システムとのリアルタイム通信が関連しています。プロセッサ・モデルの支払システムでは、承認用にリアルタイム通信が、精算処理用にバッチ操作がサポートされています。

支出フローでは、リアルタイム取引処理の概念はありません。支払処理はバッチ・モードでのみ実行されます（通常、支払ファイルは支払システムにFTPで送信されます）。

支払システム統合の構成要素

Oracle Paymentsとカスタム支払システムとの統合を実装する場合は、統合の構成要素をいくつか開発する必要があります。統合の構成要素は、支払処理サイクルの様々な段階でOracle Paymentsによって起動される基本的な要素です。

実装される構成要素のリストは、支払フローのタイプ（資金取得または支出）、支払システムのタイプ（ゲートウェイまたはプロセッサ）、支払手段のタイプ（クレジット・カード、デビット・カードまたは銀行口座）など、様々な要因によって異なります。

次の表に、カスタム支払システムとインタフェースするために実装される様々な統合の構成要素タイプを示します。カスタム統合では、リストされている統合構成要素のサブセットのみが必要になる場合があります。

注意: 統合の構成要素タイプの一部はJavaで開発されます。

Oracle Paymentsでは、インバウンド（資金取得）とアウトバウンド（支出）の両方のフローをサポートしています。したがって、支払システム統合の実装方法では、資金取得の場合と資金支出の場合を個別の項で説明します。次の項では、カスタム支払システム統合を達成するために実行する必要があるタスクについて詳細に説明します。

資金取得と資金支出については、「Oracle Payments設定」ページを使用して、基本的な設定をいくつか実行する必要があります。これらの基本的な設定は、資金取得と資金取得の両方で類似しており、エンティティ（支払システム、支払システム・アカウント、プロセス・プロファイルなど）の作成に関連しています。

統合の残りの部分は、統合の構成要素（フォーマット、伝送、検証、受信確認など）の作成に関連しています。これらの構成要素の作成は、支払システムの特性によって異なるため、次の項で詳細を説明します。

資金取得用のカスタム支払システム統合の開発

カスタム支払システムとの統合で実行する必要があるタスクのリストは、次の要因によって異なります。

• 支払システムのタイプ（ゲートウェイまたはプロセッサ・モデル）

• 支払手段のタイプ（クレジット・カード、デビット・カードまたは銀行口座）

カスタム支払システムとの統合の実装ガイドラインには、次の事項が含まれています。

• クレジット・カードとデビット・カードの処理では、通常、支払システムがゲートウェイかプロセッサであるかに関係なく、オンライン承認取引が必須です。銀行口座取引に承認ステップはありません。一部の支払システムではオンライン検証の概念がサポートされており、銀行口座に対する基本的な検証がいくつか実行されます。

• ゲートウェイ・モデルでは、個々の取引のみが支払システムに送信されます。バッチの概念はありません。プロセッサ・モデルの支払システムでは、承認はオンライン取引（リアルタイム処理）として送信され、精算はバッチでオフライン処理されます。

• プロセッサ・モデルの支払システムは、受信確認をサポートしている場合とサポートしていない場合があります。サポートしている場合は、バッチ問合せを実行して、支払システムから精算ステータスを受信し、精算取引を最終ステータスに設定できます。プロセッサ・モデルの支払システムがバッチ問合せをサポートしていない場合は、精算の発行がOracle Paymentsでの最終ステップとなります。

カスタム統合の実行に必要なタスクを判断するには、次のフローチャートを参照してください。

資金取得支払システム用の統合タスク・リスト

次の表に、資金取得用支払システムを統合するために完了する必要があるタスクを示します。

次の注意は、後述するバッチ処理インフラストラクチャ・タスク表に関する注意です。

注意: バッチ処理タスクはゲートウェイには関係ありません。

次の注意は、後述するバッチ問合せインフラストラクチャ・タスク表に関する注意です。

注意: バッチ問合せタスクはゲートウェイには関係ありません。

資金支出用のカスタム支払システム統合の開発

資金取得とは異なり、資金支出統合は常にオフラインで支払ファイルを使用します。資金支出フローには、オンライン/リアルタイム取引処理の概念がありません。

資金支出フローでは、通常、実装に支払指図（支払バッチとも呼ばれる）からのデータを使用した支払ファイルの作成が関連することになります。支払ファイルは支払システム固有のフォーマットで作成され、支払システムに転送（通常はFTP経由で）されます。

支払システムが問合せ機能をサポートしている場合は、問合せメッセージと承認パーサーの実装が必要になります。

次のフローチャートを使用して、カスタム統合の実行に必要なタスクを判断してください。

資金支出支払システム用の統合タスク・リスト

次の基本設定タスクの表に、カスタム支払システムを統合するためのタスクを示します。

次の注意は、後述するバッチ処理インフラストラクチャ・タスク表に関する注意です。

注意: バッチ処理タスクはゲートウェイには関係ありません。

支払システムの定義

支払システム統合の最初のタスクは、支払システムを定義することです。この定義では、支払システムの属性と、ユーザーが設定する支払システム・アカウントに定義されるアカウント・オプション（ある場合）の両方を指定する必要があります。

支払システムの属性

次の表に、支払システムの主な属性を示します。

これらの属性はすべて「支払システムの作成」または「支払システムの更新」ページで設定できます。

関連項目

支払システムの設定の情報は、「ステップ6. 支払システムの設定」を参照してください。

アカウント・オプション

アカウント・オプションは、支払システムがその支払システムのユーザー・アカウントに対して定義する属性です。最初に、「支払システム」ページでパラメータを定義する必要があります。次に、「支払システム・アカウント」ページで支払システム・アカウントを作成する際に実際の値を入力します。アカウント・オプションは、支払指図ファイルの生成に使用され、資金取得抽出に表示されます。

注意: カスタム支払システム統合を実装するには、値を確実に文書化する必要があります。

関連項目

支払システム・アカウントを使用可能にする方法は、「支払システム・アカウントの有効化」を参照してください。

フォーマット

支払システムでは、取引を処理する際に異なるフォーマットが使用されます。たとえば、承認にはあるフォーマットを、精算バッチでは別のフォーマットを使用する場合があります。Oracle Paymentsでフォーマットを作成するには、その前に、対応するOracle XML Publisherのテンプレート・エンティティを使用可能にする必要があります。

フォーマット・テンプレートの開発

次の表に、値がOracle Paymentsによって指定されているOracle XML Publisherのテンプレート属性を示します。

カスタム支払システム統合を実装するためには、XMLパブリッシャ用に支払指図テンプレートを開発する必要があります。この開発には、eText（RTF）やXSLなど、サポートされているXMLパブリッシャ・テンプレート・タイプのいずれかを使用します。次に、XMLパブリッシャ・テンプレートをシードし、シードしたテンプレートにフォーマットをリンクする必要があります。

フォーマット・テンプレートの設定

Oracle XML Publisherのテンプレートを作成した後は、Oracle Paymentsの「書式の作成」ページを使用して、対応するフォーマット・エンティティを作成する必要があります。

抽出ジェネレータ

抽出ジェネレータは、支払ファイル抽出文書（取引に関連する全データのスーパーセット）を作成します。フォーマット・テンプレートは、最終的な支払ファイルを作成するための抽出に適用されます。

支払ファイル抽出は、構造がXMLスキーマに準拠しているXML文書です。資金取得XMLスキーマは、$IBY_TOP/patch115/publisher/defs/IBY_FCI_1_0.xsdファイルに定義されています。資金支出XMLスキーマは、$IBY_TOP/patch115/publisher/defs/IBY_PPIOUT_1_0.xsdファイルに定義されています。

資金取得XMLスキーマは、すべての資金取得手段タイプ（クレジット・カード、銀行口座、暗証番号不要のデビット・カードなど）およびすべての資金取得取引操作タイプ（承認、オンライン精算、精算バッチなど）について取引をサポートしています。

資金支出XMLスキーマには、支払指図情報、支払プロセス・プロファイル、支払フォーマットおよび構成支払も含めて、すべての支出関連支払情報が含まれています。

カスタム支払システム統合を実装するには、支払指図ファイル・テンプレートを作成する上で、抽出の構造を完全に理解する必要があります。

抽出フォーマッタ

抽出フォーマッタは、抽出ジェネレータによって作成された抽出文書を取り込み、フォーマット・テンプレートに適用して最終的な支払ファイルを作成します。Oracle Paymentsでは、Oracle E-Business SuiteアプリケーションのOracle XML Publisher（XDO）をそのフォーマット・エンジンとして使用します。

カスタム支払システム統合を実装するには、支払システムがサポートするすべての取引操作タイプに対してテンプレートを作成する必要があります。支払システムの統合モデルが、フォーマットされた支払ファイル配信のいずれにも準拠していない場合は、未変更の抽出文書を作成する通常のフォーマット・テンプレートを出力として使用し、HTTPを使用して抽出をサーブレットに配信し、次に、サーブレット・マップの支払システム固有の支払要求メカニズムに文書を抽出できます。通常のテンプレートは、Oracle Paymentsによって、テンプレート・コードIBY_IDENTITYですでにシードされています。IBY_IDENTITYは、フォーマットしないで現状のままの抽出を戻す特別なテンプレートです。

伝送関数

伝送関数には、支払ファイルを支払システムに配信し、特定の伝送プロトコルを実装する役割があります。

カスタム支払システム統合を実装するには、支払システムと通信するために各伝送プロトコルに対して伝送関数のコードポイントを作成する必要があります。

支払システム仕様の構成要素の1つは、支払ファイルを支払システムに配信する際に使用する伝送プロトコルです。伝送プロトコルには、通信の試行時に必要なシステム・データを定義する伝送パラメータが関連付けられています。また、伝送プロトコルには伝送関数のコードポイントが定義されています。このコードポイントは、プロトコルを実装する自己完結型のコードで、oracle.apps.iby.net.TransmitFunctionインタフェースに準拠しています。

伝送関数の開発

伝送プロトコルはJavaクラスを介して実装され、このクラスがoracle.apps.iby.net.TransmitFunctionインタフェースを実装する必要があります。インタフェースを実装するには、このクラスに伝送関数を定義する必要があります。

次の表に、この関数のシグネチャを示します。

伝送関数によるプロトコルの実装では、その関数が、次のようなoracle.apps.iby.exception.PSException型の例外によって発生するシステム例外を処理する必要があります。

throw new PSException(PSException.COMMUNICATION_ERROR);

必要な伝送プロトコル・パラメータが設定されていない場合は、同じクラス・タイプを使用して次のような例外がスローされます。

throw new PSException(PSException.CODEPOINT_ARG_ERR,

PSException.CODEPOINT_ARG_ERR_TOKEN_ARG,

      <parameter code>);

伝送関数はJavaリフレクションAPIを介して起動されるため、その伝送関数によって生成された例外を保持するには、特別な処理が必要です。この処理がないと、この関数に障害がある場合、Oracle Paymentsエンジンでは、一般的なjava.lang.reflect.InvocationTargetExceptionのみが参照されます。エンジンが参照できるように当初の例外を保持するには、次の関数をコールする必要があります。

oracle.apps.iby.engine.CodePoint.storeException()

伝送プロトコルの設定

ユーザー・インタフェースで支払システムの支払システム・アカウントを構成すると、その支払システムのシステム・プロファイルに定義されているすべての伝送プロトコル・パラメータが自動的に表示されます。

次の表に、伝送プロトコルの属性を示します。

次の表に、伝送プロトコルのパラメータの属性（プロトコルのサブエンティティ）を示します。

伝送プロトコルとそのパラメータは、それらを挿入するSQLスクリプトを作成することで、Oracle Paymentsにシードできます。

注意: 変換可能なプロトコル属性TRANSMIT_PROTOCOL_NAMEを除くすべての属性は、IBY_TRANSMIT_PROTOCOLS_B表に挿入してください。変換可能な属性TRANSMIT_PROTOCOL_NAMEはIBY_TRANSMIT_PROTOCOLS_TLに挿入し、プロシージャIBY_PP_MLSUTL_PVT.TRANS_PROT_ADD_LANGUAGEをコールしてください。

変換可能なプロトコル・パラメータ属性TRANSMIT_PARAMETER_NAMEを除くすべての属性は、IBY_TRANSMIT_PARAMETERS_B表に挿入してください。変換可能な属性TRANSMIT_PARAMETER_NAMEはIBY_TRANSMIT_PARAMETERS_TLに挿入し、プロシージャIBY_PP_MLSUTL_PVT. TRANS_PARAM_ADD_LANGUAGEをコールしてください。

承認パーサー

支払システムは、資金取得指図の配信を受信すると、受信確認を送信します。承認パーサーの役割は、Oracle Paymentsで理解できるように応答を解析することです。

カスタム支払システム統合を実装するには、すべての伝送関数に対して承認パーサーを作成する必要があります。支払システムでプロトコルの受信確認をサポートしていない場合でも、デフォルト値または一般的な値を戻すデフォルトの承認パーサーを作成する必要があります。

承認パーサーは、支払システムからの応答をOracle Paymentsエンジンで処理可能な形式に解析する自己完結型のコードポイントです。

承認パーサーのシード

次の表に、承認パーサーをシードする際の属性を示します。

承認パーサーの属性を定義した後は、それらをIBY_ACK_READERS表に挿入するSQLスクリプトを作成することで、定義した属性をOracle Paymentsにシードできます。

カスタム支払システム統合を実装するには、承認パーサーを実装するJavaクラスをユーザーに配布し、Oracle Paymentsエンジンをホスティングするアプリケーション・サーバーのCLASSPATHに配置する必要があります。

承認パーサーの開発

すべての承認パーサーは、oracle.apps.iby.bep.ACKParserインタフェースをサブクラス化する必要があります。このインタフェースには、次のインタフェースを備えた単一の関数parseがあります。

承認パーサーに対するhints引数は、応答の作成対象となった取引に関する情報を提供する名称/値ペアの集合です。

次の表に、この集合で使用可能な値を示します。

注意: hintsは、特定の取引タイプについてのみ移入されます。たとえば、バッチ・クローズ操作ではhintsは移入されません。

承認パーサーの戻り結果は、クラスoracle.apps.iby.bep.ACKParserから導出されたオブジェクトです。このクラスは、支払システム応答からマップされた様々な応答フィールドの保持を目的とする単一のレコードです。

ACK

抽象クラスoracle.apps.iby.bep.ACKは、すべてのサブクラスが継承する最も基本的な受信確認属性を定義します。次の表に、このクラスと派生サブクラスすべての構造を示します。

注意: 特定のクラスにリストされている各属性には、属性にアクセスするためのget<AttributeName>関数とset<AttributeName>関数が暗黙的に存在します。get<AttributeName>は属性の型のオブジェクトを戻し、set<AttributeName>は属性の型のオブジェクトを単一の引数として取得します。

TrxnACK

抽象クラスabstract class oracle.apps.iby.bep.TrxnACKは、取引の受信確認の一般的な属性を定義します。このクラスはoracle.apps.iby.bep.ACKのサブクラスであるため、その属性も継承します。

属性ExtensiblitySetはoracle.apps.iby.util.NameValuePairオブジェクトの配列として型指定されます。この属性は、適切な受信確認オブジェクトのいずれの属性にも対応しない重要なデータが、支払システムの受信確認に含まれている場合は、パーサーによって随意的に設定されることがあります。ExtensiblitySet属性で戻された名称の値は、IBY_TRXN_EXTENSIBILITY表に格納され、OriginalCCTransactionまたはOriginalDCTransaction要素の下に表示される一連のExtendサブ要素を使用して、後続取引の抽出文書に挿入されます。

次の表に、oracle.apps.iby.util.NameValuePairクラスの属性を示します。

CreditCardTrxnACK

クラスoracle.apps.iby.bep.CreditCardTrxnACKは、単一のクレジット・カード取引に関する受信確認情報を保持します。次の表に属性を示します（親クラスoracle.apps.iby.bep.TrxnACKから継承される属性は記載していません）。

BankAccountTrxnACK

クラスoracle.apps.iby.bep.BankAccountTrxnACKは、単一の預金口座取引に関する受信確認情報を保持します。次の表に属性を示します（oracle.apps.iby.bep.TrxnACKから継承される属性も記載されています）。

BatchACK

抽象クラスoracle.apps.iby.bep.BatchACKは、バッチの受信確認について一般的な属性を定義します。次の表に属性を示します（クラスoracle.apps.iby.bep.ACKから継承される属性も記載されています）。

注意: 保留中（11）以外のすべてのバッチ・ステータスは最終ステータスです。バッチの受信確認が存在しない場合に備えて、たとえば、バッチ・クローズ直後またはバッチの処理前に発生するバッチ問合せの最中に、既存の受信確認ファイルがない場合でも、バッチ・ステータス0（ゼロ）でバッチの受信確認オブジェクトを作成する必要があります。

CreditCardBatchACK

クラスoracle.apps.iby.bep.CreditCardBatchACKは、oracle.apps.iby.bep.BatchACKを拡張し、クレジット・カード・バッチの受信確認の属性が格納されます。次の表に属性を示します。

BankAccountBatchACK

クラスoracle.apps.iby.bep.BankAccountBatchACKは、oracle.apps.iby.bep.BatchACKを拡張し、クレジット・カード・バッチの受信確認の属性が格納されます。次の表に属性を示します。

カスタム支出検証セットの作成

検証セットは、支払作成プログラムによって様々な処理ポイントで実行されるコード部分です。各検証セットは一連のビジネス・ルールを適用して、考慮対象の支払エンティティがすべてのルールに合格するかどうかを判断します。すべてのルールに合格しないかぎり、検証セットは支払作成プログラムに不合格のステータスを戻します。

検証セット・レベル

検証セットを作成するには、その前に、検証に適用するレベルを決定する必要があります。検証セット・レベルは、検証ポイントとも呼ばれ、検証が必要なエンティティを決定します。次の3種類の検証レベルがあります。

• 文書

• 支払

• 支出指図

検証コード入力ポイント

支払作成プログラムは、特定のエンティティにリンクされている検証セットを動的に起動します。検証セット入力ポイントは、IBY_VALIDATION_SETS_VLビューにシードされています。次の表に、検証コード入力ポイントに関連する重要な列を示します。このビューには、シード検証セットが格納されます。

この表に示した内容と同じ検証セット・データの場合、支払作成プログラムは、PL/SQL検証セットIBY_VALIDATIONSETS_CALLS_PUB. PT_CHECK_GENを動的に起動して、買掛/未払金文書を検証します。

注意: カスタム検証セットはカスタム・パッケージ内に作成する必要があります。IBY_VALIDATIONSETS_CALLS_PUBパッケージはOracle Payments専用のため、このパッケージにはカスタム検証セットを追加しないでください。

支払エンティティへの検証セットのリンク

通常、検証セットは次の2種類の支払エンティティのいずれか1つにリンクされます。

• 方法

• フォーマット

支払方法にリンクした検証セットは、請求書の作成時にOracle Payablesで実行する請求書の検証など、オンラインでも適用できます。オンライン検証では、文書の不合格はありませんが、ユーザーには、Oracle Paymentsに文書を発行する前に警告メッセージが表示されます。これによって、文書検証サイクルでOracle Paymentsに文書を発行する前にエラーを訂正できます。請求書に対してオンライン検証が実行され、検証エラーがあると、その請求書は保留されます。オンライン検証中に発生したエラーは保留事由として表示され、その請求書は保留事由が訂正されるまで選択プログラムの選択対象外となります。支払方法にリンクした検証セットは、買掛/未払金文書がOracle Paymentsに発行される際に再度適用されます。

ほとんどのシード検証はフォーマットにリンクされます。検証セットと支払方法/フォーマット間のリンクは、検証セットと支払エンティティ間のリンクを格納するIBY_VAL_ASSIGNMENTS表に格納されます

前述の表は、検証セットPT_CHECK_GENが支払フォーマットIBY_PAY_CHK_PTにリンクされていることを示しています。検証セットPT_CHECK_GENは文書レベルで適用できるため、支払作成プログラムは、買掛/未払金文書がIBY_PAY_CHK_PTフォーマットで渡される都度、この検証を実行します。

検証セットのシグネチャ

すべての検証セットには、同じ5つの引数シグネチャが含まれています。第3パラメータは検証対象となる支払エンティティです。このパラメータは、検証をコーディングした検証レベルに従って、買掛/未払金文書、支払または支払指図のいずれかになります。

文書レベルの検証セット

文書レベルの検証はPL/SQLで実装され、次のシグネチャが必要です。

PROCEDURE MY_VALIDATION_SET(
    p_validation_assign_id  IN          
        IBY_VAL_ASSIGNMENTS.
            validation_assignment_id%TYPE,
    p_validation_set_code   IN   
        IBY_VALIDATION_SETS_VL.
            validation_set_code%TYPE,
    p_document_id           IN 
        IBY_DOCS_PAYABLE_ALL.
            document_payable_id%TYPE,
    p_is_online_val         IN VARCHAR2,
    x_result                OUT NOCOPY NUMBER
    );

前述の例は、文書レベルで適用できるMY_VALIDATION_SETという検証セットを示しています。文書レベルの検証を作成するときは、同じシグネチャを使用する必要があります。

支払レベルの検証セット

支払レベルの検証はPL/SQLで実装され、次のシグネチャが必要です。

PROCEDURE MY_VALIDATION_SET(
    p_validation_assign_id  IN          
        IBY_VAL_ASSIGNMENTS.
            validation_assignment_id%TYPE,
    p_validation_set_code   IN   
        IBY_VALIDATION_SETS_VL.
            validation_set_code%TYPE,
    p_document_id           IN 
        IBY_DOCS_PAYABLE_ALL.
            document_payable_id%TYPE,
    p_is_online_val         IN VARCHAR2,
    x_result                OUT NOCOPY NUMBER
    );

前述の例は、支払レベルで適用できるMY_VALIDATION_SETという検証セットを示しています。支払レベルの検証セットを作成するときは、同じシグネチャを使用する必要があります。

支払指図レベルの検証セット

支払指図レベルの検証はPL/SQLで実装され、次のシグネチャが必要です。

PROCEDURE MY_VALIDATION_SET(
    p_validation_assign_id  IN          
        IBY_VAL_ASSIGNMENTS.
            validation_assignment_id%TYPE,
    p_validation_set_code   IN   
        IBY_VALIDATION_SETS_VL.
            validation_set_code%TYPE,
    p_instruction_id           IN 
        IBY_PAY_INSTRUCTIONS_ALL.
            payment_instructionid%TYPE,
    p_is_online_val         IN VARCHAR2,
    x_result                OUT NOCOPY NUMBER
    );

前述の例は、支払指図レベルで適用できるMY_VALIDATION_SETという検証セットを示しています。支払指図レベルの検証セットを作成するときは、同じシグネチャを使用する必要があります。

検証セットに関する重要な注意事項

注意: p_is_online_valは、文書レベルの検証セットにのみ関係します。支払レベルと支払指図レベルの検証セットを実装する場合は無視してください。Oracle Payablesで、手動または請求書インタフェース・インポート・プログラム経由で請求書を検証するときは、文書の支払方法に添付されている検証セットが起動されます。請求書の作成時には、潜在的なエラーを捕捉するためにオンライン検証として検証セットが起動されます。したがって、Oracle Payablesでは、p_is_online_valがYに設定された状態で検証セットが起動されます。これは、検証エラー・メッセージが請求書の支払予定に警告として表示され、支払予定が保留になることを意味します。検証セットは請求時に認識されるため、適用できるのは、支払方法に割り当てた検証と銀行口座に添付したOracle Cash Management検証のみです。

注意: x_resultパラメータは、支払作成プログラムに戻される検証セットの戻り値です。ゼロ（0）の値は検証が成功したことを意味します。1の値は支払エンティティが検証で失敗したことを意味します。

検証セットで生成されるエラーの格納

検証セット内のカプセル化されたビジネス・ルールを適用することで生成されるエラー・メッセージは、ユーザーに対して表示する必要があります。

次のIBY_TRANSACTION_ERRORS表には、検証セットによって生成されるエラー・メッセージが格納されます。検証対象の支払エンティティには複数のエラー・メッセージが関連付けられる可能性があるため、この表には、特定の支払エンティティIDに対して複数の行が存在する場合があります。

文書レベルの検証セットの実装

文書レベルの検証セットは、次のプロセスに従う必要があります。

1. 提供された文書の属性をすべて取得します。文書IDは、文書レベルの検証セットに対する入力パラメータとして提供されます。

2. IBY_TRANSACTION_ERRORS表に挿入するためのエラー・レコードを作成します。

3. 関連する文書属性を使用してビジネス・ルールを適用します。

4. 文書の検証が失敗した場合は、その内容を反映するためのエラー・レコードを移入します。

5. すべてのビジネス・ルールが適用されるまで手順3と4を繰り返します。

6. すべての検証が正常に終了した場合は、ゼロ（0）を戻します。

7. いずれかの検証が失敗した場合は、そのエラー・レコードをIBY_TRANSACTION_ERRORS表に挿入し、1を戻します。

ヘルパー関数

IBYには、前述の手順の一部についてヘルパー関数が実装されています。これらの関数を使用するとコーディング時間を短縮できます。

• 手順1では、IBY_VALIDATIONSETS_PUB.initDocumentDataを使用して、すべての文書属性を取得できます。このメソッドでは入手できない他の属性が必要な場合は、独自のPL/SQLロジックを記述して、IBY_DOCS_PAYABLE_ALL表から取得する必要があります。

• 手順3では、メソッドIBY_VALIDATIONSETS_PUB.evaluateConditionを使用できます。このメソッドには、EQUALSTO、NOTEQUALSTO、NOTNULL、LENGTH、MAXLENGTHなど、いくつかの事前定義条件を指定します。このメソッドを使用すると、簡単なビジネス・ルールを実装できます。複雑なビジネス・ルールは、カスタム・コードで実装する必要があります。

• 手順4では、メソッドIBY_VALIDATIONSETS_PUB.insertIntoErrorTableを使用します。このメソッドは、取引エラー表への一括挿入に使用できるPL/SQLメモリー構造に、特定のエラー・レコードを挿入します。

• 手順7では、メソッドIBY_VALIDATIONSETS_PUB.insert_transaction_errorsを使用して、IBY_TRANSACTION_ERRORS表へのエラー・メッセージの一括挿入を実行します。このメソッドは、検証セットの最後に1回起動してください。

支払レベルの検証セットの実装

支払レベルの検証セットは、次のプロセスに従う必要があります。

1. 提供された文書の属性をすべて取得します。文書IDは、支払レベルの検証セットに対する入力パラメータとして提供されます。

2. IBY_TRANSACTION_ERRORS表に挿入するためのエラー・レコードを作成します。

3. 関連する支払属性を使用してビジネス・ルールを適用します。

4. 文書の検証が失敗した場合は、その内容を反映するためのエラー・レコードを移入します。

5. すべてのビジネス・ルールが適用されるまで手順3と4を繰り返します。

6. すべての検証が正常に終了した場合は、ゼロ（0）を戻します。

7. いずれかの検証が失敗した場合は、そのエラー・レコードをIBY_TRANSACTION_ERRORS表に挿入し、1を戻します。

ヘルパー関数

Oracle Paymentsには、前述の手順の一部についてヘルパー関数が実装されています。これらのヘルパー関数を使用するとコーディング時間を短縮できます。

• 手順1では、IBY_VALIDATIONSETS_PUB.initDocumentDataを使用して、いくつかの文書属性を取得できます。このメソッドでは入手できない他の属性が必要な場合は、独自のPL/SQLロジックを記述して、IBY_PAYMENTS_ALL表から取得する必要があります。

• 手順3では、メソッドIBY_VALIDATIONSETS_PUB.evaluateConditionを使用できます。このメソッドには、EQUALSTO、NOTEQUALSTO、NOTNULL、LENGTH、MAXLENGTHなど、いくつかの事前定義条件を指定します。このメソッドを使用すると、簡単なビジネス・ルールを実装できます。複雑なビジネス・ルールは、カスタム・コードで実装する必要があります。

• 手順4では、メソッドIBY_VALIDATIONSETS_PUB.insertIntoErrorTableを使用します。このメソッドは、取引エラー表への一括挿入に使用できるPL/SQLメモリー構造に、特定のエラー・レコードを挿入します。

• 手順7では、メソッドIBY_VALIDATIONSETS_PUB.insert_transaction_errorsを使用して、IBY_TRANSACTION_ERRORS表へのエラー・メッセージの一括挿入を実行します。このメソッドは、検証セットの最後に1回起動してください。

支払指図レベルの検証セットの実装

支払指図レベルの検証セットは、次のプロセスに従う必要があります。

1. 提供された支払指図の属性をすべて取得します。支払IDは、支払指図レベルの検証セットに対する入力パラメータとして提供されます。

2. IBY_TRANSACTION_ERRORS表に挿入するためのエラー・レコードを作成します。

3. 関連する支払指図属性を使用してビジネス・ルールを適用します。

4. 支払の検証が失敗した場合は、エラー・レコードを移入してメモリーに挿入します。

5. すべてのビジネス・ルールが適用されるまで手順3と4を繰り返します。

6. すべての検証が正常に終了した場合は、ゼロ（0）を戻します。

7. いずれかの検証が失敗した場合は、メモリー内のエラー・レコードをIBY_TRANSACTION_ERRORS表に挿入し、1を戻します。

ヘルパー関数

Oracle Paymentsには、前述の手順の一部についてヘルパー関数が実装されています。これらのヘルパー関数を使用するとコーディング時間を短縮できます。

• 手順1では、IBY_VALIDATIONSETS_PUB.initDocumentDataを使用して、すべての文書属性を取得できます。このメソッドでは入手できない他の属性が必要な場合は、独自のPL/SQLロジックを記述して、IBY_DOCS_PAYABLE_ALL表から取得する必要があります。

• 手順3では、メソッドIBY_VALIDATIONSETS_PUB.evaluateConditionを使用できます。このメソッドには、EQUALSTO、NOTEQUALSTO、NOTNULL、LENGTH、MAXLENGTHなど、いくつかの事前定義条件を指定します。このメソッドを使用すると、簡単なビジネス・ルールを実装できます。複雑なビジネス・ルールは、カスタム・コードで実装する必要があります。

• 手順4では、メソッドIBY_VALIDATIONSETS_PUB.insertIntoErrorTableを使用します。このメソッドは、取引エラー表への一括挿入に使用できるPL/SQLメモリー構造に、特定のエラー・レコードを挿入します。

• 手順7では、メソッドIBY_VALIDATIONSETS_PUB.insert_transaction_errorsを使用して、IBY_TRANSACTION_ERRORS表へのエラー・メッセージの一括挿入を実行します。このメソッドは、検証セットの最後に1回起動してください。

カスタム検証ロジックの実装

すべての基本的な検証には、できるかぎりメソッドIBY_VALIDATIONSETS_PUB.evaluateConditionを使用してください。このメソッドに適切なトークン値を渡すことで、一般的な検証条件（フィールドがNULLかどうかの確認、金額が指定の限度額未満か以上かの検証など）のほどんどを網羅できます。

必要な検証が複雑で、通常のトークン演算子の使用では検証を実装できない場合は、evaluateConditionをコールする際に特別なトークンCUSTOMを使用します。CUSTOMトークンを使用すると、evaluateConditionでは、指定の検証メソッドが動的に起動されます。起動するメソッドは、引数としてevaluateConditionに渡す必要があります。

例

次のコードは、CUSTOMトークンを使用してevaluateConditionを起動する例を示しています。

IBY_VALIDATIONSETS_PUB.evaluateCondition
(
'PAYEE_BANK_SWIFT_CODE',
l_payee_bank_swift_code,
'CUSTOM',   /* token (operator) is ‘CUSTOM’ */
'DFPML.VAL_SWFT_CD', /* custom method to be invoked */
null, 
l_valResult, 
l_docErrorRec
);

evaluateConditionに対するフィールド名とフィールド値のパラメータは、カスタム検証メソッドに渡されます。これらのパラメータはevaluateConditionメソッドに対する最初の2つの引数です。カスタム検証メソッドは、OUTパラメータである第3パラメータを使用して、検証の成否を指定する必要があります。OUTパラメータがゼロ（0）の場合は、カスタム検証が成功したこと（それ以外の場合は失敗）を意味します。

カスタム検証メソッドは、次のシグネチャに従う必要があります。

PROCEDURE <custom validation name>(
    p_fieldName VARCHAR2,
    p_fieldValue VARCHAR2,
    l_chr OUT NOCOPY VARCHAR2
    );

たとえば、カスタム検証メソッドは次のようになります。

PROCEDURE VAL_SWFT_CD(
    p_fieldName VARCHAR2,
    p_fieldValue VARCHAR2,
    l_chr OUT NOCOPY VARCHAR2
    ) 
IS
BEGIN
    /*
     * Do some validations here on the field value.
     */

    :
    :
   
    /*
     * Return ‘0’ if everything is Ok. Else
     * return ‘1’.
     */
    l_chr := '0'; /* success */
END VAL_SWFT_CD;

コード例

検証セットの実装例では、次のファイルに注意してください。

$IBY_TOP/patch/115/sql/ibyvalcs.pls 
$IBY_TOP/patch/115/sql/ibyvalcb.pls

これらの2つのファイルは、Oracle Paymentsによってシードされた検証セットのPL/SQL仕様部と本体です。本体には、文書レベル、支払レベルおよび支払指図レベルでの検証セットが含まれています。できるかぎり多くのコードを再利用することをお薦めします。

カスタム検証セットのシード

検証セットを作成した後は、その検証セットをIBY_VALIDATION_SETS_VL表にシードすることを忘れないでください。

IBY_VALIDATION_SETS_VLはビューであるため、新規に作成した検証セットはIBY_VALIDATION_SETS_VLに直接挿入できません。次の手順で挿入する必要があります。

1. 検証セットをIBY_VALIDATION_SETS_B表に挿入します。これは、変換可能なテキストを含まない基礎表です。

   例:

   insert into iby_validation_sets_b (validation_set_code,validation_level_code,validation_code_package,validation_code_entry_point,validation_code_language,created_by,creation_date,last_updated_by,last_update_date,last_update_login, object_version_number) values 
   ('paymul_pmt_validations','PAYMENT','mis_iby_val_pkg','mis_iby_gen_val_pmt_pml','plsql','294110',sysdate,'294110',sysdate,'294110',1);
   

2. 検証セットをIBY_VALIDATION_SETS_TL表に挿入します。この表には変換可能なテキストが含まれています。検証セット名は変換可能です。

   例:

   insert into iby_validation_sets_tl (validation_set_code,language,source_lang,validation_set_display_name,created_by,creation_date,last_updated_by,last_update_date,last_update_login,object_version_number) values 
   ('paymul_pmt_validations','us','us','paymul eft validation-payment level','294110',sysdate,'294110',sysdate,'294110',1);
   

この時点で、検証セットが「Oracle Payments設定」ページに表示されるようになります。ナビゲータ・パスは「Oracle Payments設定」 > 「支払設定」 > 「共有設定」 > 「検証」です。

検証セットは、支払方法や支払フォーマットなどの適切な支払エンティティにリンクできます。その後は、支払作成プログラムを実行して、検証ロジックをテストできます。

検証セットの実装に関する重要な注意事項

検証セットの実装に関する重要な注意事項は、次のとおりです。

• COMMITまたはROLLBACKコールは検証セット内に挿入しないでください。検証エンジンがCOMMITを実行するのは、検証セットを起動した後です。

• カスタム検証セットには、その検証セット内から別の表のデータを操作または問い合せるDMLコマンドを指定できます。ただし、変更した内容は、検証セットが起動された後、検証エンジンによってコミットされることに注意してください。

• 検証セット内の表またはビューを作成、変更または削除するDDLコマンドは使用しないでください。DDL文では暗黙的なコミットが発生します。

• 検証セットは支払エンティティごとに1回起動されます。文書レベルの検証セットは、支払プロセス要求の文書ごとに1回起動されます。支払レベルの検証セットは、作成した支払ごとに1回起動されます。したがって、検証セットは単純で効率的にすることが重要です。そうしないと、検証セットによって多大なパフォーマンス・コストが発生する可能性があります。

• 新規に作成した検証セットは、IBY_VALIDATION_SETS_VL表に直接挿入できません。これは、この表がビューであるためです。検証セットをIBY_VALIDATION_SETS_VL表に挿入するには、最初に基礎表IBY_VALIDATION_SETS_Bに挿入し、次に変換可能な表IBY_VALIDATION_SETS_TLに挿入するという2段階の手順が必要です。

• 検証セットは、可能なかぎりヘルパー関数IBY_VALIDATIONSETS_PUB.evaluateConditionを起動して検証することをお薦めします。

検証セットには、次の2つのコールも含める必要があります。

/*	
 * Inserts the error generated by a single 
 * validation within the validation set into 
 * the l_docErrorTab temporary PLSQL table.  
 *
 * Similarly, you can have l_pmtErrorTab
 * for payments.
 *
 * This call should be invoked once after each 
 * validation to accumulate all the error
 * messages in l_docErrorTab.
 */
IBY_VALIDATIONSETS_PUB.insertIntoErrorTable(l_docErrorRec, l_docErrorTab);

/*
 * Permanently inserts all the error messages 
 * in l_docErrorTab into the
 * IBY_TRANSACTION_ERRORS table.
 *
 * This call should be invoked only once at 
 * the end of your validation set.
 */
IBY_VALIDATIONSETS_PUB.insert_transaction_errors(p_is_online_val,l_docErrorTab); 

カスタム資金取得検証セットの作成

検証セットは、支払処理エンティティ（通常は、資金取得オーダー（支払取引）または支払バッチ）に対して一連の検証を実行するプログラム・ユニットです。各検証セットは一連のビジネス・ルールを適用して、考慮対象の支払エンティティがすべてのルールに合格するかどうかを判断します。資金取得検証セットは、Java関数またはPL/SQLプロシージャとして実装でき、支払エンジンによって動的に起動されます。

検証セット・レベル

検証セットを作成するには、その前に、検証に適用するレベルを決定する必要があります。検証セット・レベルは、検証ポイントとも呼ばれ、検証が必要なエンティティを決定します。次の2種類の検証レベルがあります。

• オーダー

• 指図

オーダー・レベルの検証は取引レベルの検証です。指図レベルの検証はバッチ・レベルの検証です。オーダー・レベルの検証はJavaで実装され、指図レベルの検証はPL/SQLで実装されます。

検証コード入力ポイント

支払エンジンは、特定のエンティティにリンクされている検証セットを動的に起動します。検証セット入力ポイントは、IBY_VALIDATION_SETS_VLビューにシードされています。次の表に、検証コード入力ポイントに関連する列を示します。IBY_VALIDATION_SETS_VL表には、シード検証セットが格納されます。

前述の表で示した同じ検証セット・データについては、支払エンジンがJava検証セットoracle.apps.iby.bep.proc.paymentech.FundsCaptureValidationSet.validateを動的に起動して取引を検証します。

注意: 検証セットは独自のクラスに作成できます。oracle.apps.iby.bep.proc.paymentech.FundsCaptureValidationSetクラスには、カスタム検証セットを追加しないでください。このクラスはOracle Payments専用です。

次のIBY_VALIDATION_SETS_VL表（シード検証セットが格納される表）に、PL/SQL検証のシード検証セット入力ポイントを示します。

前述の表で示した同じ検証セット・データについては、支払エンジンがPL/SQL検証セットIBY_FNDCPT_VLD_PUB.Validate_Paymentech_Batchを動的に起動して支払指図（支払バッチ）を検証します。

支払エンティティへの検証セットのリンク

資金取得検証セットは、次の支払エンティティにのみリンクされます。

• フォーマット

検証セットと支払エンティティ間のリンクは、次のIBY_VAL_ASSIGNMENTS表に格納されます。

前述のIBY_VAL_ASSIGNMENTS表の例は、検証セットPTK_ONLINE_7_2_BATCH_2_1_0が支払フォーマットPTECH_ONLINE_7_2にリンクされていることを示しています。検証セットPTK_ONLINE_7_2_BATCH_2_1_0はオーダー・レベルで適用できるため、支払エンジンは、オーダーがフォーマットPTECH_ONLINE_7_2で渡される都度、この検証を実行します。

検証セットのシグネチャ

支払システム・フォーマット固有の検証は、支払エンジン内で、JavaおよびPL/SQLで実装された検証セットのコードポイント別に実行され、特定の支払システム・フォーマットに関連付けられます。

取引レベルの検証セット

取引レベルのJava検証セットの実装は、次のクラス・インタフェースに準拠している必要があります。

oracle.apps.iby.payment.FndCptValidationSet.

このインタフェース・クラスには、validateという単一のメソッドがあります。このメソッドのシグネチャは、次の表のとおりです。

validateメソッドはValidationSetResultオブジェクトを介して検証の結果を戻します。ValidationSetResultオブジェクトには次の要素が含まれています。

バッチ・レベルの検証セット

バッチ・レベルの検証はPL/SQLで実装され、次のシグネチャが必要です。

取引レベルの検証セットの実装

取引レベルの検証セットは、次のプロセスに従う必要があります。

1. 検証セットは、oracle.apps.iby.payment.FndCptValidationSetインタフェースを実装するクラスでコーディングしてください。つまり、検証セット・クラスにはvalidateメソッドを含める必要があります。

2. validateメソッドは、受取人、支払手段、実際のオーダーおよび取引の各属性をカプセル化する入力パラメータとともに起動されます。関連する属性にはビジネス・ルールを適用します。

3. いずれかの属性が検証に失敗した場合は、エラー・コードとエラー・メッセージを備えたoracle.apps.iby.engine.ValidationSetResultオブジェクトを移入して戻ります。

4. すべての検証が成功した場合は、ValidationSetResultオブジェクトの結果コードをSUCCESSに設定します。

5. oracle.apps.iby.payment.FndCptValidationSetインタフェースの、次の支払システム固有の実装は、参照として使用できます。次の表に、各実装および関連する支払システム・フォーマットを示します。

バッチ・レベルの検証セットの実装

バッチ・レベルの検証セットは、次のプロセスに従う必要があります。

1. シグネチャを使用して、バッチ・レベルの検証セットを実装します。

2. 検証の入力パラメータとして提供されるパラメータmbatchidは、IBY_BATCHES_ALL表に対する主キーです。このパラメータを使用すると、IBY_BATCHES_ALL表からバッチの詳細を取得したり、IBY_TRXN_SUMMARIES_ALL表に連結して、取引の詳細を取得することもできます。

3. 関連する支払属性にビジネス・ルールを適用します。

4. いずれかの属性が検証に失敗した場合は、x_return_status出力パラメータをFND_API.G_RET_STS_ERRORに設定します。FNDメッセージ・スタックでエラー・メッセージを移入して戻ります。

5. すべての検証が成功した場合は、set x_return_statusをFND_API.G_RET_STS_SUCCESSに設定して戻ります。

6. バッチ・レベルの検証の参照実装には、パッケージIBY_FNDCPT_VLD_PUB（$IBY_TOP/patch/115/sql/ibypfcvb.pls）を参照できます。Paymentechに送信するクレジット・カード・バッチの検証には、メソッドValidate_Paymentech_Batchが使用されます。同様に、FDC North支払システムに送信するクレジット・カード・バッチの検証には、メソッドValidate_FDCNorth_Batchが使用されます。

カスタム検証セットのシード

検証セットを作成した後は、その検証セットをIBY_VALIDATION_SETS_VL表にシードすることを忘れないでください。

IBY_VALIDATION_SETS_VLはビューであるため、新規に作成した検証セットはIBY_VALIDATION_SETS_VLに直接挿入できません。次の手順で挿入する必要があります。

1. 検証セットをIBY_VALIDATION_SETS_B表に挿入します。これは、変換可能なテキストを含まない基礎表です。

   例:

   insert into iby_validation_sets_b (validation_set_code,validation_level_code,validation_code_package,validation_code_entry_point,validation_code_language,created_by,creation_date,last_updated_by,last_update_date,last_update_login, object_version_number) values 
   ('my_cc_validations','ORDER', 'oracle.apps.iby.bep.proc.myproc.FundsCaptureValidationSet,'validate',’JAVA','294110',sysdate,'294110',sysdate,'294110',1);
   

2. 検証セットをIBY_VALIDATION_SETS_TL表に挿入します。この表には変換可能なテキストが含まれています。検証セット名は変換可能です。

   例:

   insert into iby_validation_sets_tl (validation_set_code,language,source_lang,validation_set_display_name,created_by,creation_date,last_updated_by,last_update_date,last_update_login,object_version_number) values 
   ('my_cc_validations','us','us','My credit card validatons','294110',sysdate,'294110',sysdate,'294110',1);
   

この時点で、検証セットが「Oracle Payments設定」ページに表示されるようになります。ナビゲータ・パスは「Oracle Payments設定」 > 「支払設定」 > 「共有設定」 > 「検証」です。

検証セットは、資金取得支払方法およびフォーマットなどの適切な支払エンティティにリンクできます。

これで、取引を作成してバッチを発行することで、検証ロジックをテストできます。

検証セットの実装に関する重要な注意事項

検証セットの実装に関する重要な注意事項は、次のとおりです。

• COMMITまたはROLLBACKコールは検証セット内に挿入しないでください。検証エンジンがCOMMITを実行するのは、検証セットを起動した後です。

• カスタム検証セットには、その検証セット内から別の表のデータを操作または問い合せるDMLコマンドを指定できます。ただし、変更した内容は、検証セットが起動された後、検証エンジンによってコミットされることに注意してください。

• 検証セット内の表またはビューを作成、変更または削除するDDLコマンドは使用しないでください。DDL文では暗黙的なコミットが発生します。

• 検証セットは支払エンティティごとに1回起動されます。オーダー・レベルの検証セットは取引ごとに1回起動されます。バッチ・レベルの検証セットは、支払バッチごとに1回起動されます。したがって、検証セットはを単純で効率的にすることが重要です。そうしないと、検証セットによって多大なパフォーマンス・コストが発生する可能性があります。

• 新規に作成した検証セットは、IBY_VALIDATION_SETS_VL表に直接挿入できません。これは、この表がビューであるためです。検証セットをIBY_VALIDATION_SETS_VL表に挿入するには、最初に基礎表IBY_VALIDATION_SETS_Bに挿入し、次に変換可能な表IBY_VALIDATION_SETS_TLに挿入するという2段階の手順が必要です。

Copyright © 2000, 2007, Oracle. All rights reserved.