BassemE/mulesoft-documentation-embeddings huggingface dataset:
Stopping Request Execution | MuleSoft Documentation
# Stopping Request Execution
To intercept and stop a request, return a `Response` object from your `on_request` wrapped functions:
```
Response::new(401)
  .with_headers(vec![("WWW-Authenticate".to_string(), "Bearer realm=\"oauth2\"".to_string())])
  .with_body(r#"{ "error": "token was not present"}"#)
```

You can block or allow requests to reach the upstream service using a `Flow`. A `Flow` in an `enum` value with two possible values:
  * `Continue`: Defines an object that is forwarded to the response.
  * `Break`: Aborts the request and returns the provided response.


Create a `Flow` as follows:
```
async fn request_filter(request_state: RequestState) -> Flow<()> {
  let header_state = request_state.into_headers_state().await;
  let handler = header_state.handler();
  if handler.header("authorization").is_some() {
    Flow::Continue(())
  } else {
    Flow::Break(Response::new(401)
    .with_headers(vec![("WWW-Authenticate".to_string(), "Bearer realm=\"oauth2\"".to_string())])
    .with_body(r#"{ "error": "token was not present"}"#))
  }
}
```

Due to the streaming nature of `proxy wasm`, it is possible for an early request to partially reach the upstream service while awaiting the `headers_state.into_body_state` function. Avoid this is by not awaiting the body. However, this is not possible for all policies. Configure your upstream to ignore partial requests if the policy must read the body. To avoid early responses reaching the client, see Sharing Data Between Requests and Responses.  
---  
## See Also
  * Implementing Your Custom Policy Features in Rust
CLI for Runtime Manager | MuleSoft Documentation
# CLI for Runtime Manager
Anypoint CLI supports these Runtime Manager features:
  * Hybrid Applications
  * Alerts for Hybrid Applications
  *   * Local Cluster Servers
  * Local Server Groups
Managing Asset Deletion | MuleSoft Documentation
# Managing Asset Deletion
Control how assets are deleted in Exchange from **Settings**. Admins can choose how asset owners can delete asset versions in Exchange. They can enable or disable the ability to permanently delete an asset to reuse the GAV (group ID, asset ID, and version) for a new asset. It doesn’t matter when the asset version was created. When enabled, asset owners see an option to allow the GAV to be reused when deleting an asset version. When disabled, the GAV can’t be reused after deleting the asset version.
To enable or disable the option to delete an asset and reuse the GAV:
  1. From the navigation bar, select **Settings** and select **Asset Deletion & Connected Apps Management**.
  2. In **Asset Deletion Configuration** , enable or disable the option.


## See More
  *
Documentation Conformance | MuleSoft Documentation
# Documentation Conformance
You can check for API documentation conformance using a custom or MuleSoft-provided ruleset. A ruleset provided by MuleSoft that validates API catalog documentation is:
  * API Documentation Best Practices


See Finding and Fixing Conformance Issues for an overview of ways to validate conformance and determine why conformance failed.
## Fix API Documentation Conformance Issues in Exchange
Fix API documentation issues by updating the documentation associated with the API to conform to the rules it violated. For information about updating API documentation using Exchange, see Editing an Asset.
WebSockets Connector in CloudHub | MuleSoft Documentation
# WebSockets Connector in CloudHub
You can deploy Mule apps that contain inbound WebSockets endpoints, outbound WebSockets endpoints, or both to CloudHub.
If your app has inbound WebSockets endpoints only, to deploy the app in CloudHub you must:
  1. Configure an Anypoint Virtual Private Cloud (VPC).
  2. Set up a dedicated load balancer to route WS and WSS traffic through the Mule app.


To set up the inbound WebSocket endpoints:
  1. Configure the WebSockets inbound listener (`<ws:inbound-listener>`) to listen on one of the following ports:
     * `0.0.0.0`.
     * To communicate over WS, set the listener port to `8091`.
     * To communicate over WSS, set the listener port to `8092`.
  2. Deploy your app to the VPC.
  3. Set up the dedicated load balancer’s URL mapping rules to associate a URI to a specific app.
For example, if your app is named 'my-websockets-mule-app', you can define a rule like the following:
     * Input Path: `/my-websockets-mule-app/`
     * Target App: `my-websockets-mule-app`
     * Output Path: `/`
     * Protocol: `ws`


This rule routes all requests made to your dedicated load balancer’s URL and the specified input path to your Mule app’s root path `/`. The load balancer’s name determines its assigned URL, so for this example, if you name your load balancer `mylb`, then you would need to browse to: `ws://mylb.lb.anypointdns.net:80/my-websockets-mule-app/` to connect to your WebSockets Listener.
The dedicated load balancer forwards all requests issued to port 80 to your app’s port 8091, which is destined for all WS connections. When using WSS, however, issue your requests to port 443, and these requests are forwarded to your Mule app’s port 8092.
For CloudHub 2.0 deployments, a Mule app that supports websockets is deployed in the same manner as any other Mule app deployed to CloudHub 2.0. For details, refer to Deploying Apps to CloudHub 2.0.   
---  
## See Also
  * MuleSoft Help Center
  * VPC Network Architecture
  * Dedicated Load Balancer Architecture
  * Dedicated Load Balancer Mapping Rules
