BassemE/mulesoft-documentation-embeddings huggingface dataset:
X12 EDI Connector 2.7 | MuleSoft Documentation
# X12 EDI Connector 2.7
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)


To use X12 EDI connector, you must have:
  * Purchased a MuleSoft license for Anypoint B2B
  * 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
Anypoint Exchange 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
WebSockets Studio Configuration | MuleSoft Documentation
# WebSockets Studio Configuration
To configure the connector in Anypoint Studio:
  1. Add the connector to a Studio project.
  2. Configure the connector.
  3. Configure an input source for the connector.


## Add the Connector to a Studio Project
Anypoint Studio provides two ways to add the connector to your Studio project: from the Exchange button in the Studio taskbar or from the Mule Palette view.
### Add the Connector Using Exchange
  1. In Studio, create a Mule project.
  2. Click the Exchange icon **(X)** in the upper-left of the Studio task bar.
  3. In Exchange, click **Login** and supply your Anypoint Platform username and password.
  4. In Exchange, search for "websockets".
  5. Select the connector and click **Add to project**.
  6. Follow the prompts to install the connector.


### Add the Connector in Studio
  1. In Studio, create a Mule project.
  2. In the Mule Palette view, click **(X) Search in Exchange**.
  3. In **Add Modules to Project** , type "websockets" in the search field.
  4. Click this connector’s name in **Available modules**.
  5. Click **Add**.
  6. Click **Finish**.


## Configure the Connector
  1. Go to the **Global Elements** tab, and click **Create**.
  2. From **Connector Configuration** , select the **WebSockets Config**.
  3. If you want your connector to listen for incoming requests check the **Configure Inbound WebSocket** section. If you want to perform requests to external services, check the **Configure Outbound WebSocket** section. You can check both if your application will be doing both inbound and outbound connections.


### Configure Inbound WebSockets
  1. Go to the **Global Elements** tab and click **Create**.
  2. From **Connector Configuration** , select the **HTTP Listener Config**.
  3. In your WebSockets Configuration, check the **Server settings** box.
  4. Specify the listener base path(optional) and reference the HTTP Listener Config you created before.


### Configure Outbound WebSockets
  1. In your WebSockets Configuration, check the **Client settings** box.
  2. Specify the following optional properties:
  3. In the **Default Headers** and **Query Parameters** sections you can introduce your default values for headers and query parameters by selecting an option from the drop-down list.
    1. Select **Expression** to enter a `dwl` expression.
    2. Click **Edit Inline** to enter key/value pairs by clicking the '+' sign.


## Configure an Input Source
Configure an input source for the connector.
You can put the following operations for the connector in the **Source** area of the Studio canvas:
  * Inbound Listener
  * On Outbound Socket Message
  * On Inbound Connection (requires an Inbound Listener)
  * On Socket Closed


## Next
Now that you have completed configuring Studio, see the Connector Configuration for more configuration ideas.
## See Also
  * MuleSoft Help Center
  * WebSockets Connector Overview
  * XML and Maven Configuration
Designing API Specs with AI | MuleSoft Documentation
# Designing API Specs with AI
Cloud IDE 
Desktop IDE 
Simplify your API designs by generating API specifications with AI. Use natural language to create prompts and let Einstein Generative AI build APIs for you. Pre-trained large language models (LLMs) within the Salesforce Shared Trust Boundary power these capabilities and are at the core of API spec generation in Anypoint Code Builder.
Anypoint Code Builder Generative AI API specifications is available on US, EU, Canada, and Japan cloud hosts.   
---  
## Trust Layer
The generative AI trust layer bridges Anypoint Platform and the LLMs, as shown in this flow:
The Anypoint Code Builder user creates a message based on their use case and sends it to Agentforce.  
---  
To minimize inaccurate responses (the AI "hallucination" effect), messages are grounded with factual MuleSoft proprietary data and user context.  
To ensure the data is sent safely to the external LLM, the message is sent to Open AI via the secure gateway.  
To keep your data secure, all data remains in Salesforce.  
After the LLM generates a response, the content is sent back through the secure gateway.  
MuleSoft validates the generated output to ensure the generated flow works within the MuleSoft ecosystem.  
Anypoint Code Builder logs the message and generated responses for monitoring before surfacing the validated response in Anypoint Code Builder.  
This feature uses generative AI, which is known to include inaccurate or harmful responses. Before implementing this feature, review the output for accuracy and safety. You assume responsibility for the output when making business decisions.   
---  
## See Also
  * Einstein Generative AI & Trust
  *   * Einstein Trust Layer: Designed for Trust
  * Creating API Specs with AI
