BassemE/mulesoft-documentation-embeddings huggingface dataset:
SAP S/4HANA SOAP Connector 2.6 | MuleSoft Documentation
# SAP S/4HANA SOAP Connector 2.6
Anypoint Connector (SAP S/4HANA SOAP Connector) provides full support for the SOAP APIs exposed by SAP S/4HANA Cloud ERP, and starting with version 2.1, also provides support for SAP S/4HANA on-premise ERP. This connector enables you to automatically discover SOAP services enabled on your SAP S/4HANA instance and to invoke the SOAP service and associated operations.
For software requirements and compatibility information, see the SAP S/4HANA SOAP Connector Release Notes.
## Before You Begin
Before you create an app and use this connector, you must:
  * Have a developer account or other valid SAP S/4HANA instance.
  * Have a MuleSoft Enterprise license.
  * Enable discovery service in your SAP S/4HANA instance.
  * Have a communication user that is assigned to the corresponding communication arrangements for the desired APIs.
  * Be familiar with:
    * SAP S/4HANA SOAP
    * Mule runtime engine (Mule)
    * Anypoint Connectors
    * Anypoint Studio essentials


## Common Use Cases For the Connector
Send an XML request to SAP S/4HANA’s SOAP API and print a response.
## Using 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 SOAP Connector Release Notes
  * SAP S/4HANA SOAP Connector on Exchange
  * MuleSoft Help Center
Troubleshooting Anypoint Partner Manager | MuleSoft Documentation
# Troubleshooting Anypoint Partner Manager
Anypoint Partner Manager relies on several different MuleSoft technologies including but not limited to Mule, Anypoint Runtime Manager, secrets manager, and your infrastructure for B2B storage payloads.
Because Anypoint Partner Manager is used with other technologies, troubleshooting an issue with Partner Manager often involves troubleshooting these other technologies as well.
Look for solutions in the documentation about connectivity and related errors or use the documentation page’s navigation pane to locate troubleshooting information specific to either Anypoint Partner Manager or its related technologies.
Salesforce Composite Connector 2.19 - XML and Maven Support | MuleSoft Documentation
# Salesforce Composite Connector 2.19 - 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/salesforce-composite
http://www.mulesoft.org/schema/mule/salesforce-composite/current/mule-salesforce-composite.xsd
```

This example shows how the namespace statements are placed in the XML:
```
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:salesforce-composite="http://www.mulesoft.org/schema/mule/salesforce-composite" xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
  xmlns:http="http://www.mulesoft.org/schema/mule/http"
  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/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-composite http://www.mulesoft.org/schema/mule/salesforce-composite/current/mule-salesforce-composite.xsd">
```

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

Verify that 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 composite`.
  4. Select the connector.
  5. Click **Dependency Snippets** near the upper right of the screen.


## Next Step
After completing your namespace and `pom.xml` file, you can try the Examples.
## See Also
  * Introduction to Anypoint Connectors
  * MuleSoft Help Center
Header Injection Policy | MuleSoft Documentation
# Header Injection Policy
**Policy name** | Header Injection  
---|---  
Adds headers to a request or a response  
Transformation  
**First Mule version available**  
**Returned Status Codes**  
500 - The configuration includes an expression that was not evaluated.  
## Summary
The Header Injection policy adds HTTP headers to the request or response of a message. When you configure this policy for your API, you must specify an inbound and outbound map of the headers that you want to add in the message processing in the form of a key-value pair.
You can optionally include DataWeave expressions in the value or name of the header. For example, all headers matching the following configured expression are injected to the message:
`“#[attributes.requestPath]”`
If the injected header already exists in the message attributes, the policy creates a new header without overriding the value of the existing one.
Only certain headers are restricted to support multiple values, and they will be overwritten using configured values. These headers are: `access-control-allow-origin`, `content-type`, `content-length`, `transfer-encoding`. To overwrite any other existing message header, remove it before adding your header. See the Header Removal policy.  
---  
## Configuring Policy Parameters
### Mule Gateway
When you apply the policy to your API from the UI, the following parameters are displayed:
**Parameter** | **Description**  
---|---  
Inbound Header Map |  List of headers to be injected at the beginning of the message processing.  
Inbound Header Key |  String or Dataweave expression to be used as header name at the beginning of the message.  
Inbound Header Value |  String or Dataweave expression to be used as header value at the beginning of the message.  
Outbound Header Map |  List of headers to be injected at the end of the message processing.  
Outbound Header Key |  String or Dataweave expression to be used as header name at the end of the message processing.  
Outbound Header Value |  String or Dataweave expression to be used as header value at the end of the message processing.  
Method & Resource conditions |  The option to add configurations to only a select few or all methods and resources of the API  
Header keys should be compliance with HTTP 1.1 standard.  
---
Migrating to Helm Managed Runtime Fabric | MuleSoft Documentation
# Migrating to Helm Managed Runtime Fabric
You can migrate to helm native for Runtime Fabrics that were installed using rtfctl.
## Before You Begin
To perform the migration, you must consider the following:
  * The migration is applicable to BYOK clusters which are installed with `rtfctl` and want to migrate to helm managed.
  * The cluster must be on `rtf-agent` v2.2.5 or above. Note that you will first have to upgrade agent to the required version before you can initiate the migration.


