BassemE/mulesoft-documentation-embeddings huggingface dataset:
Compiling Custom Policies | MuleSoft Documentation
# Compiling Custom Policies
Compile your custom policy to create the policies binary target files by using the `make build` command. You must compile your custom policy after every time you edit the policy’s source code before you can deploy the policy to a Flex Gateway.
## Before You Begin
Ensure you have completed all the steps in Creating a New Project.
## Compile Using Build Command
To compile the policy, run the `make build` command from the policy’s root folder:
The `make build` command preforms the following actions:
  1. Runs the `make build-asset-files` script
  2. Runs the `make build` command to compile the policy to a `WebAssembly` binary file
  3. Generates additional configuration files that are not generated by the `make build-asset-files` script and are required to execute the policy


The `make build` command outputs the generated files to the `target` directories.
You can execute the `make build` command as many times as necessary to generate compiled artifacts. You must compile the custom policy for your source code and configuration edits to be present in the compiled artifacts.
When compiling your policy the first time, Rust fetches the latest version dependencies. If a dependency requires a Rust version later than {rust-ver-max-var}, pin the latest compatible version of the dependency with this command: ```
cargo update -p <conflicting_crate> --precise <major.minor.patch>
```
  
---  
## See Also
  * Debugging Custom Policies with the PDK Debugging Playground
  * Applying Custom Policies
  *
Grant Tokenization Permissions | MuleSoft Documentation
# Grant Tokenization Permissions
An administrator for your organization can grant management permissions to any user by using access management.
## Tokenization Permissions
A user must have a set of predefined permissions to create and manage tokenization formats and services:
Name | Description  
---|---  
Manage Tokenization Formats |  Provides the ability to create, modify, and delete tokenization formats to use with the tokenization service in a specific environment.  
Manage Tokenization Services |  Provides the ability to create and deploy a tokenization service, as well as modify and delete a tokenization service in a specific environment.  
## Grant a User Tokenization Permissions
  1. In the Access Management page, go to the left navigation menu and click **Users**.
  2. To grant permissions to a user, click the user’s name.
  3. In the **Permissions** tab, click **Tokenization**.
  4. Select **Manage Tokenization Formats** from the **Permissions** menu, and click the blue "plus" icon.
  5. Select the environment from the Environment menu, then select the **Manage Tokenization Services** permission from the Permissions menu, and click the blue "plus" icon.
Web Service Consumer Connector 1.6 | MuleSoft Documentation
# Web Service Consumer Connector 1.6
Anypoint Connector for Web Service Consumer (Web Service Consumer Connector) consumes a SOAP web service from a Mule app to acquire data from an external source. In many cases, you can use Anypoint Connector for Workday (Workday Connector) or Anypoint Connector for ServiceNow (ServiceNow Connector) to connect to a service provider, however, when no connector is available for a specific web service, the easiest way to consume the service is to use the Web Service Consumer Connector.
The main features of the connector include:
  * Ability to consume DOC literal web services
  * Use of SOAP multipart messages
  * Use of SOAP headers
  * Support for a DataSense for SOAP headers, SOAP body, and attachments
  * Use of embedded DataWeave transformations inside the operation
  * Support for a unified experience for SOAP with attachments and MTOM handling
  * Custom HTTP configuration as a transport
  * Support for Web Service Security (WS Security)


Web Service Consumer Connector doesn’t support RPC WSDLs (Remote procedure call Web Service Descripting Language).   
---  
## Before You Begin
To use this connector, you must be familiar with:
  * SOAP and WSDLs
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * DataWeave
  * Creating a Mule app using Anypoint Studio


Before creating an app, you must have access to Anypoint Studio.
## Audience
  * New user, read:
    * Studio Configuration
    * Additional Configuration Information to help extend your understanding of the Web Service Consumer Connector
    * Examples, which provides one or more use cases for the connector
  * Advanced user, read:
    * XML and Maven Support
    * Additional Configuration Information
    * Examples, which provides one or more use cases for the connector


## Next Step
After you complete the prerequisites and experiment with templates and examples, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Web Service Consumer in Exchange
  * MuleSoft Help Center
isTypeType | MuleSoft Documentation
# isTypeType
## isTypeType(t: Type): Boolean
Returns `true` if the input is the Type type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The type to check.  
### Example
This example shows how `isTypeType` behaves with different inputs.
#### Source
```
%dw 2.0
import * from dw::core::Types
type AType = Type
output application/json
---
{
  a: isTypeType(AType),
  b: isTypeType(Type),
  c: isTypeType(String),
}
```

