私たちは複数のアプリケーションを通信するためのアーキテクチャを設計しており、Mirth を (疑似) ESB として使用することにしました。私たちのプロセスでは、できるだけ早くユーザーにコントロールを返したいので、ユーザーがアクションを実行すると (たとえば、フォームに入力した後に [保存] ボタンを押す)、データベースに (必要な) 変更が加えられます。メッセージを別のシステムに送信する必要があります。ユーザーはメッセージが送信されるまで待つ必要がないため、アプリケーションはデータベースの変更が完了すると制御を返します。メッセージの作成はバックグラウンドで非同期的に行われます。しかし、どのアプローチに従うべきかはよくわかりません。
a) アプリで新しいスレッドを開始し、必要なすべてのデータを収集します (「プライマリ データ」から開始します。これは、すべての情報を検索できるいくつかのプライマリ キーです) HL7 メッセージを入力し、Mirth があるキューに送信します。聞いている。
b) 「プライマリ データ」を Mirth に送信し、それに HL7 メッセージ構成を委譲します。Mirth はデータベースに直接アクセスして必要なデータを収集するか、別のオプションで独自の REST/SOAP サービスを呼び出すことができます。
オプション B の場合、Mirth を呼び出す方法について疑問があります。 b.1) アプリがデータベースを変更し、プライマリ データをキューに書き込みます (分散トランザクション)。b.2) アプリはデータベースを変更し、Mirth が発行する SOAP または REST サービスを呼び出します。これは、Mirth が読み取るキューにメッセージを書き込むことだけです (アプリには分散トランザクションはありません)。
アプリでメッセージを作成し、Mirth をブローカーとしてのみ使用することは、Mirth を「誤用」していると主張する人もいます。反対に、Mirth からアプリ データベースにアクセスするのは非常に煩わしく、スキーマを認識してはならないという意見もあります。最後の選択肢として、HL7 に必要なすべての情報を返すアプリ サービスを Mirth から呼び出すことは、Mirth がサービスを呼び出した (そのデータをパラメーターとして渡す) ときにのみ、アプリから Mirth に「プライマリ データ」を送信するようなものです。
アドバイスありがとうございます。