BassemE/mulesoft-documentation-embeddings huggingface dataset:
Delete an Instance of Self-Managed Flex Gateway | MuleSoft Documentation
# Delete an Instance of Self-Managed Flex Gateway
To delete a gateway and its replicas in Runtime Manager:
  1. From Anypoint Platform, select **Runtime Manager**.
  2. Select **Flex Gateways** in the navigation menu.
  3. Click the action menu button for the gateway that you want to delete.
  4. Click **Delete gateway**.


If there are APIs associated with the gateway you want to delete, Runtime Manager displays a message that prompts you to either:
  * Move the associated APIs to another gateway.
  * Delete all associated APIs.


Once you moved or deleted all the associated APIs, follow the steps previously described to delete a gateway and confirm the deletion.
## Flex Gateway Status
The following table describes the meaning of each gateway status:
Status Name | Description  
---|---  
Gateway is connected to the platform, and you can add APIs to it.  
Not Running |  Gateway is not connected to the platform.  
Gateway is in the process of being deleted.  
Gateway was deleted from the platform. It stops accepting API requests and configuration changes, and stops reporting metrics.  
Deleted gateways are shown with status `Deleted` for 30 days before the status is removed from the gateways list.
If you delete a gateway, you lose its configuration history and can’t recover it.   
---
X12 EDI Connector 2.8 | MuleSoft Documentation
# X12 EDI Connector 2.8
Anypoint Connector for X12 EDI (X12 EDI Connector) enables you to convert X12 messages to and from DataWeave-compatible representations by using lists and maps. All of the schema definitions you need for supported X12 standard transaction sets are included. For complete information about schemas, see X12 EDI Schema Language Reference.
Many Health Insurance Portability and Accountability Act (HIPAA) document versions are also supported, as listed separately in the Supported HIPAA Versions. For more information about HIPAA usage, refer to Connector HIPAA Standards.
## Before You Begin
To use this connector, you must be familiar with:
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Purchased a MuleSoft license for X12 EDI Connector.
Contact your Account Representative about purchasing a license.
  * Anypoint Studio 7.0 or later


X12 EDI Connector supports files of up to 15 MB in size, and the memory requirement is approximately 40 to 1. For example, a 1 MB file requires up to 40 MB of memory to process, so it’s important to consider this memory requirement in conjunction with your Transactions Per Second (TPS) needs for large X12 files. This is not an exact figure; the value varies according to the complexity of the mapping instructions.   
---  
## 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.
### X12 EDI Connector Templates in Exchange
Anypoint Exchange Templates provide starting points for Studio projects such as:
  * Sets up your Outbound transactions.


Map application messages to outbound EDI X12 transactions
  * Sets up your Inbound transactions.


Map inbound EDI X12 transactions to application message format
  * Use this for setting up your Partner Manager content storage.


Partner Manager Content Storage API - S3 Template
### X12 EDI Connector Examples in Exchange
X12 Connector Examples enable you to create complete Studio projects such as:
  * How to transform an X12 EDI purchase order from XML to JSON.


Transform XML to EDI X12 850 purchase orders and X12 850 to JSON
  * How to transform an Outbound purchase order.


Transform outbound purchase order XML messages to EDI X12 850 transactions
  * How to transform an Inbound purchase order.


Transform inbound EDI X12 850 transactions to Purchase Order JSON
## Next Step
After you complete the prerequisites, you are ready to create your own app and configure the connector using Anypoint Studio.
## See Also
Introduction to Anypoint Connectors
Use Exchange to Discover Connectors, Templates, and Examples
MuleSoft Help Center
Configure the Last Will and Testament Messages for MQTT Connector | MuleSoft Documentation
# Configure the Last Will and Testament Messages for MQTT Connector
In this example, you set a Last Will and Testament (LWT) message for Anypoint Connector for MQTT (MQTT Connector) to ensure that a message is sent to all of the subscribers of a specific LWT topic if the client disconnects temporarily or permanently from the broker. The LWT message is sent when the connection to the broker is established.
Configure the LWT message in the configuration element and specify whether or not you want the broker to retain that message. If an MQTT message is set for retention, the broker stores the last message marked as retained that arrived at a specific topic. If no listeners are subscribed to a matching topic at the time the message is sent, the broker stores the message until a listener connects to that topic. Then, the broker delivers the listener to the last message retained for that topic.
  1. In Studio, navigate to the **Global Elements** tab.
  2. Click **Create**.
  3. In the filter box, type `mqtt` and select **MQTT3 Config**.
  4. Click **OK**.
  5. In **MQTT3 Config** > **Connection** , select **MQTT3 Form Connection**.
  6. For **Client id generator** , select **Client id random suffix generator**.
  7. Set the following fields:
     * **Client ID** : `smart-bentley-123`
     * **Username** : `usertest`
     * **Password** : `passtest`
     * **URL** : `tcp://127.0.0.1:1883`
  8. Click **LWT**.
  9. Set the following fields:
     * **Topic** : `LWT`
     * **Body** : `Testing body message`
     * **Is retained** : **True**.
  10. Click **OK**.


