# mulesoft VM Connector - Full Documentation --- product: VM Connector version: 2.0 is-latest-version: true --- # Aggregate Messages Pending in Queue with VM Connector Examples > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following examples show two scenarios on how to aggregate messages pending in a queue using Anypoint Connector for Virtual Machine (VM Connector). Note that VM is a queue and you cannot perform a for each operation over every message pending on a queue. ## First Example of Aggregating Messages in a Queue In this example, you use the Aggregators module to aggregate the received messages by the VM **Listener** operation and then iterate over the result of the aggregation. ![Aggregate Messages Pending in Queue first flow in Anypoint Studio canvas](/mulesoft/current/en-us/vm-connector/latest/_images/vm-aggregate-flow-1.png) ### Create the First Flow In the first flow, an HTTP **Listener** source listens for incoming HTTP messages. Then a VM **Publish** operation publishes specific content in a VM queue: 1. In Studio, create a new Mule project. 2. In **Mule Palette**, select the **HTTP > Listener** source and drag it on to the canvas. 3. On the HTTP **Listener** configuration screen, set the **Path** field to `/`. 4. Click the plus sign (+) next to the **Connector configuration** field to configure a global element that can be used by all instances of the HTTP **Listener** in the app. 5. Complete the required fields for the HTTP global configuration. 6. Click **OK**. 7. Drag a **For Each** component to the right of the HTTP **Listener** source. 8. Set **Collection** to `1 to 200`. 9. Drag a **VM > Publish** operation into the **For Each** component. 10. Set **Content** to `"hello world"`. 11. Click the plus sign (+) next to the **Connector configuration** field to configure a global element that can be used by all instances of the VM **Publish** operation in the app. 12. In the **VM Config** window, click the plus sign (+) to add a new queue. 13. Set **Queue name** to `demo`. 14. Click **Finish**. 15. Click **OK**. ### Create the Second Flow In the second flow, a VM **Listener** operation listens to the messages published in the VM queue. The **Time based aggregator** scope aggregates the received messages until the time condition is reached. 1. In Studio, drag a **VM > Listener** operation below the first flow. 2. For **Connector configuration**, select the previously created `VM_Config` configuration. 3. Set **Queue name** to `demo`. 4. Drag a **Time based aggregator** scope to the right of the **VM Listener**. 5. Set **Name** to `demoaggregator`. 6. Set **Period** to `5` to aggregate the received messages until 5 seconds is reached. ### Create the Third Flow In this flow, an **Aggregator listener** operation listens to the messages aggregated by the **Time based aggregator** scope. The **For Each** component iterates over the messages and a **Logger** component logs the content of each message. 1. In Studio, drag an **Aggregator listener** source above the second flow. 2. Set **Aggregator name** to `demoaggregator`. 3. Drag a **For Each** component to the right of the **Aggregator listener** source. 4. Set **Collection** to `[#payload]`. 5. Drag a **Logger** component into the **For Each** component. 6. Set **Message** to `[#payload]`. 7. Save and run your Mule app. 8. In your terminal, run the curl command `curl [http://localhost:8081/](http://localhost:8081/)`. ### XML for the First Example of Aggregating Messages in a Queue Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule app: ```xml ``` ## Second Example of Aggregating Messages in a Queue In this example, a **For Each** component iterates over messages that were consumed by the VM **Consume** operation. The Mule app appends every received message into a variable, and logs the payload content for each message. Note that in this example scenario you get slices of messages until no messages are available on the queue. When this occurs, the VM **Consume** operation throws a timeout message handled by the **On Error Continue** component and then the results are available for iteration. ![Aggregate Messages Pending in Queue second flow in Anypoint Studio canvas](/mulesoft/current/en-us/vm-connector/latest/_images/vm-aggregate-flow-2.png) ### Create the First Flow In the first flow, an **HTTP Listener** source listens for incoming HTTP messages, and the VM **Publish** operation publishes specific content in a VM queue: 1. In Studio, create a new Mule project. 2. In **Mule Palette**, select the **HTTP > Listener** source and drag it on to the canvas. 3. On the HTTP **Listener** configuration screen, set the **Path** field to `/`. 4. Click the plus sign (+) next to the **Connector configuration** field to configure a global element that can be used by all instances of the HTTP **Listener** in the app. 5. Complete the required fields for the HTTP global configuration. 6. Click **OK**. 7. Drag a **For Each** component to the right of the HTTP **Listener** source. 8. Set **Collection** to `1 to 55`. 9. Drag a **VM > Publish** operation into the **For Each** component. 10. Set **Content** to `"test world"`. 11. Click the plus sign (+) next to the **Connector configuration** field to configure a global element that can be used by all instances of the VM **Publish** operation in the app. 12. In the **VM Config** window, click the plus sign (+) to add a new queue. 13. Set **Queue name** to `demo`. 14. Click **Finish**. 15. Click **OK**. ### Create the Second Flow In the second flow, a VM **Consume** operation pulls the published messages from the queue. The **Transform Message** component transforms the payload content and save it in a variable. The Mule app logs each variable payload. 1. In Studio, drag a **Scheduler** source below the first flow. 2. Set **Frequency** to `5000`. 3. Drag a **Set Variable** component to the right of the **Scheduler** component. 4. Set **Name** to `result`. 5. Set **Value** to `[]`. 6. Drag a **Try** scope component to the right of **Set Variable**. 7. Drag a **For Each** component into the **Try** scope. 8. Set **Collection** to `1 to 10000`. 9. Drag a VM **Consume** operation into the **For Each** component. 10. For **Connector configuration**, select the previously created `VM_Config` configuration. 11. Set **Queue name** to `demo`. 12. Drag a **Transform Message** component to the right of **Consume**. 13. Set the DataWeave script to: %dw 2.0 output application/java --- vars.result << payload 14. Drag an **On Error Continue** component into the **Error handling** section of the **Try** scope component. 15. Set **Type** to `VM:EMPTY_QUEUE`. 16. Drag a **Set Payload** component to the right of the **Try** scope component. 17. Set **Value** to `vars.result`. 18. Drag a **For Each** component to the right of the **Set Payload** component. 19. Set **Collection** to `payload`. 20. Drag a **Logger** component into the **For each** scope component. 21. Set **Message** to `payload`. 22. Save and run your Mule app. 23. In your terminal, run the curl command `curl [http://localhost:8081/](http://localhost:8081/)`. ### XML for the Second Example of Aggregating Messages in a Queue Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule app: ```xml ``` ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # Troubleshooting VM Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To troubleshoot Anypoint Connector for Virtual Machine (VM Connector), become familiar with the information about enabling verbose logging and interpreting commonly thrown messages. ## Enable Verbose Logging To get a better understanding of why an application’s interaction with VM Connector is failing, temporarily enable verbose logging for VM Connector. Remember to always disable the enhanced verbosity after troubleshooting, because it affects your Mule application performance. To enable verbose logging in the configuration file: 1. Access Anypoint Studio and navigate to the **Package Explorer** view. 2. Open your application’s project name. 3. Open the `src/main/resources` path folder. 4. Open the `log4j2.xml` file inside the folder. 5. Add an `` tag inside the `` tag: ```xml ... ... ``` 6. Save your application changes. 7. Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule Application**. ## Understand Common Throws Here is a list of common throw messages and how to interpret them: - VM:EMPTY\_QUEUE The referenced queue is empty. - VM:RETRY\_EXHAUSTED The maximum number of retries for the operation is reached. - VM:CONNECTIVITY The connection is no longer valid. Apply a reconnection policy if defined in the application setup. - VM:QUEUE\_TIMEOUT Timeout exceeded waiting for response on a queue. - VM:PUBLISH\_CONSUMER\_FLOW\_ERROR The \*Publish consume\* operation failed to process the published message. ## See Also - [VM Connector Reference](https://docs.mulesoft.com/vm-connector/latest/vm-reference) - [Salesforce Help](https://help.salesforce.com) - [Known Issues](https://help.salesforce.com/s/issues) --- product: VM Connector version: 2.0 is-latest-version: true --- # Using Anypoint Studio to Configure VM Connector 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Studio (Studio) editors help you design and update your Mule applications, properties, and configuration files. To add and configure a connector in Studio: 1. [Create a Mule project](#create-mule-project). 2. [Add the connector to your Mule project](#add-connector-to-project). 3. [Configure a source for the connector’s flow](#configure-input-source). 4. [Add a connector operation to the flow](#add-connector-operation). 5. [Configure a global element for the connector](#configure-global-element). When you run the connector, you can view the app log to check for problems, as described in [View the App Log](#view-app-log). If you are new to configuring connectors in Studio, see [Using Anypoint Studio to Configure a Connector](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio). If, after reading this topic, you need additional information about the connector fields, see [VM Connector Reference](https://docs.mulesoft.com/vm-connector/latest/vm-reference). ## Create a Mule Project In Studio, create a new Mule project in which to add and configure the connector: 1. In Studio, select **File > New > Mule Project**. 2. Enter a name for your Mule project and click **Finish**. ## Add the Connector to Your Mule Project Add VM Connector to your Mule project to automatically populate the XML code with the connector’s namespace and schema location and to add the required dependencies to the project’s `pom.xml` file: 1. In the **Mule Palette** view, click **(X) Search in Exchange**. 2. In the **Add Dependencies to Project** window, type `vm connector` in the search field. 3. Click **VM Connector** in **Available modules**. 4. Click **Add**. 5. Click **Finish**. Adding a connector to a Mule project in Studio does not make that connector available to other projects in your Studio workspace. ## Configure a Source A source initiates a flow when a specified condition is met. You can configure one of these input sources to use with VM Connector: - **VM Listener**, which initiates a flow by listening on a VM queue - **HTTP Listener**, which initiates a flow each time it receives a request on the configured host and port - **Scheduler**, which initiates a flow when a time-based condition is met For example, to configure a **VM Listener** source, follow these steps: 1. In the **Mule Palette** view, select **VM > Listener**. 2. Drag **Listener** to the Studio canvas. 3. On the **Listener** configuration screen, optionally change the value of the **Display Name** field. 4. Click the plus sign (+) next to the **Connector configuration** field to configure a VM queue that can be used by all instances of the **Listener** source and other VM Connector operations in the app. 5. [Define the VM queue](#configure-global-element). 6. On the **Listener** configuration screen, set the **Number of consumers** field to your desired value (default is `4`). 7. In the **Queue** section, select a **Queue name** from the drop-down menu. If you previously created a VM queue, the **Queue name** value appears automatically. 8. Specify a value for the **Timeout** (default is `5`). 9. Select a **Timeout unit** from the drop-down menu. ## Add a Connector Operation to the Flow When you add a connector operation to your flow, you immediately define a specific operation for that connector to perform. To add an operation for VM Connector, follow these steps: 1. In the **Mule Palette** view, select **VM Connector** and then select the desired operation. 2. Drag the operation onto the Studio canvas and to the right of the input source. ## Configure a Global Element for the Connector When you configure a connector, it’s best to configure a global element that all instances of that connector in the app can use. A VM Connector global configuration defines the queues on which the connector operates. You can define any number of configurations, each with its own set of queues. Each queue defined within a given VM Connector configuration can be used only by operations referencing that specific configuration. A queue name cannot be repeated across configurations, and two queues with the same name can not exist in the same app or domain. To configure the global element for VM Connector, follow these steps: 1. Select the name of the connector in the Studio canvas. 2. In the configuration screen for the operation, click the plus sign (+) next to the **Connector configuration** field to access the global element configuration fields. 3. In the **General** section, in the **Queues** drop-down menu select either: - `Bean reference` In the **Bean reference** field, add your desired reference value. - `Edit inline` In the **Queues** field, click the plus sign (+) to add a new queue. Then add a **Queue name** value, set **Queue type** to either `TRANSIENT (Default)` or `PERSISTENT`, add a value for **Max outstanding messages**; and click **Finish**. 4. In the **Connection** section, optionally configure a reconnection strategy. 5. On the **Advanced** tab, optionally configure an expiration policy. 6. Click **OK**. The following screenshot shows an example of configuring the VM Connector: ![VM Connector Configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-studio-config1.png) Figure 1. VM Connector Configuration The following screenshot shows an example of configuring the VM queue: ![VM Queue Configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-studio-config2.png) Figure 2. VM Queue Configuration In the XML editor, the VM Connector configuration looks like this: ```xml ``` ## View the App Log To check for problems, you can view the app log as follows: - If you’re running the app from Anypoint Platform, the output is visible in the Anypoint Studio console window. - If you’re running the app using Mule from the command line, the app log is visible in your OS console. Unless the log file path is customized in the app’s log file (`log4j2.xml`), you can also view the app log in the default location `MULE_HOME/logs/.log`. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Using Anypoint Studio to Configure a Connector](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio) - [VM Connector Reference](https://docs.mulesoft.com/vm-connector/latest/vm-reference) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Connector for Virtual Machine (VM Connector) manages intra-app and inter-app communication through either transient or persistent asynchronous queues: - Transient queues are faster than persistent queues, but they are not reliable if the system crashes. - Persistent queues are slower but reliable. When running a Mule application in single runtime instance mode, persistent queues work by serializing and storing the contents on the disk. However, when running the Mule application in cluster runtime instance mode, the persistent queues are backed up in the memory grid. Thereby, when a flow uses VM Connector to publish content to a queue, Mule runtime engine determines whether to process the message in the same origin node or to send the message to the cluster to pick another node. Using VM Connector facilitates the load distribution across a cluster. In either single or cluster runtime instance mode, when using persistent queues, the data you send must be serializable. Although you can enable Kryo serialization to get a wider range of serializable values, Kryo does have some limitations. Refer to the [considerations when using serialization](https://docs.mulesoft.com/mule-runtime/latest/configure-custom-serializers#considerations-when-using-serialization) documentation for details. When using persistent queues: - Keep your values simple because complex structures might result in serialization errors or performance issues if they are not easy to serialize. - Ensure complex Java objects implement the `Serializable` interface and that they conform to the JavaBean contract. - Use streams, JSON objects, maps, and so on only if the associated values comply with the previous recommendations. Note that persistent queues are unavailable in CloudHub 2.0 and Runtime Fabric. ## Before You Begin To use this connector, you must be familiar with: - Anypoint Connectors - Mule runtime engine (Mule) - Elements and global elements in a Mule flow - Creating a Mule app using Anypoint Studio or Anypoint Code Builder Before creating an app, you must have access to Anypoint Studio. ## Common Use Cases for the Connector Use VM Connector when you want to: - Pass messages from one flow to another through a queueing mechanism, instead of using a `` directly - Distribute work across a cluster - Communicate with different apps that are running in the same Mule domain - Perform simple queueing that does not justify the use of a full JMS broker For examples, see [Examples](https://docs.mulesoft.com/vm-connector/latest/vm-examples). ## Audience - New users, read: - [Using Anypoint Studio to Configure the Connector](https://docs.mulesoft.com/vm-connector/latest/vm-studio-configuration) to create your Mule app - [Examples](https://docs.mulesoft.com/vm-connector/latest/vm-examples), which provide one or more use cases for the connector - Advanced users, read: - [XML and Maven Support](https://docs.mulesoft.com/vm-connector/latest/vm-xml-maven) - [Examples](https://docs.mulesoft.com/vm-connector/latest/vm-examples), which provide one or more use cases for the connector ## Next Step After you complete the prerequisites and experiment with templates and examples, you are ready to create your own app and configure the connector using [Anypoint Studio](https://docs.mulesoft.com/vm-connector/latest/vm-studio-configuration). ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Dynamic Routing Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use expressions to have a generic flow that sends messages to different queues depending on certain conditions. For instance, you can make [the publish and listen example](https://docs.mulesoft.com/vm-connector/latest/vm-publish-listen) more interesting by also using an expression in the `queueName` attribute. Suppose that the JSON object that you get through the HTTP connector includes a destination object that maps directly to the name of the queue to which you need to write. You can do the following: ```xml #[payload.body] ``` --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Examples > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To fully benefit from using Anypoint Connector for Virtual Machine (VM Connector), see the following examples of configuring the connector operations: - [Dynamic Routing](https://docs.mulesoft.com/vm-connector/latest/vm-dynamic-routing) Configure the **Publish** operation to dynamically route messages to different queues depending on certain conditions. - [Propagate Message Attributes](https://docs.mulesoft.com/vm-connector/latest/vm-propagate-messages) Configure both the **Publish** operation and **Listener** source to propagate message attributes through a VM queue via the message payload. - [Send Messages across Different Apps](https://docs.mulesoft.com/vm-connector/latest/vm-publish-across-apps) Configure the **Publish**, **VM Listener**, and **Consume** operations to send messages across different apps. - [Publish and Listen to Messages](https://docs.mulesoft.com/vm-connector/latest/vm-publish-listen) Configure the **Publish** operation and **Listener** source to publish a message that is received by a different flow. - [Publish a Message and Get a Response](https://docs.mulesoft.com/vm-connector/latest/vm-publish-response) Configure the **Publish consume** operation to publish a message and get a response. - [Aggregate Messages Pending in Queue](https://docs.mulesoft.com/vm-connector/latest/vm-aggregate-messages) Configure the VM **Publish**, **Consume** and Aggregators module to aggregate messages pending in a queue. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Propagate Message Attributes Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following example illustrates how you can propagate message attributes through a VM queue via a message payload. The first flow takes incoming HTTP message attributes and additionally creates a custom attribute of its own, and then adds both of these attributes into a message payload so the **VM Publish** operation can publish the message to a VM queue. In the second flow, the **VM Listener** source receives the message payload from the previous flow and sets its own message attributes, and the message payload is finally stored in an object store. The following screenshot shows the Anypoint Studio app flow for this example: ![VM Connector example flow](/mulesoft/current/en-us/vm-connector/latest/_images/vm-example-messageflow.png) Figure 1. VM Connector Propagate message attributes flow ## Create the VM Publishing Flow The VM publishing flow first listens for incoming HTTP message attributes and then transforms the message attributes into a JSON structure message. Finally the **VM Publish** operation publishes the message in a VM queue. To create the VM publishing flow: 1. Create a new Mule project in Studio. 2. In the **Mule Palette** view, select the **HTTP Listener** source and drag it into the canvas. The source listens for incoming HTTP messages attributes. 3. On the **HTTP Listener** configuration screen, set the **Path** field to `/message`. 4. Click the plus sign (+) next to the **Connector configuration** field to configure a global element that can be used by all instances of the **HTTP Listener** in the app. 5. In the **Connection** section, set **Protocol** to `HTTP (Default)`, **Host** to `All Interfaces [0.0.0.0] (default)`, and **Port** to `8081`. 6. Set **Base path** to `/publish`. 7. Click **Test Connection** to confirm that Mule can connect with the specified server. 8. Click **OK**. 9. Drag the **Transform Message** component to the right of **HTTP Listener**. The component transforms the incoming HTTP message attributes into a JSON structure that contains the `listenerPath` and `method` attributes, as well as a new custom `sizeAttribute` attribute. 10. In the **Output Payload** script view of the **Transform Message** component, define the `listenerPath` and `method` attributes using the following DataWeave code: ```DataWeave %dw 2.0 output application/json --- { listenerPath: attributes.listenerPath, method: attributes.method } ``` 11. In the **Output Attributes** script view of the **Transform Message** component, define a new custom `sizeAttribute` attribute using the following DataWeave code: ```DataWeave %dw 2.0 output application/json --- { sizeAttribute: sizeOf(attributes.listenerPath) + sizeOf(attributes.method) } ``` 12. Drag the **VM Publish** operation to the right of the **Transform Message** component. The operation publishes the created JSON message in the VM queue. 13. On the **VM Publish** configuration screen, click the plus sign (+) next to the **Connector configuration** field to configure a global element for the VM queue. 14. On the **VM Config** window, for **Queues** select `Edit inline`. 15. On the **Queue** window, set **Queue name** to `testqueue1`, **Queue type** to `TRANSIENT (Default)`, and **Max outstanding message** to `o`. 16. Click **Finish**. 17. Click **OK**. In Studio, the **VM Config** global element configuration looks like this: ![VM Config global element configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-example-publish2.png) Figure 2. VM Config global element configuration 18. In the **General > Content** field of the **VM Publish** configuration screen, define the following DataWeave code: ```DataWeave %dw 2.0 output application/json --- {'listenerPath': payload.listenerPath, 'method': payload.method, 'messageSize': attributes.sizeAttribute } ``` In Studio, the **VM Publish** operation configuration looks like this: ![VM Publish operation configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-example-publish1.png) Figure 3. VM Publish operation configuration ## Create the VM Listening Flow The VM listening flow listens for incoming messages attributes in the VM queue from the previous VM Publish flow, then set its own attributes via the **VM Listener** source. Finally stores the message payload in an object store. To create the VM listening flow: 1. In the **Mule Palette** view, select the **VM Listener** source and drag it onto the canvas below the first VM Publish flow. The source listens for the incoming message attributes from the previous flow. 2. On the **VM Listener** configuration screen, click the plus sign (+) next to the **Connector configuration** field and select the VM queue configuration created in the VM Publish flow. In Studio, the **VM Listener** source configuration looks like this: ![VM Listener source configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-example-listener.png) Figure 4. VM Listener source configuration 3. Drag a **Logger** component to the right of the **VM Listener**. 4. On the **Logger** configuration screen, set the **Message** field to `payload`. 5. Drag another **Logger** component to the right of the first **Logger** component. 6. On the **Logger** configuration screen, set the **Message** field to `'VM message attributes: queue name ' ++ attributes.queueName as String`. 7. Drag an **ObjectStore Store** operation to the right of the second **Logger** component. The operation stores the received `'method':'listenerPath'` pair attributes in an object store. 8. On the **ObjectStore Store** configuration screen, set the **Display Name** field to `Add Http Request`. 9. In the **General** section, set **Key** to `payload.method` and **Value** to `payload.listenerPath`. 10. Click the plus sign (+) next to the **Object Store** field to set the global object store configuration. 11. Set the default values and click **OK**. 12. Save the project and run the app. 13. Test the app by sending a request to `http://127.0.0.1:8081/publish/message`. ## XML for Propagating Message Attributes Through the VM Queue Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule app: ```xml ``` ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Publish and Listen to Messages Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following example illustrates how to publish a message that is received by a different flow: - The first flow takes an incoming HTTP message payload, then the **VM Publish** operation publishes the message to a VM queue. - In the second flow, the **VM Listener** source receives the message payload from the previous flow via the same VM queue. - To do this, point both operations to the same queue which prevents message loss caused by sending messages to a queue with no active listener. The following screenshot shows the Anypoint Studio app flow for this example: ![VM Connector Publish and Listen to Messages flow](/mulesoft/current/en-us/vm-connector/latest/_images/vm-example-publishlisten.png) Figure 1. VM Connector Publish and Listen to Messages flow ## Create the VM Publishing Flow The VM publishing flow first listens for an incoming HTTP message payload, which contains the body attribute of a JSON object. Then, in a one-way **VM Publish** operation, the message is published in a VM queue, and the flow continues. To create the VM publishing flow: 1. Create a new Mule project in Studio. 2. In the **Mule Palette** view, select the **HTTP Listener** source and drag it on to the canvas. The source listens for incoming HTTP messages attributes. 3. On the **HTTP Listener** configuration screen, set the **Path** field to `/json-here`. 4. Click the plus sign (+) next to the **Connector configuration** field to configure a global element that can be used by all instances of the **HTTP Listener** in the app. 5. In the **Connection** section, enter the following values: - **Protocol** `HTTP (Default)` - **Host** `All Interfaces [0.0.0.0] (default)` - **Port** `8081` 6. Click **Test Connection** to confirm that Mule can connect with the specified server. 7. Click **OK**. 8. Drag the **VM Publish** operation to the right of the **HTTP Listener** source. The operation publishes the message payload in the VM queue. 9. In the **Content** field of the connector configuration, set the value to `payload.body`. This field enables you to use DataWeave to build the value to send. If you do not specify a parameter value, the entire payload is sent. 10. On the **VM Publish** configuration screen, click the plus sign (+) next to the **Connector configuration** field to configure a global element for the VM queue. 11. On the **VM Config** window, for **Queues**, select **Edit inline**. 12. On the **Queue** window, enter the following values: - **Queue name** `myQueue` - **Queue type** `TRANSIENT (Default)` - **Max outstanding message** `o` 13. Click **Finish**. 14. Click **OK**. The following screenshot shows the **VM Config** global element configuration: ![VM Config global element configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-publishlisten2.png) Figure 2. VM Config global element configuration The following screenshot shows the **VM Publish** operation screen configuration: ![VM Publish operation configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-publishlisten3.png) Figure 3. VM Publish operation configuration ## Create the VM Listening Flow The VM listening flow listens for the message payload in the VM queue from the previous VM Publish flow, and then logs the message. The flow contains a **VM Listener** as a message source and points to the same VM queue configured in the **VM Publish** operation. The processing on the listening side happens asynchronously. You do not receive notification of its outcome. To create the VM listening flow: 1. In the **Mule Palette** view, select the **VM Listener** source and drag it onto the canvas below the first VM publishing flow. The source listens for the message payload received from the previous flow. 2. On the **VM Listener** configuration screen, click the plus sign (+) next to the **Connector configuration** field and select the VM queue configuration created in the VM publishing flow. 3. Drag a **Logger** component to the right of the **VM Listener** source. 4. Save the project and run the app. 5. Test the app by sending a request to `http://127.0.0.1:8081/json-here`. The following screenshot shows the **VM Listener** source screen configuration: ![VM Listen source configuration](/mulesoft/current/en-us/vm-connector/latest/_images/vm-publishlisten4.png) Figure 4. VM Listen source configuration ## XML for Publishing and Listening to Messages Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule app: ```xml ``` ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Publish Messages and Get a Response Back Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In certain cases, you might want to get a response back. The `publish-consume` operation handles this by waiting for the message to be processed on the other end and providing the response. The operation is otherwise exactly the same as `publish`. Building on the [publish and listen example](https://docs.mulesoft.com/vm-connector/latest/vm-publish-listen), suppose you want to send the response back. You can modify the example like this: ```xml #[payload.body] ``` In the next example, notice that the `` source embeds a DataWeave expression that builds the response. Suppose that you want a response in a predefined JSON format, such as simple one with a `body` and `origin` value: ```xml ``` ## Error Handling If the receiving flow fails, this operation will raise a `VM:PUBLISH_CONSUMER_FLOW_ERROR` error. This error’s description will be that of the original error raised by the flow. Additionally, a `VM:QUEUE_TIMEOUT` might also be thrown if the receiving flow doesn’t respond in the expected timeframe. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt VM Connector v2.0 Anypoint Connector for Virtual Machine (VM) (VM Connector) provides intra-app and inter-app communication through transient or persistent asynchronous queues. Transient queues are faster, but not as reliable as persistent queues if the system crashes. Persistent queues, on the other hand, are slower but reliable. When running on a single instance, persistent queues work by serializing and storing the contents on to disk. When running in cluster mode, persistent queues are instead backed by the memory grid. This means that when a Mule flow uses VM Connector to publish content to a queue, Mule runtime engine (Mule) decides whether to process that message in the same origin node or to send it out to the cluster to be picked up and processed by another node. This is an easy way to distribute load across the cluster and ensure that transactions are always supported. Each configuration defines its own set of queues, which are visible only to components referencing that configuration. Release Notes: [VM Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/connector-vm) ## Configurations --- ### Default Configuration These are the parameters for the default configuration: #### Parameters
NameTypeDescriptionDefault ValueRequired

