BassemE/mulesoft-documentation-embeddings huggingface dataset:
Writing and Running BAT Tests in IntelliJ IDEA | MuleSoft Documentation
# Writing and Running BAT Tests in IntelliJ IDEA
You can write and run BAT tests in IntelliJ IDEA. The DataWeave 2.0 Intellij plugin, which adds the required support, offers these features:
  * Support for local refactoring
  * Syntax highlighting
  * A view of the structure of the BAT test that you are editing
  * MULE XML language injection
  * String interpolation
  * Support for running tests


## About This Task
The steps in this procedure explain how to modify a BAT project for support in IntelliJ IDEA, open that project, create a new test file, and run a test.
## Before You Begin
  * Ensure that the DataWeave 2.0 IntelliJ plugin in installed in your IntelliJ IDEA editor. You can install it by following these steps:
    1. In IntelliJ IDEA, open the preferences.
    2. Select **Plugins** and then click **Browse Repositories**.
    3. Click **Manage Repositories**.
    4. Click the plus icon to add a custom repository.
    5. Paste in the following URL: https://plugins.jetbrains.com/plugins/Develop/10362
    6. Click **Check Now** to verify that the repository is reachable. Then, click **OK**.
    7. In the **Browse Repositories** dialog, search on `dataweave`.
    8. Select **DataWeave 2.0 IntelliJ Plugin** and then click **Install** in the plugin details.
    9. Restart IntelliJ IDEA.
  * Log in to BAT in a terminal window and run the `bat --update` command to be sure that you have the latest version of the BAT CLI.


## Write and Run BAT Tests in IntelliJ IDEA
  1. If you do not already have a BAT project that you want to work with, create one with the `bat init` command in a terminal window.
  2. Inside the project folder, run the command `bat idea`.
**Result** : The command creates a new file in the project: `_project-name_.iml`
  3. In IntelliJ IDEA, open the project by selecting the project folder.
  4. In the **Project Structure** dialog, set the Java SDK that you want to use for your project.
  5. If you want to write a test, create a new test file:
    1. Right-click the folder that contains your tests and select **New** > **DataWeave Component**.
    2. In the dialog box, select **Bat Test** in the **Kind** field.
**Result** : A new Bat Test file appears in the Tests folder. Double-click that to open it in the editor pane. Write your test in that file.
  6. To run a test:
    1. Open the test in the editor.
    2. Right-click in the file and select **Run** > **Bat Test _filename_**.
**Result** : The output of the test appears in the **Run** tool window.
Transaction | MuleSoft Documentation
# Transaction
_Transactions_ are used to split _Workflow_ s into logical, self-contained units. They provide structure for your _Workflow_ s, which is more important the larger a _Workflow_ gets. They do not have additional properties.
Upgrading and Migrating Microsoft Dynamics for Finance and Operations Connector to Version 3.0 | MuleSoft Documentation
# Upgrading and Migrating Microsoft Dynamics for Finance and Operations Connector to Version 3.0
Anypoint Connector for Microsoft Dynamics 365 for Finance and Operations (Microsoft Dynamics 365 for Finance and Operations Connector) version 3.0 supports OAuth Client Credentials authentication.
## Supported Upgrade Paths
From Version | To Version  
---|---  
## Changes in This Release
The OAuth Client Credentials connection authentication type has been added in Microsoft Dynamics 365 for Finance and Operations Connector version 3.0. To use this authentication method, you must use Mule 4.2.1 or later.
## Requirements
Ensure that you are using Mule 4.2.1 or later before you perform the upgrade.
## Upgrade Prerequisites
Before you perform the upgrade, you must create a backup of your files, data, and configurations in case you need to restore to them.
## Upgrade Steps
Follow these steps to perform the upgrade:
  1. In Anypoint Studio, open the Mule project for your connector.
  2. In the Anypoint Studio menu, select **Help > Check for Updates**.
  3. Select the latest version of **Mule Server Runtime** and click **Next**.
  4. Select **I accept the terms of the license agreement** and click **Finish**.
  5. In the **Mule Palette** view, click **Search in Exchange**.
  6. In **Add Dependencies to Project** , enter `dynamics finance` in the search field.
  7. In **Available modules** , select **Microsoft Dynamics 365 for Operations** and click **Add**.
  8. Click **Finish**.
  9. Click **Yes** to restart Studio. Studio upgrades the connector automatically.
  10. After Studio restarts, verify that the dependency version is 3.0.0 in the `pom.xml` file in the Mule project.


### Verify the Upgrade
After you install the latest version of the connector, follow these steps to verify the upgrade:
  1. In Studio, verify that there are no errors in the **Problems** or **Console** views.
  2. Verify that there are no problems in the project `pom.xml` file.
  3. Test the connection to verify that the operations work.


### Revert the Upgrade
If it is necessary to revert to the previous version of Microsoft Dynamics 365 for Finance and Operations Connector Connector, change the `mule-microsoft-dynamics365-for-operations-connector` dependency version in the project’s `pom.xml` file to the previous version.
You must update the project’s `pom.xml` file in Anypoint Studio.
Enable HTTPS in Mule 3 API Proxies | MuleSoft Documentation
# Enable HTTPS in Mule 3 API Proxies
Enable HTTPS in your Mule 3.x API proxies to enhance the privacy and protection of your APIs. HTTPS ensures that a client is communicating with the real API and receiving back authentic contents.
To enable your proxy application to support HTTPS requests:
  1. From API Manager, download and deploy an API proxy.
  2. From Anypoint Studio, add a keystore (SSL certificate) to your API proxy (Mule Gateway).
  3. Export the modified proxy.
  4. In Runtime Manager, search for your proxy application.
  5. From **Settings** , select **Upload File** in the **Choose File** menu and select your modified proxy.
Copy Folder | MuleSoft Documentation
# Copy Folder
Copies a source folder to the target directory.
## Properties
  * **Common**
See Common Properties for a description.
  * **Folder Operations Settings**
    * **Copy empty subfolders**
Determines wether to copy empty subfolders or not.
    * **Copy subfolders**
Determines wether to copy all subfolders and files inside them or not.
    * **Destination Directory Path**
Path to the destination directory where to copy the source folder.
    * **Directory Path**
Path to the directory that contains the folder to copy.
    * **Duplicates file handling**
Determines the behavior of the workflow when it finds duplicate files during the copy. Available options are: **Overwrite files** , **Skip files** , and **Force error**.
    * **Filter files**
Defines a filter using wildcards to specify which files to copy. By default, it is set to (`*.*`), meaning all files.


## Inbound Variables
  * **Destination Directory Path**
  * **Filter files**
  * **Copy subfolders**
  * **Copy empty subfolders**
  * **Directory Path**


## Outbound Variables
  * **Is Copied**
  * **Source Directory Path**
  * **Destination Directory Path**


## See Also
  *
Configuring Anypoint MQ | MuleSoft Documentation
# Configuring Anypoint MQ
Configure Anypoint MQ queues, exchanges, and connected apps to send and retrieve messages.
  * Setting Up the Environment and Access Permissions
Use access management to create an environment and manage the roles of users who administer the Anypoint MQ features in Anypoint Platform for your organization.
  * Configuring and Using Queues
Create queues, FIFO queues, and dead-letter queues in Anypoint Platform. Send, receive, and purge messages from queues.
  * Sending Messages to Multiple Queues Using Message Exchanges
Send messages to multiple standard queues simultaneously by binding those queues to a message exchange.
Route messages to specific queues that are bound to the message exchange by creating _intelligent message-routing rules_ on the bindings.
  * Configuring Cross-Region Failover for Standard Queues
Enable cross-region failover so that if a Mule app can’t reach an Anypoint MQ server in a region, it switches to the fallback queue configured in the fallback region.
  * Configuring Connected Apps
Integrate external applications with Anypoint Platform by using Connected Apps to provide access to those applications without sharing your user credentials.
  * Configuring Client Apps
Generate credentials to use for publishing and consuming from a queue when using Anypoint Connector for MQ (Anypoint MQ Connector) version 3.x or earlier.
MuleSoft recommends that you use connected apps rather than client apps to generate credentials. For information, see Configuring Connected Apps.
YAML Format | MuleSoft Documentation
# YAML Format
MIME type: `application/yaml`
ID: `yaml`
Values in the YAML data format map one-to-one with DataWeave values. DataWeave natively supports all of the following YAML types:
  * `Boolean`
  * `Mapping`
  * `Sequences`


## Example: Represent YAML in the DataWeave Format (dw)
This example shows how DataWeave represents YAML values.
### Input
The following YAML snippet serves as the input payload for the DataWeave source in this example.
```
american:
 - Boston Red Sox
 - Detroit Tigers
 - New York Yankees
national:
 - New York Mets
 - Chicago Cubs
 - Atlanta Braves
```

### Source
The DataWeave script transforms the YAML encoded input payload to the DataWeave (dw) format and MIME type.
```
%dw 2.0
output application/dw
---
payload
```

### Output
The following output shows how the YAML input is represented in the DataWeave (`dw`) format.
```
{
 "american": [
  "Boston Red Sox",
  "Detroit Tigers",
  "New York Yankees"
 ],
 "national": [
  "New York Mets",
  "Chicago Cubs",
  "Atlanta Braves"
 ]
}
```

## Configuration Properties
DataWeave supports the following configuration properties for this format.
### Reader Properties
This format accepts properties that provide instructions for reading input data.
Parameter | Type | Default | Description  
---|---|---|---  
`maxEntityCount` |  Sets the maximum number of entity expansions. The limit helps avoid Billion Laughs attacks.  
### Writer Properties
This format accepts properties that provide instructions for writing output data.
Parameter | Type | Default | Description  
---|---|---|---  
`bufferSize` |  Size of the buffer writer, in bytes. The value must be greater than `8`.  
Generates the output as a data stream when set to `true`, and defers the script’s execution until the generated content is consumed. Valid values are `true` or `false`.  
The encoding to use for the output, such as UTF-8.  
`skipNullOn` |  Skips `null` values in the specified data structure. By default, DataWeave does not skip the values.
  * `arrays` + Ignore and omit `null` values inside arrays from the YAML output, for example, with `output application/yaml skipNullOn="arrays"`.
  * `objects` + Ignore key-value pairs that have `null` as the value, for example, with `output application/yaml skipNullOn="objects"`.
  * `everywhere` + Apply `skipNullOn` to arrays and objects, for example, `output application/yaml skipNullOn="everywhere"`.

Valid values are `arrays` or `objects` or `everywhere`.  
`writeDeclaration` |  Indicates whether to write the header declaration or not. Valid values are `true` or `false`.  
## Supported MIME Types
This format supports the following MIME types.
`application/yaml`  
---  
`application/x-yaml`
OAuth 2.0 Token Introspection Policy | MuleSoft Documentation
# OAuth 2.0 Token Introspection Policy
**Policy Name** | OAuth 2.0 Token Introspection Policy  
---|---  
Allows access only to authorized client applications  
Security  
**First Flex Gateway version available**  
**Returned Status Codes** | 400 - Invalid token  
401 - Unauthorized access or error when connecting to the authorization server  
403 - Forbidden, invalid client application credentials  
500 - Bad response from authorization server, or WSDL SOAP fault error  
## Summary
The OAuth 2.0 Token Introspection policy enables you to configure OAuth 2.0 using any third-party Identify Provider (IdP), such as Okta, AWS, Azure or Google Cloud Platform. The policy allows for tokens based on the OAuth 2.0 Authorization Framework to be authorized without having to register an external IdP server in the Anypoint Platform.
The policy validates the token sent by the client to the protected API, and allows access to the backend server only if the introspection endpoint authorizes the token.
## Configuring Policy Parameters
### Flex Gateway Local Mode
In Local Mode, you apply the policy to your API via declarative configuration files. Refer to the following policy definition and table of parameters:
```
- policyRef:
  name: oauth2-token-introspection-flex
 config:
  introspectionURL: <string> // REQUIRED
  authorizationValue: <string> // REQUIRED
  validatedTokenTTL: <number> // OPTIONAL
  authenticationTimeout: <number> // OPTIONAL
  skipClientIdValidation: <boolean> // REQUIRED
  consumerBy: <string> // REQUIRED
  exposeHeaders: <boolean> // OPTIONAL
  scopes: <string> // OPTIONAL
  scopeValidationCriteria: <string> // OPTIONAL
  maxCacheEntries: <number> // OPTIONAL
```

Parameter | Required or Optional | Default Value | Description  
---|---|---|---  
`introspectionURL` |  The third-party token introspection URL  
`authorizationValue` |  The method to request authorization from the authentication service. Specify either a Basic Auth string with `client_id` and `client_secret`, or a Bearer Token.  
`validatedTokenTTL` |  The caching limit for the validated token  
`authenticationTimeout` |  The timeout when sending data to the authentication service  
`skipClientIdValidation` |  Enables/disables client ID enforcement support  
Associate an identity provider’s `username` or `client_id` response with a registered platform’s `client_id`. Required if `skip_client_id_validation`is `true`.  
`exposeHeaders`  
A space-delimited list  
`scopeValidationCriteria` |  The criteria to apply to the `scopes` values. Valid parameter values are "AND" or "OR".  
`maxCacheEntries`  
#### Resource Configuration Example
```
- policyRef:
  name: oauth2-token-introspection-flex
 config:
  introspectionURL: https://my-introspection.com/introspect
  authorizationValue: Basic am9obkBleGFtcGxlLmNvbTphYmMxMjM=
  validatedTokenTTL: 600
  authenticationTimeout: 10000
  skipClientIdValidation: false
  consumerBy: "client_id"
  exposeHeaders: true
  scopes: "profile email shopping"
  scopeValidationCriteria: "AND"
  maxCacheEntries: 1000
```
Delete Clusters | MuleSoft Documentation
# Delete Clusters
Private Cloud Edition  Runtime Fabric 
When deleting a cluster, consider the following:
  * Alert definitions and history for the cluster are deleted.
  * Servers assigned to the cluster are not deleted.
  * Servers assigned to the cluster are restarted.
  * Applications deployed to the servers in the cluster are removed.


To delete a cluster:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Servers** in the left menu.
  3. Click **Cluster** in the **Type** column to display the details pane.
  4. Click the cluster status and select **Delete** from the menu:
Figure 1. The arrow shows the **Delete** option in the details pane.
  5. In the confirmation window, select the checkbox to verify that you want to delete the cluster, and then click the **Delete Cluster** button.


After deleting the cluster, the servers that were in that cluster are restarted.
## See Also
  * Multicast vs Unicast Clusters
  * Remove Servers from a Cluster
Step 1. Prerequisites for Building an API | MuleSoft Documentation
# Step 1. Prerequisites for Building an API
Before you begin your API-led journey, verify that you have the required tools and access:
  * Username and password for your Anypoint Platform organization. If you don’t have Anypoint Platform yet, create a Trial organization on Anypoint Platform.
Create a Trial organization
  * Download Anypoint Studio 7.16.0 or later. Anypoint Studio is an Eclipse-based IDE with rich functionality for building and deploying apps to Anypoint Platform.
  * To test REST requests, obtain a client such as Advanced REST Client or Postman if you don’t already have one. This tutorial uses Advanced REST Client.
Install Advanced REST Client
Depending on your platform, you might need to install a different client, or install Advanced REST Client from GitHub.


## Helpful Hints
  * Use two browser windows: One to read instructions and one to perform the tasks.
  * Set Advanced REST Client to have a long timeout. When you step through the processes during debugging, you don’t want the REST request to time out.
toPeriod | MuleSoft Documentation
# toPeriod
## toPeriod(str: String): Period
Transform a `String` value into a `Period` value.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The `String` value to transform into a `Period` value.  
### Example
This example shows how `toPeriod` behaves with different inputs. It produces output in the `application/dw` format.
#### Source
```
%dw 2.0
import * from dw::util::Coercions
output application/dw
---
{
 toPeriodEx1: toPeriod("P1D"),
 toPeriodEx2: toPeriod("PT1H1M")
}
```

#### Output
```
{
 toPeriodEx1: |P1D|,
 toPeriodEx2: |PT1H1M|
}
```
Viewing and Deleting API Alerts | MuleSoft Documentation
# Viewing and Deleting API Alerts
If you have been granted the **Organization Administrators** role for the root organization, you can view a list of alerts that are generated for APIs in the API Manager.
Before you can view and delete alerts, ensure that you have:
  * **Manage Alerts** permission to view and delete API alerts.
  * **View Alerts** permission to only view alerts.


For more information about how to set these permissions, see To Set Permissions.
To view and delete alerts:
  1. Navigate to **Anypoint Platform** > **API Manager**.
  2. In **API Administration** , click the API instance whose alert you want to view or delete.
  3. Click **Alerts**
  4. Expand the alert you want to delete.
Details about the alert options appear.
  5. Click **Delete**.
