BassemE/mulesoft-documentation-embeddings huggingface dataset:
Azure Event Hubs Connector 1.1 | MuleSoft Documentation
# Azure Event Hubs Connector 1.1
Support Category: Select
Anypoint Connector for Azure Event Hubs (Azure Event Hubs Connector) enables support for event producing and consuming.
Azure Event Hubs is a big data streaming platform and event ingestion service. It can receive and process millions of events per second. Data sent to an event hub can be transformed and stored by using any real-time analytics provider or batching/storage adapters.
For information about compatibility and fixed issues, refer to the Azure Event Hubs Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * Azure Event Hubs
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


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


## Common Use Cases for the Connector
Some common use cases for Azure Event Hubs Connector include:
  * Sending an event
  * Sending an event to a specific partition
  * Sending a batch of events
  * Listening to events on Event Hubs
  * Listening to events on a specific partition


## Connection Types
Azure Event Hubs Connector uses the SAS authentication and Active Directory authentication type.
## Security
To get secured authentication to Azure Event Hubs, review the following recommendations:
  * Use Java to send events to or receive events from Azure Event Hubs
  * Authorizing access to Event Hubs resources using Shared Access Signatures
  * Passwordless connections for Azure services


## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Azure Event Hubs Messaging Connector Reference
  * MuleSoft Help Center
Azure Service Bus Management Connector 1.0 | MuleSoft Documentation
# Azure Service Bus Management Connector 1.0
Anypoint Connector for Microsoft Azure Service Bus Management (Azure Service Bus Management Connector) enables management integration with Azure Service Bus on the cloud. This connector connects to the Azure REST API and supports management operations for queues, topics, and subscriptions. In addition, you can use the built-in management API to discover Azure Service Bus objects automatically and provision them.
This connector supports integrations with Azure Service Bus (cloud). It does not work with Microsoft Windows Service Bus (on-premise). To connect with Microsoft Windows Service Bus on-premise, use Anypoint Connector for Microsoft Windows Service Bus.   
---  
To use the Azure management API for message integration with Azure Service Bus on the cloud, use the Anypoint Connector for Azure Service Bus.
For compatibility information, see the Azure Service Bus Management Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Microsoft Azure REST API
  * Anypoint connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have access to:
  * The Microsoft Azure target resource
  * Anypoint Studio version 7.x or later


## Common Use Cases For the Connector
Common use cases for this connector include:
  * Creating, modifying, and deleting a queue, topic, and subscription
  * Retrieving all queues, topics, and subscriptions from the Azure Service Bus instance


For examples, see Examples.
## Audience
  * New user
To create your Mule app, see:
    * Using Anypoint Studio to Configure Microsoft Azure Connector
    * Additional Configuration Information to help extend your understanding of Azure Service Bus Management connector
    * Examples, which provide one or more use cases for the connector
  * Advanced user
Read the following:
    *     * Additional Configuration Information


## Next Step
After you complete the prerequisites and experiment with the examples, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Advanced Mule Concepts | MuleSoft Documentation
# Advanced Mule Concepts
After you become familiar with the basics of Mule application development and Mule runtime engine (Mule) concepts, you can focus on more advanced features, such as the execution engine, the classloading isolation mechanism, and distributed file polling.
Learn about the execution engine to understand how Mule runtime engine processes the operations in a Mule application flow, and to understand how to change the thread pools if needed. Mule runtime engine uses execution metadata provided by operations in a flow to perform autotuning.
The classloading isolation mechanism implemented in Mule 4 is designed to make upgrades easier by preventing components from exposing their internal resources. All components interact with each other through their defined APIs so that only exposed resources can be accessed by other components. Classloading isolation ensures that a component’s internal content is protected and can be changed any time, without affecting other components.
Mule 4 supports distributed file polling, which allows connectors to read files from certain directories as they are created. Distributed file polling also makes it possible to poll files in all cluster nodes.
Mule 4 also supports distributed locking, which provides the ability to create locks for synchronizing access to resources within Mule components.
Learn more about Mule data types to understand how Mule centralizes data access across different components, and also how DataWeave uses this information to determine which reader and writer to use.
You can refer to the Javadocs for Mule Kernel (the community edition of Mule runtime engine) to learn definitions for classes, fields, and data types.
You can see a list of third-party software that is included as part of Mule runtime engine as internal dependencies.
Importing and Publishing API Specs | MuleSoft Documentation
# Importing and Publishing API Specs
Use API Designer for importing and Publishing your API Specifications.
With API Designer, you can:
  * Import Files into an API-Specification Project
  * Import Files into an API-Fragment Project
  * Add Dependencies to an API-Specification Project
  * View the Source Project for Assets Published to Exchange
  * Publish an API Specification
  * Share an OAS 3.0 API Specification as RAML
