MuleSoft-Mule ESBの紹介

ESBは Enterprise Service Bus の略で、基本的にバスのようなインフラストラクチャ上でさまざまなアプリケーションを統合するためのミドルウェアツールです。基本的に、それは統合されたアプリケーション間で作業を移動する均一な手段を提供するように設計されたアーキテクチャです。このようにして、ESBアーキテクチャの助けを借りて、通信バスを介してさまざまなアプリケーションを接続し、互いに依存せずに通信できるようにすることができます。

ESBの実装

ESBアーキテクチャの主な焦点は、システムを相互に分離し、安定した制御可能な方法で通信できるようにすることです。 ESBの実装は、次のように*「バス」および「アダプター」*の助けを借りて行うことができます-

JMSやAMQPなどのメッセージングサーバーを介して実現される「バス」の概念は、異なるアプリケーションを互いに分離するために使用されます。
バックエンドアプリケーションと通信し、データをアプリケーション形式からバス形式に変換する「アダプター」の概念は、アプリケーションとバスの間で使用されます。

バスを介して1つのアプリケーションから別のアプリケーションに渡されるデータまたはメッセージは標準形式であり、1つの一貫したメッセージ形式があることを意味します。

アダプタは、セキュリティ、監視、エラー処理、メッセージルーティング管理などの他のアクティビティも実行できます。

ESBの指導原則

これらの原則は、統合の基本原則と呼ぶことができます。彼らは次のとおりです-

オーケストレーション-データとプロセス間の同期を実現するための2つ以上のサービスの統合。
変換-データを標準形式からアプリケーション固有の形式に変換します。
トランスポート-FTP、HTTP、JMSなどの形式間のプロトコルネゴシエーションの処理
調停-サービスの複数のバージョンをサポートするために複数のインターフェースを提供します。
非機能一貫性-トランザクションとセキュリティを管理するためのメカニズムを提供します。

ESBの必要性

ESBアーキテクチャにより、各アプリケーションが通信できるさまざまなアプリケーションを統合できます。 ESBを使用するタイミングに関するガイドラインを次に示します-

* 2つ以上のアプリケーションを統合する*-ESBアーキテクチャの使用は、2つ以上のサービスまたはアプリケーションを統合する必要がある場合に有益です。
将来さらに多くのアプリケーションを統合-将来さらに多くのサービスやアプリケーションを追加したい場合は、ESBアーキテクチャの助けを借りて簡単に行うことができます。
複数のプロトコルの使用-HTTP、FTP、JMSなどの複数のプロトコルを使用する必要がある場合、ESBが適切なオプションです。
メッセージルーティング-メッセージコンテンツおよび他の同様のパラメータに基づいてメッセージルーティングが必要な場合に、ESBを使用できます。
構成と消費-構成と消費のサービスを公開する必要がある場合は、ESBを使用できます。

P2P統合と ESB統合

アプリケーションの数の増加に伴い、開発者の前での大きな疑問は、異なるアプリケーションを接続する方法でしたか？この状況は、さまざまなアプリケーション間の接続を手作業でコーディングすることで処理されました。これは、「ポイントツーポイント統合」と呼ばれます。

P2P統合

剛性*は、ポイントツーポイント統合の最も明らかな欠点です。接続とインターフェイスの数が増えると、複雑さが増します。 P-2-P統合の欠点により、ESB統合が可能になります。

ESBは、アプリケーション統合へのより柔軟なアプローチです。各アプリケーション機能をカプセル化して、個別の再利用可能な機能のセットとして公開します。他のアプリケーションと直接統合するアプリケーションはありませんが、以下に示すように、ESBを介して統合します

ESB統合

統合を管理するために、ESBには次の2つのコンポーネントがあります-

Service Registry -ESBに公開されているすべてのサービスが公開および登録されているMule ESBにはService Registry/Repositoryがあります。他のアプリケーションのサービスと機能を利用できる場所からの発見のポイントとして機能します。
集中管理-名前が示すように、ESB内で発生する相互作用のパフォーマンスのトランザクションフローのビューを提供します。
ESB機能*-VETROの略語は、一般にESBの機能を要約するために使用されます。それは次のとおりです-
V （検証）-名前が示すように、スキーマ検証を検証します。検証パーサーと最新のスキーマが必要です。 1つの例は、最新のスキーマを確認するXMLドキュメントです。
E （Enrich）-メッセージに追加データを追加します。目的は、ターゲットサービスにとってメッセージをより意味のある便利なものにすることです。
T （Transform）-データ構造を標準形式または標準形式から変換します。例は、日付/時刻、通貨などの変換です。
R（ルーティング）-メッセージをルーティングし、サービスのエンドポイントのゲートキーパーとして機能します。
O （操作）-この機能の主な仕事は、ターゲットサービスを呼び出すか、ターゲットアプリと対話することです。バックエンドで実行されます。

VETROパターンは統合に全体的な柔軟性を提供し、一貫性があり検証されたデータのみがESB全体にルーティングされるようにします。

ESB Muleとは何ですか？

Mule ESBは、MuleSoftが提供する軽量で拡張性の高いJavaベースのエンタープライズサービスバス（ESB）および統合プラットフォームです。 ESB Mule ESBにより、開発者はアプリケーションを簡単かつ迅速に接続できます。 Mule ESBを使用すると、アプリケーションで使用されるさまざまなテクノロジーに関係なく、アプリケーションを簡単に統合して、データを交換できます。 ESB Muleには次の2つのエディションがあります-

コミュニティ版
エンタープライズ版

Mule ESBの利点は、両方のエディションが共通のコードベースで構築されているため、Mule ESBコミュニティからMule ESBエンタープライズに簡単にアップグレードできることです。

ESB Mule ESBの機能と機能

Mule ESBには次の機能があります-

シンプルなドラッグアンドドロップのグラフィカルなデザインです。
ESB Muleは、視覚的なデータのマッピングと変換が可能です。
ユーザーは、事前に構築された何百もの認証済みコネクタの機能を取得できます。
集中監視および管理。
堅牢なエンタープライズセキュリティ実施機能を提供します。
API管理の機能を提供します。
クラウド/オンプレミス接続用の安全なデータゲートウェイがあります。
ESBに公開されるすべてのサービスが公開および登録されるサービスレジストリを提供します。
ユーザーは、Webベースの管理コンソールを介して制御できます。
サービスフローアナライザーを使用して、迅速なデバッグを実行できます。

MuleSoft-Muleプロジェクト

Muleプロジェクトの背後にある動機は-

プログラマーのために物事を簡単にするために、
アプリケーションレベルのメッセージングフレームワークから企業全体の高度に分散可能なフレームワークまで拡張できる軽量でモジュール式のソリューションの必要性。

ESB Muleは、プログラム駆動型のフレームワークと同様にイベント駆動型のフレームワークとして設計されています。メッセージの統一表現と組み合わされ、プラグ可能なモジュールで拡張できるため、イベント駆動型です。プログラマーは、特定のメッセージ処理やカスタムデータ変換などの追加の動作を簡単に埋め込むことができるため、プログラム的です。

歴史

Muleプロジェクトの歴史的展望は次のとおりです-

SourceForgeプロジェクト

MuleプロジェクトはSourceForgeプロジェクトとして2003年4月に開始され、2年後にその最初のバージョンがリリースされ、CodeHausに移行されました。ユニバーサルメッセージオブジェクト（UMO）APIは、そのアーキテクチャの中核でした。 UMO APIの背後にある考え方は、基礎となるトランスポートから隔離されたまま、ロジックを統合することでした。

バージョン1.0

2005年4月にリリースされ、多数のトランスポートが含まれていました。それに続く多くの他のバージョンの主な焦点は、デバッグと新しい機能の追加にありました。

バージョン2.0（Spring 2の採用）

Mule 2では、構成および配線フレームワークとしてのSpring 2が採用されましたが、必要なXML構成の表現力が不足しているため、大幅なオーバーホールであることが判明しました。この問題は、XML Schemaベースの構成がSpring 2で導入されたときに解決されました。

Mavenを使用した構築

Muleの使用を開発時とデプロイ時の両方で簡素化した最大の改善は、Mavenの使用でした。バージョン1.3から、Mavenでの構築が開始されました。

MuleSource

2006年、MuleSourceは「ミッションクリティカルなエンタープライズアプリケーションでMuleを使用して急速に成長しているコミュニティをサポートし、有効にするために」組み込まれました。 Muleプロジェクトの重要なマイルストーンであることが証明されました。

ESB Mule ESBのライバル

Mule ESBの主要な競合他社の一部を次に示します-

WSO2 ESB
Oracle Service Bus
WebSphere Message Broker
Aurea CXプラットフォーム
フィオラノESB
WebSphere DataPower Gateway
Workday Business Process Framework
Talend Enterprise Service Bus
JBoss Enterprise Service Bus
iWayサービスマネージャー

Muleのコアコンセプト

前述のように、ESB Muleは軽量で拡張性の高いJavaベースのエンタープライズサービスバス（ESB）および統合プラットフォームです。 Mule ESBを使用すると、アプリケーションで使用されるさまざまなテクノロジーに関係なく、アプリケーションを簡単に統合して、データを交換できます。このセクションでは、このような統合を実現するために登場するMuleのコアコンセプトについて説明します。

そのためには、そのアーキテクチャとビルディングブロックを理解する必要があります。

建築

ESB Muleのアーキテクチャには、次の図に示すように、トランスポート層、統合層、アプリケーション層の3つの層があります-

Mule Core Concept

一般的に、ESB Muleのデプロイを設定およびカスタマイズするために実行できるタスクには、次の3つのタイプがあります-

サービスコンポーネントの開発

このタスクには、既存のPOJOまたはSpring Beanの開発または再利用が含まれます。 POJOは、getおよびsetメソッド、クラウドコネクタを生成する属性を持つクラスです。一方、Spring Beanには、メッセージを充実させるビジネスロジックが含まれています。

サービスオーケストレーション

このタスクは、基本的に、メッセージプロセッサ、ルーター、トランスフォーマー、フィルターの構成を伴うサービスメディエーションを提供します。

統合

ESB Mule ESBの最も重要なタスクは、使用しているプロトコルに関係なく、さまざまなアプリケーションを統合することです。この目的のために、Muleはさまざまなプロトコルコネクタでメッセージを受信およびディスパッチできるトランスポートメソッドを提供します。 ESB Muleは多くの既存のトランスポート方法をサポートしていますが、カスタムのトランスポート方法を使用することもできます。

ビルディングブロック

ESB Muleの構成には次の構成要素があります-

ビルディングブロック

春豆

Spring Beanの主な用途は、サービスコンポーネントの構築です。 Spring Serviceコンポーネントを構築した後、設定ファイルがない場合は、設定ファイルを介して、または手動で定義できます。

エージェント

これは基本的に、Mule Studioの前にAnypoint Studioで作成されたサービスです。サーバーを起動するとエージェントが作成され、サーバーを停止するとエージェントが破棄されます。

