BassemE/mulesoft-documentation-embeddings huggingface dataset:
Pushing Messages to a Flow form a Message Source | MuleSoft Documentation
# Pushing Messages to a Flow form a Message Source
After generating a piece of information for the flow, the source uses the `SourceCallback` to send the information to the flow. Returning to the minimalistic HTTP listener example:
```
public class HttpListener extends Source<InputStream, HttpRequestAttributes> {
  @Override
  public void onStart(SourceCallback<InputStream, HttpRequestAttributes> sourceCallback) throws MuleException {
    httpServer = serverProvider.connect(); **(1)**
    server.listen(path).onRequest(request -> { **(2)**
      Result<InputStream, HttpRequestAttributes> result = requestToResult(request); **(3)**
      sourceCallback.handle(result); **(4)**
    });
  }
}
```

The example uses the ConnectionProvider to obtain an `HttpServer`. The typical connection provider most already configured the server with the proper host and port.  
---  
HTTP requests are pushed into the server by the remote clients, and the `HttpServer` component will notify the source of every request. The source then uses the `SourceCallback` to push the message into the flow.  
The message is represented by leveraging the same `Result` object that operations use to communicate complex outputs. See `Result` for more information.  
The example uses the `handle(Result)` method in the `SourceCallback` to pass the message.  
## Threading Model
Once the `Result` object is passed to the `SourceCallback` through the `handle(Result)` method, message processing occurs asynchronously in a different thread than the one invoking the method.
The next step explains how to catch the result of the Flow processing and optionally send a response.
## Next Step
  * Obtaining Flow output and Sending responses from a Message Source
Migrating Connectors and Modules to Mule 4 | MuleSoft Documentation
# Migrating Connectors and Modules to Mule 4
This section covers the migration of connector-specific features and lists connectors that are deprecated or removed from Mule 4.
## Deprecated or Removed Connectors
The following table shows deprecated/removed Mule 3.x modules and how to replace them in Mule 4.0.
Mule 3.x Module | Mule 4.0 Replacement  
---|---  
Use APIkit + standard REST.  
Replaced with HTTP + DataWeave.  
Use Web Service Consumer / APIkit for SOAP.  
MuleSoft now provides connectivity to Pega or Appian for BPM.  
Use Web Service Consumer.  
Removed.  
MuleSoft now provides connectivity to Pega or Appian for BPM.  
Use new HTTP module.  
Replaced DataWeave expression language, or MEL in compatibility module.  
Patterns | Removed. Use flows instead.  
Use new Scheduler component.  
Use HTTP + DataWeave.  
New embedded mode in development.  
Use DataWeave.  
New embedded mode in development.  
Use Sockets connector.
AS2 Signature and Encryption Algorithms | MuleSoft Documentation
# AS2 Signature and Encryption Algorithms
AS2 endpoints deployed from Partner Manager support the following signature and encryption algorithms:
  * Signature algorithms
    * `UNSIGNED (Default)`
  * Encryption algorithms
    * `UNENCRYPTED (Default)`
    * `AES128_CBC`
    * `AES128_CCM`
    * `AES128_GCM`
    * `AES192_CBC`
    * `AES192_CCM`
    * `AES192_GCM`
    * `AES256_CBC`
    * `AES256_CCM`
    * `AES256_GCM`
    * `AES256_WRAP`
    * `DES_EDE3`


## See Also
  * Creating Endpoints
Getting Started Writing Tests | MuleSoft Documentation
# Getting Started Writing Tests
A test suite is composed of the following elements:
  * A directory that contains a main file named `bat.yaml` that describes the structure of your test suite
  * A `config` folder that contains files in which you specify variables
  * One or more folders in which you write tests


Tests are written in the BDD Test-Writing syntax and use the `.dwl` file extension.
## Before You Begin
Before you can write and run tests, you must have access to an Anypoint Platform account.
## Use Examples to Learn the Basics
Learn the basics of writing tests using the provided examples.
To select examples:
  1. In the **Create Monitor** page, click **Switch to code editor**.
  2. In the selector menu for the code editor, select a test example. Examples include:
     * Test an expected status code
     * Validate multiple assertions
     * Set and reuse variables
     * Iterate test
     * Extract function
     * Assert with regex expression
     * Repeat N times
The code in the code editor automatically changes to show the selected example code.
  3. Modify the example test for your own needs. See BDD Test-Writing Syntax Reference to understand the syntax and write your own tests.
  4. Validate whether the test works by clicking **Validate Test**.


The example menu is available only when creating a monitor.   
---  
## See Also
  * The website for the Deck of Cards API
  * BDD Test-Writing Syntax Reference
  *   *
Step 1. Prerequisites for Creating an Automation | MuleSoft Documentation
# Step 1. Prerequisites for Creating an Automation
Before you begin your automation journey, verify that you have the required tools and access:
  * **User Accounts and Permissions**
    * A user account to access RPA Manager