In the **Configuration XML** editor, the `<mqtt3:last-will-and-testament>` configuration looks like this:
```
<mqtt3:config name="MQTT_LWT_Config">
  <mqtt3:connection username="usertest" password="passtest" url="tcp://127.0.0.1:1883">
    <mqtt3:client-id-generator >
      <mqtt3:client-id-random-suffix-generator clientId="smart-bentley-123" />
    </mqtt3:client-id-generator>
    <mqtt3:last-will-and-testament topic="LWT" isRetained="true" >
      <mqtt3:body ><![CDATA[Testing body message]]></mqtt3:body>
    </mqtt3:last-will-and-testament>
  </mqtt3:connection>
</mqtt3:config>
```

## See Also
  * MQTT Connector Examples
  * MuleSoft Help Center
WSS Module - Examples | MuleSoft Documentation
# WSS Module - Examples
The following WSS module examples show you how to validate a Web Service Security (WSS) configuration in your incoming SOAP requests:
  * Validate Operation Examples
    * Decrypt Message Example
    * Validate UsernameToken Examples
      *       * Credentials Authentication
    * Validate Signature Examples
      *       *     * Validate Timestamp Example
    * Validate SAML Examples
      * 

The following WSS module examples show you how to apply a Web Service Security (WSS) configuration to your outgoing SOAP responses:
  * Apply Operation Examples
    *     *     * Encrypt and Sign Example


## See Also
  * MuleSoft Help Center
Multipart (dw::module::Multipart) | MuleSoft Documentation
# Multipart (dw::module::Multipart)
This helper module provide functions for creating MultiPart and formats and parts (including fields and boundaries) of MultiPart formats.
To use this module, you must import it into your DataWeave code, for example, by adding the line `import dw::module::Multipart` to the header of your DataWeave script.
## Functions
Name | Description  
---|---  
Creates a `MultipartPart` data structure using the specified part name, input content for the part, format (or mime type), and optionally, file name.  
Creates a `MultipartPart` data structure from a resource file.  
Creates a `Multipart` data structure using a specified array of parts.  
| Helper function for generating boundaries in `Multipart` data structures.  
## Types
  *
CIM Fulfill Subject Area | MuleSoft Documentation
# CIM Fulfill Subject Area
Activities you perform to fulfill an order to a customer. For example, shipment and fulfillment order.
## Model Diagrams
The following diagrams show the entities and relationships in this subject area, organized by entity group.
### Fulfillment Order
## Implementation
## See Also
  *   * CIM Design Elements
  *   *
Missing Request Access ButtonConfiguration | MuleSoft Documentation
# Missing Request Access ButtonConfiguration
If a published API version is not showing the **Request access** button:
  1. Ensure that the API version is managed in API Manager.
  2. If it is not, click **Import from Exchange**.
  3. Ensure that the API version has at least one endpoint defined.
  4. Label the endpoint.
  5. This label displays in your community.
  6. Ensure that at least one of the API version’s endpoints is configured as public in Exchange.


In the community builder, check the audience targeting settings of the API Access Requester Lightning component. To make the API Access Requester appear to all members, ensure that it is not assigned to any audience. To make it appear only to a specific audience, ensure that it is assigned to the correct audience, and verify it by viewing the page while logged in to an account that is a member of this audience.
Uninstalling Runtime Fabric | MuleSoft Documentation
# Uninstalling Runtime Fabric
Depending on your installation method, you can use the Runtime Fabric command line tool (`rtfctl`) or Helm to uninstall Runtime Fabric.
## Uninstall Runtime Fabric Using RTFCTL
To uninstall Runtime Fabric using `rtfctl` commands, follow these steps:
  1. Using Runtime Manager, delete all Mule app and API gateways deployed on Runtime Fabric.
  2. Verify on all associated environments that you have removed all applications.
  3. In Runtime Manager, delete the Runtime Fabric.
  4. Run the `rtfctl uninstall` command to uninstall the Runtime Fabric services from the Kubernetes cluster.
  5. Run the `rtfctl uninstall --confirm` command to verify the uninstall operation.
  6. After the uninstall command finishes, verify that there are no Runtime Fabric applications or services running in the cluster.


## Uninstall Runtime Fabric Using Helm
To uninstall Runtime Fabric using Helm:
  1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric.
  2. Verify on all associated environments that you have removed all applications.
  3. Using Runtime Manager, delete the Runtime Fabric.
  4. Run the following command:
```
helm uninstall runtime-fabric -n rtf
```

If need to uninstall due to an error in the installation process, for example, if the install did not complete correctly, run the following command:
```
helm uninstall runtime-fabric -n rtf --no-hooks
```



## Uninstalling Runtime Fabric on Red Hat OpenShift
Perform the following procedure to uninstall Runtime Fabric on Red Hat OpenShift:
  1. Using Runtime Manager, delete all Mule applications and API gateways deployed on Runtime Fabric.
  2. Verify that you have removed all applications from all associated environments.
  3. Using Runtime Manager, delete the Runtime Fabric.
  4. In the Red Hat OpenShift console, navigate to **Operators** > **Installed Operators**.
  5. Select the Runtime Fabric operator.
  6. Click **Uninstall**.
  7. Using the following Helm command, uninstall Runtime Fabric from the cluster:
```
helm uninstall runtime-fabric -n rtf --no-hooks
```

  8. Delete the `rtf` namespace from the cluster:
```
oc delete ns rtf
```



### Troubleshooting Deletion of the rtf Namespace
If the command to delete the `rtf` namespace does not work, complete the following steps:
  1. Run the following command:
```
oc get ns rtf -o json > rtf.json
```

  2. Edit `rtf.json` and remove `kubernetes` from the `finalizer` array.
  3. Run the following commands:
```
oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json
oc get ns
```

  4. Confirm the `rtf` namespace is no longer present.


## See Also
  * Installing Runtime Fabric
  * Configuring Runtime Fabric
  * Upgrading Runtime Fabric
Configuring Text Panels in a Custom Dashboard | MuleSoft Documentation
# Configuring Text Panels in a Custom Dashboard
You can add text panels to custom dashboards in Anypoint Monitoring. A text panel can provide information about your dashboard. You can add one to any row in the dashboard.
You can write text in these modes:
  * HTML: See HTML Support for HTML examples.
  * Markdown: See Markdown Syntax Support for Markdown examples.

  
---  
## Markdown Example
As this Markdown example shows, you can see how your text will appear in the UI as you type.
Figure 1. Markdown Example
After you complete your configuration, you can click Save Changes. To exit the configuration and return to the dashboard, simply click the `X`.
## HTML Example
This HTML example creates the heading shown in Text example:
Amazon Secrets Manager Properties Provider 1.0 | MuleSoft Documentation
# Amazon Secrets Manager Properties Provider 1.0
Amazon Secrets Manager Properties Provider is a configuration that enables you to retrieve your secrets from Amazon Secrets Manager cloud service before your Mule app runs.
For information about compatibility and fixed issues, refer to the Amazon Secrets Manager Properties Provider Release Notes.
## Before You Begin
To use this properties provider, you must be familiar with:
  * AWS Secrets Manager
  * 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:
  * Mule Enterprise Edition
  * Credentials to access the AWS Secrets
  * Anypoint Platform
  * Anypoint Studio version 7.3.5 or later


## Common Use Cases for the Properties Provider
With AWS Secrets Manager Properties Provider, you can:
  * Configure values from AWS Secrets Manager for Mule applications.
  * Retrieve secrets for SaaS applications as part of the source or operation.
  * Specify the name of the secret to retrieve.
  * Authenticate to AWS using the available options from the AWS SDK IAM, default provider chain, or Basic Authentication.
  * Specify the AWS server or region to connect to the appropriate server for your business unit.
  * Be notified about errors while connecting to AWS.
  * Be notified about errors while retrieving secrets from AWS.


## See Also
  * Amazon Secrets Manager Properties Provider Examples
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Amazon Secrets Manager Properties Provider Reference
  * MuleSoft Help Center
Dates Types (dw::core::Dates) | MuleSoft Documentation
# Dates Types (dw::core::Dates)
Type | Definition | Description  
---|---|---  
DateFactory |  `type DateFactory = { day: Number, month: Number, year: Number }` |  Type containing selectable `day`, `month`, and `year` keys and corresponding `Number` values, such as `{day: 21, month: 1, year: 2021}`. The fields accept a `Number` value. Numbers preceded by `0`, such as `01`, are not valid.  
DateTimeFactory |  `type DateTimeFactory = DateFactory & LocalTimeFactory & Zoned` |  Type that combines `DateFactory`, `LocalTimeFactory`, and `Zoned` types. For example, `{day: 21, month: 1, year: 2021, hour: 8, minutes: 31, seconds: 55, timeZone : |-03:00|} as DateTimeFactory` is a valid `DateTimeFactory` value.  
LocalDateTimeFactory |  `type LocalDateTimeFactory = DateFactory & LocalTimeFactory` |  Type that combines `DateFactory` and `LocalTimeFactory` types. For example, `{day: 21, month: 1, year: 2021, hour: 8, minutes: 31, seconds: 55, timeZone : |-03:00|} as LocalDateTimeFactory` is a valid `LocalDateTimeFactory` value. The `timeZone` field is optional.  
LocalTimeFactory |  `type LocalTimeFactory = { hour: Number, minutes: Number, seconds: Number }` |  Type containing selectable `hour`, `minutes`, and `seconds` keys and corresponding `Number` values, such as `{hour: 8, minutes: 31, seconds: 55}`. The fields accept any `Number` value.  
TimeFactory |  `type TimeFactory = LocalTimeFactory & Zoned` |  Type that combines `LocalTimeFactory` and `Zoned` types. For example, `{hour: 8, minutes: 31, seconds: 55, timeZone : |-03:00|} as TimeFactory` is a valid `TimeFactory` value.  
`type Zoned = { timeZone: TimeZone }` |  Type containing a selectable `timeZone` key and `TimeZone` value, such as `{ timezone : |-03:00|}`.
Client Management | MuleSoft Documentation
# Client Management
Anypoint Platform acts as a client provider by default, but you can also configure up to 25 external client providers to authorize client applications. As an API owner, you can apply an OAuth 2.0 policy to authorize client applications that try to access your API. You need an OAuth 2.0 provider to use an OAuth 2.0 policy.
You can configure more than one client provider and associate the client providers with different environments. If you configure multiple client providers after you have already created environments, you can associate the new client providers with the environment. You should review the existing client configuration before reassigning client providers to avoid any downtime with existing assets or APIs. When you delete a client provider from your root organization, the client provider is no longer available in environments that used it. Also, assets or APIs that used the client provider can no longer authorize users who want to access them.
You can configure the following OAuth providers:
  *   * PingFederate versions: 6 through 8
  * Dynamic Client Registration-compliant client providers
    * Microsoft Entra ID Client Management
