BassemE/mulesoft-documentation-embeddings huggingface dataset:
Finding Information in a PDF | MuleSoft Documentation
# Finding Information in a PDF
First, you need to find the order ID in the PDF.
As you can see in the image of the order confirmation letter, the order ID is always listed in a table next to the entry 'Order ID'. You can use this information to implement the workflow that contains the following steps:
  1. Copy the content of the order confirmation to a text file.
  2. Read the text file line by line to find the one containing the order ID.
  3. Check if the order ID is found.
  4. Cut out the order ID from the text and store it in an activity parameter.


## 1. Copying Text From a PDF to a Text File
To open the PDF, you use the **Read PDF file** action step. Then, you use the returned `ReadText` as input for the **Write to Text File** to save the content as a text file on your computer.
The following image shows the result of storing the text content. Each line of the PDF has a corresponding line in the text file. Images are omitted.
## 2. Looping Over All Lines of a Text File
To loop over all lines of the text file, you first need to count the number of lines by reading the entire file using the action step **Read from Text File**. You use the returned `line count` as the maximum value for the iteration counter. The counter also functions as the number of the line to read with **Read from Text File** in each iteration.
## 3. Checking a Case and Catching Errors
Because you don’t know which line contains the order ID, you use **Select Case** to differentiate between the two possibilities. If you find the order ID, you copy it from the text and store it in the activity parameter `order_id`. If you didn’t, which happens in each other line, you still want to complete the loop and the workflow and use **Force OK State** to avoid returning an error.
The criteria for deciding whether you found the order ID is that the string `Order ID` is part of the current line.
## 4. Retrieving a Substring and Saving It to a Variable
Because you know that the order ID is written after the text `Order ID`, you can remove these first nine characters from the current line (which contains the substring `Order ID`) by using the **Trim left (remove first characters)** operations of the **String Operations** action step. The rest of the string is the order ID. You store it in the Activity Parameter with the same name by using the result of the string operation as a Pin Variable in the **Set Variable** action step.
## See Also
  * RPA Builder Action Step: Read PDF File
  * RPA Builder Action Step: Write to Text File
  * RPA Builder Action Step: Read from Text File
  * RPA Builder Action Step: Select Case
  * RPA Builder Action Step: Force OK State
  * RPA Builder Action Step: String Operations
  * RPA Builder Action Step: Set Variable
encodeURI | MuleSoft Documentation
# encodeURI
## encodeURI(text: String): String
Encodes a URI with UTF-8 escape sequences.
Applies up to four escape sequences for characters composed of two "surrogate" characters. The function assumes that the URI is a complete URI, so it does not encode reserved characters that have special meaning.
The function _does not encode these characters_ with UTF-8 escape sequences:
Type (not escaped) | Examples  
---|---  
Reserved characters | ; , / ? : @ & = $  
Unescaped characters | alphabetic, decimal digits, - _ . ! ~ * ' ( )  
### Parameters
Name | Description  
---|---  
The URI to encode.  
### Example
This example shows encodes spaces in one URL and lists some characters that do not get encoded in the `not_encoded` string.
#### Source
```
%dw 2.0
import * from dw::core::URL
output application/json
---
{
  "encodeURI" : encodeURI("http://asd/ text to decode /text"),
  "not_encoded": encodeURI("http://:;,/?:@&=\$_-_.!~*'()")
}
```

#### Output
```
{
  "encodeURI": "http://asd/%20text%20to%20decode%20/%25/\"\'/text",
  "not_encoded": "http://:;,/?:@&=$_-_.!~*'()"
}
```
Upgrading Message Flow Runtime Templates | MuleSoft Documentation
# Upgrading Message Flow Runtime Templates
Anypoint Partner Manager uses prebuilt templates to convert your B2B message flow configurations into generic runtime applications. As these templates are updated, you can upgrade your message flows to use them to take advantage of new capabilities that enable better integration with your partner’s ecosystem.
Runtime templates related to Partner Manager are upgraded when:
  * A new feature or functionality is added
  * A component on which your environment is dependent, such as a connector version, is upgraded
  * A security vulnerability is fixed
  * Functional and performance defects are resolved in the template
  * Flow optimizations are implemented


When new runtime templates are available, a tooltip shows on the **Manage deployments** button to indicate there’s a new version available.
To take advantage of new features, click **Manage deployments** , select **Upgrade deployments** , confirm that you understand the effects of these actions, and then click **Confirm**.
Upgrading deployments updates all the Mule applications in your runtime with the latest template versions that contain new features or bug fixes.
The process of updating all your message flows can take several minutes, depending on the number of message flow configurations and runtime applications in your environment. Your existing message flows continue uninterrupted during the upgrade process.
Before upgrading your production environment, upgrade your nonproduction environments to test the changes on some of your message flows.
## See Also
  * Deploying and Testing Message Flows
