BassemE/mulesoft-documentation-embeddings huggingface dataset:
Creating New Projects Synchronized with New GitHub Repositories | MuleSoft Documentation
# Creating New Projects Synchronized with New GitHub Repositories
When creating an API Designer project, you can also create a GitHub repository and synchronize the repository with your project.
## Before You Begin
Before you create and synchronize a project, ensure you have:
  * The Design Center Developer permission within Anypoint Platform
  * Installed and authorized the GitHub Synchronization application
  * Signed into GitHub


## Synchronize A New Project
  1. On the Design Center **Projects** page, click **Create new**.
  2. Select **New API Spec**.
  3. In the **New API Spec** dialog, specify an API title.
  4. Select **I’m comfortable with designing it on my own**.
  5. Click the **Sync this project with an external GitHub repository** checkbox.
  6. In the expanded dialog, select an organization from the **GitHub Organization** list.
The **GitHub Organization** list remains empty if the GitHub Synchronization application is not installed.   
---  
  7. If necessary, specify a new name for the repository.
  8. Click **Create API Spec**.
You are navigated to the new project’s text editor.


In addition to synchronizing GitHub repositories when creating API specifications, you can synchronize a new GitHub repository when creating fragments and importing APIs.
## See Also
  * Create an API Specification with the Text Editor
  * Helpful Features in the Text Editor
  * Publish an API Specification
Access Server Settings | MuleSoft Documentation
# Access Server Settings
Private Cloud Edition 
Use the **Settings** page to configure server properties and view alerts. You can also perform other actions from this page, such as deleting a server group.
To access the server **Settings** page:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Click **Servers** in the navigation menu.
  3. Either:
     * Click the **Type** column to display the details pane and click **Manage Server** , **Manage Group** , or **Manage Cluster** :
Figure 1. The arrow shows the **Manage Server** button in the details pane.
     * Click the name of the server, server group, or cluster on the **Servers** page and then click **Settings** :
Figure 2. The arrow shows the option to navigate to the **Settings** page.


## See Also
  * Configure Server Properties
  * Create Custom Server Properties
  * Shut Down, Restart, or Delete Servers
Azure Cosmos DB Connector 1.0 XML and Maven Support | MuleSoft Documentation
# Azure Cosmos DB Connector 1.0 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/azure-cosmos-db
http://www.mulesoft.org/schema/mule/azure-cosmos-db/current/mule-azure-cosmos-db.xsd
```

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

## 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-azure-cosmos-db-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 `azure cosmos db`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Web Application Firewall Security Policy | MuleSoft Documentation
# Web Application Firewall Security Policy
The Web Application Firewall (WAF) security policy is available for request and response traffic to provide protection at the Web application level. The OWASP Core Rule Set (CRS) rules, as enumerated in the Anypoint Security policies RAML are supported. Policies are grouped into the major threat categories for requests and responses.
Only the official OWASP CRS rules are supported.   
---  
WAF policies are fully integrated with the existing Anypoint Security policy DoS (Denial of Service). When the WAF policy detects errors, it triggers the thresholds configured in the DoS, which can be optionally configured to take actions such as shaping or blocking traffic for an IP address from a malicious source.
## See Also
Configuring a Proxy for FTPS Connector | MuleSoft Documentation
# Configuring a Proxy for FTPS Connector
Anypoint Connector for FTPS (FTPS Connector) enables you to configure an HTTP or HTTPS tunnel proxy. The following example shows how to configure the **Proxy** field:
  1. In Studio, select your FTP Connector operation from the canvas.
  2. In the configuration screen for the operation, click the plus sign (**+**) next to **Connector configuration** to access the global element configuration fields.
  3. On the **General** tab, specify the connection information for the connector.
  4. Set **Proxy** to **Https tunnel proxy**.
  5. Set **TLS Configuration** to **Edit inline**.
  6. For **Trust Store Configuration** , select **Insecure**.
  7. Set the following fields:
     * **Proxy host** : `localhost`
     * **Proxy port** : `3129`
     * **Proxy username** : `userprox`
     * **Proxy host** : `passprox`


In the **Configuration XML** tab, the configuration `ftp:https-tunnel-proxy` looks like this:
```
<ftps:config name="FTPS_Config">
		<ftps:connection >
			<ftps:proxy >
				<ftps:https-tunnel-proxy host="localhost" port="3129" username="proxuserftps" password="passproxftps" >
					<tls:context >
						<tls:trust-store insecure="true" />
					</tls:context>
				</ftps:https-tunnel-proxy>
			</ftps:proxy>
		</ftps:connection>
	</ftps:config>