lookup | MuleSoft Documentation
# lookup
## lookup(flowName: String, payload: Any, timeoutMillis: Number = 2000)
This function enables you to execute a flow within a Mule app and retrieve the resulting payload.
It works in Mule apps that are running on Mule Runtime version 4.1.4 and later.
Similar to the Flow Reference component (recommended), the `lookup` function enables you to execute another flow within your app and to retrieve the resulting payload. It takes the flow’s name and an input payload as parameters. For example, `lookup("anotherFlow", payload)` executes a flow named `anotherFlow`.
The function executes the specified flow using the current attributes, variables, and any error, but it only passes in the payload without any attributes or variables. Similarly, the called flow will only return its payload.
Note that the `lookup` function doesn’t support calling subflows.
Always keep in mind that a functional language like DataWeave expects the invocation of the `lookup` function to _not_ have side effects. So, the internal workings of the DataWeave engine might cause a `lookup` function to be invoked in parallel with other `lookup` functions, or not to be invoked at all. MuleSoft recommends that you invoke flows with the Flow Ref (`flow-ref`) component, using the `target` attribute to put the result of the flow in a `var` and then referencing that `var` from within the DataWeave script.  
---  
_This function is**Deprecated**. Use DataWeave functions, instead._
### Parameters
Name | Description  
---|---  
A string that identifies the target flow.  
The payload to send to the target flow, which can be any (`Any`) type.  
`timeoutMillis` | Optional. Timeout (in milliseconds) for the execution of the target flow. Defaults to `2000` milliseconds (2 seconds) if the thread that is executing is CPU_LIGHT or CPU_INTENSIVE, or 1 minute when executing from other threads. If the lookup takes more time than the specified `timeoutMillis` value, an error is raised.  
### Example
This example shows XML for two flows. The `lookup` function in `flow1` executes `flow2` and passes the object `{test:'hello '}` as its payload to `flow2`. The Set Payload component (`<set-payload/>`) in `flow2` then concatenates the value of `{test:'hello '}` with the string `world` to output and log `hello world`.
#### Source
```
<flow name="flow1">
 <http:listener doc:name="Listener" config-ref="HTTP_Listener_config"
  path="/source"/>
 <ee:transform doc:name="Transform Message" >
  <ee:message >
   <ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
Mule::lookup('flow2', {test:'hello '})]]></ee:set-payload>
  </ee:message>
 </ee:transform>
</flow>
<flow name="flow2" >
 <set-payload value='#[payload.test ++ "world"]' doc:name="Set Payload" />
 <logger level="INFO" doc:name="Logger" message='#[payload]'/>
</flow>
```
System (dw::System) | MuleSoft Documentation
# System (dw::System)
This module contains functions that allow you to interact with the underlying system.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::System` to the header of your DataWeave script.
## Functions
Name | Description  
---|---  
Returns an environment variable with the specified name or `null` if the environment variable is not defined.  
Returns all the environment variables defined in the host system as an array of strings.
drop | MuleSoft Documentation
# drop
## drop<T>(array: Array<T>, n: Number): Array<T>
Drops the first `n` elements. It returns the original array when `n <= 0` and an empty array when `n > sizeOf(array)`.
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
The left array of elements.  
The number of elements to take.  
### Example
This example returns an array that only contains the third element of the input array. It drops the first two elements from the output.
#### Source
```
%dw 2.0
import * from dw::core::Arrays
var users = ["Mariano", "Leandro", "Julian"]
output application/json
---
drop(users, 2)
```

#### Output
```
[
 "Julian"
]
```

## drop(array: Null, n: Any): Null
Helper function that enables `drop` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
MUnit Overview | MuleSoft Documentation
# MUnit Overview
Anypoint Code Builder 
Anypoint Studio 
Build automated tests for your integrations and APIs with MUnit. MUnit is a Mule application testing framework that provides a full suite of integration and unit test capabilities, and is fully integrated with Maven and Surefire for integration with your continuous deployment environment.
MUnit version 3.0 and later works with all Mule versions since 4.3.
With MUnit you can:
  * Create your test by writing Mule code
  * Mock processors
  * Spy any processor
  * Verify processor calls
  * Enable or ignore particular tests
  * Tag tests
  * Generate coverage reports


You can create, design, and run MUnit tests in Anypoint Studio and Anypoint Code Builder.
MUnit has two main sub modules:
  * MUnit
  * MUnit Tools


Each module has its dependency:
## MUnit Dependencies
```
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-runner</artifactId>
	<version>LATEST_VERSION</version> **(1)**
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

