BassemE/mulesoft-documentation-embeddings huggingface dataset:
Write a File Using the FTP Connector Example | MuleSoft Documentation
# Write a File Using the FTP Connector Example
Anypoint Connector for FTP (FTP Connector) provides a **Write** operation that writes content into the given path on demand.
## Configure the Write Operation in Studio
To add and configure the **Write** operation in Studio, follow these steps:
  1. In the **Mule Palette** view, search for `ftp` and select **Write**.
  2. Drag the **Write** operation onto the Studio canvas.
  3. In the **General** tab of the operation configuration screen, click the plus sign (+) next to **Connector configuration** to access the global element configuration fields.
  4. Specify the connection information and click **OK**.
  5. In the **General** tab, set **Path** to `output.csv` to set the path of the file to write. By default, the connector writes whatever is in the message payload.


In the **Configuration XML** editor, the `<ftp:write>` configuration looks like this:
```
<ftp:write path="output.csv" />
```

## Use Embedded DataWeave Transformations
If you place a **Transform Message** component before a **Write** operation, the message payload changes, and that impacts the operation that is placed after the **Write** operation. Therefore, if the payload is in a different format and you need to transform it before writing it, you can place the transformation inside **Content** in the **Write** configuration to generate the content to be written without affecting the message in transit.
The following example places the **DataWeave** transformation in **Content** :
In the **Configuration XML** editor, the configuration looks like this:
```
<ftp:write path="output.csv">
 <ftp:content>#[%dw 2.0
          output application/csv
          ---
          payload.customers.email
         ]
 </ftp:content>
</ftp:write>
```

## Write into a Directory
The **Write** operation fails by default if you set nonexistent directories in **Path**. Set **Create parent directories** to **True (Default)** to automatically create any missing directories.
In the following example, if any of the `a`, `b`, or `c` directories set in **Path** do not exist, the connector creates them:
In the **Configuration XML** editor, the configuration looks like this:
```
<ftp:write path="a/b/c/myFile.txt" />
```

## Write to Existing Files
When writing content to a file, set **Write Mode** to any of the following modes:
  * **OVERWRITE (Default)** If the file exists, overwrite it completely.
  * **APPEND** If the file exists, add its content to the end of an existing file.
  * **CREATE_NEW** Create a new file. An error occurs if the file already exists.


## Locks
The **Write** operation supports locking similar to the **Read** operation. The main difference is that the lock releases automatically after the **Write** operation finishes. Set **Lock** to either of the following modes:
  * **FALSE (Default)**


## See Also
  * FTP Connector Examples
  * MuleSoft Help Center
CloudHub Release Notes | MuleSoft Documentation
# CloudHub Release Notes
  *   * CloudHub Runtime and OS Release Notes
  * CloudHub Dedicated Load Balancer Release Notes
  * Anypoint VPN Updates Release Notes
FTPS Connector | MuleSoft Documentation
# FTPS Connector
Support Category: Premium
Anypoint Connector for FTPS (FTPS Connector) connects to FTP servers the same way as the FTP Connector but adds support for Transport Layer Security (TLS).
## 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
  * FTPS Connector Reference
  * MuleSoft Help Center
Configuring a Liveness Check in Connected Mode | MuleSoft Documentation
# Configuring a Liveness Check in Connected Mode
Flex Gateway includes the following CLI command to test gateway health:
```
flexctl probe --check=liveness
```

If the Flex Gateway instance is running normally, the command returns an exit code of `0`. Otherwise, the gateway is unhealthy and the command returns a `1`.
You can either run the liveness check command manually or configure the command to run automatically. By default, Flex Gateways deployed on Kubernetes have an automatic liveness probe configured. The liveness probe periodically runs the liveness check command and automatically restarts the Flex Gateway pod after a specified number of failed liveness checks.
Docker and Linux deployments do not have preconfigured liveness probes.
## Before You Begin
  1. Download Flex Gateway.
  2. Register and Run Flex Gateway.


## Configure a Kubernetes Liveness Probe
By default, Flex Gateways running on Kubernetes include a liveness probe configured in the Helm chart. The liveness probe automatically runs `flexctl probe --check=liveness` at an interval of 10 seconds and restarts unhealthy pods after 5 failed tests.
The liveness probe is configured by default with the following values:
```
livenessProbe:
 exec:
  command:
  - flexctl
  - probe
  - --check=liveness
 initialDelaySeconds: 10
 periodSeconds: 10
 failureThreshold: 5
 timeoutSeconds: 1
```