If you don’t have a RPA Manager user, ask an administrator from your organization to set up your credentials with:
      * Enough privileges to access the automation modules
      * Enough permissions to manage the different project phases
      * The **Project Management** privilege
      * The **Builder Usage** privilege
The User Management module enables configuration of user privileges.
    * A user account to access MuleSoft Composer
If you don’t have a Composer user, ask an administrator from your organization to set up your credentials.
    * An RPA API Key to connect MuleSoft Composer and MuleSoft RPA
See Create an API Key for a User for instructions.
    * A Connected App configured in Access Management to use with MuleSoft RPA
See Configure a Connected App in Access Management for instructions on creating and configuring the Connected App.
  * **RPA Applications installed in your system**
    * RPA Builder installed and configured in your environment
See Installing and Configuring RPA Builder for installation and configuration instructions.
    * RPA Recorder installed and configured in your environment
See Installing and Starting RPA Recorder for installation and configuration instructions.
    * RPA Bot installed and configured in your environment
See Installing RPA Bot and Configuring RPA Bot for installation and configuration instructions.
      * Ensure you configure the Secure Session in the RPA Bot Configurator tool.


Use two browser windows: One to read instructions and one to perform the tasks.   
---  
## Next Steps
After you set up your environment with the necessary applications and credentials, you are ready to start evaluating processes for automation.
Continue with Step 2: Evaluate a process for automation
## See Also
  *   * Hardware and Software Requirements
Troubleshooting Queries With Response Logs | MuleSoft Documentation
# Troubleshooting Queries With Response Logs
Anypoint DataGraph provides response logs that contain useful query troubleshooting information.
Response logs contain information about only Anypoint DataGraph queries. Anypoint DataGraph stores up to 100 MB or up to 30 days of log data, whichever limit is reached first.
If your organization has the Anypoint Integration Advanced package or a Titanium subscription to Anypoint Platform, this feature provides a higher resource allocation.
For more information on log limits, see limits in Anypoint Monitoring.
## Log Levels for Anypoint DataGraph Response Logs
Log levels for Anypoint DataGraph include DEBUG, INFO, WARN, and ERROR. Log levels are incremental, and each level contains the following information:
Log level | Description | Levels included  
---|---|---  
Logs information for request headers and request queries | All levels  
Logs information for request queries, response times, and the underlying API URLs requested per field in queries | INFO, WARN, and ERROR  
Lists warning messages | INFO, WARN  
Lists error messages on invalid queries, timeouts, authentication failures, and payload errors  
By default, the log level for each environment is set to INFO. You can change this setting at any time. Changes to the log level persist for _all future queries to that Anypoint DataGraph instance_ , regardless of the user.
## View Response Logs for an Operation
You must have the Operate or Admin permission to view and search response logs.
If you are a Titanium subscriber, you can also view response logs in Anypoint Monitoring.
To view response logs in Anypoint DataGraph:
  1. Write and run an operation.
  2. From the actions menu (**…​**), select **View Response Logs**.
Response logs for that query are displayed:


## Search Response Logs
Search for logs that contain specified values or search for logs by date and priority.
The **Date & Time** filter enables you to search logs by specifying a date range using the following values:
  * Last hour
  * Last 24 hours
  * Last week
  * Last month


You can also filter searches by priority level:
  * All priorities
  * DEBUG
  * ERROR


To search existing logs:
  1. Enter a value in the search box, or click Advanced to search for logs for a specified time, day, date range, and message priority.
  2. Click **Apply**.


## Additional Resources
  * Troubleshoot Query Performance with Query Tracing
  * Run Queries and Mutations
Json Query | MuleSoft Documentation
# Json Query
Use the Json Query action step to parse Json objects and read individual values or elements from the object. The result remains available for the rest of the process run as a source variable.
Combine this action step with REST Call to further refine the resulting JSON output.
## Properties
  * **JsonPath Expression**
The JsonPath expression. For example, `$.access_token`.


## Inbound Variables
  * **Json Object**
The Json object from which to extract the value using the JsonPath expression. You can select the result of a REST Call action step to serve as an object.
  * **JsonPath Expression**
The JsonPath expression to specify the value to extract from the object. For example, `$.ID`, to extract the value of element `ID` as a result.


## Outbound Variables
  * **IsSucceeded** (boolean)
Shows if the action step executed successfully or not.
  * **FirstItem** (array)
Outputs the first element of the array as a string.
  * **ArrayCount**
Indicates the number of elements of the returned array.


## Wizard
Use the Wizard to select the source JSON Object, usually an Inbound Variable containing the result of a REST Call, and to specify the JsonPath expression to extract values from the object. An empty result is a valid result and the process continues without considering it as an error.
Use the JsonPath expression Builder to simplify the process of creating the JsonPath expression.
For more information about JSONPath, see XPath for JSON.
## See Also
  * Building JSONPath Expressions
