バッチモジュールの移行
|
このバージョンの Mule は、拡張サポートが終了する 2023 年 5 月 2 日にその すべてのサポートが終了しました。 このバージョンの Mule を使用する CloudHub には新しいアプリケーションをデプロイできなくなります。許可されるのはアプリケーションへのインプレース更新のみになります。 標準サポートが適用されている最新バージョンの Mule 4 にアップグレードすることをお勧めします。これにより、最新の修正とセキュリティ機能強化を備えたアプリケーションが実行されます。 |
バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。
このセクションの内容
バッチ要素の移行
Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、<batch:job> 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。
これは <batch:input> は使用されなくなることを意味します。<batch:input> の役割は、<batch:job> がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。
-
<batch:job>: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの <batch:job> 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 -
<batch:execute>: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。
<batch:job name="batchJob">
<<batch:input>>
<poll frequency="10000">
<sfdc:query ..../>
</poll>
</<batch:input>>
<batch:process-records>
<batch:step name="batchStep1">
<mp />
<mp />
</batch:step>
<batch:step name="batchStep1">
<event processor/>
<event processor/>
</batch:step>
<batch:process-records>
</batch:job><flow name="flowOne">
<scheduler>
<scheduling-strategy>
<fixed-frequency frequency="10000"/>
</scheduling-strategy>
</scheduler>
<batch:job jobName="batchJob">
<batch:process-records>
<batch:step name="batchStep1">
<event processor/>
<event processor/>
</batch:step>
<batch:step name="batchStep1">
<mp />
<mp />
</batch:step>
</batch:process-records>
</batch:job>
</flow>Record Vars から Vars への移行
通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。
Mule 3 では、Mule メッセージにフロー変数 (flowVars) を使用するのと同様に、レコードレベル変数 (recordVars) を使用して変数を特定のレコードに添付します。
Mule 4 では recordVars が変数 (vars) に置き換わります。. 変数は Mule 4 の Mule イベントの一部です。<batch:step> 内から、<batch:job> の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。
次の Mule 3 の例では、For Each コンポーネントの式内で recordVars が使用されています。
<batch:step name="commitStep">
<batch:commit size="10">
<foreach>
<expression-component>
record.payload = 'foo';
record.recordVars['marco'] = 'polo';
</expression-component>
</foreach>
</batch:commit>
</batch:step>次の Mule 4 の例では、For Each コンポーネントの式内で vars が使用されています。
<batch:job jobName="batchJob">
<batch:process-records>
<batch:step name="batchStep">
<batch:aggregator doc:name="batchAggregator" size="10">
<foreach doc:name="For Each">
<script:execute engine="groovy">
<script:code>
vars['marco'] = 'polo'
vars['record'].payload = 'foo'
</script:code>
</script:execute>
</foreach>
</batch:aggregator>
</batch:step>
</batch:process-records>
</batch:job>非 Java データセットのサポート
Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。
たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。
[
{
"name": "Luke Skywalker",
"darkSide": true
},
{
"name": "Ben Solo",
"darkSide": true
},
{
"name": "Obi-Wan Kenobi",
"darkSide": false
}
]
Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。
<batch:job name="forceJob">
<<batch:input>>
<http:listener path="/forceWielders" config-ref="forceListener" />
<ee:transform>
<ee:message>
<ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload
}]]></ee:set-payload>
</ee:message>
</ee:transform>
<<batch:input>>
.....
</batch:job>Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。
<flow name="useTheForceBatch">
<http:listener path="/forceWielders" config-ref="forceListener" />
<batch:job jobName="forceJob">
....
</batch:job>
</flow>Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。
Mule 4 のバッチ要素および属性の XML 変更
-
キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、
max-failed-records は maxFailedRecords、accept-policy は acceptPolicy のようになります。 -
MuleSoft では、
<batch:step>` 要素から filter-expression パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、accept-expression パラメーターにに置き換える必要があります。 -
<batch:commit> は <batch:aggregator> と呼ばれるようになりました。