BassemE/mulesoft-documentation-embeddings huggingface dataset:
isLeapYear | MuleSoft Documentation
# isLeapYear
## isLeapYear(dateTime: DateTime): Boolean
Returns `true` if it receives a date for a leap year, `false` if not.
This version of `leapYear` acts on a `DateTime` type. Other versions act on the other date and time formats that DataWeave supports.
### Parameters
Name | Description  
---|---  
The `DateTime` value to evaluate.  
### Example
This example indicates whether the input is a leap year.
#### Source
```
%dw 2.0
output application/json
---
[ isLeapYear(|2016-10-01T23:57:59|), isLeapYear(|2017-10-01T23:57:59|) ]
```

#### Output
```
[ true, false ]
```

## isLeapYear(date: Date): Boolean
Returns `true` if the input `Date` is a leap year, 'false' if not.
### Parameters
Name | Description  
---|---  
The `Date` value to evaluate.  
### Example
This example indicates whether the input is a leap year.
#### Source
```
%dw 2.0
output application/json
---
[ isLeapYear(|2016-10-01|), isLeapYear(|2017-10-01|) ]
```

#### Output
```
[ true, false ]
```

## isLeapYear(datetime: LocalDateTime): Boolean
Returns `true` if the input local date-time is a leap year, 'false' if not.
### Parameters
Name | Description  
---|---  
A `LocalDateTime` value to evaluate.  
### Example
This example indicates whether the input is a leap year. It uses a `map` function to iterate through the array of its `LocalDateTime` values, applies the `isLeapYear` to those values, returning the results in an array.
#### Source
```
%dw 2.0
output application/json
---
[ |2016-10-01T23:57:59-03:00|, |2016-10-01T23:57:59Z| ] map isLeapYear($)
```

#### Output
```
[ true, true ]
```
Create Clusters in Runtime Manager | MuleSoft Documentation
# Create Clusters in Runtime Manager
Private Cloud Edition 
To deploy applications to a cluster, add the servers to Runtime Manager first and then create the cluster. You need to add at least one server to create a cluster.
When you add a server to a unicast cluster, all existing servers in the cluster are restarted.   
---  
For Object Store persistence on all the servers in your cluster, create your cluster manually and use Quorum Management.
## Restrictions
Before you add servers to a cluster, note the following restrictions:
  * Servers cannot contain any previously deployed applications.
  * Servers cannot belong to another cluster or group.
  * Multicast servers can be in the **Running** or **Disconnected** state.
  * Unicast servers must be in the Running state.
  * All servers in a cluster must be running the same versions of:
    * Mule runtime engine (including monthly update)
    * Runtime Manager agent
    * Java
For information about monthly updates, see Monthly Date-Patch Updates.


## Create a Cluster
To create a cluster:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Servers** in the menu.
  3. Click the **Create Cluster** button:
Figure 1. The arrow shows the **Create Cluster** button on the **Servers** page.
  4. In the **Create Cluster** page, enter the name for the cluster.
Cluster names can contain between 3-40 alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). They cannot start or end with a hyphen and cannot contain spaces or other characters.
  5. Select **Unicast** or **Multicast**.
  6. Select the servers to include in your new cluster.
  7. Click the **Create Cluster** button.


The new cluster appears in the **Servers** list. The servers no longer appear in the **Servers** list. To see the list of servers in the cluster, click the cluster name.
## See Also
  * Add Servers to Runtime Manager
  *   *   * Shut Down, Restart, or Delete Servers
  * Deployment and Server Scaling
Cipher Suites | MuleSoft Documentation
# Cipher Suites
When you configure a TLS context, default ciphers are applied to it based on the TLS version you selected. If you don’t use the defaults, you can select ciphers that match the configured keystore to ensure that TLS can set up a connection:
  * For a keystore with an RSA key (the most common type), select ciphers that contain the string `RSA`.
  * If you are using ECC ciphers, select ciphers that contain the string `ECDSA`. Consult TLS standards and documentation for more information.
  * If a client device supports AES-dedicated CPU instructions, use the AES-GCM ciphers. If the client does not support AES-dedicated instructions (some mobile and IoT devices), the client negotiates to use `CHACHA20-POLY1305`. It takes two (client and server) to perform the CHACHA.


## TLS 1.3 Cipher Suites
TLS 1.3 support is available only if you are using the **Anypoint Security** target.
The cipher suites for TLS 1.3 are listed with those of TLS 1.2 and TLS 1.1 and appear in the **No known vulnerabilities and support Perfect Forward Secrecy** grouping. When you use cipher suites that start with the string `TLS`, keep in mind the following:
  * The new cipher suites for TLS 1.3 cannot be used with TLS 1.1 and TLS 1.2.
  * The cipher suites for TLS 1.2 and TLS 1.1 cannot be used for TLS 1.3.
  * The new cipher suites for TLS 1.3 are defined differently from the cipher suites for earlier versions of TLS and do not specify the certificate type (for example, RSA, DSA, ECDSA) or the key exchange mechanism (for example, DHE or ECHDE).


## Select Ciphers
In addition to the defaults, you can select other ciphers to use with the selected TLS version. Each TLS context can have multiple ciphers.
  1. Click **Ciphers** to select available ciphers. If you select a **TLS Version** value of **TLS 1.3** , keep the default selection, which includes all three of the TLS cipher suites.
  2. If you selected **Mule** as the **Target** value for the TLS context, you can define custom ciphers to use with your proxy instance.
  3. Click **Save**.


