19 レポートの作成
この章では、デプロイされたデータの実行時動作のリアルタイム・ステータスを示すOracle B2Bのレポートについて説明します。ビジネス・メッセージ・レポート、ワイヤ・メッセージ・レポート、アプリケーション・メッセージ・レポート、エラー・レポートおよび対話レポートについて説明します。
この章の内容は以下のとおりです。
19.1 レポートの概要
実行時リポジトリのデータを検索するには、「レポート」リンクを使用します。保存済検索の機能は使用できません。
検索では、次のメッセージ・タイプを使用できます。
-
ビジネス・メッセージ—ビジネス・メッセージ・レポートの作成を参照してください。
-
ワイヤ・メッセージ—ワイヤ・メッセージ・レポートの作成を参照してください。
-
アプリケーション・メッセージ—アプリケーション・メッセージ・レポートの作成を参照してください。
-
エラー・メッセージ—エラー・レポートの作成を参照してください。
-
対話メッセージ—対話レポートの作成を参照してください。
ノート:
クラスタ環境で、システム・タイムスタンプがクラスタ内のすべてのノードに対して同期化されていない場合は、誤りと思われるメッセージ・タイムスタンプが表示される可能性がありますが、実際は誤りではありません。たとえば、非同期のマルチノードのクラスタがあるとします。あるノードでアウトバウンド・メッセージを受信し、別のノードからリプライを送信すると、レポートにはメッセージの受信が午前4時と表示され、確認の送信は午前3時55分と表示される可能性があります。
19.1.1 監視ユーザー・ロール
メッセージ・レポートを作成および分析するビジネス・アナリストなどの個人に対して、Oracle B2Bには、管理者による取引パートナ・ユーザーへの割当てが可能な監視ユーザー・ロールが用意されています。このロールを使用すると、ユーザーは、Oracle B2Bの「レポート」タブの機能にのみアクセスできます。監視ロールのユーザーは、インタフェースの他の部分の表示やアクセス、他の取引パートナのデータの表示は実行できません。監視ロールの割当て方法は、取引パートナ・ユーザーの追加を参照してください。
19.1.3 Oracle B2Bからのメッセージの再発行
インバウンド・メッセージまたはアウトバウンド・メッセージの送信時に発生したエラーがOracle B2B内部である場合は、問題を修正してメッセージを再送信できます。たとえば、適切に構成されていないエンドポイントにB2Bがメッセージを送信しようとした場合やアグリーメントが適切に構成されていない場合は、エラーを修正し、アプリケーション・メッセージまたはワイヤ・メッセージの「再発行」を使用します。
メッセージのエラーの原因がエンドポイントのHostname/IPAddressまたはポート変更である場合、メッセージはMSG_WAIT_STACKまたはMSG_WAIT_TRANSMITにあります。エンドポイントのHostname/IPAddressまたはポートを修正し、MSG_WAIT_STACKにある最初のエラー・メッセージを再発行します。シーケンス内のすべての保留中になっているメッセージは、エンドポイントの更新されたHostname/IPAddressまたはポートを使用して処理されます。エンドポイントの各エラー・メッセージを再発行する必要はありません。
アウトバウンド・メッセージの場合、アプリケーション・メッセージを再発行すると、メッセージは、そのメッセージを受信した時間から再実行され、アグリーメント参照、メッセージ変換(EDIの場合)と進み、最後に配信が試行されます。アプリケーション・メッセージの再発行は、アグリーメント設定またはドキュメント構成が必須ではなく、更新された設定でメッセージを再構成する必要がある場合に役立ちます。
インバウンド・メッセージの場合、アプリケーション・メッセージを再発行すると、バックエンド・アプリケーションへのメッセージ配信が再度試行されます。再発行は、バックエンド・アプリケーションが停止したため配信を再試行する必要がある場合に役立ちます。
アウトバウンド・メッセージの場合、ワイヤ・メッセージを再発行すると、以前に処理されたメッセージについてのみ再配信が試行されます。再パッケージングまたは他のメッセージ変換は実行されません。これは、問題がデリバリ・エンドポイントにある場合(パートナのサーバーが停止したためメッセージを受信できない場合など)に役立ちます。
インバウンド・メッセージの場合、ワイヤ・メッセージを再発行すると、メッセージは、そのメッセージを取引パートナから受信した時間から再実行されます。交換およびドキュメントは再度識別されてアグリーメント参照が実行されます。処理されたメッセージはバックエンドに配信されます。これは、アグリーメントまたはドキュメント設定が適切でないために、メッセージを再度変換して検証する必要がある場合に役立ちます。
ノート:
EDI/EDIFACTドキュメントの場合、ユーザーはチェックするXPath式を設定し、それによって重複を回避できます。同じXPath値を持つ2つのメッセージが到着した場合、後から到着したメッセージが重複としてマークされ、エラーが出力されます。
エラーが発生したこの重複メッセージを再発行(ワイヤ・メッセージを再発行)した場合、再発行は意図的に実行されるものなので、Oracle B2Bは重複という事実を無視してメッセージを処理します。したがって、Oracle B2Bが重複メッセージを処理しないようにする場合は、重複メッセージを再発行してはいけません。
ノート:
インバウンドAS2同期ワイヤ・メッセージを再発行すると、MDNが生成されますが、同期モードで送信者に戻されません。これは、送信者が元のメッセージを開始したユーザーではないためです。このシナリオでは、MDNメッセージの状態はMSG_COMPLETE
状態です。
19.1.3.1 再発行時のB2Bにおける相関フローIDのレスポンス
ワイヤ・メッセージベースのインバウンドの再発行では、新しい相関フローIDが生じます。これは、新しいビジネス・フローとして処理されます。
インバウンドのアプリケーションの再発行では、B2Bビジネス情報が変更されないため、相関情報が再利用されます。
相関情報を保持する必要がある場合は、アプリケーション・メッセージの再発行を使用できます。新しいフローを開始する場合は、ワイヤの再発行を使用できます。
アウトバウンドのアプリケーションおよびワイヤの再発行では、バックグランドで使用されるビジネス・フローが同じため、既存の相関情報が再利用されます。
19.2 ビジネス・メッセージ・レポートの作成
ビジネス・メッセージ・ステータス・レポートには、ドキュメント・プロトコルに対するビジネス・メッセージ・インスタンスの詳細が示されます。これらの詳細には、送信および受信取引パートナ、アグリーメント名、ビジネス・アクション、ビジネス・メッセージID、ステータス、交換プロトコル、ドキュメント・プロトコルおよびメッセージ詳細が含まれます。
図19-1に、ビジネス・メッセージ・レポートを示します。
ビジネス・メッセージ・レポートを作成するには:
19.2.1 メッセージ状態の定義
表19-1は、メッセージ状態の定義を示しています。
表19-1 メッセージ状態の定義
メッセージ | 説明 |
---|---|
不変状態のメッセージ |
[-] |
MSG_COMPLETE |
メッセージ転送が完了した後(および確認/FAがある場合は送信の確認を受信した後)のビジネス・メッセージの状態。ワイヤ・メッセージの状態も、MSG_COMPLETE状態になります。 |
MSG_WAIT_ACK |
アウトバウンド・メッセージが取引パートナに送信され、B2Bが確認の受信を待っている場合のビジネス・メッセージの状態。 |
MSG_ERROR |
B2Bで問題が発生した場合または取引パートナから否定確認を受信した場合のビジネス・メッセージの状態。ワイヤ・メッセージの状態も、MSG_ERROR状態になります。 |
可変状態のメッセージ |
[-] |
MSG_WAIT_TRANSMIT |
B2Bが取引パートナにメッセージを送信中のビジネス・メッセージの状態。メッセージが順序付けでキューに入れられるときにも、この状態になります。 |
MSG_WAIT_FA |
アウトバウンド・メッセージが取引パートナに送信され、B2Bが機能確認の受信を待っている場合のビジネス・メッセージの状態。 |
MSG_SEND_FA |
B2Bが取引パートナに機能確認を送信中のビジネス・メッセージの状態。 |
MSG_WAIT_BATCH |
バッチの有効期限が切れるまでの間、メッセージをバッチ処理している場合のビジネス・メッセージの状態。バッチの有効期限が切れると、メッセージのバッチ全体が送信され、ビジネス・メッセージおよびワイヤ・メッセージの状態はMSG_COMPLETE (または、問題がある場合はMSG_ERROR)になります。 |
MSG_WAIT_STACK |
順序付けでトランスポート・エラーが生じた場合のビジネス・メッセージの状態。 |
MSG_WAIT_TA1 |
EDI-X12のTA1メッセージを待機中のビジネス・メッセージの状態。 |
MSG_SEND_TA1 |
EDI-X12のTA1メッセージを送信中のビジネス・メッセージの状態。 |
MSG_CONTINUE_PROCESS |
メッセージがB2B (エンジン)で処理されている場合のビジネス・メッセージの状態。 |
MSG_COLLAB_WAIT |
メッセージがコラボレーションを待機中のビジネス・メッセージの状態。 |
MSG_PROCESS_ACK |
確認を処理中のビジネス・メッセージの状態。 |
MSG_SEND_ACK |
インバウンド・メッセージが取引パートナから受信され、B2Bが確認を送信中のビジネス・メッセージの状態。 |
MSG_SEND_EXP |
例外メッセージを送信中のビジネス・メッセージの状態。 |
MSG_PROCESS_EXP |
例外メッセージを処理中のビジネス・メッセージの状態。 |
MSG_INVALD |
この状態は、B2Bでメッセージの処理が開始されるときのデフォルト/初期状態です。B2Bでメッセージの状態をモニタリングしているときに、この状態が発生することはありません。 |
MSG_ABORTED |
メッセージは強制終了されました。 |
19.3 ワイヤ・メッセージ・レポートの作成
ワイヤ・メッセージ・レポートを作成するには:
19.4 アプリケーション・メッセージ・レポートの作成
19.5 エラー・レポートの作成
エラー・ステータス・レポートでは、エラー・メッセージの詳細が提供されます。これらの詳細には、エラー・コード、エラー・テキスト、ビジネス・メッセージ識別、メッセージ日付およびメッセージ詳細が含まれます。
図19-7に、エラー・レポートを示します。
エラー・レポートを作成するには:
19.6 対話レポートの作成
ドキュメント定義に相関XPathを設定してメッセージを相関付けすると、対話メッセージが表示されます。また、相関メッセージには、自動的に相関付けされたメッセージが表示されます。
たとえば、AS2メッセージとその確認(MDN)は自動的に相関付けされ、対話の一部になります。RosettaNetでは、送受信される確認に加えて、リクエストとレスポンスのメッセージも相関付けされます。これらの関連メッセージは、「対話」タブに表示されます。
図19-9に、対話レポートを示します。
対話レポートを作成するには: