BassemE/mulesoft-documentation-embeddings huggingface dataset:
Resource-Level Policies | MuleSoft Documentation
# Resource-Level Policies
Unless otherwise configured, policies are by default applied to the entire API. However, you can implement an additional level of policy granularity, one in which access is controlled based on a criteria. Policies with this granularity are called _resource-level policies_.
At the resource level of granularity, policies are applied to only those requests that match the criteria. All policies, except the Cross-Origin Resource Sharing (CORS) policy, are resource-level.
For Flex Gateway running in Connected Mode, you configure resource-level policies in API Manager.
For information about configuring resource-level policies for Flex Gateway running in Local Mode, refer to Secure an API with an Automated Resource-Level Policy.
Using Topic Subscriptions | MuleSoft Documentation
# Using Topic Subscriptions
Topics in IBM MQ allow you to configure how the subscription behaves regarding the connection of the consumer and also how these consumers interact with each other.
Using IBM MQ Connector, you can handle of the aspects of a Topic subscription using the `topic-consumer` configuration in both the `consumer` and `listener` operations.
## Registering Durable Subscriptions
Durable subscriptions allows to receive messages that were published to the topic while the consumer was offline. Once a durable subscription registered, each time a consumer is available it will receive all the messages published before the connection was established:
```
<ibm-mq:consume config-ref="JMS_config" destination="#[vars.destination]">
  <ibm-mq:consumer-type>
    <ibm-mq:topic-consumer durable="true" subscriptionName="SampleSub"/>
  </ibm-mq:consumer-type>
</ibm-mq:consume>
```

Then IBM MQ stores the messages published to the topic, as it would store messages sent to a queue. If this or another application creates a `topic-consumer` using the same connection and its client ID, the same topic, and the same subscription name, the subscription is reactivated, and IBM MQ delivers the messages that were published while the subscriber was inactive.
## Allowing Multiple Consumers on the Same Subscription
In JMS 1.1, a subscription on a topic was not permitted to have more than one consumer at a time, meaning that the work of processing messages on a topic subscription could not be shared, thereby limiting the scalability of the application. This restriction has been removed in JMS 2.0 by the introduction of **shared subscriptions**.
The IBM MQ Connector, **when configured with a JMS 2.0 connection** , allows you to declare any `topic-consumer` as part of a `shared` subscription:
```
<ibm-mq:listener config-ref="config" destination="InvoiceEventsTopic">
  <ibm-mq:consumer-type>
    <ibm-mq:topic-consumer shared="true" subscriptionName="ClusterSubscription"/>
  </ibm-mq:consumer-type>
</ibm-mq:listener>
```

With this configuration on two different `listener` instances, when a Message is published to the invoices destination, it will be delivered only to one of the listeners and not the other.
## How to Ignore Self Published Messages
There are cases in which you may not want to receive the Messages that were published to a Topic by the same application. For this cases, you can use the `noLocal` parameter in the `topic-consumer`, thus preventing the Consumer to receive Messages published to the Topic **by the same Connection** :
```
<ibm-mq:listener config-ref="config" destination="${notificationsChannel}">
  <ibm-mq:consumer-type>
    <ibm-mq:topic-consumer noLocal="true"/>
  </ibm-mq:consumer-type>
</ibm-mq:listener>
```

Consumers configured as `noLocal` **can’t** be part of a `shared` subscription.
## See Also
  * To Listen For New Messages
  * To Consume Messages
Introduction to Mule 4: DataWeave Expression Language | MuleSoft Documentation
# Introduction to Mule 4: DataWeave Expression Language
In Mule 3, you must learn both the Mule Expression Language (MEL) and DataWeave. MEL forces you to convert your payloads from binary data (such as XML or JSON documents) into Java objects so that you can write expressions that access that data, for example, when routing to a specific location.
In Mule 4, DataWeave is the default expression language. Combined with the built-in streaming capabilities, this change simplifies many common tasks:
  * Events can be routed based on payload data, without requiring conversion to Java objects.
  * Binary data can easily be queried from an expression anywhere in your flow, for example, when logging.
  * Streaming now happens transparently. You no longer need to worry about larger-than-memory data streams or about consuming a stream twice.


DataWeave 2.0 also features many improvements, which are covered in the DataWeave 2.0 section.
At the core, expressions continue to work as before. You can use them to extract data, log data, or make decisions about where to route data. And like MEL, the syntax to access properties in your data is very simple.
```
<logger message="#[payload]"/>
<set-variable variableName="httpResponseStatus" value="#[attributes.statusCode]"/>
```