```

## See Also
  * MuleSoft Help Center
Flow Control | MuleSoft Documentation
# Flow Control
Flow Control action steps enable you to perform controlled iterations and loops during the automation.
  * Break Loop enables you to exit a _Loop_ control block during its execution.
  * This _Flow Control Element_ reads data from a CSV file.
  * This action step simply forces the Workflow into an error state.
  * This action step can reset an error state to OK.
  * The Group block enables you to group action steps for better visibility and readability.
  * This action step enables you to synchronize access if multiple parallel Workflows need to access a file or a mailbox, for example in the case of Robotic Applications.
  * A Loop block enables you to repeat the same Transaction and action steps two or more times.
  * The Managed block enables you to handle errors within your Workflow as they happen.
  * This action step enables you to respond flexibly to non-predictable situations.
  * This action step makes it possible to match the contents of a variable against certain predefined cases.
  * Transactions enable you to split Workflows into logical, self-contained units.
Troubleshooting | MuleSoft Documentation
# Troubleshooting
Private Cloud Edition  Runtime Fabric 
If you experience problems with your deployed apps, Runtime Manager provides several tools that can help you determine the cause.
The troubleshooting resources available to you depend on your deployment strategy.
## Troubleshoot Applications
You can access information to help you troubleshoot applications using the following tools:
  * You can access a dashboard with key metrics and see events at an individual transaction level of detail.
  * Using API functional monitoring, you can automate testing and generate reports to verify API functionality and validate the results that the API generates. You can monitor APIs at each stage of the software development life cycle and in production.
  * View application log data 
For applications deployed to CloudHub and CloudHub 2.0, you can access log data that includes deployment messages and events for each worker or replica and Mule runtime engine logs.
For applications deployed to your own servers, you can export log data to third-party software to view there.


## Troubleshoot Servers
With applications deployed to your own servers, you can access information to help you troubleshoot them through the following tools:
  * Use alerts and dashboards to get information about the servers.
  * Export data to external analytics tools
Send data to an external tool like Splunk or ELK.


## See Also
  * Manage Deployed Applications
  *   * Deploying Apps to CloudHub 2.0
  *
Developing Integrations Using Agentforce | MuleSoft Documentation
# Developing Integrations Using Agentforce
Cloud IDE 
Desktop IDE 
To jumpstart your integration development, use natural language input in Agentforce for Anypoint Code Builder Generative Flows to generate flows for you. The engine for these generative flows is the pre-trained large language models (LLM) that exist within the Salesforce Shared Trust Boundary. These LLMs are at the core of the Generative Flows capabilities in Anypoint Code Builder.
Agentforce for Anypoint Code Builder Generative Flows is available on US, EU, Canada, and Japan cloud hosts.   
---  
## Trust Layer
The Agentforce trust layer bridges Anypoint Platform and the LLMs, as shown in this flow:
The Anypoint Code Builder user creates a message based on their use case and sends it to Agentforce.  
---  
To minimize inaccurate responses (the AI "hallucination" effect), messages are grounded with factual MuleSoft proprietary data and user context.  
To ensure the data is sent safely to the external LLM, the message is sent to Open AI via the secure gateway.  
To keep your data secure, all data remains in Salesforce.  
After the LLM generates a response, the content is sent back through the secure gateway.  
MuleSoft validates the generated output to ensure the generated flow works within the MuleSoft ecosystem.  
Anypoint Code Builder logs the message and generated responses for monitoring before surfacing the validated response in Anypoint Code Builder.  
This feature uses generative AI, which is known to include inaccurate or harmful responses. Before implementing this feature, review the output for accuracy and safety. You assume responsibility for the output when making business decisions.   
---  
## See Also
  * Einstein Generative AI & Trust
  *   * Einstein Trust Layer: Designed for Trust
  * Creating Integrations Using Agentforce
Reviewing Processed Documents | MuleSoft Documentation
# Reviewing Processed Documents
After processing a document, IDP queues it for review if:
  * At least one field marked as _visible_ shows a confidence score lower than the configured threshold.
  * At least one field marked as _visible_ and _required_ is missing or could not be extracted.


In this case, a user must review the document to verify the values for the conflicting fields. After the review is finished, the status of the extraction changes to `SUCCEEDED`.
## Before You Begin
Before you can review a document, ensure that:
  * You are assigned as a reviewer in the corresponding document action.


## Review a Document in the UI
To review the results of a processed document:
  1. In the navigation panel, click **Review Tasks**.
  2. Click the name of the document to review.
  3. In the **Results** panel, verify the values extracted from each field.
During this step, you can modify the values that require adjustment.
IDP highlights fields in yellow when the extracted values have a confidence score below the configured threshold.
  4. After reviewing all values, click **Submit This Page**.
If there are more than one results page, click **Submit and Next** and continue the process until you review all pages.


## See Also
  * Processing Documents and Retrieving Results With the API
  * Processing Documents and Retrieving Results With RPA
  *
Migrating the Secure Properties Placeholder | MuleSoft Documentation
# Migrating the Secure Properties Placeholder
In Mule 3, the Secure Properties Placeholder was part of the Security Module. In Mule 4, it is separated in its own Secure Configuration Properties module.
Example: Complete Secure Properties Placeholder in Mule 3
```
<secure-property-placeholder:config
 name="Secure_Property_Placeholder" key="${prod.key}"
 location="test.${env}.properties" encryptionAlgorithm="Blowfish"
 encryptionMode="CBC"/>