Check the MUnit Release Notes to get the **LATEST_VERSION**.  
---  
## MUnit Tools Dependencies
```
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-tools</artifactId>
	<version>LATEST_VERSION</version> **(1)**
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

Check the MUnit Release Notes to get the **LATEST_VERSION**.  
---  
## See Also
  * MUnit Test Structure Fundamentals
  *   * Testing Projects with MUnit in Studio
  * Testing Projects with MUnit in Anypoint Code Builder
Implementing APIs | MuleSoft Documentation
# Implementing APIs
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.
Use Anypoint Code Builder to start an API implementation by importing and scaffolding an API spec into an interface that you implement and integrate within a Mule app.
Anypoint Code Builder supports automated scaffolding of OAS, RAML, AsyncAPI, and GraphQL APIs, _except for_ APIs that reference OAS or JSON schema fragment dependencies from Exchange.
The methods for implementing APIs using Anypoint Code Builder are:
  * Scaffold an API from a spec in Exchange and create a new implementation project.
  * Import an API spec from Exchange to scaffold the API in an existing integration project.
  * Scaffold an API into an implementation project without first publishing it to Anypoint Exchange, enabling iterative design and implementation.


After scaffolding an API specification into an interface, you are ready to develop, test, and deploy your Mule app as described in Developing Integrations. To understand how an integration project can implement an API specification, see the tutorial Implementing the American Flights API Spec.
## Source Control for Implementation Projects
Use source control management (SCM) to store and share your design, integration, and implementation projects. For source control options, see Controlling Source Files.
Discovering APIs | MuleSoft Documentation
# Discovering APIs
The Home page or landing page of a portal contains the API Carousel. The API Carousel offers API consumers an interactive way to explore all the available APIs. The API Carousel shows API cards in rows and columns, and divided into pages, and shows controls to filter the displayed APIs by type and search terms. Each card shows an API. With the carousel, you can view and explore large numbers of API versions.
The APIs page contains the API Catalog of all the APIs in the portal. The searchable catalog shows a horizontally scrollable set of API cards. Each card shows an API. The API icon, name, and description are shown based on the API information from Exchange.
## See Also
  *   * Viewing API Details
AS2 Connector 6.5 | MuleSoft Documentation
# AS2 Connector 6.5
Mule runtime engine (Mule) supports the AS2 protocol through Anypoint Connector for AS2 (AS2 Connector).
AS2 Connector enables trading partners to transmit and receive AS2 messages with EDI-X12, EDIFACT, XML, or binary payloads, for example:
  * Send messages, signed or unsigned, over HTTP or HTTPS, using the AS2 protocol
  * Receive messages over HTTP or HTTPS, using the AS2 protocol
  * Receive asynchronous MDN for sent messages


For compatibility information and fixed issues, see the AS2 Connector Release Notes.
For a major or minor release, see Upgrading and Migrating.
## Before You Begin
To use this connector, you must be familiar with:
  * The AS2 target resource
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio (Studio)


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


## Common Use Cases for the Connector
Common use cases for AS2 Connector include the following:
  * Send with sync MDN


Sends a message through HTTP or HTTPS using the AS2 protocol requesting the partner for a synchronous MDN (receipt)
  * Send with async MDN


Sends a message through HTTP or HTTPS using the AS2 protocol requesting the partner for an asynchronous MDN (receipt)
  * Listener


Source that receives messages via HTTP or HTTPS using the AS2 protocol
  * MDN Listener


Source that receives asynchronous MDN receipts via HTTP or HTTPS using the AS2 protocol
  * Non repudiation Listener


Source that receives a signed copy of a receipt or a message for persistent non-repudiation storage
## Non-Repudiation Storage of AS2 Messages and MDNs
If needed, you can configure non-repudiation storage for your AS2 operations to support regulatory or compliance requirements.
Only signed messages and MDNs are eligible for non-repudiation.
The following AS2 Connector sources and operations support the non-repudiation feature:
  * AS2 Send Sync operation
  * AS2 Send Async operation
  * AS2 Listener source
  * AS2 MDN Listener source


### Before You Begin for Non-Repudiation Storage
To enable non-repudiation of a message in AS2 Connector, you must implement and configure a separate Mule flow that acts as a non-repudiation flow:
  * The non-repudiation flow must have access to the signed MIME message that is passed to it, along with appropriate non-repudiation specific attributes.
  * This non-repudiation-specific Mule flow is responsible for receiving, storing, and acting upon the messages and attributes it receives.
  * The name of this non-repudiation flow must be configured on an appropriate listener or operation that has non-repudiation storage enabled.


## 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
  * MuleSoft Help Center
Gmail Connector 1.1 - XML and Maven Support | MuleSoft Documentation
# Gmail 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/gmail
http://www.mulesoft.org/schema/mule/gmail/current/mule-gmail.xsd
```

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

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


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Access the EU Control Plane from Anypoint Studio | MuleSoft Documentation
# Access the EU Control Plane from Anypoint Studio
Configure your Anypoint Studio implementation to point to the EU control plane to perform tasks there, such as deploying to CloudHub, importing an asset from Exchange, or importing an API definition from Design Center.
  1. Open the preferences view in the manner appropriate to your OS:
     * In MacOS, either navigate to **Anypoint Studio** > **Preferences…​** or press `cmd + ,`.
     * In Windows and Linux, navigate to **Window** > **Preferences…​**.
  2. Expand **Anypoint Studio** in the left navigation bar, and select **Anypoint Platform** :
  3. Select **EU** from the region drop-down menu, and then select **Apply and Close** :


As a result, all Anypoint Platform tools embedded in Anypoint Studio display your Anypoint Platform from the EU control plane.
## See Also
  * EU Control Plane
  * To Access the EU Control Plane
Uploading Custom Policies to Exchange | MuleSoft Documentation
# Uploading Custom Policies to Exchange
During the custom policy development cycle, you can upload your policy to Exchange to create a new Exchange asset to manage the policy’s version and to distribute it to other users. For more information about Exchange, see Anypoint Exchange Overview.
For custom policies running in Local Mode, it is not required to publish your policy to Exchange. However, Exchange is a useful version control tool. It is your responsibility to distribute custom policies for Local Mode use.
When uploading your policy to Exchange, you can choose to either:
  * Publish a Custom Policy Publish a policy if the policy version is still in development. This enables you to test and edit the policy version.
  * Release a Custom Policy Release the policy to create a definitive version of the policy. After releasing the policy, you must create a new policy version to edit the policy.


Every time you publish or release a policy, you create a new `stable` asset in Exchange. For more information about `stable` state assets, see Stable State Assets.
After you upload your policy to Exchange, see Applying Custom Policies.
## Before You Begin
  * Ensure that the Connected App you used to authenticate to the Anypoint Platform CLI has the `Exchange Contributor` scope applied.
  * Compile your Policy.


## Publish a Custom Policy
To publish a custom policy, run the `make publish` command from the policy’s root folder:
After publishing the asset, a new asset labeled `DEV` appears in Exchange:
The asset’s group ID, asset ID, and asset version (GAV) appear, similar to the following:
  * **groupID** : `<organizationId>`
  * **assetID** : `my-custom-policy-dev`
When publishing a policy, `-dev` appears appended to the **assetID**.
  * **version** : `1.0.0-20230618115723`
