BassemE/mulesoft-documentation-embeddings huggingface dataset:
HMACBinary | MuleSoft Documentation
# HMACBinary
## HMACBinary(secret: Binary, content: Binary, algorithm: String = "HmacSHA1"): Binary
Computes an HMAC hash (with a secret cryptographic key) on input content.
See also, `HMACWith`.
### Parameters
Name | Description  
---|---  
The secret cryptographic key (a binary value) used when encrypting the `content`.  
The binary input value.  
`algorithm` |  The hashing algorithm. `HmacSHA1` is the default. Valid values depend on the JDK version you are using. For JDK 8 and JDK 11, `HmacMD5`, `HmacSHA1`, `HmacSHA224`, `HmacSHA256`, `HmacSHA384`, and `HmacSHA512` are valid algorithms. For JDK 11, `HmacSHA512/224` and `HmacSHA512/256` are also valid.  
### Example
This example uses HMAC with a secret value to encrypt the input content.
#### Source
```
%dw 2.0
import dw::Crypto
output application/json
---
{
 "HMACBinary" : Crypto::HMACBinary("confidential" as Binary, "xxxxx" as Binary, "HmacSHA512")
}
```

#### Output
```
{
 "HMACBinary": "\ufffd\ufffd\ufffd\ufffd^h\ufffd!3\u0005\ufffd֎\u00017\ufffd\ufffd\ufffd`\ufffd8?\ufffdjn7\ufffdbs;\t\ufffdƅ\ufffd\ufffd\ufffdx&g\ufffd~\ufffd\ufffd%\ufffd7>1\ufffdK\u000e@\ufffdC\u0011\ufffdT\ufffd}W"
}
```
Salesforce Connector 11.1 XML and Maven Support | MuleSoft Documentation
# Salesforce Connector 11.1 XML and Maven Support
If you manually code a Mule app in XML either from the Anypoint Studio XML editor or a text editor, perform the following actions to get access to the connector:
  * Add the namespace for the connector to your XML flow.
  * Add dependency information to your Maven `pom.xml` file.


In the Studio visual editor, when you drag a connector from the palette to the canvas, Studio automatically populates the XML code with the connector namespace and schema location.
## Add a Namespace for the Connector
Paste the following code inside the `<mule>` tag of the header of your configuration XML:
```
http://www.mulesoft.org/schema/mule/salesforce
http://www.mulesoft.org/schema/mule/salesforce/current/mule-salesforce.xsd
```

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

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

Replace `x.x.x` with version information from Exchange. Ensure the connector version corresponds to the one 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 `salesforce`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## Next
After completing your namespace and `pom.xml` file, you can try the Salesforce Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Web Service Consumer Connector 2.0 | MuleSoft Documentation
# Web Service Consumer Connector 2.0
Anypoint Connector for Web Service Consumer (Web Service Consumer Connector) consumes a SOAP web service from a Mule app to acquire data from an external source. In many cases, you can use Anypoint Connector for Workday (Workday Connector) or Anypoint Connector for ServiceNow (ServiceNow Connector) to connect to a service provider, however, when no connector is available for a specific web service, the easiest way to consume the service is to use the Web Service Consumer Connector.
The main features of the connector include:
  * Ability to consume DOC literal web services
  * Use of SOAP multipart messages
  * Use of SOAP headers
  * Support for a DataSense for SOAP headers, SOAP body, and attachments
  * Use of embedded DataWeave transformations inside the operation
  * Support for a unified experience for SOAP with attachments and MTOM handling
  * Custom HTTP configuration as a transport
  * Support for Web Service Security (WS Security)


Web Service Consumer Connector doesn’t support RPC WSDLs (Remote procedure call Web Service Descripting Language).   
---  
## Before You Begin
To use this connector, you must be familiar with:
  * SOAP and WSDLs
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements in a Mule flow
  * Global elements
  * DataWeave
  * Creating a Mule app using Anypoint Studio


Before creating an app, you must have access to Anypoint Studio.
## Next Step
After you complete the prerequisites, you are ready to create an app and configure the connector using Anypoint Studio.
## See Also
  * Introduction to Anypoint Connectors
  * Use Exchange to Discover Connectors, Templates, and Examples
  * Web Service Consumer in Exchange
  * MuleSoft Help Center
Configuring a Liveness Check in Local Mode | MuleSoft Documentation
# Configuring a Liveness Check in Local Mode
Flex Gateway includes the following CLI command to test gateway health:
```
flexctl probe --check=liveness
```

If the Flex Gateway instance is running normally, the command returns an exit code of `0`. Otherwise, the gateway is unhealthy and the command returns a `1`.
You can either run the liveness check command manually or configure the command to run automatically. By default, Flex Gateways deployed on Kubernetes have an automatic liveness probe configured. The liveness probe periodically runs the liveness check command and automatically restarts the Flex Gateway pod after a specified number of failed liveness checks.
Docker and Linux deployments do not have preconfigured liveness probes.
## Before You Begin
  1. Download Flex Gateway.
  2. Register and Run Flex Gateway.


## Configure a Kubernetes Liveness Probe
By default, Flex Gateways running on Kubernetes include a liveness probe configured in the Helm chart. The liveness probe automatically runs `flexctl probe --check=liveness` at an interval of 10 seconds and restarts unhealthy pods after 5 failed tests.
The liveness probe is configured by default with the following values:
```
livenessProbe:
 exec:
  command:
  - flexctl
  - probe
  - --check=liveness
 initialDelaySeconds: 10
 periodSeconds: 10
 failureThreshold: 5
 timeoutSeconds: 1