Implementing a SOAP Interface | MuleSoft Documentation
# Implementing a SOAP Interface
Create an API by using Anypoint Studio and APIkit for SOAP to consume a remote SOAP service. Download this WSDL tshirt2.wsdl example to create a SOAP interface that accesses data resources and integrates the interface with backend processes that function as an API.
Start by creating an APIkit for SOAP project.
## See Also
  * APIkit for REST Module Reference
Administrator Tasks | MuleSoft Documentation
# Administrator Tasks
Exchange administrators have permissions to perform these tasks:
  * Share an asset to publish an API asset to a public portal, or to grant access to an asset to specific users in your organization, to everyone in your organization, or to everyone in a chosen external organization.
  * Publish an API to a public portal
Publish APIs to a public portal for external users.
  * Save and maintain searches for assets within a business group.
  * Use API Manager to add the Request Access button
Specify which API assets can be shared with users.
  * Set User Access Permissions
Grant the Exchange Administrator, Contributor, Viewer, or Creator permissions to members of your organization, and optionally provide access for individual assets.
  * About Exchange cookies
Find information about Exchange cookies, cookie configuration, and cookies for vanity domains.
  * Migrate Exchange 1 assets to Exchange 2
Move assets from Exchange 1.
Remove Servers from a Cluster | MuleSoft Documentation
# Remove Servers from a Cluster
Private Cloud Edition 
You can remove a server from a cluster without changing the server or cluster.
When you remove a server from a unicast cluster, all existing servers in the cluster are restarted.   
---  
To remove a server from a cluster:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Servers** in the left menu.
  3. Click **Cluster** in the **Type** column to display the details pane.
  4. Click the **X** icon to the right of the server to remove the server from the cluster:
Figure 1. The arrow shows the **X** icon in the details pane.
  5. In the **Remove** confirmation window, select the checkbox to verify that you want to remove the server from the cluster, and then click the **Remove** button.


## See Also
  * Multicast vs Unicast Clusters
WebSockets Messaging Operations | MuleSoft Documentation
# WebSockets Messaging Operations
## Send Operation
The Send operation allows you to send a message through a WebSocket identified by its socket ID after a connection is established. This operation can be used for both inbound and outbound WebSocket instances.
```
  <flow name="sayHello">
   <websocket:open-outbound-socket
    path="/chat/hello"
    config-ref="ws"
    target="socketId"
    targetValue="#[attributes.socketId]"/>
   <websocket:send socketId="#[vars.socketId]" config-ref="ws">
    <websocket:content>'Good morning!'</websocket:content>
   </websocket:send>
  </flow>
  <flow name="sayHelloBack">
    <websocket:inbound-listener
      path="/chat/hello"
      config-ref="ws"
      outputMimeType="text/plain" />
    <websocket:send socketId="#[attributes.socketId]" config-ref="ws">
      <websocket:content>#['Good morning ' ++ attributes.socketId ++ '!']</websocket:content>
    </websocket:send>
  </flow>
```

## Broadcast Operation
The Broadcast operation sends a message to a group of sockets. To select the group of sockets to which the message can be broadcast:
  * Subscribe to specific groups
  * Connect to a specific path
  * Be of a specific type (INBOUND or OUTBOUND)


The type and group parameters work in tandem, in an additive way. They are both optional and can be used separately, but when used together they act as two levels of filtering:
```
<!-- Send to all INBOUND sockets connected to the /quotes endpoint, in the MARVEL and DC groups -->
<websocket:broadcast
  doc:name="Broadcast"
  socketType="INBOUND"
  config-ref="WebSockets_Config"
  path="/quotes">
  <websocket:groups >
    <websocket:group value=" #[['MARVEL', 'DC']]" />
  </websocket:groups>
</websocket:broadcast>
```

### Output
The output of the Broadcast operation is void.
## See Also
  * MuleSoft Help Center
  * WebSockets Connector Overview
  *   * Connector Configuration
Policy Development Kit Architecture Overview | MuleSoft Documentation
# Policy Development Kit Architecture Overview
Flex Gateway Policy Development Kit (PDK) consists of:
  * Anypoint CLI PDK Plugin: Generates and distributes the policy to Exchange
  * Policy Template: Scaffolds new custom policies
  * SDK Building Tools: Simplifies the development process