Name

String

The name for this configuration. Connectors reference the configuration with this name.

x

Connection

The connection types that can be provided to this configuration.

x

Queues

Array of Queue

The queues that this configuration owns.

x

#### Connection Types ##### Connection Returns instances of VMConnection. ###### Parameters
NameTypeDescriptionDefault ValueRequired

Reconnection

When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.

## Associated Operations - [Consume](#consume) - [Publish](#publish) - [Publish Consume](#publishConsume) ## Associated Sources - [Listener](#listener) ## Operations ### Consume `` This operation pulls a message from a queue. If a message is not immediately available, the Consume operation waits for up to the configured `queueTimeout` value, after which a `VM:QUEUE_TIMEOUT` error is thrown. The flow in which the content is consumed cannot contain a Listener (``) source. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN: The current operation joins to the current transactions. If a transaction doesn’t exist or is not compatible with the operation, the execution fails.

  • JOIN_IF_POSSIBLE: The current operation joins to available transactions. If there is no transaction to join, the current operation executes outside of existing transactions.

  • NOT_SUPPORTED: The current operation executes outside of existing transactions.

The type of joining action that operations can take regarding transactions.

JOIN_IF_POSSIBLE

Queue Name

String

The name of the queue.

x

Timeout

Number

How long to wait for the queue to complete an operation (either publishing or consuming) before failing with a timeout error. The default is 5 seconds.