Manage Contracts for Anypoint DataGraph | MuleSoft Documentation
# Manage Contracts for Anypoint DataGraph
As an Anypoint DataGraph administrator, you ensure that only authorized client applications can consume the unified schema by granting access based on specified user credentials and the SLA tier.
Client applications request access to the unified schema via Anypoint DataGraph. Approving access creates a contract between the client application and the unified schema for its environment, and registers the client application. Refer to Client Applications and Contracts for more information.
## Anypoint DataGraph Contract Administration
In API Manager, the DataGraph **Contracts** page lists client applications that have requested access, client applications you’ve approved, and client applications whose contracts you have revoked:
To get additional information about a client application, click the icon next to the application’s name.  
---  
To revoke an application’s access, click **Revoke**.  To restore access, click **Restore**.  
## See Also
  * Anypoint DataGraph Overview
  * Permissions For Anypoint DataGraph
OCR With AWS | MuleSoft Documentation
# OCR With AWS
The OCR with AWS action step enables you to recognize the text in a document by sending a local file to the AWS Textract service, which returns the extracted values.
This action step processes the document in a synchronous fashion (Amazon does not store the document) and automatically converts PDF files to PNG images. You can adjust the fidelity of the conversion in the properties grid.
## Inbound Variables
  * **Directory Path**
  * **File Name**
  * **Password**
  * **Read text from page**
  * **Read text to page**
  * **AWS Credentials**
Or, if **Use custom settings** is activated in the wizard:
    * **Client Id**
    * **Client Secret**
    * **Session Token**
    * **Use Session Token**
    * **Region Endpoint**
  * **Json Path**


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


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


## See Also
  *   * Amazon Textract: Detecting Text
  * Building JSONPath Expressions
Scripting Module 2.0 | MuleSoft Documentation
# Scripting Module 2.0
Scripting module executes custom logic written in a scripting language. In some cases, you might need to create custom code to perform all or part of a complex task, or to reuse modules that you have already written. Starting with Scripting module version 2.0, you must provide a compliant `jsr-223` scripting language engine.
## Before You Begin
To use this module, you must be familiar with:
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * Creating a Mule app using Anypoint Studio


Before creating an app, you must have access to Anypoint Platform.
## Common Use Cases for the Module
Scripting module performs logic in a supported language, which enables you to access variables and the registry, log information via the Mule logger, read payloads, and so on.
For examples, see Examples.
## Audience
  * New user, read:
    * Using Anypoint Studio to Configure the Connector to create your Mule app
    * Examples, which provides one or more use cases for the connector
  * Advanced user, read:
    * XML and Maven Support
    * Examples, which provides one or more use cases for the connector


For a major or minor release, see Upgrading and Migrating.
## Next Step
After you complete the prerequisites and experiment with templates and examples, 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
  * MuleSoft Help Center
Making Sure Windows Fonts Match | MuleSoft Documentation
# Making Sure Windows Fonts Match
Ensure that the window colors and fonts of the system a _Workflow_ is created on are identical to the systems the _Workflow_ is going to run on. The window colors and fonts determine how windows are displayed, including size, font and color of captions, buttons, and various control elements.
## Verifying Windows Color Schemes and Font Sizes
To access the color and font settings for Windows:
  1. Open the Windows **Personalization** settings.
     * Right-click on the Desktop and select **Personalize** , or
     * Open the **Start** menu and go to **Settings** > **Personalization**.
  2. Click the **Colors** tab and verify the settings.
  3. Click the **Fonts** tab and verify the settings.
  4. Ensure the fonts, sizes, and colors are identical on every machine where the _Workflow_ will run and also on the system used to record the _Workflow_.
