BassemE/mulesoft-documentation-embeddings huggingface dataset:
Migrating the Enricher to a Target Variable | MuleSoft Documentation
# Migrating the Enricher to a Target Variable
The Message Enricher and its functionality in Mule 3 is replaced by the `target` parameter in Mule 4. The Enricher provided a way to execute a group of message processors and redirect their output to a variable without side effects to the current message. In Mule 4, all non-void operations (for example, `<flow-ref>`, `<http:request>`, `<db:select>`, and so on) include `target` and `targetValue` parameters, which allow redirecting each operation’s output into a variable (such as `myVar`). Other components in a Mule flow can then access that data through a DataWeave selector (for example, `vars.myVar`).
## Example
Consider a message coming from an HTTP request, which we want to redirect to a third system, only that adding a `state` query param which is to be extracted using a secondary flow called `stateLookup`. Because you don’t want to lose the original payload or headers, you need to extract this value without affecting the original message. The Enricher calls out to the enrichment resource with the current message (containing the zip code), then enriches the current message with the result.
Mule 3 example
```
<flow name="orderProcessingFlow">
  <http:listener .../>
  <enricher target="#[variable:state]">
    <flow-ref name="stateLookup"/>
  </enricher>
 <http:request config-ref="config" path="state" method="POST">
  <http:request-builder>
    <http:query-param paramName="state" value="#[flowVars.state]" />
  </http:request-builder>
 </http:request>
</flow>
```

In Mule 4, you can simply use the `target` parameter in the `<flow-ref>` operation:
Mule 4 example
```
<flow name="orderProcessingFlow">
 <http:listener .../>
 <flow-ref name="stateLookup" target="state" />
 <http:request config-ref="config" path="state" method="POST">
  <http:query-params>
   #[{'state' : vars.state}]
  </http:query-params>
 </http:request>
</flow>
```

## Migrate Multiple Enrichers
In Mule 4, you can set only one `target` variable per operation. If you have more than one enricher configured in your Mule 3 application, you can achieve the same behavior in Mule 4 by using the `Set Variable` component:
Mule 3 example
```
<flow name="orderProcessingFlow">
	...
	<enricher doc:name="order-enricher">
	  <flow-ref name="validator-flow" doc:name="validator-flow"/>
	  <enrich source="#[payload.validation.result]" target="#[flowVars.validationResult]"/>
	  <enrich source="#[payload.validation.code]" target="#[flowVars.validationCode"/>
	</enricher>
	...
</flow>
```

Mule 4 example
```
<flow name="orderProcessingFlow">
 ...
 <flow-ref name="validator-flow" target="validation" />
 <set-variable value="#[vars.validation.result]" variableName="validationResult"/>
 <set-variable value="#[vars.validation.code]" variableName="validationCode"/>
 ...
</flow>
```

## See Also
  *
Migrating the Poll Component | MuleSoft Documentation
# Migrating the Poll Component
In Mule 3, the `<poll>` element was used to trigger a certain flow at a fixed frequency of time. This element was also a scope which required one (and only one) message processor to live inside of it. The output of that processor would be the message that the flow receives.
Mule 3 Example: Poll
```
<flow name="poll>
  <poll frequency="1000">
    <db:select config-ref="MySQL_Configuration">
      <db:parameterized-query>SELECT * FROM PERSON></db:parameterized-query>
    <db:select>
  </poll>
  <flow-ref name="doProcess" />
</flow>
```

In Mule 4, the `<poll>` element was replaced with the `<scheduler>` element. Main differences are:
  * It just triggers the flow. It’s no longer a scope
  * It supports both fixed frequency and cron expressions


Mule 4 Example: Scheduler
```
<flow name="poll>
  <scheduler>
    <scheduling-strategy>
      <fixed-frequency frequency="1000"/>
    </scheduling-strategy>
  </scheduler>
  <db:select config-ref="MySQL_Configuration">
    <db:sql>SELECT * FROM PERSON></db:sql>
  <db:select>
  <flow-ref name="doProcess" />
</flow>
```

For more information on the `<scheduler>` element, please read the Scheduler documentation.
## Migrating a Watermark
The `<poll>` element also supported a `<watermark>` element which was used to aid and scheduled synchronizations. That element doesn’t exist anymore. Instead, please read the Migrating Watermarks page.
## Quartz Transport
In Mule 3, a `quartz` transport existed that was deprecated in favor of the `poll`, so most of its uses may also be replaced by the `scheduler` in Mule 4.
Some features of the `quartz` transport do not exist in Mule 4, so a different approach is necessary to migrate those use cases.
### repeatCount
`repeatCount` is not supported in Mule 4 by the `scheduler`.
If you really need to fetch it, compare and store a counter in an Object Store.
### quartz:outbound-endpoint
This endpoint is not supported in Mule 4.
An alternative approach is to write the events to a queue (JMS or VM, for instance) and have another flow with a Scheduler that consumes all the messages from the queue and processes them.
### Unsupported job-endpoint
The transport used in a `job-endpoint`, when migrated to a Mule 4, can be migrated to a connector that has a polling source (such as File). In that case, you can put the Scheduler configuration directly into the polling source.
Mule 3 Example: Polling source
```
<flow name="poll>
  <quartz:inbound-endpoint name="quartzInboundEndpoint"
    cronExpression="0/3 * * * * ?" jobName="cronJob">
    <quartz:endpoint-polling-job>
      <quartz:job-endpoint address="sftp://.../~/data" />
    </quartz:endpoint-polling-job>
  </quartz:inbound-endpoint>
  <flow-ref name="doProcess" />
</flow>
```