APIkit for AsyncAPI | MuleSoft Documentation
# APIkit for AsyncAPI
APIkit for AsyncAPI enables you to implement event-driven APIs. You can create AsyncAPI specifications using asynchronous messaging protocols. It provides modules with operations that you can add and configure when implementing your API in a Mule project.
AsyncAPI is based on event-driven architectures that communicate data between different systems reliably and efficiently.
The APIkit scaffolder generates a minimal implementation of an API Specification within a Mule project that you can further develop. Scaffold your Mule application from Exchange, and re-scaffold your Mule application in Anypoint Code Builder or Anypoint Studio.
APIkit for AsyncAPI supports validation of messages by checking if the messages in the `listener` and `publish` operations conform to the schema.
APIkit for AsyncAPI supports the AsyncAPI 2.6 spec.   
---  
## See Also
  * APIkit for AsyncAPI Module Reference
  * APIkit for AsyncAPI Error Handling Reference
  * AsyncAPI Specifications
Crypto (dw::Crypto) | MuleSoft Documentation
# Crypto (dw::Crypto)
This module provide functions that perform encryptions through common algorithms, such as MD5, SHA1, and so on.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::Crypto` to the header of your DataWeave script.
## Functions
Name | Description  
---|---  
Computes an HMAC hash (with a secret cryptographic key) on input content.  
Computes an HMAC hash (with a secret cryptographic key) on input content, then transforms the result into a lowercase, hexadecimal string.  
Computes the MD5 hash and transforms the binary result into a hexadecimal lower case string.  
Computes the SHA1 hash and transforms the result into a hexadecimal, lowercase string.  
Computes the hash value of binary content using a specified algorithm.
Managing CloudHub and Hybrid Settings | MuleSoft Documentation
# Managing CloudHub and Hybrid Settings
On the **Settings** page in Anypoint Monitoring, you can:
  * Find the instructions to install Anypoint Monitoring on an on-premises server to monitor Mule applications running on that server.
  * Enable (or disable) monitoring for applications running on Mule.


## Access the Settings Page
To access the **Settings** page, you must have the Anypoint Monitoring User and the Runtime Manager - Read Applications permissions. See Granting Permissions and Roles to Users.
  1. Log in to Anypoint Platform with a user account that has permission to access Anypoint Monitoring content.
  2. Navigate to **Anypoint Monitoring**.
  3. In the Anypoint Monitoring navigation menu, click **Settings**.
  4. To monitor applications deployed to a local server, select **Hybrid** , and follow the procedure to install Anypoint Monitoring agent from the latest version of the agent’s installer in `am.zip`.
To use an earlier version, see the knowledge article Unable to Download Anypoint Monitoring Agent Installer for Windows after April 1st, 2025 from Anypoint Monitoring UI.
  5. To enable (or disable) monitoring for apps deployed to CloudHub, select **CloudHub**.


Anypoint Monitoring is enabled by default for all CloudHub 2.0 applications.   
---  
## See Also
  * Install Anypoint Monitoring On-Premises
  * Configure Anypoint Monitoring for Mule Apps
Check Folder | MuleSoft Documentation
# Check Folder
Use this action step to check if a folder exists in the specified directory path.
## Properties
  * **Common**
See Common Properties for a description.
  * **Folder Operations Settings**
    * **Check if the folder**
Select between **Exists** or **Not Exists** to determine the type of check to perform.
    * **Directory Path**
Path to the directory to check the existence of the folder.


## Inbound Variables
  * **Directory Path**


## Outbound Variables
  * **Directory Path**
  * **Check Succeeded**


## See Also
  *
X12 EDI Connector 2.17 - XML and Maven Support | MuleSoft Documentation
# X12 EDI Connector 2.17 - 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.
When 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/x12-edi
http://www.mulesoft.org/schema/mule/x12-edi/current/mule-x12-edi.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<mule xmlns:x12-edi="http://www.mulesoft.org/schema/mule/x12-edi"
	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/x12-edi
	http://www.mulesoft.org/schema/mule/file/current/mule-file.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>mule-x12-connector</artifactId>
 <version>2.x.x</version>
 <classifier>mule-plugin</classifier>
</dependency>
```

Replace the <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 `X12 Connector`.
  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