Specification Conformance | MuleSoft Documentation
# Specification Conformance
You can check for API specification conformance using a custom or MuleSoft-provided ruleset such as:
  * Anypoint Best Practices
  * Authentication Security Best Practices
  * OpenAPI Best Practices
  * AsyncAPI Best Practices
  * Required Examples


See Finding and Fixing Conformance Issues for an overview of ways to validate conformance and determine why conformance failed.
## Validate API Specifications Against Rulesets
You can validate specifications against rulesets within the context of your API project regardless of whether your API is centrally governed through Anypoint API Governance. Developers or implementors typically do this either to proactively identify conformance issues or to review issues they’re notified about.
For detailed information about validating specifications against rulesets, see:
  * Anypoint Code Builder: Validating API Specifications Against Governance Rulesets
  * Design Center: Ruleset Dependencies
  * Anypoint CLI: governance:api:validate


## Fix Conformance Issues
After you identify conformance issues in your specification, you can fix the issues using your IDE and publish the new version of the specification to Exchange.
For detailed information about fixing API conformance issues, see:
  * Anypoint Code Builder: Fix Conformance Issues
  * Design Center: Ruleset Dependencies in the Design Center documentation


## See Also
  * Monitoring API Conformance
indexOf | MuleSoft Documentation
# indexOf
## indexOf<T>(array: Array<T>, toFind: T): Number
Returns the index of the first occurrence of an element within the array. If the value is not found, the function returns `-1`.
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
The array of elements.  
The element to find.  
### Example
This example returns the index of the matching value from the input array. The index of `"Julian"` is `2`.
#### Source
```
%dw 2.0
import * from dw::core::Arrays
output application/json
var users = ["Mariano", "Leandro", "Julian"]
---
indexOf(users, "Julian")
```
Maven Settings Files in Anypoint Code Builder | MuleSoft Documentation
# Maven Settings Files in Anypoint Code Builder
Cloud IDE 
Desktop IDE 
Anypoint Code Builder relies on Apache Maven settings for managing Mule applications (implementation and integration projects) and API specifications in design projects.
For information about the Maven file `settings.xml`, see the Maven documentation.
## Custom Location for Maven Settings File
The Apache Maven file `settings.xml` enables you to configure Maven settings, such as repositories, proxy settings, and credentials. For detailed information, see Settings Reference in the Apache Maven documentation.
To change the default path to your Maven `settings.xml` directory, set the `maven.settings` or `M2_REPO` system property.
To locate `settings.xml`, the IDE first checks for a `maven.settings` configuration. If the property specifies a path, the IDE uses the `settings.xml` file at that path. If `maven.settings` doesn’t specify a path or if the file isn’t present at that path, the IDE checks for `settings.xml` within the path set by the `M2_REPO` classpath variable (for example, `M2_REPO/settings.xml`). If `settings.xml` isn’t found at that path, the IDE creates an empty `settings.xml` file in the default location, `${user.home}/.m2/repository`.
## Anypoint Code Builder Settings File
Anypoint Code Builder doesn’t make changes to your Maven `settings.xml` file. Instead, when you open the IDE, a separate settings file, `acb_settings.xml`, is created if the Anypoint Extension Pack is installed in the IDE. The extension pack is preinstalled in the cloud IDE, but you must install it to the desktop IDE. See Set up the Desktop IDE.
Updates that you save to your `settings.xml` are reflected automatically within `acb_settings.xml`. The `acb_settings.xml` file is located in `${user.home}/AnypointCodeBuilder/maven`. When troubleshooting a project in Anypoint Code Builder, you can export the file with any sensitive information, such as passwords, obfuscated. To export, see Export Troubleshooting Information.
## See Also
  * Export Troubleshooting Information
Salesforce Marketing Cloud REST Connector 1.0 | MuleSoft Documentation
# Salesforce Marketing Cloud REST Connector 1.0
Anypoint Connector for Salesforce Marketing Cloud REST (Salesforce Marketing Cloud REST Connector) enables you to integrate with the Salesforce Marketing Cloud marketing platform. This connector exposes operations provided by the Salesforce Marketing Cloud REST API.
For information about compatibility and fixed issues, refer to the Salesforce Marketing Cloud REST Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Salesforce Marketing Cloud REST API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have:
  * Credentials to access the Salesforce Marketing Cloud REST target resource
  * Anypoint Platform
  * Anypoint Studio version 7.3.5 or later


## Connection Types
Salesforce Marketing Cloud REST connections use the OAuth Client Credentials authentication type, which enables a client to use its own credentials.
## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Salesforce Marketing Cloud REST Connector Reference
  * MuleSoft Help Center
