BassemE/mulesoft-documentation-embeddings huggingface dataset:
Viewing Key Metrics in API Manager for Flex Gateway in Connected Mode | MuleSoft Documentation
# Viewing Key Metrics in API Manager for Flex Gateway in Connected Mode
API Manager and Anypoint Monitoring collect metrics on active Flex Gateway API instances. You can view charts related to these metrics and filter the data by date.
The metrics available in API Manager are considered **Key Metrics** and are described here. **Key Metrics** are available with all Anypoint Platform subscriptions. For additional Flex Gateway API metrics not included in the **Key Metrics** section, use Anypoint Monitoring (Anypoint Integration Advanced package or Titanium subscriptions only). You can navigate to Anypoint Monitoring by clicking **Anypoint Monitoring** from Anypoint Platform.
The **Mule API Analytics** tab in API Manager is currently not available for Flex Gateway APIs. Use the **Key Metrics** or the additional metrics in Anypoint Monitoring.  
---  
## Key Metrics
  1. Log in to Anypoint Platform.
  2. In the navigation bar or the Anypoint Platform page, click **API Manager**. The **API Administration** page appears, showing a list of APIs that are available in your organization.
  3. Click the API instance. The **API Summary** page appears, showing general information and the status of the API instance.
To see an API instance in Anypoint Monitoring, from the **Key Metrics** section click **View more metrics in Anypoint Monitoring dashboard** or navigate to Anypoint Monitoring directly.


The **Key Metrics** section shows four charts. If charts do not appear for your API instance, refresh your browser.
## Understanding Key Metrics
The **Key Metrics** section of the API summary contains the following charts: 

Total Requests
    
Sum of requests in the selected time period for the given API.
Data is aggregated in one minute increments. 

Total Policy Violations
    
Sum of requests that return policy violations.
Data is aggregated in one minute increments. 

Total Errors
    
Sum of HTTP response codes that occur in the selected time period. The response codes counted in this metric are 400, 401, 402, 403, 404, 405, 408, 409, 410, 411, 412, 413, 415, 416, 417, 420, 422, 429, 500, 502, 503, 504, 504, 510, and 511.
Data is aggregated in one minute increments. In the chart, HTTP response codes are abbreviated as 4xx and 5xx. 

Average Response Time
    
Average response time of requests in the selected time period for the given API.
Data is aggregated in one minute increments.
## Setting the Time Period for Key Metrics
You can view the data points collected for the last given period of time (such as the last 5 or 30 minutes) or over a given date and time range. Use the drop-down in the calendar icon to select the time period to display.
## See Also
  * Using Flex Gateway API Alerts
  * Setting Up Basic Alerts in Anypoint Monitoring.
  * Using Built-in API Dashboards
Introduction to Mule 4: DataWeave 2.0 | MuleSoft Documentation
# Introduction to Mule 4: DataWeave 2.0
DataWeave 2 is largely unchanged from DataWeave 1. However, MuleSoft made many improvements to make it easier to learn and added new capabilities.
## Operators Are Functions
In DataWeave 2, all operators are now functions. While this can involve more parentheses, it is less ambiguous and more friendly to learn through auto-completion features. The previous syntax continues to work for functions with two parameters, providing a shorter syntax for power users.
DataWeave 1 | `sizeOf payload filter $.age > 30`  
---|---  
DataWeave 2 - Function Syntax | `sizeOf(filter(payload, (value) → value.age > 30)))`  
DataWeave 2 - Shortcut Syntax | `sizeOf(payload filter $.age > 30)`  
## Traits Are Functions
DataWeave 1 | `payload is :empty`  
---|---  
DataWeave 2 | `isEmpty(payload)`  
## Type Names
DataWeave 2 uses a type name syntax, which removes the `:` from the name.
DataWeave 1 | `payload.foo as :string`  
---|---  
DataWeave 2 | `payload.foo as String`  
## XML Format
The default for the reader property `nullValueOn` is `empty` for DataWeave 2.0.
For DataWeave 1.0 (which is compatible with Mule 3.x), the value is `none`, for example:
DataWeave Script
```
%dw 1.0
%output application/xml nullValueOn="none"
---
payload
```

Input
```
<book>
 <name></name>
</book>
```

## New Capabilities
There are also many new capabilities, including:
  * Typing for reusable functions
  * Multi-line comments
  * Ability to call out to Java code
  * Multipart, URL-encoded, and text readers and writers
  * Modules and imports
  * and more