Mule 4 Example: Polling source
```
<flow name="poll>
  <sftp:listener config-ref="inboundEndpointConfig" directory="data">
    <scheduling-strategy>
      <cron expression="0/3 * * * * ?"/>
    </scheduling-strategy>
  </sftp:listener>
  <flow-ref name="doProcess" />
</flow>
```

## See Also
  * Scheduler Endpoint (Trigger)
Queue Event Processors | MuleSoft Documentation
# Queue Event Processors
Anypoint Code Builder 
Anypoint Studio 
The Queue event processors allow you to manage temporary queues during your test runs.
All queues are emptied as soon as the test ends.
## Queue
Adds the value to the queue. If not specified, the value is taken from the `payload`.
```
<munit-tools:queue>
  <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

You can specify the queue’s name to which the value should be added. If not specified, the default queue will be used.
```
<munit-tools:queue queueName="CUSTOM_QUEUE_1">
  <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

## Dequeue
Removes the last element of the queue, if the queue is empty, it waits until an element is queued.
```
<munit-tools:dequeue/>
```

You can specify a timeout when waiting for an element to be queued:
```
<munit-tools:dequeue timeout="1000" timeoutUnit="SECONDS"/>
```

Like the queue operation, you can specify the queue’s name from which to dequeue. If not specified, the default queue will be used.
```
<munit-tools:dequeue queueName="CUSTOM_QUEUE_1"/>
```

## Queue Size
Function that obtains the queue size.
```
<munit-tools:assert-that expression="#[MunitTools::queueSize()]" is="#[MunitTools::equalTo(2)]" />
```

Like the other operations, you can specify the queue from which to the get the size. If not specified, the default queue will be used.
```
<munit-tools:assert-that expression="#[MunitTools::queueSize('CUSTOM_QUEUE_1')]" is="#[MunitTools::equalTo(2)]" />
```
Flow Metrics | MuleSoft Documentation
# Flow Metrics
Private Cloud Edition 
MuleSoft deprecated the flow metrics feature on Dec 9th, 2019. We recommend that you use Anypoint Monitoring to monitor your applications and APIs.   
---  
You can view the evolution of performance metrics for individual flows in your applications that are deployed to servers on premises (hybrid or Anypoint Platform Private Cloud Edition).
## Enable Flow Metrics for Hybrid
When you deploy a new application to a hybrid deployment environment, the flow metrics feature is not enabled by default. To enable flow metrics, your account must be granted one of the following permissions.
  * **Manage Application Data**
  * **Create Applications**
  * **Manage Settings**


To enable flow metrics:
  1. From Runtime Manager, click **Applications**.
  2. Select the application where you want to enable flow metrics, then click **Manage Application**.
  3. Click **Settings** , then select the **Flow Monitoring** tab.
  4. Select **Enabled**.
  5. Click **Apply Changes**.


## Access Flow Metrics
To view flow metrics, you must have the Read Application permission for the desired applications.
  1. Select the **Applications** tab in Runtime Manager.
  2. Enter a running application’s settings (either by clicking the **Manage Application** button on the side panel, or the application name itself in the table).
  3. Select the **Flows** tab on the left side bar.
  4. Select one or multiple flows.


## Verify the Status of Servers
If your application is deployed to a cluster or a server group, you can view the status of the flow on each server it runs in.
Use this information to rule out the possibility of a communication issue leading to inconsistent states throughout the servers.
## View Flow Metrics
Once you have selected one or multiple flows, you can view the **Metrics** tab.
This tab contains charts for the following three metrics:
  * Mule messages
  * Errors
  * Flow response time


All metrics are displayed as an average relative to the selected time scale.
The retention period for flow metrics is two weeks.   
---  
## Navigate the Metrics
All graphs can be viewed at different time scales by selecting the desired time interval on the top-right corner.
If your application runs on a cluster or server group, the aggregated metrics of the entire set of servers included are charted as a single plot line.
By hovering your mouse over a given point of a graph, an overlay displays numerical detail about activity on that instant.
You can set up alerts to notify you automatically whenever any of these metrics hits a critical value for a sustained period of time.
## See Also
  * Anypoint Monitoring
  *   * Monitor Applications