Building JSONPath Expressions | MuleSoft Documentation
# Building JSONPath Expressions
JSONPath expressions navigate through a JSON structure in a similar way that XPath expressions reference parts of an XML document.
To simplify the process of creating JSONPath expressions, use the JSONPath Expression Builder included in RPA Builder. Open this tool by clicking () in the top menu bar or inside action steps that support JSONPath expressions (JSON Query, REST Call, and AWS action steps).
Opening the JSONPath Expression Builder from the top menu bar enables you to copy the resulting JSONPath expression for further use, instead of assigning it directly within an action step.
## Build an Expression Using the JSONPath Expression Builder
To create a JSONPath expression using the JSONPath Expression Builder:
  1. Click the **Build JSONPath Expression** () button.
  2. Click **Import from file** to explore and select a JSON file to open or paste the JSON directly in the textbox.
  3. Click **Next**.
  4. Click an object in the **JSON** panel to extract the object’s JSONPath Expression.
After clicking a JSON element, the **Result** panel updates to show what values the expression extracts and the **JSONPath expression** field updates to show the expression built to extract the specified value.
  5. Click **Next**.
  6. You can set filters for the expression at this point. See Set Filters for a JSONPath Expression for details.
  7. Click **Apply** to confirm and use the built JSONPath expression in the current action step.
Optionally, you can click the **Copy JsonPath expression to clipboard** () button to copy the expression.


For more information about JSONPath, see XPath for JSON.
## Set Filters for a JSONPath Expression
During the last step of creating a JSONPath expression, you can set filters by specifying the conditions before applying the expression created using the builder:
Click on any array element (`[*]`) of the resulting expression.  
---  
Select the conditions for the filter.  
Click the **Add new filter** () button.  
## See Also
  *   *
toDateTimeOrNull | MuleSoft Documentation
# toDateTimeOrNull
## toDateTimeOrNull(str: String, formatters: Array<Formatter>): DateTime | Null
Transforms a `String` value into a `DateTime` value using the first `Formatter` that matches with the given value to transform.
If none of the `Formatter` matches with the given value, the function returns a `null` value.
_Introduced in DataWeave version 2.5.0._
### Parameters
Name | Type | Description  
---|---|---  
The `String` value to transform into a `DateTime` value.  
`formatters` | Array<Formatter> | The `array` of formatting to use on the `DateTime` value.  
### Example
This example shows how `toDateTimeOrNull` behaves with different inputs. It produces output in the `application/dw` format.
#### Source
```
%dw 2.0
import * from dw::util::Coercions
output application/dw
---
{
 a: toDateTimeOrNull("2003-10-01 23:57:59Z", [{format: "uuuu/MM/dd HH:mm:ssz"}, {format: "uuuu-MM-dd HH:mm:ssz"}]),
 b: toDateTimeOrNull("2003-10-01 23:57:59Z", [{format: "uuuu/MM/dd HH:mm:ssz"}])
}
```

#### Output
```
{
 a: |2003-10-01T23:57:59Z| as DateTime {format: "uuuu-MM-dd HH:mm:ssz"},
 b: null
}
```
Set Event Processor | MuleSoft Documentation
# Set Event Processor
Anypoint Code Builder 
Anypoint Studio 
The Set Event Processor allows you to define a Mule Event. This message processor is normally used at the beginning of an MUnit test, to define the first message to send to the flow being tested.
The example below shows how to define a simple payload of a Mule Message:
```
<munit:set-event cloneOriginalEvent="false">
 <munit:payload value="#['payload_value']" mediaType="text/plain" encoding="UTF-8"/>
</munit:set-event>
```

The set-event has the cloneOriginalEvent property. If set to true, it clones the event produced by your code. By default, the value of this property is false.
The payload element in the Set Event processor has the following attributes:
Attribute Name | Description  
---|---  
Defines the value of the payload’s message.  
Defines the encoding of the message. This attribute is optional.  
`mediaType` | Defines the mime type of the message. This attribute is optional.  
You can also use the Set Event processor to define message attributes and event variables:
```
<munit:set-event cloneOriginalEvent="false">
 <munit:payload value="#['Example Body']" mediaType="text/plain" encoding="UTF-8"/>
 <munit:attributes value="#[{ method : 'GET', queryParams : { page : '1'}}]" />
 <munit:variables>
  <munit:variable key="variable_key" value="#['example']" mediaType="text/plain" encoding="UTF-8"/>
 </munit:variables>
</munit:set-event>
```

All the properties have the same set of attributes:
Table 1. Property Message Processor’s Attributes Attribute Name | Description  
---|---  
The key of the property being set.  
The content of the property.  
Defines the encoding of the message. This attribute is optional.  
`mediaType` | Defines the mime type of the message. This attribute is optional.  
You can define as many properties per each scope as you need for your test.
If you define two properties in the same scope with the _same_ key, be aware that one would end up overwriting the other.  
---  
## See Also
  * Testing and Mocking Errors
  * Fail Event Processor
  * Run Custom Event Processor