Deleting the Local User After Installing Anypoint Platform PCE | MuleSoft Documentation
# Deleting the Local User After Installing Anypoint Platform PCE
During installation, Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) creates a local Anypoint Platform user that enables you to configure platform components during installation. The credentials for this user are stored locally in Anypoint Platform. However, after configuring an external authentication provider such as LDAP, you should delete this user to improve security.
  1. Before deleting the local user, perform the following steps:
     * Install and configure your external identity provider.
     * Ensure that `SystemAdmin` user is not the owner of any other organizations.
  2. Select the new user to whom you want to assign administrator privileges. This user must be defined in your external identity provider.
  3. Determine the internal user ID for this user.
    1. From Anypoint Platform, select **Access Management**.
    2. Select **Users**.
    3. Select the name of the user.
    4. Record the internal user ID. This ID appears in the URL as:
  4. Configure your installer machine with `kubeconfig.yaml to access the Anypoint Platform PCE K8s cluster.
    1. Set the environment variable `KUBECONFIG=/path/to/kubeconfig.yaml`.
    2. Check access to kubernetes cluster with `kubectl get nodes`.
  5. Identify one of the `authentication-server` containers:
```
kubectl get pods -n access-management -l component=authentication-server
```

  6. Change the owner, providing the internal the `authentication-server` container and user ID obtained earlier:
```
kubectl exec -it -n access-management <authentication-server-pod> -c application – node bin/change_owner.js --new-owner-id <user_id>
```

This command changes the owner from the default system user to a new user managed by the external authentication provider. The command you use should be similar to the following example:
```
kubectl exec -it -n access-management <authentication-server-pod> -c application – node bin/change_owner.js --new-owner-id a363279f-982f-493c-b08f-9feb91be90d4
```

  7. Disable and delete the `System Admin` user.
    1. Log in as the user you just added as the organization owner.
    2. From Anypoint Platform, select **Access Management**.
    3. Select **Users**.
    4. Select `username` in the same row as `SystemAdmin`.
    5. Select **Disable**.
    6. Select **Delete**.


This removes the default user from the platform.
## See Also
  * Configuring Anypoint Platform PCE
Logging and Debugging | MuleSoft Documentation
# Logging and Debugging
MuleSoft provides a variety of logging and debugging options for Mule apps.
Application logs and a runtime log help you monitor and troubleshoot your apps and the Mule server. For details, see Configuring Logging.
You can enable verbose logging for connectors and modules to record debug level information in the logs.
The Logger component can help you monitor or even debug your Mule app by logging important information such as error messages, status notifications, payloads, and so on. You can add a Logger anywhere in a flow, and you can configure it to log a string that you specify, the output of a DataWeave expression you write, or any combination of strings and expressions. For details, see Logger Component in the Core component documentation.
To control the display of Mule stack traces, you can use command-line arguments or set properties in Anypoint Studio. For details, see Configuring Mule Stack Traces.
To troubleshoot a Mule app in Anypoint Studio, you can use the Studio Visual Debugger, which lets you set breakpoints to stop execution and check events. If you are creating your Mule app outside of Studio, you can either use MUnit to test your app, or you can activate remote debugging. For details, see Debugging Outside Studio.
If you are running your Mule application in CloudHub, see View Log Data for additional information about log data and persistence.
Mule Runtime Issues and Errors | MuleSoft Documentation
# Mule Runtime Issues and Errors
Cloud IDE 
Desktop IDE 
**Open Beta Release** : The **cloud IDE is in open beta**. Any use of Anypoint Code Builder in its beta state is subject to the applicable beta services terms and conditions, available from the IDE.
Anypoint Code Builder bundles a version 4 instance of Mule runtime engine (Mule) to run your integrations and implementations.
Do not change the default locations of Mule unless you receive an error that Mule is not found or installed. If such errors occur, the following properties enable you to change the path to Mule:
  * **Mule Runtimes Directory** : The default location of the Mule installation.
Default value: `/Users/<user-name>/muleRuntimes/`
  * **Mule Home** : The full path that points to the root files of the Mule instance.
Default value: `/Users/<user-name>/muleRuntimes/<mule-runtime-installation>`


## Mule Runtime Is Not Installed
The error `Mule Runtime Is Not Installed, You Must Configure a Mule Runtime to Enable This Feature` occurs if **Mule Home** and **Mule Runtimes Directory** are misconfigured or empty and a feature requires a running Mule instance. For example, auto-completion and debugging features require Mule to run.
To troubleshoot this issue, use the following procedure:
  1. Locate the **Mule > Runtime: Mule Home** and **Mule > Runtime: Mule Runtimes Directory** properties:
  2. Provide the full path to the folder that contains Mule runtime. This field must not be empty.


## No Mule Runtime Found
The warning `No Mule runtime found. To perform this action, you must have Mule runtime configured.` occurs if Mule is not configured properly when you open Anypoint Code Builder. The **Mule Home** or **Mule Runtimes Directory** fields are misconfigured or empty.
To troubleshoot this issue, use the following procedure:
  1. Navigate to your Anypoint Code Builder view, and select the **Open ACB Settings** icon.
  2. Locate the **Mule > Runtime: Mule Home** and **Mule > Runtime: Mule Runtimes Directory** properties:
  3. Provide the full path to the folder that contains Mule runtime. This field must not be empty.


## Please Download and Install a JDK to Compile Your Project
This request is _not_ from MuleSoft or Anypoint Code Builder:
Instead of using this feature, you can use the command **Download Mule Runtime and Java Versions**. See also, Version Settings for Mule, Java, and Connectors.
Deploy Security Policies to Runtime Fabric | MuleSoft Documentation
# Deploy Security Policies to Runtime Fabric
## Prerequisites
To deploy policies, you must meet the following requirements:
  * Have the **Manage Runtime Fabrics** permission associated to your user.
  * Your account must have the following entitlements:
    * **Runtime Fabrics**
    * **Security Edge Policies**
    * **API Manager**
    * **Analytics**


## Deploy Policies
  1. Go to **Runtime Manager** , and click **Runtime Fabric** in the left navigation bar.
  2. Select the Runtime Fabric where you want to enable Edge policies.
  3. Click the **Inbound Traffic** tab, and navigate to **Security Policies**.
  4. For each policy to deploy, select the name of the policy from the drop-down list, then click **Deploy**. The policy is deployed to Runtime Fabric.


## See Also
  *   *   *   *
Upgrading Runtime Fabric on Red Hat OpenShift | MuleSoft Documentation
# Upgrading Runtime Fabric on Red Hat OpenShift
Red Hat OpenShift console allows you to run upgrades automatically (default) or manually. You can change this setting in the **Subscription** tab in the Runtime Fabric Operator.
Starting with Runtime Fabric agent version 2.4.0, for any new Mule app deployment, you must use a Mule runtime image built on Aug 8, 2023, or later.
## Upgrade Runtime Fabric on Red Hat OpenShift
To upgrade Runtime Fabric on Red Hat OpenShift, use the Runtime Fabric operator in the Red Hat OpenShift console.
  1. In the Red Hat OpenShift console, navigate to **Operators > Installed Operators**.
  2. Select the Runtime Fabric operator.
  3. Click **Upgrade**.


## Upgrade to an Intermediate Runtime Fabric on Red Hat OpenShift
To upgrade to an intermediate Runtime Fabric OpenShift operator, you need to uninstall the previous version and install the intermediate version:
  1. From the OpenShift console, uninstall the Runtime Fabric operator, without deleting or uninstalling Runtime Fabric instances or clusters.
  2. On the OpenShift console find the Runtime Fabric operator in the Operator Hub and install the desired version.


This automatically triggers the upgrade of the existing Runtime Fabric instances.
## See Also
  * Upgrading Runtime Fabric
Google BigQuery Connector 1.1 - XML and Maven Support | MuleSoft Documentation
# Google BigQuery Connector 1.1 - XML and Maven Support
Although you can manually code a Mule app in XML, it is more efficient to use Anypoint Studio:
  * If you manually code a Mule runtime engine (Mule) app in XML (either from the Anypoint Studio XML editor or from a text editor), you can access the connector from your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file.
  * If you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location and it also adds a dependency to the `pom.xml` file.


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

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

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

Replace `<version>` with the version that corresponds to the connector you are using.
To obtain the most up-to-date `pom.xml` file information:
  1. Go to Anypoint Exchange.
  2. In Exchange, click **Login** and supply your Anypoint Platform username and password.
  3. In Exchange, search for `google bigquery`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## Next Step
After completing your namespace and `pom.xml` file, you can try the Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Upgrading Pre-requisites | MuleSoft Documentation
# Upgrading Pre-requisites
For all OpenShift upgrades from versions 2.6.52 and earlier to versions 2.7.0 and later, you must manually increase the `rtfd` container resources to the desired values. See Scalability Benchmarks for guidance on `rtfd` container resource values.
To update `rtfd` container resources:
  1. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**.
  2. Select the **Runtime Fabric** operator and open the Runtime Fabric instance `.yaml` file.
  3. In the `.yaml` file, go to `spec:` > `agent:` > `rtfd:`, and update the resource allocations to recommended values.
  4. Click **Save**.


For Helm-based upgrades, if the Helm-based installations had previously overridden `rtfd` container resources in the `values.yaml` file, then you must manually increase the allocations as per scalability guidelines, as Helm-based upgrades respect pre-release manual overrides.   
---
Iterable and Map Matchers Reference | MuleSoft Documentation
# Iterable and Map Matchers Reference
Anypoint Code Builder 
Anypoint Studio 
## everyItem(Matcher)
Checks that every element in the expression matches the specified matcher.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::notNullValue())]"/>
```

Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::startsWith('a'))]"/>
```

## hasItem(Object)
Checks that any element in the expression matches the specified matcher.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem('example')]"/>
```

Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem(MunitTools::startsWith('a'))]"/>
```

## hasSize(Matcher|Integer)
Checks that the size of the expression matches the specified matcher.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(MunitTools::greaterThan(2))]"/>
```

Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(5)]"/>
```

## isEmpty()
Checks that the expression is an empty collection.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmpty()]"/>
```

