機械翻訳について

自分のタスク・タイプの作成

タスク・タイプを作成して、履行タスクの終了に使用するサービスを指定します。

Get_Customer_Acceptanceという名前の新しいタスク・タイプを作成する必要があるとします。

1. 「設定および保守」作業領域に移動してから、タスクに移動します。

   • オファリング: オーダー管理

   • 機能領域: オーダー

   • タスク: タスク・タイプの管理

2. タスク・タイプを追加します。

   • 「タスク・タイプの管理」ページで、「処理」>「カスタムの追加」をクリックします。

   • ページによって新しい行が追加されます。 値を入力します。

     属性	値
     タスク・タイプ	Get_Customer_Acceptance

   • タスク・タイプ属性をステップ・アウトします。

   Servicesリストにサービスが追加されています。 ページでは、タスク・タイプ属性に入力した値がコピーされ、サービスのタイプ(作成など)とともに追加されてから、サービスのコード列に値が挿入されます。 たとえば:

   コード	名前
   Get_Customer_Acceptance作成	Get_Customer_Acceptance作成
   Get_Customer_Acceptanceインバウンド	Get_Customer_Acceptanceインバウンド

   ノート

   • 1つのサービスがアウトバウンド作成操作コードを参照します。

   • 別のサービスがインバウンド操作コードを参照しています。

   • 新しいタスク・タイプごとに少なくとも1つのタスクを作成する必要があります。

   • 各サービスの名前を指定でき、変更、ステータスの取得、保留の適用、保留解除または取消などの他の操作コードを参照するサービスを追加できます。

   • Task Type(タスク・タイプ)属性をステップ・アウトしてからTask Type(タスク・タイプ)属性に戻り、値を変更した場合、ページはCode(コード)列の値を更新せず、タスク・タイプと参照するサービスの間の値が異なります。 「保存」をクリックすると、サービス・リストのコード属性が読取り専用になり、変更できません。

     タスク・タイプとそのサービスは機能しますが、タスク・タイプとは異なるコード名を持つと、設定の他の部分で混乱する可能性があります。 そのため、タスク・タイプ属性を変更する場合は、保存をクリックする前に、サービス・リストのコードも変更することをお薦めします。

     たとえば、新しいタスク・タイプを作成し、タスク・タイプ属性をGet_Customer_Acceptanceに設定し、属性からTabでGet_Customer_Acceptance Createサービスを追加し、タスク・タイプ属性をGet_Customer_Acceptance_During_Drop_Shipに変更しても、サービスのコード属性はGet_Customer_Acceptance Createのままであるとします。 「保存」をクリックする前に、サービス・リストのコード列をGet_Customer_Acceptance_During_Drop_Ship Createに変更することをお薦めします。

3. タスク・タイプにステータス・コードを割り当てます。

   オーダー管理では、保留、変更保留、取消または取消済など、一部のシステム・ステータス・コードのデフォルト値が設定されます。 各タスク・タイプが参照するステータス・コードによって、タスク・タイプを使用する待機ステップの終了基準の値と、次のオーケストレーション・プロセス・ステップのタスク・ステータスの値も制御されます。 新しいステータス・コードを作成することも、すでに存在するステータス・コードを割り当てることもできます。 詳細は、「ステータス値の管理」を参照してください。

4. タスク・ステータス条件を管理します。 詳細は、「タスク・ステータス条件の管理」を参照してください。

5. 「保存」をクリックします。

6. 新しいタスク・タイプが参照するタスクおよびサービスを実行する履行システムにオーダー管理を接続します。 詳細は、「オーダー管理を履行システムに接続する概要」を参照してください。

7. オーケストレーション・プロセス・ステップの作成時に新しいタスク・タイプを参照します。

   事前定義済タスク・タイプを参照するのと同じ方法で参照します。

終了基準、分岐、待機ステップおよびオーケストレーション・プロセスでのタスク・タイプの使用の詳細は、「オーケストレーション・プロセスの概要」を参照してください。

履行システムへのレスポンスの送信

履行システムにレスポンスを送信するには、webサービスを使用する必要があります。

• 使用するペイロードは、使用するサービスによって異なります。
• これらのサービスは、即時レスポンスまたは遅延レスポンスを提供できます。
• 1つのWSDLを即時レスポンスに使用し、別のWSDLを遅延レスポンスに使用します。

詳細は、「オーダー管理を履行システムに接続」を参照してください。

オーダー履行レスポンス・サービス

次に例を示します。

<ns1:FulfillmentRequest
xmlns:ns1="http://xmlns.oracle.com/apps/scm/doo/taskLayer/fulfillOrder/DooTaskFulfillOrderResponseInterfaceComposite">
  <ns1:FLine
xmlns:ns2="http://xmlns.oracle.com/apps/scm/doo/common/process/model/">
<ns2:SourceOrderSystem>LEG</ns2:SourceOrderSystem>
  <ns2:FulfillLineId>300100135839049</ns2:FulfillLineId>
  <ns2:Status>COMPLETED</ns2:Status>
  <ns2:TaskType>my_task_type</ns2:TaskType>
  </ns1:FLine>