Amazon DynamoDB Connector | MuleSoft Documentation
# Amazon DynamoDB Connector
Amazon DynamoDB Connector v1.4
Anypoint Connector for Amazon DynamoDB (Amazon DynamoDB Connector) provides connectivity to the Amazon DynamoDB API. Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability.
For compatibility information and fixed issues, see the Amazon DynamoDB Connector Release Notes
## Common Use Cases for the Connector
Amazon DynamoDB Connector enables you to interact with Amazon DynamoDB to create a database table that can:
  * Store and retrieve any amount of data
  * Serve any level of request traffic
  * Automatically distribute the data and traffic for the table over a sufficient number of servers to manage the request capacity and the amount of data stored.
Amazon Dynamo DB Connector does this while maintaining consistent, fast performance.


## Before You Begin
To use this information, you must be familiar with:
  * The Amazon DynamoDB API
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * How to create a Mule app using Anypoint Studio


Before creating an app, you must have access to:
  * Amazon DynamoDB
  * AWS Identity and Access Management (IAM) user account credentials
  * Anypoint Studio version 7.0 or later


## Audience
  * Starting user
To create your Mule app, see Using Anypoint Studio to Configure Amazon DynamoDB Connector. The Examples topic provides one or more use cases for the connector.
  * Power user
Read the XML and Maven Support and Examples topics.


## Authentication Types
Amazon DynamoDB Connector supports the Basic and Role authentication types. For information about configuring these authentication types, see Using Anypoint Studio to Configure Amazon DynamoDB Connector.
## Next Step
After you complete the prerequisites and finish experimenting with templates and examples, you are ready to create a new app using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Using Anypoint Studio to Configure Amazon DynamoDB Connector
  * MuleSoft Help Center
Azure Key Vault Connector 1.0 | MuleSoft Documentation
# Azure Key Vault Connector 1.0
Anypoint Connector for Azure Key Vault (Azure Key Vault Connector) enables you to retrieve secrets, keys, or certificates, and encrypt or decrypt content.
For information about compatibility and fixed issues, refer to the Azure Key Vault Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Azure Key Vault Secrets 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 Azure Key Vault target resource
  * Anypoint Platform
  * Anypoint Studio version 7.3.5 or later


## Common Use Cases for the Connector
Some common use cases for Azure Key Vault Connector include:
  * Authenticating to Azure Key Vault via Client Secret Credential to access Key Vault secrets without exposing sensitive credentials in code, thus improving resilience and security
  * Enabling other applications in a Mule flow to have access to encrypt and decrypt operations using Azure Key Vault keys to avoid key rotations
  * Authenticating to other database and HTTP connectors in a more secure and automated way to fetch and use credentials to access other endpoints
  * Retrieving a certificate and saving the certificate into a file


## Connection Types
Azure Key Vault connections use the Connection authentication type, which uses a client ID, client secret, and cryptography client cache.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Azure Key Vault Connector Reference
  * MuleSoft Help Center
prependIfMissing | MuleSoft Documentation
# prependIfMissing
## prependIfMissing(text: String, prefix: String): String
Prepends the `prefix` to the beginning of the string if the `text` does not already start with that prefix.
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
The input string.  
The text to use as prefix.  
### Example
This example shows how `prependIfMissing` behaves with different inputs and sizes.
#### Source
```
%dw 2.0
import prependIfMissing from dw::core::Strings
output application/json
---
{
 "a": prependIfMissing(null, ""),
 "b": prependIfMissing("abc", ""),
 "c": prependIfMissing("", "xyz"),
 "d": prependIfMissing("abc", "xyz"),
 "e": prependIfMissing("xyzabc", "xyz")
}
```

#### Output
```
{
 "a": null,
 "b": "abc",
 "c": "xyz",
 "d": "xyzabc",
 "e": "xyzabc"
}
```

## prependIfMissing(text: Null, prefix: String): Null
Helper function that enables `prependIfMissing` to work with a `null` value.
_Introduced in DataWeave version 2.2.0._
SLA Tiers For API Groups | MuleSoft Documentation
# SLA Tiers For API Groups
As a Group Administrator, you can specify service-level agreement (SLA) tiers for API Groups instances to limit the number of requests an application (user) can make to the APIs in an API Group. SLAs enable you to protect your API Group instances and help manage network traffic to your APIs.
The SLA tier definition also determines whether access to the API Groups instance requires your approval. You can configure manual or automatic approvals to requests.
## SLA Types
SLA tiers are of two types:
  *   * Individual SLAs


