BassemE/mulesoft-documentation-embeddings huggingface dataset:
Zuora AQuA XML and Maven Support | MuleSoft Documentation
# Zuora AQuA XML and Maven Support
If you manually code a Mule app in XML, either from the Anypoint Studio XML editor or from a text editor, you can access the connector in your app by adding reference statements to your XML Mule flow and in the Apache Maven POM file.
You can avoid the manual process described in this topic by using Studio. When you install the connector in Studio, it automatically populates the XML code with the connector’s namespace and schema location, and adds a dependency to the POM file.  
---  
## Add a Namespace for the Connector
Paste the following code inside the `<mule>` tag of the header of your configuration XML:
```
xsi:schemaLocation="
...
http://www.mulesoft.org/schema/mule/zuora-aqua-connector
http://www.mulesoft.org/schema/mule/zuora-aqua-connector/current/mule-zuora-aqua-connector.xsd"
```

This example shows how the namespace statements are placed in the mule XML block:
```
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http"
   xmlns:mule-zuora-aqua-connector="http://www.mulesoft.org/schema/mule/mule-zuora-aqua-connector"
	  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/mule-zuora-aqua-connector
        http://www.mulesoft.org/schema/ mule/mule-zuora-aqua-connector/current/mule-mule-zuora-aqua-connector.xsd
        http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
   <!-- Insert your configuration elements and your flow here -->
</mule>
```

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

Replace `x.x.x` with the version that corresponds to the connector you are using.
To obtain the most up-to-date `pom.xml` file information, access the connector in Anypoint Exchange and click **Dependency Snippets**.
## Next Step
After completing this section, you can try the Zuora Examples.
## See Also
  * MuleSoft Help Center
Managing App Logs | MuleSoft Documentation
# Managing App Logs
Logging is available for apps deployed to both shared and private spaces.
If your organization has a Titanium subscription, you can use Anypoint Monitoring for more advanced searching and log management. For more information, see Anypoint Monitoring Overview.
## Configure Logging for the App
Logging is enabled by default for apps deployed to CloudHub 2.0.
### Disable or Enable Logging
To disable or reenable logging for the app:
  1. Click the **Logging** tab.
  2. Deselect or select the **Forward application logs to Anypoint Platform** option.
  3. Click **Apply Changes**.


If you disable logging, the **Logs** heading still appears in the Runtime Manager navigation menu, but application logs are not collected.
### Configure Log Levels and Categories
To configure additional log levels and categories to include in logs:
  1. Click the **Monitoring** tab.
  2. Select the log level:
     * **INFO** : Informative messages
     * **DEBUG** : Debugging messages
     * **WARNING** : Warning messages
     * **ERROR** : Error messages, such as when an exception occurs
     * **FATAL** : Fatal messages for when an application fails
  3. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key.
  4. Click **Apply Changes**.


Changing the log level and clicking **Apply Changes** restarts the application.   
---  
## See Also
  * Integrating with Your Logging System Using Log4j
  * Viewing Log Data for Deployed Apps
  * Anypoint Monitoring Overview
Configuring Chat Operations for Einstein AI Connector 1.2 | MuleSoft Documentation
# Configuring Chat Operations for Einstein AI Connector 1.2
## Configure the Chat Answer Prompt Operation
The **Chat answer prompt** operation sends a request to the configured LLM. This operation uses a plain text prompt as input and responds with a plain text answer.
  1. Select the operation on the Anypoint Code Builder or Studio canvas.
  2. In the **General** properties tab for the operation, enter plain text for the **Prompt**.
  3. In **Additional properties** , enter these values:
     * **Model name**
Select the model name. The default is `OpenAI GPT 3.5 Turbo`.
     * **Probability**
Enter the probability of the model staying accurate. The default is `0.8`. **Locale**
Enter the localization information, which can include the default locale, input locale(s), and expected output locale(s). The default is `en_US`.


This is the XML configuration for this operation:
```
<ms-einstein-ai:chat-answer-prompt
 doc:name="Chat answer prompt"
 doc:id="66426c0e-5626-4dfa-88ef-b09f77577261"
 config-ref="Einstein_AI"
 prompt="#[payload.prompt]"
/>
```

## Configure the Chat Generate from Messages Operation
The **Chat generate from messages** operation is a prompt request operation to the configured LLM, with provided messages. This operation accepts multiple messages and uses a plain text prompt as input. The operation responds with a plain text answer.
  1. Select the operation on the Anypoint Code Builder or Studio canvas.
  2. In the **General** properties tab for the operation, enter plain text for the **Messages**.
  3. In **Additional properties** , enter these values:
     * **Model name**
Select the model name. The default is `OpenAI GPT 3.5 Turbo`.
     * **Probability**
Enter the probability of the model staying accurate. The default is `0.8`. **Locale**
Enter the localization information, which can include the default locale, input locale(s), and expected output locale(s). The default is `en_US`.


This is the configuration XML for this operation:
```
<ms-einstein-ai:chat-generate-from-messages
 doc:name="Chat generate from messages"
 doc:id="94fa27f3-18ce-436c-8a5f-10b8dbfa4ea3"
 config-ref="Einstein_AI"
 messages="#[payload.messages]"
/>
```

## See Also
  * Using Anypoint Code Builder to Configure a Connector
  * Einstein AI Connector Overview
  * Einstein AI Connector Reference
  * MuleSoft Help Center
EDIFACT EDI Connector 2.10 XML and Maven Support | MuleSoft Documentation
# EDIFACT EDI Connector 2.10 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/edifact-edi
http://www.mulesoft.org/schema/mule/edifact-edi/current/mule-edifact-edi.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<mule xmlns:http="http://www.mulesoft.org/schema/mule/edifact-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/edifact-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-edifact-extension</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 `EDIFACT EDI`.
  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
Policy Categories | MuleSoft Documentation
# Policy Categories
Policies are categorized by the function they perform. For example, because you resolve issues with the help of logs, the Message Logging policy is categorized as a troubleshooting policy. The following table lists included policies by its category and the function it performs:
Category | Policy | Function  
---|---|---  
Basic Authentication - LDAP |  Authenticates the LDAP credentials.  
Basic Authentication - Simple |  Authenticates a single user password.  
IP Blocklist |  Blocks a range of IP addresses.  
IP Allowlist |  Allows access from only a preapproved range of IP addresses.  
JSON Threat Protection |  Protects against a malicious JSON structure in API requests.  
XML Threat Protection |  Protects against malicious XML elements in API requests.  
Validates a JWT token.  
OAuth 2.0 Access Token Enforcement Using Mule OAuth Provider Policy |  Enforces token access using the MuleSoft OAuth Provider policy.  
OpenAM Access Token Enforcement |  Restricts access to a protected resource using an Open AM authentication server.  
PingFederate Access Token Enforcement |  Restricts access to a protected resource using the PingFederate authentication server.  
Tokenization |  Transforms sensitive data into nonsensitive equivalent tokens.  
Detokenization |  Transforms a tokenized value back to the original data.  
Client ID Enforcement |  Allows access to client applications with a valid client credentials.  
Enables calls executed in a web page to interact with resources from different domains.  
Transformation |  Header Injection |  Adds headers to the request or response message of a policy.  
Transformation |  Header Removal |  Removes headers from the request or response message of a policy.  
Quality of Service |  HTTP Caching |  Stores HTTP responses from an API implementation.  
Quality of Service |  Rate Limiting |  Enables imposing a limit on the number of requests that an API can accept within a specified time.  
Quality of Service |  Rate Limiting, SLA-Based |  Enables imposing an API request limit based on SLA tiers.  
Quality of Service |  Spike Control |  Controls API traffic.  
Troubleshooting |  Message Logging |  Logs a custom message when an API is invoked.  
## See Also
  * Included Policies Directory
Core Matchers Reference | MuleSoft Documentation
# Core Matchers Reference
Anypoint Code Builder 
Anypoint Studio 
## nullValue()
Checks that the expression is null.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::nullValue()]"/>
```

## notNullValue()
Checks that the expression is not null.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::notNullValue()]"/>
```

## withMediaType(String)
Checks that the expression’s media type is the one specified.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withMediaType('text/xml')]"/>
```

## withEncoding(String)
Checks that the expression encoding is the one specified.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withEncoding('UTF-8')]"/>
```

## both(Matcher, Matcher)
Checks that both provided matchers are successful.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::both(MunitTools::notNullValue(),MunitTools::equalTo('example'))]"/>
```

## either(Matcher,Matcher)
Checks that at least one of the matchers is successful.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::either(MunitTools::nullValue(),MunitTools::equalTo(0))]"/>
```

## not(Object)
Checks if the provided matcher is not successful.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(0)]"/>
```

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

## anyOf(Array<Matcher>)
Checks if any of the matchers are successful.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## allOf(Array<Matcher>)
Checks if all of the matchers are successful.
Example
```
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## See Also
  *   * String Matchers Reference
  * Comparable Matchers Reference
  * Iterable and Map Matchers Reference
Migration to Mule 4 | MuleSoft Documentation
# Migration to Mule 4
For your Mule 3 apps to take advantage of Mule 4, migrate them to Mule 4 through one of the following processes:
  * A fully manual migration of connectors, modules, transports, expressions, and API gateways to their Mule 4 counterparts.
For guidance with a fully manual migration, see Prepare to Migrate and review Manual Migration Process.
  * A partially automated migration with the Mule Migration Assistant (MMA), which is available as an open source project on GitHub.
For guidance using MMA to assist in a migration, see the user documentation (on GitHub). MuleSoft suggests that you try MMA to determine whether you prefer it to a fully manual migration. Note that you can run MMA on a sample application by following steps in the Migration Tutorial (on GitHub).



Important
    
**Mule Migration Assistant (MMA) is subject to the terms and conditions described forCommunity connectors. Additionally, Mule Migration Assistant is distributed under the terms of the 3-Clause BSD License.**
A benefit of using MMA is that it automates part of the migration of Mule 3 apps to Mule 4. Though the MMA does not migrate the app entirely, it provides significant help with the following tasks:
  * Migrating the project structure.
  * Automatically creating descriptor files, such as `pom.xml` or `mule-artifact.json`.
  * Automatically performing many adaptations of the app’s code.
  * Providing guidance on how to manually migrate components and patterns that cannot be migrated automatically.


MMA helps with such tasks, but it does not deliver a fully functional app. Some additional steps are required. Those steps include testing and can also include:
  * Manual migration of unsupported components.
  * Manual migration of complex MEL expressions to DataWeave that cannot be automatically converted by MMA.
  * Manual migration of complex DataWeave transformations that cannot be automatically converted by MMA.
  * Prior migration of the DataMapper with the DataWeave Migration tool, before running the MMA.


It is also important to note that the MMA does not support incremental migrations.
Salesforce Marketing Cloud REST Connector 1.2 | MuleSoft Documentation
# Salesforce Marketing Cloud REST Connector 1.2
Anypoint Connector for Salesforce Marketing Cloud REST (Salesforce Marketing Cloud REST Connector) enables you to integrate with the Salesforce Marketing Cloud marketing platform. This connector exposes operations provided by the Salesforce Marketing Cloud REST API.
For information about compatibility and fixed issues, refer to the Salesforce Marketing Cloud REST Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Salesforce Marketing Cloud REST API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


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


## Connection Types
Salesforce Marketing Cloud REST connections use the OAuth Client Credentials authentication type, which enables a client to use its own credentials.
## 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
  * Salesforce Marketing Cloud REST Connector Reference
  * MuleSoft Help Center
dateTime | MuleSoft Documentation
# dateTime
## dateTime(parts: DateTimeFactory): DateTime
Creates a `DateTime` value from values specified for `year`, `month`, `day`, `hour`, `minutes`, `seconds`, and `timezone` fields.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
`Number` values for `year`, `month`, `day`, `hour`, `minutes`, and `seconds` fields followed by a `TimeZone` value for the `timezone` field. Valid values are numbers between 1 and 12 for the `month`, 1 through 31 for the `day`, 0 through 23 for the `hour`, 0 through 59 for `minutes`, and 0 through 59 (including decimals, such as 59.99) for seconds. You can specify the name-value pairs in any order, but the output is ordered by default as a `DateTime` value, such as `2012-10-11T10:10:10-03:00`. The input fields are parts of a `DateTimeFactory` type.  
### Example
This example shows how to create a value of type `DateTime`.
#### Source
```
%dw 2.0
import * from dw::core::Dates
output application/json
---
{
  newDateTime: dateTime({year: 2012, month: 10, day: 11, hour: 12, minutes: 30, seconds: 40 , timeZone: |-03:00|})
}
```

#### Output
```
{
  "newDateTime": "2012-10-11T12:30:40-03:00"
}
```
nameOf | MuleSoft Documentation
# nameOf
## nameOf(t: Type): String
Returns the name of the input type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The type to query  
### Example
This example shows how `nameOf` behaves with different inputs.
#### Source
```
%dw 2.0
output application/json
import * from dw::core::Types
type AArray = Array<String> {n: 1}
type AArray2 = Array<String>
---
 {
   a: nameOf(AArray),
   b: nameOf(AArray2),
   c: nameOf(String)
 }
```