コネクタ

これは、プロトコルに固有のパラメーターで構成されたソフトウェアコンポーネントです。主にプロトコルの使用を制御するために使用されます。たとえば、JMSコネクタは Connection で構成され、このコネクタは実際の通信を担当するさまざまなエンティティ間で共有されます。

グローバル構成

名前が示すとおり、このビルディングブロックはグローバルプロパティと設定を設定するために使用されます。

グローバルエンドポイント

フローで何度も使用できるグローバル要素タブで使用できます-

グローバルメッセージプロセッサ

名前が示すように、メッセージまたはメッセージフローを監視または変更します。トランスフォーマーとフィルターは、グローバルメッセージプロセッサの例です。

トランスフォーマー-トランスフォーマーの主な仕事は、データをある形式から別の形式に変換することです。グローバルに定義でき、複数のフローで使用できます。

フィルター-どのMuleメッセージを処理するかを決定するのはフィルターです。フィルタは基本的に、メッセージが処理されてサービスにルーティングされるために満たす必要がある条件を指定します。

モデル

エージェントとは対照的に、それはスタジオで作成されるサービスの論理的なグループです。特定のモデル内のすべてのサービスを開始および停止する自由があります。

サービス-サービスは、ビジネスロジックまたはコンポーネントをラップするものです。また、そのサービス専用にルーター、エンドポイント、トランスフォーマー、フィルターも構成します。

エンドポイント-サービスがメッセージを受信（受信）および送信（送信）するオブジェクトとして定義できます。サービスはエンドポイントを介して接続されます。

Flow

メッセージプロセッサは、フローを使用して、ソースとターゲット間のメッセージフローを定義します。

ラバのメッセージ構造

Muleメッセージオブジェクトの下に完全にラップされたMuleメッセージは、Muleフローを介してアプリケーションを通過するデータです。構造ミュールのメッセージは、次の図に示されています-

メッセージ構造

上の図に見られるように、Muleメッセージは2つの主要な部分で構成されています-

ヘッダ

それはさらに次の2つのプロパティによって表されるメッセージのメタデータにすぎません-

インバウンドプロパティ-これらは、メッセージソースによって自動的に設定されるプロパティです。ユーザーが操作または設定することはできません。本来、インバウンドプロパティは不変です。

アウトバウンドプロパティ-これらは、インバウンドプロパティなどのメタデータを含むプロパティであり、フローの過程で設定できます。 Muleが自動的に設定するか、ユーザーが手動で設定できます。本質的に、送信プロパティは変更可能です。

メッセージがトランスポートを介して、あるフローのアウトバウンドエンドポイントから別のフローのインバウンドエンドポイントに渡されると、アウトバウンドプロパティはインバウンドプロパティになります。

メッセージがコネクタではなくflow-refを介して新しいフローに渡される場合、送信プロパティは送信プロパティのままです。

ペイロード

メッセージオブジェクトによって運ばれる実際のビジネスメッセージは、ペイロードと呼ばれます。

変数

メッセージに関するユーザー定義のメタデータとして定義できます。基本的に、変数は、メッセージを処理しているアプリケーションで使用されるメッセージに関する一時的な情報です。メッセージとともに宛先に渡されることを意図していません。それらは以下に示すように3つのタイプがあります-

フロー変数-これらの変数は、それらが存在するフローにのみ適用されます。

セッション変数-これらの変数は、同じアプリケーション内のすべてのフローに適用されます。

レコード変数-これらの変数は、バッチの一部として処理されるレコードにのみ適用されます。

添付ファイルと追加のペイロード

これらは、メッセージペイロードに関する追加のメタデータであり、必ずしもメッセージオブジェクトに毎回表示されるとは限りません。

MuleSoft-私たちの機械の中のラバ

前の章では、ESB Muleの基本を学びました。この章では、インストールと設定の方法を学びましょう。

前提条件

Muleをコンピューターにインストールする前に、次の前提条件を満たす必要があります-

Java開発キット（JDK）

MULEをインストールする前に、システムでJavaのバージョンがサポートされていることを確認してください。 ESB Muleをシステムに正常にインストールするためには、JDK 1.8.0をお勧めします。

オペレーティング・システム

Muleでは以下のオペレーティングシステムがサポートされています-

MacOS 10.11.x
HP-UX 11iV3
AIX 7.2
Windows 2016サーバー
Windows 2012 R2サーバー
ウィンドウズ10
Windows 8.1
Solaris 11.3
RHEL 7
Ubuntu Server 18.04
Linuxカーネル3.13+

データベース

ESB Muleランタイムはスタンドアロンサーバーとして実行されるため、アプリケーションサーバーやデータベースは必要ありません。ただし、データストアにアクセスする必要がある場合、またはアプリケーションサーバーを使用する場合は、次のサポートされているアプリケーションサーバーまたはデータベースを使用できます-

Oracle 11g
Oracle 12c
MySQL 5.5以降
IBM DB2 10
PostgreSQL 9
ダービー10
Microsoft SQL Server 2014

システム要求

Muleをシステムにインストールする前に、次のシステム要件を満たしている必要があります-

仮想化環境で少なくとも2 GHz CPUまたは1仮想CPU
最小1 GBのRAM
最小4 GBのストレージ

ラバをダウンロード

Mule 4バイナリファイルをダウンロードするには、リンクhttps://www.mulesoft.com/lp/dl/mule-esb-enterpriseをクリックすると、次のようにMuleSoftの公式Webページに移動します-

ミュールをダウンロード

必要な詳細を提供することにより、Mule 4バイナリファイルをZip形式で取得できます。

ESB Muleのインストールと実行

Mule 4バイナリファイルをダウンロードしたら、解凍して、解凍したフォルダ内のMuleディレクトリに MULE_HOME という環境変数を設定します。

たとえば、WindowsおよびLinux/Unix環境の環境変数は、次のようにダウンロードディレクトリでバージョン4.1.5に設定できます-

Windows環境

$ env:MULE_HOME=C:\Downloads\mule-enterprise-standalone-4.1.5\

Unix/Linux環境

$ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.1.5/

さて、ESB Muleがエラーなしでシステムで実行されているかどうかをテストするには、次のコマンドを使用します-

Windows環境

$ $MULE_HOME\bin\mule.bat

Unix/Linux環境

$ $MULE_HOME/bin/mule

上記のコマンドは、Muleをフォアグラウンドモードで実行します。 ESB Muleが実行中の場合、ターミナルで他のコマンドを発行することはできません。ターミナルで ctrl-c コマンドを押すと、Muleが停止します。

ESB Muleサービスを開始

MuleはWindowsサービスとして、またLinux/Unixデーモンとしても起動できます。

WindowsサービスとしてのMule

ESB MuleをWindowsサービスとして実行するには、以下の手順に従う必要があります-

ステップ1 *-最初に、次のコマンドを使用してインストールします-

$ $MULE_HOME\bin\mule.bat install

ステップ2 *-インストールしたら、次のコマンドを使用してmuleをWindowsサービスとして実行できます。

$ $MULE_HOME\bin\mule.bat start

Linux/UnixデーモンとしてのMule

MuleをLinux/Unixデーモンとして実行するには、以下の手順に従う必要があります-

ステップ1 *-次のコマンドを使用してインストールします-

$ $MULE_HOME/bin/mule install

ステップ2 *-インストールしたら、次のコマンドを使用して、muleをWindowsサービスとして実行できます-

$ $MULE_HOME/bin/mule start

例

次の例では、MuleをUnixデーモンとして起動します-

$ $MULE_HOME/bin/mule start
MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.1.5
MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.1.5
Starting Mule Enterprise Edition...
Waiting for Mule Enterprise Edition.................
running: PID:87329

ESB Muleアプリをデプロイする

Muleアプリは次の手順で展開できます-

ステップ1 *-まず、Muleを起動します。

ステップ2 *-Muleが起動したら、JARパッケージファイルを *$ MULE_HOME の apps ディレクトリに移動してMuleアプリケーションをデプロイできます。

ESB Muleサービス

Muleを停止するには、 stop コマンドを使用できます。たとえば、次の例はMuleをUnixデーモンとして起動します-

$ $MULE_HOME/bin/mule stop
MULE_HOME is set to/Applications/mule-enterprise-standalone-4.1.5
MULE_BASE is set to/Applications/mule-enterprise-standalone-4.1.5
Stopping Mule Enterprise Edition...
Stopped Mule Enterprise Edition.

*remove* コマンドを使用して、システムからMuleサービスまたはデーモンを削除することもできます。 次の例では、MuleをUnixデーモンとして削除します-

$ $MULE_HOME/bin/mule remove
MULE_HOME is set to/Applications/mule-enterprise-standalone-4.1.5
MULE_BASE is set to/Applications/mule-enterprise-standalone-4.1.5
Detected Mac OSX:
Mule Enterprise Edition is not running.
Removing Mule Enterprise Edition daemon...

MuleSoft-Anypoint Studio

MuleSoftのAnypoint Studioは、Muleアプリケーションの設計とテストに使用されるユーザーフレンドリーな* IDE（統合開発環境）*です。 EclipseベースのIDEです。 Muleパレットからコネクタを簡単にドラッグできます。つまり、Anypoint Studioは、フローなどの開発のためのEclipseベースのIDEです。

前提条件

MuleをすべてのOS、つまりWindows、Mac、Linux/Unixにインストールする前に、次の前提条件を満たす必要があります。

Java Development Kit（JDK）*-Muleをインストールする前に、システムでJavaのバージョンがサポートされていることを確認してください。システムにAnypointを正常にインストールするには、JDK 1.8.0をお勧めします。

Anypoint Studioのダウンロードとインストール

Anypoint Studioを異なるオペレーティングシステムにダウンロードしてインストールする手順は異なる場合があります。次に、さまざまなオペレーティングシステムでAnypoint Studioをダウンロードしてインストールするために従うべき手順があります-

Windowsの場合

WindowsでAnypoint Studioをダウンロードしてインストールするには、以下の手順に従う必要があります-

ステップ1 *-まず、リンクhttps://www.mulesoft.com/lp/dl/studioをクリックし、トップダウンリストからWindowsオペレーティングシステムを選択してスタジオをダウンロードします。

Anypoint Studioのダウンロード

ステップ2 *-次に、それを *‘C：\’ ルートフォルダーに抽出します。

ステップ3 *-抽出されたAnypoint Studioを開きます。

ステップ4 *-デフォルトのワークスペースを受け入れるには、[OK]をクリックします。初めてロードするときに、ウェルカムメッセージが表示されます。

ステップ5 *-次に、[開始]ボタンをクリックして、Anypoint Studioを使用します。

OS Xで

OS XにAnypoint Studioをダウンロードしてインストールするには、次の手順に従う必要があります-

ステップ1 *-まず、リンクhttps://www.mulesoft.com/lp/dl/studioをクリックして、スタジオをダウンロードします。

OS XでAnypoint Studioをダウンロード

ステップ2 *-今、それを抽出します。 OSバージョンSierraを使用している場合は、抽出したアプリを起動する前に/Applicationsフォルダー*に移動してください。

ステップ3 *-抽出されたAnypoint Studioを開きます。

ステップ4 *-デフォルトのワークスペースを受け入れるには、[OK]をクリックします。初めてロードするときに、ウェルカムメッセージが表示されます。

ステップ5 *-次に、 *Get Started ボタンをクリックしてAnypoint Studioを使用します。

ワークスペースへのカスタムパスを使用する場合、Anypoint StudioはLinux/Unixシステムで使用される〜チルダを展開しないことに注意してください。したがって、ワークスペースの定義中に絶対パスを使用することをお勧めします。

Linuxの場合

LinuxにAnypoint Studioをダウンロードしてインストールするには、以下の手順に従う必要があります-

ステップ1 *-まず、リンクhttps://www.mulesoft.com/lp/dl/studioをクリックし、トップダウンリストからLinuxオペレーティングシステムを選択してスタジオをダウンロードします。

Linuxでダウンロード

ステップ2 *-今、それを抽出します。

ステップ3 *-次に、抽出されたAnypoint Studioを開きます。

ステップ4 *-デフォルトのワークスペースを受け入れるには、[OK]をクリックします。初めてロードするときに、ウェルカムメッセージが表示されます。

ステップ5 *-次に、[開始]ボタンをクリックして、Anypoint Studioを使用します。

ワークスペースへのカスタムパスを使用する場合、Anypoint StudioはLinux/Unixシステムで使用される〜チルダを展開しないことに注意してください。したがって、ワークスペースの定義中に絶対パスを使用することをお勧めします。

Linuxで完全なStudioテーマを使用するには、GTKバージョン2をインストールすることもお勧めします。

Anypoint Studioの機能

以下は、Muleアプリケーションを構築しながら生産性を向上させるAnypoint studioの機能です。

ローカルランタイム内でESB Muleアプリケーションを即座に実行できます。
Anypoint Studioは、API定義ファイルとMuleドメインを構成するためのビジュアルエディターを提供します。
ユニットテストフレームワークが組み込まれており、生産性が向上しています。
Anypoint studioは、CloudHubにデプロイする組み込みサポートを提供します。
他のAnypoint Platform組織からテンプレート、例、定義、およびその他のリソースをインポートするために、Exchangeと統合する機能があります。

MuleSoft-Anypoint Studioの発見

Anypoint Studioエディターは、アプリケーション、API、プロパティ、構成ファイルの設計に役立ちます。設計に加えて、編集にも役立ちます。この目的のためにMule構成ファイルエディタがあります。このエディターを開くには、 /src/main/mule にあるアプリケーションXMLファイルをダブルクリックします。

アプリケーションを操作するために、Mule構成ファイルエディターの下に次の3つのタブがあります。

[メッセージフロー]タブ

このタブは、ワークフローの視覚的な表現を提供します。基本的に、フローを視覚的に確認するのに役立つキャンバスが含まれています。 Muleパレットからイベントプロセッサをキャンバスに追加する場合は、ドラッグアンドドロップするだけでキャンバスに反映されます。

[メッセージフロータブ]

イベントプロセッサをクリックすると、選択したプロセッサの属性を含むMuleプロパティビューを取得できます。それらを編集することもできます。

グローバル要素タブ

このタブには、モジュールのグローバルMule構成要素が含まれています。このタブでは、構成ファイルを作成、編集、または削除できます。

グローバル要素タブ

[構成XML]タブ

名前が示すように、Muleアプリケーションを定義するXMLが含まれています。ここで行うすべての変更は、メッセージフロータブの下のイベントプロセッサのプロパティビューだけでなく、キャンバスにも反映されます。

構成XMLタブ

ビュー

アクティブなエディターの場合、Anypoint studioは、ビューの助けを借りて、プロジェクトのメタデータ、プロパティのグラフィック表示を提供します。ユーザーは、Muleプロジェクトでビューを移動したり、閉じたり、追加したりできます。以下はAnypoint studioのいくつかのデフォルトビューです-

パッケージエクスプローラー

パッケージエクスプローラービューの主なタスクは、Muleプロジェクトに含まれるプロジェクトフォルダーとファイルを表示することです。 Muleプロジェクトフォルダの横にある矢印をクリックして、フォルダを展開または縮小できます。フォルダまたはファイルは、ダブルクリックして開くことができます。そのスクリーンショットを見てください-

パッケージエクスプローラー

ミュールパレット

ミュールパレットビューには、スコープ、フィルター、フロー制御ルーターなどのイベントプロセッサーと、モジュールおよびそれらの関連操作が表示されます。 Mule Paletteビューの主なタスクは次のとおりです-

このビューは、プロジェクトのモジュールとコネクタを管理するのに役立ちます。
Exchangeから新しい要素を追加することもできます。

そのスクリーンショットを見てください-

ミュールパレット

ラバのプロパティ

名前が示すように、キャンバスで現在選択されているモジュールのプロパティを編集できます。ラバのプロパティビューには次のものが含まれます-

ペイロードのデータ構造に関するリアルタイム情報を提供するDataSense Explorer。
インバウンドおよびアウトバウンドのプロパティ（利用可能な場合）または変数。

以下はスクリーンショットです-

ミュールのプロパティ

コンソール

ESB Muleアプリケーションを作成または実行するたびに、組み込みESB Muleサーバーは、Studioによって報告されたイベントおよび問題のリストを表示します。コンソールビューには、その組み込みMuleサーバーのコンソールが含まれています。そのスクリーンショットを見てください-

コンソール

問題ビュー

Muleプロジェクトの作業中に多くの問題に遭遇する可能性があります。これらの問題はすべて、問題ビューに表示されます。以下はスクリーンショットです

問題ビュー

展望

Anypoint Studioでは、指定された配置のビューとエディターのコレクションです。 Anypoint Studioには2種類のパースペクティブがあります-

ミュールデザインパースペクティブ-スタジオで取得するデフォルトのパースペクティブです。

Muleデバッグパースペクティブ*-Anypoint Studioが提供するもう1つのパースペクティブはMuleデバッグパースペクティブです。

一方、独自のパースペクティブを作成し、デフォルトビューを追加または削除することもできます。

MuleSoft-最初のMuleアプリケーションの作成

この章では、MuleSoftのAnypoint Studioで最初のMuleアプリケーションを作成します。作成するには、まずAnypoint Studioを起動する必要があります。

Anypoint Studioの起動

Anypoint Studioをクリックして起動します。初めて起動する場合は、次のウィンドウが表示されます-

Anypoint Studioの起動

Anypoint Studioのユーザーインターフェイス

[ワークスペースに移動]ボタンをクリックすると、次のようにAnypoint Studioのユーザーインターフェイスに移動します-

anypoint Studioのユーザーインターフェイス

ESB Muleアプリケーションの作成手順

ESB Muleアプリケーションを作成するには、以下の手順に従ってください-

新しいプロジェクトの作成

ESB Muleアプリケーションを作成する最初のステップは、新しいプロジェクトを作成することです。以下に示すように、パス FILE→NEW→Mule Project を実行することで実行できます-

ESB Muleアプリケーションの作成手順

プロジェクトの命名

上記のように新しいMuleプロジェクトをクリックすると、プロジェクト名とその他の仕様を尋ねる新しいウィンドウが開きます。プロジェクトの名前「 TestAPP1 」を入力して、完了ボタンをクリックします。

プロジェクトの命名

[完了]ボタンをクリックすると、MuleProject用に構築されたワークスペース、つまり 'TestAPP1' が開きます。前の章で説明したすべての Editors および Views を見ることができます。

TestAPP1

コネクタの構成

ここでは、HTTPリスナー用のシンプルなMuleアプリケーションを作成します。このためには、MuleパレットからHTTPリスナーコネクタをドラッグし、以下に示すようにワークスペースにドロップする必要があります-

コネクタの設定

次に、構成する必要があります。上記に示すように、[基本設定]の下の[コネクタ設定]の後に緑色の+記号をクリックします。

HTTPリスナー設定

[OK]をクリックすると、HTTPリスナーのプロパティページに戻ります。次に、[全般]タブでパスを指定する必要があります。この特定の例では、パス名として /FirstAPP を提供しています。

FirstAppパス名

Set Payload Connectorの構成

次に、Set Payloadコネクタを取得する必要があります。また、次のように設定タブでその値を与える必要があります-

ペイロードコネクタ

これは私の最初のMuleアプリケーション*で、この例で提供されている名前です。

ESB Muleアプリケーション

今、それを保存し、以下に示すように* Muleアプリケーションとして実行*をクリックします-

Muleアプリケーションとして実行

次のようにアプリケーションをデプロイするコンソールで確認できます-

最初のESB Muleアプリケーション

最初のESB Muleアプリケーションが正常にビルドされたことを示しています。

ESB Muleアプリケーションの検証

次に、アプリが実行されているかどうかをテストする必要があります。 ChromeアプリのPOSTMAN に移動して、URLを入力します： http：/localhost：8081 。以下に示すように、Muleアプリケーションの構築中に提供したメッセージが表示されます-

Muleアプリケーションの検証

MuleSoft-DataWeave言語

DataWeaveは基本的にMuleSoft式言語です。 Muleアプリケーションを介して受信したデータにアクセスし、変換するために主に使用されます。 ESB MuleランタイムはESB Muleアプリケーションでスクリプトと式を実行する役割を果たし、DataWeaveはESB Muleランタイムと強力に統合されています。

DataWeave言語の機能

以下は、DataWeave言語のいくつかの重要な機能です-

データは、ある形式から別の形式に非常に簡単に変換できます。たとえば、application/jsonをapplication/xmlに変換できます。入力ペイロードは次のとおりです-

{
   "title": "MuleSoft",
   "author": " finddevguides.com ",
   "year": 2019
}

以下は、変換のためのDataWeaveのコードです-

%dw 2.0
output application/xml
---
{
   order: {
      'type': 'Tutorial',
      'title': payload.title,
      'author': upper(payload.author),
      'year': payload.year
   }
}

次に、*出力*ペイロードは次のとおりです-

<?xml version = '1.0' encoding = 'UTF-8'?>
<order>
   <type>Tutorial</type>
   <title>MuleSoft</title>
   <author>finddevguides.com</author>
   <year>2019</year>
</order>

変換コンポーネントは、単純なデータ変換と複雑なデータ変換の両方を実行するスクリプトの作成に使用できます。

MuleメッセージプロセッサのほとんどがDataWeave式をサポートしているため、必要なMuleイベントの一部でコアDataWeave関数にアクセスして使用できます。

前提条件

コンピューターでDataWeaveスクリプトを使用する前に、次の前提条件を満たす必要があります-

Dataweaveスクリプトを使用するには、Anypoint Studio 7が必要です。
Anypoint Studioをインストールした後、DataWeaveスクリプトを使用するために、Transform Messageコンポーネントでプロジェクトをセットアップする必要があります。

例でDataWeaveスクリプトを使用する手順

DataWeave scripを使用するには、以下の手順に従う必要があります-

ステップ1

最初に、*ファイル→新規→Muleプロジェクト*を使用して、前の章で行ったように、新しいプロジェクトを設定する必要があります。

ステップ2

次に、プロジェクトの名前を指定する必要があります。この例では、 Mule_test_script という名前を付けています。

ステップ3 *

次に、* Transform Messageコンポーネント*を* Mule Paletteタブ*から canvas にドラッグする必要があります。以下のように表示されます-

DataWeaveスクリプト

ステップ4 *

次に、 Transform Message component タブで、PreviewをクリックしてPreviewペインを開きます。 [プレビュー]の横にある空の四角形をクリックして、ソースコード領域を展開できます。

ステップ5 *

これで、DataWeave言語でスクリプト作成を開始できます。

例

以下は、2つの文字列を1つに連結する簡単な例です-

メッセージコンポーネントの変換

上記のDataWeaveスクリプトには、2つの文字列を1つに連結するキーと値のペア*（\ {myString：（ "hello" ++ "World"）}）*があります。

MuleSoft-メッセージプロセッサおよびスクリプトコンポーネント

スクリプトモジュールは、ユーザーがMuleでスクリプト言語を使用できるようにします。簡単に言えば、スクリプトモジュールはスクリプト言語で記述されたカスタムロジックを交換できます。スクリプトは、実装またはトランスフォーマーとして使用できます。式の評価、つまりメッセージルーティングの制御に使用できます。

ESB Muleには、次のサポートされているスクリプト言語があります-

グルーヴィーな
Python
JavaScript
Ruby

スクリプトモジュールのインストール方法

実際、Anypoint Studioにはスクリプトモジュールが付属しています。 Muleパレットでモジュールが見つからない場合は、 + Add Module を使用して追加できます。追加後、Muleアプリケーションでスクリプトモジュール操作を使用できます。

実装例

前述のように、ワークスペースを作成するためにモジュールをキャンバスにドラッグアンドドロップし、アプリケーションで使用する必要があります。以下はその例です-

スクリプトモジュールのインストール

HTTPリスナーコンポーネントの構成方法は既に知っています。したがって、スクリプトモジュールの構成について説明します。スクリプトモジュールを構成するには、以下の手順に従う必要があります-

ステップ1

Muleパレットからスクリプトモジュールを検索し、上記のようにスクリプトモジュールの EXECUTE 操作をフローにドラッグします。

ステップ2

次に、同じ設定をダブルクリックして、「構成の実行」タブを開きます。

ステップ3 *

一般*タブの下で、以下に示すように*コードテキストウィンドウ*でコードを提供する必要があります-

コードテキストウィンドウ

ステップ4 *

最後に、実行コンポーネントから Engine を選択する必要があります。エンジンのリストは以下のとおりです-

グルーヴィーな
Nashorn（javaScript）
jython（Python） *jRuby（ルビー）

構成XMLエディターでの上記の実行例のXMLは次のとおりです-

<scripting:execute engine="jython" doc:name = "Script">
   <scripting:code>
      def factorial(n):
         if n == 0: return 1
      return n* factorial(n-1)
      result = factorial(10)
   </scripting:code>
</scripting:execute>

メッセージソース

Mule 4にはMule 3メッセージよりも単純化されたモデルがあり、情報を上書きすることなく、コネクタ間で一貫した方法でデータを簡単に操作できます。 ESB Mule 4のメッセージモデルでは、各ESB Muleイベントは2つのもので構成されています：メッセージとそれに関連する変数。

ESB Muleメッセージにはペイロードとその属性があり、属性は主にファイルサイズなどのメタデータです。

また、変数は、演算結果、補助値などの任意のユーザー情報を保持します。

インバウンド

Mule 3のインバウンドプロパティは、Mule 4のAttributesになりました。インバウンドプロパティはメッセージソースから取得したペイロードに関する追加情報を保存することを知っていますが、これはMule 4では属性の助けを借りて行われています。属性には次の利点があります-

属性が強く型付けされているため、属性の助けを借りて、利用可能なデータを簡単に確認できます。
属性に含まれる情報に簡単にアクセスできます。

以下は、Mule 4の典型的なメッセージの例です-

インバウンド

アウトバウンド

Mule 3のアウトバウンドプロパティは、追加データを送信するためにMuleコネクタとトランスポートによって明示的に指定される必要があります。しかし、Mule 4では、それぞれにDataWeave式を使用して、それぞれを個別に設定できます。メインフローで副作用は発生しません。

たとえば、以下のDataWeave式はHTTP要求を実行し、メッセージプロパティを設定する必要なくヘッダーとクエリパラメーターを生成します。これは以下のコードに示されています-

<http:request path = "M_issue" config-ref="http" method = "GET">
   <http:headers>#[{'path':'input/issues-list.json'}]</http:headers>
   <http:query-params>#[{'provider':'memory-provider'}]</http:query-params>
</http:request>

メッセージプロセッサ

ESB Muleがメッセージソースからメッセージを受信すると、メッセージプロセッサの作業が開始されます。 ESB Muleは、1つ以上のメッセージプロセッサを使用して、フローを介してメッセージを処理します。メッセージプロセッサの主なタスクは、ESB Muleフローを通過するメッセージを変換、フィルタリング、強化、処理することです。

Muleプロセッサの分類

以下は、機能に基づいてMuleプロセッサのカテゴリです-

コネクタ-これらのメッセージプロセッサはデータを送受信します。また、標準プロトコルまたはサードパーティAPIを介して外部データソースにデータをプラグインします。
コンポーネント-これらのメッセージプロセッサは本質的に柔軟性があり、Java、JavaScript、Groovy、Python、Rubyなどのさまざまな言語で実装されたビジネスロジックを実行します。
フィルタ-メッセージをフィルタリングし、特定の基準に基づいて、特定のメッセージのみをフローで処理し続けることができます。
ルーター-このメッセージプロセッサは、ルーティング、リシーケンシング、またはスプリットするメッセージのフローを制御するために使用されます。
スコープ-フロー内のきめ細かい動作を定義するために、基本的にコードのスニペットをラップします。
*トランスフォーマー-トランスフォーマーの役割は、システム間の通信を容易にするためにメッセージペイロードタイプとデータ形式を変換することです。
ビジネスイベント-基本的に、主要業績評価指標に関連するデータをキャプチャします。
例外戦略-これらのメッセージプロセッサは、メッセージ処理中に発生するあらゆるタイプのエラーを処理します。

MuleSoft-コアコンポーネントと構成

Muleの最も重要な機能の1つは、コンポーネントを使用してルーティング、変換、および処理を実行できることです。そのため、さまざまな要素を結合するMuleアプリケーションの構成ファイルのサイズは非常に大きくなります。

ESB Muleが提供する構成パターンのタイプは次のとおりです-

シンプルなサービスパターン
ブリッジ
バリデーター
HTTPプロキシ
WSプロキシ

コンポーネントの構成

Anypoint studioでは、以下の手順に従ってコンポーネントを構成できます-

ステップ1

ESB Muleアプリケーションで使用したいコンポーネントをドラッグする必要があります。たとえば、ここでは次のようにHTTPリスナーコンポーネントを使用します-

コンポーネントの構成

ステップ2

次に、コンポーネントをダブルクリックして、構成ウィンドウを取得します。 HTTPリスナーの場合、それは以下に示されています-

設定ウィンドウ

ステップ3 *

プロジェクトの要件に従ってコンポーネントを構成できます。たとえば、HTTPリスナーコンポーネントに対して行った-

HTTPリスナーコンポーネント

コアコンポーネントは、Muleアプリのワークフローの重要な構成要素の1つです。 ESB Muleイベントを処理するためのロジックは、これらのコアコンポーネントによって提供されます。 Anypoint studioでは、これらのコアコンポーネントにアクセスするには、以下に示すように、Muleパレットからコアをクリックします-

App Mule Palette

以下は、さまざまな*コアコンポーネントとMule 4 *での動作です-

カスタムビジネスイベント

このコアコンポーネントは、Muleアプリでビジネストランザクションを処理するメッセージプロセッサだけでなく、フローに関する情報の収集にも使用されます。言い換えると、カスタムビジネスイベントコンポーネントを使用して、次の作業フローを追加できます-

メタデータ
主要業績評価指標（KPI）

KPIを追加する方法は？

ESB MuleアプリのフローにKPIを追加する手順は次のとおりです-

ステップ1 *-Muleアプリのワークフローにカスタムビジネスイベントコンポーネントを追加するには、Mule *パレット→コア→コンポーネント→カスタムビジネスイベント*に従います。

ステップ2 *-コンポーネントをクリックして開きます。

ステップ3 *-次に、表示名とイベント名の値を指定する必要があります。

ステップ4 *-メッセージペイロードから情報をキャプチャするには、次のようにKPIを追加します-

KPIの名前（キー）（_tracking：meta-data_要素）と値を指定します。この名前は、ランタイムマネージャーの検索インターフェイスで使用されます。
ESB Mule式の値を指定します。

例

次の表は、名前と値を持つKPIのリストで構成されています-

Name	Expression/Value
Student RollNo	#[payload[‘RollNo’]]
Student Name	#[payload[‘Name’]]

動的評価

このコアコンポーネントは、Muleアプリでスクリプトを動的に選択するために使用されます。 Transform Messageコンポーネントを介してハードコアスクリプトを使用することもできますが、Dynamic Evaluateコンポーネントを使用する方がより良い方法です。このコアコンポーネントは次のように動作します-

まず、別のスクリプトを生成する式を評価します。
次に、そのスクリプトを評価して最終結果を求めます。

このようにして、ハードコーディングするのではなく、動的にスクリプトを選択できます。

例

Idクエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを_MyScript_という名前の変数に保存する例を次に示します。これで、動的評価コンポーネントは変数にアクセスしてスクリプトを呼び出し、 UName クエリパラメーターから名前変数を追加できるようになります。

フローのXML構成は以下のとおりです-

<flow name = "DynamicE-example-flow">
   <http:listener config-ref = "HTTP_Listener_Configuration" path = "/"/>
   <db:select config-ref = "dbConfig" target = "myScript">
      <db:sql>#["SELECT script FROM SCRIPTS WHERE ID =
         $(attributes.queryParams.Id)"]
      </db:sql>
   </db:select>
   <ee:dynamic-evaluate expression = "#[vars.myScript]">
      <ee:parameters>#[{name: attributes.queryParams.UName}]</ee:parameters>
   </ee:dynamic-evaluate>
</flow>

スクリプトは、メッセージ、ペイロード、変数、属性などのコンテキスト変数を使用できます。ただし、カスタムコンテキスト変数を追加する場合は、キーと値のペアのセットを提供する必要があります。