Commerce Cloud B2C Shop Connector 2.1 - XML and Maven Support | MuleSoft Documentation
# Commerce Cloud B2C Shop Connector 2.1 - 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.
When 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/commerce-cloud-shopper-api
http://www.mulesoft.org/schema/mule/commerce-cloud-shopper-api/current/mule-commerce-cloud-shopper-api.xsd
```

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

## 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>commerce-cloud-shopperapi</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace the contents of the `<version>` tag 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 `Commerce Cloud B2C Shop Connector`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## Next Step
After completing your namespace and `pom.xml` file, you can try the Examples.
## See Also
MuleSoft Help Center
slice | MuleSoft Documentation
# slice
## slice<T>(array: Array<T>, from: Number, until: Number): Array<T>
Selects the interval of elements that satisfy the condition: `from <= indexOf(array) < until`
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
The array of elements.  
The starting index of the interval of elements to include from the array. If this value is negative, the function starts including from the first element of the array. If this value is higher than the last index of the array, the function returns an empty array (`[]`).  
The ending index of the interval of elements to include from the array. If this value is higher than the last index of the array, the function includes up to the last element of the array. If this value is lower than the first index of the array, the function returns an empty array (`[]`).  
### Example
This example returns an array that contains the values of indices 1, 2, and 3 from the input array. It excludes the values of indices 0, 4, and 5.
#### Source
```
%dw 2.0
import * from dw::core::Arrays
output application/json
var arr = [0,1,2,3,4,5]
---
slice(arr, 1, 4)
```

#### Output
```
[
 1,
 2,
 3
]
```

## slice(array: Null, from: Any, until: Any): Null
Helper function that enables `slice` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
Accessing Policy Metadata | MuleSoft Documentation
# Accessing Policy Metadata
PDK exposes a `Metadata` injectable that provides metadata about the policy, the Flex instance, the API instance, and the Anypoint Organization. The `Metadata` struct is as follows:
```
pub struct Metadata {
  pub flex_metadata: FlexMetadata,
  pub policy_metadata: PolicyMetadata,
  pub api_metadata: ApiMetadata,
  pub platform_metadata: PlatformMetadata,
}
```

The `Metadata` struct references the following structures:
  * `FlexMetadata`:
```
pub struct FlexMetadata {
  pub flex_name: String,
  pub flex_version: String,
}
```

  * `PolicyMetadata`:
```
pub struct PolicyMetadata {
  pub policy_name: String,
  pub policy_namespace: String,
}
```

  * `ApiMetadata`:
```
pub struct ApiMetadata {
  pub id: Option<String>,
  pub name: Option<String>,
  pub version: Option<String>,
  pub slas: Option<Vec<ApiSla>>, // API SLA tiers in the platform
}
// Each ApiSla contains the limits for each SLA.
pub struct ApiSla {
  pub id: String,
  pub tiers: Vec<Tier>, // Limits within an API SLA tier in the platform
}
```

  * `PlatformMetadata`:
```
pub struct PlatformMetadata {
  pub organization_id: String,
  pub environment_id: String,
  pub root_organization_id: String,
}
```



## Inject Metadata into the #[entrypoint]
To inject metadata into the `#[entrypoint]` configuration function, see the following code snippet:
```
#[entrypoint]
async fn configure(launcher: Launcher, metadata: Metadata) -> Result<()> {
  logger::info!("Flex instance name is: {}", metadata.flex_metadata.flex_name.to_string());
  launcher
    .launch(on_request(filter))
    .await?;
  Ok(())
}
```

## Inject Metadata into the Wrapped Functions
You cannot directly inject metadata into the wrapped functions. To use metadata in the wrapped functions, first inject the data into the `#[entrypoint]` function and then the wrapped function:
```
#[entrypoint]
async fn configure(launcher: Launcher, metadata: Metadata) -> Result<()> {
  launcher
    .launch(on_request(|r| request_filter(r, &metadata)))
    .await?;
  Ok(())
}
async fn request_filter(_: RequestState, metadata: &Metadata) -> Flow<()> {
  let mut vec = Vec::new();
  let headers = &mut vec;
  headers.push((
    "flex_name".to_string(),
    metadata.flex_metadata.flex_name.to_string(),
  ));
  headers.push((
    "policy_name".to_string(),
    metadata.policy_metadata.policy_name.to_string(),
  ));
  Flow::Break(Response::new(201).with_headers(vec))
}
```

## See Also
  *
Autocataloging APIs Using API Catalog CLI | MuleSoft Documentation
# Autocataloging APIs Using API Catalog CLI
API Catalog CLI enables you to discover and catalog your API definitions, documentation files, and associated metadata as part of an automated process. You can embed the publish asset command in your automation tools, such as a CI/CD pipeline or custom scripts, to automatically trigger the publishing of your API assets to Exchange. API Catalog CLI is agnostic of CI/CD tools and runtime environments.
With API Catalog CLI you can:
  * Identify all APIs in a project directory structure and create a descriptor file to use to publish the APIs to Exchange.
  * Identify all new and changed APIs and update the descriptor file on an ongoing basis.
  * Conditionally trigger the publish based on criteria such as branches and tags.
  * Conditionally set the asset version strategy based on criteria such as branches and tags.
  * Publish APIs described in the descriptor file by running commands either at a command prompt or as part of your CI/CD pipelines or custom scripts.