```

Differences between Mule 3 and Mule 4:
  * The Mule 3 `location` attribute is replaced by `file` in Mule 4 for consistency with other components.
  * In Mule 3, `location` can define more than one file, separated by a comma (`,`). In Mule 4, this is not possible for troubleshooting purposes. Instead, you need to define a `<secure-properties:config>` tag for each file.
  * For overlapping properties between files, Mule 3 preserves the last definition. The Mule 4 module preserves the first definition.
  * The encryption attributes (`mode` and `algorithm`) are defined in the child tag `<secure-properties:encrypt/>`, and the supported algorithms and modes are the same for both Mule 3 and 4 (see Mule 4 Secure Configuration Properties).


A full migration of the Mule 3 example looks like this:
Example: Complete Migration Example
```
<secure-properties:config
 key="${prod.key}"
 file="test.${env}.properties"
 name="Secure_Property_Placeholder">
  <secure-properties:encrypt algorithm="Blowfish" mode="CBC"/>
</secure-properties:config>
```

## See Also
Mule 4 Secure Configuration Properties
locationString | MuleSoft Documentation
# locationString
## locationString(value: Any): String
Returns the location string of a given value.
### Parameters
Name | Description  
---|---  
A value of any type.  
### Example
This example returns the contents of the line (the location) that defines variable `a` in the header of the DataWeave script.
#### Source
```
%dw 2.0
import * from dw::Runtime
var a = 123
output application/json
---
locationString(a)
```

#### Output
```
"var a = 123"
```
Google Drive Connector 1.1 | MuleSoft Documentation
# Google Drive Connector 1.1
Anypoint Connector for Google Drive (Google Drive Connector) enables you to automate business processes between Google Drive (Drive) and other enterprise applications, either on premises or in the cloud. Using the Google Drive connector, you can programmatically access and upload content and relevant information to and from Drive.
Drive enables you to store and back up all of your files in the cloud, including documents, slides, images, audio, and video. It integrates seamlessly with cloud-native apps that enable your teams to collaborate effectively in real time, using apps like Google Docs, Sheets, and Slides.
For compatibility information and fixed issues, see the Google Drive Connector Release Notes.
## Before You Begin
To use this connector, you should be familiar with:
  * The Google Drive 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 Google Drive
  * Anypoint Studio version 4.2.1 or later


## Common Use Cases for the Connector
Automate powerful business processes by integrating Google Drive with other enterprise IT tools and systems, such as messaging, CRM, and ITSM. Possibilities include:
  * Improving sales operations
Automate contract approval processes so that when a sales contract is received in the Salesforce CRM system, it is automatically uploaded to Drive and shared with the deal desk or other teams for their review.
  * Enhancing cross-team collaboration
Automatically notify all relevant teams and team members via Slack or Microsoft Teams and email when new content, such as product specs, contracts, and legal addendums, is uploaded to a given folder in Drive.
  * Securing your enterprise content
Automatically upload properly secured content from other enterprise systems, such as CRM, email, and marketing tools, to Drive folders. This minimizes IP leaks by making Drive the single source of truth for all of your content.


## Authentication Types
Google Drive Connector uses the OAuth 2.0 authentication connection type, which uses access tokens provided by the authorization server to access protected data.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Zendesk Connector 1.1 | MuleSoft Documentation
# Zendesk Connector 1.1
Anypoint Connector for Zendesk enables you to connect to the Zendesk Support API.
For information about compatibility and fixed issues, see the Zendesk Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Zendesk Connector’s API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have access to:
  * The Zendesk target resource
  * Anypoint Platform
  * Anypoint Studio version 4.2.1 or later


## Common Use Cases For the Connector
Common use cases for Zendesk Connector include the following:
  * Integrating Salesforce with Zendesk to automate actions
For example:
    * Keep your organization data in Zendesk in sync with your account data in Salesforce, and avoid deduplication on either side.
    * Sync data between your case data in Salesforce with your ticket data in Zendesk.
    * Sync contact data in Salesforce with your user data in Zendesk. When a new user is created or updated in Zendesk, a corresponding record is created or updated in Salesforce.
  * Communicating with Slack
Send case data from Zendesk as a message in Slack to drive effective collaboration and resolution.


## Authentication Types
Zendesk connections can use the following authentication types:
  * Basic authentication
Uses an email address and password for authentication
  * API token
Uses your email address with an API token for authentication
  * OAuth2
Delegates user authentication to the service hosting the user account


## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Xero Accounting Connector 1.1 | MuleSoft Documentation
# Xero Accounting Connector 1.1
Anypoint Connector for Xero Accounting (Xero Accounting Connector) enables you to access the Xero Accounting APIs. Xero Accounting APIs expose accounting and related functions of the main Xero application and can be used for a variety of purposes, such as creating transactions like invoices and credit notes, to extracting accounting data via the Reports endpoint.
For compatibility information and fixed issues, see the Xero Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Xero Accounting 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 Xero Accounting target resource
  * Anypoint Platform
  * Anypoint Studio 7.3 or later


## Authentication Types
Xero Connector connections use the OAuth 2.0 authentication method.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  *   * MuleSoft Help Center
About Object Store in the EU Control Plane | MuleSoft Documentation
# About Object Store in the EU Control Plane
The EU control plane uses Object Store V2. Mule applications that you create in the EU control plane use this version of Object Store by default. You do not have to modify any configuration in the platform or your application to use this version.
Object Store V1 is not supported in the EU control plane.
## See Also
  * Anypoint Object Store V2
  * To Use Object Store v2
  * REST API: Object Store v2
  * EU Control Plane
Core Namespaces (dw::Core) | MuleSoft Documentation
# Core Namespaces (dw::Core)
Namespace | Definition | Description  
---|---|---  
`xsi = http://www.w3.org/2001/XMLSchema-instance` |  Namespace declaration of XMLSchema.
OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement | MuleSoft Documentation
# OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement
The OAuth dance is the authentication process performed by the Mule OAuth 2.0 provider, API, and client application. This authentication process conforms to RFC 6749.
## OAuth Dance Authentication Flow
The OAuth dance authentication flow is illustrated in the following screenshot:
  1. A token request is sent to the provider, specifying client application credentials as needed.