Parameter | Description  
---|---  
`exec.command` | The liveness check command  
`initialDelaySeconds` | The time in seconds to wait after startup before executing the first liveness test  
`periodSeconds` | The period in seconds between each liveness check  
`failureThreshold` | The number of failed liveness tests before the Kubernetes pod is restarted  
`timeoutSeconds` | The time in seconds before the test times out  
To modify the default liveness probe parameters, you must update your Helm chart. You can modify these parameters during or after the initial installation of the Helm chart. For more information about how to modify a Helm chart, see Update Pod Settings for a Flex Gateway Deployment Through a Helm Chart
## Docker and Linux Liveness Probes
For Docker or Linux deployments, there is no default liveness probe configured to check health or restart unhealthy Flex Gateways. However, you can still run the liveness check command manually or configure it for automated use with third-party services. Besides the Kubernetes liveness probe, MuleSoft does not provide support for third-party liveness probes or health checks.
One method of running the liveness check command with Docker is to configure `HEALTHCHECK` in your `docker run` command. For more information, see Docker run HEALTHCHECK.
## See Also
  * Configure Liveness, Readiness and Startup Probes.
  *
Database Connector 1.11 | MuleSoft Documentation
# Database Connector 1.11
Anypoint Connector for Database (Database Connector) establishes communication between your Mule app and a relational database. Database Connector can connect to almost any Java Database Connectivity (JDBC) relational database and run SQL operations. An application can support multi-tenant scenarios using the same configuration element, changing the connection attributes based on, for example, information coming from each request.
Database Connector has connection providers that automatically set the driver class name and create JDBC URLs with given parameters for the following databases:
  * Derby
  * Microsoft SQL Server
  * MySQL
  * Oracle


You can set up other JDBC databases using a generic JDBC configuration. Database Connector is JDBC compliant. Ensure that for the connection configuration, you use a driver that is compliant with JDBC to avoid compatibility issues. Additionally, you can reference a JDBC `DataSource` object or an `XADataSource` object, which is required for XA transactions, by creating the object in Anypoint Studio using Spring.
## 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 the database target resource, Anypoint Platform, and have downloaded the proper database driver for your database.
## Common Use Cases for the Connector
Database Connector enables you to:
  * Perform predefined queries, dynamically constructed queries, and template queries that are self-sufficient and customizable.
  * Specify DataWeave expressions in connector fields and configure attributes dynamically, depending on the database configuration you use.
  * Use a source listener operation to read from a database in the data source section of a flow.
  * Execute other operations to read and write to a database anywhere in the process section.
  * Perform multiple SQL requests in a single bulk update.
  * Make Data Definition Language (DDL) requests that alter the data structure rather than the data itself.
  * Execute stored procedures and SQL scripts.


For examples, see Examples.
## Using Exchange Templates and Examples
Anypoint Exchange provides templates that you can use as starting points for your apps and examples that illustrate a complete solution.
  * Database Connector Examples
  * Database Connector Templates


## Next Step
After you complete the prerequisites and try the templates and examples, you are ready to create your own app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Managing Client Applications and Contracts | MuleSoft Documentation
# Managing Client Applications and Contracts
Client applications and contracts requested through API Experience Hub are created in API Manager. Depending on the SLA tier configuration, they’re approved automatically or they require approval by the owner of the API or API Group. To review and approve contracts, refer to the API Manager documentation.
## See Also
  *
years | MuleSoft Documentation
# years
## years(nYears: Number): Period
Creates a Period value from the provided number of years.
The function applies the `period` function to the input value.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
A whole number for the number of years. A positive or negative number is valid.  
### Example
This example shows how `years` behaves with different inputs. It adds a year to a DateTime value, and it converts the whole number 4 into a number of years in the Period format (`P4Y`). Notice that `years(-1) + years(2)` returns the number of months.
#### Source
```
%dw 2.0
import * from dw::core::Periods
output application/json
---
{
 nextYear: |2020-10-05T20:22:34.385Z| + years(1),
 fourYearPeriod: years(4),
 addNegativeValue: years(-1) + years(2)
}
```

#### Output
```
{
  "nextYear": "2021-10-05T20:22:34.385Z",
  "fourYearPeriod": "P4Y",
  "addNegativeValue": 12
}
```
Set Reader and Writer Configuration Properties | MuleSoft Documentation
# Set Reader and Writer Configuration Properties
DataWeave provides configuration properties for data formats, such as JSON (`application/json`), XML (`application/xml`), and (`application/csv`). The properties change the behavior of DataWeave readers and writers for those formats. For example, the default separator for a CSV reader is a comma (`,`). You can use the format’s `separator` property to specify a different separator for CSV content.
Refer to DataWeave Formats for more details on available reader and writer properties for various data formats.
## Use a Writer Property in an Output Directive
The following example shows how to append writer properties to the DataWeave `output` directive. The script uses `indent = false` to compress the JSON output into a single line.
DataWeave Script:
```
%dw 2.0
output application/json indent = false
---
{
	hello : "world",
	bello : "world",
	mello : "world"
}
```

Output JSON:
```
{"hello": "world","bello": "world","mello": "world"}
```