```

Parameter | Description  
---|---  
`exec.command` | The liveness check command  
`initialDelaySeconds` | The time in seconds to wait after startup before executing the first liveness test  
`periodSeconds` | The period in seconds between each liveness check  
`failureThreshold` | The number of failed liveness tests before the Kubernetes pod is restarted  
`timeoutSeconds` | The time in seconds before the test times out  
To modify the default liveness probe parameters, you must update your Helm chart. You can modify these parameters during or after the initial installation of the Helm chart. For more information about how to modify a Helm chart, see Update Pod Settings for a Flex Gateway Deployment Through a Helm Chart
## Docker and Linux Liveness Probes
For Docker or Linux deployments, there is no default liveness probe configured to check health or restart unhealthy Flex Gateways. However, you can still run the liveness check command manually or configure it for automated use with third-party services. Besides the Kubernetes liveness probe, MuleSoft does not provide support for third-party liveness probes or health checks.
One method of running the liveness check command with Docker is to configure `HEALTHCHECK` in your `docker run` command. For more information, see Docker run HEALTHCHECK.
## See Also
  * Configure Liveness, Readiness and Startup Probes.
  *
Console Mocking Service Not Loading | MuleSoft Documentation
# Console Mocking Service Not Loading
If the console shows a spinning icon and never loads the mocking service:
  1. Open Salesforce setup.
  2. Open the **Named Credentials** configuration.
  3. Ensure that the Anypoint Platform credentials for the data bridge are configured as described in Manual Setup.
seconds | MuleSoft Documentation
# seconds
## seconds(nSecs: Number): Period
Creates a Period value from the provided number of seconds.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The number of seconds as a whole or decimal number. A positive or negative number is valid.  
### Example
This example shows how `seconds` behaves with different inputs. It adds and subtracts seconds from DateTime values. It also converts the decimal value `4.555` into the Period format (`PT4.555S`) and and the whole number `4` into the Period format (`PT4S`)
#### Source
```
%dw 2.0
import * from dw::core::Periods
output application/json
---
{
 nextSecond: |2020-10-05T20:22:34.385Z| + seconds(1),
 previousSecond: |2020-10-05T20:22:34.385Z| - seconds(1),
 decimalInputPeriod: seconds(4.555),
 wholeNumberInputPeriod: seconds(4),
 addNegativeValue: seconds(-1) + seconds(2)
}
```

#### Output
```
{
 "nextSecond": "2020-10-05T20:22:35.385Z",
 "previousSecond": "2020-10-05T20:22:33.385Z",
 "decimalInputPeriod": "PT4.555S",
 "wholeNumberInputPeriod": "PT4S",
 "addNegativeValue": 1
}
```
X12 EDI Connector 2.12 | MuleSoft Documentation
# X12 EDI Connector 2.12
Support Category: Premium
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.
## Prerequisites
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
X12 EDI Connector templates provide starting points that help you:
  * Map application messages to outbound X12 transactions 
  * Map inbound X12 transactions to the application message format
  * Set up your Partner Manager content storage


### X12 EDI Connector Examples in Exchange
X12 EDI Connector examples in Exchange enable you to:
  * Customize an X12 EDI schema for B2B integrations
  * Transform outbound purchase order XML messages to X12 850 transactions
  * Transform inbound X12 850 transactions to JSON purchase orders
  * Transform outbound XML messages into X12 purchase orders, inbound X12 purchase orders into JSON, and generate a functional acknowledgement
  * Implement an end-to-end order to cash workflow from the perspective of a seller
  * Implement an end-to-end B2B procure to pay workflow from the perspective of a buyer


## 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
Configuring Chatter Feed Tracking | MuleSoft Documentation
# Configuring Chatter Feed Tracking
To engage with your portal community, add Chatter Feed tracking. Chatter tracking enables portal members to create discussions about APIs, get real-time updates and notifications, seek expert advice, and review relevant discussions.
For existing API portals, you must add the Feed and Feed Publisher components manually using the Experience Builder.
## Enable Feed Tracking
  1. In Salesforce, click **Setup**.
  2. In the **Quick Find** box, enter **feed tracking** and click **Feed Tracking**.
  3. Select **Community Asset** and **Enable Feed Tracking**.
  4. Click **Save**.


## Add Feed Components For Existing API Portals
To add Feed components for existing portals:
  1. Navigate to the Builder.
  2. In **Preview** mode, on the **API details** page, click **Back to Builder**.
  3. Click **Components** , then click the **Tab Layout (New)** component.
  4. In the **Tab Layout (New)** dialog, click **Add**.
  5. In the **Tab Name** field, enter **Feedback and discussions** or any name for the tab and then click **Save**.
  6. Click **Save**.
  7. Click **Components** and enter **Feed** in the **Search** box.
  8. Drag the **Feed** and **Feed Publisher** components into the **Tab Layout (New)** area for **Feedback and discussions**.


## See Also
  * Configure Feed Component
  * Configure Feed Publisher Component
To Deploy an Application to CloudHub (EU Control Plane) | MuleSoft Documentation
# To Deploy an Application to CloudHub (EU Control Plane)
The procedures for deploying an application to CloudHub in the EU control plane is similar to those in the US control plane. See Deploying to CloudHub.
However, consider the following differences when deploying to the EU control plane.
  * The EU control plane supports a smaller number of Mule runtimes than the US control plane.
  * The domain name of CloudHub workers is `<app_name>.de.eu1.cloudhub.io`.
  * You can only deploy to the Frankfurt or Dublin regions from the EU control plane.
  * Applications deployed to the EU control plane use Object Store v2.


## See Also
  * About Object Store in the EU Control Plane
  * EU Control Plane
  * To Access the EU Control Plane
Automation Credits Usage and Rates | MuleSoft Documentation
# Automation Credits Usage and Rates
Your MuleSoft Automation subscription plan includes a quota of Automation Credits that depletes as you create and execute automations.
Credit usage rates differ for different subscription plans. Refer to the article that corresponds to your subscription plan as shown in the following table:
Subscription Plan | Conversion Rate Sheet  
---|---  
  * Automation Starter
  * Automation Advanced
  * Automation for vCore/Core
  * Additional Automation Credits

| MuleSoft Automation Credits 2.0  
  * MuleSoft - Automation
  * MuleSoft - Automation - (Gold, Platinum, Titanium Edition)
  * MuleSoft - Automation for Salesforce
  * MuleSoft - Automation for Salesforce - (Gold, Platinum, Titanium Edition)
  * MuleSoft - Automation - Additional Credits (100)
  * MuleSoft - Automation - Additional Credits (100) - (Gold, Platinum, Titanium)

| MuleSoft Automation Credits 1.0  
For more information on usage and pricing metrics, see Metrics Collected in Anypoint Platform.
## Monthly Account Summary Emails
Salesforce sends usage-based billing reports to every MuleSoft Composer customer on the 10th of each month. By default, Salesforce sends these emails to the account’s billing contact.
For additional information about the reports, the list of recipients, and other details, see the Monthly Account Summary Email FAQ.
## Access Composer with MuleSoft Automation Package
To access Composer with the MuleSoft Automation package, first grant access to users and then log in to Anypoint Platform and open Composer.
### Admin: Grant Access to Composer Users
To access Composer via Anypoint Platform, the Anypoint Admin must first:
  1. Create an Anypoint Platform Account for the users.
  2. Grant one of the following roles to each user:
    1. **Composer Base User** : This user can create and manage their own flows.
    2. **Composer Super User** : This user can create and manage their own flows. Additionally, this user can take ownership and manage any flows in the Anypoint Composer org. The Usage Summary is only available to those with the Composer Super User role.


### Access Composer with the MuleSoft Automation Package
To access Composer with the MuleSoft Automation Package:
  1. Log in to Anypoint Platform.
  2. On the **Anypoint Platform** page, click **Go to Composer**.


## See Also
  * Mulesoft Composer: Overview
  * MuleSoft Composer: Getting Started
  * Composer Connector Reference
  * Knowledge Articles
Connected Apps for Developers | MuleSoft Documentation
# Connected Apps for Developers
Anypoint Platform provides a comprehensive set of APIs to extend functionality.
The Connected Apps feature enables you to:
  * Delegate access to applications that use APIs to interact with Anypoint Platform programmatically.
  * Build CI/CD pipelines or productize additional third-party use cases on top of Anypoint Platform.
  * Enable or disable clients and view client usage. For example, you can see how many organizations are using the app and how many users have access.


## Authentication
The Connected Apps feature supports OAuth 2.0 and OpenID Connect, so you must ensure your app can use tokens to request access to user data.
See the information in the Open ID configuration discovery endpoint to find the supported OpenID Connect capabilities.
To make the authentication experience consistent for end users, third-party developers with their own websites or web apps can allow users to sign in using the **Sign in with Anypoint Platform** option.
## Application Allowlist
Organization administrators can enable an allowlist to control which apps can access the organization’s user data.
When your app is added to an allowlist, only the set of scopes associated with the app are reviewed and approved by the administrator. If you add new scopes to your app later, you’re unable to request those scopes from users until the admin reapproves your app. Existing authorizations and new authorizations using the previously allowlisted set of scopes continue to work.
For more information, see connected apps for administrators.
## See Also
  * Access Management API - Connected App Examples
  * Creating Connected Apps
  * Connected Apps for Organization Administrators
Reordering Policies | MuleSoft Documentation
# Reordering Policies
In Mule Gateway, to execute certain policies before others, you can configure the order of execution of included and custom API level policies. However, you cannot configure API level policies to execute before automated policies.
You reorder policies via API Manager.
You cannot configure the execution order of the Cross-Origin Resource Sharing (CORS) policy. In Mule Gateway, the CORS policy executes before automated and API level policies.   
---  
## Mule Gateway
To reorder policies in Mule Gateway:
  1. Go to **Anypoint Platform > API Manager**.
  2. In **API Administration** click the name of the API whose policies you want to reorder.
  3. From the left navigation menu, click **Policies**.
  4. From the top of the list of the applied policies, click **Reorder policies**.
  5. From the **Reorder Applied Policies** section, use the up and down arrows to rearrange the order of policies.
  6. Click **Apply order**.


## See Also
  * Included Policies Directory
APIkit for REST Error Handling Reference | MuleSoft Documentation
# APIkit for REST Error Handling Reference
When something goes wrong with a part of your flow, you get a message with an error type.
## APIkit for REST Error Types
APIkit for REST defines the following error types:
Error Type | Description  
---|---  
APIKIT:BAD_REQUEST | Bad request  
APIKIT:NOT_FOUND | Resource not found  
APIKIT:METHOD_NOT_ALLOWED | Method not allowed  
APIKIT:NOT_ACCEPTABLE | Not acceptable  
APIKIT:UNSUPPORTED_MEDIA_TYPE | Unsupported media type  
APIKIT:NOT_IMPLEMENTED | Not implemented  
## APIkit for REST Error Handling
APIkit scaffolder generates error-handling code based on the most widely used HTTP status code responses, which are mapped to the error types and messages described as follows:
Status Code | Error Type | Response Message  
---|---|---  
APIKIT:BAD_REQUEST | Bad request  
APIKIT:NOT_FOUND | Resource not found  
APIKIT:METHOD_NOT_ALLOWED | Method not allowed  
APIKIT:NOT_ACCEPTABLE | Not acceptable  
APIKIT:UNSUPPORTED_MEDIA_TYPE | Unsupported media type  
APIKIT:NOT_IMPLEMENTED | Not implemented  
## APIkit for REST Example Error
The following code shows an error handler for an HTTP 400 response, which you can use to build your own custom status codes and messages.
```
...
  <on-error-propagate type="APIKIT:BAD_REQUEST" doc:name="On Error Propagate">
    <ee:transform xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
      <ee:message>
        <ee:set-payload><![CDATA[%dw 2.0
  output application/json
  ---
  {message: "Bad request"}]]></ee:set-payload>
      </ee:message>
      <ee:variables>
        <ee:set-variable variableName="httpStatus">400</ee:set-variable>
      </ee:variables>
    </ee:transform>
  </on-error-propagate>