The credentials correspond to a client ID and secret generated by Anypoint Platform.
  2. The Mule OAuth 2.0 provider returns a token.
  3. An HTTP request is performed against the protected resource to which the OAuth 2.0 Access Token Enforcement policy is applied.
The protected resource must be linked with the API definition through Autodiscovery.
  4. The OAuth 2.0 Access Token Enforcement policy intercepts this request and communicates with the provider to validate the token.
  5. If the token is correctly validated:
    1. The token is allowlisted and kept on the record until it expires.
Any further request that contains this token is not validated against the OAuth provider.
    2. The associated client ID of the client application credentials is verified to ensure that the application has an active contract with the API.
This is not applicable to OpenAM providers.
  6. The request is then forwarded to the resource.
  7. An HTTP response is generated.


The requester obtains the authorization from an OAuth provider, instead of directly gaining access to the credentials of the client application. The client application owner owns the credentials and authorizes the provider to interact with the API. The protected resource determines that the user is authorized because it has a valid access token.
## Example HTTP Request to a Protected Resource Using curl
In the following example, the protected resource is set to .
### Using an HTTP Authorization Header
```
curl -H "Authorization:Bearer <access token>" "http://localhost:8081/simple" -vvv
```

### Using an HTTP Query Parameter
```
curl "http://localhost:8081/simple/?access_token=<access token>" -vvv
```

## See Also
  * OAuth 2.0 Grant Types
  * Mule OAuth 2.0 Provider
Translate With AWS | MuleSoft Documentation
# Translate With AWS
The translate with AWS action step enables you to use the Amazon Translate service to translate the specified text.
See Supported Languages for a list of languages that the Amazon Translate service supports.
## Inbound Variables
  * **AWS Credentials**
Or, if **Use custom settings** is activated in the wizard:
    * **Client Id**
    * **Client Secret**
    * **Session Token**
    * **Use Session Token**
    * **Region Endpoint**
  * **Json Path**


## Outbound Variables
  * **Raw Text**
The extracted raw text of the document.
  * **Normalized Json**
The parsed result based on the normalized result and defined Json path.
  * **Raw Json**
The complete AWS response.
  * **Detected Language**
The detected language of the document’s text.


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


## See Also
  *   *   * Building JSONPath Expressions