#### Output
```
{
 "a": true,
 "b": true,
 "c": false
}
```
Tree (dw::util::Tree) | MuleSoft Documentation
# Tree (dw::util::Tree)
This utility module provides functions for handling values as tree-data structures.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::util::Tree` to the header of your DataWeave script.
_Introduced in DataWeave version 2.2.2._
## Functions
Name | Description  
---|---  
| Transforms a `Path` value into a string representation of the path.  
| Applies a filtering expression to leaf or `Path` values of an array.  
| Applies a filtering expression to leaf or `Path` values of keys in an object.  
Filters the value or path of nodes in an input based on a specified `criteria`.  
Returns `true` if the provided `Path` value is an `ARRAY_TYPE` expression.  
| Returns `true` if the provided `Path` value is an `ATTRIBUTE_TYPE` expression.  
| Returns `true` if the provided `Path` value is an `OBJECT_TYPE` expression.  
| Maps the terminal (leaf) nodes in the tree.  
Returns `true` if any node in a given tree validates against the specified criteria.  
## Variables
  * 

## Types
Migrating Transports | MuleSoft Documentation
# Migrating Transports
Mule 3 transports have been replaced by connectors, which follow an operation model in Mule 4. Most Mule transports are replaceable by a corresponding connector in Mule 4.
Some migration issues are common to all transports. For transport-specific migration documentation, refer to Migrating Connectors and Modules to Mule 4 and its child pages, instead.
## Endpoint Addresses
In Mule 3, an endpoint could be configured with either transport-specific attributes (for example, an HTTP endpoint could use `host`, `port`, and `path`) or with the generic `address` attribute.
Whenever the generic `address` attribute was used, it was possible to reference a property, for example:
```
<http:inbound-endpoint address="${External.URL}"/>
```

The properties configuration for `External.URL` looks something like this:
```
External.URL=http://0.0.0.0:8080/rootPath
```

In Mule 4, the connectors define the connection attributes separately, so any full address property has to be split into its components.
```
<http:listener-config name="listenerConfig">
  <http:listener-connection host="${External.URL.host}" port="${External.URL.port}"/>
</http:listener-config>
<flow>
  <http:listener config-ref="listenerConfig" path="${External.URL.path}"/>
  ...
</flow>
```

The configuration for the properties becomes:
```
External.URL.host=0.0.0.0
External.URL.port=8080
External.URL.path=/rootPath
```

Connector-specific documentation (such as for the HTTP or Email connector) provides detail on the exact properties that the connector requires.
## Service Overrides
In Mule 4, service override customizations through custom Java code are not supported in Mule 4.
In Mule 3, it is possible to customize the behavior of a transport through a connector’s `service-overrides` element. This element provides a way to reference Java classes with custom code that provides the new functionality.
Mule 3 Example: Connector with `service-overrides`
```
<imap:connector name="imapConnector" moveToFolder="processed" deleteReadMessages="false" checkFrequency="200">
  <service-overrides messageReceiver="org.mule.transport.email.functional.RetrieveMessageReceiverPollCounter"/>
</imap:connector>
```

The way to migrate such customizations to Mule 4 depends on what the custom code does, so you might:
  * Provide the functionality through another Mule feature or component, such as a DataWeave transformation, a Java Module, or a Scripting Module).
  * Use the Mule SDK to create a connector that provides your customized transport functionality. As a starting point, you can use open-source connectors as dependencies (for example, https://github.com/mulesoft/mule-http-connector).
  * Similar to the previous approach, you can fork an open-source connector repository and add your custom code to the fork. MuleSoft welcome Pull Requests for your changes.
  * Provide a feature request to MuleSoft. You can request that MuleSoft add the functionality that your custom code provided through `service-overrides`. Visit MuleSoft Support Ideas to submit such requests.


## See Also
Migrating Connectors and Modules to Mule 4
xsiType | MuleSoft Documentation
# xsiType
## xsiType(name: String, namespace: Namespace)
Creates a `xsi:type` type attribute. This method returns an object, so it must be used with dynamic attributes.
_Introduced in DataWeave version 2.2.2._
### Parameters
Name | Description  
---|---  
The name of the schema `type` that is referenced without the prefix.  
`namespace` | The namespace of that type.  
### Example
This example shows how the `xsiType` behaves under different inputs.
#### Source
```
%dw 2.0
output application/xml
ns acme http://acme.com
---
 {
   user @((xsiType("user", acme))): {
     name: "Peter",
     lastName: "Parker"
   }
 }
```

#### Output
```
<?xml version='1.0' encoding='UTF-8'?>
 <user xsi:type="acme:user" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:acme="http://acme.com">
   <name>Peter</name>
   <lastName>Parker</lastName>
 </user>