## hasKey(Matcher|String)
Checks that the expression has a key that matches the specified matcher.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey(MunitTools::startsWith('a'))]"/>
```

Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey('mykey')]"/>
```

## hasValue(Object)
Checks that the expression has a value that matches the specified matcher.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue('myvalue')]"/>
```

Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue(MunitTools::startsWith('a'))]"/>
```

## See Also
  *   * Core Matchers Reference
  * String Matchers Reference
  * Comparable Matchers Reference
Getting Started with API Designer | MuleSoft Documentation
# Getting Started with API Designer
You can use the API Designer web UI to design API specifications in:
  * RESTful API Modeling Language (RAML) version 0.8 or 1.0
  * OpenAPI Specification (OAS) version 2.0 or 3.0
  * AsyncAPI 2.6 and AsyncAPI 2.0


You can also design API fragments in RESTful API Modeling Language (RAML) version 0.8 or 1.0.
## Add and View Documentation
As you add descriptions in your specifications and fragments, you can view them in auto-generated, interactive documentation in the right pane of the text editor.
## Test Using the Mocking Service
You can use the mocking service for RAML or OAS APIs to:
  * Preview API functionality before writing a single line of code.
  * Send requests to a specification and receive defined responses.
  * Use behavioral headers to simulate different scenarios, such as timeouts and errors.