Unlike MEL, you can use DataWeave to easily access data anywhere in your flow without concern for transforming it into intermediate objects. Consider this example in Mule 3:
```
<http:listener path="/hello"/> <!-- receives a JSON HTTP Body -->
<json:json-to-object/> <!-- convert to Java objects -->
<choice> <!-- route data based on the data -->
 <when expression="#[payload.customer == 'Acme, Inc']">
  <!-- do some logic -->
 </when>
</choice>
```

In Mule 4, you no longer need to convert JSON to an intermediate format. You can simply access the data directly through expressions without losing the original underlying data, and Mule 4 handles all data streaming and random access transparently for you.
```
<http:listener path="/hello"/> <!-- receives a JSON HTTP Body -->
<choice> <!-- route data based on the data -->
 <when expression="#[payload.customer == 'Acme, Inc']">
  <!-- do some logic -->
 </when>
</choice>
```

## See Also
Transformations and Streaming
Migrating from DataWeave 1.0 to 2.x
DataWeave Language
Using Custom Message Attributes with Message Types | MuleSoft Documentation
# Using Custom Message Attributes with Message Types
You can associate up to five custom message attributes with a Receive from Partners or Source at Host message type. Using these attributes enables you to have visibility into the full lifecycle of your B2B workflow.
For example, you can define attributes for a message’s PO number, Sales order number, Invoice number, and Shipment ID. When you associate these attributes with a message type in a message flow, Partner Manager extracts this data from the inbound or outbound payload and displays it in the message view of the **Activity** window. From there, you can search for an attribute value, such as a specific PO Number, so you can view every message that has the specified attribute value.
## Create a Custom Message Attribute
Use the **< host>** page to create new custom message attributes:
  1. In the sidebar, select **< host>**.
  2. From the **Custom message attributes** section, click **New**.
  3. Enter the attribute alias and label.
The alias is used in the reference map that is associated with the message type. The label is used in the message view of the transactions. Both the alias and the label must be unique across the host.
  4. To make the attribute searchable on the **Activity** window, select the **Is searchable** checkbox.
  5. Repeat these steps for each new attribute you want to define.
  6. Click **Save**.


## Associate a Custom Message Attribute with a Message Type
To associate a custom message attribute with a message type, include definitions for those attributes in the message type’s reference map. For more information, see Creating Reference Maps for Message Types.
## Dissociate a Custom Message Attribute from a Message Type
To dissociate a custom message attribute from a message type, remove it from the message type’s reference map.
## Delete a Custom Message Attribute
You can delete custom attributes that are not used in reference maps:
  1. In the sidebar, select the **< host-name>**.
  2. In the **Custom message attributes** section, locate the attribute you want to delete.
  3. In the row containing the attribute you want to delete, hover over the attribute label, select the trash can that appears, and click **Delete**.


## See Also
  * Creating Message Types
  * Modifying Message Type Settings
Managing Permissions for Anypoint Monitoring | MuleSoft Documentation
# Managing Permissions for Anypoint Monitoring
Anypoint Monitoring has product-specific permissions that control access to its assets:
Required Permissions | Grants the Ability to | Notes  
---|---|---  
Monitoring Administrator |  View, create, modify, and delete content in Anypoint Monitoring.  
Monitoring Viewer |  View but not modify content in Anypoint Monitoring.  
Telemetry Exporter Administrator | 
  * View connections and configurations in Telemetry Exporter.
  * Create, modify, and delete connections in Telemetry Exporter.
  * Create, modify, and delete configurations in Telemetry Exporter.

|  Assign this permission at the root organization level.  
Telemetry Exporter Configurations Manager | 
  * View connections and configurations in Telemetry Exporter.
  * Create, modify, and delete configurations in Telemetry Exporter.

  
In addition to Monitoring Administrator and Anypoint Monitoring Viewer permissions, asset-specific permissions are required to view and read API and app data for some deployments. For example, if you have the Anypoint Monitoring Viewer permission and want to view Anypoint Monitoring data on a hybrid Mule app deployment, you must also have the Read Applications permission (from Runtime Manager) in the same environment that the app is deployed to.
Deployment Type | Permission | Grants the Ability to | Permission Type  
---|---|---|---  
Hybrid Deployment Data |  Read Applications |  View app data for hybrid deployments. See also, Setting Up Monitoring for Hybrid Deployments. |   
Flex Gateway Deployment Data |  View API Alerts |  View the API alerts for Flex API data.  
Read Servers |  View server and Flex Gateway resources. |   
## See Also
  * Access Management Teams
  * Access Management Roles
  * Access Management Managing Permissions
  * Access Management External Organization Access
  * Permissions in API Manager
  * Permissions in CloudHub 2.0