...
```

The main flow transmits an HTTP error response that encompasses an HTTP status code paired with an associated message expressed in clear and straightforward language. In this example, `message: "Bad request"`.
## See Also
  *
CIM Sell Subject Area | MuleSoft Documentation
# CIM Sell Subject Area
Anything you plan to sell or any part of a product that needs to be tracked for service purposes. For example, you are selling a green tractor.
## Model Diagrams
The following diagrams show the entities and relationships in this subject area, organized by entity group.
## Implementation
## See Also
  *   * CIM Design Elements
  *   *
SMART on FHIR with Okta | MuleSoft Documentation
# SMART on FHIR with Okta
See the Okta SMART on FHIR - Implementation Template asset, which walks you through how to set up a reference SMART on FHIR implementation on Anypoint Platform using Okta as the identity provider.
The **S** ubstitutable **M** edical **A** pplications and **R** eusable **T** echnology (SMART) is a web/mobile app, which is typically embedded in EHR but can also serve as a standalone smartphone app. SMART on FHIR provides a consistent approach to security and data requirements for health applications. It also provides a workflow to securely request access to data, receive the data, and use the data.
SMART on FHIR addresses the following three key aspects:
  * Identity and access management by using the OpenID Connect identity management protocol with different categories of scopes
    * Clinical data (example, `patient/Observation.read`)
    * Contextual data (example, `launch/patient`)
    * Identity data (example, `openid fhirUser`)
  * Access to the data using FHIR based APIs
  * Launch workflow for different use cases such as:
    * Patient apps that launch standalone
    * Patient apps that launch from an EHR portal
    * Provider apps that launch standalone
    * Provider apps that launch from an EHR portal


Anypoint platform supports SMART on FHIR in the following ways:
  * Identity and access management
    * Provisioning third-party OIDC client provider like Okta for identity management
    * Out-of-the-box OpenID Connect token enforcement policy
    * Leverage OAuth provider information in the `authentication` object for custom policy
  * Access to the data using FHIR based APIs
    * MuleSoft Accelerator for Healthcare provides FHIR R4 specifications for all the FHIR resources
    * Out-of-the-box cross origin resource sharing (CORS) policy enables cross origin data exchange.


## See Also
  *   * MuleSoft Accelerator for Healthcare
Confirm Alert Box | MuleSoft Documentation
# Confirm Alert Box
This _Web Automation_ object allows you to confirm or dismiss _JavaScript_ Alert Boxes, and enter text in _JavaScript_ input boxes.
## Properties
**Action on Messagebox** Decide whether to accept a message box (equivalent to clicking _OK_) or dismiss it (equivalent to clicking _Cancel_). If you are handling an input box (a message box with a text input field) and want to enter text, set this to _Enter Text_.
**Text to send** Text that should be entered. Only applicable for message boxes with a text input field when _Action on Messagebox_ is set to _Enter Text_.
## Inbound Variables
**Action on Messagebox** Decide whether to accept a message box (equivalent to clicking _OK_) or dismiss it (equivalent to clicking _Cancel_). If you are handling an input box (a message box with a text input field) and want to enter text, set this to _Enter Text_.
## Outbound Variables
The action step _Confirm Alert Box_ possesses no outbound variables.
## Wizard
_JavaScript_ pop-ups are a bit difficult to identify. They look slightly different in each browser, but they always look a bit like system dialogs.
Screenshot | MuleSoft Documentation
# Screenshot
This action step takes a screenshot and saves it to the trace folder. You can use this screenshot to get feedback on what is happening at any point in a _Workflow_ , which is specially helpful for debugging _Workflows_ running on distant machines.
## Properties
  * **Capture Area**
    * **Height**
The height of the screenshot. Set _Height_ **and** _Width_ to 0 to capture the whole screen.
    * **Image Type**
Determines if the screenshots will be saved as compressed JPG files or uncompressed BMP files or loss-free compressed PNG files.
    * **Shrink to [%]**
Size in % to which the image shall be reduced to. This value refers to the length and the width of the image and not to its area or file size. You can enter any integer between 10 and 100. The default value is 50% for newly created Workflows and 100% for Workflows created with an older version of RPA Builder.
    * **Width**
The width of the screenshot. Set _Height_ **and** _Width_ to 0 to capture the whole screen.
    * **X Coordinate/Offset**
Defines the x-coordinate (horizontal axis) of the screenshot. If _Capture relative to_ is set to anything other than _None_ , this defines the horizontal offset from the relative coordinates.
    * **Y Coordinate/Offset**
Defines the y-coordinate (vertical axis) of the screenshot. If _Capture relative to_ is set to anything other than _None_ , this defines the vertical offset from the relative coordinates.
  * **Custom Folder Settings**
    * **Filename**
Defines which name the saved screenshot file should have. Leave empty for automatic name generation.
    * **Path**
Where the screenshot is saved to.
    * **Use Custom Settings**
Specifies whether to save the screenshot in a custom folder with a custom name. If not selected, screenshots will be saved within the usual trace folder (and will subsequently be part of analysis packages).


## Wizard
  * **Define Screenshot Area**
It is possible to restrict the screenshot to a certain part of the screen. This area is captured in the same way as described in the section Add pattern from screen capture (Capture Pattern).
  * **Set to full screen**
Captures the entire screen.
  * **Image Size [%]**
Size in percent, to which the image shall be reduced to. In the Wizard you can set this value in steps of 10 with the help of the slider. In the Properties you can enter any integer between 10 and 100.
The percentage given refers to the length and the width of the image and not to the image’s file size or its area. For example if you set the reduction to Shrink To 50%, the area of the image is reduced to 25%.
The default value for newly created Workflows is set to 50%.
  * **Capture relative to**
Takes a screenshot relative to a previous _Image Search_ result.
Caching | MuleSoft Documentation
# Caching
Identifying key aspects of your data such as when to use cache and which cache strategy to follow, helps you to improve processing performance:
  * Is the data frequently called, with often repeated results?
  * Can you afford eventual consistency between the data source and the cache information? At least for a while until cache refreshes.


Mule runtime engine (Mule) offers customizable strategies, such as the Cache scope and the HTTP Caching API Gateway policy, to enable cache according to your needs. Both strategies help applications that constantly request the same data by reducing the processing load, especially network interactions with a remote host.
For Cache scope, consider a production environment in which the default in-memory caching consumes all of your memory resources. To avoid this consumption, use an object-store caching configuration with well-defined storage and expiry policies.
## See Also
  *   *
Configuring PROXY Protocol in Connected Mode | MuleSoft Documentation
# Configuring PROXY Protocol in Connected Mode
For use cases when Flex Gateway is deployed behind a load balancer or other proxy service, configure PROXY protocol to preserve client IP addresses across multiple layers of NAT or TCP proxies.
In PROXY protocol, the load balancer or other proxy service sends the PROXY protocol header containing the client address and additional information to Flex Gateway. To learn more about PROXY protocol, see the HAProxy specification.
Enabling PROXY protocol only enables Flex Gateway to receive the PROXY protocol header. Your load balancer or other proxy service must support PROXY protocol to transmit the header.
Enable PROXY Protocol for Flex Gateway as a Linux Service |  Enable PROXY Protocol for Flex Gateway in a Docker Container |  Enable PROXY Protocol for Flex Gateway in a Kubernetes Cluster  
---|---|---  
## Before You Begin
Before enabling PROXY protocol for Flex Gateway, complete the following tasks:
  1. Download Flex Gateway
  2. Register and Run Flex Gateway


## Enable PROXY Protocol for Flex Gateway as a Linux Service
  1. Create a YAML configuration file in the Flex Gateway configuration directory:
```
sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml
```

  2. Update the file with the PROXY protocol configuration file:
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
 name: config
spec:
 proxyProtocol:
  enabled: true
```