Additionally, you must have these details:
  * organizationId
  * fabricId
  * Bearer token for Anypoint user account with **manage fabric** privileges
  * rtfctl version >= v1.0.10 is downloaded


## Migrate rtfctl to Helm
To migrate your Runtime Fabric from rtfctl to helm, run this command:
```
rtfctl migrate previous-rtf-bkp.tar.gz --organizationId <orgId value> --fabricId <fabricId value> --token <bearer token> --host anypoint.mulesoft.com --confirm
```

Running this command performs the following actions:
  * Backs up the current Runtime Fabric installation: tarball is created with input file name.
  * Uninstalls the current Runtime Fabric installation: running the command does not update Mule application deployments, it does not delete any of your configurations applied to the rtf namespace, it does not delete the rtf namespace, and it does not touch any other namespace than the rtf namespace. Uninstalls only the previous runtime-fabric helm chart.
  * Regenerates activation data for provided fabricId.
  * Deletes custom-properties secret in the rtf namespace, because helm managed rtf recreates the secret using values from the helm chart.
  * Installs Runtime Fabric with helm commands, to re-render Runtime Fabric helm chart.


Running the command does not upgrade Runtime Fabric to the version other than the existing installation version.
### Command Success
If running the command is successful:
  * You can verify that Runtime Fabric is now helm managed in the Anypoint Runtime Manager UI.
  * You can verify that configurations such as ingress templates, persistence gateway, custom resources and proxy values that you applied before the migration are intact.


### Command Fails
If running the command fails:
  1. Run `rftctl restore` command with the backup:
```
rtfctl restore <path_to_backup_file>
```

  2. Re-try `rfctl migrate` command:
```
rtfctl migrate previous-rtf-bkp.tar.gz --organizationId <orgId value> --fabricId <fabricId value> --token <bearer token> --host anypoint.mulesoft.com --confirm
```



## Command Help
To get help with the command, run the following entry:
```
rtfctl migrate –help
```

## Add Annotations and Labels
To add annotations or labels after the migration, run these commands:
For annotations:
```
kubectl annotate secret rtf-muleruntime-license -n rtf \
meta.helm.sh/release-name=runtime-fabric \
meta.helm.sh/release-namespace=rtf --overwrite
```

For labels:
```
kubectl label secret rtf-muleruntime-license -n rtf \
app.kubernetes.io/managed-by=Helm --overwrite
```
Context Information Injection | MuleSoft Documentation
# Context Information Injection
To get information about the context in which an operation or source is being processed, you can add parameters to the operation or source. The parameters do not appear in the UI, but they are injected by the SDK into the runtime.
## Component Location
When executing an operation or using a source, you might want to have some context about the location of the component, mostly for logging purposes. To achieve this, you can define a `ComponentLocation` as a parameter, and it will be injected.
This examples shows how to log the component location when starting a source:
```
@Alias("listener")
public class HttpListener extends Source<InputStream, HttpRequestAttributes> {
 private static final Logger LOGGER = getLogger(HttpListener.class);
 @Connection
 private ConnectionProvider<HttpServer> serverProvider;
 private ComponentLocation location;
 @Parameter
 private String path;
 private HttpServer server;
 @Override
 public void onStart(SourceCallback<InputStream, HttpRequestAttributes> sourceCallback) throws MuleException {
  server = serverProvider.connect();
  if (LOGGER.isDebugEnabled()) {
   LOGGER.debug("Starting HTTP Listener %s on path %s", location.getLocation(), path);
  }
  server.listen(path);
 }
// ...
}
```

This example shows how to log the component location in an operations (non-source) context:
```
//ComponentLocation is added as a parameter when used in an operation
 public String sayHi(String person, String q, ComponentLocation location) {
  // ...
  System.out.println("Location: " + location.getLocation());
  // ...
 }
```