#### Output
```
{
  "a": "AArray",
  "b": "AArray2",
  "c": "String"
 }
```
Define a Custom Addition Function | MuleSoft Documentation
# Define a Custom Addition Function
This DataWeave example takes in a set of item prices and stock amounts and uses several functions to calculate subtotals, deduct discounts and add taxes.
It makes use of the following:
  * `map` function to go through all the items in the input.
  * basic math operations like `*`, `+` and `-`.
  * String concatenation with `++`.
  * `as` to force string values into numbers.
  * Fixed values in the header to set tax and discount amounts.
  * A custom function in the header, to define once and use multiple times in the code.
  * `reduce` function to aggregate the various items into a total.


DataWeave Script:
```
%dw 2.0
output application/json
var tax = 0.085
var discount = 0.05
fun getSubtotal (items) = items reduce ((item, accumulator = 0) ->
    accumulator + (item.unit_price * item.quantity * (1 - discount)))
---
invoice: {
  header: payload.invoice.header,
  items: { (payload.invoice.items map {
    item : {
      description: $.description,
      quantity: $.quantity,
      unit_price: $.unit_price,
      discount: (discount * 100) as Number ++ "%",
      subtotal: $.unit_price * $.quantity * (1 - discount)
    }
  }) },
  totals:
  {
    subtotal: getSubtotal(payload.invoice.items ),
    tax: (tax * 100) as Number ++ "%",
    total: getSubtotal(payload.invoice.items ) * (1 + tax)
  }
}
```

Input JSON Payload:
```
{
 "invoice": {
  "header": {
   "customer_name": "ACME, Inc.",
   "customer_state": "CA"
  },
  "items": [
   {
    "description": "Product 1",
    "quantity": "2",
    "unit_price": "10"
   },
   {
    "description": "Product 2",
    "quantity": "1",
    "unit_price": "30"
   }
  ]
 }
}
```

Output
```
{
 "invoice": {
  "header": {
   "customer_name": "ACME, Inc.",
   "customer_state": "CA"
  },
  "items": {
   "item": {
    "description": "Product 1",
    "quantity": "2",
    "unit_price": "10",
    "discount": "5%",
    "subtotal": 19.00
   },
   "item": {
    "description": "Product 2",
    "quantity": "1",
    "unit_price": "30",
    "discount": "5%",
    "subtotal": 28.50
   }
  },
  "totals": {
   "subtotal": 47.50,
   "tax": "8.500%",
   "total": 51.53750
  }
 }
}
```

## Related Examples
  * Use Constant Directives
  * Conditionally Reduce a List through a Function
  * Define a Function that Flattens Data in a List
  * Pass Functions as Arguments


## See Also
  * DataWeave Core Functions
  * DataWeave Selectors
  *
Zip Arrays Together | MuleSoft Documentation
# Zip Arrays Together
This DataWeave example restructures bills of materials for Ikea-style furniture. The input contains the measurements and amounts of screws in two separate arrays that run in parallel, the transformation reorders them so that the "screws" array is made up of tuples, each with a measurement and its corresponding amount. The same is applied to wooden boards: the input contains two arrays with the x and the y measurements of each; the transformation rearranges them into a series of tuples, one for each board.
It uses these DataWeave functions:
  * `map` to go through the elements in the main array.
  * `zip` to rearrange pairs of long arrays, so that they’re grouped by index into multiple two-element arrays.


DataWeave Script:
```
%dw 2.0
output application/json
---
payload map (item, index) ->
{
  name: item.name,
  id: item.itemID,
  screws: zip(item.screws.size, item.screws.quantity),
  measurements: zip(item.measurements.x,item.measurements.y )
}
```

Input JSON Payload:
```
[
  {
  "name":"wooden-chair",
  "itemID": "23665",
  "screws":{
   "size":[4,6,10],
   "quantity":[15,8,28]
  },
  "measurements":
  {"x":[25,46, 46, 16,150,5, 100, 100, 8],
  "y":[15,4, 4, 80,3, 4, 4, 15]
  }
 },
  {
  "name":"coffee-table",
  "itemID": "14398",
  "screws":{
   "size":[3,8,10],
   "quantity":[8,12,20]
  },
  "measurements":
  {"x":[55, 48, 48, 48, 48, 30, 30, 30, 30],
  "y":[55, 40, 40, 40, 50, 4, 4, 4, 4]
  }
 }
]
```