## Anypoint CLI PDK Plugin
The Anypoint CLI PDK plugin creates the PDK project and uploads policy assets to Exchange (for Connected Mode only). After creating the project, PDK provides a simplified set of commands in a `Makefile` to complete all following development steps.
## Policy Template
PDK generates some simple scaffolding when creating the policy.
All generated files contain the required information to properly compile the policy.
For more information about the included files, see Project Structure.
## SDK Building Tools
Flex Gateway is built on Envoy which requires developed policies to be compatible with the event-driven proxy-wasm architecture.
`proxy-wasm’s event-driven architecture requires users to manage the different events that handle a single request. This causes the following drawbacks that make developing and maintaining event-driven code costly:
  * High complexity of the code due to the coupling of business logic with the entry points
  * Inability to modularize common logic which creates monolithic code
  * Verbose non-linear control flow that creates difficult function callbacks and error propagation


PDK provides building tools that abstract the developer from the event-oriented coding approach by using reactor and executor patterns. PDK provides the developer a way to code each incoming request in a linear method that results in:
  * Fewer compile and runtime errors from using methods in the incorrect context
  * Reduced learning curve
  * Improved debugging by minimizing call stacks
  * Reduced code duplication
  * Improved parameter injection
  * Reduced use of dynamic memory that decreases indeterminism and the need for custom memory management


## See Also
  * Prerequisites for Flex Gateway Policy Development Kit (PDK)
Salesforce Data Cloud Connector 1.2 | MuleSoft Documentation
# Salesforce Data Cloud Connector 1.2
Anypoint Connector for Salesforce Data Cloud (Salesforce Data Cloud Connector) provides a quick and easy way to integrate with Salesforce Data Cloud API endpoints. You can automate data ingestion from third parties, query the Data Cloud Data Lake, search and query customer profile information and calculated insights, and consume data action events to enrich the 360-degree view of the customers in your Data Cloud instance.
Each API call uses a request/response pattern over an HTTPS connection. All required request headers, error handling, and HTTPS connection configurations are built into the connector.
For information about compatibility and fixed issues, refer to the Salesforce Data Cloud Connector release notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Salesforce Data Cloud Ingestion API
  *   * 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:
  * Set up the Ingestion API
  * Credentials to access the Salesforce Data Cloud target resource
  * Anypoint Platform
  * Anypoint Studio version 7.11.x or later


## Set Up the Ingestion API
To use Salesforce Data Cloud Connector, you must first set up the Ingestion API. For more information, refer to Connect MuleSoft with Data Cloud.
After setting up the Ingestion API, refer to Next Step to configure your connector.
## Common Use Cases For the Connector
These are some common use cases for Salesforce Data Cloud Connector:
  * Stream data via insert and delete object endpoints of the Ingestion API Connector
  * Create a bulk job, upload job data, close or abort a job, get a job status, and delete a job as part of the Bulk Ingestion interaction pattern of the Ingestion API Connector
  * Query Data Cloud objects
  * Query Salesforce Data Cloud data lake across data model, lake, unified, and linked objects
  * Query calculated insights with selected dimensions, selected measures, and optional filters
  * Look up and search customer profile information
  * Create webhooks as data action targets for data actions in Data Cloud


For examples, see Salesforce Data Cloud Connector Examples use cases.
## Connection Types
Salesforce Data Cloud connections use the following authentication types:
  * OAuth JWT
Uses OAuth 2.0 with a JSON Web token (JWT) request for user authentication
  * OAuth Username Password
Uses OAuth 2.0 with a username and password for authentication


For information about configuring authentication types, see Using Anypoint Studio to Configure Salesforce Data Cloud Connector.
## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  *   * Use Exchange to Discover Connectors, Templates, and Examples
  * Salesforce Daa Cloud Connector Reference
  * MuleSoft Help Center
Run Mule Runtime Engine On-Premises | MuleSoft Documentation
# Run Mule Runtime Engine On-Premises
When you deploy applications on-premises, you have complete control over the Mule instance which enables you to take advantage of certain characteristics of the on-premises deployment model
If you want to host Mule runtime engine in your own environment, first verify that you meet all hardware and software requirements, and then download and install Mule.
You don’t need to install Mule in the following scenarios:
  * When you use Anypoint Studio (which contains Mule) for development and testing
  * When you deploy applications to CloudHub or Anypoint Runtime Fabric.


After your installation of Mule is complete, install an enterprise license to enable all capabilities of Mule runtime engine.
Learn how to start and stop Mule runtime engine to deploy Mule applications.
Follow the steps in Hardening your Mule Installation when you are ready to promote your Mule applications to production.
If you want to manage your on-premises Mule instance using Runtime Manager, register it using the Runtime Manager agent.
Learn how to choose cluster runtime instances to enhance availability, fault tolerance, and performance characteristics.
Coordinates | MuleSoft Documentation
# Coordinates
The _Coordinates_ action step can be used to either specify a _Variable_ of type _Coordinates_ in the _Workflow_ or to modify existing coordinates.
The X and Y coordinates used in the action step can either be defined individually as constant values or linked as a coordinate pair to another variable of type _Coordinates_. The _Coordinates_ action step can also be used to define offsets to both the X and Y coordinates. The X and Y offsets are added to the X and Y coordinates respectively. The final result of applying offsets to the coordinates is provided as an output variable from the _Coordinates_ action step.
## Properties
  * **Coordinate as point** (default: 0.0) X and Y coordinates
  * **X Offset** (default: 0) This value specifies the X value (horizontal) to be added to the X coordinate.
  * **Y Offset** * (default: This value specifies the X value (horizontal) to be added to the X coordinate.


## Inbound Variables
**Coordinate** (default: 0.0) X and Y coordinates
**X Offset** (default: 0) This value specifies the X value (horizontal) to be added to the X coordinate.
**Y Offset** * (default: This value specifies the X value (horizontal) to be added to the X coordinate.
## Outbound Variables
**Modified Coordinate** Coordinate pair calculated at _Workflow_ runtime from (X-coordinate + X-offset) and (Y-coordinate + Y-offset).
CIM Produce Subject Area | MuleSoft Documentation
# CIM Produce Subject Area
Handling of material that you will be buying, moving and selling. For example, product and inventory product.
## Model Diagrams
The following diagrams show the entities and relationships in this subject area, organized by entity group.
### Inventory Product
### Inventory Received
## Implementation
## See Also
  *   * CIM Design Elements
  *   *
NetSuite Connector 11.10 XML and Maven Support | MuleSoft Documentation
# NetSuite Connector 11.10 XML and Maven Support
Although you can manually code a Mule app in XML, it is more efficient to use Anypoint Studio:
If you manually code a Mule runtime engine (Mule) app in XML, either from the Anypoint Studio XML editor or from a text editor, you can access the connector from your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file.
If you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location and it also adds a dependency to the `pom.xml` file.
## Add a Namespace for the Connector
Paste the following code inside the `mule` tag of the header of your configuration XML:
```
http://www.mulesoft.org/schema/mule/netsuite
http://www.mulesoft.org/schema/mule/netsuite/current/mule-netsuite.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:
```
<mule xmlns:netsuite="http://www.mulesoft.org/schema/mule/netsuite"
	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/netsuite
	http://www.mulesoft.org/schema/mule/netsuite/current/mule-netsuite.xsd">
```