Dynamic Client Registration-compliant identity providers must conform to the OpenID Connect Client Registration 1.0 incorporating errata set 1.


To configure client management on Anypoint Platform for supported providers, you must have an identity provider (IdP) account with the provider you want to use.
## Delete a Client Provider
Before you delete a client provider, ensure that you do not have APIs, assets, or environments that depend on the client provider or you will lose functionality. For example, any APIs that depend on the client provider can no longer authenticate user access.   
---  
  1. Sign in to Anypoint Platform using an account that has the Organization Administrator permission.
  2. In the navigation bar or the main Anypoint Platform page, click **Access Management**.
  3. In the **Business Groups** menu, select your root organization.
  4. In the Access Management navigation menu, click **Client Providers**.
  5. Click the name of the client provider you want to delete.
  6. In the client provider’s page, click **Delete**.
  7. Enter the name of the client identity provider name.
  8. Click **Delete**.


## See Also
  * OpenID Connect Client Registration 1.0 incorporating errata set 1
  * Configure Client Management by OpenAM
  * Configure Client Management by PingFederate
  * Configure OpenID Connect Client Management
Enhancing Data Extraction with Einstein | MuleSoft Documentation
# Enhancing Data Extraction with Einstein
By default, IDP uses its natural language processing model (IDP NLP) to extract data based on the configured prompts. When you create a document action, you can select Einstein to analyze the document and extract the data.
Use Einstein to answer complex questions about the document, such as asking the total of an invoice after deducting taxes and other concepts, or to extract data from non-standard documents such as a driver’s license or a medical record that contains handwriting.
Einstein supports these predictive models:
  * OpenAI’s `GPT-4o (gpt-4o-2024-08-06)` LLM
  * OpenAI’s `GPT-4o Mini (gpt-4o-mini-2024-07-18)` LLM
  * Google’s `GEMINI-2.0 Flash 001` LLM


Einstein accesses these models through the Salesforce Einstein Trust layer, which is part of the Salesforce Einstein platform.
Select the model to use during document analysis by clicking **Settings** in the document action editor.
Document actions created before February 5th support only OpenAI’s `GPT-4o (gpt-4o-2024-05-13)`. To enable model selection and the new models, create a new document action. See Configure Document Action Settings for details about feature availability and configuration.   
---  
To analyze any type of document with Einstein, fully customize the output structure, and optimize Einstein credit consumption, see Analyzing Documents With Custom User-Defined Schemas.
## Before You Being Using Einstein
  1. Ensure you have any of these Anypoint permissions: 

Manage Actions
    
Gives a user complete access to IDP and assigns reviewer permission by default for every document action. 

Build Actions
    
Enables a user to create, edit, publish, and execute document actions and assign reviewers to the actions.
  2. Enable MuleSoft Anypoint Platform to publish MuleSoft assets to Salesforce.
  3. Enable Einstein for Anypoint Platform.


## Select the Response from Einstein
To configure Einstein to analyze and extract data for a given prompt:
  1. In the document action builder, add a new prompt to a document action or edit an existing one.
  2. Run a document analysis to generate results in the **Outputs** panel.
  3. Click the dropdown button (), next to a prompt’s result.
  4. Select the response labeled **Einstein**.


When you query a published document action, IDP uses the model selected in each prompt to extract the data for the corresponding field.
## See Also
  * Example Einstein Prompts
  * Analyzing Documents Using Pre-Built Schemas
Set Transaction Id | MuleSoft Documentation
# Set Transaction Id
The Set Transaction Id component enables you to set an identifier for all tracked events so that meaningful information, such as an order number, is displayed for a transaction when analyzing tracked events at runtime, whether using Anypoint Runtime Manager or CloudHub.
The transaction ID supports DataWeave expressions, which enables you to create an ID dynamically and include information related to the event into the ID.
## Customize the Transaction ID
Follow these steps to set a transaction ID either in Anypoint Studio or by editing the configuration XML:
  * In the Studio UI:
    1. Drag the **Set Transaction Id** component to your flow.
    2. In the **Set Transaction ID** configuration screen, set an ID value for the **Transaction ID** field:
  * In the XML editor:
    * Add a child element to the `flow` element:
```
<flow name="flow">
...
 <tracking:transaction id="#[payload.orderId]" />
...
</flow>
```



## Set Transaction ID Reference
Field | Description  
---|---  
Transaction ID (`id`) |  Defines the value of the identifier. It can be an expression or a literal. By default, the component assigns a numeric value.  
## See Also
  *   * Configure Default Events Tracking
API Experience Hub Release Notes | MuleSoft Documentation
# API Experience Hub Release Notes
API Experience Hub is an API management platform and digital experience that enables organizations to create vibrant API ecosystems within and outside the enterprise. API providers can share, promote, and engage with their developer community. Developers and partners can find, explore, and consume APIs designed anywhere from a single place.
The following release notes are provided for API Experience Hub:
  * Anypoint API Experience Hub Release Notes


## See Also
  * API Experience Hub Overview
  *
