1. オーダー管理の実装
  2. Webサービスを使用したオーダー管理の統合に関するガイドライン
機械翻訳について

Webサービスを使用したOrder Managementの統合に関するガイドライン

ガイドラインを適用して、オーダー管理を使用する他のシステムとの統合がスムーズに行われるようにします。

プラン

統合の計画

要件

説明

ソース・システムを登録します。

オーダー・リクエストを送信する各ソース・システムをソース・システムとして登録する必要があります。

複数のソース・システムによってソース・オーダーが作成される可能性があるため、webサービスには、オーダーを送信するソース・システムを追跡できるように、オーダーのソース・システムを識別する詳細が格納されます。

webサービスは、相互参照中にソース・システムを使用して、ソース・システムに固有の対応する内部識別子または値を決定します。

顧客マスター・データの同期方法を計画します。

ソース・オーダーをインポートする前に、顧客マスター・データを同期する必要があります。

オーダーの顧客がサービス・スキーマのCreateCustomerInformationFlagプリファレンスに従ってOracle Tradingの顧客モデルに存在しない場合、オーダー管理は顧客詳細を作成できます。

Oracle Configure, Price, and Quote Cloudの属性を計画します。

Oracle Configure, Price, and Quote Cloud (CPQ)を使用すると、CPQは、FreezePriceFlag、FreezeShippingChargeFlag、FreezeTaxFlagなど、オーダー管理がこの機能を使用するために必要な属性に関する詳細を送信します。

価格設定を計画します。

アップストリーム・システムにすでに価格設定されているソース・オーダーを送信することも、webサービスでソース・オーダーの価格を設定することもできます。

Oracle Configure, Price, and Quote Cloudの事前定義済実装を使用する場合、webサービスでは、アップストリーム・システムがソース・オーダーをすでに価格設定していると想定され、オーダー管理での価格変更は許可されません。

下書き販売オーダーの処理方法を計画します。

ソース・システムは、送信済ソース・オーダーまたは下書きステータスのソース・オーダーを送信できます。

  • ソース・オーダーが下書きステータスの場合は、ソース・オーダーを参照する販売オーダーを発行する必要があります。

  • オーダー管理では、販売オーダーを発行するまで、販売オーダーを履行するオーケストレーション・プロセスは実行されません。

  • webサービスでドラフト・ステータスのオーダーが作成された場合は、オーダー管理作業領域からオーダーを発行するか、Webサービスで操作SubmitDraftOrderを使用してオーダーを発行できます。

  • SubmitDraftOrderを使用する場合は、これを定義するペイロードを追加する必要があります。

非同期または同期サービスの使用

非同期または同期

説明

サービスを使用する統合プラットフォームまたはアプリケーションは、非同期サービスをサポートします。

非同期は同期よりも回復性が高く、フォルト・トレラントであるため、非同期操作を使用します。 何らかの理由で履行システムからのレスポンスが遅延した場合、非同期操作の処理を続行できますが、同期操作がタイムアウトしてエラー状態になる可能性があります。

プラットフォームまたはアプリケーションは非同期サービスをサポートしていないか、実装がより複雑であるため非同期を使用しないことをお薦めします。

販売オーダーのライン数が300秒後にタイムアウトしなければ同期を使用します。

同期を使用し、販売オーダーがタイムアウトした場合は、販売オーダーを再発行するように実装を設定する必要があります。

複数の販売オーダーを処理

オーダー・インポート・サービスの次の操作を使用します。

  • stageOrders. ペイロードで複数の販売オーダーを受け入れることができる唯一の操作。

  • createOrders. ペイロードで受け入れることができる販売オーダーは1つのみです。

オーダー・リクエストの受入webサービスは、ペイロード内の1つの販売オーダーのみを受け入れることができます。

オーダー・インポート・サービスで使用できる入力メッセージおよび出力メッセージについて学習します。 詳細は、「Oracle SCM用SOAP Webサービス」、「ビジネス・オブジェクト・サービス」>「販売オーダーのインポート」の順に展開します。

ペイロードで正しい階層が使用されていることを確認

Webサービスでサポートされるエンティティ階層

ペイロードでこのエンティティ階層が使用されていることを確認してください。

  • ヘッダー

    • オーダー支払

    • オーダー販売実績

    • オーダー添付

    • オーダー明細

      • 行LotSerial

      • 行SalesCredit

      • 明細支払

      • 明細文書参照

      • 明細添付

      • 明細トランザクション属性

      • 手数料

        • 手数料コンポーネント

    • オーダー・プリファレンス

論理データ・モデル

ペイロードがデータ・モデルに対応できることを確認します。

ペイロードがデータ・モデルに対応できることを確認します。

応答ペイロード

統合で、オーダー管理が送信するレスポンスに対応できることを確認します。 レスポンス・ペイロードはステータスを返します。

ステータス

説明

SUCCESS