Apply a Policy | MuleSoft Documentation
# Apply a Policy
For Flex Gateway running in Connected Mode, you apply included policies via API Manager:
  1. Go to **Anypoint Platform > API Manager**.
  2. In **API Administration** click the name of the API to which to apply a policy.
  3. From the left navigation menu, click **Policies**.
  4. Click **+ Add policy**.
  5. Select the policy to apply.
  6. Configure the required configuration parameters.
For policy configuration parameters, see Included Policies Directory.
  7. Click **Apply**


You can apply a policy either to the entire API (default) or to specific methods and resources of an API.
How Version 4.x Differs from Previous Versions | MuleSoft Documentation
# How Version 4.x Differs from Previous Versions
Scripts that use versions of the Anypoint Platform CLI earlier than 4.x do not automatically use Anypoint CLI 4.x commands because the new version of the CLI has different command names and syntax. However, because the CLI version 4.x name and install package are different from previous versions, you can install Anypoint CLI 4.x and an earlier version on the same system and use both versions in your scripts.
Warning: Anypoint CLI 4.x is not backward compatible with previous versions.
## Changes
Anypoint CLI 4.x introduces the following changes:
  * **CLI Name** The new CLI is named `anypoint-cli-v4`.
  * **Installation** Command groups for Anypoint Platform components are packaged as plugins that can optionally be installed and uninstalled separately from the core installation package.
  * **Authentication**
    * Set your credentials using the `anypoint-cli-v4 conf` command.
    * The only way to authenticate to Anypoint CLI 4.x is through Connected Apps.
  * **Command Syntax** The separator between command parameters can be either a colon (:) or a space. For example, the command to get the Exchange asset resource list can be either `anypoint-cli-v4 exchange:asset:resource:list` or `anypoint-cli-v4 exchange asset resource list`.
  * **Commands and Properties** The following commands and properties have changed:
    * `exchange:asset:upload` replaces `exchange:asset:uploadv2`.
    * `exchange:asset:upload --properties='{"property1":"value2", "property2": "value2"}'` replaces `exchange:asset:upload properties.value1.value2`.
    * `cloudhub:load-balancer:allowlist:add/remove` commands replace the similar commands that used a non-inclusive term.
    * `runtime-mgr:cloudhub-application:describe -o JSON` replaces `runtime-mgr cloudhub-application describe-json`.
    * `runtime-mgr:pcf-application:describe -o JSON` replaces `runtime-mgr pcf-application describe-json`.
    * `cloudhub:vpc:describe -o JSON` replaces `cloudhub vpc describe-json`.
    * Environments and Business Groups commands are no longer supported.
    * Datagraph API Source Management commands are no longer supported.
    * Runtime Fabric Instances commands are no longer supported.
  * **Interactive Mode** Because interactive mode is no longer supported, the following commands and flags are no longer available:
    * `use business-group` command
    * `use environment` command
    * `exit` command
    * `-f, --fields` flag
    * Ability to interactively enter the password if you omit it
  * When using multi-option flags in a command in Anypoint CLI 4.x,you need to either put the parameter before the flags or use a `--` (two dashes followed by a space) before the parameter to make it work.
substringEvery | MuleSoft Documentation
# substringEvery
## substringEvery(text: String, amount: Number): Array<String>
Splits a string into an array of substrings equal to a specified length.
The last substring can be shorter than that length. If the length is greater than or equal to the length of the string to split, the function returns the entire string.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The string to split.  
The desired length of each substring.  
### Example
This example shows how `substringEvery` behaves when splitting an input string. The last returned substring is shorter than the others.
#### Source
```
%dw 2.0
import substringEvery from dw::core::Strings
output application/json
---
substringEvery("substringEvery", 3)
```

#### Output
```
["sub", "str", "ing", "Eve", "ry"]
```

## substringEvery(text: Null, amount: Any): Null
Helper function that enables `substringEvery` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
Viewing Schedules That Use a Private Location | MuleSoft Documentation
# Viewing Schedules That Use a Private Location
You can view the number of schedules that use a private location.
When initially specifying the private location, a test run worker associated with the schedule is created in that location. Viewing the location shows how many workers are running.
## View the Schedules That Use a Private Location
  1. Display the list of locations by opening **Location Manager** from the homepage.
  2. Click the **Private Locations** tab.
  3. Select a private location.
The list of schedules that use the private location appears. Each schedule displays the following information:
     * The name of the monitor that the test is defined in
     * The interval at which the test is run
     * The configuration used when running the test