Amazon SNS Connector 4.7 - Get Started | MuleSoft Documentation
# Amazon SNS Connector 4.7 - Get Started
Anypoint Connector for Amazon SNS (Amazon SNS Connector) provides connectivity to the Amazon Simple Notification Service (Amazon SNS) API, enabling you to build distributed web-enabled applications. Mule apps can use Amazon SNS Connector to easily push real-time notification messages to interested subscribers over multiple delivery protocols.
Release Notes: Amazon SNS Connector Release Notes Exchange: Amazon SNS Connector in Anypoint Exchange
## About Connectors
Anypoint Connectors are Mule runtime engine extensions that enable you to connect to APIs and resources on external systems, such as Salesforce, Amazon SNS, ServiceNow, and Twitter.
## Before You Begin
Before creating an app, you must:
  * Have access to the Amazon SNS target resource and Anypoint Platform.
  * Understand how to create a Mule app using Anypoint Studio.
  * Have AWS Identity and Access Management (IAM) credentials.


### Compatibility
Amazon SNS connector is compatible with:
Application/Service | Version  
---|---  
Mule Runtime  
AWS SDK for Java  
Anypoint Studio |  7.0 or higher  
## Next Step
After you have met the prerequisites, you are ready to create an app with Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * MuleSoft Help Center
Bot Workload | MuleSoft Documentation
# Bot Workload
The **Bot Workload** widget shows how many of the sessions of an **RPA Bot** are reserved and how many are still free.
This gives you an overview of the utilization of the bots and you can allocate resources flexibly.
## Data Representation
The workloads of the Bots are displayed as a bar chart.
The individual bars have different colors depending on the allocation between free sessions and those reserved for individual production configurations.
## Configuration
You can select multiple bots in sequence from the drop-down list.
## Drill-down
This widget does not contain any drill-down data.
functionParamTypes | MuleSoft Documentation
# functionParamTypes
## functionParamTypes(t: Type): Array<FunctionParam>
Returns the list of parameters from the given function type. This function fails if the provided type is not a Function type.
_Introduced in DataWeave version 2.3.0._
### Parameters
Name | Description  
---|---  
The function type.  
### Example
This example shows how `functionParamTypes` behaves with different inputs.
#### Source
```
%dw 2.0
output application/json
import * from dw::core::Types
type AFunction = (String, Number) -> Number
type AFunction2 = () -> Number
---
{
  a: functionParamTypes(AFunction),
  b: functionParamTypes(AFunction2)
}
```

#### Output
```
{
  "a": [
   {
    "paramType": "String",
    "optional": false
   },
   {
    "paramType": "Number",
    "optional": false
   }
  ],
  "b": [
  ]
 }
```
Offline Custom Policies | MuleSoft Documentation
# Offline Custom Policies
To manage offline custom policies, see the following topics:
  * Applying Offline Custom Policies
  * Removing Offline Custom Policies
To Write a File Using the File Connector | MuleSoft Documentation
# To Write a File Using the File Connector
A Write operation is available to the File, FTP, and SFTP connectors. For these connectors, the operation writes content into the given path on demand. It supports common use cases described below.
## Embedded DataWeave Transformations
By default, the connector writes whatever is in the message payload:
Example: File Connector
```
<file:write path="output.csv" />
```

However, if the payload is a different format (for example, not CSV) and you need to transform it before writing it, what do you do? If you place a Transform component before the Write operation, the message payload changes and that impacts the operation that is placed after the Write operation.
To avoid this undesired impact, you can place the transformation inside the Write operation to generate content that will be written without producing a side effect on the message in transit.
The next example uses the File connector to write the content:
Example: Transformation within a File Write Operation
```
<file:write path="output.csv">
 <file:content>#[%dw 2.0
         output application/csv
         ---
         payload.customers.email
        ]
 </file:content>
</file:write>
```

## Writing into Directories
If any of the `a`, `b`, or `c` directories in the example below do not exist, the Write operation will fail by default. However, if you set the `createParentDirectories` to `true`, the connector will automatically create any missing directories.
Example: File Connector writes to a Directory
```
<file:write path="a/b/c/myFile.txt" />
```

## Write to Existing Files
When writing content to a file, set **Write Mode** to any of the following modes:
  * **OVERWRITE (Default)** If the file exists, overwrite it completely.
  * **APPEND** If the file exists, add its content to the end of an existing file.
  * **CREATE_NEW** Create a new file. If the file already exists, then you receive an error.


## Locks
The **Write** operation supports locking similar to the **Read** operation. The main difference is that the lock releases automatically after the **Write** operation finishes. Set **Lock** to any of the following modes:
  * **FALSE (Default)**