Output JSON:
```
[
 {
  "name": "wooden-chair",
  "id": "23665",
  "screws": [
   [
    4,
    15
   ],
   [
    6,
    8
   ],
   [
    10,
    28
   ]
  ],
  "measurements": [
   [
    25,
    15
   ],
   [
    46,
    4
   ],
   [
    46,
    4
   ],
   [
    16,
    80
   ],
   [
    150,
    3
   ],
   [
    5,
    4
   ],
   [
    100,
    4
   ],
   [
    100,
    15
   ]
  ]
 },
 {
  "name": "coffee-table",
  "id": "14398",
  "screws": [
   [
    3,
    8
   ],
   [
    8,
    12
   ],
   [
    10,
    20
   ]
  ],
  "measurements": [
   [
    55,
    55
   ],
   [
    48,
    40
   ],
   [
    48,
    40
   ],
   [
    48,
    40
   ],
   [
    48,
    50
   ],
   [
    30,
    4
   ],
   [
    30,
    4
   ],
   [
    30,
    4
   ],
   [
    30,
    4
   ]
  ]
 }
]
```

## Related Examples
  *   *   * Define a Custom Addition Function
  * 

## See Also
  *   * DataWeave Selectors
  *
Confluent Schema Registry - XML and Maven Support | MuleSoft Documentation
# Confluent Schema Registry - 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/confluent-schema-registry
http://www.mulesoft.org/schema/mule/confluent-schema-registry/current/mule-confluent-schema-registry.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<mule xmlns:$2="http://www.mulesoft.org/schema/mule/confluent-schema-registry"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/$2
	http://www.mulesoft.org/schema/mule/$2/current/mule-confluent-schema-registry.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-confluent-schema-registry-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 `Confluent Schema Registry`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Values (dw::util::Values) | MuleSoft Documentation
# Values (dw::util::Values)
This utility module simplifies changes to values.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::util::Values` to the header of your DataWeave script.
_Introduced in DataWeave version 2.2.2._
## Functions
Name | Description  
---|---  
This function creates a `PathElement` to use for selecting an XML attribute and populates the type’s `selector` field with the given string.  
This function creates a `PathElement` data type to use for selecting an _object field_ and populates the type’s `selector` field with the given string.  
This function creates a `PathElement` data type to use for selecting an _array element_ and populates the type’s `selector` field with the specified index.  
This `mask` function replaces all _simple_ elements that match the specified criteria.  
This `update` function updates a field in an object with the specified string value.  
## Types
C-CDA to FHIR Converter | MuleSoft Documentation
# C-CDA to FHIR Converter
The C-CDA to FHIR converter comes with a ready to use template for CDA to FHIR conversion. This template can be extended or modified to meet specific conversion requirements.
## Functional diagram
## Advantages
  * Accelerates efforts to standardize on FHIR and enables more comprehensive view into patients
  * Follows best practices prescribed by HL7 and removes manual work associated with conversion
  * Solution can be extended to support additional CDA documents
  * Highly performant with underlying DataWeave engine


## See Also
  * MuleSoft Accelerator for Healthcare
Migrating the Choice Router | MuleSoft Documentation
# Migrating the Choice Router
Little changed between Choice router for Mule 3 and Mule 4 except for:
  * DataWeave is now the expression language so the when statements are actually going to use it instead of MEL
  * The `<otherwise>` block is now optional


## Expression Language for the When Block
The when expressions need to be changed from MEL to DataWeave. This also mean that you can leverage DataWeave’s ability to interpret any format to avoid unnecessary convertions. For example, suppose a flow in which a JSON document representing a user is posted through HTTP and you want to check if the person is underage:
Mule 3 Example: MEL
```
<flow name="checkAge">
 <http:listener path="person" method="POST" config-ref="http" />
 <json:json-to-object-transformer />
 <choice>
  <when expression="#[payload.age > 21]">
   <logger message="adult" />
  </when>
  <otherwise>
   <logger message="underage" />
  </otherwise>
 </choice>
</flow>
```

With Mule 4, you don’t need to worry about JSON or Java formats and just do:
Mule 4 Example: DataWeave 2
```
<flow name="checkAge">
 <http:listener path="person" method="POST" config-ref="http" />
 <choice>
  <when expression="#[payload.age > 21]">
   <logger message="adult" />
  </when>
  <otherwise>
   <logger message="underage" />
  </otherwise>
 </choice>