## Supported APIs
The API Catalog CLI supports:
  1. Event-driven APIs (AsyncAPI 2.0 JSON and AsyncAPI 2.0 YAML format)
  2. REST APIs (OAS 2.0 JSON, OAS 2.0 YAML, OAS 3.0 JSON, OAS 3.0 YAML, RAML 0.8, and RAML 1.0 format)


## API Catalog CLI Concepts
Review the following concepts before using API Catalog CLI.
### Descriptor File
A descriptor file has the metadata Exchange needs to catalog a set of APIs within a directory and its subdirectory structure. This file’s schema supports metadata specific to API Catalog CLI and can include in-line or referenced metadata from `exchange.json` files.
### Trigger Conditions
Trigger conditions are set in descriptor files to enable the automated publication process to determine which APIs to publish during a run of the API Catalog CLI `publish-assets` command using the `--trigger-criteria` flag.
### Version Strategy Conditions
Version strategy conditions are set in descriptor files to enable the automated publication process to determine the version strategy for APIs during a run of the API Catalog CLI `publish-assets` command using the `--version-strategy-criteria` flag.
## See Also
  * Getting Started with API Catalog CLI
  * Creating or Updating Descriptor Files Using the CLI
  *
RPA Recorder Overview | MuleSoft Documentation
# RPA Recorder Overview
RPA Recorder is MuleSoft’s tool for recording a business process.
RPA Recorder enables you to:
  * Record actions like mouse clicks, keyboard inputs on your system or on a web browser, and used applications
  * Add comments and variable information during the recording
  * Take screenshots automatically per mouse click, or manually at any time


You can start RPA Recorder either directly from RPA Manager in the design phase, or as a standalone tool without server connection.
  * If started from RPA Manager, RPA Recorder automatically uploads the recorded BPMN process model with the documentation into the server, and creates a local PDF with the same information after the recording is finished.
  * If used without server connection, RPA Recorder creates the BPMN and stores it locally.


In either case, RPA Recorder also creates an XES file for further processing in process mining tools.
upper | MuleSoft Documentation
# upper
## upper(text: String): String
Returns the provided string in uppercase characters.
### Parameters
Name | Description  
---|---  
The string to convert to uppercase.  
### Example
This example converts lowercase characters to uppercase.
#### Source
```
%dw 2.0
output application/json
---
{ "name" : upper("mulesoft") }
```

#### Output
```
{ "name": "MULESOFT" }
```

## upper(value: Null): Null
Helper function that enables `upper` to work with a `null` value.
Upgrading and Migrating FTP Connector to Version 2.0 | MuleSoft Documentation
# Upgrading and Migrating FTP Connector to Version 2.0
Upgrade Anypoint Connector for FTP (FTP Connector) to version 2.x.
## Supported Upgrade Paths
From Version | To Version  
---|---  
## Changes in This Release
This release contains the following changes:
  * The `mule-file-commons` module dependency is removed to make FTP Connector a standalone connector.
  * The **List** operation now returns the file path instead of the file content.
  * The **List** operation no longer includes the **Time Between Size Check** and **Time Between Size Check Unit** fields because the file content is no longer read.


## Requirements
Ensure that you meet these requirements before you perform the upgrade:
Application/Service | Version  
---|---  
4.3.0 and later  
## Upgrade Prerequisites
Before you perform the upgrade, create a backup of your files, data, and configuration in case you need to restore to the previous version.
## Upgrade Steps
Follow these steps to perform the upgrade:
  1. In Anypoint Studio, create a Mule project.
  2. In **Mule Palette** , click **Search in Exchange**.
  3. In **Add Dependencies to Project** , enter `ftp` in the search field.
  4. In **Available modules** , select **FTP** and click **Add**.
  5. Click **Finish**.
  6. Verify that the FTP Connector dependency version is 2.0 in the `pom.xml` file in the Mule project.


Studio upgrades the connector automatically.
## Post-Upgrade Steps
After you install the latest version of the connector, verify that your error handling is updated to work with the minor changes in error codes in this version of the connector.
## Verify the Upgrade
After you install the latest version of the connector, follow these steps to verify the upgrade:
  1. In Studio, verify that there are no errors in the **Problems** or **Console** views.
  2. Verify that there are no problems in the project `pom.xml` file.
  3. Test the connection to verify that the operations work.


## Revert the Upgrade
If it is necessary to revert to the previous version of FTP Connector, change the `mule-ftp-connector` dependency version in the project’s `pom.xml` file to the previous version.
You must update the project’s `pom.xml` file in Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Zoom Connector | MuleSoft Documentation
# Zoom Connector
Anypoint Connector for Zoom (Zoom Connector) enables you to access the Zoom API.
For information about compatibility and fixed issues, refer to the Zoom Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Zoom 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:
  * Credentials to access the Zoom target resource
  * Anypoint Platform
  * Anypoint Studio version 7.3.5 or later