Mime (dw::module::Mime) | MuleSoft Documentation
# Mime (dw::module::Mime)
This module contains helper functions for working with MIME type.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::module::Mime` to the header of your DataWeave script.
_Introduced in DataWeave version 2.7.0._
## Functions
Name | Description  
---|---  
Transforms a MIME type string value representation to a `MimeType`.  
Returns `true` if the given `MimeType` value is handled by the base `MimeType` value.  
Transforms a `MimeType` value to a string representation.  
## Types
Email Connector 1.4 | MuleSoft Documentation
# Email Connector 1.4
Anypoint Connector for Email (Email Connector) sends and retrieves email messages over standard email protocols. Email Connector configurations share a basic set of parameters that require a connection over the protocols you use.
For compatibility information and fixed issues, see the Email Connector Release Notes.
## 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 Anypoint Platform and Anypoint Studio.
## Common Use Cases for the Connector
Email Connector enables you to:
  * Retrieve emails from POP3 mailboxes
  * Retrieve, delete, and store emails from IMAP mailboxes
  * Send emails over the SMTP protocol
  * Support secure connections for all protocols over Transport Layer Security (TLS)


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 provides one or more use cases for the connector
    * Troubleshooting Guide


## 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
Previewing and Publishing Your Portal | MuleSoft Documentation
# Previewing and Publishing Your Portal
After managing and curating your portal, you can preview your changes in the Builder, then publish it for your users. The URL for the portal isn’t accessible until the portal is published. When you publish your site for the first time, the portal URL is live and login access is enabled.
To preview and publish the portal, follow these steps:
  1. From the **Manage your API portal** page, click **Preview and publish your portal**.
  2. Review your changes and click **Publish**.
You receive an email confirmation when your changes are live. The email contains the URL link to the published site.


## View URL for a Live Published Portal
To view the URL for the live published portal, in the Builder, go to **Settings** > **General**. The **Published Status** section displays the URL for the live published portal.
## See Also
  * Customizing Your Portal
  * Discovering and Consuming APIs
Work with Functions and Lambdas in DataWeave | MuleSoft Documentation
# Work with Functions and Lambdas in DataWeave
In DataWeave, functions and lambdas (anonymous functions) can be passed as values or be assigned to variables.
When using lambdas within the body of a DataWeave file in conjunction with an function such as `map`, its attributes can either be explicitly named or left anonymous, in which case they can be referenced as `$`, `$$`, etc.
## Declare and Invoke a Function
You can declare a function in the header or body of a DataWeave script by using the `fun` keyword. Then you can invoke the function at any point in the body of the script.
You refer to functions using this form: `functionName()` or `functionName(arg1, arg2, argN)`
You can pass an expression in between the parentheses for each argument. Each expression between the parentheses is evaluated, and the result is passed as an argument used in the execution of the function body.
Input
```
{
 "field1": "Annie",
 "field2": "Point",
 "field3": "Stuff"
}
```

Transform
```
%dw 2.0
output application/json
fun toUser(obj) = {
 firstName: obj.field1,
 lastName: obj.field2
}
---
{
 "user" : toUser(payload)
}
```

Output
```
{
 "user": {
  "firstName": "Annie",
  "lastName": "Point"
 }
}
```

## Specify Type Parameters
Starting in DataWeave syntax version 2.5, you can specify the type parameters of a function at the call site.
Input
```
{
 "measures": [1,2,4,1,5,2,3,3]
}
```

Transform
```
%dw 2.5
output application/json
fun max<T>(elems: Array<T>): T = elems reduce ((candidate: T, currentMax = elems[0]) -> if (candidate > currentMax) candidate else currentMax)
---
{
 max: max<Number>(measures)
}
```

Output
```
{
 "max": 5
}
```

## Assign a Lambda to a Var
You can define a function as a variable with a constant directive through `var`
Input
```
{
 "field1": "Annie",
 "field2": "Point",
 "field3": "Stuff"
}
```

Transform
```
%dw 2.0
output application/json
var toUser = (user) -> {
 firstName: user.field1,
 lastName: user.field2
}
---
{
 "user" : toUser(payload)
}
```

Output
```
{
 "user": {
  "firstName": "Annie",
  "lastName": "Point"
 }
}
```

## Use Named Parameters in a Lambda
This example uses a lambda with an attribute that is explicitly named as `name`.
Input
```
%dw 2.0
output application/json
var names = ["john", "peter", "matt"]
---
users: names map((name) -> upper(name))
```

Transform
```
{
 "users": ["JOHN","PETER","MATT"]
}
```

## Use Anonymous Parameters in a Lambda
This example uses a lambda with an attribute that’s not explicitly named, and so is referred to by default as `$`.
Transform
```
%dw 2.0
output application/json
var names = ["john", "peter", "matt"]
---
users: names map upper($)
```

Output
```
{
 "users": ["JOHN","PETER","MATT"]
}
```

## See Also
Supported Data Formats
Stopwatch | MuleSoft Documentation
# Stopwatch
The _Stopwatch_ is basically a combined _Start/Stop Timer_ with a clear graphical representation. It also enables you to use additional timer modes in combination with the _Loop_ item.
## Properties
**Timer mode** Decide how the measured time will be computed when the _Stopwatch_ is within a _Loop_. See below for details.
## Inbound Variables
**Suffix** can be used if the _Stopwatch_ is within the _Control Block_ 's _File Controlled Loop_. A suffix is then added to the name of the _Stopwatch_ during every loop. Each suffix is a column entry in the file that was imported in the _File Controlled Loop_.
## Outbound Variables
The action step _Stopwatch_ has no outbound variables.
## Wizard
The _Stopwatch_ wizard is similar to the _Transaction_ wizard. It suggests the name of the surrounding _Transaction_ to be _Stopwatch_ by default. Just edit the name to change it if required.
## Timer Modes (Using the Stopwatch within a Loop)
Use the _Timer mode_ setting for the _Stopwatch_ to determine how the measurement value is calculated:
  * **Last** The last measured time is saved
  * **Average** The Workflow calculates an average value of all measured times and saves it
  * **Min** The fastest measured time is saved
  * **Max** The slowest measured time is saved


## See Also
  *
Web Service Consumer Connector 1.8 | MuleSoft Documentation
# Web Service Consumer Connector 1.8
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.
## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Web Service Consumer in Exchange
  * MuleSoft Help Center
XML Module | MuleSoft Documentation
# XML Module
XML Module v1.2
The XML Module can process and extract data from an XML document. Although DataWeave is recommended for most XML-related use cases, the XML module should be used for cases that involve the use of XML standards such as XSLT, XPath and XQuery, or XSD.
To use the XML module, you can add it to your Mule app through the Studio UI, or you can add the following dependency in your `pom.xml` file:
```
<dependency>
  <groupId>org.mule.modules</groupId>
  <artifactId>mule-xml-module</artifactId>
  <version>x.x.x</version> <!-- or newer -->
  <classifier>mule-plugin</classifier>