keysOf | MuleSoft Documentation
# keysOf
## keysOf<K, V>(obj: { (K)?: V }): Array<K>
Returns an array of keys from key-value pairs within the input object.
The returned keys belong to the Key type. To return each key as a string, you can use `namesOf`, instead.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The object to evaluate.  
### Example
This example returns the keys from the key-value pairs within the input object.
#### Source
```
%dw 2.0
output application/json
---
{ "keysOf" : keysOf({ "a" : true, "b" : 1}) }
```

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

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

#### Output
```
{
 "keysOfExample": [
  "http://test.com",
  "http://test.com",
  {
   "name": "Mariano",
   "lastName": "Achaval"
  },
  {
   "name": "Stacey",
   "lastName": "Duke"
  }
 ],
 "namesOfExample": [
  null,
  null,
  null,
  null
 ]
}
```

## keysOf(obj: Null): Null
Helper function that enables `keysOf` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
onNull | MuleSoft Documentation
# onNull
## onNull<R>(previous: Null, callback: () -> R): R
Executes a callback function if the preceding expression returns a `null` value and then replaces the `null` value with the result of the callback.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The value of the preceding expression.  
Callback that generates a new value if `previous` returns `null`.  
### Example
This example shows how `onNull` behaves when it receives a `null` value.
#### Source
```
%dw 2.0
output application/json
---
{
   "onNull": []
       reduce ((item, accumulator) -> item ++ accumulator)
       then ((result) -> sizeOf(result))
       onNull "Empty Text"
 }
```

#### Output
```
{
 "onNull": "Empty Text"
}
```

## onNull<T>(previous: T, callback: () -> Any): T
Helper function that enables `onNull` to work with a _non-null_ value.
_Introduced in DataWeave version 2.4.0._
X12 EDI Connector 2.17 - Understanding the EDI Schema Language | MuleSoft Documentation
# X12 EDI Connector 2.17 - Understanding the EDI Schema Language
X12 EDI Connector uses a YAML format called EDI Schema Language (ESL) to represent EDI schemas. Basic ESLs define the structure of Electronic Data Interchange (EDI) messages in terms of:
  * structures, known as _transaction sets_ in X12 terminology
  * groups, known as loops, in X12
  * segments, composites, and elements


ESLs for the all supported X12 versions are included. If you are using HIPAA, then a set of HIPAA variations of base X12 transaction sets are included.
You can customize X12 schema definitions to suit your data by defining an overlay schema. An overlay schema is a type of ESL that enables you to modify a base schema, such as an X12 4010 850 schema, with your specific conventions. You don’t need an overlay schema if you’re using the structure defined by the standard, but most EDI exchanges modify the base definitions in an implementation convention.
You can define your own custom schemas, or copy and edit a base X12 schema definition to suit your data as shown in the EDI Schema Language Reference.
## Finding Schema Locations
To use the connector, you need to know the locations of the schemas in your project. If you’re using out-of-the-box X12 schemas and not customizing anything, the schema location follows the `/x12/{version}/{transaction set}.esl` convention.
For example, using the `005010` version and the 850 transaction set, the schema location is `/x12/005010/850.esl`.
If you’re using one or more custom schemas, refer to XML Schema and Trading Partner Configuration for complete information about setting your schema locations.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
first | MuleSoft Documentation
# first
## first(text: String, amount: Number): String
Returns characters from the beginning of a string to the specified number of characters in the string, for example, the first two characters of a string.
If the number is equal to or greater than the number of characters in the string, the function returns the entire string.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The string to process.  
The number of characters to return. Negative numbers and `0` return an empty string. Decimals are rounded down to the nearest whole number.  
### Example
This example returns the first five characters from a string.
#### Source
```
%dw 2.0
import first from dw::core::Strings
output application/json
---
"hello world!" first 5
```

## first(text: Null, amount: Any): Null
Helper function that enables `first` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
OAuth2 Provider Module | MuleSoft Documentation
# OAuth2 Provider Module
OAuth2 Provider Module v1.0
The OAuth2 Provider module enables a Mule runtime engine (Mule) app to be configured as an Authentication Manager in an OAuth2 dance. With this role, the application can authenticate to previously registered clients, grant tokens, validate tokens, or register and delete clients, all during the execution of a flow.
The following documentation assumes a basic knowledge of the OAuth2 authorization protocol. For further reference, see the RFC-6749.
If the app behaves as the client in the OAuth2 dance, use the OAuth Module instead.
## Before You Begin
To use this module, 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)