## Add a POM File Dependency
The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app. If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to this connector:
```
<dependency>
 <groupId>com.mulesoft.connectors</groupId>
 <artifactId>mule-netsuite-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 `netsuite`.
  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 NetSuite examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Managing Your Portal | MuleSoft Documentation
# Managing Your Portal
After your portal is styled using the guided design, the **Manage your API portal** page provides options to manage APIs, users, settings, environments, and surfaces issues that occur while managing the portal.
  * Add your APIs from Exchange into your API portal, remove APIs from your portal, view list of APIs that you have in Exchange, and change the visibility of an API version.
  * View and manage members and pending requests.
  * Settings
View information about your portal’s Salesforce account and disconnect the portal.
  * Manage separate deployment environments for your API portal. You can connect to multiple Salesforce sandbox organizations and switch between them.


## Viewing Issues on API Management Pages
API Experience Hub provides diagnostics checks that run in the background to identify issues with the portal and attempt to fix them automatically or provide troubleshooting options. Checks are triggered when loading or refreshing a page and performing an action on the UI. These checks help administrators identify error states and troubleshoot issues.
When issues are detected on API management pages, a message displays in the banner of the page. The message indicates that there are some detected issues that the system is trying to fix.
If there are still issues after all checks and patches are attempted, the banner shows a message that there are issues that require you to act on. To see more information about these issues, click **View details**.
The following minimal prerequisite checks run each time pages in the portal are loaded or refreshed:
  * Connection with Salesforce is operational.
  * The API Experience Hub package is installed in the Salesforce organization.
  * Access Management team for the out-of-the-box profiles are created.
  * The shared user (Experience Builder preview) exists and has all the necessary permissions to log in to Salesforce and interact with the Experience Builder.


Issues can have the following severity:
  * Error
Issues that block you from using one or multiple functions in the portal.
  * Warning
Issues that indicate something isn’t working as expected, but you can still use the portal without addressing the issues.
  * Info
Information that is helpful for you to know but isn’t blocking you from using the portal.
SAP S/4HANA OData Connector 2.8 | MuleSoft Documentation
# SAP S/4HANA OData Connector 2.8
Anypoint Connector for SAP S/4HANA OData (SAP S/4HANA OData Connector) provides support for the OData APIs exposed by SAP S/4HANA Cloud and SAP S/4HANA on-premise.
The connector enables you to perform operations to:
  * Create, get, update, and delete entities
  * Retrieve a single entity
  * Query multiple entities
  * Invoke a remote function
  * Execute batch requests that consist of multiple requests


For software requirements and compatibility information, see the SAP S4/HANA Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The SAP S/4HANA OData API
  * Anypoint Connectors
  * Mule runtime (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Credentials to access the SAP S/4HANA OData target resource
  * Anypoint Platform
  * Anypoint Studio 7.3 or later
  * Have a developer account or other valid SAP S/4HANA instance
  * Access to the catalog service that allows you to use the service discovery
  * A communication user that is assigned to the corresponding communication arrangements for the desired APIs


## Common Use Case for the Connector
Perform CRUD operations on entity types of SAP S/4HANA’s OData API and process the response.
## Exchange Templates and Examples
Anypoint Exchange provides templates you can use as a starting point for your app, as well as examples that illustrate a complete solution.
## Next Step
After you complete the prerequisites and experiment with templates and examples, you are ready to create an app with Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * SAP S/4HANA OData Connector Release Notes
  * SAP S/4HANA OData Connector on Exchange
  * MuleSoft Help Center
Avoid a Potential Security Vulnerability | MuleSoft Documentation
# Avoid a Potential Security Vulnerability
The guest and member user profile contains the Exchange Viewer permission that gives access to all assets in Exchange with this visibility. An impersonated user can potentially exploit this visibility and access assets that are not intended for them.
To troubleshoot this issue, ensure that guest and community users can only access intended and required assets.
  1. Create a new team in Access Management called Guest Community Users and create a new mapping for External Idp Groups called Community Guest.
  2. In Salesforce, change the Named Credential authentication information.
  3. In Exchange, share the assets for the Everyone visibility with the Guest Community Users team and share assets for the Members only visibility with the Community Users team.
  4. In Access Management, remove the Exchange Viewer permission and the inherited permissions of the guest user and the Community Users team.


To avoid a potential security vulnerability:
  1. Create a new team in Access Management called Guest Community Users and create a new mapping for External Idp Groups called Community Guest:
    1. Go to Access Management.
    2. In the Access Management navigation menu, click **Teams**.
    3. Click **Create Team** and enter `Guest Community Users`.
    4. Select **External Idp Groups** and enter the following fields:
       * In **Group Name** , enter `Community Guest`.
       * In **Provider Name** , select a provider.
    5. Click **Save Changes**.
  2. In Salesforce, change the Named Credential authentication information:
    1. Go to **Salesforce > *Setup**.
    2. In the **Quick Find** search box, enter `Named Credentials` and select it.
    3. Click **Anypoint**.
    4. In the **Authentication** section, go to the **Per User Subject** field.
    5. In the **Formula Editor** field change `& "|[\"Community User\"]"` to `& "|" & IF($User.Alias = "guest", "[\"Community Guest\"]", "[\"Community User\"]")`.
    6. Click **Save**.
  3. In Exchange, share the asset with the Guest Community Users or the Community Users team. Repeat these steps for each asset you want to share with guest community users or the community users:
    1. Go to Exchange and select the asset.
    2. Click **Share**.
    3. In the **Collaborators** tab, enter `Guest Community Users` or `Community Users`.
    4. Click **Save**.
  4. In Access Management, remove the ability for users to see the inherited permissions from the Exchange Viewer permission:
    1. Go to **Access Management > Users**.
    2. Select the guest user.
    3. In **Permissions** , move the slider to disable showing inherited permissions.
    4. Click **Permissions > Remove all permissions**.
Configuring DNS on Anypoint Platform PCE | MuleSoft Documentation
# Configuring DNS on Anypoint Platform PCE
For Mule runtime engine (Mule) to communicate with Anypoint Platform, you must provide the DNS or IP address where your Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) installation is exposed to the local network. To do so, follow these steps:
  1. From Anypoint Platform, click **Access Management**.
  2. Click **DNS/IP**.
  3. In **Platform DNS/IP** , enter the address where you are hosting the platform.
  4. Click **Save**.


If you perform a DNS update that changes the endpoints that Mule instances use to connect to Runtime Manager, you must restart the Mule instances before they can connect to the new endpoints.   
---  
## See Also
  * Configuring Anypoint Platform PCE
GitHub Synchronization | MuleSoft Documentation
# GitHub Synchronization
API specification designers often use multiple authoring and version control tools. This can result in maintaining several different specification versions.
GitHub Synchronization is a version control tool that maintains API specifications existing in several locations. Use GitHub Synchronization to enable two-way synchronization between API Designer and your GitHub repository and to automatically capture changes to API projects and send the changes to a synchronized GitHub repository of your choice. Similarly, the application automatically propagates to your API project any changes made in a synchronized GitHub repository.
This bidirectional flow extends API Designer into a collaborative environment where the single source of truth is always GitHub. Unlimited collaborators can share and contribute to the same content.
Using GitHub synchronization with API Designer enables you to:
  * Create new GitHub repositories that synchronize with existing API projects.
  * Create new API projects that synchronize with new GitHub repositories.
  * Create new API projects that synchronize with existing remote GitHub repositories.


To perform GitHub-specific actions, such as opening pull requests, viewing branch diffs, or viewing synchronization status, use the GitHub UI.
## See Also
  * Install and Authorize GitHub Synchronization
  * Create a New Project Synchronized with a New GitHub Repository
  * Create a New Project Synchronized From an Existing GitHub Repository
  * Create a New GitHub Repository Synchronized from an Existing Project
Install API Community Manager Package | MuleSoft Documentation
# Install API Community Manager Package
Support for Mulesoft Government Cloud is only available in API Community Manager version 2.4.x and earlier.   
---  
To perform a new install of the API Community Manager package in your API Community Manager Salesforce Organization, perform the following steps. To upgrade an existing API Community Manager installation, refer to Upgrade API Community Manager.
  1. Complete the prerequisite steps.
  2. In your browser, navigate to the package installation link provided in the API Community Manager Release Notes.
  3. Select **Install for Admin users only**.
  4. Select **I acknowledge that I’m installing a Non-Salesforce Application that is not authorized for distribution as part of Salesforce’s AppExchange Partner Program**.
  5. Select **Install**.
  6. On the **Approve Third-Party Access** page, select the **Yes, grant access to these third-party web sites** check box.
  7. Select **Continue**.
  8. When installation completes, select **Done**.
  9. Start the guided setup.


If you see a message indicating that the installation process is taking a long time to install, you will receive an email when the installation completes.   
---  
You can verify that API Community Manager installation is successful by reviewing the **Installed Packages** information in **Setup**.
Zuora XML and Maven Support | MuleSoft Documentation
# Zuora XML and Maven Support
If you manually code a Mule app in XML either from the Studio XML editor or a text editor, you must perform the following actions to get access to the connector:
  1. Add the namespace for the connector to your XML flow.
  2. Add dependency information to your Maven `pom.xml` file.


In the Studio visual editor, when you drag a connector from the palette to the canvas, Studio automatically populates the XML code with the connector namespace and schema location.
## Add a Namespace for the Connector
If you manually code the Mule app using Studio’s XML editor or another text editor, paste the following code inside the `<mule>` tag of the header of your configuration XML.
```
xsi:schemaLocation="
...
http://www.mulesoft.org/schema/mule/zuora-connector
http://www.mulesoft.org/schema/mule/zuora-connector/current/mule-zuora-connector.xsd"
```

This example shows how the namespace statements are placed in the mule XML block:
```
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http"
   xmlns:mule-zuora-connector="http://www.mulesoft.org/schema/mule/mule-zuora-connector"
	  xmlns="http://www.mulesoft.org/schema/mule/core"
	  xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core
        http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/mule-zuora-connector
        http://www.mulesoft.org/schema/ mule/mule-zuora-connector/current/mule-mule-zuora-connector.xsd
        http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
   <!-- Insert your configuration elements and your flow here -->