The following examples also append writer configuration properties to the `output` directive:
  * Avro example that uses `schemaUrl`
  * Excel (XLSX) example that uses `header=true`
  * Flat File example that sets a `schemaPath`
  * XML example that uses `inlineCloseOn="empty"` to close any empty XML elements


## Use Reader and Writer Properties in DataWeave Functions
The DataWeave `read`, `readUrl`, and `write` functions accept one or more comma-separated property configurations within curly braces.
In the header of the following script, the value of `myVar` is a `read` function that inputs an XML sample with an empty child element (`<ex1></ex1>`). The function passes an XML reader property `{nullValueOn: "empty"}` that converts the value of the empty element to `null`.
In the body of the script, a `write` function accepts the value of `myVar` as input. The function passes the JSON writer properties `{skipNullOn:"objects", writeAttributes:true}` to skip the object with the `null` value (`<ex1>null</ex1>`) and to write the attribute and value of `<ex3 a='greeting'>hello</ex3>`.
DataWeave Script:
```
%dw 2.0
var myVar = read("<greeting><ex1></ex1><ex2>hello</ex2><ex3 a='greeting'>hello</ex3></greeting>", "application/xml", {nullValueOn: "empty"})
output application/json with binary
---
write(myVar.greeting, "application/json", {skipNullOn:"objects", writeAttributes:true})
```

Output JSON:
```
{
 "ex2": "hello",
 "ex3": {
  "@a": "greeting",
  "__text": "hello"
 }
}
```

The following examples pass reader properties to `readUrl`:
  *   * 

## See Also
  *   *   *
Core Processors | MuleSoft Documentation
# Core Processors
Configure message and event processing in an integration application or API implementation. Core processors (also called Mule components) run on the Mule runtime engine.
  *   * Cache Scope (<ee:cache/>)
  *   * Custom Event (<tracking:custom-event/>)
  * Dynamic Evaluate (<ee:dynamic-evaluate/>)
  * Error Handler (<error-handler/>)
Includes On-Error Continue (`<on-error-continue/>`) and On-Error Propagate (`<on-error-propagate/>`)
  * First Successful (<first-successful/>)
  *   * Flow Reference (<flow-ref/>)
  * For Each (<foreach/>)
  * Idempotent Message Validator (<idempotent-message-validator/>)
  * Invalidate Cache (<ee:invalidate-cache/>)
  * Invalidate Key (<ee:invalidate-key/>)
  * Logger Component (<logger/>)
  * Parallel For Each (<parallel-foreach/>)
  * Parse Template (<parse-template/>)
  * Raise Error (<raise-error/>)
  * Remove Variable (<remove-variable/>)
  * Round Robin (<component-xml-root/>)
  * Scatter-Gather (<scatter-gather/>)
  * Scheduler (<scheduler/>)
  * Set Payload (<set-payload/>)
  * Set Variable (<set-variable/>)
  * Subflow (<sub-flow/>)
  * Transaction (<tracking:transaction/>)
  * Transform (<ee:transform/>)
  *   * Until Successful (<until-successful/>)
What’s New in DataWeave | MuleSoft Documentation
# What’s New in DataWeave
DataWeave 2.4 is bundled with Mule 4.4. The 2.4 version of DataWeave introduces the following features:
  * Ability to read larger-than-memory strings automatically. When you are using the indexed reader strategy and processing a String with a size larger than 1.5 MB, DataWeave automatically splits the value in chunks to avoid out-of-memory issues. Related reader properties are `com.mulesoft.dw.max_memory_allocation` and `com.mulesoft.dw.buffered_char_sequence.enabled`. Refer to Indexed Readers in DataWeave.
  * New reader and writer properties for working with data formats. For example, the XML writer now enables you to define namespaces at the root level.
  * Many new modules, functions, types, annotations, and variables. Some are experimental and subject to change in future releases.
  * A number of functions are overloaded to introduce new helper functions for handling `null` values.


Changes to the documentation include more detailed function signatures and organization of the functions by their module names, such as `dw::Core`, `dw::core::Strings`, and `dw::util::Math`.
DataWeave 2.4 is bundled with Mule 4.4. For information about the Mule 4.4 release, refer to What’s New in Mule 4.4.
## New Properties for Data Formats
DataWeave introduces the following reader and writer properties:
  * DataWeave (dw) reader property: `privileges` enables you to provide a comma-separated list of privileges to use in the format, such as `'Resources,Properties'`.
  * Excel (XLSX) reader property: `tableLimit` enables you to set position of the last column in each row.
  * YAML writer property: `writeDeclaration` enables you to write the header declaration.
  * XML writer properties: `defaultNamespace` specifies the default namespaces of the output XML , and `writeDeclaredNamespaces` marks the namespaces to declare in the root element of the XML.