</dependency>
```

Mule runtime engine (Mule) converts RELEASE to the latest version.
Release Notes: XML Module Release Notes Exchange: XML Module
## Validate Against a Schema
When using the XML Module to validate against a schema that has references to other local schema files, validation can fail because the access was restricted by the `expandEntities` as it was using the default value of NEVER. The error message is: The supplied schemas were not valid. schema_reference: Failed to read schema document `NMVS_Composite_Types.xsd`, because `file` access is not allowed due to restriction set by the accessExternalSchema property.
You can eliminate this issue by adding `expandEntities="INTERNAL"` to the `xml-module:config` element.
## See Also
  * Using XPath with the XML Module
  * XSLT Transformations with the XML Module
  * Validating Documents against an XSD Schema with the XML Module
  * Using XQuery with the XML Module
  * XML Module Documentation Reference
  * MuleSoft Help Center
What’s New in Mule 4.4 | MuleSoft Documentation
# What’s New in Mule 4.4
Mule runtime engine 4.4 provides important enhancements and fixes. Deploy all your new and existing applications to Mule 4.4 to benefit from all the improvements in this version.
## Correlation ID Management
Mule 4.4 enables you to modify the correlation ID associated with a Mule event. You can also change the algorithm Mule uses to generate each correlation ID.
See Correlation ID for additional information and configuration instructions.
## Improved Logging Capabilities
Mule 4.4 incorporates Mapped Diagnostic Context (MDC), which enriches logging and improves tracking by providing more context or information in the logs for Mule events.
By using the Mule Tracing module, you can add, remove, and clear variables from the logging context for a given Mule event.
See MDC Logging for additional information and configuration instructions.
## DataWeave Updates
The Mule 4.4 release includes DataWeave 2.4.0 features.
See What’s New in DataWeave for additional information.
## Core Components
Mule 4.4 introduces the Mule Tracing Module (available in Studio 7.11), which enables correlation ID management capabilities as well as improved logging options.
See Tracing Module for the complete documentation of this module.
## Feature Flags
Mule 4.4 incorporates a feature flagging mechanism, which enables you to control the enablement of certain Mule features that affect backward compatibility.
See Feature Flagging for additional information and configuration instructions.
## See Also
  * Mule Runtime 4.4.0 Release Notes
Try Scope XML Reference | MuleSoft Documentation
# Try Scope XML Reference
A Try scope follows the structure described below.
  * A single root element `<try>`
  * Components that are executed under the error-handling rules defined by the Try scope are defined as child elements of the `try` element. You can place one or many here.
  * A single `<error-handler>` element holds all error handling strategies for the scope.
  * In the error handler, one or several `on-error-continue` and `on-error-propagate` define the various strategies. At least one of these must be present.
  * Components that are executed when a matching error occurs are defined as child elements of the `on-error` element. You can place one or many here.


```
<try>
 <!-- COMPONENTS TO TRY TO USE -->
 <error-handler>
  <on-error-continue>
   <!-- COMPONENTS TO USE IN CASE OF ERROR -->
  </on-error-continue>
  <on-error-propagate>
   <!-- COMPONENTS TO USE IN CASE OF ERROR -->
  </on-error-propagate>
 </error-handler>