</flow>
```

## Optional Otherwise
In Mule 3, the `<otherwise>` block was required. Many times in which fallback logic was not necessary, you ended up with an `<otherwise>` block which just had an insignificant logger. In Mule 4, the `<otherwise>` block is optional and you don’t need to specify it if not necessary.
## See Also
Introduction to Mule 4: Error Handlers
Migrating from MEL to DataWeave
Migrating from DataWeave 1.0 to 2.x
Viewing API Details | MuleSoft Documentation
# Viewing API Details
To view the API Details page, select an API from the Home or APIs page of the portal. The API Details page includes the following information about an API:
  * **Name**
Name of the API.
  * **Type**
The API type can be AsyncAPI, HTML, REST, or SOAP.
  * **Contact email**
The email of the contact for the API.
  * **Categories**
The name and value of the predefined category this API belongs to. APIs can have multiple categories. Categories organize APIs into groups to improve browsing and discovery. Categories are created and maintained in Exchange.
  * **Tags**
The name of a predefined keyword associated with this API. APIs can have multiple tags. Tags are created and maintained in Exchange.
  * **Description**
A description of the API.
  * **Asset version**
The version of the API.
  * **Version state**
The lifecycle state (development, stable, or deprecated) of this API.
  * **Instances**
The count of instances of the API.
  * **Clients**
The number of client applications of the API.


The API Console is located in the API Details page. The console component is interactive and shows information about API specifications and their methods. Endpoints are displayed in alphabetical order. See Using the API Console for more information.
## View Categories and Tags
To view the categories or tags for an API:
  1. On the **API details** page, click **Categories** or **Tags** to view the information.
  2. Click **Categories** or **Tags** again to close the list.


## View Instances Information and Copy the URL
To view the name and URL of an API instance and copy the URL:
  1. On the **API details** page, click **View instances**.
  2. Click the copy icon.
  3. Click **Close**.


## See Also
  * Requesting Access to an API Instance
keySet | MuleSoft Documentation
# keySet
## keySet<K, V>(obj: { (K)?: V }): Array<K>
Returns an array of key names from an object.
_This function is**Deprecated**. Use dw::Core::keysOf, instead._
### Parameters
Name | Description  
---|---  
The object to evaluate.  
### Example
This example returns the keys from the input object.
#### Source
```
%dw 2.0
import * from dw::core::Objects
output application/json
---
{ "keySet" : keySet({ "a" : true, "b" : 1}) }
```

#### Output
```
{ "keySet" : ["a","b"] }
```

### Example
This example illustrates a difference between `keySet` and `nameSet`. Notice that `keySet` retains the attributes (`name` and `lastName`) and namespaces (`xmlns`) from the XML input, while `nameSet` returns `null` for them because it does not retain them.
#### Source
```
%dw 2.0
import * from dw::core::Objects
var myVar = read('<users xmlns="http://test.com">
           <user name="Mariano" lastName="Achaval"/>
           <user name="Stacey" lastName="Duke"/>
         </users>', 'application/xml')
output application/json
---
{ keySetExample: flatten([keySet(myVar.users) map $.#,
             keySet(myVar.users) map $.@])
}
++
{ nameSet: flatten([nameSet(myVar.users) map $.#,
          nameSet(myVar.users) map $.@])
}
```

#### Output
```
{
 "keySet": [
  "http://test.com",
  "http://test.com",
  {
   "name": "Mariano",
   "lastName": "Achaval"
  },
  {
   "name": "Stacey",
   "lastName": "Duke"
  }
 ],
 "nameSet": [
  null,
  null,
  null,
  null
 ]
}
```
Entities With AWS | MuleSoft Documentation
# Entities With AWS
The Entities with AWS action step enables you to use Amazon Comprehend to inspect text for named entities and return information about them.
## Inbound Variables
  * **Text**
The ext to analyze and extract entities from.
  * **Json Path**
Json Path Expression to filter the Normalized Json outbound result.
  * **AWS Credentials**
Or, if **Use custom settings** is activated in the wizard:
    * **Client Id**
    * **Client Secret**
    * **Session Token**
    * **Use Session Token**
    * **Region Endpoint**


## Outbound Variables
  * **Normalized Json**
The parsed result based on the normalized result and defined Json path.
  * **Raw Json**
The complete AWS response.


## Wizard
  * **Authentication Settings**
The AWS credentials to use for authentication
    * **Pin credentials**
Use this option to reference an existing **Credentials for AWS** configuration.
    * **Use custom settings**
Use this option to manually specify an AWS **Cliend ID** , **Client Secret** , **Region Endpoint** , and **Session Token** for this action step.
  * **Response settings**
    * **JsonPath Expression**
The Json path to the property of the response object.
  * **Text**
The text to analyze.
  * **Language**
The language of the source text to analyze.


## See Also
  *   *   * Building JSONPath Expressions
Azure Event Hubs Connector 1.0 | MuleSoft Documentation
# Azure Event Hubs Connector 1.0
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
API Functional Monitoring with the Blackbox Automated Testing (BAT) CLI | MuleSoft Documentation
# API Functional Monitoring with the Blackbox Automated Testing (BAT) CLI
You can use API Functional Monitoring to run a test or suite of tests on an API. API Functional Monitoring is based on Blackbox Automated Testing (BAT).
Using API Functional Monitoring, you can automate testing and get test reports. You can test before pushing code into your repository and before deploying to production. Tests can verify API functionality and validate results the API generates. You can monitor APIs at each stage of the software development life cycle and in production.
The prerequisites for testing and scheduling are:
  * One or more deployed APIs
  * Installation of BAT.
  * A directory that contains a test suite.
  * At least one test file in that directory.
You write tests in Behavior Driven Development (BDD) syntax using a code or text editor, such as IntelliJ. Test files must use the `.dwl` extension for processing by DataWeave.


An additional prerequisite, this one for monitoring scheduled tests in the cloud, is an account on Anypoint Platform.
## See Also
  *   * BDD Test Writing Language Reference
Workflow: Create a Mapping through the Anypoint Studio UI | MuleSoft Documentation
# Workflow: Create a Mapping through the Anypoint Studio UI
  1. Define Input and Output Structure of a Transformation Provide expected input and required output structures.
  2. Graphically Construct a Mapping Drag elements of the input and drop them onto elements of the output. You can also include fixed values and functions to build out the output.
  3. Preview the Output of a Transformation Verify that the transformation produces the expected output.


## See Also
Transform Message Component
DataWeave Language
Securing Runtime Fabric | MuleSoft Documentation
# Securing Runtime Fabric
To secure Anypoint Runtime Fabric, review the following topis:
  * Runtime Fabric Security Architecture Understand the architecture of how Runtime Fabric provides a secure way to manage MuleSoft applications and API gateways deployed onto Runtime Fabrics anywhere.
  * Configuring Authorized Namespaces Configure authorized namespaces to deploy Runtime Fabric alongside other services in a Kubernetes cluster.
  * Enabling FIPS 140-2 Compliance Mode Configure Runtime Fabric to run application containers in FIPS 140-2 compliance mode.
  * Using a Local Registry Use a local registry to pull and store Docker images.
  * Hardening Mule Runtime Review best practices for Mule runtime engine hardening with Runtime Fabric.


## See Also
  * Hardening Runtime Fabric
API Specification for MuleSoft Connectivity Ecosystem | MuleSoft Documentation
# API Specification for MuleSoft Connectivity Ecosystem
If you are an independent software vendor (ISV), you can participate in the MuleSoft Connectivity Ecosystem by auto-generating a connector from a REST API specification. These steps explain how to prepare your API specification in Anypoint Platform and how to work with your MuleSoft BD counterpart to do the rest.
  1. In Anypoint Platform, follow these steps to prepare your API specification:
    1. Sign up for Anypoint Platform:
https://anypoint.mulesoft.com/login/#/signup
    2. Log into Anypoint Platform and click **Design Center**.
    3. Create a new API specification project by clicking **Create new** in the top-right corner and then clicking **New API Specification**.
    4. In the **New API Specification** window, specify the name of the project, select **I’m comfortable designing it on my own** , and select the language of the specification. Then, click **Create API**.
    5. Delete the file that is automatically generated by hovering over its name, clicking the three dots to its right, and selecting **Delete**.
    6. On the left side of the screen, click the action menu (the three-dot icon) at the top of the file list and select **Import**. You can import a RAML or `.oas` file, a `.zip` file, or a specification that is at a URL.
    7. After importing, test your API to make sure it works as you expect it to.
      1. In the top-right corner of the screen, switch on the mocking service.
      2. In the file list, select your API specification.
      3. In the API summary on the right side of the screen, expand the **Resources** entry until you see the methods for your resources.
      4. Click one of the methods.
      5. Review the information about the method.
      6. Click **Try It**.
      7. If the endpoint requires parameters, specify values for them.
      8. Click **Send**.
The results of the test of the method appear on the right side of the screen under the **Send** button.
  2. After your API specification is ready, save it in a git-compatible repository, such as GitHub or Bitbucket.
  3. Contact your MuleSoft BD counterpart and follow these steps:
    1. Sign the Technology Partner Agreement (provided by your MuleSoft BD counterpart)
    2. Ask for an extension to the expiration date of your trial of Anypoint Platform.
    3. Ask for an invitation to the Connectivity Assets Manager tool, a self-service certification tool for connectivity assets, and create a new Anypoint Platform account based on the invitation.
    4. Schedule a short demonstration to help MuleSoft understand your APIs and how they work in Anypoint Platform.
Configuring Identity Management | MuleSoft Documentation
# Configuring Identity Management
As the Anypoint Platform organization administrator, you can configure identity management in Anypoint Platform to set up users for single sign-on (SSO). An organization can have up to 25 external identity providers, or _IdPs_ , configured for SSO. Configure identity management using one of the following single sign-on standards:
  * OpenID Connect: End user identity verification by an authorization server including SSO
  * SAML 2.0: Web-based authorization including cross-domain SSO


This diagram shows the SAML identity management process:
Before configuring OpenID Connect or SAML 2.0, select an OpenID Connect-compliant provider, such as PingFederate, OpenAM, or Okta. If you are not using OpenID Connect, select any SAML 2.0-compliant provider.
The following SAML providers are fully supported:
  * Salesforce
  * PingFederate (versions: 6, 7, 8)
  * OpenAM (version: 14)


The following SAML providers are known to work, but aren’t actively tested:
  * Active Directory Federation Services (AD FS)
  * Shibboleth
  * onelogin
  * CA Single Sign-On
  * SecureAuth


The following providers are fully supported to work with OpenID Connect:
  * Salesforce
  * PingFederate (versions: 6, 7, 8)
  * OpenAM (version: 14)


After you select an identity provider:
  * Set up your Anypoint Platform organization as your audience in your identity provider configuration.
The IdP you select is effective for the entire organization and all business groups.   
---  
  * Configure identity management in the Anypoint Platform root organization.
  * Configure attribute names on the IdP and Anypoint Platform to match.


For more information, see the documentation for your identity provider.
## Manage Users with an External Identity Provider
After configuring external identity management, you must add new SSO users using your external identity management solution and internal provisioning process. If you use the Invite User feature to add users to your organization after you have configured an external identity provider, the credentials for these users are stored in your organization using the Anypoint identity provider rather than with the external identity provider.
Users that sign in with SSO are new users to the system. If the new user has the same username as a user that already exists in your Anypoint Platform organization, the new user co-exists with the original user with the same username. Users with the same username are managed independently from one another.
## See Also
  * Configure OpenID Connect
  *   * Configure LDAP in Anypoint Platform Private Cloud
Set Toggle App Element | MuleSoft Documentation
# Set Toggle App Element
Use the _Set Toggle App Element_ action step to set a toggle App Element to `enabled` or `disabled`. Examples of these elements include checkboxes and toggle buttons.
## Properties
**Set Element to**
+ Enables you to define the status you want to set the element to: `enabled` or `disabled`.
## Inbound Variables
  * **XPath to Element**
  * **Window Title**
  * **Set Element to**


## Outbound Variables
The _Set Toggle App Element_ action step does not have any outbound variables.
## Wizard
See Common Properties (App Automation).
Modifying the User Interface | MuleSoft Documentation
# Modifying the User Interface
With the exception of the menu bar, all areas can be resized and positioned anywhere in the graphical user interface (GUI). Simply click on the title bar of the view you wish to move and drag the frame. It is possible to position the frame anywhere in the GUI by dropping it onto the positioning icons which appear when a frame is moved.
For example, drag the _Workflow Outline_ tab and drop it onto the positioning icon on the far right-hand side:
The _Workflow Outline_ is now docked to the right-hand edge:
You can also show any view as a standalone window. Again, start dragging a view by its title bar, but instead of dropping it onto a positioning icon, simply drop it anywhere else:
Furthermore, every frame can be hidden to make more working space available. To hide a frame, click on the pin icon in its title bar:
Hidden frames are accessible via the tabs located on the edges of the screen closest to their position before hiding. Move the mouse cursor over the tab and the frame will slide in again:
Setting Up Self-Managed Flex Gateway | MuleSoft Documentation
# Setting Up Self-Managed Flex Gateway
Setting up Anypoint Flex Gateway consists of installation and registration:
  * Downloading Flex Gateway
    * Install in Linux. Download for Docker or Kubernetes.
  * Registering and Running Flex Gateway in Connected Mode
    * Register in Connected Mode using an Anypoint username and password, a connected application, or a token.
  * Registering and Running Flex Gateway in Local Mode
    * Register in Local Mode using an Anypoint username and password, a connected application, or a token.


## See Also
  * Flex Gateway Overview
  * Getting Started with Self-Managed Flex Gateway