## New DataWeave Function Modules and Features
New DataWeave modules and features:
  * dw::Core introduces new functions and annotations:
    *     * Core Annotations introduces a number of new annotations.
  * dw::core::Dates is a new module with functions and types to create and manipulate Date types, for example, the function `today`.
  * dw::core::Strings introduces new functions:
    *     *     *     *     *     *     *     *   * dw::util::Coercions is a new DataWeave module with functions and types to simplify data type transformations, for example, the function `toString`.
  * dw::util::Math is a new DataWeave module with functions and variables that provides mathematical functions, for example, the function `sin`.
  * dw::util::Periods is a new DataWeave module with functions and types to simplify the creation of Periods, for example, the function `days`.
  * dw::util::Tree introduces new functions:
    *     *     *     *     *   * dw::util::Values provides a new type `UpdaterValueProvider`.
Monitor Applications and Servers | MuleSoft Documentation
# Monitor Applications and Servers
Private Cloud Edition  Runtime Fabric 
After you deploy your application, use the monitoring dashboards in Runtime Manager to monitor the application’s performance. If you deployed the application to an on-premises server, you can also monitor the server.
Depending on the deployment option you use, different monitoring resources are available, including alerts, dashboards, notifications, and flow metrics.
For CloudHub 2.0 deployments, the Runtime Manager monitoring feature is available for applications only. For more information, see Monitoring Apps Deployed to CloudHub 2.0.   
---  
## Monitoring Servers
On applications that are deployed on-premises, use the following tools to get information about the servers.
  * Send e-mail alerts whenever key events occur. A history of when these alerts were triggered can also be accessed.
  * See the evolution of key performance metrics related to service usage and available processing power
To use Runtime Manager monitoring dashboards when running Mule on Windows, the Mule service must be started by a user that belongs to the **Performance Log Users** group.   
---  


## See Also
  * Monitoring Dashboards
  *   *   * Notifications on Runtime Manager
  * Custom Application Alerts and Notifications
  *   * Manage Deployed Applications
  *
Impaired Worker Monitoring | MuleSoft Documentation
# Impaired Worker Monitoring
CloudHub continuously verifies the health of the workers running Mule applications.
When a worker is impaired by hardware or software failures, including network unavailability, memory issues, server hardware failures, or file corruption, CloudHub automatically attempts to restart the app on a new worker.
Because CloudHub replaces impaired workers on a fixed schedule, which depends on the underlying infrastructure, you might experience a delay between the time the new worker starts and when it starts sharing the load. As long as the app is running on multiple workers, this delay shouldn’t impact the application.
After the app is completely up and running, CloudHub switches the traffic to the new app instance and deletes the old app instance, ensuring zero downtime.
If the application fails to start after five attempts, its status is **Failed** or **Unrecoverable Runtime Error** and you must manually restart the application.
You see a notification indicating that the automatic restart occurred. The application log indicates when an app is restarted automatically and any failures. For example:
```
Your application was running on an impaired worker instance. To avoid any downtime, the platform has restarted the application.
```

The automatic worker-restart functionality is different from the automatic application-restart functionality, which is configurable using the **Automatically restart application when not responding** option on the **Settings** page for the app. CloudHub automatically attempts to restart impaired workers, regardless of the application-restart setting.   
---  
## Scheduled Maintenance Activities
CloudHub checks for these scheduled maintenance activities on the worker infrastructure that can cause potential downtime for the running applications: reboot, stop, start, or replacement of the instances. To ensure zero downtime, CloudHub schedules the app to restart automatically on a new worker before the maintenance occurs.
You can restart your apps manually at your convenience or let CloudHub restart the app automatically.
One month before the scheduled restart, the notification (bell) icon in the top right of both the **Applications** page and the **Settings** page for the application turns red to indicate that you have a new notification:
Figure 1. The arrow shows the notification icon on the **Settings** page for the application.
Click the icon to display the notification, which includes the date that CloudHub will automatically restart the worker.
CloudHub displays a reminder notification one week before automatic application restart.
## See Also
  * Notifications on Runtime Manager
  * Application Monitoring and Automatic Restarts
  * Manage Deployed Applications
Introduction to Mule 4: Configuring Mule Apps | MuleSoft Documentation
# Introduction to Mule 4: Configuring Mule Apps
In Mule 3, Spring property placeholders are often used to configure apps dynamically for the environment in which they are deployed. Mule 4 contains a built-in mechanism for this that allows you to set default values and avoid the need to learn Spring.
These properties are stored in a YAML file:
```
http:
 path: service
 port: "10000"
```

You can add the YAML file to your Mule app through the Global Element called Configuration Properties. The XML for it looks like this:
```
<configuration-properties file="myConfiguration.yaml" />
```

MuleSoft highly recommends that you do not package the configuration files for all the environments inside your app. Instead, you should use this file to provide defaults, then use Runtime Manager to override each of these properties at deployment time.
## See Also
Configure Properties
Upgrading MCP Connector to Version 1.1 | MuleSoft Documentation
# Upgrading MCP Connector to Version 1.1
MCP Connector 0.1.0-BETA is deprecated. Use MCP Connector 1.x instead. MCP Connector 1.x is not backward-compatible with the 0.1.0-BETA version of this connector.
## Supported Upgrade Paths
From Version | To Version  
---|---  
## Changes in 1.1
  * A **Default Request Headers** parameter is added to both the SSE Client and Streamable Http Client connection types within the MCP Client configuration. This parameter lets you specify custom headers to send with every request to the MCP server.