</mule>
```

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

Replace `x.x.x` with the version that corresponds to the connector you are using.
To obtain the most up-to-date `pom.xml` file information, access the connector in Anypoint Exchange and click **Dependency Snippets**.
## Next Step
After completing this section, see the Zuora Examples to experiment with Zuora Connector.
## See Also
MuleSoft Help Center
Troubleshooting | MuleSoft Documentation
# Troubleshooting
When you perform API Manager tasks, you might encounter issues or receive error messages. The following topics are covered in this section:
  * Deployment error when creating policies
  * Deployment error when configuring Autodiscovery
Profit Analysis: Process Time | MuleSoft Documentation
# Profit Analysis: Process Time
The widget **Profit Analysis: Process Time** shows the execution duration of a process by a bot compared to the time that a human requires to execute the same process.
The times are shown individually for each configuration.
## 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.
Drag the mouse over any point to see the exact data.
## Configuration
You can select an individual process, whose execution duration 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.
Included Mule Gateway Policies | MuleSoft Documentation
# Included Mule Gateway Policies
See the Included Policies Directory for descriptions of all included policies.
Policies applied to APIs are the same as those in the earlier release with a few exceptions.
Classloader isolation exists between the application, the runtime and connectors, and policies. To fulfill the isolation requirement, policies are self-contained and packaged to include libraries needed for execution, similar to an application.
Policies are non-blocking. You can order all policies except CORS which takes precedence over all other policies.
MEL expressions are replaced by DataWeave.
## Policy Management and Mule 4
In Mule 4, classloader isolation exists between application, runtime, connectors and policies.
Other changes to policies are:
  * All policies are non-blocking, which is described in Mule 4 documentation.
  * All policies except CORS, which is executed first, can be ordered.
  * Resource level policy support, which was restricted to RAML-based APIs, is extended to any HTTP API.
  * You can distribute policies outside of the runtime, which simplifies upgrades.


Mule 4 introduces changes to the packaging, size and scope of a policy.
## Provided Policies and Mule 4
Notable changes to policies for governing APIs are:
  * API Manager now provides two HTTP Basic Authentication policies, one based on the simplest technique for enforcing access control to web resources and the other on the LDAP configuration.
If you upgrade APIs from the Jul 2017 to Nov 2017, the security manager setup information is no longer required. The policy incorporates the information.
  * Header propagation no longer occurs by default. You can configure header propagation for token enforcement and rate limiting policies by checking the Expose Headers checkbox.
  * You can configure the rate limiting policy to share the quota among the cluster nodes (default) or not.


## See Also
  *   * Reordering Policies
Configuring the Response Headers and Status Code | MuleSoft Documentation
# Configuring the Response Headers and Status Code
In the **HTTP Listener** configuration, you can customize the HTTP response body, headers, status code, and reason phrase.
## Configure Variable Names
You can configure the default variables that the HTTP listener searches for by configuring these properties in **APIkit Router** :
  * `outboundHeadersMapName`
Name of the variable that contains a headers map added in the response (`outboundHeaders` by default)
  * `httpStatusVarName`
Name of the variable that stores the status code to set in the response (`httpStatus` by default)


**APIkit Router** creates both variables and facilitates including custom HTTP headers and status codes in the response.
```
<apikit:config name="api-config"
        api="api.raml"
        outboundHeadersMapName="outboundHeaders"
        httpStatusVarName="httpStatus"/>