```
Browser Support for Anypoint Platform | MuleSoft Documentation
# Browser Support for Anypoint Platform
Use Anypoint Platform with the latest version of any supported browser:
  * Microsoft Edge with Chromium
  * Microsoft Edge without Chromium (supported through December 31, 2020)
  * Google Chrome
  * Mozilla Firefox
  * Safari


Browser support for Anypoint Platform follows the Salesforce Lightning Experience policy.
## Exceptions to Browser Support Policy
Partner Manager 2.0 modifies the browser support policy:
  * 

## Unsupported Browsers
Internet Explorer versions 11 and earlier are not supported. If you use the browser with Anypoint Platform, you might experience issues.
## See Also
Supported Browsers for Lightning Experience
Jira Connector 1.2 XML and Maven Support | MuleSoft Documentation
# Jira Connector 1.2 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/jira
http://www.mulesoft.org/schema/mule/jira/current/mule4-jira.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<mule xmlns:$2="http://www.mulesoft.org/schema/mule/jira"
	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/mule4-jira.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-jira-connector</artifactId>
	<version>1.0.0</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 `jira`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Mocking Resources for Your Tests | MuleSoft Documentation
# Mocking Resources for Your Tests
Anypoint Code Builder 
Anypoint Studio 
As your tests suites start to get bigger and more complex, it’s a good practice to externalize some parts of the test code, not only so that you can keep the code clean and organized but also to reuse the files that you need to mock for your tests.
Mule 3 uses a `getResourceAsString()` function to incorporate external or mocked resources into your tests. In Mule 4, you can leverage DataWeave to mock your test code, either by creating DataWeave scripts or by using variables in a DataWeave module.
## Mock Files Using DataWeave File
You can write a DataWeave file that returns the data that you want to mock, save the file under a folder in `src/test/resources` and then use a DataWeave function from your test to read this file.
For example, imagine that you have defined a `mockPost.dwl` file in the `src/test/resources/sample_data` folder with the following content:
```
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file (`mockPost.dwl`) is a sample that creates a mock payload that you want to return in an `http:request` request.
When configuring the `then-return` section in the `mock-when`, use the `readUrl` function to read the mapping file:
```
<munit-tools:then-return>
 <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

The `classpath-based` URL uses the `classpath:` protocol prefix to find the file defined in `src/test/resources`.
## Mock Files Using Variables in a DataWeave Module
You can create a DataWeave module to centralize all your mocked data in a single file by declaring it using DataWeave variables.
For example, imagine that you create a custom DataWeave module by creating a `TestData.dwl` file in `src/test/resources`, and you add variables with references to different mocked data, either from files or inline:
```
import getResourceAsString from MunitTools
var mockPost = readUrl('classpath://sample_data/mockPost.dwl')
var foo = "N123"
var jsonFromFile = read(getResourceAsString('sample_data/mydata.json'), 'application/json')
var jsonObject = { paymentID: "1B56925769601335TLQMIWVY" }
```

You can then access any of the defined variables in the DataWeave module by importing the variables from your module:
```
<munit-tools:then-return >
  <munit-tools:variables>
    <munit-tools:variable key="ticket" value="#[import TestData output application/json --- TestData::mockPost]" mediaType="application/json" />
  </munit-tools:variables>