When publishing a policy, a timestamp appears appended to the **version**.


Rerunning the publish command creates a new version of the policy asset with an updated timestamp. Previously published policy versions are still available.
## Release a Custom Policy
To release a custom policy, run the `make release` command from the policy’s root folder:
Released policies are not labeled `DEV`. The asset’s GAV appears similar to the following:
  * **groupID** : `<organizationId>`
  * **assetID** : `my-custom-policy`
Released policies do not have `-dev` appended to their **assetID**.
  * **version** : `1.0.0`
Released policies do not have a timestamp appended to their **assetID**.


After releasing the asset, rerunning the `make release` command results in a conflict error.
To begin working on the next version of your policy, update the version number in the `Cargo.toml` file.
For example, if the latest version is `1.0.0`, update the `Cargo.toml` file as follows to begin working on a minor release:
```
name = "my-custom-policy"
version = "1.1.0"
```

## See Also
  * Applying Custom Policies
  *
Apache Kafka 4.10 Examples | MuleSoft Documentation
# Apache Kafka 4.10 Examples
The following examples shows how to configure Apache Kafka Connector:
  * Publish and Consume Example Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.
  * Integrate Confluent Schema Registry Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Policy Types | MuleSoft Documentation
# Policy Types
You can create included, custom, or automated policies, each with its own scope, management, and usability. You can uniformly apply a policy to all APIs, or you can apply _resource-level policies_ to select APIs based on specified criteria.
## Included Mule Gateway Policies
MuleSoft provides several ready-to-use policies for areas such as authentication, security management, threat protection, and tokenization. Using the API Manager from Anypoint Platform, you can apply any of these policies to any of your API endpoints.
After you apply a policy, its complete lifecycle is managed by API Manager. You can apply a default policy to a specific API. To automatically apply a policy to all APIs in your environment, you must configure it as an automated policy.
## Automated Policies
You can apply any default or a custom policy to all the APIs in your environment, making that policy an _automated policy_. However, you require specific access, such as API Manager Environment Administrator, to create automated policies.
## Custom Policies
Although MuleSoft provides you with several ready-to-use included policies, you might want to create a custom policy to meet your specific business needs. You can either customize an existing policy, or you can create an entirely new custom policy. These policies are categorized as either online or offline.
### Online Custom Policies
Online Custom policies are applied and managed by API Manager, which is the default and recommended way to apply policies. Online policies enable you to manage the policy lifecycle by leveraging Anypoint Platform. This way, the applied policies are always in sync with API Manager, and are protected by the gatekeeper mechanism at startup.
### Offline Custom Policies
Offline custom policies are applied directly to the runtime and managed manually. Because they can easily become out of sync with API Manager, using this type of policy is not recommended.
Offline custom policies are not protected by the Gatekeeper mechanism at startup. Additionally, client credentials validation is also not supported in offline policies.
## See Also
  *   *   *   * Resource-Level Policies
CIM Setup Subject Area | MuleSoft Documentation
# CIM Setup Subject Area
Defines technical resources such as software components and document images.
## Model diagrams
The following diagrams show the entities and relationships in this subject area, organized by entity group.
### Generated Document
## Implementation
## See Also
  *   * CIM Design Elements
  *   *
X12 EDI Connector 2.13 | MuleSoft Documentation
# X12 EDI Connector 2.13
Support Category: Premium
Anypoint Connector for X12 EDI (X12 EDI Connector) enables you to convert X12 messages to and from DataWeave-compatible representations by using lists and maps. All of the schema definitions you need for supported X12 standard transaction sets are included. For complete information about schemas, see X12 EDI Schema Language Reference.
Many Health Insurance Portability and Accountability Act (HIPAA) document versions are also supported, as listed separately in the Supported HIPAA Versions. For more information about HIPAA usage, refer to Connector HIPAA Standards.
## Prerequisites
To use this connector, you must be familiar with:
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Purchased a MuleSoft license for X12 EDI Connector.
Contact your Account Representative about purchasing a license.
  * Anypoint Studio 7.0 or later


X12 EDI Connector supports files of up to 15 MB in size, and the memory requirement is approximately 40 to 1. For example, a 1 MB file requires up to 40 MB of memory to process, so it’s important to consider this memory requirement in conjunction with your Transactions Per Second (TPS) needs for large X12 files. This is not an exact figure; the value varies according to the complexity of the mapping instructions.   
---  
## Exchange Templates and Examples
Anypoint Exchange provides templates that you can use as starting points for your apps and examples that illustrate a complete solution.
### X12 EDI Connector Templates in Exchange
X12 EDI Connector templates provide starting points that help you:
  * Map application messages to outbound X12 transactions 
  * Map inbound X12 transactions to the application message format
  * Set up your Partner Manager content storage