```

To modify the default names of these variables, update the default HTTP listener configuration to align the variable names and the configuration.
```
<http:listener config-ref="api-httpListenerConfig" path="/api/*">
  <http:response
    statusCode="#[vars.httpStatus default 200]">
    <http:headers>#[vars.outboundHeaders default {}]</http:headers>
  </http:response>
  <http:error-response
    statusCode="#[vars.httpStatus default 500]">
    <http:body>#[payload]</http:body>
    <http:headers>#[vars.outboundHeaders default {}]</http:headers>
  </http:error-response>
</http:listener>
```

## Add a Header to a Response
Put the header to add in the `outboundHeaders` map, as shown in the following example:
```
<set-variable
  value='#[vars.outboundHeaders default {} ++ {newHeaderName: "Header value"}]'
  variableName="outboundHeaders"/>
```

## Set the Status Code of a Response
Use the following example as a reference to assign a specific value to the `httpStatus` variable:
```
<set-variable
  value="201"
  variableName="httpStatus"/>
```

## See Also
  * Sending HTTP responses when configuring HTTP listener source in Mule 4
Obtaining the Client Credentials of a Registered Client Application | MuleSoft Documentation
# Obtaining the Client Credentials of a Registered Client Application
As the owner of a registered client application, you are occasionally required to provide your client ID and client secret when accessing an API, after a contract is created between your application and an API.
You are required to provide the client ID and client secret credentials depending on the policies applied to that API. For example, if the API owner has applied the Client ID Enforcement policy, you must provide your application’s client ID and, optionally, its client secret to access the API.
You must have the Organization Administrator privileges of the root organization, or must be the owner of the client application to access the credentials.
To obtain the credentials of a client application:
  1. Go to **Anypoint Platform** > **API Manager**.
  2. Click **Client Applications**.
  3. From the details pane, click the application for which you want to view the client credentials.
The client ID and client secret credentials for the selected application appear in the window.
  4. Alternatively, if you need to obtain only the client ID of the registered client application, select the correct version of the API and click **Contracts**.
As an Application Owner, if you do not have access to API Manager, you can view the application credentials in Exchange.
  5. To view the details, click the specific API contract.


## See Also
  * Registering a Client Application https://docs.mulesoft.com/exchange/about-my-applications
every | MuleSoft Documentation
# every
## every<T>(list: Array<T>, condition: (T) -> Boolean): Boolean
Returns `true` if every element in the array matches the condition.
The function stops iterating after the first negative evaluation of an element in the array.
### Parameters
Name | Description  
---|---  
The input array.  
`condition` | A condition (or expression) to apply to elements in the input array.  
### Example
This example applies a variety of expressions to the input arrays. The `$` references values of the elements.
#### Source
```
%dw 2.0
import * from dw::core::Arrays
var arr0 = [] as Array<Number>
output application/json
---
{ "results" : [
   "ok" : [
    [1,1,1] every ($ == 1),
    [1] every ($ == 1)
   ],
   "err" : [
    [1,2,3] every ((log('should stop at 2 ==', $) mod 2) == 1),
    [1,1,0] every ($ == 1),
    [0,1,1,0] every (log('should stop at 0 ==', $) == 1),
    [1,2,3] every ($ == 1),
    arr0 every true,
   ]
  ]
 }