## Tracking an Event
**Available since version 1.1**
To be able to trace an event through logs, you can use a `CorrelationInfo` parameter in your operations and source callback. This correlation info provides the event ID and correlation ID of the event that is processed.
You simply need to add a `CorrelationInfo` parameter to your operation method or source callback. The instance will be populated with the event information the method or callback runs.
This simplified example shows how to use `CorrelationInfo`:
```
public class ObjectStoreOperations {
 private static final Logger LOGGER = getLogger(ObjectStoreOperations.class);
// ...
 @Throws(StoreErrorTypeProvider.class)
 public void store(String key,
          @Content TypedValue<Serializable> value,
          ObjectStore objectStore,
          CorrelationInfo correlationInfo) {
   objectStore.store(key, value);
   if (LOGGER.isDebugEnabled()) {
    LOGGER.debug("Object stored with key: %s .The event id is: %s", key, correlationInfo.getEventId());
   }
 }
// ...
}
```
cos | MuleSoft Documentation
# cos
## cos(angle: Number): Number
Returns the trigonometric cosine of an angle from a given number of radians.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
Number of radians in an angle.  
### Example
This example shows how `cos` behaves with different inputs.
#### Source
```
%dw 2.0
import * from dw::util::Math
output application/json
---
{
 "cos0": cos(0),
 "cos13": cos(0.13),
 "cos-1": cos(-1)
}
```

#### Output
```
{
 "cos0": 1.0,
 "cos13": 0.9915618937147881,
 "cos-1": 0.5403023058681398
}
```
CLI for Local Server Groups | MuleSoft Documentation
# CLI for Local Server Groups
Use the `serverGroup` commands to automate your Local Server Groups Processes. For more information about how to use these commands, refer to the Runtime Manager documentation.
Command | Description  
---|---  
runtime-mgr:serverGroup:add:server |  Adds server to a server group  
runtime-mgr:serverGroup:create |  Creates server group from servers  
runtime-mgr:serverGroup:describe |  Describes server group  
runtime-mgr:serverGroup:delete |  Deletes server group  
runtime-mgr:serverGroup:list |  Lists all server groups in the environment  
runtime-mgr:serverGroup:modify |  Modifies server group  
runtime-mgr:serverGroup:remove:server |  Removes server from a server group  
## runtime-mgr:serverGroup:add:server
```
> runtime-mgr:serverGroup:add:server [flags] <serverGroupId> <serverId>
```

Adds the server passed in `serverId` to the server group passed in `serverGroupId`.
This command accepts the default flags.
## runtime-mgr:serverGroup:create
```
> runtime-mgr:serverGroup:create [flags] <name> [serverIds...]
```

Creates a server group with the name passed in `name` using the server Id(s) passed as argument(s) thereafter.
This command accepts the default flags.
## runtime-mgr:serverGroup:describe
```
> runtime-mgr:serverGroup:describe [flags] <serverGroupId>
```

Describes the server group passed in `serverGroupId`.
This command accepts the `--output` flag. Use the `--output` flag to specify the response format. Supported values are `table` (default) and `json`.
This command accepts the default flags.
## runtime-mgr:serverGroup:delete
```
> runtime-mgr:serverGroup:delete [flags] <serverGroupId>
```

Deletes the server groups passed in `serverGroupId`.
This command accepts the default flags.
This command does not prompt twice before deleting. If you send a delete instruction, it does not ask for confirmation.   
---  
## runtime-mgr:serverGroup:list
```
> runtime-mgr:serverGroup:list [flags]
```

Lists all server groups in the environment.
This command has the `--output` flag. Use the `--output` flag to specify the response format. Supported values are `table` (default) and `json`.
This command accepts the default flags.
## runtime-mgr:serverGroup:modify
```
> runtime-mgr:serverGroup:modify [flags] <serverGroupId>
```

Modifies the server group passed in `serverGroupId`.
In order to update the id for the cluster, you need to pass the `--name` flag.
This command accepts the default flags.
## runtime-mgr:serverGroup:remove:server
```
> runtime-mgr:serverGroup:remove:server [flags] <serverGroupId> <serverId>
```

Removes the server passed in `serverId` from the server group passed in `serverGroupId`.
This command accepts the default flags.
SAP S/4HANA OData Connector 2.9 Batch Operations | MuleSoft Documentation
# SAP S/4HANA OData Connector 2.9 Batch Operations
The batch processing feature is available in SAP S/4HANA OData Connector 2.1 and later.
You must follow the correct order for structural batch operations, which is as follows:
  1. Initiate the batch before adding any requests into it.
  2. Do not add requests to the batch or the change set after it is executed.


## Create a Batch Operation
To create and process a batch operation, you must:
  1. Place the **Initiate Batch** operation in the Mule flow, which returns a unique batch identifier. This unique batch identifier must be stored, for example, in the flow variable, so that it can then be used to group the batch data operations under the common batch request.
  2. Use the **Create Change Set** operation to create a new change set. This operation returns a unique change set identifier, which you then use in the **Batch Create** , **Batch Update** , **Delete Entity** , or **Batch Execute Function** operations to add them to the change set.
  3. When you complete the batch, use the **Execute Batch** operation to send the batch request.