</munit-tools:then-return>
```

## See Also
  * Create Custom Modules and Mappings
Managing Anypoint Platform PCE | MuleSoft Documentation
# Managing Anypoint Platform PCE
After your installation is complete, your instance of Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) is ready to use.
## Users Using Anypoint Platform PCE
Ensure that users registered in your external identity service have access to your Anypoint Platform organization.
You can also register servers so that you can then deploy to them, and so on.
## Mule Developers Using Anypoint Studio
Mule app developers in your organization who create Mule apps through the Anypoint Studio IDE must set up their editors so the Mule apps interface with your locally installed Anypoint Platform rather than the default cloud Anypoint Platform.
## Manage Anypoint Platform PCE
The following topics describe how to manage Anypoint Platform PCE:
  * Backing up and restoring for Anypoint Platform PCE
  * Allowing addresses for API Platform proxies
  * Uploading custom policies and publish assets to exchange using the Maven client
  * Adding Compatible Java Versions for Assets Using the Maven Client
  * Configuring Anypoint Studio for Anypoint Platform PCE
  * Analyzing Business and API Data Using ELK
  * Troubleshooting Mule Runtime Engine Registration
  * 

## See Also
  * Installing Anypoint Platform Private Cloud Edition (Anypoint Platform PCE)
  * Configuring Anypoint Platform PCE
Mail Operations | MuleSoft Documentation
# Mail Operations
Mail Operations enable interactions with an email inbox.
  * The Mail Session action step is an inclusive element for all mail operations.
  * With the Read Mail action step, you can read the e-mails from a mailbox.
  * With the Send Mail action step, you can send an e-mail with the SMTP protocol.
  * With the Set Mail action step, you can change the status of an e-mail.
Monitoring in Connected Mode | MuleSoft Documentation
# Monitoring in Connected Mode
Flex Gateway running in Connected Mode enables you to monitor APIs via Anypoint Platform. By using Anypoint Platform, you can configure logs and view key metrics and analytics.
Refer to the following tasks for details about monitoring in Connected Mode:
  * Configure Message Logging - Apply a Message Logging policy to your API instance via API Manager. This policy enables you to view basic logs for Flex Gateway APIs.
  * Configure API Alerts - Configure API alerts to receive email notifications that flag unusual API behavior.
  * Configure Flex Gateway Log Output for Third-Party Services - Configure log output for consumption by third-party services such as Splunk.
  * View Key Metrics for Flex Gateway APIs - Collect metrics for active Flex Gateway APIs via API Manager. You can view charts and filter metrics by date.
  * View the Replica Status in Runtime Manager - View Flex Replica connection status from Runtime Manager.
  * View the Flex Gateway API Status in Runtime Manager - View the Flex Gateway API status from Runtime Manager.
  * View Runtime Logs in Runtime Manager - View details of your Flex Gateway logs from Runtime Manager.
  * View Logs in Anypoint Monitoring - View details of your Flex Gateway logs from within the Anypoint Monitoring UI.
  * Disable Flex Gateway Log Output - Disable log output to Anypoint Platform by using a local declarative configuration file.
Configuring Client Apps | MuleSoft Documentation
# Configuring Client Apps
When using Anypoint Connector for MQ (Anypoint MQ Connector) version 3.x or earlier, you create a client app to generate credentials to use to publish and consume from a queue.
MuleSoft recommends that you use connected apps rather than client apps to generate credentials. For information, see Configuring Connected Apps.
When you create a client app, Anypoint MQ lists the client ID and client secret for the app. You use the client ID and client secret values when configuring Anypoint MQ Connector in a Mule app in Anypoint Studio. Don’t share the ID and secret pair with multiple apps.
An app does not need to exist for you to register it with Anypoint MQ Connector.
## Create a Client App
To create a client app:
  1. Sign in to Anypoint Platform and click **MQ** in the navigation menu.
  2. Click **Client Apps** in the navigation pane:
**Client Apps** displays and creates client apps.  
---  
**Add** icon adds a client app.  
  3. Click the **Add** icon ().
  4. In the **Create Client App** window, enter the name of the client app, such as `DemoClientApp` and click **Save Changes**.
  5. Click the client app name to view the client app ID and client secret values in the details pane:
Client app name displays client app details.  
---  
**Copy** buttons copy the client app ID or client secret value.  
**Show** displays the client secret value, which is obfuscated by default.  
  6. Click **Copy** to copy the client app ID or client secret value to your clipboard.
  7. When you configure Anypoint MQ Connector in your Mule app, paste the client app ID and client secret values to the **Anypoint MQ Config** window in Studio:
For more information, see Tutorial: Create a Queue and Send Messages to It.


## Regenerate a Client Secret
You might need to regenerate the client secret for a client app ID if your organization’s security policy requires that you change client secrets on a schedule.
Another reason you might need to regenerate the client secret is to revoke access to a client ID by a specific consumer or publisher. In this case, you can regenerate the client secret in Anypoint MQ and reconfigure the secret in only those apps for which you want to allow access.
To regenerate the client secret:
  1. Sign in to Anypoint Platform and click **MQ** in the navigation menu.
  2. Click **Client Apps** in the navigation pane.
  3. Click the client app name to display the details pane.
  4. Click **Regenerate Secret** :


## Delete a Client App
To delete a client app:
  1. Sign in to Anypoint Platform and click **MQ** in the navigation menu.
  2. Click **Client Apps** in the navigation pane.
  3. Click the client app name to display the details pane.


## See Also
  * Anypoint MQ Connector Reference
  *   * Configuring Connected Apps
  * Anypoint MQ on Hyperforce
Licensing Overview | MuleSoft Documentation
# Licensing Overview
Anypoint API Community Manager licenses are procured and provisioned by MuleSoft. A standard API Community Manager license consists of a _Salesforce Customer Community Plus Login License Unlimited Edition_. It is based on the number of member logins per month, and includes as a base:
  * Up to 100 communities
  * Five (5) admin users (community administrators or operators)
  * Connectivity to one (1) Anypoint Platform top-level organization
  * Up to 10,000 member accounts across all communities
  * Salesforce Standard Objects, Features, Capability, and Custom Objects in Customer Community Plus
  * One (1) megabyte storage per user for all communities
  * 10 megabyte storage for organization and session caches
  * One (1) million page views per month across all communities
  * 40 gigabit network bandwidth in production environments for all communities and 1 gigabit network bandwidth for all sandbox environments
  * 100 Developer sandboxes, 5 Developer Pro sandboxes, 1 Partial Copy sandbox, and 1 Full Copy sandbox
  * 10 Custom Objects
  * 10 API calls per day to the Salesforce Digital Experience site


Community login-based license is calculated by the number of **daily unique logins** : login actions that different members perform daily in your communities during a month. Members associated with your license consume one login each day they log into any of your communities. Logging in multiple times during the same day only consumes one login. Once logged in, switching between communities doesn’t consume extra logins.
Forecasting the adequate number of daily unique logins is critical to ensure that you have enough licenses to satisfy the demand your community will generate. Your MuleSoft account team will assist you in this analysis as part of the capacity planning and community design process before you roll out your community.
You can find more information about **Salesforce Customer Community Plus Login License Unlimited Edition** in the Salesforce Experience Cloud documentation page Communities User Licenses.
Additional capacity can be provisioned to your organization if required. For more information, contact your MuleSoft representative.
Web Service Consumer Connector Examples | MuleSoft Documentation
# Web Service Consumer Connector Examples
The following examples illustrate how to configure Anypoint Connector for Web Service Consumer (Web Service Consumer) Connector operations both in Anypoint Studio and the XML editor.
  * Web Service Consumer Connector Example 1 This example transforms a variable value into XML and pass that value to the Web Service Consumer Connector, which subsequently consumes a web service.
  * Web Service Consumer Connector Example 2 This example list an inventory of t-shirts and the Web Service Consumer Connector returns if there is an error such as `BAD_RESPONSE` or `EMPTY_RESPONSE`.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Values Types (dw::util::Values) | MuleSoft Documentation
# Values Types (dw::util::Values)
Type | Definition | Description  
---|---|---  
UpdaterValueProvider |  `type UpdaterValueProvider = (newValueProvider: (oldValue: Any, index: Number) -> Any) -> ReturnType` |  Type that represents the output type of the update function. _Introduced in DataWeave version 2.4.0._
Administer Your Site | MuleSoft Documentation
# Administer Your Site
Administering your Anypoint API Community Manager site includes performing basic maintenance on your API Community Manager Salesforce organization, checking for important notifications about new API Community Manager upgrades and downtime, performing diagnostics, and using sandboxes. Administering your site also includes getting support from MuleSoft, if necessary.
These pages explain how to perform each action:
  * Salesforce documentation: Maintain an Organization
  * Check for Important Notifications
  * Administer Salesforce Releases and Migrations
  * Check API Community Manager Diagnostics
  * Use API Community Manager Sandboxes
  * Contact MuleSoft Support
ServiceNow Connector 6.8 | MuleSoft Documentation
# ServiceNow Connector 6.8
Anypoint Connector for ServiceNow (ServiceNow Connector) provides connections between Mule runtime engine (Mule) and ServiceNow apps. Use the ServiceNow operations with the custom ServiceNow tables, along with any operations available through the installed plugins.
For compatibility information and fixed issues, see the ServiceNow Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow and global elements
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have access to the ServiceNow target resource and Anypoint Platform.
## Common Use Cases For the Connector
ServiceNow Connector enables organizations to fully integrate business processes across HR, legal, procurement, operations, marketing, and facilities departments. Creating connectivity within and outside of the enterprise is quick and simple with the integration of over 120 Anypoint Connectors.
Use ServiceNow Connector to create instant API connectivity with the ServiceNow API, and quickly and easily interface with ServiceNow from within Anypoint Platform.
For examples, see example use cases, which include getting a ServiceNow incident record.
## Audience
  * New users, read:
    * Using Anypoint Studio to Configure the Connector to create your Mule app
  * Advanced users, read:
    * XML and Maven Support
    * Examples, which provides one or more use cases for the connector


## Connection Types
The following authentication types are supported:
  * Basic
  * OAuth 2.0 Authorization Code


### Limitations
  * OAuth 2.0 Authorization Code authentication works only with the following versions of Mule:
    * 4.1.5
    * 4.2.1 and later
  * Metadata does not work with OAuth 2.0 Authorization Code authentication.


## Use Exchange Templates and Examples
Anypoint Exchange provides templates you can use as a starting point for your app, as well as examples that illustrate a complete solution.
  * Workday and ServiceNow Worker Bidirectional Sync
  * Workday Worker to ServiceNow Service Request Migration
  * Workday and ServiceNow Employee Aggregation
  * Workday to ServiceNow Service Worker Migration
  * Workday Worker to ServiceNow Service Request Broadcast


## Next Step
After you complete the prerequisites and experiment with templates and examples, you are ready to create an app with Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Anypoint Exchange to Discover Connectors, Templates, and Examples
  * ServiceNow Connector Release Notes
  * ServiceNow Connector on Exchange
  * MuleSoft Help Center
Math Variables (dw::util::Math) | MuleSoft Documentation
# Math Variables (dw::util::Math)
Variable | Definition | Description  
---|---|---  
Variable `E` sets the value of mathematical constant `e`, the base of natural logarithms. _Introduced in DataWeave version 2.4.0._  
Variable `PI` sets the value of constant value pi, the ratio of the circumference of a circle to its diameter. _Introduced in DataWeave version 2.4.0._
Implementing and Validating Avro Schemas in APIkit for AsyncAPI Module | MuleSoft Documentation
# Implementing and Validating Avro Schemas in APIkit for AsyncAPI Module
APIkit for AsyncAPI supports Avro, a data serialization system that helps you define the format for specifying the structure and encoding of messages. This module shows you the structure of messages in the design phase. APIkit for AsyncAPI also supports DataSense of messages with Avro schema.
## Schema Definitions
The Avro spec defines its format by giving the value of `schemaFormat` as `application/vnd.apache.avro`.
The Avro spec supports describing the schema inline or referencing an external document that describes the schema in the Avro format:
  * Inline definition
```
publish:
 summary: inform details about person
 operationId: lightMeasured
 message:
  schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
  payload:
   name: lightMeasured
   type: record
   fields:
    - name: lumens
     type: int
     example: 134
    - name: sentAt
     type: string
     logicalType: timestamp-millis
     10
     example: 1985-04-12T23:20:50.52Z