Throttling and Rate Limiting | MuleSoft Documentation
# Throttling and Rate Limiting
The Rate Limiting policy limits the number of requests an API accepts within a window of time. The API rejects requests that exceed the limit. You can configure multiple limits with window sizes ranging from milliseconds to years.
The Throttling policy queues requests that exceed limits for possible processing in a subsequent window. The API eventually rejects the request if processing cannot occur after a certain number of attempts. You can configure a delay between retries, as well as limit the number of retries.
The Rate Limiting and Throttling policies impose a limit on all requests or a specific resource (in Mule 3.x and earlier, the API must be APIkit-based). The service level access (SLA)-based Rate Limiting and Throttling policies add further granularity, limiting requests by the level of access granted to the requesting application. These policies contain a persistence engine to preserve the current state of the policy in case of sudden restart (power outage).
How you configure the rate or throttling limit depends on whether the policy is SLA-based or not. If the policy is _not_ SLA-based, you configure limits when you apply the policy.
This example sets one limit of 10 requests (quota) per every 2 seconds (window).
If the policy is SLA-based, Mule Runtime fetches all contracts, which defines the relationship between an SLA and the application, for the API.
When you configure Mule Runtime in a cluster, you can configure the policy for distributed access control.
Rate Limiting and Throttling policies are designed to limit API access, but have different intentions: Rate limiting protects an API by applying a hard limit on its access. Throttling shapes API access by smoothing spikes in traffic.
## See Also
  * About Resource-Level Policies
  * Throttling And Rate Limiting Reference
  *
Applying Offline Custom Policies | MuleSoft Documentation
# Applying Offline Custom Policies
An offline policy is applied directly to the runtime and not through API Manager. When you create a file in the offline-policies directory, Mule runtime engine (Mule) detects the presence of the file and starts applying the policy.
Mule then generates the JSON and XML policy files in a new directory in `%MULE_HOME%/policies`.
## Task Prerequisites
Before you apply an offline custom policy, ensure that:
  * Mule runtime engine (Mule) is installed with Mule Gateway capabilities enabled.
  * An API configured with a basic endpoint or a proxy endpoint exists in API Manager.
  * A Mule application is deployed with a HTTP(s) based flow, which is linked to the API through Autodiscovery.
When Autodiscovery is correctly configured in your Mule application, your application’s API is said to be tracked by or paired to API Manager.


## Apply an Offline Custom Policy
To apply an offline custom policy:
  1. If you do not want to use the policy template from Exchange due to various reasons, place the template JAR in the following directory before you apply the offline policy to the API.
`%MULE_HOME%/policies/policy-templates`
  2. Create a JSON file in `%MULE_HOME%/policies/offline-policies` directory that defines the policy configuration.
  3. Name the JSON file after the policy ID.
  4. In the file, include the following configuration specifications:
     * Policy template information
Specify the Exchange groupId, assetId, and version of the template used to deploy the offline policy definition.
     * IDs of the APIs that the policy will be applied to
     * A list of resources that the policy will be applied to
     * Order of the policy
     * Parameters if the defined template is using handlebars variables
The following example shows a typical offline policy definition:
```
{
 "template" : {
  "groupId" : "com.mulesoft.anypoint",
  "assetId" : "policyTemplate",
  "version" : "0.1.0"
 },
 "api": [
  {
   "id": "1"
  },
  {
   "id": "2"
  }
 ],
 "order": 1,
 "configuration" : {
  "payload" : "Payload"
 }
}
```

  5. After you apply a custom offline policy, you must manually deploy it to a Mule runtime engine (Mule) file system.


## See Also
  * Removing Offline Custom Policies
Analyzing Problems with Analysis Packages | MuleSoft Documentation
# Analyzing Problems with Analysis Packages
After a business process runs locally in RPA Builder, you can upload it to RPA Manager, move it to the test phase, run it on an RPA Bot, and start a long-term test. Run tests for at least three days before using the business process productively. If menu runs contain errors, RPA Manager generates Analysis Packages that you can download.
The Analysis Package provides detailed information on the run in the same format as if you had executed the Workflow locally. Use this information to fix any errors. Elements, which have caused an error or a warning, are marked with an expandable red or yellow frame. This frame contains more detailed information concerning the run results. Use the Analysis Packages to understand and fix errors for each failed Workflow run. If you see the same error repeatedly, fix the error once and start collecting results again.
## Download and Analysis Package
To download an Analysis Package for a Workflow that throws an error:
  1. In RPA Manager, open the **Process Management** module.
  2. Open the process for which you want to download the Analysis Package.
  3. Start a test and wait a few minutes for the test to complete.
If you don’t have any test plans available, click **Create new test plan** and follow the instructions to create one.
  4. Click **Update** to refresh the test run results.
  5. Click the result number in the **Failure** column.
If there are no errors, the **Failure** column shows `0` results and there’s no Analysis Package available to download.
  6. Click the **Download** button.


## Load and Analysis Package
To load an Analysis Package:
  1. In RPA Builder, open any Workflow to make the Workbench menu appear.
  2. In the Workbench menu, click **Tools**.
  3. Click **Load Analysis Package** and select the location of the Analysis Package file.