## Connection Types
Zoom connections use the following authentication types:
  * Client Credentials Config
    * Client Credentials Connection Provider
  * Zoom Connector Configuration
    * Bearer Connection Provider
    * Oauth Connection Provider


## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Zoom Connector Reference
  * MuleSoft Help Center
Submit Form | MuleSoft Documentation
# Submit Form
This _Web Automation_ object allows you to submit a form on a webpage. It will work on any field contained within a form and submit the whole form.
## Properties
**Webelement Find Options**
  * **Screenshot The recorded screenshot is displayed here.**
  * **Use Regex to find Window (Enable Regex) Use this function if you want to use Regex when searching the window.**


Other Properties that are the same in all action steps in the _Web Automation_ are described in the section on **Common Properties**. For reasons of clarity they are not shown here.
## Inbound Variables
**Element XPath**
**Window Title**
## Outbound Variables
The action step _Submit Form_ possesses no outbound variables.
## Wizard
Forms are often used on websites to collect various data. The most common example would be a registration form to get an account to log in to a website. _Submit Form_ is a very simple-to-use tool that allows you to transfer the required data. Just define an element XPath to identify the form that you want to submit.
You do not have to use the submit button to start transferring the data; modifying any of the fields contained in the form is sufficient.
To Access the EU Control Plane | MuleSoft Documentation
# To Access the EU Control Plane
This topic describes how to access Anypoint Platform in the EU control plane.
Anypoint Platform account data is not shared between the US and EU control planes. Even if you have an account in the US control plane, you must create a new account in the EU control plane.   
---  
  1. Go to the following URL:
```
eu1.anypoint.mulesoft.com
```

  2. If you do not have an Anypoint Platform account in the EU control plane, click Sign Up.
    1. Enter your personal information. All fields are required.
    2. Choose a username.
    3. Choose a password, then click Create Account
  3. Enter your username and password, then click Sign In.


## See Also
  * EU Control Plane
Copy and Move Files with the SFTP Connector Example | MuleSoft Documentation
# Copy and Move Files with the SFTP Connector Example
Anypoint Connector for SFTP (SFTP Connector) **Copy** and **Move** operations enable you to copy and move files or directories on demand.
While SFTP has a native concept of copying and moving, FTP does not. FTP Connector simulates these operations by downloading file content and writing it to a new location, using concurrent streams that start writing and reading at the same time. Because these operations create significant network overhead, use them wisely. Note that the SFTP Connector **Move** operation does not impact network overhead.
## Configure the Copy Operation in Studio
To add and configure the **Copy** operation in Studio, follow these steps:
  1. In the **Mule Palette** view, search for `sftp` and select the **Copy** operation.
  2. Drag the **Copy** operation onto the Studio canvas.
  3. In the **General** tab of the operation configuration screen, click the plus sign (**+**) next to the **Connector configuration** field to access the global element configuration fields.
  4. Specify the connection information and click **OK**.
  5. Set the **Source path** field to the path of the file to copy, for example, `source.txt`.
  6. In the **Target path** field, enter the directory path into which to copy the file, for example, `backup`.
  7. Set the **Rename to** field to rename the file as part of the operation, for example, `renamed.txt`. This field must be a filename, not a path. If this attribute is not provided, the original filename is used.


In the **Configuration XML** editor, the `<sftp:copy>` configuration looks like this:
```
<sftp:copy sourcePath="source.txt"
 targetPath="backup" overwrite="true|false"
 createParentDirectories="true|false"
 renameTo="renamed.txt"/>
```

## Configure the Move Operation in Studio
To add and configure the **Move** operation in Studio, follow these steps:
  1. In the **Mule Palette** view, search for `sftp` and select the **Move** operation.
  2. Drag the **Move** operation onto the Studio canvas.
  3. In the **General** tab of the operation configuration screen, click the plus sign (**+**) next to the **Connector configuration** field to access the global element configuration fields.
  4. Specify the connection information and click **OK**.
  5. Set the **Source path** field to the path of the file to move, for example, `source.txt`.
  6. In the **Target path** field, enter the directory path into which to move the file, for example `backup`.
  7. Set the **Rename to** field to rename the file as part of the operation, for example, `renamed.txt`. This field must be a filename, not a path. If this attribute is not provided, the original filename is used.


In the **Configuration XML** editor, the `<sftp:move>` configuration looks like this:
```
<sftp:move sourcePath="source.txt"
 targetPath="backup" overwrite="true|false"
 createParentDirectories="true|false"
 renameTo="renamed.txt"/>
```

## See Also
  * SFTP Connector Examples
  * MuleSoft Help Center
