1. Homepage
  2. Mule Runtime (4.3)
  3. Mule 3 ユーザー向けの Mule 4 情報

  4. Mule 4 の新機能

Mule 4 の新機能

Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。

以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。

簡略化されたイベントとメッセージモデル

Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。

DataWeave 2.0: 新しい Mule 式言語

Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。

Mule 4​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。

  • イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。

  • バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。

  • メモリを超えるデータへのアクセスが透過的に実行されます。

DataWeave 2.0 でも多くの機能強化が実装されています。

  • 言語の簡略化。すべてが機能するようになりました。

  • 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。

  • マルチラインコメントのサポート。

  • DataWeave からの直接的な静的 Java メソッドのコールのサポート。

詳細については、​​DataWeave ドキュメント​へのリンクを参照してください。

ストリーミング管理

Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。

  • DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。

  • ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。

  • ユーザーがメモリを超えるデータに透過的にアクセスできるため。

  • ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。

非ブロックで自己調整のランタイム

Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。

この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​<async>​ プロセッサーを使用できます。

各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。

コネクタ/モジュールからの直接的なイベントのエンリッチ

任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。

<http:request target="myVar" config-ref="requestConfig" method="GET" url="http://mulesoft.com"/>

これにより、Mule メッセージを ​myVar​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。

targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。

<http:request target="myVar" targetValue="#[attributes.statusCode]" .../>

簡略化されたコネクタとモジュール環境

Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。

トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。

簡略化されたエラー処理および新しい Try スコープ

Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。

例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。

フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。

新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。

より使いやすく、スコープになったバッチ

Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。

クラスローダー分離によるアップグレード可能性の向上

Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。

  • コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。

    • ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。

    • 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。

  • 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。

  • 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。

設定のサポートの強化

Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。

コネクタとモジュールの更新

データベースコネクタ

データベースコネクタでは軽微な更新が行われました。

  • 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。

  • 1 つの環境で静的および動的クエリを実行できます。

  • メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。

  • コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。

File Connector と FTP Connector

File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。

  • 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリの内容の完全なリストの作成をオンデマンドで実行する機能。

  • ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。

  • ファイルシステムレベルでのファイルのロックのサポート。

  • 高度なファイル一致機能。

  • FTP、SFTP、FTPS などのローカルファイルのサポート。

JMS Connector

JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。

スクリプティングモジュール

スクリプティングモジュールは Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。

<script:execute engine="groovy">
    <script:code>
         return "$payload $prop1 $prop2"
    </script:code>
    <script:parameters>
         #[{prop1: "Received", prop2: "A-OK"}]
    </script:parameters>
</script:execute>

Spring モジュール

Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring モジュールをアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。

<spring:config name="springConfig" files="beans.xml"/>

VM Connector

VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。

その他のモジュールおよびコネクタ

その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。

Mule SDK

Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。

多くの点で DevKit と似ていますが、多くの機能強化も施されています。

  • SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。

  • トランザクションのサポート。

  • Request-Response (要求-応答) メッセージソースのサポート。

  • 動的設定。

  • ルーターのサポート。

  • 非ブロック操作。

  • クラスローディング分離。

関連情報