## Enable PROXY Protocol for Flex Gateway in a Docker Container
If you have already added a volume for a folder with your Flex Gateway configuration files, skip to the last step.   
---  
  1. Press Ctrl+C to stop your Flex Gateway and any replicas.
  2. Create a folder named `app` in the directory with your Flex Gateway configuration files.
  3. Restart your Flex Gateway with an additional volume for the new `app` directory:
```
docker run --rm \
-v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \
-p 8080:8080 \
mulesoft/flex-gateway
```

Specify an optional name you want to assign to your Flex Replica by including the following: `-e FLEX_NAME=<name-for-flex-replica> \`.   
---  
  4. Create and save a YAML configuration file in your `app` folder with your PROXY protocol configuration details.
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
 name: config
spec:
 proxyProtocol:
  enabled: true
```



## Enable PROXY Protocol for Flex Gateway in a Kubernetes Cluster
To configure PROXY protocol for Flex Gateway, create a new resource using a YAML configuration file with your PROXY protocol details.
```
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
 name: config
spec:
 proxyProtocol:
  enabled: true
```

## See Also
  *
Tree Variables (dw::util::Tree) | MuleSoft Documentation
# Tree Variables (dw::util::Tree)
Variable | Definition | Description  
---|---|---  
ARRAY_TYPE |  Variable used to identify a `PathElement` value as an array. _Introduced in DataWeave version 2.2.2._  
ATTRIBUTE_TYPE |  `ATTRIBUTE_TYPE` |  Variable used to identify a `PathElement` value as an attribute. _Introduced in DataWeave version 2.2.2._  
OBJECT_TYPE |  Variable used to identify a `PathElement` value as an object. _Introduced in DataWeave version 2.2.2._
Export Resources | MuleSoft Documentation
# Export Resources
Mule Applications, Mule Domains and Mule Policies contain a set of resources which may be properties files, DataWeave transformation files, Java classes, etc. By default, all of these files are internal to the artifact in which they are defined, and as a result, they are inaccessible from other artifacts. For instance, if a resource defined at the domain level is not explicitly exported, then it cannot be accessed from within any of the applications that belong to that shared domain. Another example is classes from an application that are meant to be used by the Java module. If those classes are not exported, then the Java module will not be able to access them.
## How to Export Java Classes
To export Java classes, you have to export the complete package that contains them by using the `exportedPackages` field of the `mule-artifact.json` file of your artifact. Individual classes cannot be exported.
Use `.api.` when naming public packages and `.internal.` when naming your non-public packages to make them easier to identify.
```
{
  "name": "MyApp",
  "minMuleVersion": "4.0.0",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": [
        "org.mule.myapp.api.customer",
        "org.mule.myapp.api.account"
      ]
    }
  }
}
```