Installing and Configuring RPA Builder | MuleSoft Documentation
# Installing and Configuring RPA Builder
After downloading and installing RPA Builder, configure the connection with RPA Manager and configure the necessary system parameters in your Windows installation to improve the overall performance of your system and improve text recognition features. You can also customize the RPA Builder UI to match your preferences.
## Download and Install RPA Builder
  1. Download the latest RPA Builder installer from the **Home** page of RPA Manager.
  2. Right-click the installer file and select **Run as Administrator**.
  3. Continue the installation process until it finishes.
  4. Ensure you have the required privileges assigned in RPA Manager.
See Assign Privileges to a Users for instructions. If you are in doubt, contact your organization’s RPA administrator.


## Connect RPA Builder with RPA Manager (Anypoint Platform)
After opening RPA Builder for the first time, configure the connection with RPA Manager using your Anypoint Platform credentials:
  1. Provide your RPA Manager instance address.
Use **Proxy Settings** to configure a specific proxy to connect with Anypoint Platform.
By default, **Use System Proxy Settings** is enabled so that RPA Builder uses the same proxy configuration your system uses to access internet.
  2. Log in using your Anypoint Platform account.


After you log in, RPA Builder remains connected using the specified Anypoint Platform credentials.
To connect to a different RPA Manager instance or use other login credentials:
  1. In the top menu bar, navigate to **Options > Account**.
  2. Click **Sign out**.
  3. Provide the new RPA Manager address and login credentials.


## Connect RPA Builder with RPA Manager (Legacy)
If your organization is not migrated to Anypoint Platform, provide your RPA Manager user credentials to establish the connection after opening RPA Builder for the first time:
  1. In the top menu bar, select **Options** > **Repository**. (This menu opens automatically the first time you open RPA Builder)
  2. Configure the required values:
     * **RPA Manager Address**
The URL of the RPA Manager instance RPA Builder connects to. Do not specify the protocol (`https://`) as part of this value.
     * **User Name**
The RPA Manager user name that RPA Builder uses to log in.
     * **Password**
The RPA Manager password that RPA Builder uses to log in.
     * **Proxy Settings**
Use to configure a proxy to connect to RPA Manager.
By default, **Use System Proxy Settings** is enabled so that RPA Builder uses the same proxy configuration your system uses to access internet.
  3. Click **Test Connection** and confirm that the login succeeds.
If the login attempt fails, verify the provided details and try again.
  4. Click **OK**.


## See Also
  * Checking System Parameters
  *   * Modifying the User Interface
Resource Sizing for Self-Managed Flex Gateway | MuleSoft Documentation
# Resource Sizing for Self-Managed Flex Gateway
Before getting started with Flex Gateway, analyze and choose your configuration to obtain the best performance and auto-scaling rate.
When assigning resources for a replica node, consider:
  * Number of APIs
  * Amount of memory the node needs
  * Processing power for the node
  * Number of policies in each API
  * Amount of traffic each node handles
  * Amount of time the node takes to answer the request (latency)
  * Type of traffic the node handles, and within the traffic:
    * The number of requests per second (RPS) the node handles
    * Size of each request (bytes)


## Resources
The following table describes the resources you must allocate to your replica node according to your environment:
Node Size | CPU | RAM  
---|---|---  
1-2 cores  
2-4 cores  
8-16 cores | 16-32 GB  
For IBM Power10 deployments, allocate 5-16 CPU cores for a "Large" node.   
---  
Nodes belonging to a cluster must be of the same size.   
---  
## Cluster Size
The following table describes appropriate node and cluster sizes:
Node Size | Number of APIs | Number of Policies | Expected Latency | Expected Throughput | Target Environment  
---|---|---|---|---|---  
< 500 RPS | Dev/test cluster  
< 2500 RPS | Production cluster  
< 10000 RPS | Mission-critical clusters  
These sizing figures are per node. API configurations replicate to all nodes in the cluster. For example, for 10 APIs deployed each with three policies, the 10 APIs and their policies are deployed to each node in the cluster.
The traffic is distributed across all nodes in the cluster. A small cluster node supports up to 500 RPS, but if the cluster has two nodes then the total traffic that the cluster allows is 1000 RPS (500 RPS for each node). Exceeding the recommended traffic per node eventually causes increased CPU usage. To avoid this issue, you must increase the size of all nodes in the cluster or scale horizontally.
High CPU usage can lead to increased latency. In such a case, proceed with horizontal scaling or increase the node size.
High memory consumption can lead to out-of-memory errors. To solve this issue, increase the memory allocation or the node size. Horizontal scaling might not help solve issues in this situation. You must increase memory first, and scale horizontally later.
These guidelines are for a cluster with an average request size of 1 KB and four policies implemented. Adjust your parameters depending on your use case.
The most commonly used out-of-the-box policies are:
  * Message logging
  * Rate limiting
  * JWT validation
  * Header injection


