# Solace PubSubPlus Adapter for SAP Integration Suite
The Solace PubSubPlus adapter enables SAP Integration Suite to connect to the Solace PubSubPlus broker via the SMF protocol.
Use the Solace PubSubPlus Sender adapter to receive messages from Solace PubSubPlus broker. Use the Solace PubSubPlus Receiver adapter to send messages to Solace PubSubPlus broker.
> **ⓘ Note** Only SMF allowed headers are forwarded on the Sender and Receiver. To store any custom headers on the Receiver, use the UserProperties header.
## Related Information
[Configure the Solace PubSubPlus Sender Adapter](#configure-the-solace-pubsubplus-sender-adapter)
[Configure the Solace PubSubPlus Receiver Adapter](#configure-the-solace-pubsubplus-receiver-adapter)
### Configure the Solace PubSubPlus Sender Adapter
The Solace PubSubPlus sender adapter allows you to consume messages in SAP Integration Suite from queues or subscriptions on a Solace PubSubPlus broker using the SMF message protocol.
> **⚠️ Important - Blue-Green Deployment Considerations:** During SAP Cloud Integration's blue-green deployment of worker nodes, connection counts may temporarily double due to the deployment strategy's nature. This occurs because both old and new worker nodes establish connections simultaneously during the switchover phase. Plan your broker service connection thresholds accordingly to avoid `JCSMPErrorResponseException: 503: Too Many Connections` errors during new node startup. To proactively manage this, configure connection count alerts on your broker service and ensure your service plan's connection limits can accommodate the temporary spike.
The **General** tab displays general information about the adapter itself.
| Parameter | Description |
|--------------------|------------------|
| Name/Adapter Type | SolacePubSubPlus |
| Transport Protocol | TCP |
| Message Protocol | SMF |
Switch to the **Connection** tab to configure the adapter's connection details.
#### Connection (Tab)
| Parameter | Description |
|------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Host | The IP address (or host name) to connect to. Multiple host entries separated by commas (up to four) are allowed. With multiple entries, each is tried in turn until one succeeds. Host contains one or more host entries (up to four). A host entry has the form:
`[Protocol:]Host[:Port]`
Protocol is the protocol used for the transport channel. The valid values are:- tcp - use a TCP channel for communications between the application and its peers. If no protocol is set, tcp is used as a default.
- tcps - use a SSL channel over TCP for communications between the application and its peers. The encryption with compression is not supported.
- Host is the IP address (or host name) to connect to for a connection. Port is the port to connect to for a connection. A value is only required when using a port other than the automatically assigned default port number. The default port for TCP is 55555 when compression is not in use, or 55003 when compression is in use. The default port for SSL is 55443.
The secured SMF host name of the event broker can be copied by navigating to the AEM service -> Connect -> Solace Messaging -> Connection Details -> copy the `Secured SMF Host` using the copy icon. |
| Message VPN | The name of the Message VPN to attempt to join when connecting to the event broker. Can be copied from the same place as the host, present under the `Message VPN` section. |
| Username | The client username used for authentication with the event broker. |
| Authentication Type | The authentication mechanism to be used while connecting to Solace PubSubPlus. The available options are:- Basic
- Client Certificate
- OAuth2
|
| Password Secure Alias
(Only when using `Basic` authentication) | The alias which defines the client password used for authentication with the event broker, stored as Secure Parameter. |
| Keystore Alias
(Only when using `Client Certificate` authentication) | The alias of the private Key Pair in the Integration Suite's Keystore. |
| Truststore Alias
(Only when using `Client Certificate` authentication) | The alias of the Certificate in the Integration Suite's Keystore. This is optional and maybe necessary only if event broker host certificate requires to be trusted or not recognized by the JRE. |
| OAuth2 Credential Type
(Only when using `OAuth2` authentication) | The type of OAuth2 credential type to be used. The available options are:- OAuth2 Client Credentials (Integration Suite managed OAuth2 credential store)
- OAuth2 Authorization Code (Integration Suite managed OAuth2 credential store)
- OAuth2 - Custom (Adapter managed OAuth2 credential store)
|
| Access Token Fetch/Refresh Interval (in secs)
(Only when using `OAuth2` authentication) | The interval in seconds for fetching the access token from the respective Integration Suite's credential store when OAuth2 credential type is **Client Credentials** or **Authorization Code**. When **OAuth2 - Custom** type is selected, it is the interval at which the token is refreshed. By default, the value is 300 secs. |
| OAuth2 Client Credentials Credential Name
(Only when using `OAuth2` authentication and `OAuth2 Client Credentials` OAuth2 credential type) | The alias of the deployed OAuth2 Client Credentials artifact in the Integrations Suite's Credential Store. See [Deploying an OAuth2 Client Credentials](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/deploying-oauth2-client-credentials-artifact) know more. |
| OAuth2 Authorization Code Credential Name
(Only when using `OAuth2` authentication and `OAuth2 Authorization Code` OAuth2 credential type) | The alias of the deployed OAuth2 Authorization Code artifact in the Integrations Suite's Credential Store. See [Deploying an OAuth2 Authorization Code](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/deploying-oauth2-authorization-code) know more. |
| OAUTH2 Access Token Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of OAuth2 Access token, stored as Secure Parameter. |
| OAUTH2 Refresh Token Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of the OAuth2 Refresh token, stored as Secure Parameter. |
| OAUTH2 Client ID Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of the OAuth2 Client ID, stored as Secure Parameter. |
| OAUTH2 Refresh Token URL Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of the OAuth2 Refresh token URL, stored as Secure Parameter. |
| Proxy Type | The type of proxy connection to be used for connecting to the Solace broker. The available options are:- **Internet** (Default) - Direct connection to Solace broker without proxy
- **On-Premise** - Connection through SAP Cloud Connector for on-premise systems
**Note:** When using On-Premise proxy type, ensure that your SAP Cloud Connector is properly configured and that the Solace broker host is accessible through the Cloud Connector. The adapter uses TCP protocol for communication with the advanced event mesh broker, which utilizes the SOCKS5 proxy endpoint provided by the Cloud Connector for all TCP communications.
**⚠️ Important:** Avoid mixing proxy configurations within the same tenant. If any adapter instance uses "On-Premise" proxy type, it may affect other adapter instances configured for "Internet" connectivity, potentially causing unexpected routing behavior. For consistent results, use the same proxy configuration across all adapter instances in your tenant. |
| Location ID
(Only when using `On-Premise` proxy type) | To connect to an SAP Cloud Connector instance associated with your account, enter the location ID that you defined for this instance in the destination configuration on the cloud side. This parameter is optional if your Cloud Connector uses the default location.
**Important:** This Location ID must match exactly with the location ID configured in your SAP Cloud Connector and the corresponding destination in the SAP BTP Cockpit. |
| JCSMP Properties | A map of key-value pairs to configure additional connection properties. See [JCSMP Properties](https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/com/solacesystems/jcsmp/JCSMPProperties.html) and [JCSMP Channel Properties](https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/com/solacesystems/jcsmp/JCSMPChannelProperties.html) for the available options.
When using "client_name" property, the provided value is always appended with a unique 10 character alphanumeric string separated by a '/'. For eg. if the provided value is "iflow_x_sender" then the actual client_name would become "iflow_x_sender/az077ylyln". The uniqueness is added to succeed the client connection in a multi-worker deployment, where each client is expected to have a unique name.
**NOTE:** JCSMP channel property keys must be prepended by `CLIENT_CHANNEL_PROPERTIES.`.
For example:- `GENERATE_SENDER_ID` (regular JCSMP property)
- `CLIENT_CHANNEL_PROPERTIES.ReconnectRetries` (JCSMP channel property)
|
Switch to the **Processing** tab to configure the adapter's message processing details.
#### Processing (Tab)
| Parameter | Description |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Consumer Mode | The adapter's consumer mode. The available options are:
- Direct
- Guaranteed
- Durable Topic Endpoint
|
| Run on a single worker node? | When enabled, the consumer is bound to only one of the available worker nodes. It is recommended in the following cases:
- When consuming in Direct mode to avoid the processing of the same message on all the worker nodes due to fanout.
- When using exclusive access type Durable Topic Endpoints with broker versions prior to 10.12.0, or when you want to ensure only one active consumer flow for exclusive DTEs.
**Note:** Starting with broker version 10.12.0, exclusive DTEs support multiple consumer bindings in a fault-tolerant manner, where the first consumer receives all messages and subsequent consumers take over if the primary consumer becomes unavailable. |
| Topic Subscriptions
(Only when using `Direct` consumer mode) | The list of Solace PubSubPlus topic subscriptions from which messages will be consumed.
**Note:** Special characters may need to be UTF-8 encoded. For example: `>` as `%3E`. |
| Parallel Consumers
(Only when using `Guaranteed` or `Durable Topic Endpoint` consumer mode) | The number of concurrent consumer flows.
**Note:** If the IFlow is running with more than 1 worker, this will be a multiple of the number of workers. For eg. if you configure this value to 3 and the IFlow is running with 2 workers, in total there will be 6 consumers. |
| Queue Name
(Only when using `Guaranteed` consumer mode) | The Solace PubSubPlus queue name from which messages will be consumed. |
| Topic Endpoint Name
(Only when using `Durable Topic Endpoint` consumer mode) | The Solace PubSubPlus durable topic endpoint on which a durable topic subscription needs to be created using the `Topic Endpoint` config.
A durable topic endpoint has an access type, which determines how messages are delivered when multiple consumer flows are bound to it. Topic endpoints can be assigned one of the following access types:
- Exclusive—specifies that multiple clients can bind to the topic endpoint, but only the first consumer receives messages in a fault-tolerant manner. If the primary consumer becomes unavailable, the next consumer takes over (broker version 10.12.0+). For earlier broker versions, only one consumer binding is allowed.
- Non-exclusive—specifies that all bound flows are able to receive messages, and when multiple flows are bound to a non-exclusive topic endpoint, they receive messages in a round-robin fashion.
|
| Topic Name
(Only when using `Durable Topic Endpoint` consumer mode) | The Solace PubSubPlus topic name on which the durable topic subscription needs to be made.
**Warning:** Durable Topic endpoints support a single subscription; should the topic subscription change, all messages persisted to the topic endpoint are deleted. |
| Selector
(Only when using `Guaranteed` or `Durable Topic Endpoint` consumer mode) | A SQL-92 selector to filter messages for consumption. It is a string up to a maximum of 2,000 bytes that uses a conditional expression syntax that is a subset of SQL92.
**Warning:** When binding to a topic in Durable Topic Endpoint mode; should the selector change, all messages persisted to the topic endpoint are deleted. |
| Acknowledgment Mode
(Only when using `Guaranteed` or `Durable Topic Endpoint` consumer mode) | The strategy to be used when acknowledging messages. The possible options are:
- Automatic Immediate
- Messages are acknowledged immediately after being read from the event broker.
- Automatic On Exchange Complete (Default)
- Messages are acknowledged upon exchange completion.
|
| Settlement Outcome After Maximum Attempts
(Only when using `Guaranteed` or `Durable Topic Endpoint` consumer mode and `Automatic On Exchange Complete` acknowledgment mode) | Settlement outcome for failed messages after all processing attempts have been exhausted. The possible options are:
- Failed
- This negative acknowledgment notifies the event broker that the message was not processed. The event broker will attempt to redeliver the message while adhering to delivery count limits.
- Rejected
- This negative acknowledgment notifies the event broker that the message was not accepted. The event broker will remove the message from its queue and then move the message to the Dead Message Queue (DMQ) if it is configured.
|
| Maximum Message Processing Attempts | The maximum number of attempts to process a message.
**Note:** This is an adapter level retry and hence will not result in DeliveryCount header increment. DeliveryCount will increment only when the message is re-delivered by the event broker. |
| Retry Interval (in ms)
(Only when using more than 1 maximum message processing attempts) | The initial time interval to delay retrying to process a message. |
| Maximum Retry Interval (in ms)
(Only when using more than 1 maximum message processing attempts) | The maximum time interval to delay retrying to process a message. |
| Exponential Backoff Multiplier
(Only when using more than 1 maximum message processing attempts) | The multiplier to apply to the current time interval delay after every subsequent retry of a message. If set to `1`, this is equivalent to applying a fixed delay. |
### Message Headers
The adapter accepts headers on both Sender and Receiver side.
The Sender adds the following SMF headers to the Exchange: ApplicationMessageId, ApplicationMessageType, CoS, CorrelationId, DeliveryCount, Destination, DestinationEndpointType, Expiration, HttpContentEncoding, HttpContentType, IsDiscardIndication, IsDMQEligible, IsElidingEligible, IsRedelivered, IsReplyMessage, Priority, ReceiveTimestamp, ReplicationGroupMessageId, ReplyToEndpointType, ReplyToDestination, SenderId, SenderTimestamp, SequenceNumber, TimeToLive, UserProperties.
In addition to the SMF headers there are some non-SMF headers as well that are added to the Exchange by the Sender.
**Note:** These non-SMF headers are not automatically persisted on the message beyond the Exchange.
1. LocalProcessingAttempt - The count of processing attempts per delivery of a message from the Solace PubSubPlus Queue or Durable Topic Endpoint.
2. TotalLocalProcessingAttempt - The total processing attempts for all deliveries which includes redelivery of a message from the Solace PubSubPlus. **Note:** It is required to enable the DeliveryCount feature on your Queue or Durable Topic Endpoint for this feature to work. However, count accuracy is not preserved during iFlow redeployments or restarts. In addition, this count can become inaccurate if redelivered messages from Solace PubSubPlus are handled by consumers other than the original delivery client.
The Sender supports the propagation of SAP_MplCorrelationId. If the incoming message already has a SAP_MplCorrelationId, then the same value is propagated into the Exchange Headers.
When setting up the integration flow, add them to the allowlist via Integration Flow -> Runtime Configuration -> Allowed Header(s), if required. See [Specify the Runtime Configuration](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/specify-runtime-configuration).
### Configure the Solace PubSubPlus Receiver Adapter
The Solace PubSubPlus receiver adapter allows you to send messages to queues or topics on a Solace PubSubPlus broker in SAP Integration Suite using the SMF message protocol.
> **⚠️ Important - Blue-Green Deployment Considerations:** During SAP Cloud Integration's blue-green deployment of worker nodes, connection counts may temporarily double due to the deployment strategy's nature. This occurs because both old and new worker nodes establish connections simultaneously during the switchover phase. Plan your broker service connection thresholds accordingly to avoid `JCSMPErrorResponseException: 503: Too Many Connections` errors during new node startup. To proactively manage this, configure connection count alerts on your broker service and ensure your service plan's connection limits can accommodate the temporary spike. Consider implementing Connection Pooling strategies (available in v1.4.1+) to help reduce connection counts and mitigate this impact during deployment phases.
The **General** tab displays general information about the adapter itself.
| Parameter | Description |
|--------------------|------------------|
| Name/Adapter Type | SolacePubSubPlus |
| Transport Protocol | TCP |
| Message Protocol | SMF |
Switch to the **Connection** tab to configure the adapter's connection details.
#### Connection (Tab)
| Parameter | Description |
|------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Host | The IP address (or host name) to connect to. Multiple host entries separated by commas (up to four) are allowed. With multiple entries, each is tried in turn until one succeeds. Host contains one or more host entries (up to four). A host entry has the form:
`[Protocol:]Host[:Port]`
Protocol is the protocol used for the transport channel. The valid values are:- tcp - use a TCP channel for communications between the application and its peers. If no protocol is set, tcp is used as a default.
- tcps - use a SSL channel over TCP for communications between the application and its peers. The encryption with compression is not supported.
- Host is the IP address (or host name) to connect to for a connection. Port is the port to connect to for a connection. A value is only required when using a port other than the automatically assigned default port number. The default port for TCP is 55555 when compression is not in use, or 55003 when compression is in use. The default port for SSL is 55443.
The secured SMF host name of the event broker can be copied by navigating to the AEM service -> Connect -> Solace Messaging -> Connection Details -> copy the `Secured SMF Host` using the copy icon. |
| Message VPN | The name of the Message VPN to attempt to join when connecting to the event broker. Can be copied from the same place as the host, present under the `Message VPN` section. |
| Username | The client username used for authentication with the event broker. |
| Authentication Type | The authentication mechanism to be used while connecting to Solace PubSubPlus. The available options are:- Basic
- Client Certificate
- OAuth2
|
| Password Secure Alias
(Only when using `Basic` authentication) | The alias which defines the client password used for authentication with the event broker, stored as Secure Parameter. |
| Keystore Alias
(Only when using `Client Certificate` authentication) | The alias of the private Key Pair in the Integration Suite's Keystore. |
| Truststore Alias
(Only when using `Client Certificate` authentication) | The alias of the Certificate in the Integration Suite's Keystore. This is optional and maybe necessary only if event broker host certificate requires to be trusted or not recognized by the JRE. |
| OAuth2 Credential Type
(Only when using `OAuth2` authentication) | The type of OAuth2 credential type to be used. The available options are:- OAuth2 Client Credentials (Integration Suite managed OAuth2 credential store)
- OAuth2 Authorization Code (Integration Suite managed OAuth2 credential store)
- OAuth2 - Custom (Adapter managed OAuth2 credential store)
|
| Access Token Fetch/Refresh Interval (in secs)
(Only when using `OAuth2` authentication) | The interval in seconds for fetching the access token from the respective Integration Suite's credential store when OAuth2 credential type is **Client Credentials** or **Authorization Code**. When **OAuth2 - Custom** type is selected, it is the interval at which the token is refreshed. By default, the value is 300 secs. |
| OAuth2 Client Credentials Credential Name
(Only when using `OAuth2` authentication and `OAuth2 Client Credentials` OAuth2 credential type) | The alias of the deployed OAuth2 Client Credentials artifact in the Integrations Suite's Credential Store. See [Deploying an OAuth2 Client Credentials](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/deploying-oauth2-client-credentials-artifact) know more. |
| OAuth2 Authorization Code Credential Name
(Only when using `OAuth2` authentication and `OAuth2 Authorization Code` OAuth2 credential type) | The alias of the deployed OAuth2 Authorization Code artifact in the Integrations Suite's Credential Store. See [Deploying an OAuth2 Authorization Code](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/deploying-oauth2-authorization-code) know more. |
| OAUTH2 Access Token Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of OAuth2 Access token, stored as Secure Parameter. |
| OAUTH2 Refresh Token Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of the OAuth2 Refresh token, stored as Secure Parameter. |
| OAUTH2 Client ID Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of the OAuth2 Client ID, stored as Secure Parameter. |
| OAUTH2 Refresh Token URL Secure Alias
(Only when using `OAuth2` authentication and `OAuth2 - Custom` OAuth2 credential type) | The alias of the OAuth2 Refresh token URL, stored as Secure Parameter. |
| Proxy Type | The type of proxy connection to be used for connecting to the Solace broker. The available options are:- **Internet** (Default) - Direct connection to Solace broker without proxy
- **On-Premise** - Connection through SAP Cloud Connector for on-premise systems
**Note:** When using On-Premise proxy type, ensure that your SAP Cloud Connector is properly configured and that the Solace broker host is accessible through the Cloud Connector. The adapter uses TCP protocol for communication with the advanced event mesh broker, which utilizes the SOCKS5 proxy endpoint provided by the Cloud Connector for all TCP communications.
**⚠️ Important:** Avoid mixing proxy configurations within the same tenant. If any adapter instance uses "On-Premise" proxy type, it may affect other adapter instances configured for "Internet" connectivity, potentially causing unexpected routing behavior. For consistent results, use the same proxy configuration across all adapter instances in your tenant. |
| Location ID
(Only when using `On-Premise` proxy type) | To connect to an SAP Cloud Connector instance associated with your account, enter the location ID that you defined for this instance in the destination configuration on the cloud side. This parameter is optional if your Cloud Connector uses the default location.
**Important:** This Location ID must match exactly with the location ID configured in your SAP Cloud Connector and the corresponding destination in the SAP BTP Cockpit. |
| JCSMP Properties | A map of key-value pairs to configure additional connection properties. See [JCSMP Properties](https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/com/solacesystems/jcsmp/JCSMPProperties.html) and [JCSMP Channel Properties](https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/com/solacesystems/jcsmp/JCSMPChannelProperties.html) for the available options.
When using "client_name" property, the provided value is always appended with a unique 10 character alphanumeric string separated by a '/'. For eg. if the provided value is "iflow_x_sender" then the actual client_name would become "iflow_x_sender/az077ylyln". The uniqueness is added to succeed the client connection in a multi-worker deployment, where each client is expected to have a unique name.
**NOTE:** JCSMP channel property keys must be prepended by `CLIENT_CHANNEL_PROPERTIES.`.
For example:- `GENERATE_SENDER_ID` (regular JCSMP property)
- `CLIENT_CHANNEL_PROPERTIES.ReconnectRetries` (JCSMP channel property)
**⚠️ Adapter Custom Properties (New in v1.4.1):**
The adapter supports the following custom properties for enhanced functionality:
- `ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE` - Enable connection pooling for Receiver adapters (default: false) - **Receiver adapters only**
- `ADAPTER.CUSTOM_PROP.USE_CPI_TRUSTSTORE` - Automatically configure truststore from SAP CPI keystore service (default: false) - **Available for both Sender and Receiver adapters**
**ⓘ Note (v1.4.1+):** All receiver connections include automatic inactivity-based eviction (5-8 minutes of inactivity) to optimize resource usage. Connections are recreated automatically on demand. When connection pooling is enabled, shared connections persist across individual iFlow undeployments. |
Switch to the **Processing** tab to configure the adapter's message processing details.
#### Processing (Tab)
##### Publisher Processing Details
| Parameter | Description |
|-------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Delivery Mode | The delivery mode for the message being published to the broker. The available options are:
- Direct
- Persistent (Guaranteed)
|
| Endpoint Type | The endpoint/destination type for the message being published. The available options are:
|
| Destination Name | The name of the endpoint/destination for the message being published. It can the name of Topic or Queue based on your selection of the **Endpoint Type**.
This value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`.
**Note:** When using the Receiver as a Replier in the Request-Reply pattern, to set the Destination Name dynamically use the expression `${header.ReplyToDestination}` |
| Message Type | The message type to be used for publishing the message to the broker. The available options are:
- **Automatic** (recommended): The adapter sets the message type based on the message format before the Receiver.
- **Binary**: The adapter converts the message into a Binary type before sending.
- **Text**: The adapter converts the message into a String type before sending.
- **Map**: The adapter converts the message into a Map type before sending.
|
##### Synchronous Request Processing Details
| Parameter | Description |
|--------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Convert Publish Into Synchronous Requestor? | Enable if this is a Request in the Adapter Request/Reply pattern. This will send a Request to the configured Destination, set the ReplyToDestination and CorrelationId, and synchronously wait for a Reply for the duration of the **Reply Timeout(ms)** property. |
| Reply Timeout (ms) (Only when **Convert Publish Into Synchronous Requestor?** is selected) | The timeout for Request-Reply Pattern. |
#### Message Properties (Tab)
| Parameter | Description |
|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Time To Live (ms) | The number of milliseconds before the message is discarded or moved to a Dead Message Queue. The message is set to never expire when this is left blank. Explicitly setting this to 0 resets message expiration to 0. Leaving it blank will ensure the Exchange Header is pass-through. |
| Is DMQ Eligible? | Set the message to be eligible for moving to a Dead Message Queue. Select **None** if you would like to use Exchange Header as pass-through. |
| Is Eliding Eligible? | Sets whether the message is eligible for eliding. Select **None** if you would like to use Exchange Header as pass-through. |
| Priority | The valid priority value range is 0-255 with 0 as the lowest priority and 255 as the highest. Leaving it blank will ensure the Exchange Header is pass-through. |
| Sender Timestamp (ms) | Allows the application to set the send timestamp overriding the API's generated value. Value is in milliseconds, from midnight, January 1, 1970 UTC. Leaving it blank will ensure the Exchange Header is pass-through. |
| Sequence Number | Sets the sequence number for the message being published. If sequence number generation is enabled, this value overrides the generated value. This field can be set automatically during message publishing, but existing values are not overwritten if set, as when a message is sent multiple times. Leaving it blank will ensure the Exchange Header is pass-through. |
| Application Message ID | Sets the application message ID (a string for an application-specific message identifier).
This value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`. Leaving it blank will ensure the Exchange Header is pass-through. |
| Application Message Type | Sets the application message-type.
This value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`. Leaving it blank will ensure the Exchange Header is pass-through. |
| Sender ID | Sets the Sender Id for the message to be published.
This value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`. Leaving it blank will ensure the Exchange Header is pass-through. |
| Class Of Service | Sets the Class of Service (CoS) value for message to be published. Leaving it blank will ensure the Exchange Header is pass-through. |
##### Reply Message Properties
When the Receiver to publish a reply message in the Request-Reply pattern.
> **Note:** These Properties are not available when **Is Requestor** is enabled as they don't apply to the Requestor in the Request-Reply pattern.
| Parameter | Description |
|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Is Reply? | Specify if this is a reply message in a Request-Reply messaging pattern, when the Receiver is used as a Replier. Select 'None' if you would like to use Exchange Header as pass-through. |
| ReplyTo Destination Name | Use this to set the reply-to Destination Name on the message being published to the broker, in a Request-Reply messaging pattern.
This value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`. Leaving it blank will ensure the Exchange Header is pass-through. |
| ReplyTo Endpoint Type | Use this to set the reply-to Endpoint type on the message being published to the broker, in a Request-Reply messaging pattern. The available options are:
Select **None** if you would like to use Exchange Header as pass-through. |
| Correlation ID | Sets the correlation ID for Request-Reply messaging.
This value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`. The correlation ID is used for correlating a request to a reply. Leaving it blank will ensure the Exchange Header is pass-through. |
##### Additional Properties
**User Properties** is Map (key-value) type header. It allows users to specify their own user properties to be carried in the message separate from the payload.
| Parameter | Description |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Key | The key/name of the User Property. |
| Value | The value of the respective User Property's key/name.
The value can be defined dynamically by using the following expressions: `${header.headerName}` or `${property.propertyName}`. |
### Message Headers
The adapter accepts headers on both Sender and Receiver side.
The Receiver can support the following headers on the message being published to the broker: ApplicationMessageId, ApplicationMessageType, CoS, CorrelationId, DeliveryCount, Destination, DestinationEndpointType, Expiration, HttpContentEncoding, HttpContentType, IsDiscardIndication, IsDMQEligible, IsElidingEligible, IsRedelivered, IsReplyMessage, Priority, ReceiveTimestamp, ReplicationGroupMessageId, ReplyToEndpointType, ReplyToDestination, SenderId, SenderTimestamp, SequenceNumber, TimeToLive, UserProperties. When setting up the integration flow, add them to the allowlist via Integration Flow -> Runtime Configuration -> Allowed Header(s), if required. See [Specify the Runtime Configuration](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/specify-runtime-configuration). Some of these headers can be defined at design-time via the **Message Properties** tab and the rest could be defined using a Content Modifier.
Additionally, the SAP_MplCorrelationId is propagated in every outgoing message as an entry in the UserProperties.
## Performance Optimization
### Connection Pooling for Receiver Adapters (New in v1.4.1)
The Solace PubSubPlus adapter includes intelligent connection pooling **exclusively for Receiver (Producer) adapters** to optimize resource utilization in scenarios with multiple receiver endpoints sharing similar connection parameters. This feature is not available for Sender adapters.
#### How Connection Pooling Works
When multiple Receiver adapters within the same tenant have identical connection parameters (host, authentication, proxy settings, etc.), the adapter can share pooled connections instead of creating separate connections for each adapter instance.
#### Configuration
Connection pooling is controlled by the `ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE` property in the JCSMP Properties configuration:
| Configuration | Behavior | Use Case |
|---------------|----------|----------|
| `ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE=true` | **Enabled**: Multiple receivers with identical connection parameters share pooled connections | Multi-receiver scenarios with same broker, authentication, and proxy settings |
| `ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE=false` or not set | **Disabled** (Default): Each receiver gets a unique connection with auto-generated unique identifier | Independent receivers or when connection isolation is required |
#### Pool Characteristics
- **Expiration**: Connections expire after 5 minutes of inactivity (NEW in v1.4.1 - applies to all receiver connections regardless of pooling setting)
- **Cleanup**: Automatic cleanup every 2 minutes. Connections are cleaned up 5-8 minutes after expiry (5-minute expiry + up to 2-minute delay for cleanup job cycle)
- **On-Demand Creation**: Connections are automatically recreated when needed after eviction
- **iFlow Undeployment Behavior**:
- **When connection reuse is disabled** (Default): Connection is removed immediately on iFlow undeployment (unchanged behavior)
- **When connection reuse is enabled** (NEW in v1.4.1): Shared connections remain active after individual iFlow undeployments since other iFlows may be using the same connection. Connection is only removed after 5-8 minutes of inactivity across all sharing iFlows.
#### Example Configuration
**Scenario**: Three receiver adapters publishing to different queues but using the same Solace broker
**With Connection Reuse Enabled:**
```
All three receivers configured with:
- Host: tcps://mr-connection-xyz789.messaging.solace.cloud:55443
- Message VPN: production-vpn
- Authentication Type: Basic
- Username: publisher-user
- JCSMP Properties: ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE=true
```
**Result**: All three receivers share a single pooled connection.
**With Connection Reuse Disabled (Default):**
Same configuration but `ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE=false` or property not set.
**Result**: Each receiver gets its own dedicated connection.
#### Advanced: Multiple Connection Pools for High Throughput
For high-throughput scenarios using **Persistent (Guaranteed) messaging**, you can create multiple connection pools by using different `CLIENT_NAME` values while keeping connection reuse enabled. This balances resource optimization with performance scaling.
**Scenario**: 60 receivers with high throughput requirements (>10,000 msg/sec total) using Persistent delivery mode
**Configuration Strategy:**
```
Pool 1 (Receivers 1-20):
- Host: tcps://mr-connection-xyz789.messaging.solace.cloud:55443
- Message VPN: production-vpn
- Authentication Type: Basic
- Username: publisher-user
- Delivery Mode: Persistent (Guaranteed)
- JCSMP Properties:
- CLIENT_NAME: high-throughput-pool-1
- PUB_ACK_WINDOW_SIZE: 50
- ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE: true
Pool 2 (Receivers 21-40):
- Same connection parameters as Pool 1
- Delivery Mode: Persistent (Guaranteed)
- JCSMP Properties:
- CLIENT_NAME: high-throughput-pool-2
- PUB_ACK_WINDOW_SIZE: 50
- ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE: true
Pool 3 (Receivers 41-60):
- Same connection parameters as Pool 1
- Delivery Mode: Persistent (Guaranteed)
- JCSMP Properties:
- CLIENT_NAME: high-throughput-pool-3
- PUB_ACK_WINDOW_SIZE: 50
- ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE: true
```
**Result**:
- **3 pooled connections** (different CLIENT_NAME creates separate pools)
- **20 receivers share each connection** (same CLIENT_NAME within each pool)
- **Broker sees 3 client connections** vs 60 without pooling (95% reduction)
- **Throughput scales linearly** (3× capacity vs single shared connection)
**Key Insights**:
- Same CLIENT_NAME = shared connection within that pool. Different CLIENT_NAME = separate connection pools.
- **PUB_ACK_WINDOW_SIZE**: Controls the maximum number of messages that can be published without waiting for acknowledgment from the broker (range: 1-255, default: 1). Higher values (50-255) significantly improve throughput for Persistent messaging by allowing the publisher to send multiple messages in flight before blocking for acknowledgments. This reduces round-trip latency overhead and maximizes network utilization. **Note**: Only applicable to Persistent (Guaranteed) messages; Direct messages do not use publisher acknowledgments.
#### Best Practices
- **Enable for similar configurations**: Use connection pooling when multiple receivers have identical connection parameters
- **Consider authentication impact**: Pooled connections share the same authentication context
- **Ensure identical parameters**: All connection parameters (host, VPN, authentication, proxy settings) must match for successful connection reuse
#### Important: Credential Rotation and Password Changes
**When passwords or credentials change in SAP Integration Suite's Secure Parameters, affected iFlows must be redeployed to pick up the new credentials.** Running iFlows will continue using their existing connection with the old credentials until redeployment.
#### When to Avoid Connection Pooling
- When each receiver requires unique monitoring or client identification
- When compliance/auditing requires connection-level isolation
- Single receiver deployments (no benefit)
#### Troubleshooting Connection Pooling
**Connection Pool Not Working**:
1. Verify that `ADAPTER.CUSTOM_PROP.RECEIVER_CONNECTION_REUSE` is set to `true` on all receivers
2. Ensure identical connection parameters (host, VPN, authentication, proxy settings)
3. Check that all connection-related JCSMP properties match across receivers