## Share in Exchange and API Manager
You can publish an API specification to Anypoint Exchange for use in API Manager, or Anypoint Studio. You can also add an API specification directly to API Manager.
## Use Specifications and Fragments Across MuleSoft Products
You can use the specifications and fragments that you design in API Designer with integrated MuleSoft products:
  * Use API Designer to design API specifications and RAML fragments.
  * Use assets that are hosted in Exchange in your RAML specifications.
  * Publish iterations and final versions of the API specifications to Anypoint Exchange.
  * Import specifications that were designed in API Designer into Anypoint Studio and API Manager.
  * Import specifications into Anypoint Studio directly from API Designer.


## See Also
  * Create and Publish an API Specification with the Text Editor in API Designer
  * Create and Publish an API Specification with the Visual Text Editor in API Designer
  * Create and Publish an API Fragment in the Text Editor in API Designer
Introduction to Mule 4: Transformations and Streaming | MuleSoft Documentation
# Introduction to Mule 4: Transformations and Streaming
The way to think about data in Mule 4 is fundamentally different in Mule 3. In Mule 3, you often need to know about the underlying Java types, how to manage InputStreams, whether a payload is larger-than-memory, and how to convert data into Java objects so they can be accessed by MEL.
For Mule 4, these best practices are recommended:
  * Avoid unnecessary conversions to Java data types, and work with data directly.
  * Let the runtime handle streaming for you.
  * Do not convert binary data types to `String`, `byte[]`, or `InputStream` unless you are performing a direct integration with custom Java code.


## Transparent Streaming
Introduction to Mule 4: DataWeave Expression Language showed how to work with data directly using DataWeave. This ability to access different data formats, combined with Mule 4 streaming capabilities, means that you no longer need to convert your data to Java objects first. This improvement greatly simplifies working with data in the runtime because:
  * Data can be read multiple times or accessed randomly using the DataWeave expression language, without side effects.
  * Data can be sent to multiple places without the need to cache that data in memory first.
  * You can transparently access larger-than-memory data.


For more information on how streaming works in Mule 4, please see About Streaming in Mule 4.0.
## Data Types and Object to String/Byte/InputStream Transformers
Because Mule now manages the data streams for you, data access becomes simpler. You do not need to be concerned with the underlying Java representation of that type whether it is a `byte[]`, `InputStream`, `String`, or some other format.
A common pattern observed in Mule 3 applications is that users would convert things to strings in order to log them or send them through some transport. This was necessary because streams cannot be consumed twice, so a Transformer was needed:
```
<http:listener ... /> <!-- Obtains an InputStream payload -->
<object-to-string/> <!-- consume the stream and convert it to a String -->
<logger message="#[payload]"/> <!-- log the String -->
<http:request .../> <!-- send the String somewhere else-->
```

In Mule 4, you can simply log or send the data without worrying about the underlying type or how many times the stream is consumed. Instead of thinking about the `InputStream`, you should just think about the payload as binary data. Or, if you know the content type, you can think about it directly as JSON, XML, or whatever data type corresponds to the content type.
```
<http:listener ... /> <!-- payload is JSON document -->
<logger message="#[payload]"/> <!-- log the JSON document -->
<http:request .../> <!-- send the JSON document somewhere else-->
```

## See Also
  * Streaming in Mule Apps