5

Timeout Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit that qualifies the #timeoutUnit

SECONDS

Target Variable

String

The name of a variable in which the operation’s output is placed.

Target Value

String

An expression that evaluates against the operations’s output. The outcome of this expression is stored in the target variable.

#[payload]

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

#### For Configurations - [Default Configuration](#config) #### Throws - VM:EMPTY\_QUEUE - VM:RETRY\_EXHAUSTED - VM:CONNECTIVITY ### Publish `` This operation publishes the given content into the queue of the given queue name. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Content

Any

The content to be published.

#[payload]

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN: The current operation joins to the current transactions. If a transaction doesn’t exist or is not compatible with the operation, the execution fails.

  • JOIN_IF_POSSIBLE: The current operation joins to available transactions. If there is no transaction to join, the current operation executes outside of existing transactions.

  • NOT_SUPPORTED: The current operation executes outside of existing transactions.

The type of joining action that operations can take regarding transactions.

JOIN_IF_POSSIBLE

Queue Name

String

The name of the queue

x

Timeout

Number

How long to wait for the queue to complete an operation (either publishing or consuming) before failing with a timeout error. The default is 5 seconds.

5

Timeout Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit that qualifies the #timeoutUnit.

SECONDS

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### For Configurations - [Default Configuration](#config) #### Throws - VM:RETRY\_EXHAUSTED - VM:QUEUE\_TIMEOUT - VM:CONNECTIVITY ### Publish Consume `` This operation publishes the provided content into a queue, and then waits up to the time configured in `queueTimeout` for a response to be supplied on a temporal reply-To queue that this operation creates automatically. The temporal reply-To queue is automatically disposed of after a response is received or the timeout expires. The flow in which the content is published cannot contain a Listener (``) source. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Content