## Default SLAs
The default limit applies to all API instances. This means that the same SLA limit is applicable to every API instance in that API Group.
If you add a new API instance to an API Group instance, the default limit SLA configured at the group instance level applies, unless an individual API SLA tier is also configured by the Group Administrator.
## Individual SLAs
As a Group Administrator, you can define individual limits for API instances within an API Group instance. If you have configured a default SLA limit at the API Group instance level and an individual SLA limit at the API instance level, the individual SLA overrides the default limit.
If no individual SLA is configured, then the default SLA limit is enforced for that API instance.
If the Rate Limiting policy is applied on an API instance, as a Group Administrator you must determine if the new SLA can be fulfilled by the underlying API instance.
## Manual and Automatic Approvals
When you configure automatic approvals for an SLA tier, requests made to the API instances with that tier applied are automatically approved. Consumers can instantaneously use API Group instances in this case.
Manual approvals are routed through a manual approval flow, where the API Group owner must manually approve the consumer request.
## Layered SLAs
API Groups supports multiple SLA limits. You can set multiple throughput limits for a single SLA tier. A single SLA tier named `Premium` can limit requests to 100 per second as well as limiting requests to 10,000 per day.
This strategy ensures that applications registered on a `Premium` tier do not exceed the top limit of 100 requests per second. This way, applications do not inundate the API, and registered applications get the expected 10,000 requests per day.
## See Also
  * Add SLA Tiers to API Groups
  * Remove SLA Tiers from API Groups
  * Manage Group Instance Contracts
Shopify Connector - Additional Configuration Information | MuleSoft Documentation
# Shopify Connector - Additional Configuration Information
After you complete basic Shopify Connector configuration, you can perform additional configuration tasks.
## Configure Shopify Metafield Values
To configure Shopify metafield values with Shopify Connector, add a custom query parameter to the operation. Shopify Connector doesn’t support creating new metafields; however, you can modify existing metafields using the predefined operations that support them.
For example, use the **Product Update** operation to get and update Shopify metafield values:
  1. In the **Advanced** tab of the **Product Update** operation configuration, in the **Query Parameters** field, select `Edit inline`.
  2. Add the metafield in the **Key** field and the API details in the **Value** field.


## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Troubleshooting Self-Managed Gateway with Debug Logs | MuleSoft Documentation
# Troubleshooting Self-Managed Gateway with Debug Logs
When troubleshooting Flex Gateway, set the runtime log level to `debug` for more verbose runtime logs.
This page explains how to configure debug runtime logs. To configure debug access logs, set the `level` parameter in your Message Logging policy to `DEBUG`.
## Debug Logs Configuration Example
For both Connected Mode and Local Mode, configure debug runtime logs using the following YAML configuration file:
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
 name: logging-config
spec:
 logging:
  runtimeLogs:
   logLevel: debug