動的評価の構成

次の表は、動的評価コンポーネントを構成する方法を提供します-

Field	Value	Description	Example
Expression	DataWeave expression	It specifies the expression to be evaluated into the final script.	expression="#[vars.generateOrderScript]"
Parameters	DataWeave expression	It specifies key-value pairs.	#[\{joiner: ' and ', id: payload.user.id}]

フロー参照コンポーネント

ESB Muleイベントを別のフローまたはサブフローにルーティングし、同じESB Muleアプリ内に戻す場合、フロー参照コンポーネントが適切なオプションです。

特徴

このコアコンポーネントの特徴は次のとおりです-

このコアコンポーネントにより、参照されるフロー全体を現在のフロー内の単一のコンポーネントのように扱うことができます。
ESB Muleアプリケーションを個別の再利用可能なユニットに分割します。たとえば、フローは定期的にファイルをリストしています。リスト操作の出力を処理する別のフローを参照する場合があります。
この方法では、処理ステップ全体を追加するのではなく、処理フローを指すフロー参照を追加できます。以下のスクリーンショットは、フロー参照コアコンポーネントが ProcessFiles という名前のサブフローを指していることを示しています。

フロー参照コンポーネント

ワーキング

フロー参照コンポーネントの動作は、次の図の助けを借りて理解することができます-

メイン作業フロー

この図は、1つのフローが同じアプリケーション内の別のフローを参照する場合のMuleアプリケーションの処理順序を示しています。 ESB Muleアプリケーションのメイン作業フローがトリガーされると、ESB Muleイベントはフローを通過し、ESB Muleイベントがフロー参照に到達するまでフローを実行します。

フロー参照に到達すると、ESB Muleイベントは参照されたフローを最初から最後まで実行します。 ESB MuleイベントがRef Flowの実行を終了すると、メインフローに戻ります。

例

理解を深めるために、 Anypoint Studio でこのコンポーネントを使用してみましょう。この例では、前の章で行ったように、HTTPリスナーを使用してメッセージを取得しています。そのため、コンポーネントをドラッグアンドドロップして構成できます。しかし、この例では、以下に示すように、サブフローコンポーネントを追加し、その下にペイロードコンポーネントを設定する必要があります-

Anypoint Studioのコンポーネント

次に、 Set Payload をダブルクリックして設定する必要があります。ここでは、以下に示すように、「サブフローが実行されました」という値を与えています-

ペイロードの設定

サブフローコンポーネントを正常に構成したら、メインフローのペイロードを設定した後に設定するフロー参照コンポーネントが必要です。これは、以下に示すように、Muleパレットからドラッグアンドドロップできます-

サブフローコンポーネント

次に、フロー参照コンポーネントの構成中に、以下に示すように、[一般]タブで[フロー名]を選択する必要があります-

フロー名の選択

次に、このアプリケーションを保存して実行します。これをテストするには、POSTMANに移動し、URLバーに http：/localhost：8181/FirstAPP と入力すると、「サブフローが実行されました」というメッセージが表示されます。

郵便配達員

ロガーコンポーネント

ロガーと呼ばれるコアコンポーネントは、エラーメッセージ、ステータス通知、ペイロードなどの重要な情報を記録することにより、Muleアプリケーションの監視とデバッグを支援します。 AnyPointスタジオでは、それらは Console に表示されます。

利点

ロガーコンポーネントのいくつかの利点は次のとおりです-

このコアコンポーネントは、作業フローのどこにでも追加できます。
私たちが指定した文字列を記録するように設定できます。
私たちが書いたDataWeave式の出力にそれを設定できます。
文字列と式の任意の組み合わせに設定することもできます。

例

次の例では、ブラウザのSet Payloadに「Hello World」というメッセージが表示され、メッセージもログに記録されます。

ロガーコンポーネント

上記の例のフローのXML構成は次のとおりです-

<http:listener-config name = "HTTP_Listener_Configuration" host = "localhost" port = "8081"/>
<flow name = "mymuleprojectFlow">
   <http:listener config-ref="HTTP_Listener_Configuration" path="/"/>
   <set-payload value="Hello World"/>
   <logger message = "#[payload]" level = "INFO"/>
</flow>

転送メッセージコンポーネント

変換コンポーネントとも呼ばれる変換メッセージコンポーネントを使用すると、入力データを新しい出力形式に変換できます。

変換を構築する方法

私たちは次の2つの方法の助けを借りて変換を構築することができます-

ドラッグアンドドロップエディタ（グラフィカルビュー）-これは、変換を構築するための最初で最も使用される方法です。この方法では、このコンポーネントのビジュアルマッパーを使用して、受信データ構造の要素をドラッグアンドドロップできます。たとえば、次の図では、2つのツリービューに、入力と出力の予想されるメタデータ構造が表示されています。入力を出力フィールドに接続する線は、2つのツリービュー間のマッピングを表します。

メッセージコンポーネントの転送

スクリプトビュー-変換の視覚的なマッピングは、Muleコードの言語であるDataWeaveを使用して表現することもできます。集約、正規化、グループ化、結合、パーティション化、ピボット、フィルタリングなどの高度な変換のコーディングを行うことができます。例は以下のとおりです-

変換ソース

このコアコンポーネントは、基本的に変数、属性、またはメッセージペイロードの入力および出力メタデータを受け入れます。次の形式固有のリソースを提供できます-

CSV
スキーマ
フラットファイルスキーマ
JSON
オブジェクトクラス
シンプルタイプ
XMLスキーマ
Excelの列名とタイプ
固定幅列の名前とタイプ

MuleSoft-エンドポイント

エンドポイントには基本的に、Muleアプリケーションの作業フローで処理をトリガーまたは開始するコンポーネントが含まれます。 Anypoint Studioでは Source 、Muleのデザインセンターでは Triggers と呼ばれます。 ESB Mule 4の重要なエンドポイントの1つは*スケジューラーコンポーネント*です。

スケジューラーエンドポイント

このコンポーネントは、時間ベースの条件で機能します。つまり、時間ベースの条件が満たされるたびにフローをトリガーできます。例えば、スケジューラーは、10秒ごとにESB Muleの作業フローを開始するイベントをトリガーできます。柔軟なCron式を使用して、スケジューラエンドポイントをトリガーすることもできます。

スケジューラに関する重要なポイント

スケジューライベントを使用している間、以下に示すいくつかの重要な点に注意する必要があります-

スケジューラーエンドポイントは、Muleランタイムが実行されているマシンのタイムゾーンに従います。
ESB MuleアプリケーションがCloudHubで実行されている場合、スケジューラはCloudHubワーカーが実行されている地域のタイムゾーンに従うと仮定します。
常に、スケジューラエンドポイントによってトリガーされる1つのフローのみをアクティブにできます。
ESB Muleランタイムクラスタでは、スケジューラエンドポイントはプライマリノードでのみ実行またはトリガーされます。

スケジューラを構成する方法

上で説明したように、スケジューラエンドポイントを固定間隔でトリガーされるように構成することも、Cron式を指定することもできます。

スケジューラーを構成するパラメーター（固定間隔の場合）

定期的な間隔でフローをトリガーするスケジューラーを設定するパラメーターは次のとおりです-

周波数-基本的に、スケジューラエンドポイントがMuleフローをトリガーする周波数を示します。この時間の単位は、[時間単位]フィールドから選択できます。この値を指定しない場合、デフォルト値の1000が使用されます。一方、0または負の値を指定すると、デフォルト値も使用されます。

開始遅延-アプリケーションが開始されてから初めてMuleフローをトリガーするまでの待機時間です。開始遅延の値は、周波数と同じ時間単位で表されます。デフォルト値は0です。

時間単位-周波数と開始遅延の両方の時間単位を記述します。時間単位の可能な値は、ミリ秒、秒、分、時間、日です。デフォルト値はミリ秒です。

スケジューラーを構成するパラメーター（Cron式の場合）

実際、Cronは時刻と日付の情報を記述するために使用される標準です。柔軟なCron式を使用してスケジューラーをトリガーする場合、Scheduler Endpointは毎秒を追跡し、Quartz Cron式が日時設定に一致するたびにMuleイベントを作成します。 Cron式を使用すると、イベントは1回だけ、または定期的にトリガーできます。

次の表は、6つの必要な設定の日時表現を示しています-

Attribute	Value
Seconds	0-59
Minutes	0-59
Hours	0-23
Day of month	1-31
Month	1-12 or JAN-DEC
Day of the week	1-7 or SUN-SAT

スケジューラエンドポイントでサポートされているQuartz Cron式のいくつかの例を以下に示します-

½ * * ？-スケジューラが毎日2秒ごとに実行されることを意味します。
0 0/5 16 ？-スケジューラが毎日午後4時から午後4時55分まで5分ごとに実行されることを意味します。
1 1 1 1、5 ？*-スケジューラが毎年1月1日と4月1日を実行することを意味します。

例

次のコードは、メッセージ「hi」を毎秒記録します-

<flow name = "cronFlow" doc:id = "ae257a5d-6b4f-4006-80c8-e7c76d2f67a0">
   <doc:name = "Scheduler" doc:id = "e7b6scheduler8ccb-c6d8-4567-87af-aa7904a50359">
      <scheduling-strategy>
         <cron expression = "* * * * * ?" timeZone = "America/Los_Angeles"/>
      </scheduling-strategy>
   </scheduler>
   <logger level = "INFO" doc:name = "Logger"
      doc:id = "e2626dbb-54a9-4791-8ffa-b7c9a23e88a1" message = '"hi"'/>
</flow>

MuleSoft-フロー制御と変圧器

フロー制御（ルーター）

フロー制御コンポーネントの主なタスクは、入力Muleイベントを取得し、それを1つ以上のコンポーネントシーケンスにルーティングすることです。基本的には、入力Muleイベントをコンポーネントの他のシーケンスにルーティングします。したがって、ルーターとも呼ばれます。 Choice and Scatter-Gatherルーターは、フロー制御コンポーネントで最も使用されているルーターです。

選択肢ルーター

名前が示すように、このルーターはDataWeaveロジックを適用して2つ以上のルートのいずれかを選択します。前述のように、各ルートはESB Muleイベントプロセッサの個別のシーケンスです。選択ルーターは、メッセージコンテンツの評価に使用される一連のDataWeave式に従って、フローを介してメッセージを動的にルーティングするルーターとして定義できます。

選択肢ルーターの概略図

Choiceルーターを使用する効果は、ほとんどのプログラミング言語でフローまたは if/then/else コードブロックに条件付き処理を追加するのと同じです。以下に、3つのオプションがある選択肢ルーターの概略図を示します。これらのうち、1つはデフォルトのルーターです。

選択ルーター

スキャッターギャザールーター

もう1つの最もよく使用されるルーティングイベントプロセッサは、* Scatter-Gatherコンポーネント*です。その名前が示すように、スキャター（コピー）とギャザー（統合）の基本に作用します。私たちは次の2つのポイントの助けを借りてその働きを理解することができます-