Any

The content to be published

#[payload]

Transactional Action

Enumeration, one of:

  • ALWAYS_JOIN: The current operation joins to the current transactions. If a transaction doesn’t exist or is not compatible with the operation, the execution fails.

  • JOIN_IF_POSSIBLE: The current operation joins to available transactions. If there is no transaction to join, the current operation executes outside of existing transactions.

  • NOT_SUPPORTED: The current operation executes outside of existing transactions.

The type of joining action that operations can take regarding transactions.

JOIN_IF_POSSIBLE

Queue Name

String

The name of the queue

x

Timeout

Number

How long to wait for the queue to complete an operation (either publishing or consuming) before failing with a timeout error. The default is 5 seconds.

5

Timeout Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit that qualifies the #timeoutUnit

SECONDS

Target Variable

String

The name of a variable in which the operation’s output is placed.

Target Value

String

An expression to evaluate against the operation’s output and the outcome of that expression is stored in the target variable.

#[payload]

Reconnection Strategy

A retry strategy in case of connectivity errors.

#### Output

Type

Any

Attributes Type

#### For Configurations - [Default Configuration](#config) #### Throws - VM:RETRY\_EXHAUSTED - VM:QUEUE\_TIMEOUT - VM:CONNECTIVITY ## Sources ### Listener `` A source that creates and listens on VM queues. VM queues are created by placing listeners on them, which is why this listener contains parameters for a queue’s behavior, such as whether or not it is persistent, the maximum capacity, and so on. #### Parameters
NameTypeDescriptionDefault ValueRequired