The **Batch Create Entity** , **Batch Get Entity** , **Batch Query** , and **Batch Execute Function** operations return a JSON result. However, the result of these operations cannot be read until the **Execute Batch** operation is done.
If you attempt to read the result before the **Execute Batch** operation is executed, the connector throws an exception. You can store the output of these operations, for instance, into a flow variable, and access the output after the **Execute Batch** operation is executed.
After the **Execute Batch** operation is successfully executed, a summary is returned, which contains basic information about the outcome of every batch operation that was included as part of the batch operation. The detailed results of these batch operations are then available to read.
## Troubleshooting
Exceptions are thrown in the following circumstances:
  * An operation references a batch identifier that is invalid, either because:
    * It was never initiated.
    * It was already processed as part of an **Execute Batch** operation.
  * The change set identifier used in that batch operation is not valid.


## See Also
  * SAP S/4HANA OData Connector Reference
  * MuleSoft Help Center
Anypoint Security Policies for Edge | MuleSoft Documentation
# Anypoint Security Policies for Edge
Anypoint Security features a high-performance, reliable, and scalable service that works with Anypoint Runtime Fabric to enforce security policies on nodes deployed to your Anypoint Runtime Fabric. Anypoint Security provides denial-of-service (DoS), IP allowlists, HTTP limits, and Web Application Firewall (WAF) policies to protect your APIs.
You can use the Anypoint Security policies to manage all traffic to your Runtime Fabric, and leverage API Manager policies to apply specific behaviors to specific APIs.
Anypoint Security policies then act as a default router capability through which all traffic traverses.
  * Threat detection and prevention
    * Content attack prevention (HTTP header and message limits checks)
    * Denial of Service
    * IP allowlists
  * Advanced TLS (for example, certificate pinning, CRL)
  * Basic TLS (for example, Mutual TLS, SSL Termination)


API policies that are configured in API Manager and running through an API gateway give you the ability to further customize or extend certain limitations you are applying at the Mule application level.
This layer of security provides the same control as any API Manager policy offers. For example:
  * Basic TLS (for example, mutual TLS, SSL termination)
  * Rate limiting
  * OAuth
  * Authorization and Accounting (AAA)


## Prerequisites
To configure and use the security policies, you must:
  * Have the Anypoint Security - Edge entitlement for your Anypoint Platform account.
If you don’t see **Security** in **Management Center** , contact your customer success manager to enable Anypoint Security for your account.
  * Have Runtime Fabric on VMs/Bare Metal with inbound traffic configured. Anypoint Runtime Fabric is a container service that automates the deployment and orchestration of Mule apps and API gateways.
Refer to the Runtime Fabric documentation.
Runtime Fabric requires the Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform.
  * Enable inbound traffic on Runtime Fabric to allow Mule apps and API gateways to listen on inbound connections.


## DoS Policy
DoS policies are designed to protect your network nodes against malicious clients trying to flood your network to prevent legitimate traffic to your APIs. Learn more about the DoS policy.
## IP Allowlist Policy
Create an IP address allowlist policy to configure an explicit list of IP addresses that can access your deployed endpoints. Learn more about the IP Allowlist.
## HTTP Limits Policy
HTTP limits policies prevent attacks from clients that send large messages that can consume all of your processing bandwidth. Learn more about the HTTP Limits policy.
## WAF Policy
WAF policies provide the Open Web Application Security Project (OWASP) Core Rule Set (CRS) for checking requests and responses to detect common web application attacks. Learn more about the WAF policy.
## See Also
  * Install Runtime Fabric
  * Enable Inbound Traffic on Anypoint Runtime Fabric
log | MuleSoft Documentation
# log
## log<T>(prefix: String = "", value: T): T
Without changing the value of the input, `log` returns the input as a system log. So this makes it very simple to debug your code, because any expression or subexpression can be wrapped with **log** and the result will be printed out without modifying the result of the expression. The output is going to be printed in application/dw format.
The prefix parameter is optional and allows to easily find the log output.
Use this function to help with debugging DataWeave scripts. A Mule app outputs the results through the `DefaultLoggingService`, which you can see in the Studio console.
### Parameters
Name | Description  
---|---  
An optional string that typically describes the log.  
The value to log.  
### Example
This example logs the specified message. Note that the `DefaultLoggingService` in a Mule app that is running in Studio returns the message `WARNING - "Houston, we have a problem,"` adding the dash `-` between the prefix and value. The Logger component’s `LoggerMessageProcessor` returns the input string `"Houston, we have a problem."`, without the `WARNING` prefix.
#### Source
```
%dw 2.0
output application/json
---
log("WARNING", "Houston, we have a problem")
```

#### Output
`Console Output`
```
"WARNING - Houston, we have a problem"
```

`Expression Output`
```
"Houston, we have a problem"
```

### Example
This example shows how to log the result of expression `myUser.user` without modifying the original expression `myUser.user.friend.name`.
#### Source
```
%dw 2.0
output application/json
var myUser = {user: {friend: {name: "Shoki"}, id: 1, name: "Tomo"}, accountId: "leansh" }
---
log("User", myUser.user).friend.name
```