Any internal dependencies in your Java classes are automatically exported with this configuration.
### Considerations
  * Export the minimum number of packages required for your application to work
This reduces the likelihood of conflicts with other artifacts, such as modules or connectors, that you might be using within your application.
  * Configure shared libraries if any component in your Mule app needs to access the exported packages
Due to the classloading isolation mechanism implemented in Mule, connectors and modules cannot access application dependencies unless these dependencies are configured as shared libraries.


## How to Export Resource Files
To export resources, use the `exportedResources` field of the `mule-artifact.json` file for your artifact.
```
{
  "name": "MyApp",
  "minMuleVersion": "4.0.0",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedResources": [
        "/org/mule/myapp/customer-to-user.dwl",
        "/org/mule/myapp/beans.xml"
      ]
    }
  }
 }
}
```

This same mechanism applies to every artifact, including custom extensions developed with the Mule SDK.   
---  
## See Also
  *   * Configure Shared Libraries
Zuora Connector 6.0 Examples | MuleSoft Documentation
# Zuora Connector 6.0 Examples
## Example: Retrieve Details for an Account
This example retrieves the account details for the specified account ID and returns them in JSON format.
## Studio Flows
  * Listener (HTTP) - Accepts data from HTTP requests.
  * Zuora API Connector - Connects with Zuora and executes a query to retrieve the account details for the specified account ID.
  * Transform message - Outputs the results of the `Get account` operation in JSON format.