If you add a cipher that’s not supported by the Java runtime, you receive a warning, but this does not prevent you from saving the TLS context.
## TLS Support on Anypoint Runtime Fabric
The TLS 1.3 protocol is enabled by default for those clients that support it.
OpenSSL 1.1.1 and TLS 1.3 provide the following security enhancements and performance improvements over TLS 1.2:
  * Double or more than double TLS 1.2 connection performance throughput boost over an earlier Runtime Fabric internal load balancer running on OpenSSL 1.0.2
  * Reduction of one round trip in a full handshake
  * Added TLS 1.2 and TLS 1.3 ChaCha20-Poly1305 ciphers for better mobile and IoT device support
  * Protection against downgrade attacks
  * Continued support for both RSA and ECDSA keys
  * Removal of obsolete and insecure features from TLS 1.2 and TLS 1.1. See Anypoint Security Edge Release Notes for a list of supported and deprecated ciphers.


## See Also
  * Add a TLS Context for Mule
  * Configure a TLS Context for Runtime Fabric Load Balancer
wrapWith | MuleSoft Documentation
# wrapWith
## wrapWith(text: String, wrapper: String): String
Wraps the specified `text` with the given `wrapper`.
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
The input string.  
The content used to wrap.  
### Example
This example shows how `wrapWith` behaves with different inputs and sizes.
#### Source
```
%dw 2.0
import * from dw::core::Strings
output application/json
---
{
 "a": wrapWith(null, "'"),
 "b": wrapWith("", "'"),
 "c": wrapWith("ab", "x"),
 "d": wrapWith("'ab'", "'"),
 "e": wrapWith("ab", "'")
}
```

#### Output
```
{
 "a": null,
 "b": "''",
 "c": "xabx",
 "d": "''ab''",
 "e": "'ab'"
}
```

## wrapWith(text: Null, wrapper: Any): Null
Helper function that enables `wrapWith` to work with a `null` value.
_Introduced in DataWeave version 2.2.0._
Hardening your Mule Installation | MuleSoft Documentation
# Hardening your Mule Installation
As distinct from Security, hardening refers to the steps one must perform in order to bring an application from development into production. These are elaborate procedures one must go through in order to deploy something in the IT space after you complete the development cycle.
Normally, an IT organization already has control of keeping open ports to a minimum, restricting access to administrative applications, minimizing the number of applications, and other measures to ensure quality. We recommend using secure files to configure Mule, as well as using secure configuration files.
## Hardening Checklist
To begin hardening a Mule installation that you are hosting on premises:
  * Run Mule as a non-privileged User.
  * Install Mule as a Service.
  * Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files.
  * In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings.
  * Manage certificates in a keystore file.
  * Use a separate property file to store usernames and passwords, and secure it using file system permissions.


For instructions specific to Runtime Fabric, see Hardening Mule Runtime on Runtime Fabric.
### About Running Mule as a Non-Privileged User
On Linux and Unix, you can run Mule as any user with the following caveats:
  * You need write permissions to logs directory
  * Without root you cannot use ports below 1024


On Windows, you need to be in admin user’s group to run Mule.
## Hardening in Layers
By its nature, you can situate Mule in a variety of configurations. The suggested approach to hardening involves hardening in layers beginning with the operating system, then working up the stack. The Center for Internet Security (CIS) publishes configuration benchmarks that are widely used in whole or in part as system hardening guides.
Commercial configuration management and integrity management tools can help you automate management to the CIS benchmarks. Also, Mule documentation includes a good deal of information on configuring security. If your application deals in sensitive data, consider using SSL Transport (HTTPS) to protect it.
On the network security side, security experts recommend using a good stateful inspection network firewall with a default-deny rule set and exceptions only for justified business needs. Also, any internet facing server belongs in a DMZ with strong default-deny egress rules on the firewall to prevent data exfiltration. Furthermore, you can use a network IDS/IPS to monitor and prevent known attacks. Putting the database on an internal network - not the DMZ - also helps to harden your installation.
Be sure your software developers are familiar with secure web application coding techniques. At the very least, they should be familiar with best practices to avoid common web app pitfalls, such as those listed in OWASP’s top 10 Project.
## See Also
Configuring Replicas for Flex Gateway in Connected Mode | MuleSoft Documentation
# Configuring Replicas for Flex Gateway in Connected Mode
Add a Flex Replica as a Linux Service |  Add a Flex Replica in a Docker Container  
---|---  
## Flex Replicas
A Flex Replica is an instance of Flex Gateway. Setting up your gateway layer with multiple Flex Gateway replicas enables the APIs deployed on Flex Gateway to serve more traffic.
When using Flex Gateway to manage APIs in production, configure more than one Flex Replica to avoid a single point of failure. Running multiple Flex Replicas also increases performance if your API service receives a significant amount of traffic.
## Before You Begin
Before getting started, ensure you have completed the following tasks:
  * Install a Flex Gateway
  * Register and Run in Connected Mode


## Add a Flex Replica as a Linux Service
Adding a Flex Replica as a Linux Service includes the following tasks:
  * Copy and paste the registration file created during registration to your Linux machine or VM.
  * Run the Flex Gateway start command.