Using TLS affects the response time and the process consumption.
JSON Threat Protection | MuleSoft Documentation
# JSON Threat Protection
By its nature, JSON is vulnerable to JavaScript injection. When you parse the JSON object, the malicious code inflicts its damages. An inordinate increase in the size and depth of the JSON payload can indicate injection. Applying the JSON threat protection policy can limit the size of your JSON payload and thwart recursive additions to the JSON hierarchy.
## Protecting JSON Applications
By its nature, JSON is vulnerable to JavaScript injection. When you parse the JSON object, the malicious code inflicts its damages. An inordinate increase in the size and depth of the JSON payload can indicate injection. Applying the JSON threat protection policy can limit the size of your JSON payload and thwart recursive additions to the JSON hierarchy.
Configure JSON threat protection using the procedure to protect JSON applications.
  1. Click the version number of an API.
  2. On the API dashboard, click Policies.
The list of any applied policies appears.
  3. In Apply New Policy.
  4. In Select Policy, choose JSON Threat Protection, and click Configure Policy.
  5. Specify set limits, and click apply to start protecting your JSON code. The following example shows configuration of a JSON threat protection policy.
Configuring a value of -1, for example for node depth, specifies unlimited depth.


## Responses to JSON Threat Protection Policies
  * 200
Message successfully sent.
  * 400 Bad Request
Any request that violates the configured limits causes a Bad Request error.
Develop the American Flights App | MuleSoft Documentation
# Develop the American Flights App
Cloud IDE 
Desktop IDE 
Use Anypoint Code Builder to create and implement an API specification that returns flight information from a MySQL database:
  1. Designing the American Flights API Spec:
     * Start the American Flights API specification.
     * Add a resource and methods.
     * Add query parameters and nested resources.
     * Add fragments and examples:
       * Add API fragments from Exchange for a data type and examples to the American Flights API specification.
       * Create your own examples for the specification.
       * Add a custom message for a response.
  2. Adding Examples to the API Spec
Use the Mocking Service in the API Console to check the request and responses that you configured for American Flights API.
  3. Publishing the API Spec to Anypoint Exchange:
Publish the American Flights API specification to Exchange so that other team members can find and implement it.
  4. Create an integration application for the American Flights example:
    1. Integrating American Flights Processes:
Start by creating a basic integration for the American Flights example. This integration provides some of the logic for processing requests from the American Flights API.
    2. Connecting to a Database from the App:
       * Import the Anypoint Connector for Database (Database Connector) from Exchange.
       * Configure a database operation to connect to an external database from your Mule flow.
    3. Transforming Flight Data with DataWeave:
Use DataWeave to transform and match flight data to your API specification.
  5. Implementing the American Flights API Spec:
     * Import your American Flights API specification from Anypoint Exchange.
     * Scaffold the specification into the American Flights project that you are developing.
     * Add logic to implement an endpoint in the API.
  6. Debugging the American Flights App:
     * Prepare to debug your Mule application by adding Logger and Set Variable components to better understand the behavior of your flows.
     * Set up breakpoints to stop your Mule application at specific points during a debug session.
     * Run a debug session, and inspect the message and variables at different points during your application’s execution.
  7. Deploying the American Flights App:
     * Deploy your American Flights application to CloudHub.
     * Enable your team to send requests to your API and return flight information from a database.
View Client Applications with Anypoint DataGraph Contracts | MuleSoft Documentation
# View Client Applications with Anypoint DataGraph Contracts
You can revoke a client application’s access to Anypoint DataGraph, delete the application, or remove the application owner.
To view or manage client applications with Anypoint DataGraph contracts, click **Client Applications** from the sidebar in **API Manager** :
Filter applications based on contract types. Select **Clients with DataGraph Contracts** to view only applications with DataGraph contracts.  
---  
Choose a client applications to see its contract details.  
View the contract options for a selected client application.  From this view, you can reset a client secret, revoke a client contract, delete an application, or remove the application owner.  
## See Also
  * Anypoint DataGraph Overview
  * Anypoint DataGraph Supported Authentication Methods
Shopify Connector 1.1 | MuleSoft Documentation
# Shopify Connector 1.1
Anypoint Connector for Shopify (Shopify Connector) gives you access to the Shopify platform. This connector exposes operations provided by the Shopify REST Admin API.
For information about compatibility and fixed issues, see the Shopify Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Shopify Connector’s API
  * 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:
  * Credentials to access the Shopify target resource
  * Anypoint Platform
  * Anypoint Studio version 7.5.0 or later