</ns1:FulfillmentRequest>

説明

• LEGは、ソース・システムの名前の例です。 LEGという用語は、通常、「レガシー」を意味します。 ソース・システムを識別する名前に置き換えます。

• 履行明細を識別する値の例として、300100135839049があります。 明細を識別する値に置き換えます。
• ステータス属性の完了は、履行明細のステータスです。 明細のステータスに置き換えます。
• my_task_typeは、カスタム・タスク・タイプの名前です。 作成したタスク・タイプの名前に置き換えます。

これらの各属性に値を指定する必要があります。

オーダー履行レスポンス・サービス

次に例を示します。

 <typ:processFulfillmentResponse>
  <typ:responseMessageHeader>
            
<com:IntegrationContextCode>ExportCompliance</com:IntegrationContextCode>
  <com:FulfillmentSystem>LEG</com:FulfillmentSystem>
  </typ:responseMessageHeader>
  <!--Zero or more repetitions:-->
  <typ:fulfillLineList>
          
<com:FulfillLineIdentifier>300100564138254</com:FulfillLineIdentifier>
            
<com:TaskInstanceStatusCode>COMPLETED_VAR</com:TaskInstanceStatusCode>
  </typ:fulfillLineList>
</typ:processFulfillmentResponse>

説明

• LEGは履行システム名の例です。 履行システムを識別する名前に置き換えます。
• 履行明細を識別する値の例として、300100564138254があります。 明細を識別する値に置き換えます。
• COMPLETED_VARは、カスタム・タスク・タイプのステータスです。 これをタスク・タイプのステータスに置き換えます。

これらの各属性に値を指定する必要があります。

データ整合性の維持

オーダー管理では、新しいタスク・タイプのデータ整合性が自動的に維持されます。 次の特徴があります:

• サービス・データ・オブジェクトに各必須属性のデータが含まれていることを確認します。

• 履行システムへのサービス・コールの結果として更新するトランザクション・データを決定します。 このデータは、Order Managementのトランザクション表に存在します。

データの整合性を維持すると、作成したタスク・タイプがOrder Management作業領域全体で正しく表示されるようになります。 また、Order Managementでは、次の新しいタスク・タイプで機能が正しく機能することを確認します:

• ステータス更新

• 待機ステップ

• フォワード・プランニング

• 危険

• 保留処理

• 分割処理

• 変更管理

• エラー・リカバリ

請求を含める

履行レスポンスの手数料コンポーネント・エンティティに、SourceChargeComponentId属性およびHeaderCurrencyUnitPrice属性の値を含める必要があります。

カスタム・タスクを使用して既存の課金を更新したり、履行のレスポンスを含む新しい課金を追加する場合は、履行フロー全体を徹底的にテストすることをお薦めします。 次のユースケースをテストする必要があります:

• 価格設定および運送費を確定し、販売オーダーをコピーします。
• 価格設定および運送費を凍結してから、販売オーダーをコピーしないでください。
• 販売オーダーを改訂します。
• 元のオーダーからの手数料がある返品オーダーを作成します。

新規タスク・タイプのその他のオプション設定の実行

設定のタイプ	説明
前処理	前処理ロジックを追加します。 たとえば: アウトバウンド・リクエストにデータのデフォルト値を設定します。 アウトバウンド・リクエストのデータを検証します。
後処理	後処理ロジックを追加します。 たとえば: インバウンド・リクエストのデータのデフォルト値を設定します。 インバウンド・リクエストのデータを検証します。 オーダー管理で複数のオーケストレーション・プロセス間で処理を分割する必要がある、履行システムが戻す属性またはメッセージを解釈します。
変更管理	新しいタスク・タイプを参照するオーケストレーション・プロセス・ステップで変更管理を使用します。 「変更を識別するオーダー属性の管理」ページでタスク・タイプの属性を指定します。 タスク・タイプが更新サービスと取消サービス、およびこれらのサービスが必要とするコネクタを参照していることを確認してください。
保留コード	新しいサービスに保留を適用するには、その保留コードを作成します。 すべて保留は、新しいサービスおよびすでに存在するサービスに適用されます。
危険しきい値	新しいタスクの危険スコアを含めるには、その危険しきい値を設定します。
処理制約	新しいタスクを使用するタイミングを制御する処理制約を作成します。 たとえば、アウトバウンド・リクエストまたはインバウンド応答で必要な属性を指定する処理制約を使用します。
アウトバウンド・リクエストの一部として使用されるデータ・セット	これらのリクエストを検討してください。 GetValidFLineData 前処理サービス インタフェースのルーティング・ルール いずれかを使用する場合、テンプレート・タスクでは、完全なデータ・セットを使用してオーダー管理の属性が通信されます。 データ・セットを減らして、処理をより効率的にできます。
エラー・メッセージの登録	履行システムでオーダー管理にエラー・メッセージを送信し、それらをオーダー管理で処理して表示する場合は、登録する必要があります。