Step 1: Connecting to Your Event Broker
The Micro-Integration uses the Spring Cloud Stream Binder for Solace to communicate with the event broker. The binder manages an underlying JCSMP session, the persistent connection between the Micro-Integration and the broker. This configuration controls that session only. It is separate from the connection to the vendor system (see Step 3: Vendor-Specific Configuration for Self-Managed Micro-Integrations) and from the management web server (see Step 6: Securing Management Web Endpoints).
The Spring Cloud Stream Binder for Solace uses Spring Boot Auto-Configuration for the Solace Java API to configure its session. In the application.yml, this typically is configured as follows:
solace:
java:
host: tcp://localhost:55555
msg-vpn: default
client-username: default
client-password: default
For more information and options to configure the Solace session, see Spring Boot Auto-Configuration for the Solace Java API.
For information about how to connect to your vendor system, see Step 3: Vendor-Specific Configuration for Self-Managed Micro-Integrations.
Named Binder Configuration
The preceding example places Solace session properties at the top-level solace.java prefix, which works when only one binder is in use. When your connector defines a named binder (as most vendor-specific Micro-Integrations do), the session properties covered on this page must be scoped under spring.cloud.stream.binders.<binder-name>.environment.solace.java instead. This scoping applies only to the event broker session properties described here; for the binder options that control messaging behavior, such as consumer and producer settings, see Step 2: Configuring the Spring Cloud Stream Binder.
spring:
cloud:
stream:
binders:
<binder-name>:
type: solace
environment:
solace:
java:
host: tcp://<broker-host>:55555
msgVpn: <vpn-name>
clientUsername: <username>
clientPassword: <password>
See the vendor-specific configuration topic for the binder name used by your Micro-Integration.
Authentication
By default, the binder authenticates using a client username and password (clientUsername and clientPassword). If your broker is configured for OAuth2 authentication, the binder can use an OAuth token instead. OAuth2 requires additional dependencies and configuration. See JCSMP Spring Boot: Using OAuth2 Authentication Scheme for setup instructions.
TLS for the Broker Connection
Encrypting the broker connection is independent of TLS for the management web server (see Step 6: Securing Management Web Endpoints). To encrypt the connection to the broker, change the host protocol to tcps:// and configure the trust store via apiProperties:
solace:
java:
host: tcps://<broker-host>:55443
apiProperties:
ssl_trust_store: /path/to/truststore
ssl_trust_store_password: <password>
ssl_validate_certificate: true
Setting ssl_validate_certificate to false disables certificate validation. Do not use this in production. For information about configuring TLS on the broker side, see TLS/SSL Service Connections.
Reconnection
By default, the binder does not retry the initial connection or attempt to reconnect after a disconnect. For production deployments, configure retry behavior explicitly:
solace:
java:
connectRetries: -1 # -1 = retry indefinitely on initial connect
reconnectRetries: -1 # -1 = retry indefinitely after disconnect
reconnectRetryWaitInMillis: 3000 # wait 3 seconds between attempts
During reconnection, the binder health indicator reports RECONNECTING. The solace.health-check.connection.reconnectAttemptsUntilDown property controls how many reconnect attempts occur before the health indicator transitions to DOWN instead. The default, 0, disables this behavior, so the indicator stays RECONNECTING until the session recovers or fails permanently. See Step 7: Configuring and Using the Health Endpoint for more information.
Validating the Connection
After starting the Micro-Integration, verify the broker connection by querying the health endpoint. A healthy connection is reflected in the binder health indicator with a status of UP. If the binder instead shows RECONNECTING or DOWN, check for common causes such as an incorrect host or port, rejected credentials, or blocked network access to the broker. For more information about the health endpoint and the possible binder health statuses, see Monitoring the Self-Managed Micro-Integration's State and Step 7: Configuring and Using the Health Endpoint.
Preventing Message Loss When Publishing to Topic-to-Queue Mappings
If the Micro-Integration is publishing to a topic that is subscribed to by a queue, messages may be lost if they are rejected (for example, if queue ingress is shut down).
To prevent message loss, configure the reject-msg-to-sender-on-discard option with the including-when-shutdown flag.