## Changes in 1.0
This release contains the following changes:
  * Streamable HTTP Transport
Support for Streamable HTTP transport is added. This transport method replaces the deprecated SSE transport for better scalability and cloud compatibility.
  * Custom Response Headers
Added support for custom headers on all exposed endpoints.
  * Enhanced Error Handling
Improved error handling with specific error types and better error messages.
  * Performance Improvements
Added caching support and timeout configurations.
  * Input Validation
Enhanced parameter validation with JSON schema constraints.
  * These new types are added:
    * Call Tool Response
    * Resource Content
    * Resource Metadata
    * Tool Metadata
    * New Session Request
    * Resource Request
    * Text Tool Response Content
    * Text Resource Tool Response Content
    * Blob Resource Tool Response Content
    * Blob Resource
  * The `mule.http.service.implementation=NETTY` property is no longer required and must be removed.
  * The `<mcp:resource-content>` element under `<mcp:resource-listener>` is renamed to `<mcp:resource-listener-content>`. If you used the 0.1.0-BETA version of this connector, you must manually rename the element in the connector’s configuration XML.


## Removed Features
  * The `<mcp:resource-capabilities>` and `<mcp:tool-capabilities>` configuration attributes are removed.
  * The `<mcp:add-dynamic-resource>` operation is removed. The MCP server always advertises itself as non-dynamic.


## Update the POM File Dependency
If you are using MCP Connector 0.1.0-BETA, you must update your POM file dependency to:
```
<dependency>
 <groupId>com.mulesoft.connectors</groupId>
 <artifactId>mule-mcp-connector</artifactId>
 <version>1.0.0</version>
 <classifier>mule-plugin</classifier>
</dependency>
```

Note that the `<groupId>com.mulesoft.connector</groupId>` is changed so that `connector` is now plural `connectors`.
## Remove the NETTY Property
If you used the 0.1.0-BETA version of MCP Connector and added the `-Dmule.http.service.implementation=NETTY` property, remove it anywhere you added it, including the:
  * `AnypointStudio.ini` file
  * Debug configuration
  * Apps' properties


## See Also
  * MCP Connector Reference
  * MCP Connector Examples
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Azure Service Bus Management 1.0 Additional Configuration Information | MuleSoft Documentation
# Azure Service Bus Management 1.0 Additional Configuration Information
Anypoint Connector for Azure Service Bus Management (Azure Service Bus Management Connector) cannot perform a connectivity test at startup using the **Test Connection** button in the global element of the connector configuration when you restrict access to your resources and you have a security policy with permissions at the resource level only. This scenario occurs because the security policy targets the root level of the namespace, which might be forbidden due to the customized policy applied to the shared access key.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
find | MuleSoft Documentation
# find
## find<T>(@StreamCapable() elements: Array<T>, elementToFind: Any): Array<Number>
Returns indices of an input that match a specified value.
This version of the function returns indices of an array. Others return indices of a string.
### Parameters
Name | Description  
---|---  
An array with elements of any type.  
`elementToFind` | Value to find in the input array.  
### Example
This example finds the index of an element in a string array.
#### Source
```
%dw 2.0
output application/json
---
["Bond", "James", "Bond"] find "Bond"
```

## find(@StreamCapable() text: String, matcher: Regex): Array<Array<Number>>
Returns the indices in the text that match the specified regular expression (regex), followed by the capture groups.
The first element in each resulting sub-array is the index in the text that matches the regex, and the next ones are the capture groups in the regex (if present).
Note: To retrieve parts of the text that match a regex. use the `scan` function.
### Parameters
Name | Description  
---|---  
A Java regular expression for matching characters in the `text`.  
### Example
This example finds the beginning and ending indices of words that contain `ea`
#### Source
```
%dw 2.0
output application/json
---
"I heart DataWeave" find /\w*ea\w*(\b)/
```

#### Output
```
[ [2,7], [8,17] ]
```

## find(@StreamCapable() text: String, textToFind: String): Array<Number>
Lists indices where the specified characters of a string are present.
### Parameters
Name | Description  
---|---  
A source string.  
`textToFind` | The string to find in the source string.  
### Example
This example lists the indices of "a" found in "aabccdbce".
#### Source
```
%dw 2.0
output application/json
---
"aabccdbce" find "a"
```