</try>
```

Each error handling strategy in a Try scope (`on-error-*`) follows a condition. This condition is typically an error type (or a list of several) which must match the current error. You can also define this condition as a freely written expression, such as `error.cause.message.contains("fatal")`.
Note that conditions are evaluated in order and only the first strategy to match is executed.   
---  
Below is an example that includes two error handling strategies, each executing a logger component:
```
<try>
 <http:request config-ref="HTTP-config" method="GET" path="/" />
 <error-handler>
  <on-error-continue enableNotifications="true" logException="true" type="CONNECTIVITY">
   <logger level="INFO" doc:name="Logger" message="Connectivity Error"/>
  </on-error-continue>
  <on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" type="EXPRESSION">
   <logger level="INFO" doc:name="Logger" message="Expression error" />
  </on-error-propagate>
 </error-handler>
</try>
```

## Properties of Try
Property | Default | Description  
---|---|---  
`transactionalAction` | INDIFFERENT |  Defines if what’s in the scope is treated as a transaction. Possible values:
  * INDIFFERENT : What’s in the scope isn’t treated as a transaction.
  * ALWAYS_BEGIN: A new transaction is started every time the scope is executed.
  * BEGIN_OR_JOIN: If the current processing of the flow has already begun a transaction, join it. Otherwise, begin a new one. (Only relevant when execution order may vary).

  
`transactionalType` |  Defines the type of transaction to use. Possible values:
  * "LOCAL"

  
## See Also
  *   *
HL7 MLLP Connector 2.1 | MuleSoft Documentation
# HL7 MLLP Connector 2.1
Anypoint Connector HL7 Minimal Lower-Layer Protocol (MLLP) Connector (HL7 MLLP Connector) provides connectivity and parsing functionality for HL7 MLLP messages.
For compatibility information and fixed issues, see the HL7 MLLP Connector Release Notes.
## 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)
  * HL7 MLLP Connector


To use HL7 MLLP Connector, you must have:
  * Purchased a MuleSoft license for HL7. Contact your Account Representative about purchasing a license.
  * Anypoint Studio 7.0 or later
  * Java 8


## See Also
  * HL7 MLLP Connector Release Notes
  * HL7 MLLP Connector in Anypoint Exchange
NetSuite Restlet Connector 1.0 | MuleSoft Documentation
# NetSuite Restlet Connector 1.0
Anypoint Connector for NetSuite Restlet (NetSuite Restlet Connector) synchronizes data and automates business processes between NetSuite and third-party applications, either on-premises or in the cloud. NetSuite provides cloud-based business management software that helps companies manage core business processes, ERP financials, CRM, e-commerce, inventory, and more.
NetSuite Restlet Connector provides the following features:
  * Generation of NetSuite business objects
  * Different authentication levels
  * Error-handling support
  * Access to NetSuite using REST calls to RESTlets that expose APIs created with SuiteScript


For compatibility information and fixed issues, see the NetSuite Restlet Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The NetSuite API
  * Anypoint connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * How to create a Mule app using Anypoint Studio


You must also have a NetSuite account with the Web Services features enabled.
## Connection Types
NetSuite Restlet Connector supports OAuth 1.0 only.   
---  
NetSuite Restlet connections use the following authentication types:
  * Restlet Login
Authenticates to NetSuite by invoking login
  * Restlet Token
Authenticates to NetSuite by using either a consumer and token key or secret pairs, which are established within the NetSuite environment


For information about configuring authentication types, refer to Configure a Global Element for the Connector.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * NetSuite Restlet Reference
  * MuleSoft Help Center
Enable External Access to a Trusted Anypoint Platform Organization | MuleSoft Documentation
# Enable External Access to a Trusted Anypoint Platform Organization
To establish a connection to a trusted Anypoint Platform organization, both organizations must reside in the same control plane, and trust must be established between organizations before permissions can be granted. For the users of Organization A to share with the users of Organization B, Organization A must list Organization B as a trusted organization, and Organization B must likewise list Organization A. If either Organization A or Organization B removes the other, all shared permissions are revoked.
Permissions shared between organizations are granted at the organization level. For example, if Organization A grants Organization B permission to view an asset, it grants that permission to every user in Organization B. Organization A does not receive any information about Organization B’s users, sub-organizations, or internal layout.
## Add a New Trusted Organization
When you add a new organization to your external access configuration, you establish one half of a trust relationship. After the other organization adds yours to its configuration, both organizations can share permissions with each other.
To add an organization to your configuration, you must know its Anypoint domain. Domains are human-readable names that uniquely identify an Anypoint Platform organization. Ask the administrators of the other organization what their domain is, and be prepared to share your domain with them so they can add your organization to their list in return. You can view your organization’s unique domain name in the **External Access** page in Access Management.
To add an external organization to your list of trusted organizations:
  1. From the **Access Management** home page, click the **External Access** tab.
  2. In the **External Access** page, click **Add organization**.
  3. Enter the unique domain name of the organization you want to share permissions with.
  4. Click **Add**.


## Remove a Trusted Organization
When you remove a trusted organization from your external access configuration, both organizations lose all existing shared permissions. In addition, you cannot grant new permissions until you reestablish the trust relationship.
To remove a trusted organization:
  1. From the **Access Management** home page, click the **External Access** tab.
  2. In the **External Access** page, select **…** next to the name of the organization you want to remove.
  3. Click **Remove organization**.
  4. Click **Yes, remove**.
Convert String | MuleSoft Documentation
# Convert String
This action step converts a given string or variable to any other variable type and makes it available as a set of new variables.
## Properties
**Conversion Source** The string or variable that is converted.
**Regular Expression** You may define a regular expression to use only a specific part of the given Conversion Source. For example, if your conversion source is "Price: €200" and you only want to use the number as an integer variable, you can set the Regular Expression [0-9]+ to extract the number from the conversion source. More information about regular expressions can be found in section Using Regular Expressions.
## Inbound Variables
**Conversion Source** The string or variable that is converted.
**Regular Expression** You may define a regular expression to use only a specific part of the given Conversion Source. For example, if your conversion source is "Price: €200" and you only want to use the number as an integer variable, you can set the Regular Expression [0-9]+ to extract the number from the conversion source. More information about regular expressions can be found in section Using Regular Expressions.
## Outbound Variables
**AsBool** The _Conversion Source_ as a logical value (_True_ or _False_). If the input variable is a number less than ⇐0 or not the string true or True, it returns _False_.
**AsInt** The _Conversion Source_ as an integer number. If the _Conversion Source_ does not contain a number, 0 is returned; otherwise it will be the first uninterrupted sequential digits from the _Source_. Decimal places are truncated in the case of floating point numbers.
**AsDouble** The _Conversion Source_ as a floating point number.
**AsString** The _Conversion Source_ as string value.
Salesforce Data Cloud Connector 1.3 - XML and Maven Support | MuleSoft Documentation
# Salesforce Data Cloud Connector 1.3 - 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 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/sdc
http://www.mulesoft.org/schema/mule/sdc/current/mule-sdc.xsd
```

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

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