### Copy the Registration File
Copy the `registration.yaml` file to the following location on your Linux machine or VM:
  * `/usr/local/share/mulesoft/flex-gateway/conf.d`


### Start Commands
Start Flex Gateway with the following command:
```
sudo systemctl start flex-gateway
```

Verify that the Flex Gateway service is running successfully:
```
systemctl list-units flex-gateway*
```

If `flex-gateway.service` has a status of `active`, Flex Gateway is successfully running.
```
 UNIT               LOAD  ACTIVE SUB   DESCRIPTION
 flex-gateway.service       loaded active running Application
```

Now if you check in Runtime Manager after clicking **Flex Gateway** in the left navigation, your Flex Gateway will have an additional replica listed. You may need to refresh the page.
## Add a Flex Replica in a Docker Container
To add a Flex Replica in a Docker Container you must run the Flex Gateway start command using the same `registration.yaml` file created during registration. If you are running the container locally, you will also need to use a different port.
### Start Command
Run the following start command in the same directory where you ran the registration command:
```
docker run --rm \
-v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \
-p 8080:8080 \
mulesoft/flex-gateway
```

Specify an optional name you want to assign to your Flex Replica by including the following: `-e FLEX_NAME=<name-for-flex-replica> \`.   
---  
Now if you check in Runtime Manager after clicking **Flex Gateway** in the left navigation, your Flex Gateway will have an additional replica listed. You may need to refresh the page.
TLS Configuration | MuleSoft Documentation
# TLS Configuration
Adding support for TLS configuration in your module is as simple as declaring a parameter of type `TlsContextFactory`, for example:
```
@Parameter
@Optional
private TlsContextFactory tlsContextFactory;
```

The example above will automatically generate support for this XML setting:
```
<tls:context enabledProtocols="TLSv1.2,SSLv3">
  <tls:trust-store path="my-trust-store.jks" password="myPassword"/>
  <tls:key-store path="my-key-store.jks" keyPassword="myPassword" password="myPassword"/>
</tls:context>
```

Note that a TLS context can also be defined as a global element of your app, so you can reference it by its name anywhere you need to use it.
If TLS needs are hidden from the user (for example, if you need to connect safely to a service internally), you can create your own `TlsContextFactory` using its builder:
```
private final TlsContextFactory tlsContextFactory = TlsContextFactory.builder()
                            .trustStorePath("tls/trustStore")
                            .trustStorePassword("mulepassword")
                            .build()
```

This builder also allows creating default instances of `TlsContextFactory`:
```
private final TlsContextFactory defaultTlsContextFactory = TlsContextFactory.builder().buildDefault();
```

Once a `TlsContextFactory` is available (whether as a parameter or obtained through its builder), it should be initialized, for example:
```
if (tlsContextFactory instanceof Initialisable) {
 ((Initialisable) tlsContextFactory).initialise();
}
```

It can then be used to obtain an `SSLContext`, a `SSLSocketFactory` or a `SSLServerSocketFactory`. It can also obtain enabled TLS protocols and cipher suites, allowing you to set up most Java components that use TLS/SSL as shown in the examples below.
You could set up a FTPSClient by obtaining an SSLContext and then configure the protocols and cipher suites for it:
```
SSLContext sslContext = tlsContextFactory.createSslContext();
String[] enabledProtocols = tlsContextFactory.getEnabledProtocols();
String[] enabledCiphers = tlsContextFactory.getEnabledCipherSuites();
FTPSClient client = new FTPSClient(sslContext);
client.setEnabledProtocols(enabledProtocols);
client.setEnabledCipherSuites(enabledCiphers);
```

You could obtain an SSLSocketFactory to create your own Socket:
```
SSLSocketFactory sslSocketFactory = tlsContextFactory.createSocketFactory();
Socket socket = sslSocketFactory.create();
```

To create a ServerSocketinstead, you can obtain an SSLServerSocketFactory:
```
SSLServerSocketFactory sslServerSocketFactory = tlsContextFactory.createServerSocketFactory();
ServerSocket socket = sslServerSocketFactory.createServerSocket();
```

To correctly configure TLS context and all the available parameters that you can set, see Configure TLS with Keystores and Truststores.
App Session | MuleSoft Documentation
# App Session
The _App Session_ action step is, similar to the Excel Session, an inclusive element for all App Automation action steps. These steps can only be placed within the App Session. All other action steps can also be inserted in the App Session.
Please note that an App Session **cannot** be added to another App Session.
## Properties
  * **Keep out mouse**
The mouse stays in the position specified in the _Move mouse to_ property, to avoid triggering hover effects inadvertently.
  * **Move mouse to**
Specifies the position where to keep the mouse when _Keep out Mouse_ is active. All four corners are available.
  * **Repeat keep mouse out**
Repeats the _Keep out mouse_ property before every step in the App Session. Note here that some action steps move the mouse for execution (such as click element with _Left Click_).


## Inbound Variables
The _App Session_ does not have any inbound variables.
## Outbound Variables
The _App Session_ does not have any outbound variables.
## Wizard
**Start Recording**
Enables you to record a single App Session by using the full functionality of RPA Recorder within RPA Builder. The button is only active if the App Session doesn’t contain any elements yet.
To record an App Session:
  1. Click **Start Recording** to open RPA Recorder. If you have another RPA Recorder instance in progress, you must end the other instance if you want to proceed.
  2. Click **Start Recording** to capture all actions, such as mouse movements and keystrokes.
  3. Use the Recording Toolbar to pause or stop the recording, take a screenshot, or add Image—​based mouse clicks or comments. Additional App Sessions cannot be added.
  4. After you stop the recording, the documentation shows in the **Review Recording** dialogue. Click **Finish** to keep the recording and return to RPA Builder. Click **Re-record** to replace the current recording with a new one. Click **Discard Recording** to cancel the recording and return to RPA Builder.
  5. Click **OK & generate** in RPA Builder to generate the appropriate action steps, which are added to the App Session automatically.
mapObject | MuleSoft Documentation
# mapObject
## mapObject<K, V>(@StreamCapable object: { (K)?: V }, mapper: (value: V, key: K, index: Number) -> Object): Object
Iterates over an object using a mapper that acts on keys, values, or indices of that object.
### Parameters
Name | Description  
---|---  
The object to map.  
Expression or selector that provides the `key`, `value`, or `index` used for mapping the specified object into an output object.  
### Example
This example iterates over the input `{ "a":"b","c":"d"}` and uses the anonymous mapper function (`(value,key,index) → { (index) : { (value):key} }`) to invert the keys and values in each specified object and to return the indices of the objects as keys. The mapper uses named parameters to identify the keys, values, and indices of the input object. Note that you can write the same expression using anonymous parameters, like this: `{"a":"b","c":"d"} mapObject { ($$$) : { ($):$$} }`
#### Source
```
%dw 2.0
output application/json
---
{"a":"b","c":"d"} mapObject (value,key,index) -> { (index) : { (value):key} }
```

#### Output
```
{ "0": { "b": "a" }, "1": { "d": "c" } }
```

### Example
This example increases each price by 5 and formats the numbers to always include 2 decimals.
#### Source
```
%dw 2.0
output application/xml
---
{
  prices: payload.prices mapObject (value, key) -> {
    (key): (value + 5) as Number {format: "##.00"}
  }
}
```

#### Input
```
<?xml version='1.0' encoding='UTF-8'?>
<prices>
  <basic>9.99</basic>
  <premium>53</premium>
  <vip>398.99</vip>