## find(@StreamCapable() text: Null, textToFind: Any): Array<Nothing>
Helper function that enables `find` to work with a `null` value.
Configuring Connected Apps | MuleSoft Documentation
# Configuring Connected Apps
The Connected Apps feature enables you to integrate external applications with Anypoint Platform by providing access to those applications without sharing your user credentials.
For information about Connected Apps, see Secure API Integration with Connected Apps and Connected Apps for Developers.
## Configure a Connected App in Access Management
To create a Connected App with object store scopes:
  1. In Anypoint Platform, go to **Access Management**.
  2. In the Access Management navigation menu, click **Connected Apps**.
  3. Click **Create App**.
    1. Specify a name for the app.
    2. Select **App acts on its own behalf (client credentials)**.
    3. Click **Add Scopes**.
    4. Select the object store scopes to apply:
    5. Click **Next** and select the business groups and environments to apply the scopes to.
    6. Click **Review**.
    7. Click **Add scopes** or **Cancel** to cancel your changes.
  4. Click **Save** or **Cancel** to cancel your changes.
  5. From the **Connected Apps** page, click **Copy Id** and **Copy Secret** for the app you just created.
Use this client ID and client secret to get the access token required to authenticate with the Object Store v2 API.


## Configure a Connected App Using the API
For information about configuring a connected app using the API, see How to create connected apps using the API.
## Object Store Scopes
Object store scopes apply to all stores in the given organization and environment. Unless otherwise noted, these scopes apply to both object stores and Object Store v2 object stores.
Scope in UI | Scope in API | Description  
---|---|---  
Manage stores | `manage:store` |  Create, read, update, and delete stores.  
Manage stores data | `manage:store_data` |  Perform all store operations including data, partition, and confirmation APIs.  
View stores | `read:store` |  Read store details.  
Manage store clients (object store only) | Not Available |  Manage all clients of a cloud store. This scope doesn’t apply to Object Store v2.  
View store clients (object store only) | Not Available |  View all clients of a cloud store. This scope doesn’t apply to Object Store v2.  
Store Metrics Viewer | `read:store_metrics` |  Retrieve Object Store v2 metrics using the Object Store v2 Stats API.
MuleSoft Accelerator for Retail | MuleSoft Documentation
# MuleSoft Accelerator for Retail
MuleSoft Accelerator for Retail empowers retail IT teams to unlock data from systems including ERP, CRM, MDM, commerce, and marketing to activate digital projects faster. Retail IT teams can take advantage of pre-built APIs, connectors, implementation templates, and reference architecture to create customer 360 profiles.
## Use Cases
The following use cases are supported by the MuleSoft Accelerator for Retail:
  * Customer profile sync - The Customer profile sync use case enables retail developers to create a customer 360 view by unlocking customer data from disparate systems.
  * Sales order sync - The Sales order sync use case enables retail developers to create and update sales orders across relevant applications.
  * Product sync - The Product sync use case enables retail developers to update product details in Salsify across relevant applications.
  * Real-time inventory management - The Real-time inventory management use case enables customers to make an informed decision of their online purchase based on real-time inventory of a product in nearby stores.
  * Deliver relevancy with CDP - The Deliver relevancy with CDP use case enables retail developers to combine customer profile data in a standardized format.


## See Also
  *   *   *   * MuleSoft Accelerator for Retail on Exchange
Reacting to Different Outcomes | MuleSoft Documentation
# Reacting to Different Outcomes
In the model of the process, you use an exclusive gateway to determine how to proceed with different outcomes of the tracking number extraction.
In RPA Builder, you configure the gateway using the `is_ordeid_found` Activity Parameter.
## See Also
  * RPA Builder: Connecting Activity Parameters to a Gateway
WSS Module XML and Maven Support | MuleSoft Documentation
# WSS Module XML and Maven Support
If you manually code a Mule application in XML either from the Studio XML editor or a text editor, you must perform the following actions to get access to a connector:
Add the namespace for the connector to your XML flow.
Add dependency information to your Maven `pom.xml` file.
In the Studio visual editor, when you drag a connector from the Mule Palette to the canvas, Studio automatically populates the XML code with the connector namespace and schema location.
## Add a Namespace for the Connector
If you manually code the Mule application in the Studio XML editor or another text editor, paste the following code inside the <mule> tag in your XML configuration:
```
http://www.mulesoft.org/schema/mule/wss
http://www.mulesoft.org/schema/mule/wss/current/mule-wss.xsd
```

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

## Add a POM File Dependency
The `pom.xml` Apache Maven 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 file to enable access to this connector:
```
<dependency>
    <groupId>org.mule.modules</groupId>
    <artifactId>mule-wss-module</artifactId>
    <version>1.1.1</version>
    <classifier>mule-plugin</classifier>
  </dependency>
```

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 `WSS Module`.
  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
  * MuleSoft Help Center
Creating Message Sources with the Mule SDK | MuleSoft Documentation
# Creating Message Sources with the Mule SDK
Operations are components that process a message and generate a result. Message sources are components that receive or generate new messages to be processed by the Mule Runtime.
Examples of message sources:
  * An HTTP listener
  * A File watcher
  * A JMS/AMQP listener that retrieves messages from a queue to which the user previously subscribed
  * Salesforce Streaming API