#### Output
`Console output`
```
User - {
 friend: {
  name: "Shoki"
 },
 id: 1,
 name: "Tomo"
}
```

`Expression Output`
IDP Glossary | MuleSoft Documentation
# IDP Glossary 

Callback URL
    
URL specified for IDP to call when the document processing finishes. 

Confidence score
    
The probability that IDP has properly extracted a value from a document. Documents with low confidence scores are sent for human review. 

Connected app
    
Framework that enables external applications to call the IDP API. 

Document action
    
Configurable schema definitions containing instructions to process documents. You can create them using preconfigured templates or customized fields. 

Execution ID
    
Identifier required to execute and retrieve results of document actions in MuleSoft RPA. 

Field extraction
    
Process of identifying and retrieving specific data fields from documents as defined in a document action. 

HITL (Human-in-the-loop)
    
Process where human reviewers verify the accuracy of the extracted values from documents when the confidence score is lower than the defined threshold. This ensures that the extracted data is accurate and reliable. 

NLP (Natural Language Processing)
    
Branch of artificial intelligence that focuses on processing human language, including syntactic, semantic, and pragmatic analysis, to facilitate human-computer interaction. 

Prompts
    
Instructions in natural language added to refine the extraction results. 

Reviewers
    
Individuals or teams that verify the accuracy of extracted values when the confidence score is low. 

Schema Configuration
    
Process of selecting and configuring extracted field names, visibility, threshold, and required fields for document actions. 

Unstructured data
    
Information that does not have a predefined data model or is not organized.
wait | MuleSoft Documentation
# wait
## wait<T>(value: T, timeout: Number): T
Stops the execution for the specified timeout period (in milliseconds).
Stopping the execution blocks the thread, potentially causing slowness, low performance and potentially freezing of the entire runtime. This operation is intended for limited functional testing purposes. Do not use this function in a production application, performance testing, or with multiple applications deployed.   
---  
### Parameters
Name | Description  
---|---  
Input of any type.  
The number of milliseconds to wait.  
### Example
This example waits 2000 milliseconds (2 seconds) to execute.
#### Source
```
%dw 2.0
import * from dw::Runtime
output application/json
---
{ "user" : 1 } wait 2000
```

#### Output
```
{ "user": 1 }
```
Troubleshooting Request Connection | MuleSoft Documentation
# Troubleshooting Request Connection
When configuring and running Flex Gateway, you might encounter connection issues.
To troubleshoot these issues, use the `flexctl check http` command. This command makes direct requests to both the outbound connection between the upstream service and Flex Gateway and the inbound connection between Flex Gateway and the client. Making direct requests isolates Flex Gateway connections, which allows you to localize the issue.
The following diagram demonstrates the difference between inbound and outbound requests.
## Outbound Requests Between Flex Gateway and the Upstream Service
Isolating the connection between the upstream service and Flex Gateway enables you to test for connection between the two.
To make a direct outbound request to the upstream service:
  1. Log into the Flex Gateway container or VM:
     * Linux:
```
ssh [-i sshkey.pem] <user>@<domain>
```

     * Docker:
```
docker exec -it <container-id> bash
```

     * Kubernetes:
```
kubectl -n <namespace> exec -it <pod-name> -- bash
```

  2. Make a request to the upstream service:
```
flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' <http://upstream.domain>
```



## Inbound Requests Between the Client and Flex Gateway
Isolating the connection between Flex Gateway and the client enables you to test if the connection issue is due to a load balancer or another system added between Flex Gateway and the client.
To make a direct inbound request to the client:
  1. Log into the Flex Gateway container or VM:
     * Linux:
```
ssh [-i sshkey.pem] <user>@<domain>
```

     * Docker:
```
docker exec -it <container-id> bash
```

     * Kubernetes:
```
kubectl -n <namespace> exec -it <pod-name> -- bash
```

  2. Make a request to Flex Gateway:
```
flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' http://localhost:<api-instance-port>/<path>
```
MUnit Utils | MuleSoft Documentation
# MUnit Utils
Anypoint Code Builder 
Anypoint Studio 
One of the main problems of testing production code are external system connections.
MUnit provides a set of utilities for you to write your tests in a portable way and mock external system connections from your tests.
Utility | Description  
---|---  
Implement a DB server in your local environment to test connections.  
Implement an FTP server in your local environment to test connections.  
Queue Event Processors |  Manage temporary queues during your test runs.
Regroup Fields | MuleSoft Documentation
# Regroup Fields
These DataWeave examples take input that is grouped under one field and transform it into a new structure that groups data under another field.
Both examples use these functions:
  * `groupBy` to organize the fields by `subject`
  * `mapObject` and `map` to map the fields from the input to the new hierarchy.


## Example: XML to JSON
DataWeave Script:
```
%dw 2.0
output application/json
---
classrooms: payload..*teacher groupBy $.subject mapObject ((teacherGroup, subject) -> {
  class: {
   name: subject,
   teachers: { (teacherGroup map {
    teacher:{
      name: $.name,
      lastName: $.lastName
    }
   })
  }
 }
})
```