## See Also
Migrating from DataWeave 1.0 to 2.x
DataWeave Language
Upgrade or Delete Managed Flex Gateway | MuleSoft Documentation
# Upgrade or Delete Managed Flex Gateway
You can upgrade or delete a Managed Flex Gateway using Anypoint Runtime Manager.
Managed Flex Gateways are regularly auto-upgraded, depending on your Gateway release channel (LTS or Edge). See Flex Gateway Version Lifecycle for more information.
You can upgrade a Managed Flex Gateway earlier than the regularly scheduled upgrade or patching process, between the new release date and the auto-upgrade date. You can choose the time that better suits the needs of your organization.
## Early Upgrade Managed Flex Gateway (Optional)
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu.
  3. Select the **Managed Flex Gateway** tab.
  4. Click the name of the gateway to upgrade.
  5. Click **Settings** in the navigation menu.
  6. If a newer version is available, the **Version** field shows an **Update available** tag.
  7. Click the padlock symbol next to the version and **Update available** tag.
  8. Click the **Apply Changes** button. A status message (**Your gateway is being updated**) appears while the upgrade is being applied. A success message (**Your gateway has been successfully updated**) appears when the upgrade is complete.
  9. Click **Dashboard** in the navigation menu to view your gateway status.


## Delete Managed Flex Gateway
You can delete a Managed Flex Gateway using Anypoint Runtime Manager.
### Before You Begin
If there are any APIs associated with the gateway you want to delete, you must either move the APIs to another gateway or delete the APIs. After any associated APIs are moved or deleted, follow these steps to delete a gateway and confirm the deletion.
### Delete Gateway
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu.
  3. Select the **Managed Flex Gateway** tab.
  4. Click the name of the gateway to delete.
  5. Ensure the action menu button says **Delete Gateway**. If it says **Stop Gateway** , click the down arrow part of this button, and select **Delete Gateway** to change the action.
  6. Click the action menu button **Delete Gateway**.
  7. Verify that you delete the correct gateway in the confirmation dialog.
  8. Click **Yes, Delete**. A status message (**Your gateway is being deleted**) appears while the action is applied. A success message (**Your gateway has been successfully deleted**) appears when the action is complete.


If you delete a gateway, you lose its configuration history.   
---
B2C Setup Guide | MuleSoft Documentation
# B2C Setup Guide
The following document provides guidance on how to configure your B2C Commerce instance to provide access to the Data and Shopper APIs used by the B2C Commerce System API implementation template.
## API Client ID Settings
Before doing anything with the Salesforce Commerce API, you need an API Client ID. The API Client ID is a credential that is granted from Account Manager, which consists of both an ID value and a secret. Both the ID and the secret should be protected and treated as a username and password combination to using the Salesforce Commerce API.
In Account Manager, create a new API Client with the following settings:
  * **Roles** : Salesforce Commmerce API role with access to the target instance
  * **OpenID Connect allowed scopes** :
```
sfcc.orders
sfcc.orders.rw
sfcc.products
sfcc.products.rw
sfcc.shopper-baskets-orders
sfcc.shopper-baskets-orders.rw
sfcc.shopper-myaccount
sfcc.shopper-myaccount.rw
sfcc.shopper-myaccount.addresses
sfcc.shopper-myaccount.addresses.rw
sfcc.shopper-customers.register
sfcc.customerlists.rw
```

  * **Token Endpoint Auth Method** : client_secret_post
  * **Access Token Format** : JWT