## XML Flows
Paste this XML code into Anypoint Studio to experiment with the flow described in the previous section.
```
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:mule-zuora-connector="http://www.mulesoft.org/schema/mule/mule-zuora-connector"
xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/mule-zuora-connector http://www.mulesoft.org/schema/mule/mule-zuora-connector/current/mule-mule-zuora-connector.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
<mule-zuora-connector:config name="Zuora_Connector___Mule_4_Config" doc:name="Zuora Connector - Mule 4 Config" doc:id="ab77ca79-6f70-4c6f-98f6-be22cfc8eecc" >
<mule-zuora-connector:basic-auth-connection
    username="${zuora.username}"
    password="${zuora.password}"
    baseUri="${zuora.baseUri}" />
</mule-zuora-connector:config>
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" doc:id="dc0c431a-8608-446d-9a43-cb8515a36a90" >
<http:listener-connection host="localhost" port="8081" />
</http:listener-config>
<flow name="zuora-demo-testFlow" doc:id="83fb740f-9c7b-4c98-8b32-ae8c84c3c1e4" >
<http:listener doc:name="Listener" doc:id="e623ac5d-cab7-4bf2-a6e0-27a78462ab1a" config-ref="HTTP_Listener_config" path="/getAccount"/>
<mule-zuora-connector:get-v1-accounts-by-account-key doc:name="Get account" doc:id="eedfd82c-b8d3-4b83-88b3-50e284aa217b" config-ref="Zuora_Connector___Mule_4_Config" accountKey="#[payload]"/>
<ee:transform doc:name="Transform Message" doc:id="d4607f1d-7d2e-4d84-a079-c436050767f0" >
<ee:message >
<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
payload
]]></ee:set-payload>
</ee:message>
</ee:transform>
</flow>
</mule>
```