Configuration

String

The name of the configuration to use.

x

Number Of Consumers

Number

The number of concurrent consumers to place on the queue. As the number of consumers increases, so does the speed at which this source pushes messages into the owning flow. The default is 4 concurrent consumers.

4

Transactional Action

Enumeration, one of:

  • ALWAYS_BEGIN

  • NONE

The type of beginning action that sources can take regarding transactions.

NONE

Transaction Type

Enumeration, one of:

  • LOCAL

  • XA

The type of transaction to create. Availability depends on the Mule version.

LOCAL

Redelivery Policy

Defines a policy for processing the redelivery of a message.

Queue Name

String

The name of the queue.

x

Timeout

Number

How long to wait for the queue to complete an operation (either publishing or consuming) before failing with a timeout error. The default is 5 seconds.

5

Timeout Unit

Enumeration, one of:

  • NANOSECONDS

  • MICROSECONDS

  • MILLISECONDS

  • SECONDS

  • MINUTES

  • HOURS

  • DAYS

A TimeUnit that qualifies the #timeoutUnit

SECONDS

Reconnection Strategy

A retry strategy in case of connectivity errors.

Content

Any

#[payload]

#### Output

Type

Any

Attributes Type

#### For Configurations - [Default Configuration](#config) ## Types ### Reconnection
FieldTypeDescriptionDefault ValueRequired

