AbstractAbstract Readonlyconnected$An Observable that, when subscribed, emits the current connection state to the broker. Upon subscription, emits the current connection state, unless no connect attempt has been made yet. It never completes and emits continuously when the connection state changes.
Abstract ReadonlysessionPromise that resolves to the Session when connected to the message broker, or that rejects if no connection could be established, or if no connect attempt has been made yet.
Abstractbrowse$Browses messages in a queue, without removing/consuming the messages. Messages are received in the zone in which subscribed to the Observable.
Specifies the queue to browse, or a descriptor object describing how to connect to the queue browser.
Observable that emits spooled messages in the specified queue. The Observable never completes. If not connected to the broker yet, or if the connect attempt failed, the Observable errors.
Abstractconsume$Consumes messages from a given topic endpoint or queue endpoint. Messages are received in the zone in which subscribed to the Observable.
Endpoint names are case-sensitive and consist of one or more segments, each separated by a forward slash.
When passing a string topic literal (that is, not a MessageConsumerProperties object), creates a private, non-durable topic endpoint on the broker that subscribes
to messages published to the given topic. From the consumer's point of view, this is similar to observe a topic using SolaceMessageClient#observe$, with the difference
that messages are not lost in the event of short connection interruptions as messages are retained on the broker until transported to the consumer. The lifecycle of a non-durable
topic endpoint is bound to the client that created it, with an additional 60s in case of unexpected disconnect.
To subscribe to a queue, or to pass a more advanced endpoint configuration, pass a MessageConsumerProperties object instead.
string topic literal is equivalent to passing the following config:solaceMessageClient.consume$({
topicEndpointSubscription: SolclientFactory.createTopicDestination('topic'),
queueDescriptor: new QueueDescriptor({
type: QueueType.TOPIC_ENDPOINT,
durable: false,
}),
});
solaceMessageClient.consume$({
queueDescriptor: new QueueDescriptor({
type: QueueType.QUEUE,
name: 'queue',
}),
});
A topic is not the same thing as a topic endpoint. Messages cannot be published directly to topic endpoints, but only indirectly via topics. A topic is a message property the event broker uses to route a message to its destination. Topic endpoints, unlike topics, are objects that define the storage of messages for a consuming application. Topic endpoints are more closely related to queues than to topics. For more information, refer to https://solace.com/blog/queues-vs-topic-endpoints.
For topic endpoints, you can subscribe to multiple topics simultaneously by using wildcard segments in the topic.
Single-Level Wildcard Character (*):
*) character as its only character, this segment is required and acts as a placeholder for any segment value.*) character, this segment acts as a placeholder for segment values starting with the characters before the asterisk.
The segment to match can have additional characters, must does not have to.Multi-Level Wildcard Character (>):
See https://docs.solace.com/PubSub-Basics/Wildcard-Charaters-Topic-Subs.htm for more information and examples.
If a segment begins with a colon (:), it is called a named wildcard segment that acts as a placeholder for any value. The characters after the colon give the segment its name.
Internally, named wildcard segments are translated to single-level wildcard segments. Named segments can be read from the received message
For example, the topic 'myhome/:room/temperature' is translated to 'myhome/* /temperature', matching messages sent to topics like 'myhome/kitchen/temperature' or 'myhome/livingroom/temperature'.
Substituted segment values are then available in MessageEnvelope.params, or as the second element of the tuple when using mapToBinary or mapToText RxJS operators.
To map directly to the payload, you can use the following RxJS operators: mapToBinary, mapToText.
If specifying a string literal, then it is used as the subscription topic to create a topic endpoint for, allowing messages to be reliably received even if the
connection is unstable. If passing a descriptor object, it is used as the config to connect to a queue or topic endpoint.
A topic endpoint subscription allows using wildcards (single-level or multi-level) to subscribe to multiple topics simultaneously.
As an alternative to the single-level wildcard *, named wildcard segments can be used. A named wildcard segment begins with a colon (:) followed by a name. Substituted segments can be read from the received message.
Observable that emits when receiving a message published to the given endpoint. The Observable never completes. If not connected to the broker yet, or if the connect attempt failed, the Observable errors.
Abstractobserve$Receives messages published to the given topic. Messages are received in the zone in which subscribed to the Observable.
The Observable never completes, unless invoking disconnect. If not connected to the broker yet, or if the connect attempt failed, the Observable errors.
You can subscribe to multiple topics simultaneously by using wildcard segments in the topic. Topics are case-sensitive and consist of one or more segments, each separated by a forward slash.
Single-Level Wildcard Character (*):
*) character as its only character, this segment is required and acts as a placeholder for any segment value.*) character, this segment acts as a placeholder for segment values starting with the characters before the asterisk.
The segment to match can have additional characters, must does not have to.Multi-Level Wildcard Character (>):
See https://docs.solace.com/PubSub-Basics/Wildcard-Charaters-Topic-Subs.htm for more information and examples.
If a segment begins with a colon (:), it is called a named wildcard segment that acts as a placeholder for any value. The characters after the colon give the segment its name.
Internally, named wildcard segments are translated to single-level wildcard segments. Named segments can be read from the received message
For example, the topic 'myhome/:room/temperature' is translated to 'myhome/* /temperature', matching messages sent to topics like 'myhome/kitchen/temperature' or 'myhome/livingroom/temperature'.
Substituted segment values are then available in MessageEnvelope.params, or as the second element of the tuple when using mapToBinary or mapToText
RxJS operators.
To map directly to the payload, you can use the following RxJS operators: mapToBinary, mapToText.
Specifies the topic which to observe.
Topics are case-sensitive and consist of one or more segments, each separated by a forward slash.
You can subscribe to the exact topic of a published message, or use wildcards (single-level or multi-level) to subscribe to multiple topics simultaneously.
As an alternative to the single-level wildcard *, named wildcard segments can be used. A named wildcard segment begins with a colon (:) followed by a name.
Substituted segments can be read from the received message.
Optionaloptions: ObserveOptionsControls how to observe the topic.
Observable that emits when receiving a message published to the given topic. The Observable never completes. If not connected to the broker yet, or if the connect attempt failed, the Observable errors.
AbstractpublishPublishes a message to the given topic or queue destination.
When sending the message to a topic destination, the broker will transport the message to all subscribers subscribed to the topic at the time of sending the message.
A queue differs from the topic distribution mechanism that the message is transported to exactly a single consumer, i.e., the message is load balanced to a single consumer in round‑robin fashion, or for exclusive queues, it is always transported to the same subscription. When sending a message to a queue, the broker retains the message until it is consumed, or until it expires. Refer to the subsequent chapter 'Durability of Endpoints' for more information. A queue is typically used in a point-to-point (P2P) messaging environment.
A topic is not the same thing as a topic endpoint. Messages cannot be published directly to topic endpoints, but only indirectly via topics. A topic is a message property the event broker uses to route a message to its destination. Topic endpoints, unlike topics, are objects that define the storage of messages for a consuming application. Topic endpoints are more closely related to queues than to topics. For more information, refer to https://solace.com/blog/queues-vs-topic-endpoints.
Destinations case-sensitive and consist of one or more segments, each separated by a forward slash. The destination must be exact, thus not contain wildcards.
A message may contain unstructured byte data, or a structured container. See Data for further information.
Solace supports two delivery modes, also known as qualities of service (QoS):
You can change the message delivery mode via the PublishOptions.deliveryMode property. For more information, refer to the documentation of PublishOptions.deliveryMode.
Solace distinguishes between durable und non-durable queues.
When sending the message to a durable queue, the broker retains the message until it is consumed (and also acknowledged) by the consumer, or until it expires. In constract, a non-durable queue, also known as a temporary queue, has a shorter lifecycle than a durable queue. It has the lifespan of the client that created it, with an additional 60 seconds in case of unexpected disconnect. The 60 seconds provides the client with some time to reconnect to the endpoint before it and its contents are deleted from the Solace broker.
Although the terms durable and persistent are related, keep in mind that the concept 'durability' applies to endpoints, whereas 'persistence' applies to event messages.
For further information refer to:
Specifies the destination where to send the message to. If of the type string, sends it to a topic destination.
To send a message to a queue, pass a queue Destination which can be constructed using the SolclientFactory, as following:
SolclientFactory.createDurableQueueDestination('queue')
Optionaldata: Data | MessageSpecifies optional transfer data to be carried along with this message. A message may contain unstructured byte data, or structured data in the form of a SDTField. Alternatively, to have full control over the message to be published, pass the Message object instead, which you can construct using SolclientFactory#createMessage. For more information, refer to the documentation of Data.
Optionaloptions: PublishOptionsControls how to publish the message.
A Promise that resolves when the message could be successfully dispatched or that rejects otherwise. The Promise resolves immediately if the published message has the delivery mode MessageDeliveryModeType#DIRECT (direct messaging). If the published message has the delivery mode MessageDeliveryModeType#PERSISTENT (guaranteed or persistent messaging), the Promise resolves once acknowledged, i,e., when one-third of the publish window size is reached or one second has elapsed. Refer to https://docs.solace.com/API/API-Developer-Guide/Acknowledging-Published-.htm for more information.
AbstractreplyReplies to the passed request.
Specifies the request to send a reply for.
Optionaldata: Data | MessageSpecifies optional transfer data to be carried along with the reply. The reply may contain unstructured byte data, or structured data in the form of a SDTField. Alternatively, to have full control over the message to be published, pass the Message object instead, which you can construct using SolclientFactory#createMessage. For more information, refer to the documentation of Data.
Optionaloptions: PublishOptionsControls how to publish the reply.
A Promise that resolves when dispatched the reply, or that rejects if the reply could not be dispatched.
Abstractrequest$Sends a request to the specified destination and waits for the response to arrive. Replies are received in the zone in which subscribed to the Observable.
Note:
The implementation is based on "solclientjs" Session#sendRequest which does not support receiving multiple responses
and requires the replier to include the requestor's correlationId in the reply message.
Specifies the destination where to send the message to. If of the type string, sends it to a topic destination.
Optionaldata: Data | MessageSpecifies optional transfer data to be carried along with this request. The request may contain unstructured byte data, or structured data in the form of a SDTField. Alternatively, to have full control over the message to be published, pass the Message object instead, which you can construct using SolclientFactory#createMessage. For more information, refer to the documentation of Data.
Optionaloptions: RequestOptionsControls how to publish the request, e.g., to pass a custom 'replyTo' destination.
Observable that emits the received reply and then completes, or that errors if the request could not be dispatched or no reply was received within the specified timeout.
Allows clients to communicate with a Solace messaging broker for sending and receiving messages using the native SMF protocol (Solace Message Format).
This message client establishes a single connection to the broker regardless of the number of subscriptions.
See https://docs.solace.com/API-Developer-Online-Ref-Documentation/js/index.html for more information about the Solace Web API.