## See Also
MuleSoft Help Center
View a SAML Response in the Browser | MuleSoft Documentation
# View a SAML Response in the Browser
To view your SAML response in a browser, perform a single sign-on (SSO) and use the developer tools in your browser to find the bearer token and SAML response.
Complete this task before calling the MuleSoft Support team to assist you in troubleshooting your SAML 2.0 compliant SSO setup.   
---  
  1. Open a new tab in your browser and open Chrome Developer Tools:
    1. In the Chrome developer tool:
    2. Select the **Network** tab.
    3. Select **Preserve log**.
    4. Optionally, if the **Method** column isn’t visible in the Developer Tools Network log pane, right-click any column label and select **Method**.
  2. In the Access Management navigation menu, click **Business Groups**.
  3. Click the name of your root organization.
  4. Click the **Settings** tab.
  5. Copy the domain name.
  6. Go to `anypoint.mulesoft.com/accounts/login/_domain_name_`. This will redirect you to your IDP’s single sign-on page.
  7. Enter the IDP account credentials and authenticate yourself.
  8. In **Headers** , look for a SAML Post in the Developer Tools Network log pane and select it.


Other tools or tracers might have different labels. . Record the SAML response element.
After recording the SAML response, use it to obtain a bearer token to access platform APIs. It’s also useful to record the SAML response to provide to MuleSoft support if you contact them.
  1. Log in to the MuleSoft Support Portal:
```
https://www.mulesoft.com/support-login
```

  2. Provide a screenshot of your SAML configuration in Anypoint Platform.
  3. Include an XML SAML assertion.


## Example: Chrome Developer Tools SAML Response Element
This image shows a SAML response element in Chrome developer tools after signing in to Anypoint Platform using SSO:
Figure 1. SAML response element after signing in to Anypoint Platform in Google Chrome.
In the **Network** tab (1), the `receive-id` line (2) indicates that you attempted to sign in to Anypoint Platform using single signon through your identity provider. Because the signin is successful, you can expand `receive-id` and access form data that contains your SAML response element (3). Unsuccessful signin attempts still generate SAML response elements.
Graphically Construct a Mapping (Design Center) | MuleSoft Documentation
# Graphically Construct a Mapping (Design Center)
Through the graphical UI of the Transform component you can do the tasks below. Each task will produce the DataWeave source code that describes the action.
## Map a Field
Drag an element on the input structure over to another on the output structure, this action creates a line that joins these two elements.
## Remove a Mapping
  1. Select the corresponding input element.
A trash can icon appears on the connection.
  2. Click the trash can icon.


## Set a Fixed Value or Function
  1. Double click on a field (that doesn’t have any children) in the output tree. This adds a function icon next to it.
  2. A box with the default value `null` appears. You can change `null` to anything you want, such as:
     * A fixed text value by using " ".
     * A reference to an input field.
     * A statement that includes DataWeave functions.


This experience relates to that of using a spreadsheet, where each field can be a direct reference to another field, or can be the product of a function that involves such references.
Functions can be removed by clicking on the trash-can icons that appear next to them.   
---  
## See Also
DataWeave Function Reference
DataWeave Language
MUnit in Anypoint Studio | MuleSoft Documentation
# MUnit in Anypoint Studio
Anypoint Studio 
MUnit is fully integrated with Anypoint Studio. You can use the Studio graphical interface to:
  * Create and design MUnit tests
  * Run your tests
  * View test results and coverage
  * Debug your tests


## See Also
  * Scaffold a Template for an MUnit Test from an API Specification
  * Test Recorder in Studio