Refer to the Add an API Client ID documentation in the Commerce Cloud Infocenter for more information.
## Open Commerce API Settings
OCAPI is the other set of APIs used by the implementation template. These settings are configured in Business Manager, on the **Administration - > Site Development -> Open Commerce API Settings** page. There are two groups of APIs that must be configured: Shop APIs and Data APIs. Access to Shop APIs must be configured at the Global (organization-wide) level, while access to Data APIs can be configured globally or at the individual site level.
### Shop APIs
Access to the following resources and methods of the Shop APIs is required:
Resource | Methods  
---|---  
/customers  
/customers/* | GET/PATCH  
/customers/*/addresses | GET/POST  
/customers/**/addresses/** | GET/PATCH/DELETE  
/customers/*/baskets  
/customers/*/orders  
/orders/* | GET/PATCH  
/order_search  
/product_lists  
/product_lists/* | GET/PATCH  
/product_lists/*/items | GET/POST  
/product_lists/**/items/** | PATCH/DELETE  
/product_search  
/product_search/availability  
/product_search/images  
/product_search/prices  
/product_search/variations  
/products/*  
/products/*/images  
/products/*/availability  
/products/*/prices  
/products/*/variations  
### Data APIs
Access to the following resources and methods of the Data APIs is required:
Resource | Method  
---|---  
/products/* | GET/PUT/PATCH  
/products/**/variation_attributes/**  
/products/**/variation_attributes/** /values/*  
/products/**/variations/**  
/product_search  
/inventory_lists/**/product_inventory_records/** | GET/PATCH/PUT  
/catalogs/**/categories/** /products/* | GET/PATCH/PUT  
/sites/**/orders/** * | PUT/PATCH  
## See Also
  *   * MuleSoft Accelerator for Retail
Azure Key Vault Connector 1.2 | MuleSoft Documentation
# Azure Key Vault Connector 1.2
Anypoint Connector for Azure Key Vault (Azure Key Vault Connector) enables you to retrieve secrets, keys, or certificates, and encrypt or decrypt content.
For information about compatibility and fixed issues, refer to the Azure Key Vault Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Azure Key Vault Secrets 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 Azure Key Vault target resource
  * Anypoint Platform
  * Anypoint Studio version 7.3.5 or later


## Common Use Cases for the Connector
Some common use cases for Azure Key Vault Connector include:
  * Authenticating to Azure Key Vault via Client Secret Credential to access Key Vault secrets without exposing sensitive credentials in code, thus improving resilience and security
  * Enabling other applications in a Mule flow to have access to encrypt and decrypt operations using Azure Key Vault keys to avoid key rotations
  * Authenticating to other database and HTTP connectors in a more secure and automated way to fetch and use credentials to access other endpoints
  * Retrieving a certificate and saving the certificate into a file


## Connection Types
Azure Key Vault connections use the Connection authentication type, which uses a client ID, client secret, and cryptography client cache.
## Environment Variables
When setting **Use Azure Default Credential** to `True`, you must set one of the following environment variables `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, or `AZURE_TENANT_ID`. Refer to Setting environment variables documentation for details.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Azure Key Vault Connector Reference
  * MuleSoft Help Center
Viewing Self-Managed Runtime and Access Logs in Anypoint Monitoring | MuleSoft Documentation
# Viewing Self-Managed Runtime and Access Logs in Anypoint Monitoring
Use Anypoint Monitoring to see both runtime and access logs. Use the Anypoint Monitoring filtering to see different detailed logging views.
To access Anypoint Monitoring from the Runtime Manager Flex Gateway UI:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu.
  3. Click the name of the Flex Gateway whose logs you want to view.
  4. Click **Logs**.
  5. Click **View logs in Anypoint Monitoring**.
This action takes you to the Anypoint Monitoring UI.
Get File Info | MuleSoft Documentation
# Get File Info
_Get File Info_ fetches information about a file at the specified path. You can retrieve the following information: date created, date modified, owner, and when the file was last accessed. The information fetched is saved in the appropriate variables for further processing. Dates are returned in UTC (coordinated universal time) format as follows (yyyyMM-ddTHH:mm:ssZ).
## Properties
**File Operation Settings**
  * **Directory path** Enter the path to the directory where the file is saved. You can specify an absolute or relative path. If a relative path is used, then the path relates to the _Base Path_ variable.
  * **File Name** Enter the name of the file here that require information about.


Placeholders are not permitted. For further information please refer to the section on **Invalid characters**.
Other Properties that are the same in all action steps are described in the section on **Common Properties**. For reasons of clarity they are not shown here.
## Inbound Variables
**Directory path** Enter the path to the directory where the file is saved. You can specify an absolute or relative path. If a relative path is used, then the path relates to the _Base Path_ variable.
**File Name** Enter the name of the file here that require information about.
## Outbound Variables
**File Size** The _Get_ _File Info.File Size_ variable provides the size of the file.
**Creation Date** The _Get_ _File Info.Creation Date_ variable provides the date the file was created (format: yyyyMM-ddTHH:mm:ssZ).
**Modification Date** The _Get_ _File Info.Modification Date_ variable provides the date of the last change to the file (format: yyyyMM-ddTHH:mm:ssZ).
**Last Access Date** The _Get_ _File Info.Last Access Date_ variable provides the last access date (format: yyyyMM-ddTHH:mm:ssZ).
**File Owner** The _Get_ _File Info.File Owner_ variable provides the name of the owner of the file.
**File Name** The _Get_ _File Info.File Name_ variable provides the name of the file.
**Directory path** The _Get_ _File Info.Directory Path_ variable provides the path that is used.
## Wizard
  * **Directory path** Specify the path to the file that you require information about. You can create an absolute path or a path relative to the _Base Path_. The initial value is %STWS_BASEPATH%. Select an existing path. You can also insert variables from the _Workflow_ in order to construct the path. To do so, click on the pin and select one of the available variables.


  * **File name** Enter the name here of the file that you require information about. You can also insert a variable from the Workflow as the _File Name_. To do so, click on the pin and select one of the available variables.
Keystrokes to App Element | MuleSoft Documentation
# Keystrokes to App Element
The _Keystrokes to App Element_ emulates keyboard inputs that can be sent to an App Element. In contrast to “Set Text To App Element”, control keys such as “Alt”, “Ctrl”, and “Shift” can also be sent to the element.
All the keyboard inputs are played back in sequence, which means if the sequence contains control keys that change the element in an app (such as “Tab”), the subsequent keystrokes might be sent to the element of the new focus.
## Properties
  * **Keystroke Settings**
    * **Keystrokes**
The keystrokes to send to the element. The input text is interpreted as AutoIT language. The specific AutoIT buttons can be inserted using _Insert Special Character_ and _Insert Macro_. Like in the _Set Text To App Element_ action step, you can use _Insert Script Variable_ and _Insert Environment Variable_ to insert placeholders that are replaced at runtime. The behavior here is identical to that in the _Keystrokes_ action step.


## Inbound Variables
  * **Keystrokes**
  * **XPath to Element**
  * **Window Title**


## Outbound Variables
The _Keystrokes to App Element_ action step does not have any outbound variables.
## Wizard
See Common Properties (App Automation) for a description of the common properties.
See Inserting Text Modules for additional information about environment variables and script variables.
MuleSoft Automation Credits 2.0 | MuleSoft Documentation
# MuleSoft Automation Credits 2.0
Your MuleSoft Automation subscription plan includes a quota of Automation Credits that depletes as you create and execute automations. You can use Automation Credits with MuleSoft Composer, MuleSoft IDP, MuleSoft RPA, Salesforce Flow Orchestration, MuleSoft for Flow: Integration, or a combination of these products.
The following table shows the conversion rate between Automation Credits and different activities:
RPA Bot Minutes | RPA API Calls | Composer Tasks | Flow Orchestration Runs | IDP Document Pages | Integration Tasks  
---|---|---|---|---|---  
1 = 80 Automation Credits | 1 = 2 Automation Credits | 1 = 2 Automation Credits | 1 = 100 Automation Credits | 1 = 25 Automation Credits | 1 = 2 Automation Credits  
For detailed definitions and more information, see MuleSoft Subscription Plan.
Analyzing documents with Einstein consumes Automation Credits and Einstein Requests. For more information about Einstein Requests, usage, and consumption, see Einstein Rate Card.
## Generative AI
The services contain features that use generative AI technology that may be provided by one or more third-parties as listed in the documentation applicable to the services. This documentation provides information and product requirements specific to these generative AI features and providers, including applicable third-party acceptable use policies which the customer must comply with when using the generative AI technology. Due to the nature of generative AI, the output that it generates may be unpredictable, and may include inaccurate or harmful responses. Before using any generative AI output, the customer is solely responsible for reviewing the output for accuracy, safety, and compliance with applicable laws and third-party acceptable use policies. The customer assumes all responsibility for output generated by the services and, as between Salesforce and the customer, such output is customer data.
## See Also
  * Automation Credits Usage and Rates
Read Text from App Element | MuleSoft Documentation
# Read Text from App Element
The _Read Text From App Element_ action step lets you read the text from a selected App Element. The extracted text is then available for further processing as an outbound variable.
## Properties
The _Read Text from App Element_ action step does not have any special properties.
## Inbound Variables
  * **XPath to Element**
  * **Window Title**


## Outbound Variables
  * **Read Text**
Outputs the text that was read by the action step.
  * **Has Content**
Indicates whether the extracted text has content (`true`) or is blank (`false`).


## Wizard
See Common Properties (App Automation).
Deployment Errors | MuleSoft Documentation
# Deployment Errors
Cloud IDE 
Desktop IDE 
**Open Beta Release** : The **cloud IDE is in open beta**. Any use of Anypoint Code Builder in its beta state is subject to the applicable beta services terms and conditions, available from the IDE.
In Anypoint Code Builder, the error `Failed to deploy to CloudHub: 400` occurs when you deploy a Mule application to CloudHub if the root organization or business group to which you are deploying lacks a sufficient vCore allocation.
To address this isssue, increase the vCore allocation to the root organization or business group in the **Sandbox** environment:
  * To reallocate resources, see Redistribute Resources Between Existing Business Groups.
  * To manage environments, see Environments. For additional help, contact your organization administrator for Anypoint Platform.
Mule (dw::Mule) | MuleSoft Documentation
# Mule (dw::Mule)
This DataWeave module contains functions for interacting with Mule runtime.
## Functions
Name | Description  
---|---  
This function matches an error by its type, like an error handler does.  
This function enables you to execute a flow within a Mule app and retrieve the resulting payload.  
This function returns a string that identifies the value of one of these input properties: Mule property placeholders, System properties, or Environment variables.  
## Types
Debugging Outside Studio | MuleSoft Documentation
# Debugging Outside Studio
To troubleshoot a Mule app in Anypoint Studio, you can use the Studio Visual Debugger. This lets you set breakpoints to stop execution and check events.
If you’re creating your Mule app outside of Studio, you can either use MUnit to test your app, or you can activate remote debugging.
## Use MUnit to Test an App
MUnit is a Mule application testing framework that allows you to build automated tests for your integrations and APIs. It provides a full suite of integration and unit test capabilities, and is fully integrated with Maven and Surefire for integration with your continuous deployment environment.
For more information, see the MUnit documentation.
## Activate Remote Debugging
You can start Mule with the **-debug** option to activate remote debugging, as shown in this Linux example:
```
$MULE_HOME/bin/mule -debug
```

With this option, Mule starts normally and logs the following message in the console:
```
Listening for transport dt_socket at address: 5005
```

Mule is now remotely debuggable on port 5005. Follow these steps to debug Mule:
  1. Access Eclipse, and select the **Run > Debug Configurations** menu. From there, create a **Remote Java Application** configuration that uses port 5005.
  2. Add the source code of your Mule local instance as an external archive on the second tab of the configuration panel.
  3. Click the **Debug** button at the lower right corner of the configuration screen. The local Mule instance resumes its start-up sequence and you can debug the app step-by-step.


If you want to use a port other than 5005, change the JPDA_OPTS property file in the Mule startup script before following the steps for debugging Mule.
Profit Analysis: Process Frequency | MuleSoft Documentation
# Profit Analysis: Process Frequency
The widget **Profit Analysis: Process Frequency** shows how often a process has been executed productively within a specific interval compared to its previous frequency of execution.
You can see at a glance whether a process can be executed more frequently by an bot or by a human employee, and to what extent the frequencies differ.
## Data Representation
The execution duration of the individual configurations is shown as a line chart. A colored line corresponds to a configuration.
The time interval is shown on the X axis, the execution duration of the individual runs is shown in seconds on the Y axis.
The manual execution duration in seconds is represented by a horizontal red line.
You can see the exact data if you hover the mouse over any point.
If, in the evaluation of the Process, a value is entered under **Frequency per month** , this is displayed as a red line in the graphic.
If you drag the mouse over a bar, you can see the exact number of Process executions on this day or in this month.
If the display interval is less than one month, the value **Frequency per month** is divided by 30 to enable a comparison of the execution frequency of individual days.
If the display interval is more than one month, the execution frequencies for each month are aggregated to enable a comparison of the monthly values.
## Configuration
You can select an individual process, whose execution frequency is to be displayed, from the drop-down list.
The processes are displayed below their category. Categories and processes are sorted alphabetically.
You can only select from those processes for which you are a member of the process team. Other processes are not displayed.
## Drill-down
This widget does not contain any drill-down data.
B2C Shop Connector 2.0 | MuleSoft Documentation
# B2C Shop Connector 2.0
Anypoint Connector for Salesforce Commerce Cloud B2C Shop APIs (B2C Shop Connector) enables a client to interact with the Commerce Cloud B2C API system as either a shop customer or as an agent shopping on behalf of a customer.
For information about compatibility and fixed issues, see Commerce Cloud B2C Shop Connector Release Notes.
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 Salesforce Commerce Cloud Shop API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have access to:
  * The Commerce Cloud B2C Shop Connector target resource
  * Anypoint Platform
  * Anypoint Studio version 7.1 or later
  * Salesforce-provided Commerce Cloud credentials (such as Client Id, Client Secret, and Scopes) necessary to access Shop API.


## Common Uses for the Connector
These are some common use cases for B2C Shop Connector:
  * Create a basket
  * Add items to a basket
  * Add shipping details
  * Place an order


Check the Examples for a simple use case.
## Audience
  * New user
To create your Mule app, see:
  * Using Anypoint Studio to Configure Commerce Cloud B2C Connector
  * Advanced user
  * Read the following:
  * XML and Maven Support


## Connection Types
B2C Shop Connector connections use the following authentication types:
  * Customers Auth Uses a Bearer Token, which is generated using the **Authorize Customer** operation
  * OAuth 2.0 Delegates user authentication to the service hosting the user account


For information about configuring authentication types, see Using Anypoint Studio to Configure Commerce Cloud B2C Shop Connector.
## Next Step
After you complete the prerequisites and try the 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
  * MuleSoft Help Center
MCP Schema Validation Policy | MuleSoft Documentation
# MCP Schema Validation Policy
**Policy Name** | MCP Schema Validation  
---|---  
Validates MCP requests to ensure they conform to the MCP specification  
**First Flex Gateway version available**  
**Returned Status Codes**  
This policy supports Model Context Protocol (MCP) version 2025-06-18 and earlier. To learn more about MCP, see MCP Specification.   
---  
## Summary
The MCP Schema Validation policy validates that every every JSON RPC request to the MCP server complies with the MCP schema (MCP 2024_11_05 standard). If validation fails it will report a Policy Violation.
There are no configuration parameters for this policy.
### Flex Gateway Local Mode
The MCP Schema Validation policy isn’t supported in Local Mode.
Simulating API Calls Using the Mocking Service | MuleSoft Documentation
# Simulating API Calls Using the Mocking Service
To simulate calls to your API, use the mocking service in the API Console of the portal, you can simulate calls to your API. The mocking service is a feature of Anypoint that enables you to generate simulated servers to help you develop and test APIs. These mock servers imitate the actions of accepting requests and providing responses. The mocking service replicates the functionality of a genuine API.
## Before You Begin
You must have an API specification with at least one endpoint and one method in it.
## Simulate a Call to an API Using an Internal URL
To access the internal URL, you must specify the authorization headers as part of the request URL. To test an API without supplying authorization headers, generate a mocking service public URL for this project. The mocking service is the selected server in the **Try it** pane.
  1. On the **Home** or the **APIs** page, select a REST API.
  2. Select the **API specification** tab.
  3. Click a method like `GET`.
  4. In the **Documentation** pane, review the requests and responses data.
  5. In the **Try it** pane, enter query parameters you want to test.
You can enter query parameters as name-value pairs.
  6. Click **Send**.
API Console displays the HTTP return code as specified in your API. Alternately, you can test the API by copying the Request URL and paste it into a web browser or Postman.


## See Also
  * Using the API Console
Enabling the Request Access Button | MuleSoft Documentation
# Enabling the Request Access Button
Users specify what applications can have access to an API by clicking the **Request access** button.
Exchange Administrators see **Request access** in the **More options** menu .
Enabling the **Request access** button requires the Exchange Administrator permission.
To show the **Request access** button, create an API asset and then configure it:
  1. In API Manager, click **Manage API** > **Manage API from Exchange** to open the API.
  2. Use the URL of your API asset in Exchange as the Implementation URI in API Manager.
  3. After opening your API in API Manager, you can view the API Instance ID value as well as other useful information.
  4. In Exchange, the **Request access** button appears in the three dots menu.


In API Manager, the API’s Status is marked as unregistered. To register the API, deploy the API to Anypoint Runtime Manager. Changing the API Status to registered is not required to make the API usable in Exchange.
## Request Access Display Criteria
To display the **Request access** button on an Exchange public portal:
  1. Publish a REST, SOAP, or HTTP API in Exchange.
A REST API can be either an OAS or RAML API specification.
  2. Create an instance of the API in API Manager.
  3. Set the instance as public in **API instances**.
  4. If the instance’s URL is not present, set the instance’s URL in **API instances**.


If the instance is private, then the portal displays the **Request access** button only to logged-in users.
If the instance is public, then the portal displays the **Request access** button to all users. If a logged-out user requests access, then Exchange prompts them to log in.
System | MuleSoft Documentation
# System
System action steps enable you to perform some system interactions as mapping network drives, displaying a message box, compare system parameters, and write logs.
  * This action step lets you map and unmap any network location and any drive letter.
  * This action step is used to display a message box containing user-defined text and the buttons needed.
  * System Validation compares various parameters between the system the Workflow was created on and the system where it is executed. It does not have any additional properties on the Properties grid.
  * The Write Bot Message action step enables you to enrich the result message the RPA Bot generates after each failed run. In case of execution failure, this message shows in the **Run Results** section of the **Process Management** view in RPA Manager.
  * This action step can be used to leave a comment or brief description at a certain point in the Workflow.
entrySet | MuleSoft Documentation
# entrySet
## entrySet<T <: Object>(obj: T): Array<{| key: Key, value: Any, attributes: Object |}>
Returns an array of key-value pairs that describe the key, value, and any attributes in the input object.
_This function is**Deprecated**. Use dw::Core::entriesOf, instead._
### Parameters
Name | Description  
---|---  
The `Object` to describe.  
### Example
This example returns the key, value, and attributes in the object specified in the variable `myVar`.
#### Source
```
%dw 2.0
import * from dw::core::Objects
var myVar = read('<xml attr="x"><a>true</a><b>1</b></xml>', 'application/xml')
output application/json
---
{ "entrySet" : entrySet(myVar) }
```

#### Output
```
{
 "entrySet": [
  {
    "key": "xml",
    "value": {
     "a": "true",
     "b": "1"
    },
    "attributes": {
     "attr": "x"
    }
  }
 ]
}
```
Database Connector 1.8 | MuleSoft Documentation
# Database Connector 1.8
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. 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
Configuring Runtime Fabric | MuleSoft Documentation
# Configuring Runtime Fabric
To configure Anypoint Runtime Fabric, review the following topics:
  * Associating Business Groups and Environments Associate a Runtime Fabric with one or more Anypoint Platform environments before deploying a Mule app or API proxy.
  * Configuring Runtime Fabric Using RTFCTL Use `rtfctl apply`, `update`, and `wait` commands to configure Runtime Fabric.
  * Configuring Ingress Customize ingress configurations using an ingress resource template.
  * Configuring Red Hat OpenShift Routes Configure Red Hat OpenShift Routes to create ingress endpoints for your Mule apps.
  * Configuring Persistence Gateway Use Persistence Gateway, which enables Mule apps deployed to a Mule runtime instance to store and share data across application replicas and restarts.
  * Configuring Proxies Configure proxies when running and hosting Mule apps deployed to Runtime Fabric.
  * Configuring Horizontal Pod Autoscaling (HPA) Configure horizontal autoscaling of Mule app deployments by spinning up additional replicas or spinning down unneeded replicas in response to the CPU usage as a signal.
Exchange Public Portals | MuleSoft Documentation
# Exchange Public Portals
Exchange public portals are accessible to anyone using the internet, enabling developers outside of an organization to access that organization’s REST, SOAP, and HTTP APIs. Users who are not logged in can download assets from public portals.
Exchange public portals replace what used to be known as _developer portals_.
You can customize the appearance and the content of the portal by adding a logo, banner image, text, or a favicon for the browser tab.
## Share an Asset or Update the Asset Description
As an Exchange administrator, you can edit the description of an asset in your organization so that users outside the organization can identify it, and then share the asset by publishing to a public portal:
  1. Locate the asset in your organization’s Exchange instance.
  2. Edit the asset description and then publish the asset.
  3. Verify the change by returning to the public portal and clicking the asset.


## How Users from Other Organizations Access Your Portal
Anyone can view a public portal without logging in.
Anypoint users can click the **Login** button on any page to use features such as reviewing assets, downloading assets, creating a client application to request API access, and accessing an API.
Anypoint users who belong to other Anypoint organizations and not your organization are _external users_ of your organization’s portal.
An organization administrator can see only the basic profile of an external user.
A basic profile has only these fields:
  * **Username**
  * **Primary Organization**


The first time an external user attempts to log in to your public portal, the portal requests permission for read-only access to this basic profile. When the user approves this request, they are logged in to your public portal and their information is added to the **External Users** tab. To view this tab in Anypoint Platform click **Access Management** > **Users** > **External Users**.
As your organization’s administrator, you can enable or disable each external user on that tab. Users are enabled by default. If you disable them, they cannot log in to your public portal.
Users in your organization can access features that external users cannot, such as deploying an application. You can invite an external user to join your organization so they can use these features.
## See Also
  * Customize an Exchange Public Portal
  * Public Portal Vanity Domain
File Connector | MuleSoft Documentation
# File Connector
File Connector v1.3
Anypoint Connector for File (File Connector) handles files and folders on a locally mounted file system. Its main features include:
  * The ability to read files or fully list directory contents on demand.
  * Support for common FTP operations such as creating directories and copying, moving, renaming, and deleting files.
  * Support for locking files.
  * File matching functionality.
  * A design that is fully consistent with the File and SFTP connectors. The same set of operations is available on each connector.


For information on error conditions, see the File Connector Reference.
Release Notes: File Connector Release Notes Exchange: File Connector
## Configure the File Connector
The File connector does not always require configuration. However, it is good practice to define one. The most important configuration parameter is the Working Directory (`workingDir`), which is the path to a directory that is treated as the root of every relative path that you specify with this connector. If you do not provide a working directory, the connector configuration defaults to the value of the `user.home` system property. If the system property is not set, the connector fails to initialize.
You can also set the default encoding to use when writing files. It defaults to Mule runtime’s default encoding. If you use any File connector operations without referencing a configuration, the operation uses the default values.
This example sets a working directory for the File connector:
```
<file:config name="File_Config">
 <file:connection workingDir="/Users/me/myfiles" />
</file:config>
```

## Attributes
When reading or listing files, the connector provides file metadata, such as the file name, full path, size, timestamp, and so on. The connector uses the Mule Message Attributes to access this information.
## POM File Information
```
<dependency>
 <groupId>org.mule.connectors</groupId>
 <artifactId>mule-file-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 specify a version, view File Connector in Anypoint Exchange and click **Dependency Snippets**.
## See Also
  * File Connector Documentation Reference
  *   *   *   * Listen for New or Modified Files
  * Copy or Move Files
  * MuleSoft Help Center
causedBy | MuleSoft Documentation
# causedBy
## causedBy(@DesignOnlyType error: Error, errorType: String): Boolean
This function matches an error by its type, like an error handler does.
`causedBy` is useful when you need to match by a super type, but the specific sub-type logic is also needed. It can also useful when handling a COMPOSITE_ROUTING error that contains child errors of different types.
### Parameters
Name | Description  
---|---  
Optional. An `Error` type.  
`errorType` | A string that identifies the error, such as HTTP:UNAUTHORIZED.  
### Example
This XML example calls `causedBy` from a `when` expression in a Mule error handling component to handle a SECURITY error differently depending on whether it was caused by an HTTP:UNAUTHORIZED or HTTP:FORBIDDEN error. Notice that the first expression passes in the `error` (an `Error` type) explicitly, while the second one passes it implicitly, without specifying the value of the parameter. Note that `error` is the variable that DataWeave uses for errors associated with a Mule message object (see DataWeave Variables for Mule Runtime).
#### Source
```
<error-handler name="securityHandler">
 <on-error-continue type="SECURITY">
  <!-- general error handling for all SECURITY errors -->
  <choice>
   <when expression="#[Mule::causedBy(error, 'HTTP:UNAUTHORIZED')]">
    <!-- specific error handling only for HTTP:UNAUTHORIZED errors -->
   </when>
   <when expression="#[Mule::causedBy('HTTP:FORBIDDEN')]">
    <!-- specific error handling only for HTTP:FORBIDDEN errors -->
   </when>
  </choice>
 </on-error-continue>
</error-handler>
```
pluck | MuleSoft Documentation
# pluck
## pluck<K, V, R>(@StreamCapable object: { (K)?: V }, mapper: (value: V, key: K, index: Number) -> R): Array<R>
Useful for mapping an object into an array, `pluck` iterates over an object and returns an array of keys, values, or indices from the object.
It is an alternative to `mapObject`, which is similar but returns an object, instead of an array.
### Parameters
Name | Description  
---|---  
The object to map.  
Expression or selector that provides the `key`, `value`, and/or `index` (optional) used for mapping the specified object into an array.  
### Example
This example iterates over `{ "a":"b","c":"d"}` using the anonymous mapper function (`(value,key,index) → { (index) : { (value):key} }`) to invert each key-value pair in the specified object and to return their indices as keys. The mapper uses named parameters to identify the keys, values, and indices of the object. Note that you can write the same expression using anonymous parameters, like this: `{"a":"b","c":"d"} pluck { ($$$) : { ($):$$} }` Unlike the almost identical example that uses `mapObject`, `pluck` returns the output as an array.
#### Source
```
%dw 2.0
output application/json
---
{"a":"b","c":"d"} pluck (value,key,index) -> { (index) : { (value):key} }
```

#### Output
```
[ { "0": { "b": "a" } }, { "1": { "d": "c" } } ]
```

### Example
This example uses `pluck` to iterate over each element within `<prices/>` and returns arrays of their keys, values, and indices. It uses anonymous parameters to capture them. Note that it uses `as Number` to convert the values to numbers. Otherwise, they would return as strings.
#### Source
```
%dw 2.0
output application/json
var readXml = read("<prices>
  <basic>9.99</basic>
  <premium>53.00</premium>
  <vip>398.99</vip>
  </prices>", "application/xml")
---
"result" : {
 "keys" : readXml.prices pluck($$),
 "values" : readXml.prices pluck($) as Number,
 "indices" : readXml.prices pluck($$$)
}
```

#### Output
```
{
  "result": {
   "keys": [ "basic", "premium", "vip" ],
   "values": [ 9.99, 53, 398.99 ],
   "indices": [ 0, 1, 2 ]
  }
}
```

## pluck(value: Null, mapper: (value: Nothing, key: Nothing, index: Nothing) -> Any): Null
Helper function that enables `pluck` to work with a `null` value.
functionReturnType | MuleSoft Documentation
# functionReturnType
## functionReturnType(t: Type): Type | Null
Returns the type of a function’s return type. This function fails if the input type is not a Function type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The function type.  
### Example
This example shows how `functionReturnType` behaves with different inputs.
#### Source
```
%dw 2.0
output application/json
import * from dw::core::Types
type AFunction = (String, Number) -> Number
type AFunction2 = () -> Number
---
{
  a: functionReturnType(AFunction),
  b: functionReturnType(AFunction2)
}
```

#### Output
```
{
 "a": "Number",
 "b": "Number"
}
```
Azure Service Bus Connector 3.4 | MuleSoft Documentation
# Azure Service Bus Connector 3.4
Anypoint Connector for Azure Service Bus (Azure Service Bus Connector) makes it easy to build integrations that send messages to and receive messages from Azure Service Bus, which is an asynchronous messaging cloud platform. This connector supports communication with queues and topics and can perform actions such as:
  * Send to queue
  * Send to topic
  * Receive from queue
  * Receive from subscription


To use the Azure management API for CRUD operations of queues, topics, subscriptions, and rules, use Anypoint Connector for Azure Service Bus Management (Azure Service Bus Management Connector).
This connector supports integrations with Azure Service Bus (cloud). It does not work with Microsoft Service Bus (on-premises). To connect with Microsoft Service Bus on-premises, use Anypoint Connector for Microsoft Service Bus. This connector does not work with Event Hubs.  
---  
For compatibility information and fixed issues, see the release notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Azure Service Bus APIs
  * Anypoint connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have:
  * Access to the Azure target resource
  * OpenJDK 8
  * Anypoint Studio 7.1.0 or later
  * Mule Runtime 4.2.x EE or later


## Audience
  * New user
To create your Mule app, see:
  *   * Examples, which provides one or more use cases for the connector.
  * Advanced user
  * Read the following:
  * XML and Maven Support
  * Examples topics


## Authentication Types
Azure Service Bus Connector supports the following connection types to connect to Azure:
  * Shared Access Signature (SAS)
  * Azure Active Directory (AAD)


For information about configuring these authentication types, see Using Anypoint Studio to Configure Azure Service Bus 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
  * Azure Service Bus Connector Release Notes
  * Azure Service Bus Management Connector
  * Azure Service Bus Connector on Exchange
  * MuleSoft Help Center