Input XML Payload:
```
<school>
  <teachers>
    <teacher>
      <name>Mariano</name>
      <lastName>De Achaval</lastName>
      <subject>DW</subject>
    </teacher>
    <teacher>
      <name>Emiliano</name>
      <lastName>Lesende</lastName>
      <subject>DW</subject>
    </teacher>
    <teacher>
      <name>Leandro</name>
      <lastName>Shokida</lastName>
      <subject>Scala</subject>
    </teacher>
  </teachers>
</school>
```

Output JSON:
```
{
 "classrooms": {
  "class": {
   "name": "DW",
   "teachers": {
    "teacher": {
     "name": "Mariano",
     "lastName": "De Achaval"
    },
    "teacher": {
     "name": "Emiliano",
     "lastName": "Lesende"
    }
   }
  },
  "class": {
   "name": "Scala",
   "teachers": {
    "teacher": {
     "name": "Leandro",
     "lastName": "Shokida"
    }
   }
  }
 }
}
```

## Example: JSON to JSON
This DataWeave example changes the hierarchy of a JSON object. The output groups fields by `language` and adds a new element, `attendees`, that contains the names of attendees for each course.
DataWeave Script:
```
%dw 2.0
output application/json
---
{
  "langs" :
    payload.langs groupBy $.language
      mapObject ((nameGroup, language) -> {
         (language): {
          "attendees" : nameGroup map {
            name: $.name
          }
         }
      })
}
```

Input JSON Payload:
```
{
 "langs": [
  {
   "name": "Alex",
   "language": "Java"
  },
  {
   "name": "Kris",
   "language": "Scala"
  },
  {
   "name": "Jorge",
   "language": "Java"
  }
 ]
}
```

Output JSON:
```
{
 "langs": {
  "Java": {
   "attendees": [
    {
     "name": "Alex"
    },
    {
     "name": "Jorge"
    }
   ]
  },
  "Scala": {
   "attendees": [
    {
     "name": "Kris"
    }
   ]
  }
 }
}
```

## Related Examples
  * Reference Multiple Inputs
  * Define a Function that Flattens Data in a List
  * 

## See Also
  *   * DataWeave Selectors
  *
Connecting to RPA Processes from Salesforce Products | MuleSoft Documentation
# Connecting to RPA Processes from Salesforce Products
This topic is affected by the Anypoint Platform integration.
If you use an Anypoint account to login to RPA Manager, refer to the **Settings** documentation.
RPA Manager requires user authentication to integrate RPA processes into other Salesforce products. For example, you can use your API key to configure an RPA connector in a MuleSoft Composer flow.
For security reasons, you can only see and copy your API key on creation.
## Before You Begin
  * Ask an administrator to assign you the required privileges:
Action | Privilege  
---|---  
Open the **User Management** module. | User Management Open  
Create, edit, and delete API keys. | User API Key Create, User API Key Edit, User API Key Delete  
  * You must have an account in RPA Manager to associate your API key with.
  * You must have a secure place accessible to store your API key.


## Create a User API Key
Create an API key for yourself to integrate an RPA process into another Salesforce product. After expiration, the integrated process instance can no longer connect to RPA Manager from other Salesforce products. Edit the API key to move the expiration date. For security reasons, RPA Manager shows the API Key only during creation. Copy your API Key and save it to a secure place. If you lose an API Key, create a new one.
To create a user API key:
  1. Open the **User API Keys** view of the **User Management** module.
  2. Click **Create**.
  3. Complete the form **Create User API Key** :
     * **User** :
Select yourself. Your identity and permissions are used to connect from another Salesforce products to RPA Manager.
     * **Expiration Date** :
Select an expiration date for the user API key from the calendar.
  4. Click **OK**.
  5. In the window **Key Created!** , click **Copy to clipboard**.
  6. Copy the API key to a secure place.
  7. Click **Close**.


Copy your saved API key into the configuration settings of the Salesforce products into which you want to integrate the RPA processes.
## Edit a User API Key
Edit a user API key to change its name, description, or expiration date. If you lost access to your API key, create a new one.
To edit a user API key:
  1. Open the **User API Keys** view of the **User Management** module.
  2. Click **Edit** () on the panel of the user API key to edit.
  3. Edit the form **Create User API Key** :
For an explanation of the properties, see **Create a User API Key**.
  4. Click **Save**.


## Delete a User API Key
Delete a user API key to revoke the user’s REST API access to RPA Manager. Integrated processes that use the deleted API key stop working.
To delete a user API key:
  1. Open the **User API Keys** view of the **User Management** module.
  2. Click **Remove** () on the panel of the user API key to remove.
  3. Confirm the removal.