Google Pub/Sub Connector 1.0 | MuleSoft Documentation
# Google Pub/Sub Connector 1.0
Anypoint Connector for Google Pub/Sub (Google Pub/Sub Connector) enables you to access the Google Pub/Sub messaging platform. This connector exposes operations provided by the Google Pub/Sub client libraries.
For compatibility information and fixed issues, refer to the Google Pub/Sub Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Google Pub/Sub 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 target resource
  * Anypoint Studio version 7.3.5 or later


## Common Use Cases for the Connector
Some common use cases for Google Pub/Sub Connector include:
  * Publishing messages
  * Listening to messages
  * Managing snapshots
  * Replaying messages


## Authentication Types
Google Pub/Sub Connector uses the PubSub Connection authentication method, in which you create a service account and obtain credentials. For more information, refer to Google Cloud Service Accounts.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Google Pub/Sub Connector Reference
  * MuleSoft Help Center
Set Array Variable | MuleSoft Documentation
# Set Array Variable
The Set Array Variable action step enables you to assign new values to an array.
One possible use is to copy a list to an array in order to iterate through all elements in the list more easily and to process individual list elements further.
## Properties
The _Set Array Variable_ action step contains no other properties other than the _general_ ones.
## Inbound Variables
**Array to change** (Array) Array in which values are to be changed.
The array must have previously been created as a _Workflow Based Variable_ or using _Read from Excel File_.
Please make sure that arrays are named according to their content. This makes a Workflow easier to understand.
It is preferable to create an extra array in the _Workflow Based Variables_ rather than to overwrite an array created using the _Read from Excel File_ action step with different values.
**New array value** (array or alphanumeric) Values to overwrite the entire array.
The entire array is rewritten with the given values. The former values are deleted.
By changing the values it is possible to also change the number of elements in the array (_Array Count_).
## Outbound Variables
The _Set Array Variable_ action step possesses no outbound variables.
## Wizard
The _Array to change_ is the array with values to be overwritten. You can select it from a drop-down list if such an array already exists.
The _New array value_ is the new values for overwriting the array. You can include them via a Pin Variable or enter them directly as a list of comma separated values in the relevant field.
The elements for array variables must be separated by commas.
The values for array variables are initially saved as strings. That is why, when saving the action step, all array elements which are not yet presented in double quotes will automatically be placed in double quotes.
If you want to include an element containing one or more commas in your list, you must place this element in double quotes before saving it.
E.g. “4,2” or “many commas: ,,,, , , ”
Text elements are permitted to contain single quotes:
E.g. “This ‘text’ contains single quotation marks.”
Text elements which need to contain double quotes must include another double quotation mark before each double quotation mark and the whole element also needs to be placed inside double quotes.
E.g. “This “”text”” contains double quotation marks.”
## Example
Car servicing is to be automated at a workshop.
For testing purposes, the array _Services_ , which is generated via the _Workflow Based Variables_ and which contains the services actually performed, can be pre-populated with values. Further on in the Workflow, services are read from a scanned-in form, e.g. using _OCR_ , and the array _Services_ in the _Set Array Variable_ action step is overwritten with the actual values.
Viewing Status Updates in Anypoint DataGraph | MuleSoft Documentation
# Viewing Status Updates in Anypoint DataGraph
When working with APIs and the unified schema, status updates let you know when the unified schema is available for querying, when changes to the unified schema have taken effect, and which API schemas are getting added, removed, or updated.
## Status: Updating
You can add to and update the unified schema at any time. After you apply changes, the status reads **Updating** and indicates the progress and queued updates. This status update is visible to anyone in your business group who has permissions for the environment.
When the unified schema is updating, you can view the new changes in the schema, make additional changes, and apply new changes. However, these changes aren’t available to query until the update is complete.
As queued updates finish, the status changes to **finished**.
When all updates are complete, the status changes to **Up to date**.
## Status: On hold
In the case that Anypoint DataGraph is unreachable, the status will change to **On hold**. If you were attempting any changes, Anypoint DataGraph will automatically apply those changes when it’s available, and the status will change to **Updating** , with details of which APIs are being added, removed, or updated.
When the status is **On hold** , you can continue to browse the unified schema and source list, but you can’t make any edits. You can also run queries against the previously deployed unified schema.
## Fixing Update Conflicts
As you make changes to existing API schemas or add them to the unified schema, Anypoint DataGraph automatically updates the unified schema’s metadata. This happens instantaneously, and the updated metadata is stored near real-time.
You may, however, encounter rare cases when there are errors with the metadata—for example, when another contributor applies a conflicting change at the same time. In such cases, you must ensure you have the latest version of the unified schema and then re-attempt your change.
Introduction to Mule 4: Connectors | MuleSoft Documentation
# Introduction to Mule 4: Connectors
Mule 3 offered two ways of connecting to systems: transports and connectors. Transports used the concept of inbound and outbound endpoints to send data. Connectors used the concept of operations to invoke systems, for example, `<http:request>` or `<db:select>`.
In Mule 3, MuleSoft started to replace some of these transports through the new HTTP and Database connectors. Mule 4 completes this change by completely standardizing the approach so that all connectivity is built as connectors. This change improves the consistency and usability of connectors, and it enables more powerful connectors.
## Independent Release Cycles for Core Connectors and Modules
Another big difference is how the connectors are shipped and released. In Mule 3, a number of connectors/transports were part of the Mule Runtime distribution (for example, File, Ftp, Sftp, HTTP, Database, JMS, XML, Validations, and so on). To get fixes and enhancements to any of these connectors, it was necessary to wait for the next Mule Runtime release. Meanwhile, other connectors (typically the SaaS connectors) were shipped and released independently (for example, Salesforce, Workday, ServiceNow, SAP, and so on).
Mule 4 standardizes the latest model. The Mule 4 distribution ships with no connectors or modules. Instead, each application includes the modules it needs. This approach has the following advantages:
  * Faster innovation in core modules/connectors because all connectors have their own release cycle. New features and bug fixes can become available without the need to wait for the next Mule Runtime release.
  * Ability for different apps to use different versions of the same module. This allows for easier adoption of new releases without the need to run a full regression on applications that don’t require the upgrade.
  * Consistent approach.
