---
schema_version: "1"
id: d9aeecd4d93db2c62fcee2c668029a54d83c9d775fd3db095b1c11e0d24d90f7
title: 信頼性パターン
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.5/reliability-patterns.md
canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.5/reliability-patterns
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 5b731facb4a8afc27211377e5e92b3df346b04ffc1afef69ce0abf0749ba50aa
description: MuleSoft Documentation Site
release: "4.5"
latest: false
---
# 信頼性パターン

信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。

![Reliability\_Pattern](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/reliability-pattern.png)

信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。

- HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。
- ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。

アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。

## [](#信頼性の高いメッセージング)信頼性の高いメッセージング

高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。

アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。

トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。

XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management)​を参照してください。

HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。

## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較

信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。

![ReliabilityPatternwithJMS](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/reliabilitypatternwithjms.png)

次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。

<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 10%;">
<col style="width: 60%;">
<col style="width: 30%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">エンドポイント</th>
<th class="tableblock halign-left valign-top">メリット</th>
<th class="tableblock halign-left valign-top">デメリット</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>ファイルベースの VM (スタンドアロン Mule)</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>Mule ですぐに使用できます。追加のソフトウェアが必要ありません。</p>
</li>
</ul>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>非クラスター環境にのみ適用されます。</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>JDBC</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>使用できるリソースに応じて、JDBC が大量の情報を保持できます。</p>
</li>
</ul>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>追加のソフトウェア (データベースサーバー) が必要です。</p>
</li>
<li>
<p>適切な DBMS スキーマが必要なため、複雑になる場合があります。</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>JMS (永続性に有効)</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>クラスター環境と非クラスター環境の両方に適用されます。</p>
</li>
</ul>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p>追加のソフトウェア (メッセージキューサーバー) が必要です。</p>
</li>
</ul>
</div></div></td>
</tr>
</tbody>
</table>

<table><tbody><tr><td class="icon"><i class="fa icon-note" title="Note"></i></td><td class="content">この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。</td></tr></tbody></table>

## [](#信頼性パターンの実装)信頼性パターンの実装

次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。

### [](#例-http-から-vm)例: HTTP から VM

```xml
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" >
	<http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>
<vm:config name="VM_Config" doc:name="VM Config" >
	<vm:queues >
		<vm:queue queueName="toTransactionalVM" queueType="PERSISTENT"/>
	</vm:queues>
</vm:config>
<flow name="reliable-data-acquisition">
<http:listener config-ref="HTTP_Listener_config" path="transactionalEndpoint"/>
<vm:publish config-ref="VM_Config" queueName="toTransactionalVM" sendCorrelationId="ALWAYS"/> (1)
</flow>

<!-- This is the application logic flow in the reliability pattern.
	It is a wrapper around the sub-flow "business-logic-processing". -->
<flow name="main-flow">
	<vm:listener doc:name="Listener" config-ref="VM_Config" queueName="toTransactionalVM"
		transactionalAction="ALWAYS_BEGIN"/> (2)
	<flow-ref name="business-logic-processing"/>
</flow>

<!-- In this sub-flow, the application starts processing the message. -->
<sub-flow name="business-logic-processing">
	<logger level="INFO" doc:name="Logger" />
	<!--
		This is where the actual business-logic is performed.
	-->
</sub-flow>
```

<table><tbody><tr><td><i class="conum" data-value="1"></i><b>1</b></td><td>メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。</td></tr><tr><td><i class="conum" data-value="2"></i><b>2</b></td><td>メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。</td></tr></tbody></table>

Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。

<table><tbody><tr><td class="icon"><i class="fa icon-note" title="Note"></i></td><td class="content">この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。</td></tr></tbody></table>

## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装

「​[\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​」で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。

この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。

`auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。

### [](#例-ftp-から-vm)例: FTP から VM

次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。

```xml
<ftp:config name="FTP_Config">
	<ftp:connection host="localhost" username="max" password="mulesoft"/>
</ftp:config>

<flow name="reliable-data-acquisition">
	<ftp:listener config-ref="FTP_Config" watermarkEnabled="true" directory="someDirectory/in"> (1)
		<scheduling-strategy >
			<fixed-frequency />
		</scheduling-strategy>
	</ftp:listener>
	<vm:publish config-ref="VM_Config" queueName="toTransactionalVM"/>
</flow>

<flow name="doc-examplesFlow">
	<vm:listener queueName="toTransactionalVM" config-ref="VM_Config" transactionalAction="ALWAYS_BEGIN"/>
	<set-variable value="#[attributes.filename]" variableName="filepath"/>
	<!-- File content is already present in payload -->
	<flow-ref name="business-logic-processing"/>
	<ftp:delete path="#[vars.filepath]"/> (2)
</flow>
```

<table><tbody><tr><td><i class="conum" data-value="1"></i><b>1</b></td><td>VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。</td></tr><tr><td><i class="conum" data-value="2"></i><b>2</b></td><td>ファイルを削除したくない場合は、​<code>ftp:delete</code>​ 操作を使用しないでください。目的の操作が ​<code>ftp:move</code>​ の場合にも同じことが言えます。</td></tr></tbody></table>

他のリソースベースのコネクタについても同じような実装が行われます。

## [](#一般的な考慮事項)一般的な考慮事項

信頼性パターンを実装するときには、次の点に注意してください。

- コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。
- 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。
- JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。
- 信頼性はパフォーマンスに影響を及ぼします。
- 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。