## Common Use Cases For the Connector
Some common use cases for Shopify Connector include:
  * Syncing a new customer’s information when they place an order
  * Storing information when a new order is placed through a client’s Shopify store
  * Managing items when new products are created in Shopify


## Connection Types
Shopify Connector uses the following authentication methods:
  * Basic Auth Uses a username and password for authentication.
  * OAuth2 Delegates user authentication to the service hosting the user account.


## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Shopify Connector Reference
  * MuleSoft Help Center
Testing a Connection Configuration | MuleSoft Documentation
# Testing a Connection Configuration
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.
Most connectors provide an operation, such as the HTTP Listener operation, that triggers the flow to start. These operations typically include connection configurations that you can test.
## Test Connection from the Configuration Panel
You can test the connection from the connectors **Configuration** panel. For example, to test an HTTP Listener connection:
Click the **+** icon on the connector to open the configuration panel.  
---  
After filling in the required fields, click **Test Connection**.  
The status bar shows the progress:
  * **Verifying connection** indicates that the test is in progress.
  * **Connection is valid** indicates a successful connection.
  * **Invalid Connection Got status code: 500 when trying to resolve a Mule Runtime operation** indicates a connection error.


## Test Connection from the Configuration XML
You can test the connection from the configuration XML. For example, to test an HTTP Listener connection, click **Test Connection** in the configuration XML:
The status bar shows the progress:
  * **Verifying connection inbound-request** indicates that the test is in progress.
  * **Connection is valid** indicates a successful connection.
  * **Invalid Connection Got status code: 500 when trying to resolve a Mule Runtime operation** indicates a connection error.
A common code `500` error is `port 8081: Address already in use`. For port conflicts, configure a different port, such as `8082`, and retest the connection.


Before publishing, run your application in debug mode.
Configuring SMTP in Anypoint Platform PCE | MuleSoft Documentation
# Configuring SMTP in Anypoint Platform PCE
Because Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) does not provide an SMTP server, you must set up your own SMTP email server to deliver email alerts generated by Runtime Manager. The SMTP email server also sends email messages for platform infrastructure alerts, including CPU, memory, and disk alerts.
You must direct your local installation of Anypoint Platform PCE to this server from the Access Management panel.
Only SMTP servers with authentication are supported (anonymous SMTP relay servers are not supported). SMTPS is not supported.   
---  
## Connect to an Existing SMTP Server
  1. From Anypoint Platform, select **Access Management**.
  2. Select **SMTP**.
  3. Provide the following parameters information for your SMTP server:


Field | Description | Example  
---|---|---  
Host name of your SMTP server. |  `smtp.gmail.com`  
Port used to communicate to your SMTP server.  
Username to authenticate to your SMTP server. |  `mulesoft.onprem.smtp@gmail.com`  
SMTP password. |  `examplepassphrase`  
To use anonymous logins for your SMTP server, leave the **Username** and **Password** fields empty.   
---  
  4. After entering your configuration, select **Save**.


## See Also
  * Configuring Anypoint Platform PCE
QuickBooks Online Connector 2.0 | MuleSoft Documentation
# QuickBooks Online Connector 2.0
Anypoint Connector for QuickBooks Online (QuickBooks Online Connector) synchronizes data and automates business processes between QuickBooks Online and third-party applications, either on-premises or in the cloud.
QuickBooks Online provides cloud-based accounting software that helps companies manage core business processes, ERP financials, e-commerce, inventory, and more.
For information about compatibility and fixed issues, see the QuickBooks Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The QuickBooks API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


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


## Common Use Cases For the Connector
Common use cases for QuickBooks Online Connector include the following:
  * Eliminating data staleness and manual entry errors by automatically syncing your ERP data in QuickBooks Online with your accounts and customer data in Salesforce.
  * Reducing cycle times by automating business-critical flows across QuickBooks Online and other cloud-based and on-premises systems.
  * Boosting employee productivity by saving many hours that are otherwise spent keeping your QuickBooks Online system in sync with other applications in your IT stack.


## Connection Types
QuickBooks Online Connector uses the OAuth 2.0 authentication type, which delegates user authentication to the service hosting the user account.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Using Utility Classes From a Test | MuleSoft Documentation
# Using Utility Classes From a Test
Anypoint Code Builder 
Anypoint Studio 
When developing test cases, you might want to use custom Java classes located in `src/test/java`. You can use Java classes through DataWeave or through Java Module.
When using custom classes, the package of the class must be exported in the `mule-artifact.json` file:
```
{
 "minMuleVersion": "4.x.x",
 "classLoaderModelLoaderDescriptor": {
  "id": "mule",
  "attributes": {
   "exportedPackages": [
    "com.example.test"
   ]
  }
 }
}
```