</prices>
```

#### Output
```
<?xml version='1.0' encoding='UTF-8'?>
<prices>
 <basic>14.99</basic>
 <premium>58.00</premium>
 <vip>403.99</vip>
</prices>
```

## mapObject(value: Null, mapper: (value: Nothing, key: Nothing, index: Nothing) -> Any): Null
Helper function that enables `mapObject` to work with a `null` value.
### Example
Using the previous example, you can test that if the input of the `mapObject` is `null`, the output result is `null` as well. In XML `null` values are written as empty tags. You can change these values by using the writer property `writeNilOnNull=true`.
#### Input
```
<?xml version='1.0' encoding='UTF-8'?>
<prices>
</prices>
```

#### Output
```
<?xml version='1.0' encoding='UTF-8'?>
<prices>
</prices>
```
Used Bot Minutes | MuleSoft Documentation
# Used Bot Minutes
In the **Used Bot Minutes** widget, you see how many minutes all bots have used in the selected time interval.
## Data Representation
The used bot minutes are displayed as a number.
## Configuration
This widget cannot be configured.
## Drill-down
This widget has no drill-down.
Salesforce Data Cloud 1.3 - Additional Configuration Information | MuleSoft Documentation
# Salesforce Data Cloud 1.3 - Additional Configuration Information
Configure Anypoint Connector for Salesforce Data Cloud (Salesforce Data Cloud Connector) to generate an OAuth 2.0 keystore file.
## Generate a Keystore File
Salesforce Data Cloud Connector uses the Bouncy Castle cryptographic library to load the certificate from the keystore and sign the payload for the authentication requests.
The Bouncy Castle library has a vulnerability (CVE-2018-5382) that relates to the BKS-V1 keystore file type, so do not use BKS-V1 keystore files, as documented in the Bouncy Castle proposed solution. By default, Salesforce Data Cloud Connector uses JKS or PKCS12 keystores.
To generate a JKS keystore file:
  1. Go to your Mule workspace and open the terminal or shell application for your operating system.
  2. Enter this command:
```
keytool -genkeypair -alias salesforce-cert -keyalg RSA -keystore salesforce-cert.jks
```

  3. Enter the following information:
     * Password for the keystore
     * Your first name and last name
     * Your organization unit
     * Your city and state, and the two-letter code for your country
The system generates a Java keystore file (JKS format) that contains a private or public key pair in your workspace.
  4. Provide the file path for the keystore in your connector configuration.
Enter this command:
```
keytool -exportcert -alias salesforce-cert -file salesforce-cert.crt -keystore salesforce-cert.jks
```

The system exports the public key from the keystore into the workspace. This is the public key to enter in your Salesforce instance.
  5. Verify that you have both the keystore (`salesforce-cert.jks`) and the public key (`salesforce-cert.crt`) files in your workspace.


## Next Step
After you complete configuring the connector, you can try the Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Configuring Security for Anypoint Platform PCE | MuleSoft Documentation
# Configuring Security for Anypoint Platform PCE
To use Anypoint Platform Private Cloud Edition (Anypoint Platform PCE), you must supply TLS credentials. Upload a certificate via the Anypoint Platform UI under **Access Management** , and configure the platform to use this certificate to secure communications. Ensure that every machine connected to the platform, including Mule runtime engine (Mule), trusts this certificate. Additionally, you have the option to specify custom ciphers and Diffie-Hellman (DH) groups for the key exchange method if needed.
When you replace or change the certificate, Anypoint Platform restarts the nginx server.
To configure the security, follow these steps:
  1. Create a certificate.
Generate your certificate using a tool like OpenSSL. To be compatible with Anypoint Platform, ensure your certificate is in an `nginx` friendly format. The certificate must include the domain name of your installation as both the Common Name (CN) and the Subject Alternative Name (SAN).
  2. From Anypoint Platform, select **Access Management**.
  3. Select **Security**.
  4. Under **Certificate** , select **Browse** to select the certificate on your local system.
  5. Under **Key** , select **Browse** to select the private key for your certificate.
  6. For additional security, you can upload your own cipher and Diffie-Hellman group file.
Note that this step is optional.
    1. Deselect **Use default ciphers and DH Group**.
    2. Enter a set of ciphers from the list of valid NGINX ciphers. If you are using Open SSL, you can view this list by running the `openssl ciphers` command. The cipher you enter must be in an `nginx` compatible format, for example:
```
ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384
```

    3. Generate `dhparam.pem` (the Diffie-Hellman group file) using the following `openssl` command:
```
openssl dhparam 2048 -out dhparam.pem
```

    4. Upload the `dhparam.pem` file from your system.


## See Also
  * Configuring Anypoint Platform PCE
Creating Custom Governance Rulesets | MuleSoft Documentation
# Creating Custom Governance Rulesets
MuleSoft provides several rulesets in Exchange, such as Anypoint API Best Practices, OpenAPI Best Practices, Authentication Security Best Practices, and Mule API Management Best Practices. Discover rulesets in Exchange by filtering the search by the **Rulesets** type. See Search for Assets.
Rulesets are implemented using AMF, an open-source framework for managing metadata documents. AMF parses, transforms, validates, and renders arbitrary metadata models, with built-in features for API models. Anypoint Platform uses AMF to parse RAML, OAS, AsyncAPI, and GraphQL API specifications.
If you need a ruleset other than those provided, you can create your own custom ruleset.
## Before You Begin
By writing your own rules, you can govern your APIs with your organization’s specific regulations and standards. Take some time to get familiar with the ruleset development CLI commands and ruleset language concepts before you start customizing rulesets.
You can also submit your ideas for rulesets you would like MuleSoft to provide in future releases on the MuleSoft Ideas Portal.
When you’re ready to get started:
  1. Read Custom Validation for a brief summary of how rulesets validate APIs.
  2. If you plan to create completely new custom rulesets that aren’t based on existing ones, follow the AMF Rulesets tutorial to install the ruleset development CLI.
  3. Install Anypoint CLI. You’ll need this to validate your custom rulesets, generate their documentation, and publish them to Exchange.


## Create a Custom Ruleset
To create a custom ruleset, use one of the following approaches:
  * Creating Custom Rulesets by Modifying Published Rulesets
  * Creating Completely New Custom Rulesets


After you modify or create a custom ruleset, you must validate it to ensure the code is correct, generate its documentation, and then publish it to Exchange. See Validating and Publishing Custom Rulesets.
## See Also
  * Anypoint API Governance Overview
CLI for Anypoint Runtime Fabric | MuleSoft Documentation
# CLI for Anypoint Runtime Fabric
Anypoint CLI supports managing these Runtime Fabric features:
  * Runtime Fabric App Management
  * Runtime Fabric Instances
Dropbox Connector 1.0 | MuleSoft Documentation
# Dropbox Connector 1.0
Anypoint Connector for Dropbox (Dropbox Connector) provides access to the Dropbox API.
For information about compatibility and fixed issues, refer to the Dropbox Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Dropbox Connector’s API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have:
  * Credentials to access the Dropbox target resource
  * Anypoint Platform
  * Anypoint Studio version 7.3.5 or later


## Connection Types
Dropbox connections use the Oauth 2.0 authentication type, which delegates user authentication to the service hosting the user account.
## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Dropbox Connector Reference
  * MuleSoft Help Center
Apache Cassandra Connector 4.1 Additional Configuration Information | MuleSoft Documentation
# Apache Cassandra Connector 4.1 Additional Configuration Information
Configure Anypoint Connector for Apache Cassandra (Apache Cassandra Connector) to work in your environment with basic authentication and DataSense functionality.
## Enable Apache Cassandra Authentication
By default, accessing the Apache Cassandra database does not require credentials. You need to configure Apache Cassandra to enable authentication. The Apache Cassandra Connector configuration must match the Apache Cassandra configuration for basic authentication.
After enabling authentication, run the `cqlsh` command from the Apache Cassandra installation home directory as shown in this example, which uses default credentials with username `cassandra` and password `cassandra`:
```
bin/cqlsh localhost -u cassandra -p cassandra
Connected to Test Cluster at localhost:9042.
[cqlsh 5.0.1 | Cassandra 3.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
```

  1. After installing Apache Cassandra, open the `conf\cassandra.yaml` file for editing.
  2. Optionally, change the value of `AllowAllAuthenticator` to `PasswordAuthenticator`.
  3. Restart Apache Cassandra.
  4. In a separate terminal tab, verify that Apache Cassandra is running:
`bin/nodetool status`


## POJO Configuration
The connector exposes multiple operations in the Apache Cassandra Connector Reference. The following operations accept some POJOs as input parameters, which are needed for the DataSense functionality:
  * `addNewColumn`
  * `changeColumnType`
  * `createKeyspace`
  * `createTable`
  * `deleteColumnsValue`
  * `deleteRows`
  * `dropColumn`
  * `dropKeyspace`
  * `dropTable`
  * `executeCQLQuery`
  * `getTableNamesFromKeyspace`
  * `renameColumn`


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Using Anypoint CLI with a Network Proxy | MuleSoft Documentation
# Using Anypoint CLI with a Network Proxy
Anypoint CLI can be run through a network proxy to add a layer of security. To use the Anypoint CLI with a proxy server, configure the `HTTP_PROXY` or `HTTPS_PROXY` environment variables with the hostname or IP addresses of your proxy servers as shown in the following sections. Use the `ANYPOINT_CERTIFICATE` variable to configure your trusted certificates required by proxy.
## Configure a Proxy Server Without Authentication
To configure a proxy server that does not require authentication, use the following commands:
  * Linux, macOS, or Unix
`$ export HTTP_PROXY=http://_proxy-server_:80`
`$ export HTTPS_PROXY=https://_proxy-server_:443`
  * Windows
`> set HTTP_PROXY=http://_proxy-server_:80`
`> set HTTPS_PROXY=https//_proxy-server_:443`


## Configure a Proxy Server With Authentication
To configure a proxy server that requires authentication, use these commands:
  * Linux, macOS, or Unix
`$ export HTTP_PROXY=http://_username_:_password_@_proxy-server_:80`
`$ export HTTPS_PROXY=https://_username_:_password_@_proxy-server_:443`
  * Windows
`> set HTTP_PROXY=http://_username_:_password_@_proxy-server_:80`
`> set HTTPS_PROXY=https://_username_:_password_@_proxy-server_:443`
Securing Agent Interactions with Flex Gateway | MuleSoft Documentation
# Securing Agent Interactions with Flex Gateway
Flex Gateway supports both the Model Context Protocol (MCP) and the Agent2Agent (A2A) Protocol, enabling you to protect your agents and systems. Flex Gateway provides centralized oversight, agent visibility, logging, and valuable insights, ensuring effective governance and security for your agent-based architecture. Flex Gateway secures agent interactions by enforcing policies across agent connections and by monitoring agent activities for enhanced visibility.
## Flex Gateway A2A Support
A2A is an open standard that defines how agents interact with each other, enabling interoperability for agents built by different teams, using different technologies and hosted by different organizations.
Flex Gateway protects agent A2A interactions by requiring appropriate authentication and authorization for agent requests, rewriting Agent Card URLs, logging or blocking sensitive information in messages, and logging Server-Sent Events (SSE) content for compliance audits. You can enhance agent requests by modifying incoming prompts with additional context to improve server-agent execution.
## Flex Gateway MCP Support
MCP is an open protocol that defines how agents interact with tools or external context, enabling agents to connect to the data and tools they need.
Flex Gateway secures MCP connections by restricting MCP endpoint access to authorized agents only and by simplifying governance through centralized visibility and control over all interactions.
## Securing Agent Interactions with Policies
Flex Gateway includes A2A and MCP specific policies that provide enhanced security and control over agent interactions. Flex Gateway A2A policies enable you to protect agent endpoints by rewriting Agent Card URLs, logging or blocking sensitive information in messages, modifying prompt behavior, and logging Server-Sent Events (SSE) content for compliance audits. Flex Gateway MCP policies enable you to use attribute-based access control to manage access to MCP servers.
Flex Gateway MCP and A2A server instances also support Flex Gateway’s other policies. For example, use policies such as Rate Limiting Policy or Spike Control Policy to manage the number of requests to MCP and A2A servers or use the Message Logging Policy to monitor agent interactions.
See Flex Gateway Agent Policies to learn about included A2A and MCP policies.
## See Also
  * Introducing Governance for Agent Interactions With Support for A2A & MCP
  *   *   * Streaming & Asynchronous Operations in A2A
MuleSoft Automation Credits 1.0 | MuleSoft Documentation
# MuleSoft Automation Credits 1.0
Your MuleSoft Automation subscription plan includes a quota of Automation Credits that you can use with MuleSoft Composer, MuleSoft IDP, MuleSoft RPA, or a combination of these products. As you use processes to create automations, your total credit quota is depleted.
The following table shows the conversion rate between Automation Credits and different activities:
RPA Bot Minutes | RPA API Calls | Composer Tasks | IDP Document Pages  
---|---|---|---  
1 MuleSoft Automation Credit = 2 | 1 MuleSoft Automation Credit = 100 | 1 MuleSoft Automation Credit = 50 | 1 MuleSoft Automation Credit = 6  
MuleSoft adds all the RPA execution times in seconds for the period and converts the total into minutes with two decimal precision. MuleSoft reports Automation Credits with two decimal precision.
For example, if you run 5 processes that take 30 seconds each to execute: MuleSoft converts the total execution time (150 seconds) to minutes, rounds up the last two digits: 150/60 = 2.5 minutes, and then converts the minutes to Automation Credits and rounds up the last two digits: 2.5/2 = 1.25 credits.
You can use any combination of these activities, which aggregate over the term of your subscription (not per session), and are then converted to credits as shown. Then, the credits are deducted from your assigned quota for the subscription period.
For detailed definitions and more information, see the MuleSoft Product Subscription Plans.
## See Also
  * Automation Credits Usage and Rates
  *   * Monthly Account Summary Emails
Amazon Secrets Manager Properties Provider 1.0 Reference | MuleSoft Documentation
# Amazon Secrets Manager Properties Provider 1.0 Reference
Amazon Secrets Manager Properties Provider is a configuration that enables you to retrieve your secrets from Amazon Secrets Manager cloud service before your Mule app runs.
## Configuration
Default Configuration for Amazon Secrets Manager Properties Provider.
Name | Type | Description | Default Value | Required  
---|---|---|---|---  
Name for this configuration. Connectors reference the configuration with this name.  
**Expiration Policy** |  Expiration Policy |  Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration. This does not mean that the instance expires at the exact moment that it becomes eligible. Mule purges the instances as appropriate.  
**AWS Secrets Manager Region** |  AWS Secrets Manager region, for example, `us-east-2`.  
**AWS Access Key** |  AWS access key ID.  
**AWS Secret Key a** |  AWS secret key ID.  
Uniquely identifies a role to gain cross-account access.  
## Types
### Expiration Policy
Field | Type | Description | Default Value | Required  
---|---|---|---|---  
Max Idle Time | Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.  
Time Unit |  Enumeration, one of:
  * NANOSECONDS
  * MICROSECONDS
  * MILLISECONDS
  * SECONDS
  * MINUTES
  * HOURS

| Time unit for the **Max Idle Time** field.  
## Limitations
Amazon Secrets Manager Properties Provider doesn’t support the use of property files for the configuration of the properties provider.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Activity Library Explorer | MuleSoft Documentation
# Activity Library Explorer
In the Activity Library Explorer, you can view all the activity templates assigned to your organization. All users in your organization with the privilege **Activity Library Administration** have access to the same Activity Library.
If another user adds an activity, click **Refresh** () to update the Activity Library Explorer and see the changes.
To view an outline of a workflow, select an activity and click **Show Outline** ().
To see all revisions of an activity, select the activity and click **Show Log** ().
You can create and assign Activity Tags to your activities by clicking **Manage Activity Tags** ().
## Edit, Copy, and Delete Activities
To open the individual editing mode of an activity and make changes to it, select an activity and click **Edit** ().
To make a copy of an activity, select it and click **Copy** () **Copy**. By default, this process copies all information such as name, description, and activity tags. During the upload, the Activity Library prefixes the activity name with _Copy of_. You can edit this information later, if required.
To delete an activity, select it and click **Delete from Library** () **Delete from Library**.
## Import and Export Activities
The Activity Library enables you to export activities to a package file `(.calw)` and import these activity package files into the Activity Library.
To export an Activity Library Workflow from the Activity Library to your file system as a `(.calw)` package file, click **Export**(). When you export Activity Library workflows to a file, RPA Builder removes passwords and all sensitive information stored in wizards of action steps, User Account Variables, and Activity Parameters (for example, secrets in OAuthCredentials or AWS Credentials) to prevent this information from being shared.
To import an Activity Library Workflow package `(.calw)` file from your file system to the Activity Library, click **Import** ().
## See Also
  * Using the Activity Library
  *   * RPA Manager: Upcoming Process Changes
Accessibility | MuleSoft Documentation
# Accessibility
All Anypoint API Community Manager components, including both components provided by MuleSoft and components in Salesforce Experience Cloud, comply with the Web Content Accessibility Guidelines (WCAG) 2.1 AA-level accessibility standard and enable the creation of sites compliant with this standard and level.
Because MuleSoft customers design and brand their API communities, accessibility assessment for sites built with API Community Manager depends on the customer’s choice of design, structure, visual, user interface, and behavior elements. Customers are responsible for accessibility assessment of these aspects in their specific community.
The API Community Manager community template for the fictional company Northern Trail Outfitters (NTO) is provided only as an example. It is not intended for customers to use as-is for their live communities. This template has not been assessed for accessibility.
## See Also
  * Accessibility in Salesforce Experience Cloud: Salesforce Product Accessibility Status
  * Web Content Accessibility Guidelines (WCAG) 2.1
Amazon Redshift Connector 1.1 | MuleSoft Documentation
# Amazon Redshift Connector 1.1
Anypoint Connector for Amazon Redshift (Amazon Redshift Connector) is a bulk-load connector that enables you to connect to Amazon Redshift database to perform inserts, deletes, updates, and to execute SQL queries.
For compatibility information and fixed issues, see the Amazon Redshift Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Amazon Redshift API
  * Anypoint Connectors
  * Mule runtime (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Credentials to access the Amazon Redshift target resource
  * Anypoint Platform
  * Anypoint Studio 7.3 or later


## Common Use Cases for the Connector
Some possible uses for this connector include:
  * Analytics
Amazon Redshift operates as an optimized data warehouse that can store large volumes of data, which can then be analyzed using a business intelligence (BI) tool such as Tableau.
  * Real-time processing of social media feeds
Stream data from your social media feeds, such as a Twitter feed, into Amazon Kinesis Data Streams, and then store that data in a data warehouse, such as Amazon Redshift to perform real-time analytics.


## Authentication Types
Amazon Redshift Connector uses the following connection methods:
  * Basic authentication, which uses **user** and **password** field values to connect to the database
  * IAM authentication, which uses **access key** and **secret key** field values to retrieve the temporary password for the specified user in order to connect to the database


## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Amazon Redshift Reference
  * MuleSoft Help Center
NetSuite Connector 10.0 | MuleSoft Documentation
# NetSuite Connector 10.0
Anypoint Connector for NetSuite (NetSuite Connector) synchronizes data and automates business processes between NetSuite and third-party applications, either on-premises or in the cloud. NetSuite provides cloud-based business management software that helps companies manage core business processes, ERP financials, CRM, e-commerce, inventory, and more.
NetSuite Connector provides the following features:
  * SOAP-based integration
  * Generation of NetSuite business objects
  * Different authentication levels
  * Error-handling support
  * Access to NetSuite using REST calls to RESTlets that expose APIs created with SuiteScript


For compatibility information and fixed issues, see the NetSuite Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The NetSuite API
  * Anypoint connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * How to create a Mule app using Anypoint Studio


You must also have a NetSuite account with the Web Services features enabled.
## Audience
  * New user
To create your Mule app, see Studio Configuration.
  * Advanced user
    * Try the NetSuite examples.
    * To develop the connector as a standalone application, see XML and Maven Support.


## See Also
  * Introduction to Anypoint Connectors
  * NetSuite Connector on Exchange
  * Use Exchange to Discover Connectors, Templates, and Examples
  *   * MuleSoft Help Center
Include XML Namespaces | MuleSoft Documentation
# Include XML Namespaces
You can define different namespaces in the header and then reference them on each tag.
Starting in the Mule 4.2.1 release, DataWeave also supports dynamically generated namespace keys and attributes.
The following example uses:
  * `ns` for namespace definitions in the header
  * `@` to define other attributes in an XML element


DataWeave Script:
```
%dw 2.0
output application/xml
ns orders http://www.acme.com/shemas/Orders
ns stores http://www.acme.com/shemas/Stores
---
root:
  orders#orders: {
    stores#shipNodeId: "SF01",
    stores#shipNodeId @(shipsVia:"LA01"): "NY03"
  }
```

Output XML:
```
<?xml version='1.0' encoding='UTF-8'?>
<root>
 <orders:orders xmlns:orders="http://www.acme.com/shemas/Orders">
  <stores:shipNodeId xmlns:stores="http://www.acme.com/shemas/Stores">SF01</stores:shipNodeId>
  <stores:shipNodeId xmlns:stores="http://www.acme.com/shemas/Stores" shipsVia="LA01">NY03</stores:shipNodeId>
 </orders:orders>
</root>
```

## Dynamically Generated Namespace Values
_Support starting in Mule version 4.2.1_
Using input defined in the DataWeave variables, the DataWeave functions in the following example output values for namespace keys and attributes.
DataWeave Script:
```
%dw 2.0
fun dynKeyNs(ns0: Namespace, value: Any) = { ns0#myDynKey: value }
fun dynAttrNs(ns0: Namespace, value: Any) = { myChildTag @(ns0#myDynAttribute: true): value }
var namespace1 = {uri: "http://acme.com", prefix: "ns0"} as Namespace
var namespace2 = {uri: "http://emca.com", prefix: "ns0"} as Namespace
output application/xml
---
root:
{
 mytagA: dynKeyNs(namespace1, "myTest1"),
 myTagB: dynKeyNs(namespace2, "myTest2"),
 myTagC: dynAttrNs(namespace1, "myTest1"),
 myTagD: dynAttrNs(namespace2, "myTest2")
}
```

Output XML:
```
<?xml version='1.0' encoding='UTF-8'?>
<root>
 <mytagA>
  <ns0:myDynKey xmlns:ns0="http://acme.com">myTest1</ns0:myDynKey>
 </mytagA>
 <myTagB>
  <ns0:myDynKey xmlns:ns0="http://emca.com">myTest2</ns0:myDynKey>
 </myTagB>
 <myTagC>
  <myChildTag xmlns:ns0="http://acme.com" ns0:myDynAttribute="true">myTest1</myChildTag>
 </myTagC>
 <myTagD>
  <myChildTag xmlns:ns0="http://emca.com" ns0:myDynAttribute="true">myTest2</myChildTag>
 </myTagD>
</root>
```

## Use XML Namespace with Hyphen Character
The following DataWeave script shows you how to define an XML namespace as an object, which enables you to use special characters such as hyphen (`-`) in the namespace definition:
DataWeave Script:
```
%dw 2.0
output application/xml
var myNS = {uri: "http://www.abc.com", prefix: "ns-0"} as Namespace
---
{myNS#bla : "dw"}
```

Output XML:
```
<?xml version='1.0' encoding='UTF-8'?>
<ns-0:bla xmlns:ns-0="http://www.abc.com">dw</ns-0:bla>
```

## Related Examples
  * Output Self-closing XML tags
  * Insert an Attribute into an XML Tag


## See Also
  * DataWeave Selectors
  *