```

To configure debug runtime logs, use the previous YAML configuration file when prompted for your configuration details in the following tutorials:
  * Configure External Logs in Connected Mode
  * Configure External Logs in Local Mode


If you have already configured a logging configuration file, set `logging.runtimeLogs.logLevel` to `debug` in you current file to enable debug runtime logs. This does not affect the log output location or access logs.
## See Also
To view runtime log output, see:
  * Viewing Runtime Logs in Runtime Manager in Connected Mode
  * Viewing Standard Output Logs
RPA Builder Overview | MuleSoft Documentation
# RPA Builder Overview
RPA Builder is the on-premise development environment that enables you to build the automations by specifying the tasks and steps of the process. With RPA Builder you can import a BPMN diagram generated in RPA Manager, and then drag and drop operations or record keyboard and mouse input to specify the action steps. You can also perform local testing of your workflow and when you finish building the process, you upload it to RPA Manager to move on to the testing phase.
RPA Builder enables you to:
  * Download and upload automation assets to RPA Manager.
  * Add the automation logic to the processes.
  * Run local tests for the automations.


## See Also
  * Hardware and Software Requirements
  * Installing and Configuring RPA Builder
toRadixNumber | MuleSoft Documentation
# toRadixNumber
## toRadixNumber(number: Number, radix: Number): String
Transforms a decimal number into a number string in other radix.
_Introduced in DataWeave version 2.2.0._
### Parameters
Name | Description  
---|---  
The decimal number.  
The radix of the result number.  
### Example
This example shows how the `toRadixNumber` behaves under different inputs.
#### Source
```
%dw 2.0
import toRadixNumber from dw::core::Numbers
output application/json
---
{
  a: toRadixNumber(2, 2),
  b: toRadixNumber(255, 16)
}
```

#### Output
```
{
 "a": "10",
 "b": "ff"
}
```
SAP S/4HANA OData Connector 2.6 | MuleSoft Documentation
# SAP S/4HANA OData Connector 2.6
Anypoint Connector for SAP S/4HANA OData (SAP S/4HANA OData Connector) provides support for the OData APIs exposed by SAP S/4HANA Cloud and SAP S/4HANA on-premise.
The connector enables you to perform operations to:
  * Create, get, update, and delete entities
  * Retrieve a single entity
  * Query multiple entities
  * Invoke a remote function
  * Execute batch requests that consist of multiple requests


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


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


## Common Use Case for the Connector
Perform CRUD operations on entity types of SAP S/4HANA’s OData API and process the response.
## Exchange Templates and Examples
Anypoint Exchange provides templates you can use as a starting point for your app, as well as examples that illustrate a complete solution.
## Next Step
After you complete the prerequisites and experiment with templates and examples, you are ready to create an app with Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * SAP S/4HANA OData Connector Release Notes
  * SAP S/4HANA OData Connector on Exchange
  * MuleSoft Help Center
Hardening Mule Runtime on Runtime Fabric | MuleSoft Documentation
# Hardening Mule Runtime on Runtime Fabric
By design, Runtime Fabric automatically applies and enables hardening measures for your Mule applications. By following containerization best practices, isolation at the Mule and application level is achieved by default.
The following hardening checklist provides additional information and best practices for Mule hardening with Runtime Fabric.
## Hardening Checklist
Table 1. Mule Hardening Procedure Hardening Step | Action Required  
---|---  
Run Mule as a non-privileged User. | Runtime Fabric provides this functionality.  
Install Mule as a Service | Runtime Fabric provides this functionality by deploying a Mule runtime engine for each application within its own container.  
Configure Mule to write logs or temporary files within appropriate locations. Configure logs, passwords, and keystore files. | Runtime Fabric provides this functionality. Mule writes to a temporary file system that is deleted when the application terminates. Monitoring information is collected from a sidecar agent in a specific location on disk where metrics are outputted and stored. Logs are collected from standard output streams.  
In some situations, you must configure usernames, passwords, and keystores on Mule. Usually, these settings are made available externally, so that DevOps can change these settings. | Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.  
Manage certificates in a keystore file. | This is supported on Runtime Fabric, but you must import the certificates into the keystore.  
Use a separate property file to store usernames and passwords and secure it using file system permissions. | Runtime Fabric provides this functionality. Refer to Manage Secure Properties in Runtime Fabric for additional information.
EDIFACT EDI Connector 2.10 Supported Versions | MuleSoft Documentation
# EDIFACT EDI Connector 2.10 Supported Versions
This connector supports these EDIFACT versions with supplied schema definitions for all standard messages.
D.01B.EAN003  
---  
D.01B.EAN004  
D.01B.EAN005  
D.01B.EAN006  
D.01B.EAN007  
D.01B.EAN008  
D.01B.EAN010  
D.93A.EAN001  
D.93A.EAN002  
D.93A.EAN003  
D.93A.EAN004  
D.93A.EAN005  
D.93A.EAN007  
D.96A.EAN001  
D.96A.EAN002  
D.96A.EAN003  
D.96A.EAN004  
D.96A.EAN005  
D.96A.EAN006  
D.96A.EAN008  
## See Also
  * MuleSoft Help Center
Migrating API Gateways: Mule Runtime Configuration | MuleSoft Documentation
# Migrating API Gateways: Mule Runtime Configuration
Configuration properties for API Gateway Runtime changed in Mule 4.
These properties have to be defined in the `wrapper.conf` for Mule 3 to work as API Gateway:
```
-M-Danypoint.platform.client_id=clientId
-M-Danypoint.platform.client_secret=clientSecret
-M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform
-M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts
-M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs
-M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com
```

Starting from Mule 4, these properties have to be defined in the `wrapper.conf` in order to work as an API Gateway:
```
-M-Danypoint.platform.client_id=clientId
-M-Danypoint.platform.client_secret=clientSecret
-M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com
-M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com
```

## See Also
Migrating API Gateways
Migrating API Gateways: Autodiscovery
Migrating API Gateways: Policies
Amazon Redshift Connector 1.0 | MuleSoft Documentation
# Amazon Redshift Connector 1.0
Anypoint Connector for Amazon Redshift (Amazon Redshift Connector) is a bulk-load connector that enables you to connect to Amazon Redshift database to perform inserts, deletes, updates, and to execute SQL queries.
For compatibility information and fixed issues, see the Amazon Redshift Connector Release Notes.
## Before You Begin
To use this connector, you must be familiar with:
  * The Amazon Redshift API
  * Anypoint Connectors
  * Mule runtime (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


Before creating an app, you must have:
  * Credentials to access the Amazon Redshift target resource
  * Anypoint Platform
  * Anypoint Studio 7.3 or later


## Common Use Cases for the Connector
Some possible uses for this connector include:
  * Analytics
Amazon Redshift operates as an optimized data warehouse that can store large volumes of data, which can then be analyzed using a business intelligence (BI) tool such as Tableau.
  * Real-time processing of social media feeds
Stream data from your social media feeds, such as a Twitter feed, into Amazon Kinesis Data Streams, and then store that data in a data warehouse, such as Amazon Redshift to perform real-time analytics.


## Authentication Types
Amazon Redshift Connector uses the following connection methods:
  * Basic authentication, which uses **user** and **password** field values to connect to the database
  * IAM authentication, which uses **access key** and **secret key** field values to retrieve the temporary password for the specified user in order to connect to the database


## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Amazon Redshift Reference
  * MuleSoft Help Center
Implementation Errors | MuleSoft Documentation
# Implementation Errors
Cloud IDE 
Desktop IDE 
**Open Beta Release** : The **cloud IDE is in open beta**. Any use of Anypoint Code Builder in its beta state is subject to the applicable beta services terms and conditions, available from the IDE.
You might encounter problems when implementing an API.
## Something Failed While Scaffolding an API
Anypoint Code Builder supports scaffolding these schema fragment files if they’re referenced from API specs:  
If you add a fragment that isn’t supported, the scaffolder doesn’t add these fragments as project dependencies when you import the spec from Exchange. However, you can scaffold schemas that are specified inline within the spec.
If you attempt to scaffold an API that references these types of fragments, you see a message like the following:
**Something failed while scaffolding API**
The scaffold fails and the flows and other elements aren’t created. To see scaffolding errors, select **Mule DX Server: Scaffolding** from the list in the output panel.
If you use the iterative approach to scaffold the API (using multi-root workspaces), the implementation project folder structure is not created.
To work around this issue, before scaffolding the API:
  1. Add the fragment directly to a folder in your API spec project, such as `fragments`:
  2. Change the path to the fragment from Exchange to the local folder, for example:
     * Reference Local OAS Fragment
     * Reference OAS Fragment on Exchange
```
$ref: fragments/frag-defs.yaml#/components/examples/flightsList
```

```
$ref: exchange_modules/e91cab06-650b-4634-9c6f-5bc4f4fc4d17/frag-defs/1.0.0/frag-defs.yaml#/components/examples/flightsList
```

  3. Re-scaffold the API.


See Create and Add a Fragment Directly in Your Spec.
## See Also
  * Implementing OAS, RAML, and GraphQL APIs
  * Iteratively Design and Implement APIs
last | MuleSoft Documentation
# last
## last(text: String, amount: Number): String
Returns characters from the end of string to a specified number of characters, for example, the last two characters of a string.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The string to process.  
The number of characters to return. Negative numbers and `0` return an empty string. Decimals are rounded up to the nearest whole number.  
### Example
This example returns the last six characters from a string.
#### Source
```
%dw 2.0
import last from dw::core::Strings
output application/json
---
"hello world!" last 6
```

## last(text: Null, amount: Any): Null
Helper function that enables `last` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
Managing Apps Deployed to CloudHub 2.0 | MuleSoft Documentation
# Managing Apps Deployed to CloudHub 2.0
  * Updating Apps Deployed to CloudHub 2.0
  * Managing App Schedules
  * Changing App Behavior with Properties
  * Protecting App Property Values
  *   * Automatic App Restarts
JSON Module | MuleSoft Documentation
# JSON Module
JSON Module v2.1
The JSON module provides extra functionality for processing JSON documents. Although DataWeave is the tool that Mule uses to access data in JSON documents, this module provides extra functionality that falls outside of DataWeave’s scope, like schema validation.
Release Notes: JSON Module Release Notes Exchange: JSON Module
## See Also
  * ValidateDocuments against a JSON Schema with the JSON Module
  * JSON Module Reference
  * MuleSoft Help Center
Workday Connector 16.4 XML and Maven Support | MuleSoft Documentation
# Workday Connector 16.4 XML and Maven Support
Although you can manually code a Mule app in XML, it is more efficient to use Anypoint Studio:
  * If you manually code a Mule runtime engine (Mule) app in XML, either from the Anypoint Studio XML editor or from a text editor, you can access the connector from your app by adding reference statements to both your XML Mule flow and the Apache Maven `pom.xml` file.
  * If you add the connector in Studio, Studio automatically populates the XML code with the connector’s namespace and schema location and it also adds a dependency to the `pom.xml` file.


## Add a Namespace for the Connector
Paste the following code inside the `mule` tag of the header of your configuration XML:
```
http://www.mulesoft.org/schema/mule/workday
http://www.mulesoft.org/schema/mule/workday/current/mule-workday.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<mule xmlns:$2="http://www.mulesoft.org/schema/mule/workday"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/workday
	http://www.mulesoft.org/schema/mule/workday/current/mule-workday.xsd">