```

  * Reference to an Avro fragment
```
channels:
 smartylighting.streetlights.1.0.event.{streetlightId}.monitor:
  publish:
   message:
    schemaFormat: application/vnd.apache.avro;version=1.9.0
    payload:
     $ref: /exchange_modules/83589b9b-6630-4c28-985d-174ee9172661/lumenschema/1.0.0/lumens.json'
```



The `lumens.json` file provides the specification in the Avro schema.
```
{
 "type": "record",
 "name": "lightMeasured",
 "fields": [
  {"name": "lumens", "type": "int"},
  {"name": "sentAt", "type": {"type": "string", "logicalType": "timestamp-millis"}}
 ]
}
```

APIkit for AsyncAPI supports async APIs that have Avro messages defined inline. APIkit for AsyncAPI doesn’t support API specs that refer to Avro fragments.
## Avro Message Encoding and Validation
Avro messages are encoded in either binary or text (JSON) format. The specification provides the value of `contentType` OR `defaultContentType`.
APIkit for AsyncAPI validates messages encoded in text (JSON) but doesn’t validate binary-encoded messages.
sumBy | MuleSoft Documentation
# sumBy
## sumBy<T>(@StreamCapable array: Array<T>, numberSelector: (T) -> Number): Number
Returns the sum of the values of the elements in an array.
### Parameters
Name | Description  
---|---  
The input array.  
`numberSelector` | A DataWeave selector that selects the values of the numbers in the input array.  
### Example
This example calculates the sum of the values of elements some arrays. Notice that both of the `sumBy` function calls produce the same result.
#### Source
```
%dw 2.0
import * from dw::core::Arrays
output application/json
---
{
 "sumBy" : [
  [ { a: 1 }, { a: 2 }, { a: 3 } ] sumBy $.a,
  sumBy([ { a: 1 }, { a: 2 }, { a: 3 } ], (item) -> item.a)
 ]
}
```

#### Output
```
{ "sumBy" : [ 6, 6 ] }
```

## sumBy(array: Null, numberSelector: (Nothing) -> Any): Null
Helper function that enables `sumBy` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
XML Module Examples | MuleSoft Documentation
# XML Module Examples
To fully benefit from using XML module, see the following examples of configuring the module operations:
  * Configure XQuery Transformations Configure the **Xquery transform** operation to take XML input content and transform it based on XQuery expressions.
  * Configure XPath Extractions Configure the **Xpath extract** operation to evaluate Xpath expressions in XML input content and extract the result. The operation also enables you to set namespace mapping.
  * Configure Xslt Transformations Configure the **Xslt transform** operation to take XML input and transform it using an XSL style sheet.
  * Validate Documents against an XSD Schema Configure the **Validate schema** operation to validate documents against an XSD schema.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
sum | MuleSoft Documentation
# sum
## sum(@StreamCapable values: Array<Number>): Number
Returns the sum of numeric values in an array.
Returns `0` if the array is empty and produces an error when non-numeric values are in the array.
### Parameters
Name | Description  
---|---  
The input array of numbers.  
### Example
This example returns the sum of the values in the input array.
#### Source
```
%dw 2.0
output application/json
---
sum([1, 2, 3])
```
Test Recorder in Studio | MuleSoft Documentation
# Test Recorder in Studio
The Test Recorder enables you to record a processing flow and then configure a unit test based on the captured event.
The test recorder captures real data as it goes through your application in Anypoint Studio. By capturing the flow execution, MUnit can automatically generate an MUnit test so that you can configure the necessary mocks and assertions for your test. See Recording a Test from an Exchange Example for a fully working example.
## Compatibility
The following table describes the product versions required to use the Test Recorder.
Product | Version  
---|---  
Anypoint Studio |  7.5.0 and later  
2.2.5 and later  
MUnit Anypoint Studio Plugin |  2.5.0 and later  
Mule runtime engine |  4.3.0 and later  
## Limitations
The test recorder has the following limitations when you create MUnit tests:
  * You cannot create tests for flows with Mule errors raised inside the flow or already existing in the incoming event, even if an **on error continue** error handler controls them.
  * A recorded flow execution ends successfully, but the result does not reach its destination because the application is killed.
  * Your validations fail every time your test runs if you configure `spy` or `assert` processors to assert values for random data, time-dependent information (such as timestamps), or values resulting from parallel processes, because those values change in every execution.
  * Mocking values resulting from parallel processes causes a mixture of real and mocked data that compromises the execution of the processors that follow in your test.
  * Although the recorder supports data iteration in the flow, such as recursions or loops, it does not support cases in which the structure of the data being tested changes inside the iteration.
  * The recorder does not support mocking a message before or inside a `foreach` processor.
  * When using the Test Recorder to generate a test over your flow, you can only mock parameters included in your flow. You cannot mock parameters in sub-flows or in referenced flows through the Test Recorder UI. If you need to mock parameters in sub-flows of any other process in the project, you can modify the mocking component after creating the test.


## See Also
  * Recording a Test from an Exchange Example
  * Mocking a Message Before and Inside a Foreach Processor
Accessing Request Authentication Information | MuleSoft Documentation
# Accessing Request Authentication Information
The `Authentication` injectable provides an interface to:
  * Propagate authentication data for consumption by other policies.
  * Consume authentication data already set by another policy.


To share data, `Authentication` implements the `AuthenticationHandler` trait:
```
pub trait AuthenticationHandler {
  fn authentication(&self) -> Option<AuthenticationData>;
  fn set_authentication(&self, authentication: Option<&AuthenticationData>);
}
```

The `AuthenticationData` struct contains the following authentication data:
```
pub struct AuthenticationData {
  pub principal: Option<String>,
  pub client_id: Option<String>,
  pub client_name: Option<String>,
  pub properties: Value,
}
```

For example, the following code reads the `Authentication` data and modifies it by overriding the `client_id` and `client_name`:
```
async fn request_filter(state: RequestState, authentication: Authentication) -> Flow<()> {
  let state = state.into_headers_state().await;
  let header_handler = state.handler();
  let auth = authentication.authentication().unwrap_or_default();
  let properties = auth.properties.as_object().cloned().unwrap_or_default();
  let client_id = header_handler
    .header("custom_client_id_header")
    .unwrap_or_default();
  let client_name = header_handler
    .header("custom_client_name_header")
    .unwrap_or_default();
  let auth = AuthenticationData::new(
    auth.principal,
    Some(client_id),
    Some(client_name),
    properties
  );
  authentication.set_authentication(Some(&auth));
  Flow::Continue(())
}
#[entrypoint]
async fn configure(launcher: Launcher) -> Result<()> {
  let filter = on_request(|rs, auth| request_filter(rs, auth));
  launcher.launch(filter).await?;
  Ok(())
}
```

## See Also
  *
Check Value | MuleSoft Documentation
# Check Value
This action step allows you to compare two numerical or alphanumerical (case-sensitive and case-insensitive) values to each other, using different comparison methods.
## Properties
**Compare Settings**
  * **Compare Mode** Decide whether to compare two numerical or alphanumerical values to each other. When using alphanumeric comparison, the ASCII values of the given characters will be compared. For example, "B" has an ASCII value of 66 and "a" has an ASCII value of 97, so "a" is greater than "B", so "a" is greater than "B" would be true if upper and lower case are taken into consideration when comparing (Compare Alphanumeric (case-sensitive)) and false if upper and lower case are not taken into consideration (Compare Alphanumeric (case-sensitive)).
  * **Compare Operator** Define how the two values should be compared. You can choose whether the values need to be equal or unequal, or if one should be greater than or smaller than the other.


**Compare Values**
  * **Value 1** Value to the left of the compare operator, e.g. a in a>b
  * **Value 2** Value to the right of the compare operator, e.g. b in a>b


## Inbound Variables
**Compare Value 1** Value to the left of the compare operator, e.g. a in a>b
**Compare Value 2** Value to the right of the compare operator, e.g. b in a>b
## Outbound Variables
**Compare Result** Returns whether the comparison was successful or not (Bool)
## Wizard
Note that both comparison values can be mapped to variables.
Salesforce Commerce Cloud B2C Data Connector | MuleSoft Documentation
# Salesforce Commerce Cloud B2C Data Connector
No further updates or new versions are planned for this connector. Use Anypoint Connector for HTTP (HTTP Connector) instead. Refer to the migration guide.   
---  
Anypoint Connector for Salesforce Commerce Cloud B2C Data API (B2C Data Connector) enables you to access the Commerce Cloud Data API by using certain configurations, and to then access the data, update the data, and delete the data, as required.
Salesforce Commerce Cloud B2C Data Connector and Salesforce Commerce Cloud B2C Shop Connector cannot be run in the same application.   
---  
## Before You Begin
To use this connector, you must be familiar with:
  * The Commerce Cloud Data API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Anypoint Studio version 7 or later
  * Commerce Cloud credentials such as client Id, Client Secret, and Scopes to access the Data API. You can get the required credentials from the Salesforce team.


## Audience
  * New users, read:
    * Using Anypoint Studio to Configure B2C Data Connector to create your Mule app.
    * The Examples topic, which provides one or more use cases for using the connector.
  * Advanced users, read:
    *     * The Examples topic, which provides one or more use cases for using the connector.


## Authentication Types
B2C Data Connector connections use the OAuth 2 Application Provider authentication type.
## 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
Usage and Engagement Metrics | MuleSoft Documentation
# Usage and Engagement Metrics
In Exchange, administrators and asset owners can gain insight into the consumption and user engagement of their API specification fragments and REST API assets.
The usage metrics measure:
  * The number of times the asset was downloaded from Exchange.
  * The number of imports from API Designer.
  * The number of imports from Anypoint Studio.
  * The number of dependents for the asset.
  * The number of contracts for the asset.


The asset engagement score is a composite metric that administrators and asset owners can use to measure the usage of the assets in Exchange.
Administrators can view the **Usage and engagement metrics** dashboard for metrics of API specification fragments and REST API assets in an organization. Administrators and asset owners with the Exchange contributor permission can view usage and engagement metrics for a specific asset version from the asset details page. You can share data by exporting metrics to a CSV file.
Exchange assets capture usage and engagement metrics to:
  * Drive growth and engagement, and asset reuse across the entire catalog.
Access usage metrics and engagement scores to get a composite view into how your assets are being utilized.
  * Track and manage asset adoption with out-of-the-box dashboards.
View performance analytics of your entire asset library in a single location.


## Permission and License Requirements
The following permissions and licenses are required to view the usage and engagement metrics:
  * Administrators must have the Exchange Administrator role permission for any organization to view the **Usage and engagement metrics** dashboard.
  * Administrators and asset owners must have the contributor permission to view usage details for a specific API specification fragment and REST API assets, and their versions on the asset details page.
  * Every customer tier license can view the metrics except the Industry Starter license.


## See Also
  * Asset Usage and Engagement Metrics Dashboard
  * Metrics for a Specific Asset and Version
Database Connector 1.13 | MuleSoft Documentation
# Database Connector 1.13
Anypoint Connector for Database (Database Connector) establishes communication between your Mule app and a relational database. Database Connector can connect to almost any Java Database Connectivity (JDBC) relational database and run SQL operations. An application can support multi-tenant scenarios using the same configuration element, changing the connection attributes based on, for example, information coming from each request.
Database Connector has connection providers that automatically set the driver class name and create JDBC URLs with given parameters for the following databases:
  * Derby
  * Microsoft SQL Server
  * MySQL
  * Oracle


You can set up other JDBC databases using a generic JDBC configuration. Database Connector is JDBC compliant. Ensure that for the connection configuration, you use a driver that is compliant with JDBC to avoid compatibility issues. Additionally, you can reference a JDBC `DataSource` object or an `XADataSource` object, which is required for XA transactions, by creating the object in Anypoint Studio using Spring.
## Before You Begin
To use this connector, you must be familiar with:
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have access to the database target resource, Anypoint Platform, and have downloaded the proper database driver for your database.
## Common Use Cases for the Connector
Database Connector enables you to:
  * Perform predefined queries, dynamically constructed queries, and template queries that are self-sufficient and customizable.
  * Specify DataWeave expressions in connector fields and configure attributes dynamically, depending on the database configuration you use.
  * Use a source listener operation to read from a database in the data source section of a flow.
  * Execute other operations to read and write to a database anywhere in the process section.
  * Perform multiple SQL requests in a single bulk update.
  * Make Data Definition Language (DDL) requests that alter the data structure rather than the data itself.
  * Execute stored procedures and SQL scripts.


For examples, see Examples.
## Audience
  * New users, read:
    * Using Anypoint Studio to Configure the Connector to create your Mule app
    * Examples, which provide one or more use cases for the connector
  * Advanced users, read:
    * XML and Maven Support
    * Examples, which provide one or more use cases for the connector


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


## Next Step
After you complete the prerequisites and try the templates and examples, you are ready to create your own app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center