Prerequisites for MuleSoft Accelerator for Healthcare | MuleSoft Documentation
# Prerequisites for MuleSoft Accelerator for Healthcare
This page provides a summary of the guides available for configuring the various systems and products required to implement the use cases provided by this solution. The individual systems needed, and amount of configuration required, depend on which assets are to be deployed in your target environment(s) - refer to the use case pages for more details.
## Available Guides
The Salesforce Health Cloud Setup Guide is available for this accelerator.
Most of the implementation templates also contain details on requirements specific to those applications.
## See Also
  * For guidance on configuring your local build environment to download, modify, and deploy accelerator assets, see Getting Started with MuleSoft Accelerators.
  * MuleSoft Accelerator for Healthcare
Testing a Composer Flow | MuleSoft Documentation
# Testing a Composer Flow
By testing as you build your flow, you can ensure that each step and each field mapping in your flow is working as expected before activation. Frequent validation provides near real-time feedback about the success of your flow and enables you to fix errors as you build.
Testing processes and tests a single record. You must activate your flow to process all of your records.
When testing your flow, note the following:
  * A trigger step is required.
  * Testing automatically ends after ten minutes if not halted by an error or manually terminated.
  * The entire flow is executed and tested.


When testing your flows:
  * Build your flow in a sandbox environment to test your flow using inactive accounts.
  * Test your flows with sample or dummy records.
  * Consider limiting the number of records processed if your test times out.


To test a flow:
  1. In Composer, in the flows list, click the flow you want to test and click **Edit**.
  2. Click **Test**. Composer notifies you when the test is complete. The execution results from the test appear on the card.


If you need to contact Support for troubleshooting purposes, you can export your flow as a JSON file to share your flow by clicking the wrench icon and selecting **Export**.   
---  
## See Also
  * Mulesoft Composer: Overview
  * MuleSoft Composer: Getting Started
  * Composer Connector Reference
  * Knowledge Articles
Launching the Cloud IDE | MuleSoft Documentation
# Launching the Cloud IDE
**Open Beta Release** : The **cloud IDE is in open beta**. Any use of Anypoint Code Builder in its beta state is subject to the applicable beta services terms and conditions, available from the IDE.
Launch the cloud IDE from Anypoint Platform. Your Anypoint Platform user account and business organization are hosted in the US or EU cloud and aren’t shared across the hosts.
## Before You Begin with the Cloud IDE
Meet prerequisites before attempting to launch the cloud IDE:
  * An administrator with an Anypoint Platform organization account must provide you with the necessary permissions. See Configuring Permissions.
  * The cloud IDE requires a non-trial Enterprise license of Mule runtime engine. See Upgrade Your Account and Install an Enterprise License.
  * Anypoint Platform requires a user account. You can use an existing account or create one from Anypoint Platform (see supported Cloud Hosts).
  * Your organization administrator must accept the terms and conditions of the beta program for the cloud IDE from the Anypoint Code Builder landing page on your Anypoint Platform cloud host (US or EU). Sign-in is required. The **Terms & Conditions** button is available to the organization administrator only.
  * Review important open beta information:
The cloud IDE remains in an open beta period. During the open beta, your cloud IDE instance might get deleted, causing you to lose your integrations, automations, and APIs. Click for more information: To save your work, commit your project files to a source control management (SCM) system. See Controlling Source Files. Don’t use the cloud IDE beta version of Anypoint Code Builder to develop APIs, integrations, or automations for production environments.  
---  


## Open the Cloud IDE from Anypoint Platform
To launch the cloud IDE:
  1. Review the prerequisites in Before You Begin with the Cloud IDE so that you can use Anypoint Code Builder.
  2. Log in to Anypoint Platform:
     * anypoint.mulesoft.com for the U.S. host (supports all non-EU regions)
     * eu1.anypoint.mulesoft.com for the EU-compliant host
If you have an account in one cloud but intend to work in another, you must create an account in that cloud to create and work on your projects.
  3. From Anypoint Platform, open the Anypoint Code Builder landing page.
  4. From the Anypoint Code Builder landing page, click **Launch Cloud IDE**.
After provisioning of your cloud IDE is complete, the IDE opens. The provisioning process can take a few minutes.
Your cloud IDE environment is associated with your user account. The cloud environment also has a unique URL that only you can access and that is _not_ embedded within the Anypoint Platform UI. You can reopen your cloud IDE directly from that URL or relaunch it indirectly from Anypoint Code Builder in Anypoint Platform.
  5. Click the MuleSoft icon in the activity bar to see and use Anypoint Code Builder features.
Execute Excel Macro | MuleSoft Documentation
# Execute Excel Macro
Run a macro in an Excel file or sheet and obtain the execution’s result in a variable. You can pass up to 30 variables as arguments to the macro.
Don’t include this action step inside an Excel Session; the Execute Excel Macro runs independently.
Execute Excel Macro requires Microsoft Excel installed on the computer that runs the automation. Otherwise, the action step fails to execute.
## Before You Begin
Before using this action step, ensure that:
  * Microsoft Excel is installed on the computer that runs the automation.


## Properties
  * **Common**