## Using Exchange Templates and Examples
Anypoint Exchange provides templates that you can use as starting points for your apps and examples that illustrate a complete solution.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Tokenization Service Logs | MuleSoft Documentation
# Tokenization Service Logs
To determine traffic counts, use the tokenization summary message that is returned in Runtime Fabric logs. To retrieve the logs, configure log forwarding in Runtime Fabric.
The log tag entry is `rtfTokenizationStatistics`, and the stats are a JSON string. Logs are rendered every one minute at a forced log entry of RTC `INFO` level, which is not subject to log level settings.
Failure counts are incremented only for actual tokenization and de-tokenization failures. Other failures, such as protocol errors in the requests, do not count towards the failure statistics. An example of a failure is an unknown token string that can’t be de-tokenized.
Counts are cumulative from the start of each individual pod (replica) until its death.
Example tokenization summary message:
```
<logEntry>
<header>
<time>2018-11-12T14:55:00.009667</time>
<node>icvlab11401</node>
<logType>RTC_BASE_MGMT</logType>
<logLevel>INFO</logLevel>
<process>WorkflowTest</process>
<pid>16766</pid>
<tid>16775</tid>
<file>cbrsrc/cbrcore/src/rtc/embedded/wfp/WfpTokenizationStatistics.cpp</file>
<line>98</line>
</header>
<body><rtfTokenizationStatistics>{"tokenizationStatistics":{"node":"icvlab11401","timestamp":"2018-11-12T20:55:00.009Z","tokenizeSuccess":2,"deTokenizeSuccess":6,"tokenizedBytes":6,"deTokenizedBytes":32,"tokenizeFailure":2,"deTokenizeFailure":2,"tokenizeFailedBytes":5,"deTokenizeFailedBytes":0}}</rtfTokenizationStatistics></body>+
</logEntry>
```

```
{
 "tokenizationStatistics":{
  "node":"icvlab11401",
  "timestamp":"2018-11-12T20:55:00.009Z",
  "tokenizeSuccess":2,
  "deTokenizeSuccess":6,
  "tokenizedBytes":6,
  "deTokenizedBytes":32,
  "tokenizeFailure":2,
  "deTokenizeFailure":2,
  "tokenizeFailedBytes":5,
  "deTokenizeFailedBytes":0
 }
}
```

## Tokenization Audit Logging
Audit logs are generated when a tokenization or detokenization request is initiated. To enable audit logs, select the **Enable Audit Logs** setting.
Audit logs contain:
  * Client IP address
  * Operation (tokenization or detokenization)
  * Format used
  * Timestamp
  * Correlation_id
  * Success or failure status


Example tokenization audit log:
```
<logEntry><header><time>2019-06-21T00:29:29.187995</time><node>defaulttokservice-tokenizer-55546c57f9-f8t7h</node><process>securityfabric-tokenizer-runtime</process><pid>34</pid><transId>657988989747200</transId></header><body><anypointSecurityTokenizationAuditing>{"client":"10.244.60.9","correlation_id": "bf4d3684-9ada-4931-9815-7c36ef98fdf4","operation": "detokenization", "details": [
{"format":"socialSecurityNumber","success":1,"failure":0}
]}</anypointSecurityTokenizationAuditing></body></logEntry>
```

For security reasons, neither the confidential data nor the token are logged.
## See Also
Runtime Fabric documentation
Arrays (dw::core::Arrays) | MuleSoft Documentation
# Arrays (dw::core::Arrays)
This module contains helper functions for working with arrays.
To use this module, you must import it to your DataWeave code, for example, by adding the line `import * from dw::core::Arrays` to the header of your DataWeave script.
## Functions
Name | Description  
---|---  
Counts the elements in an array that return `true` when the matching function is applied to the value of each element.  
Breaks up an array into sub-arrays that contain the specified number of elements.  
Drops the first `n` elements. It returns the original array when `n <= 0` and an empty array when `n > sizeOf(array)`.  
Drops elements from the array while the condition is met but stops the selection process when it reaches an element that fails to satisfy the condition.  
Returns `true` if every element in the array matches the condition.  
Returns the first element that satisfies the condition, or returns `null` if no element meets the condition.  
Returns the index of the first occurrence of an element within the array. If the value is not found, the function returns `-1`.  
Returns the index of the first occurrence of an element that matches a condition within the array. If no element matches the condition, the function returns `-1`.  
Joins two arrays of objects by a given ID criteria.  
Joins two arrays of objects by a given ID criteria.  
Joins two array of objects by a given `ID` criteria.  
Separates the array into the elements that satisfy the condition from those that do not.  
Selects the interval of elements that satisfy the condition: `from <= indexOf(array) < until`  
Returns `true` if at least one element in the array matches the specified condition.  
Splits an array into two at a given position.  
Splits an array into two at the first position where the condition is met.  
Returns the sum of the values of the elements in an array.  
Selects the first `n` elements. It returns an empty array when `n <= 0` and the original array when `n > sizeOf(array)`.  
Selects elements from the array while the condition is met but stops the selection process when it reaches an element that fails to satisfy the condition.
Migrating API Gateways: Autodiscovery | MuleSoft Documentation
# Migrating API Gateways: Autodiscovery
The Autodiscovery element was updated after Mule 4 release.
  * APIs are referenced by an ID instead of a name and version.
  * Creation of APIs from the runtime is no longer possible.