## See Also
  * Create an Invocable Run Configuration
  * MuleSoft RPA Connector for Composer
  * Salesforce: Use Flows with MuleSoft RPA
General | MuleSoft Documentation
# General
The General action steps enable to perform general operations related to the automated process execution.
  * The Exit Workflow action step enables you to end a Workflow in a controlled manner.
  * All search patterns belonging to a Workflow are stored centrally in the Pattern Gallery. Search patterns are image files which are used in the Search Pattern and Pattern Select action steps to determine a state.
  * Use STC Protector to handle pop-us windows in a Workflow that needs to run stably and robustly for long periods.
Migrating from DataWeave version 1 to 2 | MuleSoft Documentation
# Migrating from DataWeave version 1 to 2
  * DataWeave Header Content
  *   *   *   * Conditional Key-Value Parenthesis


## DataWeave Header Content
Most of the header directives have been changed in DataWeave. The `%dw` directive is an exception. In most cases, MuleSoft removed the `%`, and in some cases the keyword is shortened.
DataWeave 1.0 | DataWeave 2.0 | Comments  
---|---|---  
In a Mule app flow, DataWeave 2.0 recognizes the input MIME type and its reader properties based on the MIME type (`outputMimeType`) and parameters specified in the preceding component. The input MIME type is not defined using the `input` directive in the header anymore. However, the `input` directive is still used in specific cases like Validate a Script for Streamed Data.  
## Flow Controls
Flow control changed somewhat in DataWeave 2.
### When Otherwise
The `when otherwise` statement is replaced by `if else`, for example:
Mule 3 Example: DataWeave 1
```
{
  orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete"
}
```

Mule 4 Example: DataWeave 2
```
{
  orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete"
}
```

### Pattern Matcher
Pattern matching changed in DataWeave 2. It adds the keyword `case` and `else` (instead of `default`). You also no longer separate cases with commas (`,`) since they are now explicitly separated by the `case` keyword.
Mule 3 Example: DataWeave 1
```
'world' match {
  :string -> true,
  default -> false
 }
```

Mule 4 Example: DataWeave 2
```
'world' match {
  case is String -> true
  else -> false
 }
```

For type pattern matchers, the `is` keyword needs to be set.
## Type References
The `:` was removed from the type references and are now all camel case, so `:string` is now `String`
## Object Coercion
In DataWeave 1.0, selecting a key-value pair from an object required you to do something like this:
Mule 3 Example: DataWeave 1
```
%var payload = {a: 1, b:2}
---
payload.a as :object
```

The DataWeave 1.0 expression above returns `{a:1}`. Because this is a coercion, it is also included in the auto-coercion mechanism and generates undesired or unexpected results.
In DataWeave 2.0, the coercion is removed, and a new selector () is introduced to select key-value pair parenthesis.
Mule 3 Example: DataWeave 2
```
var payload = {a: 1, b:2}
---
payload.&a
```

This expression also returns `{a:1}`.
## Conditional Key-Value Parenthesis
In DataWeave 1.0, conditional key-value pairs are declared with the `when` keyword.
Mule 3 Example: DataWeave 1
```
{
  (a: 1) when payload.product == "Mule"
}
```

In DataWeave 2.0, you use the `if` keyword.
Mule 4 Example: DataWeave 2
```
{
  (a: 1) if payload.product == "Mule"
}
```

## See Also
Introduction to Mule 4: DataWeave 2.0
Configuring PROXY Protocol in Local Mode | MuleSoft Documentation
# Configuring PROXY Protocol in Local 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
  *
Using a Proxy in Anypoint Code Builder | MuleSoft Documentation
# Using a Proxy in Anypoint Code Builder
**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.
Execute network-dependent functions in Anypoint Code Builder, such as publishing to Exchange, logging into Anypoint Platform, and running or debugging applications, by configuring your proxy settings in Visual Studio Code (VS Code).
Proxy settings doesn’t work on the cloud IDE   
---  
## Before You Begin Configuring Your Proxy
Take into account these considerations before configuring your proxy setting in VS Code:
  * When setting a proxy URL, the `protocol` can be `HTTP` or `SOCKS`. For example:
    * PROTOCOL://username:password@host:port
    * PROTOCOL://host:port
Anypoint Code Builder supports `SOCKS` proxies without authentication but doesn’t support `SOCKS` proxies with basic authentication.   
---  
  * Anypoint Code Builder ignores these fields and reads settings from the proxy URL and the no-proxy list:
    * Proxy Authorization
    * Proxy Kerberos Service Principal
    * Proxy Strict SSL
  * To exclude certain hosts from the proxy, use the **Proxy bypass** settings.


