3

私は 2 つのシステムを持っており、それらを A と B と呼んでいます。A で重要なオブジェクトが変更されると、A はそれを Apache Camel を介して B に送信します。ただし、A が実際にオブジェクトの変更ログを持っているのに対し、B はオブジェクトの実際の状態のみを反映する必要があるという 1 つのケースに遭遇しました。さらに、A の変更ログには「将来の」レコードを含めることができます。これは、オブジェクトの状態の変更が将来のある時点でスケジュールされていることを意味します。システム A のユーザーは、この変更ログを編集し、変更レコードを削除し、任意のタイムスタンプ (過去および未来) を持つ新しい変更レコードを追加し、既存の変更を更新することさえできます。もちろん、A はこれらの変更レコードを B に送信しますが、B はオブジェクトの実際の状態のみを必要とします。

A からオブジェクトを照会することはできますが、A はパフォーマンスが重要なシステムであるため、追加の負荷が発生する可能性があるため、何かを照会するつもりはないことに注意してください。また、A からデータをクエリするための API は複雑すぎるため、可能な限り避けたいと考えています。

ここには 2 つの問題があります。まず、変更ログ レコードの特定の変更が実際の状態の変更を引き起こす可能性があるかどうかを認識することです。変更ログを中間データベースに保存します。変更ログ レコードが来ると、中間データベースで追加/削除/更新し、オブジェクトの実際の状態を計算して、この状態を B に送信します。

2 つ目は、変更スケジュールの追跡です。定期的なジョブを一定の間隔 (たとえば 15 分) で実行する以外に、私は何も発明できませんでした。このジョブは、最後の呼び出しから現在の呼び出しまでの時間間隔に含まれるすべてのレコードをスキャンします。

私が Apache Camel を気に入っているのは、そのコンポーネントベースのアプローチです。エンドポイントを接続してすべての作業を行うだけでよく、わずかなコーディングしか必要ありません。Apache Camel と EIP の両方で、この問題に対する既存のプリミティブはありますか?

4

1 に答える 1

0

私は実際に、システム Aがシステム B に送信する前に変換を必要とするスナップショットと更新を送信する、非常によく似たユース ケースに取り組んでいます。

最初に、システム A から初期状態 (「スナップショット」) を提供するためのメカニズムをトリガーする必要があります。これにより、timer:コンポーネントはワンタイム スタートアップ ロジックを開始できます。

これで、スナップショット データを受け取ります (方法は指定しませんでした。ftpファイルまたはjmsエンドポイントである可能性があります)。cache:Sergey がコメントで提案しているように、データを検証し、アイテムに分割し、データの各アイテムをローカルのメモリ内に保存します。論理的な有効期限ポリシー (48 時間など) を使用します。

そこから、ftp:エンドポイントからの「更新」データを継続的に処理します。更新ごとに、更新を のデータと照合し、cache:システム B に何を (いつ) 送信する必要があるかを判断する必要があります。

後でシステム B に送信する必要があるデータは、メモリまたはデータベースに永続化する必要があります。

最後に、新しいデータを送信する必要があるかどうかを 15 分ごとに決定するスケジューリング メカニズムが必要です。これにはtimer:、 orquartz:を簡単に使用できます。

要約すると、次のコンポーネントからこの統合を構築できtimerます。cacheftpquartz

主な課題は、キャッシュされてから更新されるデータの処理と、最初の接続時、切断時、またはキャメル アプリケーションの再起動時に発生する制御メカニズムの解決です。

幸運を ;)

于 2015-03-03T15:26:08.673 に答える