See Common Properties for a description.
  * **Source Excel Operation Settings**
    * **Directory path**
Directory path to the source file
    * **Macro**
Macro to run
    * **Password protected**
Whether the Excel file is password protected
If you select this option, specify the password in the wizard.
    * **Source file name**
Name of the source file


## Inbound Variables
  * **Directory path**
  * **Source file name**
  * **Password for the excel file**
  * **{Arg1} replaced by** …​ **{Arg30} replaced by**
  * **Is Arg1 used** …​ **Is Arg30 used**


## Outbound Variables
  * **Result**
Result of the macro’s execution.
  * **Executed** (Boolean)
Returns `true` if the execution of the macro was successful.


## Wizard
Specify the **Directory path** and **File name** of the Excel file that contains the macro to run.
After specifying the file, select the macro to run from the **Macro** dropdown menu. This list autopopulates with the macros existing in the specified Excel file.
You can pass up to 30 variables as arguments to the macro by selecting the corresponding checkbox and setting the value.
## See Also
  *   *
Packaging a Custom Policy | MuleSoft Documentation
# Packaging a Custom Policy
You can use the Mule Maven Plugin to package your custom policy into a deployable JAR file that you can later apply to an API.
  1. Make sure you added the Mule Maven Plugin to your pom.xml file. This is done automatically by custom policy’s Archetype
```
<plugin>
  <groupId>org.mule.tools.maven</groupId>
  <artifactId>mule-maven-plugin</artifactId>
  <version>${mule.maven.plugin.version}</version>
  <extensions>true</extensions>
</plugin>
```

  2. From the command line in your project’s folder, run the package phase:
```
> mvn clean package
```



The packager then packages your application and creates the deployable JAR file into the target directory within your project’s folder.
It will also verify that all the necessary files were provided for the packaging, and that the information provided in the mule-artifact and in the policy yaml are valid.
## See Also
  * Getting started with custom policies development
  * Uploading a Custom Policy to Exchange
  * Reviewing Custom Policy concepts
toHex | MuleSoft Documentation
# toHex
## toHex(content: Binary): String
Transforms a binary value into a hexadecimal string.
### Parameters
Name | Description  
---|---  
The `Binary` value to transform.  
### Example
This example transforms a binary version of "Mule" (defined in the variable, `myBinary`) to hexadecimal.
#### Source
```
%dw 2.0
import * from dw::core::Binaries
output application/json
var myBinary = "Mule" as Binary
var testType = typeOf(myBinary)
---
{
  "binaryToHex" : toHex(myBinary)
}
```

#### Output
```
{ "binaryToHex": "4D756C65" }
```
Credentials for AWS | MuleSoft Documentation
# Credentials for AWS
The Credentials for AWS action step enables you to set up your AWS credentials one time and then reference them in any other AWS action step that requires them.
## Inbound Variables
  * **Client Id**
  * **Client Secret**
  * **Session Token**
  * **Use Session Token**
  * **Region Endpoint**


## Outbound Variables
  * **AwsCredentials**


## Wizard
  * **Client ID**
The client ID used to authenticate against AWS.
  * **Client Secret**
The client secret used to authenticate against AWS.
  * **Region Endpoint**
The AWS region endpoint Code to connect to, for example: `us-east-1`.
See AWS service endpoints for a list of available AWS region endpoints.
  * **Use session token to authenticate**
Select this option to specify the AWS session token to use if you are connecting to AWS resources using temporary credentials that require a session token.
    * **Session Token**
The session token to use for authentication when **Use session token to authenticate** is selected.


## See Also
  *   * AWS: Using temporary credentials with AWS resources
divideBy | MuleSoft Documentation
# divideBy
## divideBy(items: Object, amount: Number): Array<Object>
Breaks up an object into sub-objects that contain the specified number of key-value pairs.
If there are fewer key-value pairs in an object than the specified number, the function will fill the object with those pairs. If there are more pairs, the function will fill another object with the extra pairs.
### Parameters
Name | Description  
---|---  
Key-value pairs in the source object.  
The number of key-value pairs allowed in an object.  
### Example
This example breaks up objects into sub-objects based on the specified `amount`.
#### Source
```
%dw 2.0
import divideBy from dw::core::Objects
output application/json
---
{ "divideBy" : {"a": 1, "b" : true, "a" : 2, "b" : false, "c" : 3} divideBy 2 }
```

#### Output
```
{
 "divideBy": [
  {
   "a": 1,
   "b": true
  },
  {
   "a": 2,
   "b": false
  },
  {
   "c": 3
  }
 ]
}
```
Custom Policies | MuleSoft Documentation
# Custom Policies
If you want an API policy that isn’t included in the default set of policies, you can create your own custom policy. A custom policy requires the following files:
  * Policy Definition - YAML file that describes the policy and its configurable parameters
  * Policy Configuration - XML file with the backend processes that implement the policy


A custom policy also must contain a pointcut declaration. See the Pointcuts Reference below for more information.
You can create a custom policy if you use one of the following runtimes:
  * Mule 3.8 or later unified runtime
  * Mule Gateway runtime 2.x or later