レスポンスには、ソース・キーとオーダー管理キーが含まれます。 このレスポンスは、オーダー管理によって販売オーダーが正常に作成された後に送信されます。

FAILURE

レスポンスには、最初の検証エラー・メッセージが表示されます。

レスポンス・ペイロードはこの構造を使用します。

レスポンス・ペイロードはこの構造を使用します。

ペイロードでの属性の指定

グループ内の属性の指定

ペイロードに必要な詳細がすべて含まれていることを確認するために、webサービスはいくつかの属性をグループとして処理します。 たとえば、ペイロードで購買パーティが識別されるように、webサービスがグループとして調査する属性を次に示します。

  1. BuyingPartyId

  2. BuyingPartyName

  3. BuyingPartyNumber

webサービスが各グループを処理するときに使用する順序を次に示します。

  1. 識別子を指定する属性(BuyingPartyIdなど)を使用します。

  2. 識別子を指定する属性が空の場合は、数値を指定する属性(BuyingPartyNumberなど)を使用します。

  3. 数値を指定する属性が空の場合は、BuyingPartyNameなどの名前を指定する属性を使用します。

識別子を指定する属性に値が含まれている場合、名前または番号を指定する属性が空でない場合でも、webサービスは常にこの値を使用します。

ペイロードに識別子、名前または番号の値が含まれていない場合は、オーダーのインポートが失敗する可能性があります。

コード化された属性とそのパートナの指定

ReturnReasonCodeなどの一部の属性は、長期間の略語を格納します。 略称は通常、参照値の意味をすばやく識別するためにユーザーが表示できるテキストです。

この属性の値はコード化されていると考えることができます。 コード化された属性には通常、パートナ属性が含まれます。 たとえば、ReturnReason属性はReturnReasonCodeのパートナです。

ペイロードのコード化された属性にのみ値を指定した場合、オーダー管理では、参照値から意味へのデータベース相互参照の値が使用されます。 たとえば、RET参照値をRETの意味(Return)に相互参照します。

この例では、ペイロードにReturnReasonCode=RETを設定するとします。

  • ReturnReason="Return Order"を設定すると、webサービスはこの値を無視し、コードを使用します。 この動作は、名前を指定しない場合の識別子の使用に似ています。

  • ReturnReasonの値を指定せず、データベースの意味への相互参照の値がReturnの場合、webサービスでは理由としてReturnが使用されます。

webサービスでは、これらの属性セットごとにこのロジックが使用されます。

コード化された属性

パートナ属性

AccountingRulecode

AccountingRule

CancelReasonCode

CancelReason

ChargeDefinitionCode

ChargeDefinition

ChargeSubtypeCode

ChargeSubType

DemandClassCode

DemandClass

FOBPointcode

FOBPoint

FreightTermsCode

FreightTerms

InvoicingRuleCode

InvoicingRule

OrderedUOMCode

OrderedUOM

PaymentMethodCode

PaymentMethod

PaymentTerm

PaymentTermCode

RequestedFulfillmentOrganizationCode

RequestedFulfillmentOrganizationName

RequestedSupplierCode

RequestedSupplierName

ShipmentPriorityCode

ShipmentPriority

ShippingCarrierCode

ShippingCarrier

ShippingModeCode

ShippingMode

ShippingServiceLevelCode

ShippingServiceLevel

SubInventoryCode

保管場所

SubstitutionReasonCode

SubstitutionReason

TaxExemptReasonCode

TaxExemptReason

TransactionalCurrencyCode

TransactionalCurrencyName

TransactionLineTypeCode

TransactionLineType

識別子と値を含める

名前に識別子という語を含む属性を使用して、ビジネス・ユニット識別子のリクエストなどの識別子を送信します。 識別子と識別子の値を送信すると、webサービスは識別子を使用します。

マスター・データには、顧客と品目が含まれます。 ソース・システムは、オーダー管理で使用される同じマスター・データと参照データのどちらを使用しているかに応じて、異なる詳細を送信できます。

  • 同じデータを使用します。 ソース・システムは、Oracle識別子または値を送信できます。

  • 同じデータを使用しません。 ソース・システムは、そこに含まれる識別子と値を送信できます。 オーダー・インポート・サービスでは、キーが顧客データを参照するか製品データを参照するかに応じて、それらをキーとして使用して相互参照を検索します。 クロス・リファレンスが次の場所にある場合:

    • Oracle Trading Community ModelをOracle顧客データに解決

    • Product Information Managementを実行し、Oracle製品データに解決

通常、各サービスは同期操作と非同期操作のペアを使用します。 サービスは、値とともに操作名を追加します。

  • Sync. ペアのもう1つの操作は非同期です。

  • Async. ペアのもう1つの操作は同期です。

変更オーダーの処理およびオーダーの取消

変更オーダーの処理

販売オーダーを変更するには、次の詳細を含むペイロードを使用してwebサービスをコールします:

  • ソース・トランザクション・システム

  • ソース・トランザクション識別子

  • オーダー管理がすでに処理した販売オーダーのオーダー番号およびソース・トランザクション番号