```

#### Output
```
{
  "results": [
   {
    "ok": [ true, true ]
   },
   {
    "err": [ false, false, false, false, false ]
   }
  ]
 }
```

## every(value: Null, condition: (Nothing) -> Any): Boolean
Helper function that enables `every` to work with a `null` value.
_Introduced in DataWeave version 2.3.0._
Timer (dw::util::Timer) | MuleSoft Documentation
# Timer (dw::util::Timer)
This utility module contains functions for measuring time.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::util::Timer` to the header of your DataWeave script.
## Functions
Name | Description  
---|---  
| Returns the current time in milliseconds.  
Executes the input function and returns an object with execution time in milliseconds and result of that function.  
Executes the input function and returns a `TimeMeasurement` object that contains the start and end time for the execution of that function, as well the result of the function.  
| Returns the representation of a specified date-time in milliseconds.  
## Types
Salesforce Composite Connector 2.9 | MuleSoft Documentation
# Salesforce Composite Connector 2.9
Anypoint Connector for Salesforce Composite enables you to work with the Salesforce Batch and SObject Tree APIs. The connector exposes convenient methods for preparing subordinate requests, executing them in one batch, and parsing the results.
Salesforce Composite Connector also enables you to create SObject trees by using the **Create sobject tree** operation, which is separate from the batch operations.
This connector provides DataSense for execution and to:
  * Prepare subordinate requests and then parse the responses
  * Create SObject trees