## Next Step
After completing your namespace and `pom.xml` file, you can try the Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Anypoint Partner Manager Release Notes | MuleSoft Documentation
# Anypoint Partner Manager Release Notes
These release notes are provided for Anypoint Partner Manager:
  * Anypoint Partner Manager Release Notes


## See Also
  * Anypoint Partner Manager Overview
Failed to deploy: You cannot deploy this message flow because there is not enough capacity in this environment to deploy this message flow. | MuleSoft Documentation
# Failed to deploy: You cannot deploy this message flow because there is not enough capacity in this environment to deploy this message flow.
## Cause
You do not have sufficient vCore capacity to deploy the applications that support the message flow.
## Solution
Contact your MuleSoft Platform Administrator to review the vCore allocation for your business group.
If vCores are added, wait at least 15 minutes before attempting deployment.
Publishing an API to a Public Portal | MuleSoft Documentation
# Publishing an API to a Public Portal
Use your organization’s public portal to publish API assets for viewing and use by developers inside and outside your organization.
A public portal is visible to anyone who has the URL of the portal. The URL for a public portal starts with `https://anypoint.mulesoft.com/exchange/portals/Domain_Name/`.
Replace `Domain_Name` with the domain name shown in Anypoint access management on the **Organization** page.
## Permissions to Control Asset Publishing
An organization’s Exchange administrators add assets to the public portal and remove assets from the public portal.
Grant the Exchange administrator permission to a user or revoke the permission from a user with Anypoint Access Management.
For more information see Set User Access Permissions.
## Add an Asset to a Public Portal
Follow these steps to add an asset to a portal and make the asset public.
Adding an asset to a portal does not delete the asset. It is still available internally.
  1. Select an API asset to show its details.
  2. Click **Share** and select **Public - Publish it on the public portal**.
  3. Select the version of the asset you want to publish in the public portal.
  4. Select **Save**.