まず、このルーターはMuleイベントを2つ以上のパラレルルートにコピー（散布）します。条件は、各ルートがサブフローのような1つ以上のイベントプロセッサのシーケンスでなければならないということです。この場合の各ルートは、個別のスレッドを使用してMuleイベントを作成します。各Muleイベントには、変数と同様に独自のペイロード、属性があります。
次に、このルーターは各ルートから作成されたMuleイベントを収集し、それらを新しいMuleイベントに統合します。その後、この統合Muleイベントを次のイベントプロセッサに渡します。ここでの条件は、すべてのルートが正常に完了した場合にのみ、S-Gルーターが統合Muleイベントを次のイベントプロセッサに渡すことです。

スキャッターギャザールーターの概略図

以下は、4つのイベントプロセッサを持つスキャターギャザールーターの概略図です。すべてのルートを順番に実行するのではなく、並行して実行します。

Scatter Gather Router

スキャッターギャザールーターによるエラー処理

まず、Scatter-Gatherコンポーネント内で生成される可能性のあるエラーの種類に関する知識が必要です。 Scatter-Gatherコンポーネントがタイプ Mule：COMPOSITE_ERROR のエラーをスローするイベントプロセッサ内でエラーが生成される場合があります。このエラーは、すべてのルートが失敗または完了した後にのみ、S-Gコンポーネントによってスローされます。

このエラータイプを処理するには、Scatter-Gatherコンポーネントの各ルートで* tryスコープ*を使用できます。エラーが try scope によって正常に処理された場合、ルートはMuleイベントを確実に生成できます。

変圧器

ESB Muleイベントの一部を設定または削除する場合は、Transformerコンポーネントが最適な選択肢です。トランスコンポーネントは次のタイプのものです-

可変トランスフォーマーを削除

名前が示すように、このコンポーネントは変数名を取得し、Muleイベントからその変数を削除します。

変数トランスフォーマーの削除の構成

以下の表は、変数トランスフォーマーの削除を構成する際に考慮されるフィールドの名前とその説明を示しています-

Sr.No

Field & Explanation

1

Display Name (doc:name)

ESB Muleワークフローでこのコンポーネントの一意の名前を表示するようにカスタマイズできます。

2

Name (variableName)

削除する変数の名前を表します。

ペイロードトランスフォーマーの設定

*set-payload* コンポーネントを使用して、メッセージのペイロードを更新できます。ペイロードは、リテラル文字列またはDataWeave式にすることができます。 このコンポーネントを複雑な式や変換に使用することはお勧めしません。 *selections* のような単純なものに使用できます。

次の表は、セットペイロードトランスフォーマーの構成中に考慮されるフィールドの名前とその説明を示しています-

Field	Usage	Explanation
Value (value)	Mandatory	The value filed is required for setting a payload. It will accept a literal string or DataWeave expression defining how to set the payload. The examples are like “some string”
Mime Type (mimeType)	Optional	It’s optional but represents the mime type of the value assigned to the payload of message. The examples are like text/plain.
Encoding (encoding)	Optional	It’s also optional but represents the encoding of the value that is assigned to the payload of message. The examples are like UTF-8.

私たちはXML構成コードを介してペイロードを設定できます-

静的コンテンツあり-次のXML構成コードは、静的コンテンツを使用してペイロードを設定します-

<set-payload value = "{ 'name' : 'Gaurav', 'Id' : '2510' }"
   mimeType = "application/json" encoding = "UTF-8"/>

式コンテンツを使用-次のXML構成コードは、式コンテンツを使用してペイロードを設定します-

<set-payload value = "#['Hi' ++ ' Today is ' ++ now()]"/>

上記の例は、今日の日付にメッセージペイロード「Hi」を追加します。

可変変圧器の設定

*set variable* コンポーネントの助けを借りて、Muleアプリケーションのフロー内で使用するために、文字列、メッセージペイロード、属性オブジェクトなどの単純なリテラル値である値を格納する変数を作成または更新できます。 このコンポーネントを複雑な式や変換に使用することはお勧めしません。 *selections* のような単純なものに使用できます。

セット変数トランスフォーマーの構成

次の表は、セットペイロードトランスフォーマーの構成中に考慮されるフィールドの名前とその説明を示しています-

Field	Usage	Explanation
Variable Name (variableName)	Mandatory	It is required filed and it represents the name of the variable. While giving the name, follow the naming convention like it must contain number, characters and underscores.
Value (value)	Mandatory	The value filed is required for setting a variable. It will accept a literal string or DataWeave expression.
Mime Type (mimeType)	Optional	It’s optional but represents the mime type of the variable. The examples are like text/plain.
Encoding (encoding)	Optional	It’s also optional but represents the encoding of the variable. The examples are like ISO 10646/Unicode(UTF-8).

例

以下の例では、変数にメッセージペイロードを設定します-

Variable Name = msg_var
Value = payload in Design center and #[payload] in Anypoint Studio

同様に、以下の例では、変数にメッセージペイロードを設定します-

Variable Name = msg_var
Value = attributes in Design center and #[attributes] in Anypoint Studio.

MuleSoft-Anypoint Studioを使用したWebサービス

REST Webサービス

RESTの完全な形式は、HTTPにバインドされたRepresentational State Transferです。したがって、Webでのみ使用されるアプリケーションを設計する場合は、RESTが最適なオプションです。

RESTful Webサービスの使用

次の例では、RESTコンポーネントと、Mule Softが提供するAmerican Flight detailsという1つの公開RESTfulサービスを使用します。さまざまな詳細がありますが、すべてのフライトの詳細を返すGET：http：//training-american-ws.cloudhub.io/api/flightsを使用します。前述のように、RESTはHTTPにバインドされているため、このアプリケーションにも2つのHTTPコンポーネントが必要です。1つはリスナーで、もう1つは要求です。以下のスクリーンショットは、HTTPリスナーの構成を示しています-

レストウェブサービス

引数の構成と受け渡し

HTTPリクエストの設定は以下のとおりです-

HTTPリクエスト

今、私たちのワークスペースフローに従って、ロガーを取得しましたので、以下のように設定できます-

ペイロードの変換

[メッセージ]タブで、ペイロードを文字列に変換するコードを作成します。

アプリケーションのテスト

次に、アプリケーションを保存して実行し、POSTMANに移動して、以下に示すように最終出力を確認します-

アプリケーションのテスト

RESTコンポーネントを使用すると、フライトの詳細が表示されます。

SOAPコンポーネント

SOAPの完全な形式は Simple Object Access Protocol です。基本的に、Webサービスの実装で情報を交換するためのメッセージングプロトコル仕様です。次に、Anypoint StudioでSOAP APIを使用して、Webサービスを使用して情報にアクセスします。

SOAPベースのWebサービスを利用する

この例では、国情報に関連するサービスを保持するCountry Info Serviceという名前のパブリックSOAPサービスを使用します。そのWSDLアドレスは、http：//www.oorsprong.org/websamples.countryinfo/countryinfoservice.wso？WSDLです。

まず、以下に示すように、MuleパレットからキャンバスにSOAP消費をドラッグする必要があります-

SOAPの使用

引数の構成と受け渡し

次に、次のように上記の例で行われたようにHTTPリクエストを設定する必要があります-

引数の受け渡し

次に、以下に示すようにWebサービスコンシューマを構成する必要があります-

Webサービスコンシューマ

WSDLの場所の場所で、WSDLのWebアドレスを提供する必要があります。これは上記で提供されています（この例の場合）。 Webアドレスを指定すると、Studioはサービス、ポート、およびアドレスを単独で検索します。手動で提供する必要はありません。

Webサービスからの転送応答

このために、Muleフローにロガーを追加し、以下に示すようにペイロードを与えるように設定する必要があります-

転送応答

Webサービスからの応答

アプリケーションのテスト

アプリケーションを保存して実行し、Google Chromeにアクセスして最終出力を確認します。 http：//localhist：8081/helloSOAP （この例の場合）と入力すると、下のスクリーンショットに示すようにコードで国名が表示されます-

最終出力

MuleSoft-ラバのエラー処理

新しいMuleエラー処理は、Mule 4で行われた最大かつ大きな変更の1つです。新しいエラー処理は複雑に見えるかもしれませんが、より効率的です。この章では、Muleエラーのコンポーネント、エラータイプ、Muleエラーのカテゴリ、およびMuleエラーを処理するためのコンポーネントについて説明します。

ラバエラーのコンポーネント

ESB Muleエラーは、ESB Mule例外エラーの結果であり、次のコンポーネントがあります

説明

Muleエラーの重要な要素であり、問題について説明します。その式は次のとおりです-

#[error.description]

Type

ESB MuleエラーのTypeコンポーネントは、問題を特徴付けるために使用されます。また、エラーハンドラー内でルーティングすることもできます。その式は次のとおりです-

#[error.errorType]

原因

ESB Muleエラーの原因コンポーネントは、失敗の原因となる基礎となるJavaスロー可能オブジェクトを提供します。その式は次のとおりです-

#[error.cause]

メッセージ

ESB Muleエラーの_Message_コンポーネントには、エラーに関するオプションのメッセージが表示されます。その式は次のとおりです-

#[error.errorMessage]

子エラー

ESB Muleエラーの_Child Errors_コンポーネントは、オプションで内部エラーのコレクションを提供します。これらの内部エラーは、主にScatter-Gatherなどの要素によって使用され、集約されたルートエラーを提供します。その式は次のとおりです-

#[error.childErrors]

例

401ステータスコードでHTTPリクエストが失敗した場合、ミュールエラーは次のとおりです-

Description: HTTP GET on resource ‘http://localhost:8181/TestApp’
failed: unauthorized (401)
Type: HTTP:UNAUTHORIZED
Cause: a ResponseValidatorTypedException instance
Error Message: { "message" : "Could not authorize the user." }

Sr.NO	Error Type and Description
1	TRANSFORMATION このエラータイプは、値の変換中にエラーが発生したことを示します。変換はMule Runtime内部変換であり、DataWeave変換ではありません。
2	EXPRESSION この種類のエラータイプは、式の評価中にエラーが発生したことを示します。
3	VALIDATION この種類のエラータイプは、検証エラーが発生したことを示します。
4	DUPLICATE_MESSAGE メッセージが2回処理されているときに発生する一種の検証エラー。
5	REDELIVERY_EXHAUSTED この種類のエラータイプは、ソースからのメッセージを再処理する最大試行回数を使い果たした場合に発生します。
6	CONNECTIVITY このエラータイプは、接続の確立中の問題を示します。
7	ROUTING このエラータイプは、メッセージのルーティング中にエラーが発生したことを示します。
8	SECURITY このエラータイプは、セキュリティエラーが発生したことを示します。たとえば、無効な資格情報を受信しました。
9	STREAM_MAXIMUM_SIZE_EXCEEDED このエラータイプは、ストリームの最大サイズが使い果たされたときに発生します。
10	TIMEOUT メッセージの処理中のタイムアウトを示します。
11	UNKNOWN このエラータイプは、予期しないエラーが発生したことを示します。
12	SOURCE フローのソースでエラーが発生したことを表します。
13	SOURCE_RESPONSE 成功した応答の処理中に、フローのソースでエラーが発生したことを表します。