### X12 EDI Connector Examples in Exchange
X12 EDI Connector examples in Exchange enable you to:
  * Customize an X12 EDI schema for B2B integrations
  * Transform outbound purchase order XML messages to X12 850 transactions
  * Transform inbound X12 850 transactions to JSON purchase orders
  * Transform outbound XML messages into X12 purchase orders, inbound X12 purchase orders into JSON, and generate a functional acknowledgement
  * Implement an end-to-end order to cash workflow from the perspective of a seller
  * Implement an end-to-end B2B procure to pay workflow from the perspective of a buyer


## Next Step
After you complete the prerequisites, you are ready to create your own app and configure the connector using Anypoint Studio.
## See Also
Introduction to Anypoint Connectors
Use Exchange to Discover Connectors, Templates, and Examples
MuleSoft Help Center
Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer | MuleSoft Documentation
# Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer
Use case three covers all patterns of a scenario in which a non-organization-owned API is exposed to an organization-owned API consumer.
Use case examples:
  * A payments service must obtain exchange rates from an external service provider.
  * An internal API Consumer accesses the organization’s external ServiceNow instance (SaaS service).


## Pattern 7: Non-Organization External API exposed to an Organization Internal Consumer
In pattern seven, you deploy Flex Gateway as an egress. You can use Flex Gateway to monitor, control, and enrich the flows to external services. Additionally, you can rate limit external access and track metrics and analytics.
The following diagram shows the physical implementation of a scenario in which a non-organization external API is exposed to an organization internal consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming non-organization external mTLS connection.
## Pattern 8: Non-Organization External API exposed to an Organization External Consumer
In pattern eight, Flex Gateway acts as an intermediary between two organization external entities. Flex Gateway runs as an ingress and egress that applies secure communication and policy enforcement.
The following diagram shows the physical implementation of a scenario in which an external non-organization API is exposed to an organization external consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming external mTLS connection.
## See Also
  * Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer
  * Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer
  * Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer
Consuming an API | MuleSoft Documentation
# Consuming an API
Anypoint Exchange provides significant features for API providers to easily publish and share APIs with developers inside and outside of an organization.
Exchange helps API consumers understand API functionality and test features with:
  * API console to view API functions. This console appears to the right of a REST API detail screen.
  * API Notebook to view API documentation and to test API features.
  * Simulate data to an API using the mocking service.
  * GraphQL console to view GraphQL schemas and run queries.


## See Also
  * View REST API Elements in an Asset
  * Test an API with API Notebook
  * Simulating Data in REST APIs
  * Viewing GraphQL API Schemas and Run Queries
Obtaining an API Bearer Token Using a SAML Assertion | MuleSoft Documentation
# Obtaining an API Bearer Token Using a SAML Assertion
If you are using an identity provider configured to use SAML 2.0, federated users within your organization can access Anypoint Platform APIs using the bearer token .
Obtaining an API bearer token using a SAML assertion works only for IdP-initiated single signon. Service provider-initiated SSO does not support unsolicited assertions.   
---  
The bearer token provides access to the platform APIs a user has permission to access. Each bearer token is associated with a specific user who is granted roles and permissions for an API. If a user attempts to access an API that they do not have permissions to access the API returns a `401 Unauthorized` error.
The validity of the bearer token is determined by the value defined for the Default Session Timeout property. This is configured in the root organization properties. See Manage Root Business Group Settings for more information.
To obtain an API bearer token using a SAML assertion:
  1. Obtain a SAML response for your identity provider as described in View a SAML Response in Your Browser.
Record this response to use in the following step.
  2. Obtain the bearer token by running the following `curl` command. Replace `<SAML_RESPONSE>` in this example with the SAML response you obtained in the previous step.
The SAML response must be Base64-encoded. If the SAML response string is URL encoded, you must decode the string before running the `curl` command.   
---  
```
curl -X POST \
 https://anypoint.mulesoft.com/accounts/login/:org-domain/providers/:providerId/receive-id \
 -H 'Content-Type: application/json' \
 -H 'X-Requested-With: XMLHttpRequest' \
 -d '{
  "SAMLResponse": "<SAML_RESPONSE>"
}'
```



After obtaining the bearer token federated users within your organization can use it to access an API. For example, you can access the API using one of the following methods:
  * **Anypoint CLI** : A user can access a platform API by supplying the `-bearer` option to the `anypoint-cli` command. See Anypoint CLI for more information.
  * **curl** : A user can access a platform API by passing the bearer token when accessing an API endpoint as shown in the following:
```
curl -X GET \
 https://anypoint.mulesoft.com/accounts/api/me \
 -H 'Authorization: Bearer <BEARER_TOKEN>'
```



## See Also
  * Managing Business Groups
  *   * To view a SAML response in your Browser
Security | MuleSoft Documentation
# Security
The service to which the connector you are creating will connect probably enforces some kind of security for apps to talk to on behalf of a user.
The SDK provides different two ways for end users of your connector to secure their connections.
  *   * Adding OAuth Authentication