Viewing the Replica Status in Runtime Manager | MuleSoft Documentation
# Viewing the Replica Status in Runtime Manager
In Runtime Manager, you can view the status of groups of Flex Replicas and individual Flex Replicas.
## Groups of Flex Replicas
To view information about the status of groups of Flex Replicas:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu. By default, all Flex Gateways regardless of their status are shown. To filter by status, click the **Any Status** arrow and the status you want to filter.


The **Name** column lists the name and the number of connected replicas.
The **Status** column shows the connection status for the replicas associated with a particular gateway.
The following table describes the meaning of each status for a group of replicas:
Status | Group of Replicas  
---|---  
At least one replica is connected to the platform and can serve traffic.  
Not Running |  There are no replicas connected to the platform and no information on whether they are serving traffic.  
## Individual Flex Replicas
To view information about the status of individual replicas:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu.
  3. Select the name of the Flex Gateway whose individual replica statuses you want to view.


The **Status** column in the list of replicas shows the connection status for that particular replica.
The following table describes the meaning of each status for a single replica:
Status | Single Replica  
---|---  
The replica is connected to the platform and can serve traffic.  
Not Running |  The replica is not connected to the platform. There is no information on whether it is serving traffic. Disconnected replicas are deleted after seven days.  
## See Also
  * View the API Status in Runtime Manager
orElseTry | MuleSoft Documentation
# orElseTry
## orElseTry<T, R>(previous: TryResult<T>, orElse: () -> R): TryResult<T | R>
Function to use with `try` to chain multiple `try` requests.
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
Result from a previous call to `try`.  
`orElseTry` | Argument to try if the `previous` argument fails.  
### Example
This example waits shows how to chain different try
#### Source
```
%dw 2.0
import * from dw::Runtime
var user = {}
var otherUser = {}
output application/json
---
{
  a: try(() -> user.name!) orElseTry otherUser.name!,
  b: try(() -> user.name!) orElseTry "No User Name"
}
```

#### Output
```
{
 "a": {
  "success": false,
  "error": {
   "kind": "KeyNotFoundException",
   "message": "There is no key named 'name'",
   "location": "\n9|   a: try(() -> user.name!) orElseTry otherUser.name!,\n                     ^^^^^^^^^^^^^^",
   "stack": [
    "main (org::mule::weave::v2::engine::transform:9:40)"
   ]
  }
 },
 "b": {
  "success": true,
  "result": "No User Name"
 }
}
```
Viewing API Status in Runtime Manager for Managed Flex Gateway | MuleSoft Documentation
# Viewing API Status in Runtime Manager for Managed Flex Gateway
To view basic information about APIs associated with Flex Gateway instances:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu.
  3. Click the name of the gateway whose APIs you want to check.
  4. Click **APIs**.
For each API, Runtime Manager shows the name, version, instance ID, label, and date on which it was added.


To see more detailed information and perform actions on your APIs, click **View details** to be redirected to API Manager.
withMaxSize | MuleSoft Documentation
# withMaxSize
## withMaxSize(text: String, maxLength: Number): String
Checks that the string length isn’t greater than the specified `maxLength`. If the string is longer, the function returns a substring that starts at the beginning of the string and is `maxLength` characters long.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The input string.  
`maxLength` | The maximum length of the string.  
### Example
This example shows how `withMaxSize` behaves with different `maxLength` values for the same string. Note that if `withMaxSize` is 0, the function returns an unmodified string. If the input is `null`, the output is always `null`.
#### Source
```
%dw 2.0
import withMaxSize from dw::core::Strings
output application/json
---
{
  a: "123" withMaxSize 10,
  b: "123" withMaxSize 3,
  c: "123" withMaxSize 2,
  d: "123" withMaxSize 0,
  e: null withMaxSize 23,
}
```

#### Output
```
{
 "a": "123",
 "b": "123",
 "c": "12",
 "d": "123",
 "e": null
}
```

## withMaxSize(text: Null, maxLength: Number): Null
Helper function that enables `withMaxSize` to work with a `null` value.
_Introduced in DataWeave version 2.3.0._
Excel Operations | MuleSoft Documentation
# Excel Operations
Excel operations enable you to interact with Microsoft Excel files by extracting and manipulating their data.
  * Use Excel Controlled Loop to iterate over data from an Excel file.
  * The Excel Session is an element that encompasses Excel operations, except for Execute Excel Macro. Excel operations include reading, modifying, and creating entire files and file elements in Excel format.
  * Run a macro in an Excel file or sheet. This action step doesn’t run inside an Excel Session.
  * Use Read from Excel File to read the contents of an Excel file.
  * Use Recalculate Excel File to recalculate the values of an Excel sheet.
  * Use Save Excel File to save the contents of an Excel file.
  * Use Write to Excel File to write content to the selected Excel file. You can write the content to the same file or to a new destination file.