上記の例では、ラバエラーの_message_コンポーネントを確認できます。

エラーの種類

その特性の助けを借りてエラータイプを理解しましょう-

ESB Muleエラータイプの最初の特徴は、名前空間と識別子*の両方で構成されることです。これにより、ドメインに応じてタイプを区別できます。上記の例では、エラータイプは *HTTP：UNAUTHORIZED です。
2番目の重要な特性は、エラータイプに親タイプがある場合があることです。たとえば、エラータイプ HTTP：UNAUTHORIZED の親は MULE：CLIENT_SECURITY であり、その親は MULE：SECURITY という名前の親も持っています。この特性は、よりグローバルなアイテムの仕様としてエラータイプを確立します。

エラーの種類

以下は、すべてのエラーが分類されるカテゴリです-

ANY

このカテゴリのエラーは、フローで発生する可能性のあるエラーです。それらはそれほど厳しくなく、簡単に処理できます。

クリティカル

このカテゴリのエラーは、処理できない重大なエラーです。以下は、このカテゴリの下のエラータイプのリストです-

Sr.NO

Error Type and Description

1

OVERLOAD

このエラータイプは、過負荷の問題によりエラーが発生したことを示します。この場合、実行は拒否されます。

2

FATAL_JVM_ERROR

この種類のエラータイプは、致命的なエラーの発生を示します。たとえば、スタックオーバーフロー。

カスタムエラータイプ

カスタムエラータイプは、当社が定義したエラーです。それらは、マッピング時またはエラー発生時に定義できます。 ESB Muleアプリケーション内の他の既存のエラータイプと区別するために、これらのエラータイプに特定のカスタム名前空間を与える必要があります。たとえば、HTTPを使用するESB Muleアプリケーションでは、カスタムエラータイプとしてHTTPを使用できません。

ラバエラーのカテゴリ

広い意味で、Muleのエラーは2つのカテゴリ、つまり Messaging ErrorsとSystem Errors に分類できます。

メッセージングエラー

Muleエラーのこのカテゴリは、Muleフローに関連しています。 ESB Muleフロー内で問題が発生すると、ESB Muleはメッセージングエラーをスローします。これらのESB Muleエラーを処理するために、エラーハンドラコンポーネント内に On Error コンポーネントを設定できます。

システムエラー

システムエラーは、システムレベルで例外が発生したことを示します。 ESB Muleイベントがない場合、システムエラーはシステムエラーハンドラーによって処理されます。次の種類の例外は、システムエラーハンドラによって処理されます-

アプリケーションの起動中に発生する例外。
外部システムへの接続が失敗したときに発生する例外。

システムエラーが発生した場合、Muleは登録されたリスナーにエラー通知を送信します。エラーも記録します。一方、Muleは、エラーが接続の失敗によって引き起こされた場合、再接続戦略を実行します。

ESB Muleエラーの処理

ESB Muleには、エラーを処理するための次の2つのエラーハンドラがあります-

エラー時のエラーハンドラー

Muleの最初のエラーハンドラはOn-Errorコンポーネントで、処理可能なエラーのタイプを定義します。前に説明したように、スコープのようなエラーハンドラコンポーネント内でOn-Errorコンポーネントを構成できます。各Muleフローにはエラーハンドラーが1つしか含まれていませんが、このエラーハンドラーには必要な数のOn-Errorスコープを含めることができます。 On-Errorコンポーネントの助けを借りて、フロー内のMuleエラーを処理する手順は次のとおりです-

まず、ESB Muleフローでエラーが発生すると、通常のフロー実行は停止します。
次に、プロセスは、エラーの種類と式に一致する* On Errorコンポーネント*を既に持っている Error Handler Component に転送されます。
最後に、エラーハンドラコンポーネントは、エラーに一致する最初の* On Errorスコープ*にエラーをルーティングします。

メッセージングの処理

ESB MuleがサポートしているOn-Errorコンポーネントには2種類あります-

エラー時の伝播

On-Error Propagateコンポーネントは実行されますが、エラーを次のレベルに伝播し、所有者の実行を中断します。 On Error Propagate コンポーネントによって処理される場合、トランザクションはロールバックされます。

エラー時の続行

On-Error Propagateコンポーネントと同様に、On-Error Continueコンポーネントもトランザクションを実行します。唯一の条件は、所有者が実行を正常に完了した場合、このコンポーネントは実行結果を所有者の結果として使用することです。 On-Error Continueコンポーネントによって処理される場合、トランザクションはコミットされます。

Scopeコンポーネントを試す

Try Scopeは、Mule 4で利用可能な多くの新機能の1つです。これは、例外の可能性があるコードを囲むJavaのtryブロックと同様に機能するため、コード全体を壊すことなく処理できます。

Try Scopeで1つ以上のMuleイベントプロセッサをラップできます。その後、tryスコープはこれらのイベントプロセッサによってスローされる例外をキャッチして処理します。 tryスコープの主な機能は、フロー全体ではなく内部コンポーネントのエラー処理をサポートする独自のエラー処理戦略を中心に展開します。そのため、フローを別のフローに抽出する必要はありません。

例

以下は、tryスコープの使用例です-

スコープを試す

トランザクションを処理するためのtryスコープの構成

私たちが知っているように、トランザクションは部分的に実行されるべきではない一連のアクションです。トランザクションのスコープ内のすべての操作は同じスレッドで実行され、エラーが発生した場合、ロールバックまたはコミットにつながるはずです。次の方法でtryスコープを構成して、子操作をトランザクションとして扱うことができます。

トライスコープの設定

INDIFFERENT [デフォルト] -tryブロックでこの構成を選択した場合、子アクションはトランザクションとして扱われません。この場合、エラーはロールバックもコミットも引き起こしません。
ALWAYS_BEGIN -スコープが実行されるたびに新しいトランザクションが開始されることを示します。
BEGIN_OR_JOIN -フローの現在の処理が既にトランザクションを開始している場合、それを結合することを示します。それ以外の場合は、新しいものを開始します。

MuleSoft-ミュールの例外処理

すべてのプロジェクトの場合、例外に関する事実は、例外が発生することです。そのため、システム/アプリケーションが矛盾した状態にならないように、例外をキャッチ、分類、および処理することが重要です。すべてのESB Muleアプリケーションに暗黙的に適用されるデフォルトの例外戦略があります。保留中のトランザクションを自動的にロールバックすることがデフォルトの例外戦略です。

ESB Muleの例外

例外処理を詳しく説明する前に、例外ハンドラーの設計時に開発者がしなければならない3つの基本的な質問とともに、どのような例外が発生する可能性があるかを理解する必要があります。

どのトランスポートが重要ですか？

すべてのトランスポートは多国籍性をサポートしていないため、この質問は例外ハンドラーを設計する前に十分な関連性があります。

ファイル*または *HTTP はトランザクションをサポートしていません。そのため、これらのケースで例外が発生した場合、手動で管理する必要があります。

データベース*はトランザクションをサポートします。この場合の例外ハンドラを設計するとき、データベーストランザクションは自動的にロールバックできることに注意する必要があります（必要な場合）。

*REST API* の場合、正しいHTTPステータスコードを返す必要があることに注意してください。 たとえば、リソースが見つからない場合の404。

どのメッセージ交換パターンを使用しますか？

例外ハンドラを設計するときは、メッセージ交換パターンに注意する必要があります。同期（要求-応答）または非同期（消火-忘れ）メッセージパターンがあります。

同期メッセージパターン*は要求/応答形式に基づいています。つまり、このパターンは応答を予期し、応答が返されるかタイムアウトが発生するまでブロックされます。

非同期メッセージパターン*は、ファイアフォーゲット形式に基づいています。つまり、このパターンは、リクエストが最終的に処理されることを前提としています。

どのタイプの例外ですか？

非常に単純なルールは、そのタイプに基づいて例外を処理することです。例外の原因がシステム/技術的な問題なのかビジネス上の問題なのかを知ることは非常に重要ですか？

システム/技術的な問題（ネットワークの停止など）によって発生した例外は、再試行メカニズムによって自動的に処理される必要があります。

一方、根本的な原因を修正せずに再試行するのは役に立たないため、再試行メカニズムを適用しても、ビジネス上の問題（無効なデータなど）によって発生した例外は解決できません。

例外を分類する理由

すべての例外が同じではないことがわかっているため、例外を分類することは非常に重要です。高レベルでは、例外は次の2つのタイプに分類できます-

ビジネスの例外

ビジネス例外が発生する主な理由は、不正なデータまたは不正なプロセスフローです。これらの種類の例外は通常、本質的に再試行不可能であるため、ロールバック*を設定することは適切ではありません。 *retry メカニズムを適用しても、根本的な原因を修正せずに再試行することは役に立たないため、意味がありません。このような例外を処理するには、処理を直ちに停止し、デッドレターキューへの応答として例外を送り返す必要があります。通知もオペレーションに送信する必要があります。

非ビジネス例外

ビジネス以外の例外が発生する主な理由は、システムの問題または技術的な問題です。これらの種類の例外は本質的に再試行可能であるため、これらの例外を解決するために*再試行*メカニズムを構成することをお勧めします。

例外処理戦略

ESB Muleには、次の5つの例外処理戦略があります-

デフォルトの例外戦略

ESB Muleは暗黙的にこの戦略をESB Muleフローに適用します。フロー内のすべての例外を処理できますが、catch、Choice、またはRollback例外戦略を追加することでオーバーライドすることもできます。この例外戦略は、保留中のトランザクションをロールバックし、例外もログに記録します。この例外戦略の重要な特徴は、トランザクションがない場合にも例外をログに記録することです。

Muleはデフォルトの戦略であるため、フローでエラーが発生した場合にこれを実装します。 AnyPointスタジオでは構成できません。

ロールバック例外戦略

エラーを修正する可能な解決策がない場合はどうすればよいでしょうか？解決策は、ロールバック例外戦略を使用して、親フローのインバウンドコネクタにメッセージを送信するとともにトランザクションをロールバックし、メッセージを再処理することです。この戦略は、メッセージを再処理する場合にも非常に役立ちます。

例

この戦略は、当座預金口座に資金が入金される銀行取引に適用できます。ここでロールバック例外ストラテジーを設定できます。トランザクション中にエラーが発生した場合、このストラテジーはメッセージをフローの最初にロールバックして処理を再試行するためです。

キャッチ例外戦略

この戦略は、親フロー内でスローされるすべての例外をキャッチします。親フローによってスローされたすべての例外を処理することにより、Muleのデフォルトの例外戦略をオーバーライドします。キャッチ例外戦略を使用して、インバウンドコネクタおよび親フローへの例外の伝播も回避できます。