In Studio 6.1 and later, you can use the Studio custom policy editor (Beta).
## Limitations
Custom policies must be self-contained. From a custom policy, do not reference another dependent policy, a connector on the app, a shared connector or any other dependency that could be available at runtime or in an external library.
You create a custom policy by using the elements in Mule Runtime to evaluate and process HTTP calls and responses. The policy filters calls to an API and matches one of the query parameters in the request to a configurable, regular expression. Unmatched requests are rejected. You set the HTTP status and the payload to indicate an error whenever a request does not match the conditions of the filter.
## Applying a Custom Policy
To make a custom policy available to users, you add the policy to Anypoint Platform in API Manager. On the API version details page of an API, users can then choose Policies, select the custom policy from the list, and apply the policy to the API.
If you deploy the API on a private server using a .zip file that you downloaded from Anypoint Platform, the new policy is available for on-premises users to apply. Even if the proxy was already deployed before creating the policy, there’s no need to re-download or re-deploy anything. The new policy automatically downloads to the `/policies` folder, in the location where the Mule Gateway or Mule 3.8 unified runtime is installed. Configure your organization’s Client ID and Token in the `wrapper.conf` file.
## Failed Policies
In Mule Runtime 3.8 and later and Mule Gateway Runtime 2.1 and later, when an online policy is malformed and it raises a parse exception, it’s stored under `failedPolicies` directory inside `policies` directory, waiting to be reviewed. In the next poll for policies it won’t be parsed. If you delete that policy, it is deleted from that folder too. If the folder has no policies, it is deleted.
### Using Existing Policies
You can modify or combine existing policies that exist by default. You can view the XML source code, and use it in a custom policy configuration.
In an on-premises runtime installation, search for the folder `examples>policies` to find existing policies.
## See Also
  * Policies in Mule 3
  * Creating a Custom Policy
External Organization Access | MuleSoft Documentation
# External Organization Access
The External Access feature enables separate organizations to collaborate in Anypoint Platform. For example, organizations can share API specifications, connectors, and other assets in Anypoint Exchange with each other, without making them public. Additionally, you can establish a connection with a trusted Salesforce organization.
Anypoint Platform organization administrators control which organizations their users can collaborate with by maintaining a list of trusted organizations in Access Management. Adding an entry to this list means that you trust the other organization and its users, and you acknowledge that you are enabling your users to grant permission to and be granted permissions by the other organization.
Using the External Access functionality in Access Management, you can:
  * Establish a relationship with a trusted Anypoint Platform organization.
  * Establish a relationship with a trusted Salesforce organization.
Running Workflows and Viewing Workflow Run Results | MuleSoft Documentation
# Running Workflows and Viewing Workflow Run Results
RPA Builder enables you to test a Workflow by executing a local run. After the Workflow execution finishes, the Workflow Run Results panel shows detailed information about the execution.
To perform a test run of a Workflow in RPA Builder, click **Run Workflow** () on the Workbench toolbar or press _F7_ on your keyboard.
The RPA Builder window is hidden while the Workflow executes, so the engine can now use the mouse and keyboard just like a normal user would and you can watch to confirm if the Workflow performs correctly. Do not use the mouse or keyboard while the Workflow runs.
Depending on the settings you made for the **Show Message boxes** value in the _Project Properties_ , additional information may appear during the run. Note that every message box takes a few seconds to disappear, which causes a corresponding pause in the Workflow and affects measured times and Workflow stability.
Before using a Workflow for productive measurement, turn off debug message boxes and perform at least one test run afterward.
## Pause or Exit a Workflow Run
To pause or exit the Workflow during the execution:
  1. Click the () tray icon.
  2. Select either **Script Paused** or **Exit**.


Pressing _Pause/Break_ on your keyboard also stops a running Workflow.
## The Workflow Run Results Panel
After you execute a Workflow from within RPA Builder, information about the last run displays in the Workflow Run Results panel at the end of the RPA Builder screen:
This information helps you identify problems and their causes in your Workflow. If you do not see the Workflow Run Results window, click **Show Workflow Run Results** in the menu bar.
The Workflow Run Results window lists information about measured response times, found images, errors that occurred, and captured screenshots. You can double-click an entry to navigate to its corresponding Workflow element.
### Identifying Errors
After a Workflow run, RPA Builder highlights Workflow elements that failed to execute and caused an error by marking them in red:
Click the expander arrows to get more detailed information about an error:
This panel provides detailed information about what failed. In this case, the _Web Session (Firefox)_ action step cannot start because Firefox is not installed in the computer that is executing the test run for the Workflow.
The error screenshot shows the desktop as it looked when the error occurred. Click the screenshot to enlarge it.
## Opening the Trace Log
The Trace Log contains even more detailed information about the last run.
To open the Trace Log, click **Open Trace Log** in the Tools submenu inside the Workbench toolbar:
## See Also
  * Using Workflow Debugger
  * Analyzing Problems with Analysis Packages