For example, assume that you want to use in an MUnit test a `MyUtilClass.java` class located in `src/test/java/com/example/`:
MyUtilClass
```
package com.example.test;
public class Helper {
 public static long getCurrentMillis() {
  return System.currentTimeMillis();
 }
}
```

## Invoke Your Java Class Using DataWeave
To invoke static methods using DataWeave you must add the `java!` prefix to the package name of the class:
Use a class in DataWeave
```
<munit:test name="usingJavaInDW">
  <munit:behavior>
    <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
  </munit:behavior>
  <munit:execution>
    <flow-ref name="myFlow"/>
  </munit:execution>
</munit:test>
```

## Invoke Your Java Class Using Java Module
To invoke a custom Java class using Java Module:
  1. Ensure that Java Module is in your project:
Java Module dependency
```
<dependency>
  <groupId>org.mule.module</groupId>
  <artifactId>mule-java-module</artifactId>
  <version>${javaModule.version}</version>
  <classifier>mule-plugin</classifier>
  <scope>test</scope>
</dependency>
```

  2. Use any of the Java Module’s operations. For this example, invoke a static method of a class:
Use a class with the Java Module
```
<munit:test name="usingJavaInDW">
  <munit:behavior>
    <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
  </munit:behavior>
  <munit:execution>
    <flow-ref name="myFlow"/>
  </munit:execution>
</munit:test>
```
Streaming Strategy Reference | MuleSoft Documentation
# Streaming Strategy Reference
You can use the default streaming strategy settings or configure them for your needs. See Streaming in Mule Apps for more details on these strategies.
## Repeatable In-Memory Stream Reference
Parameter Name | Is required? | Expressions | Default Value | Description  
---|---|---|---|---  
`initialBufferSize` | Amount of memory allocated to consume the stream and provide random access to it. If the stream contains more data than fits into this buffer, the memory expands according to the `bufferSizeIncrement` attribute, with an upper limit of `maxInMemorySize`.  
`bufferSizeIncrement` | Amount to expand the buffer size if the size of the stream exceeds the initial buffer size. Setting a value of zero or lower indicates that the buffer does not expand and that a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised when the buffer is full.  
`maxInMemorySize` | Maximum amount of memory to use. If the size of the stream exceeds the maximum, a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower or equal to zero means no limit. Defaults to 1024  
`bufferUnit` | The unit in which all these attributes are expressed. Possible values: BYTE, KB, MB, GB.  
### File-Stored Input Stream
File storage is only available in Mule Enterprise Edition (Mule EE).
Parameter Name | Is required? | Expressions | Default Value | Description  
---|---|---|---|---  
`inMemorySize` | Defines the maximum memory size for the stream to keep data in memory. If more than the configured amount is consumed, the strategy starts to buffer the content on disk.  
`bufferUnit` | The unit in which all these attributes are expressed. Possible values: BYTE, KB, MB, GB.  
## See Also
  * Streaming in Mule Apps
days | MuleSoft Documentation
# days
## days(nDays: Number): Period
Creates a Period value from the provided number of days.
The function applies the `period` function to input that is a whole number and the `duration` function to decimal input.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The number of hours as a whole or decimal number. A positive or negative number is valid.  
### Example
This example shows how `days` behaves with different inputs. It adds and subtracts hours from DateTime values. It also converts the decimal value `4.555` into a number of hours, minutes, and second in the Period format (`PT109H19M12S`) and the whole number `4` into a number of days in the Period format (`P4D`).
#### Source
```
%dw 2.0
import * from dw::core::Periods
output application/json
---
{
  tomorrow: |2020-10-05T20:22:34.385Z| + days(1),
  yesterday: |2020-10-05T20:22:34.385Z| - days(1),
  decimalDaysPlusQuarter: |2020-10-05T00:00:00.000Z| + days(0.25),
  decimalDaysPlusHalf: |2020-10-05T00:00:00.000Z| + days(0.5),
  decimalDaysPlusThreeQuarters: |2020-10-05T00:00:00.000Z| + days(0.75),
  decimalInputAsPeriod : days(4.555),
  fourDayPeriod: days(4),
  negativeValue: days(-1)
}
```