For compatibility information and fixed issues, see Salesforce Composite Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Salesforce Composite API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Credentials to access the Salesforce Composite target resource
  * Anypoint Studio version 7.0 or later


## Authentication Types
Salesforce Composite Connector connections use the following authentication types:
  * OAuth v2.0
  * OAuth JWT
  * OAuth SAML
  * OAuth Username and Password


For information about configuring these authentication types, see Using Anypoint Studio to Configure Salesforce Composite Connector.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Message Flow Components | MuleSoft Documentation
# Message Flow Components
A message flow in Partner manager comprises configuration objects that execute end-to-end B2B message processing:
  * Partner identifiers Send and receive identifiers, such as X12 ISA and GS identifiers and AS2 identifiers
  * Receive and Send endpoints Receive source messages or send transformed messages using a standard transport protocol
  * Source and target message types Settings that define the structures of received messages and of the transformed messages sent to the backend.
  * Maps DataWeave translation maps that convert inbound EDI transactions to the back-end application format or transactions outbound from the backend to EDI format
General Timer Start | MuleSoft Documentation
# General Timer Start
_General timers_ are used to measure whole _Transactions_.
First place the _Start Timer_ and then the _Stop Timer_ by the _Transaction_ elements for which the run time is to be measured.
_General timers_ are **not** valid as _Measurement Points_ and cannot therefore be linked to a _Data Source_.
## Properties
  * **Timer name**
Name to write to the output file.


## Inbound Variables
The _General Timer Start_ action step has no inbound variables.
## Outbound Variables
The _General Timer Start_ action step has no outbound variables.
## See Also
  *
Manage CloudHub-Specific Settings | MuleSoft Documentation
# Manage CloudHub-Specific Settings
This document describes Anypoint Platform settings relevant to applications deployed to CloudHub.
Manage these settings from the **Access Management** in your Anypoint Platform.
Your account must have the role **Cloudhub administrator** or **Organization Administrator** to edit access management settings.   
---  
## Manage Regions
If Global Deployment is enabled on your account, you can also set the default region. The region auto-populates in the deployment screen settings for all applications deployed by users in your organization, and it can be adjusted at the application level if necessary for individual deployments.
Access this menu by clicking the gear icon next to your user name at the top of the screen and then picking the **CloudHub** link, under **Settings** in the left menu.
If you don’t currently have Global Deployment enabled on your account but would like it, please contact your MuleSoft account manager.   
---  
See Regional Services for a list of available regions.
## CloudHub Subscription
When you first sign up for CloudHub, you’re automatically added to the Free plan (subscription level). To upgrade to a paid plan, please contact your MuleSoft account manager.
To see your subscription level and usage, click the gear icon at the top of the screen and click **Subscription** :
The following **Subscription** example shows the use of 13.1 of possible 20 vCores in the Production environment and 2 of 20 vCores in use in the Sandbox environment:
The number of workers is not the same as the number of applications. For more information about worker sizing, see High Availability and CloudHub Workers.  
---  
Only running applications count for vCores processing usage. `Stopped` applications do not consume vCore availability.
## Changing Your Plan
To change your plan, you can contact your account representative or your Customer Success Manager.
## See Also
  *   *   * CloudHub Plans and Pricing
random | MuleSoft Documentation
# random
## random(): Number
Returns a pseudo-random number greater than or equal to `0.0` and less than `1.0`.
### Example
This example generates a pseudo-random number and multiplies it by 1000.
#### Source
```
%dw 2.0
output application/json
---
{ price: random() * 1000 }
```

#### Output
```
{ "price": 65.02770292248383 }
```