0

OpenESB を使用して解決したい、変わった設計目標があります。システムによって生成され、別のシステムに転送されるファイルが多数あります。データの種類、ソース システム、および宛先システムによっては、データを宛先システムにアップロードする前に、一連の変換を行う必要があります。これに対する最善のアプローチに関するアドバイスはありますか?

一般的な要件:

  • 変換の数と種類は多数あり、時間の経過とともに変化する可能性があります。
  • 処理するデータの数と種類は、時間の経過とともにかなり固定されます。
  • ソース システムと宛先システムの数は、時間の経過とともに大幅に変化する可能性があります。
  • これらの各変換は、タイプ、ソース、宛先が類似している場合にまとめて使用できます。
  • 各顧客のビジネス ルールに基づいて、新しい変換をシーケンスに置き換えるか挿入する必要がある場合があります。これには、新しい別のシーケンスが必要になります。
  • ソリューションは、可能な限り柔軟でスケーラブルである必要があります。
  • タイプ、ソース、および宛先に基づく多くの将来の要件が発生する可能性がありますが、これについてはまだ検討していません。この柔軟性は、システムの要件です。

私たちの考え方では、ネストされた BPEL のセットが最適なソリューションであり、それぞれが POJO クラスを呼び出して目的の変換を実現するように思えます。これは実現可能ですか?より良い方法はありますか?

4

3 に答える 3

0

複雑なビジネス ロジックに関しては、BPEL で複雑なことを行うのではなく、可能な限り多くの作業を Java コードに委譲するのが最善です。EJB を作成して BPEL から呼び出すだけです。

于 2010-10-27T21:53:01.993 に答える
0

OpenESB で XSLT 変換を試してください。

于 2010-02-09T08:43:42.667 に答える
0

私はもう1つうまくやった。独自のデータ フロー処理システムをゼロから作成しました。利用可能な他のすべては、あまりにも重くて複雑でした.

私の新しいシステム、コードネーム LightRail はうまく機能します。すべての接続はコンポーネント主導であり、単一の JSON 構成ファイルを介して定義されます。すべての処理とフロー制御は、単一の BeanShell スクリプトによって処理されます。

過去 10 か月で、IMAP、SFTP、FTP、ファイル、および 1 つまたは 2 つのデータベースに接続する 10 の異なるデータ フローを既に展開しています。人生は再び良いです...

アンドリュー

于 2010-10-28T05:30:12.067 に答える