Using Third-Party Libraries | MuleSoft Documentation
# Using Third-Party Libraries
To view an example policy project that uses third-party libraries, see Crypto Policy Example.   
---  
Proxy Wasm defines a low level binary application interface (abi), that limits the system calls a library can make. All third-party libraries included in your policy must be compatible with the `wasm32-wasip1` Rust compilation target.
To define a library such as `serde_urlencoded`, add it to the dependency list in `cargo.toml`:
```
[dependencies]
...
serde_urlencoded = "0.7.0"
```

Defining libraries enables you to use functions in `lib.rs` such as:
```
serde_urlencoded::to_string([("token", "myToken")])
```

Libraries that interact with an external service like a database, or perform a system call like reading a file, are usually not compatible with the `wasm32-wasip1` target.
If your policy interacts with external services, use the Flex Gateway exposed `HttpClient`. For more information about performing an HTTP call, see Performing an HTTP Call.
It is possible that some libraries compile properly to the `wasm32-wasip1` target but don’t work properly when deployed to Flex Gateway. Example errors include:
  * `Failed to load Wasm module due to a missing import: …​`
  * `Wasm VM failed to initialize Wasm code`
  * `Plugin configured to fail closed failed to load`


In these cases, contact the owners of the third-party library, or use a different library.
## See Also
  * Implementing Your Custom Policy Features in Rust
isObjectType | MuleSoft Documentation
# isObjectType
## isObjectType(t: Type): Boolean
Returns `true` if the input is the Object type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The type to check.  
### Example
This example shows how `isObjectType` behaves with different inputs.
#### Source
```
%dw 2.0
import * from dw::core::Types
type AType = {name: String}
output application/json
---
{
  a: isObjectType(AType),
  b: isObjectType(Boolean),
}
```

#### Output
```
{
 "a": true,
 "b": false
}
```
Configure the Cache Scope | MuleSoft Documentation
# Configure the Cache Scope
  1. In your Mule app, add a Cache scope to a flow.
  2. Click to open the General tab for the Cache scope.
  3. Configure the Cache scope:
     * Provide a Display Name.
     * Select a Caching Strategy.
Examples:
       * From the UI: `My_Caching_Strategy`
       * In the Studio XML: `cachingStrategy-ref="My_Caching_Strategy"`
MuleSoft recommends that you reference a Caching Strategy that uses an ObjectStore instead of using the default in a production environment.
If you need to create a Caching Strategy, see the procedure in See Also.
  4. Opt to set up a filter for specific payloads if you need one.
Example that uses a DataWeave expression: `filterExpression="#[user.isPremium()]"`
If the message matches the expression(s), Mule executes the Caching Strategy.
If the message does not match expression(s), Mule processes the message through all message processors within the Cache scope but never saves or produces cached responses.


## Example Cache Scope Configuration
The following example shows the configuration of a Caching Strategy, which is then referenced by a Cache Scope that contains a Database Select operation and a Transform component:
```
<!-- Caching Strategy definition-->
<ee:object-store-caching-strategy name="Caching_Strategy" doc:name="Caching Strategy" />
<!-- The Database Connector config is necessary in this example because there is a Database Select operation-->
<db:config name="Database_Config" doc:name="Database Config" >
  <!-- Database Connector Configuration -->
</db:config>
<!-- Cache Scope configuration referencing the Caching Strategy-->
<ee:cache doc:name="Cache" cachingStrategy-ref="Caching_Strategy">
 <db:select doc:name="Select" config-ref="Database_Config">
  <db:sql >
   <!-- An SQL query-->
  </db:sql>
 </db:select>
 <ee:transform doc:name="Transform Message" >
  <ee:message >
   <ee:set-payload >
    <!-- A DataWeave transformation for the query results -->
   </ee:set-payload>
  </ee:message>
 </ee:transform>
</ee:cache>
```