webサービスは、ソース・トランザクション・システムとソース・トランザクション識別子の組合せに従って、オーダーを変更オーダーとして処理します。

  • 販売オーダーの作成に使用したものと同じwebサービスを使用します。 変更オーダーのペイロード構造は、作成オーダーのペイロード構造に似ています。

  • 各属性の変更済値を送信するようにペイロードを設計します。

  • ペイロードに、変更するオーダー明細のすべての属性が含まれていることを確認してください。

  • Oracle Application Development Framework (ADF)を使用する場合は、明細の一部を変更しない場合でも、ペイロードにオーダー明細全体を含める必要があります。 ただし、REST APIまたはREST APIでREST APIまたはFBDIを使用する場合は、その行全体をペイロードから除外できます。 たとえば、販売オーダーに100の明細があるが、変更が必要なのはオーダー明細1001のみの場合、REST APIまたはFBDIをREST APIとともに使用して明細1001のみをインポートできます。 詳細は、「FBDIおよびREST APIを使用した大量の販売オーダーのインポート」を参照してください。

販売オーダーの取消

販売オーダーまたはオーダー明細を取り消すには、販売オーダーの作成に使用したものと同じwebサービスをコールします。

ペイロードに含める詳細を次に示します。

取消する内容

説明

販売オーダー全体を取り消します。

オーダー・ヘッダーのOperationCodeをCANCELに設定します。 また、ソース・トランザクション・システムを識別し、ソース・トランザクション識別子を含める必要があります。

オーダー明細全体を取り消します。

オーダーのSourceTransactionLineIdentifierおよびSourceTransactionScheduleIdentifierを送信します。 いずれかを行います。

  • オーダー明細のOperationCode属性を取消に設定します。

  • オーダー数量属性を0に設定します。

出荷済オーダー明細の一部を取り消します。

オーダー数量をすでに出荷された数量に設定します。 たとえば、元のオーダー明細の数量が10個で、出荷数が7個で、バックオーダーが3個の場合は、ペイロードのオーダー数量を7個に設定します。

ペイロードに元のオーダー明細の他のすべての属性も含まれていることを確認してください。

オーダー明細の一部の取消の例

例について考えてみます。

  • 当初オーダー数量は100です

  • 出荷済数量は40です

  • 出荷待ち数量またはバックオーダー数量が60です

次の値を使用します。

シナリオ

更新サービスのペイロードで送信する数量

説明

顧客は改訂合計数量55を必要としています。

55

ペイロードの数量55が元の品質に置換されます。

40がすでに出荷されているため、オーダー履行では、現在出荷待ちまたはバックオーダー中の60のうち45が取消され、出荷待ちまたはバックオーダー中の15が残ります。

出荷されていない数量を取り消す必要があります。

40

ペイロード内の数量40が元の品質に置換されます。

オーダー履行では、現在出荷待ちまたはバックオーダー中の60が取消されます。

出荷済数量が0、出荷待ち数量が100であると想定し、数量全体を取り消す必要があります。

0

ペイロード内の数量0が元の品質に置き換わります。

オーダー履行では、現在出荷待ちの100が取消されます。

Webサービスでのセキュリティの使用

webサービスは、LPAセキュリティ・ポリシーをサービスとコールバックにアタッチします。 これにはハイブリッド・ポリシーが含まれます。

  • oracle/wss11_saml_or_username_token_with_message_protection_service_policy

このポリシーでは、これを含む5つの異なるアサーションをサポートしています。

  • oracle/wss_username_token_over_ssl_client_policy

コールバックには添付ファイルが含まれています。

  • oracle/wss_username_token_over_ssl_client_policy LPA

これらの設定を使用して、SSL (Secure Sockets Layer)でのみwebサービスをコールします。

ファイルを使用したソース・オーダーのインポート

ソース・オーダーをインポートするには、オーダー・インポート・テンプレートを使用します。 エラーを減らし、オーダーのインポートを簡素化します。 Oracleデータベースに必要な構造が含まれています。 たとえば、データベース表ごとにタブが含まれ、これらのタブは特定の順序で表示されます。

ファイルを使用したソース・オーダーのインポートを自動化します。 Oracleには、Oracle WebCenter Contentをホストするサーバーに完了したインポート・テンプレートをアップロードするために使用できるwebサービスのセットが用意されています。 次に、アップロードされたファイルをインタフェース表にインポートして処理し、各インタフェース・レコードを販売オーダーとしてインポートするスケジュール済プロセスを実行します。 詳細は、「Oracle IntegrationでのOracle ERP Cloudアダプタの使用」を参照してください。

次に、スケジュール済プロセスの実行時に使用するパラメータを示します。

パラメータ

値

JobDefinitionName

ImportOrdersJob

JobPackageName

oracle/apps/ess/scm/doo/decomposition/receiveTransform/receiveSalesOrder

関連トピック