Clusters | MuleSoft Documentation
# Clusters
Private Cloud Edition 
For information about how clustering applies to CloudHub 2.0, see Clustering.   
---  
A cluster is a set of up to eight servers that act as a single deployment target and high-availability processing unit. Unlike in server groups, application instances in a cluster are aware of each other, share common information, and synchronize statuses. If one server fails, another server takes over processing applications. A cluster can run multiple applications.
Before creating a cluster, you must create the Mule runtime engine instances and add the Mule servers to Anypoint Runtime Manager.
## Multicast vs Unicast Clusters
While configuring a cluster, specify either unicast or multicast options for identifying a node within the cluster:
  * **Unicast** :
A unicast cluster requires that you configure the IP addresses of the nodes in the cluster. If a server has multiple interfaces, use the internal IP address that allows the node to communicate directly with other nodes. Clustering across different availability zones or regions can cause a cluster performance issue, as it relies on high speed connectivity. Putting all cluster nodes on one subnet or in the same availability zone reduces performance risks.
Because Mule relies on the IP address to identify the server, IP addresses can’t be dynamically assigned using DHCP for servers on a unicast cluster. If a server is restarted and uses DHCP to get a new IP address, you must add the server to the cluster using its new IP address.
The server status must be Running to be added to a unicast cluster.
  * **Multicast** :
A multicast cluster comprises servers that automatically detect each other. Servers that are part of a multicast cluster must be on the same network segment.
One advantage of multicast clusters is that the server status doesn’t need to be Running to configure it as a node in a cluster. Another is that you can add nodes to the cluster dynamically without restarting the cluster.
Check with your network administrator to determine if multicast is allowed within your network, because many networks block multicast functionalities.


## See Also
  * Add Servers to Runtime Manager
  * Mule High Availability Clusters
camelize | MuleSoft Documentation
# camelize
## camelize(text: String): String
Returns a string in camel case based on underscores in the string.
All underscores are deleted, including any underscores at the beginning of the string.
### Parameters
Name | Description  
---|---  
The string to convert to camel case.  
### Example
This example converts a string that contains underscores to camel case.
#### Source
```
%dw 2.0
import * from dw::core::Strings
output application/json
---
{
 "a" : camelize("customer_first_name"),
 "b" : camelize("_name_starts_with_underscore")
}
```

#### Output
```
{
  "a": "customerFirstName",
  "b": "nameStartsWithUnderscore"
 }
```

## camelize(text: Null): Null
Helper function that enables `camelize` to work with a `null` value.
WebSockets Connection Close | MuleSoft Documentation
# WebSockets Connection Close
This operation closes currently connected WebSockets referenced by a Socket ID.
```
<flow name="closeConnection">
  <websocket:close-socket
    socketId="#[attributes.socketId]"
    reason="Quota exceeded"/>
</flow>
```

## Close Output
This operation returns no payload or attributes.
## On Socket Closed
A message source triggers a flow each time a WebSocket is closed. This is useful to perform cleanup operations, logging, or updating the app’s state.
This is asynchronous. By the time the flow is invoked the socket has already been closed. Trying to send messages through the referenced WebSocket results in an error.
```
<flow name="onConnectionClosed">
  <websocket:on-connection-closed path="/chat/*" config-ref="ws" />
  <logger
    level="INFO"
    message="No more messages please: you shall not pass." />
</flow>
<flow name="receiveMessagesFlow">
  <websocket:on-inbound-connection path="/chat" config-ref="ws" />
  <logger
    level="INFO"
    message="Someone just sent a message and now I will close this connection!" />
  <websocket:close-socket
    socketId="#[attributes.socketId]"
    reason="I don't like to talk."
    config-ref="ws" />
</flow>
```

The path parameter indicates the path of sockets that when closed, trigger the flow. To indicate `catch-all`, you can use the asterisk wildcard symbol (∗).
## On Socket Closed Output
This operation returns an empty payload and a WebSocketAttributes object in the attributes.
## See Also
  * MuleSoft Help Center
  *   *   * WebSockets Connector Overview
FTP Connector 2.0 | MuleSoft Documentation
# FTP Connector 2.0
Support Category: Select
Anypoint Connector for FTP (FTP Connector) provides access to files and folders on an FTP server. FTP connector operations manage file transfers by using File Transfer Protocol (FTP). The connector’s main features include:
  * The ability to read files or fully list directory contents on demand.
  * Support for common FTP operations such as creating directories and copying, moving, renaming, and deleting files.
  * Support for locking files.
  * File matching functionality.
  * A design that is consistent with the File and FTP Connectors.
The same set of operations is available using these two connectors, and they behave similarly.