また、この戦略により、フローが処理するトランザクションが例外発生時にロールバックされないようになります。

例

この戦略は、キューからのメッセージを処理するフローがあるフライト予約システムに適用できます。メッセージエンリッチャーは、シートの割り当てのためにメッセージにプロパティを追加し、メッセージを別のキューに送信します。

このフローでエラーが発生すると、メッセージは例外をスローします。ここで、キャッチ例外戦略は、適切なメッセージにヘッダーを追加し、そのメッセージをフローから次のキューにプッシュできます。

選択例外戦略

メッセージの内容に基づいて例外を処理する場合は、例外戦略を選択するのが最適です。この例外戦略の働きは次のようになります-

まず、親フロー内でスローされたすべての例外をキャッチします。
次に、メッセージの内容と例外の種類を確認します。
そして最後に、メッセージを適切な例外戦略にルーティングします。

選択例外戦略内で定義される、キャッチやロールバックなどの複数の例外戦略があります。この例外戦略の下で戦略が定義されていない場合、メッセージはデフォルトの例外戦略にルーティングされます。コミットやロールバックを実行したり、アクティビティを消費したりすることはありません。

参照例外戦略

これは、別の構成ファイルで定義されている一般的な例外戦略を指します。メッセージが例外をスローする場合、この例外戦略は、グローバルキャッチ、ロールバック、または選択例外戦略で定義されたエラー処理パラメーターを参照します。選択例外戦略のように、コミットまたはロールバックを実行したり、アクティビティを消費したりすることはありません。

MuleSoft-MUnitを使用したテスト

ユニットテストは、ソースコードの個々のユニットをテストして、それらが使用に適しているかどうかを判断できる方法であると理解しています。 Javaプログラマーは、Junitフレームワークを使用してテストケースを作成できます。同様に、MuleSoftにはMUnitと呼ばれるフレームワークもあり、APIと統合の自動テストケースを作成できます。継続的な統合/展開環境に最適です。 MUnitフレームワークの最大の利点の1つは、MavenフレームワークをMavenおよびSurefireと統合できることです。

MUnitの機能

以下は、Mule MUnitテストフレームワークの非常に便利な機能の一部です-

MUnitフレームワークでは、MuleコードとJavaコードを使用してMuleテストを作成できます。
MuleアプリとAPIは、Anypoint Studio内でグラフィカルまたはXMLで設計およびテストできます。
MUnitを使用すると、テストを既存のCI/CDプロセスに簡単に統合できます。
自動生成されたテストとカバレッジレポートを提供します。したがって、手作業は最小限です。
また、ローカルDB/FTP/メールサーバーを使用して、CIプロセスを通じてテストの移植性を高めることもできます。
テストを有効または無効にすることができます。
プラグインを使用してMUnitフレームワークを拡張することもできます。
これにより、メッセージプロセッサの呼び出しを確認できます。
MUnitテストフレームワークを使用して、エンドポイントコネクタとフローインバウンドエンドポイントを無効にすることができます。
ESB Muleスタックトレースでエラーレポートを確認できます。

Mule MUnitテストフレームワークの最新リリース

MUnit 2.1.4は、Mule MUnitテストフレームワークの最新リリースです。次のハードウェアおよびソフトウェア要件が必要です-

MS Windows 8+
Apple Mac OS X 10.10以降
Linux
Java 8
Maven 3.3.3、3.3.9、3.5.4、3.6.0

Mule 4.1.4およびAnypoint Studio 7.3.0と互換性があります。

MUnitおよびAnypoint Studio

説明したように、MUnitはAnypoint studioに完全に統合されており、MuleアプリとAPIをグラフィカルに、またはAnypoint studio内のXMLで設計およびテストできます。言い換えれば、Anypoint Studioのグラフィカルインターフェイスを使用して、次のことができます-

MUnitテストの作成および設計用
テストを実行するために
テスト結果とカバレッジレポートの表示用
テストのデバッグ用

それでは、各タスクを1つずつ説明していきましょう。

MUnitテストの作成と設計

新しいプロジェクトを開始すると、プロジェクトに src/test/munit という新しいフォルダーが自動的に追加されます。たとえば、新しいMuleプロジェクト、つまり test_munit を開始しました。下の画像を見るとわかるように、プロジェクトの下に上記のフォルダーが追加されています。

MUnitテストの設計

さて、新しいプロジェクトを開始したら、Anypoint Studioで新しいMUnitテストを作成する2つの基本的な方法があります-

フローを右クリックして-この方法では、特定のフローを右クリックし、ドロップダウンメニューからMUnitを選択する必要があります。
ウィザードを使用して-この方法では、テストを作成するためにウィザードを使用する必要があります。これにより、ワークスペース内の任意のフローのテストを作成できます。

「フローを右クリック」する方法を使用して、特定のフローのテストを作成します。

まず、次のようにワークスペースにフローを作成する必要があります-

テストMUnitFlow

次に、このフローを右クリックし、MUnitを選択して、以下に示すように、このフローのテストを作成します-

Select MUnit

フローが存在するXMLファイルにちなんで名前が付けられた新しいテストスイートが作成されます。この場合、 test_munit-test-suite は、以下に示すように、新しいテストスイートの名前です-

フロー実行

上記のメッセージフローのXMLエディターは次のとおりです-

XMLエディター

これで、Muleパレットからドラッグして MUnit メッセージプロセッサをテストスイートに追加できます。

検証アサート

ウィザードを使用してテストを作成する場合は、[ファイル]→[新規]→[MUnit]を実行すると、次のMUnitテストスイートが表示されます-

MUnitテストスイート

テストの構成

Mule 4には、2つの新しいセクション、つまり MUnit と MUnit Tools があり、すべてのMUnitメッセージプロセッサがまとめられています。 MUnitテスト領域で任意のメッセージプロセッサをドラッグできます。以下のスクリーンショットに示されています-

テストの設定

今、あなたがスーツの構成を編集したり、Anypoint Studioでテストしたい場合は、以下の手順に従う必要があります-

ステップ1

*Package Explorer* に移動し、スイートまたはテストの* .xmlファイル*を右クリックします。 次に、*プロパティ*を選択します。

ステップ2

次に、[プロパティ]ウィンドウで[実行/デバッグ設定 s]をクリックする必要があります。この後、[新規]をクリックします。

ステップ3 *

最後のステップで、「構成タイプの選択」ウィンドウの下にある「MUnit」をクリックし、「OK」をクリックします。

起動設定の編集

テストを実行する

テストだけでなくテストスイートも実行できます。最初に、テストスイートの実行方法を確認します。

テストスイートの実行

テストスイートを実行するには、テストスイートが存在するMule Canvasの空の部分を右クリックします。ドロップダウンメニューが開きます。次に、以下に示すように、* MUnitスイートを実行*をクリックします-

テストスイートの実行

後で、コンソールで出力を確認できます。

テストを実行する

特定のテストを実行するには、特定のテストを選択して右クリックする必要があります。テストスイートの実行中に取得したのと同じドロップダウンメニューが表示されます。次に、以下に示すように、* MUnitテストの実行*オプションをクリックします-

テストの実行

その後、出力がコンソールに表示されます。

テスト結果の表示と分析

Anypoint Studioは、左側のエクスプローラーペインの[MUnit]タブにMUnitテスト結果を表示します。以下に示すように、緑色で成功したテストと赤色で失敗したテストを見つけることができます-

レポート生成

カバレッジレポートを表示して、テスト結果を分析できます。カバレッジレポートの主な機能は、MUnitテストのセットによってMuleアプリケーションがどれだけ正常に実行されたかに関するメトリックを提供することです。 MUnitカバレッジは基本的に、実行されるMUnitメッセージプロセッサの量に基づいています。 MUnitカバレッジレポートは、次のメトリックを提供します-

アプリケーション全体のカバレッジ
リソースカバレッジ
フローカバレッジ

カバレッジレポートを取得するには、以下に示すように、[MUnit]タブの[レポートの生成]をクリックする必要があります-

テスト結果の分析

テストのデバッグ

テストだけでなくテストスイートもデバッグできます。最初に、テストスイートをデバッグする方法を見ていきます。

テストスイートのデバッグ

テストスイートをデバッグするには、テストスイートが存在するMule Canvasの空の部分を右クリックします。ドロップダウンメニューが開きます。今、下の画像に示すように*デバッグMUnitスイート*をクリックしてください-

テストのデバッグ

その後、コンソールで出力を確認できます。

テストのデバッグ

特定のテストをデバッグするには、特定のテストを選択して右クリックする必要があります。テストスイートのデバッグ中に取得したのと同じドロップダウンメニューが表示されます。ここで、* MUnitテストのデバッグ*オプションをクリックします。以下のスクリーンショットに示されています。

テストのデバッグ

Mulesoft-quick-guide

MuleSoft-Mule ESBの紹介

ESBの実装

ESBの指導原則

ESBの必要性

P2P統合と ESB統合

ESB Muleとは何ですか？

ESB Mule ESBの機能と機能

MuleSoft-Muleプロジェクト

歴史

SourceForgeプロジェクト

バージョン1.0

バージョン2.0（Spring 2の採用）

Mavenを使用した構築

MuleSource

ESB Mule ESBのライバル

Muleのコアコンセプト

建築

サービスコンポーネントの開発

サービスオーケストレーション

統合

ビルディングブロック

春豆

エージェント

コネクタ

グローバル構成

グローバルエンドポイント

グローバルメッセージプロセッサ

モデル

Flow

ラバのメッセージ構造

ヘッダ

ペイロード

変数

添付ファイルと追加のペイロード

MuleSoft-私たちの機械の中のラバ

前提条件

Java開発キット（JDK）

オペレーティング・システム

データベース

システム要求

ラバをダウンロード

ESB Muleのインストールと実行

Windows環境

Unix/Linux環境

Windows環境

Unix/Linux環境

ESB Muleサービスを開始

WindowsサービスとしてのMule

Linux/UnixデーモンとしてのMule

ESB Muleアプリをデプロイする

ESB Muleサービス

MuleSoft-Anypoint Studio

前提条件

Anypoint Studioのダウンロードとインストール

Windowsの場合

OS Xで

Linuxの場合

Anypoint Studioの機能

MuleSoft-Anypoint Studioの発見

[メッセージフロー]タブ

グローバル要素タブ

[構成XML]タブ

ビュー

パッケージエクスプローラー

ミュールパレット

ラバのプロパティ

コンソール

問題ビュー

展望

MuleSoft-最初のMuleアプリケーションの作成

Anypoint Studioの起動

Anypoint Studioのユーザーインターフェイス

ESB Muleアプリケーションの作成手順

新しいプロジェクトの作成

プロジェクトの命名

コネクタの構成

Set Payload Connectorの構成

ESB Muleアプリケーション

ESB Muleアプリケーションの検証