Fails Deployment

Boolean

When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.

Reconnection Strategy

The reconnection strategy to use.

### Reconnect
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often in milliseconds to reconnect.

Count

Number

How many reconnection attempts to make.

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread.

true

### Reconnect Forever
FieldTypeDescriptionDefault ValueRequired

Frequency

Number

How often in milliseconds to reconnect.

blocking

Boolean

If false, the reconnection strategy runs in a separate, non-blocking thread.

true

### Queue
FieldTypeDescriptionDefault ValueRequired

Queue Name

String

The name of the queue

x

Queue Type

Enumeration, one of:

  • TRANSIENT

  • PERSISTENT

Specifies whether the queue is persistent or transient

TRANSIENT

Max Outstanding Messages

Number

Specifies the number of messages that can be queued before blocking starts. When the value is 0, blocking starts immediately.

0

### VM Message Attributes
FieldTypeDescriptionDefault ValueRequired

Queue Name

String

Name of the queue the content came from.

Timestamp

DateTime

Time that the content was retrieved.

### Redelivery Policy
FieldTypeDescriptionDefault ValueRequired

Max Redelivery Count

Number

The maximum number of times a message can be redelivered and processed unsuccessfully before triggering process-failed message.

Use Secure Hash

Boolean

Whether to use a secure hash algorithm to identify a redelivered message.