## Representation of File Attributes
Mule 4 provides a message structure of a payload and attributes in which the data moves around, making that payload a file content. The attributes provide an object that contains metadata on the payload and information such as the file’s name, path, size, and timestamps. For FTP Connector and SFTP Connector, these attributes are known as _file attributes_.
In Mule 4, messages comprise _file content_ (a payload) and _file attributes_ (metadata about the payload, such the file’s name, path, size, and timestamps. The file attributes also describe the format in which a payload is represented by including a file’s encoding and MIME type.
## 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 (Studio)


Before creating an app, you must have access to Anypoint Platform and Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Allowing Addresses for API Platform Proxies | MuleSoft Documentation
# Allowing Addresses for API Platform Proxies
To allow addresses in Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) version 4.0 and later, follow these steps:
  1. From the api-manager/api-platform-web-env configmap verify if `APW_FEATURES_PROXYWHITELIST` is set to `true` by running the following command:


`kubectl get cm -n api-manager api-platform-web-env -o jsonpath={.data.APW_FEATURES_PROXYWHITELIST} true`
  2. If the response is not `true`, then set the value to `true` running the following command:


`kubectl patch cm -n api-manager api-platform-web-env -p '{"data":{"APW_FEATURES_PROXYWHITELIST": "true" }}`
  3. Update the `APW_PROXYWHITELIST_RULES` in the same configmap by running the following command to patch the configmap with desired allow list rules:


`kubectl patch cm -n api-manager api-platform-web-env -p '{"data":{"APW_PROXYWHITELIST_RULES": ".**\\.somewhere\\.com,.**\\.somewhereelse\\.com" }}`
The previous example shows how to allow requests to `.somewhere.com/` and `.somewhereelse.com/` domains, where `*` is any part of a DNS name or URL, then list the rules separated by commas.
  4. Verify the patch was applied correctly. After confirmed, re-create the pods to ensure each node in the cluster uses the most recent configuration by running this command:


`kubectl delete pod -n api-manager -l component=api-platform-web`
## See Also
  * Managing Anypoint Platform PCE
isDecimal | MuleSoft Documentation
# isDecimal
## isDecimal(number: Number): Boolean
Returns `true` if the given number contains a decimal, `false` if not.
### Parameters
Name | Description  
---|---  
The number to evaluate.  
### Example
This example indicates whether a number has a decimal. Note that numbers within strings get coerced to numbers.
#### Source
```
%dw 2.0
output application/json
---
[ isDecimal(1.1), isDecimal(1), isDecimal("1.1") ]
```

#### Output
```
[ true, false, true ]
```
fromCharCode | MuleSoft Documentation
# fromCharCode
## fromCharCode(charCode: Number): String
Returns a character that matches the specified Unicode.
### Parameters
Name | Description  
---|---  
The input Unicode (a `Number`).  
### Example
This example inputs the Unicode number `117` to return the character "u".
#### Source
```
%dw 2.0
import * from dw::core::Strings
output application/json
---
{
 "fromCharCode" : fromCharCode(117)
}
```

#### Output
```
{ "fromCharCode": "u" }
```

## fromCharCode(charCode: Null): Null
Helper function that enables `fromCharCode` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
HTTP Connector 1.10 - XML and Maven Support | MuleSoft Documentation
# HTTP Connector 1.10 - XML and Maven Support
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 access the connector from your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file.
  * If you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location and it also adds a dependency to the `pom.xml` file.


## Add a Namespace for the Connector
Paste the following code inside the `mule` tag of the header of your configuration XML:
```
http://www.mulesoft.org/schema/mule/http
http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
```

## Add a POM File Dependency
The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app. When you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to this connector:
```
<dependency>
 <groupId>org.mule.connectors</groupId>
 <artifactId>mule-http-connector</artifactId>
 <version>x.x.x</version>
 <classifier>mule-plugin</classifier>
</dependency>
```

Replace `<version>` 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.
  2. In Exchange, click **Login** and supply your Anypoint Platform username and password.
  3. In Exchange, search for `http`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## Next Step
After completing your namespace and `pom.xml` file, you can try the Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Anypoint VPN High Availability | MuleSoft Documentation
# Anypoint VPN High Availability
Your VPN connection consists of two VPN tunnels that terminate in different Availability Zones to provide increased availability to your VPC. During a mandatory upgrade, AWS might briefly disable one of the two tunnels of your VPN connection.
When you configure your customer gateway, configure both tunnels for redundancy. When one tunnel becomes unavailable (for example, it is down for maintenance), AWS automatically routes network traffic to the other available tunnel for that specific VPN connection. When AWS performs updates on one VPN tunnel, it sets a lower outbound multi-exit discriminator (MED) value on the other tunnel to ensure failover.
The AWS Site-to-Site VPN SLA requires two VPN endpoints for each connection. Having redundant Anypoint VPN tunnels configured helps to prevent MuleSoft service downtime during the AWS auto-patching window.
To ensure that your applications and related operations can handle Anypoint VPN updates, issues, and individual customer gateway failures, implement High Availability with redundant Anypoint VPN connections. Each Anypoint VPN connection consists of two endpoints, providing High Availability (HA) on the MuleSoft side by default.
## Prerequisites
  * Sufficient entitlement for each VPN connection
  * Two VPN endpoints using different public IP addresses
  * Two VPN connections in Runtime Manager