```

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

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


## Next Step
After completing your namespace and `pom.xml` file, you can try the Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Object Store Connector | MuleSoft Documentation
# Object Store Connector
**Reference:** Object Store Connector Reference
Object Store Connector is a Mule component that allows for simple key-value storage. Although it can serve a wide variety of use cases, it is mainly design for:
  * Storing synchronization information, such as watermarks.
  * Storing temporal information such as access tokens.
  * Storing user information.


Additionally, Mule Runtime uses Object Stores to support some of its own components, for example:
  * The Cache module uses an Object Store to maintain all of the cached data.
  * The OAuth module (and every OAuth enabled connector) uses Object Stores to store the access and refresh tokens.


## Object Store Limitations
Object Stores are not a universal solution for data storage. They do not replace a database, and they are not suitable for every use case. Most importantly, they do not support transactional access or modification. For use cases in which ACID semantics are needed, or for cases where you expect the same key to be updated in parallel, consider another solution.
## Use the Default Object Store
By default, each Mule app has an Object Store that is persistent and always available to the app _without any configuration_. Flows can use it to persist and share data.
If you want to use the default Object Store, you can specify a `key` for the Object Store without selecting or creating an Object Store reference for the Object Store operation, and without specifying an `objectStore` attribute in the XML element for the Object Store component.
The Mule app is deployed to CloudHub workers using Anypoint Platform Runtime Manager, but the contents of the default Object Store are not visible in Runtime Manager in the **Application Data** page for the app.
It is important to understand that the only Object Store displayed in the Runtime Manager Application Data tab is the default Object Store.
## Use a Custom Object Store
Custom Object Stores must specify an `objectStore` attribute. These Object Stores can be configured to behave differently than the default Object Store. For example, you can indicate whether the Object Store is persistent (so that the Object Store data survives a Mule Runtime crash) or transient (where data does not survive a Mule Runtime crash). Here are some common reasons for defining custom Object Stores:
  * You want to partition your information by storing it in different Object Stores.
  * You want to use advanced Object Store features such as these:
    * Transient/Persistent storage.
    * Specification of a time to live (TTL).
    * Specification of a max capacity.
  * You want to keep different components from sharing state by feeding them with different Object Stores.
  * You want different components to share information by feeding them with the same Object Stores.


## See Also
  * Define an Object Store
  * Store and Retrieve information from an Object Store
  *   * Object Store Connector Release Notes
  * Object Store Connector in Anypoint Exchange
CLI for CloudHub | MuleSoft Documentation
# CLI for CloudHub
Anypoint CLI supports managing these CloudHub features:
  * CloudHub Applications
  * CloudHub Dedicated Load Balancers
  * Anypoint Virtual Private Cloud