## Analysis Package Directory
After you start the workflow locally for the first time, either with the **Run Workflow** button or by pressing _F7_ , RPA Builder creates the `custom` directory. The path to the `custom` directory is: `C:\Users\[UserName]\Documents\MuleSoft\Cache\[Process-GUID]\[Activity- GUID]\Robot\custom\`.
Right-click on the Workflow tab and select **Open Workflow Location** to open the `C:\Users\[UserName]\Documents\MuleSoft\Cache\[Process-GUID]\[Activity- GUID]\` folder.
You can add extra data like screenshots or log files to the Analysis Package by saving them to the project’s `custom` folder. RPA Manager packs all files from this folder into the Analysis Package in case of an error.
Note that when an RPA Bot executes the Workflow, it saves the Analysis Package on the machine on which the bot is running.
## See Also
  * Running Workflows and Using Workflow Run Results
  * Using Workflow Debugger
Application Testing | MuleSoft Documentation
# Application Testing
All application projects include MUnit test suites, which provide basic unit test cases and functional tests defined in a Postman collection.
## Postman Tests
For running the Postman collections you will need to download and install the latest Postman release from https://www.postman.com/downloads/. A Postman account is required to launch and run tests.
Before importing the project collection into your Postman workspace you will need to set up an environment specifically for running Accelerator test collections. In the `accelerator-common-resources` project, there is a pre-defined environment file under the `testing` folder. Import this file into Postman and update the variables to reflect your own settings.
## MUnit Tests
From the command line, running any Maven goal that includes the testing phase automatically executes the MUnit tests. This includes the goals `test`, `package`, and `deploy`. To avoid running the MUnit tests, specify either `-DskipMunitTests` or `-DskipTests` on the Maven command line (for example, `mvn package -DskipTests`). Case matters when specifying the values.
## See Also
  *   *   * Application Deployment
  * Additional Customizations
  * MuleSoft Accelerators
Migrating the Scatter-Gather Router | MuleSoft Documentation
# Migrating the Scatter-Gather Router
The most important change in Scatter-Gather router between Mule 3 and Mule 4 is in the `AggregationStrategy` used to consolidate the results of the different routes. Instead of providing a Java class with the aggregation logic, you can perform the aggregation with a DataWeave transformation.
The payload Scatter-Gather returns is a collection of messages, where each the result of each route. Those messages are accessible with DataWeave.
## Example
This is a Mule 3 Scatter-Gather with a `custom-aggregation-strategy` element referencing the Java class with the aggregation strategy:
```
<scatter-gather doc:name="Scatter-Gather">
  <custom-aggregation-strategy class="com.example.poc.CustomSGAggregationStrategy"/>
  <processor-chain>
    ...
  </processor-chain>
  <processor-chain>
    ...
  </processor-chain>
</scatter-gather>
<logger message="#[payload]" level="INFO" doc:name="Logger"/>
```

And the aggregation strategy implementation is:
```
package com.example.poc;
import ...
public class CustomSGAggregationStrategy implements AggregationStrategy {
  @Override
  public MuleEvent aggregate(AggregationContext context) throws MuleException {
    StringBuilder responseBuilder = new StringBuilder();
    MuleEvent result = null;
    ArrayList < MarketRate > marketRates = new ArrayList < > ();
    for (MuleEvent event: context.collectEventsWithoutExceptions()) {
      String response = (String) event.getMessage().getPayload();
      String[] spiltResponse = StringUtils.split(response, ",");
      MarketRate marketRate = new MarketRate();
      marketRate.setEvent(event);
      marketRate.setMarketName(spiltResponse[0]);
      marketRate.setMarketRate(new Integer(spiltResponse[1]));
      marketRates.add(marketRate);
      System.out.println(marketRate);
    }
    Collections.sort(marketRates);
    result = DefaultMuleEvent.copy(marketRates.get(0).getEvent());
    result.getMessage().setPayload(marketRates.get(0).toString());
    return result;
   }
  }
```

For Mule 4, the Java class is removed, and the flow elements become:
```
<scatter-gather doc:name="Scatter-Gather">
  <route>
    ...
  </route>
  <route>
    ...
  </route>
</scatter-gather>
<ee:transform>
  <ee:message >
  	<ee:set-payload ><![CDATA[%dw 2.0
output text/plain
---
(payload map ((response, index) -> (response.payload splitBy(','))[1]) orderBy ((rate, index) -> rate))[0]
]]]></ee:set-payload>
  </ee:message>