Disable Pooling in the FTP Connector Configuration | MuleSoft Documentation
# Disable Pooling in the FTP Connector Configuration
Disable connection pooling in the Anypoint Connector for FTP (FTP Connector) configuration to ensure no connection is active if there is nothing to transfer.
  1. In Studio, navigate to the **Global Elements** tab.
  2. Click **Create**.
  3. Type `ftp`.
  4. Select **FTP Connector**.
  5. Click **OK**.
  6. In the **Global Elements** properties tab, click the **Advanced** tab.
  7. Set **Pooling profile** to **Edit inline**.
  8. Set the values of **Max active** , **Max idle** , and **Max wait** to `0` to ensure that no connection is active if there is nothing to transfer.


## See Also
  * FTP Connector Examples
  * MuleSoft Help Center
JSON Module Reference | MuleSoft Documentation
# JSON Module Reference
JSON Module v2.5
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
## Configurations
### Default Configuration
Default configuration
#### Parameters
Name | Type | Description | Default Value | Required  
---|---|---|---|---  
The name for this configuration. Connectors reference the configuration with this name.  
## Operations
### Validate Schema
`<json:validate-schema>`
Validates that the input content is compliant with a given schema. This operation supports referencing many schemas (using comma as a separator) which include each other.
JSON **Validate schema** operation supports schema versions Draft 3, Draft 4, Draft 6, Draft 7, Draft 2019-09, and Draft 2020-12. If you do not specify a draft version in the JSON schema node, the default version is Draft 04.   
---  
#### Parameters
Name | Type | Description | Default Value | Required  
---|---|---|---|---  
The JSON document to validate. | #[payload]  
Schema Redirects |  Array of Schema Redirect | Allows to redirect any given URI in the Schema (or even the schema location itself) to any other specific URI. The most common use case for this feature is to map external namespace URIs without the need to a local resource.  
Dereferencing |  Enumeration, one of: **CANONICAL** INLINE | Draft v4 defines two dereferencing modes: canonical and inline. CANONICAL is the default option, you can also specify INLINE. This field affects only when you use Draft v4. | CANONICAL  
Allow Duplicate Keys | If true, the validator allows duplicate keys, otherwise it fails  
Allow Arbitrary Precision | If true, the validator uses arbitrary precision when reading floating point values, otherwise it uses double precision.  
The location of the validate schema to validate. This attribute supports URI representations such as "http://org.mule/schema.json" or "resource:/schema.json". It also supports a most common classpath reference such as simply "schema.json".  
SchemaContent | The content of the schema to validate in text format.  
#### Throws
  * JSON:INVALID_INPUT_JSON
  * JSON:INVALID_SCHEMA
  * JSON:SCHEMA_NOT_FOUND
  * JSON:SCHEMA_NOT_HONOURED
  * JSON:SCHEMA_INPUT_ERROR


## Types
### Schema Redirect
Field | Type | Description | Default Value | Required  
---|---|---|---|---  
The original location  
The redirection location  
## See Also
MuleSoft Help Center
MUnit in Anypoint Code Builder | MuleSoft Documentation
# MUnit in Anypoint Code Builder
Anypoint Code Builder 
MUnit is integrated with Anypoint Code Builder and you can:
  * Create and design MUnit tests
  * Run your tests
  * View test results
  * Debug your tests
Publishing the API Spec to Anypoint Exchange | MuleSoft Documentation
# Publishing the API Spec to Anypoint Exchange
Cloud IDE 
Desktop IDE 
**Open Beta Release** : The **cloud IDE is in open beta**. Any use of Anypoint Code Builder in its beta state is subject to the applicable beta services terms and conditions, available from the IDE.
Publish American Flights API specification to Exchange so that other team members can find and implement it.
## Before You Begin
  * If you haven’t started the American Flight API specification, follow these procedures before attempting to publish:
    1. Designing the American Flights API Spec
    2. Adding Examples to the API Spec
    3. Testing the API Spec with the Mocking Service


  * Have some familiarity with business groups.
When you publish your API spec to Exchange from Anypoint Code Builder, the IDE requests the name of the business group.


## Publish an API to Exchange
To publish your API to Exchange:
  1. In Anypoint Code Builder, open the specification for your American Flights API project, such as `american-flights-api.raml`.
  2. Open the Command Palette.
Show me how
     * Use the keyboard shortcuts:
       * Mac: Cmd+Shift+p
       * Windows: Ctrl+Shift+p
     * In the desktop IDE, select **View** > **Command Palette**.
     * In the cloud IDE, click the (menu) icon, and select **View** > **Command Palette**.
  3. Provide the following command:
```
MuleSoft: Publish API Specification to Exchange
```

  4. If prompted, click **Allow** , and follow the prompts to sign in to Anypoint Platform.
  5. In **Select a Business Group** , find and select your business group for the project.
For more information, see Before You Begin.
  6. Type a project name: **American Flights API**.
  7. Confirm the artifact ID: **American-Flights-API**.
  8. Confirm the asset version: **1.0.0**.
  9. Confirm the API version: **v1**. The status bar shows the progress:
  10. When prompted to implement the API now, select **No** to avoid scaffolding the American Flights API specification into your integration.