## See Also
Set Up a Caching Strategy
MuleSoft Accelerators Overview | MuleSoft Documentation
# MuleSoft Accelerators Overview
Accelerators are a collection of technical assets (predominantly API specifications and implementation templates), reference architectures, and documentation that can be used to accelerate the implementation of multiple use cases supporting a larger business or industry problem.
Accelerators are designed as modular building blocks: customers can change the patterns, mappings, and endpoints to suit their needs. They represent best practices we recommend to customers in accomplishing these use cases. Customers will save hours of discovery, design, development, and testing each time they use an accelerator asset.
To access any of the asset links described within the following Accelerators, you must log in to Anypoint Platform.
MuleSoft Accelerator for Consumer Goods |  Helps consumer goods companies integrate their digital operations to gain visibility into trade promotion management and retail execution.  
---|---  
MuleSoft Accelerator for Data Cloud |  Enable organizations to easily unlock and connect core systems of record for Data Cloud.  
MuleSoft Accelerator for Financial Services |  Simplifies customer 360 initiatives by unlocking both core banking and insurance platforms, systems of engagement (such as CRM and ITSM), Insuretechs, and FinTech data.  
MuleSoft Accelerator for Healthcare |  Equips Payer, Provider, and Life Sciences organizations with foundational assets to accelerate their digital transformation journey.  
MuleSoft Accelerator for Life Sciences |  Helps pharmaceuticals, medical device companies, and contract research organizations (CROs) integrate digital operations and get their products to market faster.  
MuleSoft Accelerator for Manufacturing |  Equips discrete and process manufacturers with foundational assets for common use cases to accelerate their digital transformation journey.  
MuleSoft Accelerator for Salesforce OMS |  Enables you to extend and integrate Salesforce Order Management with external business partners and application ecosystems by leveraging the application and B2B integration capabilities of Anypoint Platform.  
MuleSoft Accelerator for Retail |  Empowers retail IT teams to unlock data from systems including ERP, CRM, MDM, commerce, and marketing to activate digital projects faster.  
MuleSoft Accelerator for SAP |  Enable organizations to easily expose SAP ERP data for consumption by all.  
If you have any questions or feedback, let us know at solutions-questions@mulesoft.com. You can also engage with other users on the MuleSoft Forum and submit ideas on the Salesforce Ideas Portal.
## See Also
  *   * MuleSoft Accelerators on Anypoint Exchange.
Submit Document to MuleSoft IDP | MuleSoft Documentation
# Submit Document to MuleSoft IDP
Send documents to MuleSoft IDP and process them with your published document actions. Each execution generates an execution ID that you must use when you run the Retrieve Results from MuleSoft IDP action step to query the results of said execution.
Calls to IDP from RPA Builder consume automation credits per page processed in addition to the bot minutes consumed by the RPA process. See Automation Credits Usage and Rates for conversion rates and usage details.
## Before You Begin
Before using this action step, ensure that:
  * Your Anypoint user account has the Build Actions permission.
  * You have IDP document actions published in your organization.
See Publishing Document Actions for additional information.
  * You have a connected app configured to access IDP.
See Processing Documents and Retrieving Results With RPA for configuration instructions.


## Properties
This action step has no properties other than **Common** and **Timing**. See Common Properties for further details.
## Inbound Variables
  * **Directory Path**
Path to the directory where the file to submit is located
  * **File Name**
Name of the file to submit
  * **Client ID**
Client ID of the connected app configured to call IDP
  * **Client Secret**
Client Secret of the connected app configured to call IDP
  * **Connected App Credentials**
Pin credentials containing the Client ID and Client Secret of the connected app configured to call IDP
  * **Execution ID**
Execution ID of the document processing operation
  * **Action ID**
ID of the published document action to call.
  * **Action Version**
Version of the referenced document action.
  * **Anypoint URL**
URL of the Anypoint organization that published the IDP document actions to call.
  * **Organisation ID**
ID of the Anypoint organization that published the IDP document actions to call.


## Outbound Variables
  * **ExecutionID**


## Wizard
Start by selecting the **Action** and the **Action Version** to call from IDP. These lists populate with the available document actions published by your organization in IDP.
Then, specify the **Directory path** and **File name** of the file to submit to IDP for processing with the selected document action.
Finally, specify the connected app credentials to use when connecting to IDP. Either use the previously configured Pin credentials or specify the **Client ID** and **Client Secret** manually in the wizard.
## See Also
  * Retrieve Results from MuleSoft IDP
  *