---
schema_version: "1"
id: 4b263eeeeaf1ad3720021b4927d7c2b2c1f0518a5a85135a8030ec01158c111d
title: VM トランスポートの移行
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.8/migration-module-vm.md
canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-module-vm
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 362a95f8ae5c779729512d934aa40161acaeeb625890b5a602b0ceb1ee84723d
description: MuleSoft Documentation Site
release: "4.8"
latest: false
---
# VM トランスポートの移行

VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。

- ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。
- 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。

## [](#whats_covered_here)このトピックの内容

- [VM トランスポート設定の移行](#file_configs)
- [インバウンドエンドポイントの移行](#vm_listener)
- [アウトバウンドエンドポイントの移行](#vm_outbound)

## [](#file_configs)VM トランスポート設定の移行

Mule 3 では、トランスポート設定はすべて ​`<vm:connector />`​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。

Mule 3 の例: 永続的 VM トランスポートの定義

```xml
<vm:connector name="persistentVmConnector" queueTimeout="1000">
    <vm:queue-profile>
        <default-persistent-queue-store/>
    </vm:queue-profile>
</vm:connector>
```

Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。

Mule 4 の例: VM Connector 設定の定義

```xml
<vm:config name="vm">
    <vm:queues>
        <vm:queue queueName="transientQueue" queueType="TRANSIENT" />
        <vm:queue queueName="persistentQueue" queueType="PERSISTENT" />
    </vm:queues>
</vm:config>
```

## [](#vm_listener)インバウンドエンドポイントの移行

Mule 3 では、​`<vm:inbound-endpoint>`​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。

Mule 3 の例: VM インバウンドエンドポイント

```xml
<flow name="persistentVM">
    <vm:inbound-endpoint path="persistentQueue" exchange-pattern="request-response">
        <vm:transaction action="ALWAYS_BEGIN"/>
    </vm:inbound-endpoint>

    ...
</flow>
```

この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。

Mule 4 では代わりに ​`<vm:listener>`​ イベントソースが使用されます。

Mule 4 の例: VM リスナー

```xml
<flow name="persistentVM">
    <vm:listener queueName="persistentQueue" transactionalAction="ALWAYS_BEGIN" config-ref="vm">
        <vm:response>
            <vm:content>
                #[lower(payload.salute)]
            </vm:content>
        </vm:response>
    </vm:listener>

    ...
</flow>
```

主な違いは次のとおりです。

- リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。
- `<vm:response>`​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。
- 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​`<vm:publish>`​ または ​`<vm:publish-response>`​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。

### [](#メッセージの順次リスン)メッセージの順次リスン

インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。

Mule 3 の例: メッセージの順次リスン

```xml
    <vm:connector name="vmConnector" numberOfConcurrentTransactedReceivers="1"/>
```

Mule 4 では、これをリスナーレベルで行うことができます。

Mule 4 の例: メッセージの順次リスン

```xml
<flow name="synchronousQueue" maxConcurrency="1">
    <vm:listener queueName="synchronousQueue" numberOfConsumers="1" config-ref="vm" transactionalAction="ALWAYS_BEGIN"/>
    ...
</flow>
```

フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。

## [](#vm_outbound)アウトバウンドエンドポイントの移行

Mule 3 トランスポートでは、​`<vm:outbound-endpoint>`​ コンポーネントを使用してメッセージをキューにパブリッシュします。

Mule 3 の例: キューへのメッセージの投稿

```xml
<vm:outbound-endpoint path="sendAsync" exchange-pattern="one-way"/>
<vm:outbound-endpoint path="sendAndWait" exchange-pattern="request-response"/>
```

`exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​`<vm:inbound-endpoint>`​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。

Mule 4 ではこれを 2 つの異なる操作を使用して行います。

Mule 4 の例: キューへのメッセージの投稿

```xml
<vm:publish queueName="sendAsync" config-ref="vm">
    <vm:content>#[upper(payload)]</vm:content>
</vm:publish>

<vm:publish-consume queueName="sendAndWait" config-ref="vm">
    <vm:content>#[upper(payload)]</vm:content>
</vm:publish-consume>
```

両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​`<vm:publish>`​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​`<vm:publish-consume>`​ 操作は参照するキューの ​`<vm:listener>`​ から応答が生成されるのを待機します。

VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。

```xml
<dependency>
    <groupId>org.mule.connectors</groupId>
    <artifactId>mule-vm-connector</artifactId>
    <version>1.1.0</version> <!-- or newer -->
    <classifier>mule-plugin</classifier>
</dependency>
```

## [](#関連情報)関連情報

- [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/)