If no action occurs, refresh your browser, log in again, and add the asset again.
## Remove an Asset from a Public Portal
Follow these steps to remove an asset from a portal and make the asset private.
Removing an asset from a portal does not delete the asset. The asset is still available internally.
  1. Select the asset in Exchange and click **Share**.
  2. Select **Public - Publish it on the public portal**.
  3. Clear the version checkbox.
The version of the asset is set to **Private**.
  4. Select **Save**.
  5. In Exchange, refresh the browser screen.
In the asset’s **Overview** , the **Visibility** setting is now **Private**.


## See Also
  *   * Set User Access Permissions
Anypoint Monitoring Release Notes | MuleSoft Documentation
# Anypoint Monitoring Release Notes
  * Anypoint Monitoring Release Notes
  * Anypoint Monitoring Agent Installer Release Notes


## See Also
  * Anypoint Monitoring Documentation
Deploying Mule Apps to Hyperforce | MuleSoft Documentation
# Deploying Mule Apps to Hyperforce
When deploying Mule Apps to a Salesforce Hyperforce (Hyperforce) instance, you deploy on CloudHub 2.0 to a private or shared space. Consider the following guidelines.
## Before You Begin
Before deploying Mule apps to Hyperforce, review the following points:
  * Hyperforce Instance Your MuleSoft account must have access to a Hyperforce instance. Contact your MuleSoft account representative to provision a MuleSoft license to a Hyperforce instance.
  * Hyperforce Endpoints Hyperforce has a different base URL, exchange and platform endpoints. For a successful deployment change the Anypoint Platform endpoints URLs to the supported Hyperforce regions endpoints:
    * Configuring Mule to access Hyperforce
    * Publish an Asset to Exchange Using Maven
    * Configure Hyperforce in Anypoint Code Builder
    * Configure Hyperforce in Anypoint Studio


## Deploy Mule Apps to Hyperforce
To deploy a Mule app to a Hyperforce instance, deploy the app to a CloudHub 2.0 private or shared space. For details, refer to Deploying to CloudHub 2.0 and Shared Global Regions.
Note that deploying to CloudHub is not supported.
## See Also
  * Configuring Mule to Access Hyperforce
  * Salesforce Hyperforce
Mule SDKs | MuleSoft Documentation
# Mule SDKs
Use the Mule SDK for Java or XML to extend the Mule 4 Runtime by creating new modules that you can install in Mule apps. Examples of modules include connectors, such as HTTP, or modules with custom functionality, such as the Validations Module.
The SDK provides an API that:
  * Facilitates faster development of Mule modules than its predecessor, DevKit.
  * Decouples modules from the Mule Runtime internals.
  * Assures consistency across Mule components and other modules, such as cloud connectors.


You can use either the advanced, feature-rich Java Mule SDK or the simpler XML SDK, which provides only outbound operations and doesn’t support recursive calls.
## Differences from DevKit
The Mule SDK for Java is the Mule 4 evolution of DevKit. It replaces Devkit and provides the canonical way of extending the Mule Runtime. DevKit is not available for Mule 4.
Although the SDK builds on the same idea of annotated Java classes, internally it works differently:
  * The SDK is not a code generator. The built module does not contain any generated code (not even the XSD schema). Your module interacts with Mule Runtime through a clearly defined _Extensions API_. However, you do not need to learn the details of this API because the SDK framework takes care of that for you.
  * Compared to DevKit, the SDK is more powerful and supports more features:
    * Transactions
    * Request-response message sources
    * Dynamic configurations
    * Routers
    * Non-blocking operations
    * Classloading isolation
    * Enhanced interoperability with runtime services


## See Also
  * DevKit to SDK Migration Tool
  *
Upgrading and Migrating Amazon SNS Connector to Version 4.7 | MuleSoft Documentation
# Upgrading and Migrating Amazon SNS Connector to Version 4.7
## Supported Upgrade Paths
From Version | To Version  
---|---  
## Changes
  * Added support for FIFO topics, which provide strict message ordering and message deduplication with Amazon SQS FIFO queues.


  * Added a new notification option. Use the **Phone number** parameter to send a text message to a specified phone number. This option is offered in addition to **Target Arn** and **Topic Arn** , which are the existing notification options.


  * Added the ability to configure TLS and custom SNS and STS endpoints.
  * Upgraded `aws-java-sdk` from 1.11.611 to 1.11.969.
  * Upgraded `aws-connector-commons` from 2.0.0 to 2.3.0.