## Configure Your Proxy Settings in VS Code
To configure your proxy settings for Anypoint Code Builder:
  1. Open VS Code.
  2. Open VS Code settings:
    1. In Windows, go to **File > Preferences > Settings**.
    2. In macOS, go to **Code > Settings > Settings**.
  3. Search for "proxy" in the settings search bar.
  4. Configure your proxy URL and no-proxy settings.
  5. Configure your proxy settings in your Maven `settings.xml` file. See Configure a Proxy in Maven for configuration instructions.
  6. Set the 'Proxy Support' setting to 'override' or 'on'.
  7. Restart VS Code to apply your changes.


## Add Anypoint Platform URLs to an Allowlist
If your organization uses an allowlist, add these Anypoint Code Builder and Anypoint Platform URLs:
Anypoint Platform services: CloudHub, Exchange, Core Services | 
  * https://(*).anypoint.mulesoft.com (/*)
  * https://repository.mulesoft.org/(*)
  * https://(*).cloudhub.io/(*/)

  
---|---  
Assets downloaded from Exchange | 
  * https://exchange2-asset-manager-kprod.s3.amazonaws.com (/*)
  * https://exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com (/*)

  
Resources for API Portals | 
  * https://exchange2-file-upload-service-kprod.s3.amazonaws.com (/*)

  
Third Party | URL  
---|---  
Eclipse libraries and Eclipse update sites | 
  * https://download.eclipse.org/eclipse/updates (/*)

  
MuleSoft Maven repositories and connectors update site | 
  * https://repo.maven.apache.org/maven2 (/*)
  * https://repo1.maven.org/maven2 (/*)

  
For services that use the web browser, such as the **Login** or **Exchange** operations, refer to the browser documentation to learn about the browser network requirements. If you use an external identity provider (IdP), you must also grant permission to other third-party domains.   
---
mapString | MuleSoft Documentation
# mapString
## mapString(@StreamCapable text: String, mapper: (character: String, index: Number) -> String): String
Applies an expression to every character of a string.
_Introduced in DataWeave version 2.4.0._
### Parameters
Name | Description  
---|---  
The string to map.  
Expression that applies to each character (`$`) or index (`$$`) of the `text` string and returns a string.  
### Example
This example redacts sensitive data from a string.
#### Source
```
%dw 2.0
import * from dw::core::Strings
output application/json
---
{ balance: ("\$234" mapString if (isNumeric($)) "~" else $) }
```

#### Output
```
{
 "balance": "$~~~"
}
```

## mapString(@StreamCapable text: Null, mapper: (character: Nothing, index: Nothing) -> Any): Null
Helper function that enables `mapString` to work with a `null` value.
_Introduced in DataWeave version 2.4.0._
Downloading an API Specification | MuleSoft Documentation
# Downloading an API Specification
A copy of an API specification can be downloaded from the API Details page by clicking **Download**.
The download file type varies depending on the API:
  * REST API RAML
If you choose As RAML, the original RAML file downloads as a zip file. If you choose As OAS, the API specification is downloaded as a zip file containing a JSON file for the specification in OAS 2.0 format.
  * REST API OAS
If you choose As RAML, the API specification is downloaded as a zip file containing a RAML file for the specification. If you choose As OAS, a zip file containing a file in the original format of either JSON or YAML is downloaded.
  * SOAP API WSDL
Downloads as a WSDL file.


## See Also
  * Using the API Console
  * Simulating API Calls Using the Mocking Service
  * Testing APIs Using an API Instance
Troubleshooting Object Store Connector | MuleSoft Documentation
# Troubleshooting Object Store Connector
To troubleshoot Anypoint Connector for Object Store (Object Store Connector), become familiar with the information about enabling verbose logging and interpreting commonly thrown messages.
## Enable Verbose Logging
To get a better understanding of why an application’s interaction fails with Object Store Connector, temporarily enable verbose logging for the connector.
Remember to always disable the enhanced verbosity after troubleshooting, because it affects your Mule application performance.
To enable verbose logging in the configuration file:
  1. Access Anypoint Studio and navigate to the **Package Explorer** view.
  2. Open your application’s project name.
  3. Open the `src/main/resources` path folder.
  4. Open the `log4j2.xml` file inside the folder.
  5. Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:
```
<Loggers>
	...
	 <AsyncLogger name="org.mule.extension.objectstore" level="DEBUG"/>
	...
</Loggers>
```

  6. Save your application changes.
  7. Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule Application**.


## Understand Common Throws
Here is a list of common throw messages and how to interpret them:
  * OS:KEY_ALREADY_EXISTS
```
The Mule app tries to store an object, but the object store already has a value for that key.
```

  * OS:STORE_NOT_AVAILABLE
```
Cannot access the object store at this time.
```

  * OS:INVALID_KEY


The supplied key is invalid. Keys cannot be null nor blank.
  * OS:KEY_NOT_FOUND


The object store must access a value, but the supplied key doesn’t exist in that store.
  * OS:NULL_VALUE


A null value was supplied to the object store. Null values are not supported.
## See Also
  * Object Store Connector Reference
  * MuleSoft Help Center
  *