Message Digest Algorithm

String

The secure hashing algorithm to use. If not set, the default is SHA-256.

Id Expression

String

Defines one or more expressions to use to determine when a message has been redelivered. This property can be set only if useSecureHash is false.

Object Store

ObjectStore

The object store where the redelivery counter for each message is stored.

## See Also [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector Send Messages across Different Apps Example > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The following examples show two ways to send messages across different apps: - Use a Listener to receive the messages from the first app and a Publish operation to feed the received messages to a second app. - Use a Publish operation in a second app to push messages to the queue of messages, and a Consume operation to consume the messages. In both cases, the two apps must be in the same domain. ## Publish Messages to a Second App 1. Create a VM configuration in a domain, like this: ```xml ``` 2. Place a listener in an app in the same domain: ```xml ``` 3. Publish messages from a second app in the same domain: ```xml ``` In this example, the Listener and Publish operation point to the same queue (`sharedQueue`) and the same configuration (`sharedVMConfig`). ## Pull Published Messages from a Queue Instead of using the `` message source, you can consume messages in a VM queue through the `` operation. This operation can consume messages on demand, allowing you to: - Dynamically consume from different queues depending on a certain condition. - Have a tighter control on the rhythm at which the app consumes messages. To consume published messages from a queue: 1. Create a VM configuration in a domain, like this: ```xml ``` 2. Publish messages from a second app in the same domain: ```xml ``` 3. Pull messages from the queue after they are published. ```xml ``` In this example, the Publish and Consume operations point to the same queue (`sharedQueue`) and the same configuration (`sharedVMConfig`). ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com) --- product: VM Connector version: 2.0 is-latest-version: true --- # VM Connector XML and Maven Support > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Although you can manually code a Mule app in XML, it is more efficient to use Anypoint Studio. If you manually code a Mule runtime engine (Mule) app in XML, either from the Anypoint Studio XML editor or from a text editor, you can get access to the connector in your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file. When you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location. It also adds a dependency to the `pom.xml` file. ## Add a Namespace for the Connector Paste the following code inside the `` tag of the header of your configuration XML: ```xml http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd ``` This example shows how the namespace statements are placed in the `` XML block: ```xml ``` ## Add a POM File Dependency The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app. If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to this connector: ```xml org.mule.connectors mule-vm-connector x.x.x mule-plugin ``` Replace `x.x.x` with the version that corresponds to the connector you are using. To obtain the most up-to-date `pom.xml` file information: 1. Go to [Anypoint Exchange](https://www.mulesoft.com/exchange/). 2. In Exchange, click **Login** and supply your Anypoint Platform username and password. 3. In Exchange, search for `vm connector`. 4. Select the connector. 5. Click **Dependency Snippets** near the upper right of the screen. ## See Also - [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors) - [Salesforce Help](https://help.salesforce.com)