## Requirements
Ensure your system meets the following requirements before you perform the upgrade:
Application/Service | Version  
---|---  
4.1.1 and later  
Amazon Java SDK for RDS | v1.11.969  
Anypoint Studio | 7.1 and later  
See the Amazon SNS Connector Release Notes for updated compatibility information for patch updates.
## Upgrade Prerequisites
Before you perform the upgrade, create a backup of your files, data, and configuration in case you need to restore to the previous version.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Hadoop (HDFS) Connector - Examples | MuleSoft Documentation
# Hadoop (HDFS) Connector - Examples
## Create a Text File in HDFS
The following example shows how to use the connector to create a text file in HDFS:
  1. In Anypoint Studio, click **File > New > Mule Project**, name the project, and click **Finish**.
  2. In the **Mule Palette** search field, type `http`.
  3. Drag the **HTTP > Listener** operation to the canvas.
  4. In **General** settings, click the green plus sign (+) to the right of **Connector Configuration**.
  5. Click **OK** to accept the default settings.
  6. In **Path** , enter `/createFile`.
  7. In the **Mule Palette** search field, type `hdfs`.
  8. Drag the HDFS **Write** operation to the canvas.
  9. Set **Path** to `/test.txt` and leave the default values for the other options. This is the path of the file that HDFS creates.
  10. Right-click in the project canvas and select **Run project** to start the application.
  11. From an HTTP client such as Postman or curl, make a POST request, set the value for `Content-type:plain/text` to `localhost:8081/createFile`, and add the content you want to write as a payload, as shown in the following example: `curl -X POST -H "Content-Type:plain/text" -d "payload to write to file" localhost:8090/createFile`
  12. Use an HDFS explorer to verify that the `/test.txt` file exists and contains your content.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Creating Monitors | MuleSoft Documentation
# Creating Monitors
You create monitors via the Functional Monitoring UI or by uploading test suites written in BAT, a Behavior Driven Development (BDD) language. Both methods enable you to create tests against one or more endpoints, and to create test schedules that run at specified intervals.
This procedure describes creating monitors via the Functional Monitoring UI.
## Before You Begin
Ensure that you have the following permissions set in Access Management:
  * **Anypoint Monitoring > Viewer** or **Anypoint Monitoring > Administrator**
  * **Exchange > Exchange Administrator** or **Exchange > Exchange Contributor**


An Anypoint Platform administrator for your organization grants permission. See Manage Permissions.
## Create a Monitor
To create a monitor:
  1. Click **Create Monitor** in the **Functional Monitoring** section of Anypoint Monitoring.
  2. Under **Step 1 - Setup the monitor** :
    1. Specify a monitor name.
    2. Select a testing location.
    3. Set the monitoring schedule.
  3. Click the **Step 2 - Select endpoints** tab and set up the tests as follows for each endpoint:
    1. By default, the monitor validates self-signed certifications for each endpoint, so **Validate SSL Certificate** is toggled on. To allow unsafe self-signed certifications for an endpoint, toggle **Validate SSL Certificate** off.
    2. Select the method and enter the endpoint URL.
    3. Search for, select, or configure custom headers and insert a value for each header.
    4. For POST, PUT, or PATCH endpoints, optionally insert body content.
    5. Optionally select headers and insert their values.
    6. Select assertion information.
    7. Preview the test by clicking **Run now** under **Preview the result of your monitor**.
  4. Click the **Step 3 - Set notifications** tab.
     * Optionally select notifiers from the list of integrated reporting tools and enter the required information in the value field for each selected notifier:
Reporting Tool | Required Information  
---|---  
New Relic | License Key  
PagerDuty | RoutingKey  
SumoLogic | Endpoint  
Email address  
To hide the required information in the monitor files, see Configuring and Viewing Reports.
  5. Click **Create Monitor**.


On the **Step 2 - Select endpoints** tab, you can alternatively click **Switch to code editor** to edit the monitor as BAT source. For more details, see BDD Test-Writing Syntax Reference.   
---  
## See Also
  * API Functional Monitoring with the Blackbox Automated Testing (BAT) CLI
  *   *   *   * Monitoring the Endpoints of Public APIs
  * Monitoring the Endpoints of Private APIs
Access Management Release Notes | MuleSoft Documentation
# Access Management Release Notes
The following release notes detail new features and fixed issues in the Access Management section of Anypoint Platform:
Anypoint Access Management Release Notes
## See Also
Access Management Overview
isUnionType | MuleSoft Documentation
# isUnionType
## isUnionType(t: Type): Boolean
Returns `true` if the input type is the Union type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The type to check.  
### Example
This example shows how `isUnionType` behaves with different inputs.
#### Source
```
%dw 2.0
import * from dw::core::Types
type AType = String | Number
output application/json
---
{
  a: isUnionType(AType),
  b: isUnionType(Boolean),
}
```

#### Output
```
{
 "a": true,
 "b": false
}
```