## Configure High Availability with Anypoint VPN
The following example shows a High Availability VPN topology that uses a single Anypoint VPC and two VPN connections.
A MuleSoft Virtual Private Gateway (VGW) supports one Anypoint VPC association and up to 10 VPN connections. You can locate your VPN Gateways in the same data center or in different physical locations.
To eliminate all single points of failure, the two customer gateways should be in different data centers, and preferably in different cities. Ideally, use your Disaster Recovery location for the second gateway.
Use BGP routing to advertise the same routes via VPN-1 and VPN-2. For instructions on how to control path selection via the routing protocol, see Anypoint VPN Path Selection using BGP Routing.
In this scenario, the VPN Gateways are configured to prefer VPN-1 Tunnel-1, then VPN-1 Tunnel-2, then VPN-2 Tunnel-1, and finally VPN-2 Tunnel-2. This configuration produces an automatic failover to another tunnel and another VPN in the event of a VPN connectivity issue. This makes the Anypoint VPN solution more resilient and robust.
High Availability VPN connections also support static routing, in which you establish a VPN-2 to work as a redundant, standby connection in the event of a failure with VPN-1.
## See Also
  * Create an Anypoint VPN Connection
  * Anypoint VPN Downtime Risk
  * Using Redundant Site-to-Site VPN Connections to Provide Failover
  * Continue to Have Redundant Pair of VPNs as Well
  * How to Calculate VPC and VPN License Requirements
Allowlisting Trusted Domains | MuleSoft Documentation
# Allowlisting Trusted Domains
Every HTTP request you make to an external resource goes through the API Console Proxy. For security reasons, you need to register the domain as a trusted domain in Anypoint Platform.
To add a new domain:
  1. Sign in to Anypoint Platform using an account that has the root Organization Administrator permission.
  2. In the navigation bar or the main Anypoint Platform page, click **Access Management**.
  3. Click **Trusted domains**.
  4. Click **Add domain**. The domain must not match with any existing trusted domain, and must not be any domain or subdomain of MuleSoft or Anypoint Platform.
  5. In the dialog box that appears, type the domain name and click **Add domain**. _Result_ : The domain has been added to your list of trusted domains. You are redirected to the trusted domains page, where you can edit or delete your domains. If you register a domain on a parent organization, it is also allowlisted on all your business groups.


## Automatic Registration of Domains
Manual domain registration can be required for public Exchange assets and portals created before 2024.   
---  
When you publish an API specification to Exchange or send a request through the proxy, the base URI of the implementation is automatically added to the list of trusted domains.
Non-authenticated requests from public portals in Exchange or via shareable links in Mocking Service are automatically registered.   
---
Get Array Count | MuleSoft Documentation
# Get Array Count
The _Get Array Count_ action step returns the number of elements in an array.
You can then use this number as the number of iterations in a loop (_Loop_), for example, across the array elements.
## Properties
This action step contains no special properties other than the _general_ ones.
## Inbound Variables
  * **Array to get count of** (array, default: blank) Array for which the number of elements is to be determined.


This array must be created beforehand using the _Workflow Based Variables_ element or any action step that creates or returns an array.
The return array from the _Read from Excel File_ Action Step is shown only within the same transaction as a Pin Variable. To use the _Array Count_ in a later transaction, copy the return array into an array created beforehand in the Workflow Based Variables (see _Set_Array_Variable_).
## Outbound Variables
  * **Array Count** (integer, default 0) Number of elements in the array


## Wizard
All arrays that are available within the Workflow are shown in the drop-down list next to _Array to get count of_.
Ensure the array is correctly populated. An empty array returns an _Array Count_ of 0.
## Example
In this example, an auto repair shop wants to monitor automatically which _Services_ have been performed on a certain vehicle.
These services are read from an array and checked off on a checklist.
To test the Workflow, the _Workflow Based Variables_ are
populated with sample values. In productive operation these values are then overwritten with values from the _Car Service App_.
The _Services_ array is populated with all the services from the _Car Service App_ which are performed.
First, in the transaction _130 Process list of done services_ , the number of services that have been performed is calculated using the _Get Array Count_ action step before each service is read in a loop and graphically (see _OCR_) compared against the services on a checklist.
If the service is on the checklist, it will be checked off. The checklist is used later on in the Workflow to calculate costs.
The configuration values of the individual action steps are passed on using (Pin) _Variables_.
## See Also
  *   *
isLiteralType | MuleSoft Documentation
# isLiteralType
## isLiteralType(t: Type): Boolean
Returns `true` if the input is the Literal type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The type to check.  
### Example
This example shows how `isLiteralType` behaves with different inputs.
#### Source
```
%dw 2.0
import * from dw::core::Types
type ALiteralType = "Mariano"
output application/json
---
{
  a: isLiteralType(ALiteralType),
  b: isLiteralType(Boolean)
}
```

#### Output
```
{
 "a": true,
 "b": false
}
```