Java EE Libraries | MuleSoft Documentation
# Java EE Libraries
In the first Mule runtime version that exclusively supports Java 17 (Mule 4.9.0), connectors can no longer include Java EE libraries. To ensure backward compatibility, Mule versions 4.6.0 through 4.9.0 continue to export Java EE libraries as part of the Container API only when Mule runtime runs on Java 8 or Java 11. However, if Mule runtime runs on Java 17 or higher, you must include the Java EE libraries manually. For connectors that support multiple Java versions, such as Java 11 and Java 17, the Java EE libraries must match the versions included in Mule runtime.
Because Mule 4.6.x exposes Java EE libraries differently than earlier Mule versions, you must add the BOM dependency to your connector and, if applicable, exclude the provided conflicting library. You can also add the libraries in the BOM dependency separately.
```
<properties>
 <muleJavaEeBomVersion>4.6.0</muleJavaEeBomVersion>
</properties>
<dependencyManagement>
 <dependencies>
  <dependency>
   <groupId>org.mule</groupId>
   <artifactId>mule-javaee-runtime-bom</artifactId>
   <version>${muleJavaEeBomVersion}</version>
   <type>pom</type>
   <scope>import</scope>
  </dependency>
 </dependencies>
</dependencyManagement>
```

## See Also
  * Upgrading Java for Custom Connectors (Customers)
  * Upgrading Java for Custom Connectors (Partners)
  *
AI OCR (screen-based) | MuleSoft Documentation
# AI OCR (screen-based)
The _AI OCR (screen-based)_ action step is a further development of the existing OCR action steps. In contrast to the other OCR action steps, it is based on concepts of neural networks. The available languages, therefore, are based on trained patterns that take account of the characteristics of the relevant language. In many cases, therefore, the correct recognition of texts that are, for example, barely legible or have little contrast or an unusual font, is improved with this Action Step.
In contrast to the AI OCR (file-based) action step, which works with existing images, e.g. from document scans, the _AI OCR (screen-based)_ action step works _with_ screenshots of the currently active desktop _._ This means, it attempts to extract texts from a previously created screen copy.
You should consider the Intelligent OCR 2020 action step if more than one language is to be recognized at once or if you wish to use your own dictionary.
## Properties
**OCR Image Preprocessing**
See also Properties in the Chapter entitled **AI OCR (File-based)**.
## Inbound Variables
**Scan Area relative to** (Coordinates) The defined Search Area is moved relative to these coordinates. The resulting result coordinates are then absolute and are with reference to the left screen corner.
This variable can only be mapped in the wizard.
## Outbound Variables
**IsSucceeded** (Boolean) Shows whether text recognition has been carried out successfully or not.
## Wizard
You can use **OCR Image Preprocessing** to improve the quality of the image so that the OCR operation can run optimally. This is always carried out in the specified sequence. Here, you can also switch the individual steps on or off.
First, a screenshot is made of the currently active desktop. Using **Initial wait time** , you can delay this operation. This can be very useful if the image takes time to form, e.g. due to animations.
You can find further explanations in Properties.
toBase64 | MuleSoft Documentation
# toBase64
## toBase64(content: Binary): String
Transforms a binary value into a Base64 string.
### Parameters
Name | Description  
---|---  
The binary value to transform.  
### Example
This example transforms a binary value into a Base64 encoded string. In this case, the binary value represents an image.
#### Source
```
%dw 2.0
import dw::Crypto
import toBase64 from dw::core::Binaries
var emailChecksum = Crypto::MD5("achaval@gmail.com" as Binary)
var image = readUrl(log("https://www.gravatar.com/avatar/$(emailChecksum)"), "application/octet-stream")
output application/json
---
toBase64(image)
```

#### Output
This example outputs a Base64 encoded string. The resulting string was shortened for readability purposes:
```
"/9j/4AAQSkZJRgABAQEAYABgAAD//..."
```
MuleSoft Accelerator for Consumer Goods | MuleSoft Documentation
# MuleSoft Accelerator for Consumer Goods
MuleSoft Accelerator for Consumer Goods helps consumer goods companies integrate their digital operations to gain visibility into trade promotion management and retail execution. Our foundational assets are expertly designed to jumpstart your top integration and business initiatives so that IT teams can spend more time innovating and less time building from scratch.
## Use cases
### Product and Account Integration with Hierarchies
The Product and Account Integration with Hierarchies use case surfaces relevant product, customer, demand planning, and pricing information from ERP and PIM systems and easily consolidate this information into Trade Promotion Management (TPM) platforms like Salesforce Consumer Goods Cloud for informed promotional planning.
### Retail execution
The Retail Execution use case unlocks shelf data to enable perfect retail execution with pre-built assets. Access store audit data from image recognition software, like Trax, and smoothly integrate into Retail Execution platforms, such as Salesforce Consumer Goods Cloud, to monitor at shelf performance in one platform.
### Trade Promotion Effectiveness
The Trade Promotion Effectiveness use case allows you to visualize your promotions in one integrated platform with pre-built assets that integrate Business Intelligence Tools (BI Tools), such as CRM Analytics, into a TPM platform like Salesforce Consumer Goods Cloud.
## See Also
  *   *   *   * MuleSoft Accelerator for Consumer Goods on Exchange