## Similarities Between an Operation and a Message Source
Operations and message sources have:
  * Parameters
  * A return type
  * Name and Description
  * Reconnection capabilities


## Differences Between an Operation and a Message Source
Operations | Message Sources  
---|---  
Operations process messages. | Sources create messages and push them to a flow.  
The lifecycle of operations is tied to the containing flow. | Message sources can be started and stopped independently of the containing flow.  
Parameters of operations have the option of accepting expressions (the default). | Sources have a clear definition of which parameters can accept expressions and which cannot. Only parameters that are part of generating a response can accept expressions.  
An operation can have a lifecycle, but its parameter values are not available or not needed. | A Message source must have `start()` and `stop()` phases, and they might require access to the parameter values.  
A connection is obtained each time the operation is executed. | A connection is obtained each time the message source is started or when reconnection happens.  
## Implementing a Message Source through the Mule SDK
The differences listed above make it difficult to define a way to implement a message source in a way 100% consistent with the model defined for operations.
Sources are required to extend the `Source` class, which takes two generics: one for the type of the generated event payload, the other for the type of the Attributes:
```
@Alias("listener")
@EmitsResponse
public class HttpListener extends Source<InputStream, HttpRequestAttributes> {}
```

You can use the `@Alias` annotation to force a name. Otherwise, the SDK will infer one.   
---  
## Next Step
  * Defining Parameters in a Message Source
Graphically Construct a Mapping (Anypoint Studio) | MuleSoft Documentation
# Graphically Construct a Mapping (Anypoint Studio)
Through the graphical UI of the Transform Message component you can do the tasks below. When doing each, the necessary lines are added to the DataWeave code to describe the action.
## Map a Field
Drag an element on the input structure over to another on the output structure, this casts a line that joins them.
## Map a Structure
Drag a high-level structure that contains lists of elements or inner fields onto another in the output. This creates a shaded region covering all the mapped structure. Fields that have identical names in these structures are automatically mapped too.
## Set a Fixed Value or Function
  1. Double click on a field in the output tree. This adds a function icon next to it.
  2. A new line is added to the DataWeave code that assigns a default `null` value to the field. This line is highlighted. Change its value to anything you want.


You can add:
  * A fixed string value by using " ".
  * A reference to an input field.
  * A DataWeave statement that includes functions.


## See Also
  * Transform Message Component
  * Workflow: Create a Mapping
  * DataWeave Language
JSON Module | MuleSoft Documentation
# JSON Module
JSON Module v2.2
The JSON module provides extra functionality for processing JSON documents. Although DataWeave is the tool that Mule uses to access data in JSON documents, this module provides extra functionality that falls outside of DataWeave’s scope, like schema validation.
Release Notes: JSON Module Release Notes Exchange: JSON Module
## See Also
  * ValidateDocuments against a JSON Schema with the JSON Module
  * JSON Module Reference
  * MuleSoft Help Center
Monitoring Flex Gateway | MuleSoft Documentation
# Monitoring Flex Gateway
Flex Gateway enables you to monitor the state of your APIs and gateway instances, and to view key metrics.
Refer to the following for details about Flex Gateway monitoring and logging:
  * Monitoring in Managed Flex Gateway
  * Monitoring in Connected Mode
  * Monitoring in Local Mode


## See Also
  * Flex Gateway Overview
  * Getting Started with Self-Managed Flex Gateway
RPA Recorder Overview | MuleSoft Documentation
# RPA Recorder Overview
Use RPA Recorder to record business processes.
RPA Recorder enables you to:
  * Record actions like mouse clicks, keyboard inputs on your system or on a web browser, and used applications
  * Add comments and variable information during the recording
  * Take screenshots automatically per mouse click, or manually at any time


You can start RPA Recorder either directly from RPA Manager in the design phase, or as a standalone tool without server connection.
  * If started from RPA Manager, RPA Recorder automatically uploads the recorded BPMN process model with the documentation into the server and creates a local PDF with the same information after the recording is finished.
  * If used without server connection, RPA Recorder creates the BPMN and stores it locally.


In either case, RPA Recorder also creates an XES file for further processing in process mining tools.
## See Also
  * Hardware and Software Requirements
Single Resource Transactions | MuleSoft Documentation
# Single Resource Transactions
Single Resource Transactions (also known as a simple transaction or local transaction) only use a single resource to send or receive messages: JMS broker, VM queues, or JDBC connections.
The example below illustrates a flow which includes a single resource transaction performed using the source and publish operations of the JMS connector.
```
<flow name="asdFlow" doc:id="2a67b1ee-0394-44a8-b6d9-9ce4f94f1ae2" >
	<jms:listener config-ref="JMS_Config" destination="test.in" transactionalAction="ALWAYS_BEGIN"/>
	<!-- Other operations -->
	<jms:publish config-ref="JMS_Config" destination="test.out" transactionalAction="ALWAYS_JOIN"/>
</flow>
```