#### Output
```
{
  "tomorrow": "2020-10-06T20:22:34.385Z",
  "yesterday": "2020-10-04T20:22:34.385Z",
  "decimalDaysPlusQuarter": "2020-10-05T06:00:00Z",
  "decimalDaysPlusHalf": "2020-10-05T12:00:00Z",
  "decimalDaysPlusThreeQuarters": "2020-10-05T18:00:00Z",
  "decimalInputAsPeriod": "PT109H19M12S",
  "fourDayPeriod": "P4D",
  "negativeValue": "P-1D"
}
```
JSON Threat Protection Policy | MuleSoft Documentation
# JSON Threat Protection Policy
**Policy Name** | JSON Threat Protection  
---|---  
Protects against malicious JSON in API requests  
Security  
**First Mule version available**  
**Returned Status Codes** | 400 - Bad Request  
## Summary
The JSON Threat Protection policy does not support SOAP APIs.   
---  
Applications processing JSON requests are susceptible to attacks characterized by unusual inflation of elements and nesting levels. Attackers use recursive techniques to consume memory resources. Dramatic swings in the size of the application data often signal a security problem. The JSON Threat Protection policy helps protect your applications from such intrusions.
If you find that attacks on your Anypoint Platform setup are difficult to detect, design your services architecture with layers of protection in addition to JSON Threat Protection.
## Configuring Policy Parameters
### Mule Gateway
When you apply the JSON Threat Protection policy to your API from the UI, the following parameters are displayed:
**Description**  
---  
Maximum Container Depth | Specifies the maximum nested depth. JSON allows you to nest the containers (object and array) in any order to any depth  
Maximum String Value Length | Specifies the maximum length of a string value  
Maximum Object Entry Name Length | Specifies the maximum string length of an object’s entry name  
Maximum Object Entry Count | Specifies the maximum number of entries in an object  
Maximum Array Element Count | Specifies the maximum number of elements in an array  
A value of -1 indicates that the field value has no limits.  
---  
## Payload Example
If your payload contains the following example JSON:
```
{
  "Players":[
   {
     "Name":"Sachin",
     "Email":"sachin.tendulkar@example.com"
   },
   {
     "Name":"Suryakumar",
     "email":"Surya@example.com"
   },
   {  "Name":"Bhuvi",
     "email":"bhuvi@example.com"
   },
   {
     "Name":"Jonty",
     "Email":"jonty@example.com"
   }
  ]
}
```

The policy defines the example parameter values as follows:
Parameter | Value | Explanation  
---|---|---  
Maximum Container Depth | The depth of the `Name` and `Email` entries  
Maximum String Value Length | The length of `sachin.tendulkar@example.com`  
Maximum Object Entry Name Length | The length of the `Players` object entry name  
Maximum Object Entry Count | The number of entries in each `Players` object  
Maximum Array Element Count | The number of elements in the `Players` array
Runtime Variables | MuleSoft Documentation
# Runtime Variables
The Runtime Variables action step provides a set of variables that the workflow populates at runtime. Use these variables to get information from the runtime context.
The following variables are available:
  * **Project Name**
Name of the _Workflow_ project
  * **Project GUID**
GUID of the _Workflow_ project
  * **Run GUID**
GUID related to the execution of the _Workflow_ (regenerated for each run)
  * **Time**
Actual time as local time or UTC in configurable format
  * **Date**
Actual date as local time or UTC in configurable format
  * **HostName**
Name of _Host_ system
  * **UserName**
Name of the user
  * **RandomVariable**
Positive random number with a configurable range of values. The workflow generates a different number on each run.
  * **Business Process ID**
ID of the business process
  * **Session Id**
Terminal session ID of the environment where the bot is running
  * **Session Name**
Terminal session name of the environment where the bot is running
  * **Bot ID**
GUID of the bot that is executing the workflow


_RandomVariable_ is an integer value. All other variables are strings.
Debugging the _Runtime Variables_ action step is not possible. Therefore, the debug functionality is disabled and you cannot set breakpoints for this action step.
## Properties
  * **Write Runtime Variables to Logfile**
When enabled, the workflow writes runtime variables to the Stc log file.


## Outbound Variables
  * **Runtime Variables.[name of the runtime variables]**
Content of _Runtime variables_.