Selecting **Yes** scaffolds the API specification into your project. Instead of scaffolding now, you will scaffold in Implementing the American Flights API Spec.


## Locate Your API in Exchange
After publishing your API specification, you can find it in Anypoint Exchange:
  1. Navigate to Anypoint Platform and log in using your credentials.
Show me how
     * US cloud (non-EU host): Anypoint Platform (US)
     * EU cloud (EU host): Anypoint Platform (EU)
  2. Navigate to Anypoint Exchange.
Show me how
     * US cloud (non-EU host): Exchange (US)
     * EU cloud (EU host): Exchange (EU)
  3. Notice that your API specification is listed as an asset.
You can select the API, navigate through its summary, and see all the endpoints you defined in the previous tasks.
  4. Proceed to Integrating American Flights Processes to start an integration app for American Flights.
Microsoft Teams Connector Reference | MuleSoft Documentation
# Microsoft Teams Connector Reference
Microsoft Teams is a SaaS enterprise communication system used to send messages within an organization and to customers outside of the direct organization.
To send a Microsoft Teams message using MuleSoft Composer, you must have an active business, enterprise, or education Microsoft 365 license.
## Connections
To connect to a system, whether it is a source of data or the target where you are sending data, you must create a connection with that system’s required credentials. You typically connect to different systems within a flow and can reuse each connection every time you need to connect.
This system requires the following credential information for its connections: 

Connection Name
    
Enter a connection name that will help you remember the details of this connection. You can reuse connections multiple times in a single flow, and in more than one flow, and the credentials are hidden after you create the connection. Therefore, it’s helpful to provide a name that easily identifies this connection from others.
Only you can see the connection. Other users in your Composer app must create their own connections.
You must disable the admin consent workflow because Composer does not support it. 

Username
    
The username that you use to log in to Microsoft 365. 

Password
    
The password that you use to log in to Microsoft 365.
## Actions
After you connect to a system and define the trigger or configure a scheduler, you define the actions that the flow performs. For example, you can copy a record between different systems, such as Workday and Salesforce. The actions you can perform depend on which system you are connected to.
This system provides the following actions: 

Send message to channel
    
Sends a message to all users who are members of a specific Microsoft Teams channel. The following fields are required:
  * Team ID
  * Channel ID
  * Message


## See Also
  * Mulesoft Composer: Overview
  * MuleSoft Composer: Getting Started
  * Composer Connector Reference
  * Knowledge Articles
Import Files into an API-Fragment Project | MuleSoft Documentation
# Import Files into an API-Fragment Project
File uploads are restricted to supported formats.   
---  
You can import RAML fragments, OAS components and JSON Schemas into an API-fragment project. The fragments that you import can be written in RAML 0.8, RAML 1.0, and OAS 3.0. You can import annotation types, data types, examples of JSON response payloads, libraries, resource types, security schemes, traits, and OAS components. You must set one of the fragments in your project as the root file of the project.
There are three locations that you can import from: your computer, a location at a URL, and Anypoint Exchange.
## Procedures
  * Import a file or the content of a ZIP file that is stored on your computer, if you are using the text editor:
    1. Click the gear icon in the top-right corner of the text editor and select **Import**.
    2. In the **Import** dialog, select **File or Zip**.
**Result:** The file or files are listed in the left pane of the editor. If you imported a ZIP file that contains files that are in a folder structure, the folder structure is represented in the pane.
  * Import a file that is available through a URL, if you are using the text editor:
    1. Click the gear icon in the top-right corner of the text editor and select **Import**.
    2. In the **Import** dialog, select **URL**.
**Result:** The file is listed in the left pane of the editor.
With this method of importing a file, you can import only one file at a time. If you import a library fragment, you must also import separately each file that the library uses.  
---  
  * To import an API fragment from Exchange, together with its dependencies:
    1. Open the **Import Asset from Exchange** dialog by using either of these methods:
       * If your project contains only the default file that API Designer created together with the project, click the linked text that appears in the **Files** pane.
       * If your project already contains files other than the default project file, click the gear icon in the top-right corner of the text editor and select **Import from Exchange**.
    2. In the drop-down menu in the top-left corner of the dialog, select the business group that owns the asset.
    3. Select one of the assets, which are listed in a table that has these columns:     
The name of an API specification or RAML fragment. 

**Version**
    
The version of a specification or fragment.
Select the **Include snapshots** checkbox in the bottom-left corner of the dialog to include snapshots in this column.     
The type of asset.
The value must be **API Fragment**. 

**Language**
    
You can choose between RAML, OAS, or JSON Schema. 

**Date modified**
    
The date that the currently selected version of the currently selected asset was published. 

**Created by**
    
The user ID of the person who published the currently selected version of the currently selected asset.
    4. Click **Import asset**.
**Result:** The file or files are listed in the left pane of the editor.


## See Also
  * Root Files in Projects in the Text Editor