Both the `jms:listener` source and the `jms:publish` operation must use the same connection configuration since this mechanism is intended to manage one resource.   
---  
The example shown above defines a JMS event source that receives messages from a `test.in` queue and another JMS operation that sends messages to a `test.out` queue. The `transactionalAction` attribute dictates how Mule initiates a transaction. Within this flow, Mule starts a new transaction for every message it receives (`jms:listener` source), and always joins the transaction in progress for every message it sends (`jms:publish` operation).
Mule only commits messages that successfully pass through the complete flow. If at any point in the flow a message throws an error which is propagated (i.e. it is not handled by an `on-error-continue`), Mule rolls back the transaction. Refer to On Error Scope for details on how to handle errors.
## Nested Transactions
Nested transactions are not available for Single Resource transactions. Refer to XA Transactions for more details.
## See Also
  * Transaction Management
Catalog Information Conformance | MuleSoft Documentation
# Catalog Information Conformance
You can check for API catalog information conformance using a custom or MuleSoft-provided ruleset. API catalog information is associated with an API asset in Exchange in the asset portal.
A MuleSoft-provided ruleset that validates API catalog information is:
  * API Catalog Information Best Practices


See Finding and Fixing Conformance Issues for an overview of ways to validate conformance and determine why conformance failed.
## Fix API Catalog Conformance Issues in Exchange
Fix issues by updating the API catalog information associated with the API so that it conforms to the rules it violated. For information about updating API catalog information using Exchange, see Editing an Asset.
Dedicated Load Balancer Updates | MuleSoft Documentation
# Dedicated Load Balancer Updates
The CloudHub dedicated load-balancer service provides quarterly updates that include the latest OS and security patches. If necessary, additional patches provide updates more often. These updates don’t include feature changes.
Because these updates contain required security patches, you cannot roll back these updates once applied.
When updates are available, an **Update** button appears on the load balancers page:
The **Update** button also appears on the details page for the individual load balancer:
## Update the Dedicated Load Balancer
The **Update** button indicates a load balancer requires an update. You can schedule the update to occur at your convenience. Before updating the Production DLBs, update the Sandbox DLB and run required tests.
To update a load balancer:
  1. From Anypoint Platform, click **Runtime Manager**.
  2. Click **Load Balancers**.
  3. Click the **Update** button.
  4. At the **Update load balancer** prompt, click **Update**.
Click the **View release notes** link for details on the update.
When you update a DLB with static IP addresses, the update might require additional static IPs. If you are prompted to add these new IP addresses to your allowlist, do so before you click **Update**.   
---  


The update results in a rolling restart with no downtime. However, some inflight requests might be impacted.
If you experience a sustained outage after updating, contact MuleSoft Support.
## See Also
  *   * DLB Monthly Scheduled Update FAQ
Troubleshooting Usage Reports | MuleSoft Documentation
# Troubleshooting Usage Reports
Because platform data availability depends on activity in your organization, in some cases, usage reports are unavailable.
## Unable to Access Usage Reports in Anypoint Platform
Verify that you have the Usage Viewer permission assigned at the root organization level.
If you don’t have the Usage Viewer permission assigned to you, contact the Anypoint Platform organization administrator.
## A Supported Product Isn’t listed
If a supported product isn’t listed when you open the product list, click **Switch View**.
For more information about product availability by view, see available products.
## Usage Reports Don’t Display Data for Runtime Fabric Apps
If you don’t see any data for Runtime Fabric apps, ensure that:
  * You’re using Runtime Fabric agent version 1.13.112, 2.1.30, or later.
  * After updating the Runtime Fabric agent, you manually redeployed each Runtime Fabric app with a supported date-patch version.


If you’re still missing Runtime Fabric apps in your usage reports, contact your account executive to request a report of apps that are not upgraded and what actions you need to take to update them.
## A Month or a Day is Unavailable in the Date Picker
If the date picker doesn’t show a month or day, data is unavailable for the selected period.
## Report Says No Data
If you select a product and daily or monthly report in new usage reports, and the report returns a `No Data` message, no data is available for the selected period.
This means that there is no data available for the selected day or month.
## No Report Available for This Time Period Message
If, after selecting a month in legacy usage reports, the report returns `No report available for this time period`, no data is available for the selected month.
This means there is no data available for the selected month.
## Deployed Mule App Isn’t Listed in the Mule Runtime Usage Report
If a deployed Mule app isn’t listed in the Mule Runtime usage report, make sure you’re using a supported version of Mule runtime. For more information, see supported runtime versions.
Redeploy your Mule apps with a supported Mule runtime version, either manually or during a monthly patching cycle.
## See Also
  * Usage and Pricing Metrics Reference
  *   * Usage Viewer permission