## Wizard
Use the wizard to add new runtime variables and specify their **Name** and **Description**.
To make variables available in later transactions, select **Make Variables available in all further Transactions**.
Use the **Delete** button to remove variables.
The values listed in **Sample Data** are for local testing. If a bot completes the workflow, the workflow re-determines the values at each run.
Some variables such as **Random Variable** show a **Settings** menu that you can expand for further configuring the variable.
Step 9: Monitor the Automation | MuleSoft Documentation
# Step 9: Monitor the Automation
After publishing the process to Exchange and executing it from Composer, use the Process Monitoring module to see a summary of the deployed bots and the process executions.
## Step 9.1: See a Live Stream of the Deployed Process
To see a live stream of the deployed process:
  1. In Composer, open the flow you created in Step 8.1: Create a New Composer Flow for editing and click **Test**.
  2. Switch to RPA Manager and open the **Process Monitoring** module.
  3. Click on **Process Streaming**.
  4. Refresh the page and click **Show process streams**.
If the button is disabled and shows **No sessions running** , it means the process has not started yet. In that case, refresh the page and try again.
  5. Click **On** to enable showing screen captures of this process.


The **Process Streaming** section shows a window for each run configuration that is currently executing. The stream consists of a sequence of images that the RPA bot records during process execution.
If this section shows empty, it is possible that the execution of the process has already finished, meaning that it is not running now and it cannot provide a stream of the process.   
---  
## Step 9.2: Monitor the Deployed Process
To see the active bots and the deployed processes:
  1. In RPA Manager, open the **Process Monitoring** module.
  2. Click on **Bot State and Operation**.


The **Bot State and Operation** section shows a list of your configured bots and the current process executions.
Note that the **Work done** column shows **1** , which confirms that the execution of the process finished one time.
## Next Steps
At this point you finished creating a Composer Flow that calls an automated process that you previously created and published to Exchange using MuleSoft RPA.
You can use this project as a template or starting point to develop further automation projects and integrations between MuleSoft Composer and RPA.
## See Also
  *
Versioning Behavior in DataWeave | MuleSoft Documentation
# Versioning Behavior in DataWeave
New minor versions of DataWeave can introduce changes that modify the way the language behaves. You can use DataWeave system properties that behave as _compatibility flags_ to continue using existing scripts that depend on the previous behavior. However, each flag defines a deletion version, which identifies the version in which the flag is no longer available and the behavior that it controls defaults to the changed behavior.
Specifying a DataWeave language level indicates to the DataWeave runtime what compatibility flags are available. To upgrade and maintain backward compatibility, you can set the language level of a previous version so that the flags available on that version remain visible even if they expire in the DataWeave version to which you upgrade. The language level defaults to the running DataWeave version and has to be at most the same as the runtime version.
For Mule applications, the language level is determined by the application’s `minMuleVersion` setting (see Feature Flags Reference in the Mule documentation). Given the `minMuleVersion`, the language level is computed by subtracting two major versions, as the following table shows:
minMuleVersion | Language Level  
---|---  
Setting the Mule version configures the application to use the corresponding DataWeave language level. This setting is independent of the DataWeave syntax version, which is set through a DataWeave script’s `%dw` directive. For details, see DataWeave Header. For example, the `com.mulesoft.dw.xml_reader.honourMixedContentStructure` system property is a compatibility flag for language level 2.4, when it was introduced, and it is removed in DataWeave 2.6. In DataWeave 2.6, the property is _visible only if_ you set the language level to 2.4 or 2.5. If you choose language level 2.4 it defaults to the old behavior, if you choose language level 2.5 it defaults to the new behavior.
Hardware and Software Requirements | MuleSoft Documentation
# Hardware and Software Requirements
If you plan to install Mule and run it on premises, review these minimum hardware and software requirements before you install.
## Minimum Hardware Requirements
  * 2 GHz CPU or 1 virtual CPU in virtualized environments.
  * 1 GB of RAM.
  * 4 GB of storage.


Adjust RAM to match your latency requirements and the size and number of simultaneous messages that applications process.
Mule supports the x86 and x64 architectures.
## Required Software
Verify that you use a supported version of Java before you install Mule.
Software | Version  
---|---  
Though you can run a different JDK of choice, MuleSoft doesn’t support or take action to fix issues if they are traced back to the JDK.   
---  
## Supported Software
Mule is supported on any operating system that runs a Java Runtime Environment (JRE) from a supported JDK.
### Tested Software
The Mule runtime engine passed functional testing against the following software and operating systems:
Software | Version  
---|---  
MacOS 10.15, HP-UX 11i V3, AIX 7.2, Windows Server 2019, Windows 10, Solaris 11.3, Red Hat Enterprise Linux 9.4, Ubuntu Server 20.04  
Adoptium OpenJDK distribution  
This version of Mule runtime engine is bundled with the Runtime Manager agent plugin version 2.4.21. For Runtime Manager Agent compatibility, see Runtime Manager Agent Release Notes.
## See Also
  * Anypoint Platform PCE Prerequisites