</ee:transform>
<logger message="#[payload]" level="INFO" doc:name="Logger"/>
```

Notice the `ee:transform` element that replicates the logic of the `CustomSGAggregationStrategy`, in DataWeave rather than Java.
## See Also
About Scatter-Gather
About the Transform Component
Setting Up the Environment and Access Permissions | MuleSoft Documentation
# Setting Up the Environment and Access Permissions
Create an environment and manage the roles of users who administer the Anypoint MQ features in Anypoint Platform for your organization using access management.
## Before You Begin
  * Create an environment with which to associate permissions.
Follow the steps in To Create a New Environment.
  * Make sure you have the permissions required to use Anypoint MQ.
For information about assigning permissions, see Grant Permissions to Users.


## Anypoint MQ Permissions
To…​ | Required Permission | Notes  
---|---|---  
View all client apps, including client app IDs and client secrets for each client app. |  View clients  
  * View all destinations and each destination’s settings (**ID** , **Type** , **Message TTL** , and **Message Lock Default TTL**).
  * View **In Queue** messages.
  * View **In Flight** message stats.

| 
  * View destinations
  * Clear destinations

  
  * View all client apps, including client app IDs and client secrets for each client app.
  * Create client apps.

|  Manage clients  
  * View all destinations and each destination’s settings (**ID** , **Type** , **Message TTL** , and **Message Lock Default TTL**).
  * View **In Queue** messages.
  * View **In Flight** message stats.
    * Create new queues, message exchanges, and bindings.
    * Edit existing queues, message exchanges, and bindings.
    * Purge messages from queues.

|  Administer destinations  
  * View all destinations and each destination’s settings (**ID** , **Type** , **Message TTL** , and **Message Lock Default TTL**).
  * View **In Queue** messages.
  * View **In Flight** message stats.
  * Create new queues and message exchanges.
  * Edit existing queues and message exchange settings.
  * Access **Message Sender** and **Browser** pages.
  * Delete messages.
  * Purge messages from queues.

|  Manage destinations (deprecated) |  Assign these permissions instead:
  * Administer destinations
  * Destination subscriber for given environment
  * Destination publisher for given environment

  
  * Consume messages from a destination.
  * Delete messages from a destination.

|  Destination subscriber for given environment  
  * Send messages to a destination.
  * Update message TTL on a destination.

|  Destination publisher for given environment  
View organization and environment statistics. |  Read MQ stats  
## Switch Environments
To switch environments:
  1. In Anypoint Platform, go to **MQ**.
  2. Click the environment button.
     * To switch to a different environment, click the name of that environment (for example, **Sandbox** , if you previously created a sandbox environment) and then click **Switch**.
     * To change your default environment, click **Open your profile to change the default environment** and choose a different environment from the **Default** environment list.


## See Also
  * Permissions Available in Anypoint Platform
SHA1 | MuleSoft Documentation
# SHA1
## SHA1(content: Binary): String
Computes the SHA1 hash and transforms the result into a hexadecimal, lowercase string.
### Parameters
Name | Description  
---|---  
A binary input value to encrypt.  
### Example
This example uses the SHA1 algorithm to encrypt a binary value.
#### Source
```
%dw 2.0
import dw::Crypto
output application/json
---
{ "sha1" : Crypto::SHA1("dsasd" as Binary) }
```

#### Output
```
{ "sha1": "2fa183839c954e6366c206367c9be5864e4f4a65" }
```
Upgrading Runtime Fabric | MuleSoft Documentation
# Upgrading Runtime Fabric
To upgrade Anypoint Runtime Fabric, review one of the following options:
  * Upgrading Runtime Fabric using RTFCTL Use the `rtfctl` command line tool to upgrade Runtime Fabric.
  * Upgrading Runtime Fabric using Helm Use Helm package manager to upgrade Runtime Fabric.
  * Upgrading Runtime Fabric as a Kubernetes (K8s) Operator Use the Red Hat OpenShift console to upgrade Runtime Fabric on Red Hat OpenShift.
  * Upgrading Pre-requisites Update the `rtfd` container values.


## See Also
  * Installing Runtime Fabric
  * Configuring Runtime Fabric
  * Uninstalling Runtime Fabric
Setting Environment Variables | MuleSoft Documentation
# Setting Environment Variables
If you’re deploying multiple applications as a shared resource, you shouldn’t set any properties in the project properties files. This might cause conflicts between the various apps that share a domain. Instead, you can set environment variables over the scope of the deployed app, its domain, and other apps under that domain.
The steps below explain how to set environment variables in Studio. These variables are only used when you deploy locally through Studio. When you deploy your applications to a standalone server, you must provide these variables through the command line.
  1. Under **Run** , select **Run Configurations**.
  2. Select the corresponding run configuration. If a run configuration does not exist for your project, you can create one by using the new button.
  3. Select the **Environment** tab, and add the variables you need.
The environment variables you create are defined at the domain level. These will affect all of the applications associated with that domain when you deploy locally using Studio.


Setting environment variables only works when running the application in the Mule runtime engine within Studio. This configuration does not affect design time operations such as DataSense, automatic completion, or validation.
## See Also
  *   * Configuring Properties
Lock Section | MuleSoft Documentation
# Lock Section
The _Lock Section_ action step is used to synchronize access if multiple parallel _Workflows_ need to access a file or a mailbox, for example in the case of Robotic Applications. Synchronization is achieved by preventing other _Workflows_ from accessing the file when it is in use.
A typical scenario where a _Lock Section_ might be used when a _Workflow_ is run in parallel in different sessions. In this case, a _Robot Secure_ is used that enables parallel secure sessions to be launched. If parallel secure sessions, such as in the example above, are running on virtual machines on a server, then a file can be locked in synchronization on this server in order to allow certain content to be read out alternately.
## Properties
  * **Lock Token** Enter an individual token here. Individual tokens are typically only necessary if you work with virtual machines with identical installations running in parallel. Normally it is adequate to use the WorkflowGUID as the token.
  * **WorkflowGUID** This field shows the GUID (Globally Unique Identifier) of the present _Workflow_. This GUID is intended to be unique anywhere in the world. However, for parallel, identical installations that use _Robot Secure_ and individual _Secure Sessions_ , there is no guarantee that this ID will be unique.


Other Properties that are the same in all action steps are described in the section on **Common Properties**. For reasons of clarity they are not shown here.
## Wizard
  * **Lock on Workflow GUID** Enable this option if parallel executions of the same Workflow need to be synchronized across various _Secure Sessions_ when using _Robot Secure_. The GUID shown in the **Lock Token** field for the active Workflow makes use of this option.
  * **Lock on user defined token** Enable this option if parallel executions of the same Workflow need to be synchronized in various _Secure Sessions_ using the _Robot Secure_. This is the case for virtual machines and parallel identical installations, for example. This option uses the token entered in the **Lock Token** field.
  * **Lock Token** Enter an individual token here. All alphanumeric characters except \ and / are allowed.