Simple Mule app with an HTTP listener and an Autodiscovery element defined:
Mule 3 Example: All Configurable Attributes
```
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:api-platform-gw="http://www.mulesoft.org/schema/mule/api-platform-gw"
   xmlns:http="http://www.mulesoft.org/schema/mule/http"
   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/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
    http://www.mulesoft.org/schema/mule/api-platform-gw http://www.mulesoft.org/schema/mule/api-platform-gw/current/mule-api-platform-gw.xsd">
  <api-platform-gw:api id="apiId" create="true" apiName="name" version="1.0.0" flowRef="flow_api">
    <api-platform-gw:description>This is a test API</api-platform-gw:description>
    <api-platform-gw:tag>tag1</api-platform-gw:tag>
    <api-platform-gw:tag>tag2</api-platform-gw:tag>
  </api-platform-gw:api>
  <http:listener-config name="httpConfig" host="localhost" port="${port}" />
  <flow name="flow_api">
    <http:listener config-ref="httpConfig" path="api" />
    <logger message="Executing empty" level="INFO"/>
  </flow>
</mule>
```

Mule 4 Example: All Configurable Attributes
```
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:http="http://www.mulesoft.org/schema/mule/http"
   xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway"
   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/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
    http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd">
  <api-gateway:autodiscovery apiId="1" flowRef="flow_api" />
  <http:listener-config name="httpConfig" basePath="api">
    <http:listener-connection host="localhost" port="${port}"/>
  </http:listener-config>
  <flow name="flow_api">
    <http:listener config-ref="httpConfig" path="api" />
    <logger message="Executing empty" level="INFO"/>
  </flow>
</mule>
```

## See Also
Migrating API Gateways
Migrating API Gateways: Policies
Migrating API Gateways: Mule Runtime Configuration
ERP Docs with AWS | MuleSoft Documentation
# ERP Docs with AWS
The ERP Docs with AWS enables you to use Amazon Textract to analyze invoices and receipts to extract relevant data.
This action step processes the document in a synchronous fashion (Amazon does not store the document) and automatically converts PDF files to PNG images. You can adjust the fidelity of the conversion in the properties grid.
## Inbound Variables
  * **Directory Path**
  * **File Name**
  * **Password**
  * **Read text from page**
  * **Read text to page**
  * **AWS Credentials**
Or, if **Use custom settings** is activated in the wizard:
    * **Client Id**
    * **Client Secret**
    * **Session Token**
    * **Use Session Token**
    * **Region Endpoint**
  * **Json Path**


## Outbound Variables
  * **Raw Text**
The extracted raw text of the document.
  * **Normalized Json**
The parsed result based on the normalized result and defined Json path.
  * **Raw Json**
The complete AWS response.


## Wizard
  * **Authentication Settings**
The AWS credentials to use for authentication
    * **Pin credentials**
Use this option to reference an existing **Credentials for AWS** configuration.
    * **Use custom settings**
Use this option to manually specify an AWS **Cliend ID** , **Client Secret** , **Region Endpoint** , and **Session Token** for this action step.
  * **Response settings**
    * **JsonPath Expression**
The Json path to the property of the response object.
  * **File Settings**
    * **Directory path**
The path to the directory where the file is located.
    * **File name**
The name of the file to analyze. Supported file types: PDF, JPEG, and PNG.
  * **PDF Settings**
These settings show when the selected file is a PDF.
    * **Automatically detect the best quality for conversion**
Disable this option to manually adjust the image quality.
    * **Image Quality**
Specifies the quality of the image created from the PDF. The value ranges from `10` (lowest quality) to `100` (highest quality).
This property is not available in the Wizard.
    * **PDF file is password protected**
Specifies if the selected PDF file is password protected. When selected, specify the password to open the file in the **Password to open PDF file** filed.
    * **Read entire file**
Instructs the service to read the entire file.
    * **Read page range**
Instructs the service to read the selected range of pages.
      * **From page**
Specify from which page the service starts reading the file.
      * **To page**
Specifies until which page the service reads the file.
      * **Read to end of file**
Instructs the service to continue reading until the end of the file.


## See Also
  *   * Amazon Textract: Analyzing Invoices and Receipts
  * Building JSONPath Expressions