Section for use
onStart / onMessage
Syntax
BRK_RESPONSE AlphaPropertyName ParameterSeries
ParameterSeries
| → | ParameterSeries Parameter | Parameter | Null |
Parameter | → | <parameter variable> | <literal parameter> |
Description
This instruction sets information on the response to return at the end of the onStart/onMessage section.
In an onStart section
An EADELIA program enables the user to stop the subscriber from starting when executing the onStart section: the BRK_RESPONSE instruction positively or negatively acknowledges the ON_START event.
In the case of a negative acknowledgment, ON_ERROR and ON_STOP events are sent to the subscriber: onError and onStop sections are executed and the subscriber is stopped before subscribing to the defined topics.
By default, if there is no explicit acknowledgment from the user, the EADELIA program positively acknowledges the ON_START event and the subscriber starts.
Positive acknowledgment
BRK_RESPONSE '*ACK'
Negative acknowledgment
BRK_RESPONSE '*NACK'
Note:
This acknowledgment is taken into account at the end of the onStart section.
Only the last acknowledgment value (the last BRK_RESPONSE instruction executed) is taken into account.
In an onMessage section
This instruction sets a response following the handling of the current message in the onMessage section:
- the subscriber can be stopped at the end of the current message handling,
- according to the broker type, the message can be positively or negatively acknowledged.
Stop the subscriber
The stop request results in an ON_STOP event being sent to the subscriber (the onStop section is executed). Depending on the broker, the subscriber stop process can be identified:
Kafka
| Kafka |
|---|
BRK_RESPONSE '*STOP' | According to the "subconf/config/brokerConfig/subscribeTopic/stopImmediate" key value, stops the subscriber at the end of the onMessage section of the current message or last message in the batch retrieved in the last poll function call. |
MQTT v3
| MQTT v3 |
|---|
BRK_RESPONSE '*STOP' | Stops the subscriber at the end of the onMessage section of the current message. As the stop request from the consumer is made asynchronously, one or more messages may be sent to the subscriber before its closure. |
MQTT v5
| MQTT v5 |
|---|
BRK_RESPONSE '*STOP' | Stops the subscriber at the end of the onMessage section of the current message. As the stop request from the consumer is made asynchronously, one or more messages may be sent to the subscriber before its closure. |
Nats Jetstream
| Nats Jetstream |
|---|
BRK_RESPONSE '*STOP' | Stops the subscriber at the end of the onMessage section of the current message |
BRK_RESPONSE '*STOP_AFTER_BATCH' | Stops the subscriber at the end of the onMessage section of the last message in the batch retrieved in the last message retrieval function call (only if the "subconf/config/brokerConfig/subscribeTopic/subscribeType" key is "Pull"). |
Note:
*STOP and *STOP_AFTER_BATCH are exclusive.
RabbitMQ AMQP
| RabbitMQ AMQP |
|---|
BRK_RESPONSE '*STOP' | Stops the subscriber at the end of the onMessage section of the current message. |
Redis Pub/Sub
| Redis Pub/Sub |
|---|
BRK_RESPONSE '*STOP' | Stops the subscriber at the end of the onMessage section of the current message. As the stop request from the consumer is made asynchronously, one or more messages may be sent to the subscriber before its closure. |
Acknowledging the message
The message acknowledgment request is carried out when the BRK_RESPONSE instruction is called (unlike the acknowledgment request in the onStart section, which is taken into account at the end of the section execution).
This request is only taken into account if the subscriber has been defined with a manual rather than automatic acknowledgment mode.
Depending on the broker, the message acknowledgment process can be identified:
Kafka
| Kafka |
|---|
BRK_RESPONSE '*ACK' | When the "subconf/config/brokerConfig/subscribeTopic/ackMode" key is "MANUAL" or "MANUAL_IMMEDIATE", positively acknowledges the message being handled (if the "subconf/config/brokerConfig/subscribeTopic/typeMsgHandling" key is "SINGLE") or the messages handled in the batch (if the "subconf/config/brokerConfig/subscribeTopic/typeMsgHandling" key is "BATCH").
Kafka stores the position of the last message sent and the last message acknowledged in the partitions. Acknowledgment can be carried out after each message has been handled or after a certain number of messages have been handled: the acknowledgment of the last message handled will acknowledge the handled messages that have not yet been committed. In the case of "BATCH" handling of messages, the position of the handled message in the batch can be seen via the 'firstPolled' and 'lastPolled' keys associated with the message.
|
BRK_RESPONSE '*NACK' SleepTime SleepTime | → | <NumConstant> | <NUM_BIN_8 variable> |
| When the "subconf/config/brokerConfig/subscribeTopic/ackMode" key is "MANUAL" or "MANUAL_IMMEDIATE", negatively acknowledges the message being handled (if the "subconf/config/brokerConfig/subscribeTopic/typeMsgHandling" key is "SINGLE") or the messages handled in the batch (if the "subconf/config/brokerConfig/subscribeTopic/typeMsgHandling" key is "BATCH").
The SleepTime parameter indicates the subscriber's sleep time allowing the broker to manage the reorganization of messages to handle. The broker will subsequently redistribute the message(s) (to the same subscriber or another subscriber in the same group).
|
MQTT v3
| MQTT v3 |
|---|
BRK_RESPONSE '*ACK' | When the "subconf/config/brokerConfig/subscribeTopic/manualAcks" key is *TRUE and the message's quality of service (QoS) is strictly higher than 0, positively acknowledges the message being handled. |
BRK_RESPONSE '*NACK' | When the "subconf/config/brokerConfig/subscribeTopic/manualAcks" key is *TRUE and the message's quality of service (QoS) is strictly higher than 0, negatively acknowledges the message being handled. The broker will subsequently redistribute the message.
|
MQTT v5
| MQTT v5 |
|---|
BRK_RESPONSE '*ACK' | When the "subconf/config/brokerConfig/subscribeTopic/manualAcks" key is *TRUE and the message's quality of service (QoS) is strictly higher than 0, positively acknowledges the message being handled. |
BRK_RESPONSE '*NACK' | When the "subconf/config/brokerConfig/subscribeTopic/manualAcks" key is *TRUE and the message's quality of service (QoS) is strictly higher than 0, negatively acknowledges the message being handled. The broker will subsequently redistribute the message.
|
Nats Jetstream
| Nats Jetstream |
|---|
BRK_RESPONSE '*ACK' | When the "subconf/config/brokerConfig/subscribeTopic/pushSubOpts/consumerConfig/ackPolicy" or "subconf/config/brokerConfig/subscribeTopic/pullSubOpts/consumerConfig/ackPolicy" key is "All" or "Explicit", positively acknowledges (asynchronously) the message being handled ("Explicit") or all the messages being handled in the batch ("All"). |
BRK_RESPONSE '*NACK' | When the "subconf/config/brokerConfig/subscribeTopic/pushSubOpts/consumerConfig/ackPolicy" or "subconf/config/brokerConfig/subscribeTopic/pullSubOpts/consumerConfig/ackPolicy" key is "All" or "Explicit", negatively acknowledges the message being handled ("Explicit") or all the messages being handled in the batch ("All")..
The broker will subsequently redistribute the message(s).
|
BRK_RESPONSE '*ACK_SYNC' Timeout Timeout | → | <NumConstant> | <NUM_BIN_8 variable> |
| When the "subconf/config/brokerConfig/subscribeTopic/pushSubOpts/consumerConfig/ackPolicy" or "subconf/config/brokerConfig/subscribeTopic/pullSubOpts/consumerConfig/ackPolicy" key is "All" or "Explicit", positively acknowledges (synchronously) the message being handled ("Explicit") or all the messages being handled in the batch ("All")..
The Timeout parameter indicates the wait time (in nanoseconds) for acknowledgment confirmation by the broker. A value of 0 avoids having to wait for confirmation from the broker. |
| BRK_RESPONSE '*TERM' | When the "subconf/config/brokerConfig/subscribeTopic/pushSubOpts/consumerConfig/ackPolicy" or "subconf/config/brokerConfig/subscribeTopic/pullSubOpts/consumerConfig/ackPolicy" key is "All" or "Explicit", indicates that you have not succeeded in handling the message and asks the broker not to return it (to any consumer). |
| BRK_RESPONSE '*IN_PROGRESS' | When the "subconf/config/brokerConfig/subscribeTopic/pushSubOpts/consumerConfig/ackPolicy" or "subconf/config/brokerConfig/subscribeTopic/pullSubOpts/consumerConfig/ackPolicy" key is "All" or "Explicit", indicates to the broker that the message is being handled and asks to reset the redistribution timer for this message (because you need more time to handle it). Handling must end with an *ACK or *NACK or *ACK_SYNC or *TERM acknowledgment. |
RabbitMQ AMQP
| RabbitMQ AMQP |
|---|
BRK_RESPONSE '*ACK' Multiple Multiple | → | <Boolean constant>|< BOOL variable> |
| When the "subconf/config/brokerConfig/subscribeTopic/autoAck" key is *FALSE, positively acknowledges the message being handled.
When its value is *TRUE, the Multiple value can be used to acknowledge all messages that have not yet been acknowledged, including the current message, and when its value is *FALSE, to acknowledge the current message only.
|
BRK_RESPONSE '*NACK' Multiple Requeue Multiple | → | <Boolean constant>|< BOOL variable> | | Requeue | ? | <Boolean constant>|< BOOL variable> |
| When the "subconf/config/brokerConfig/subscribeTopic/autoAck" key is *FALSE, negatively acknowledges the message being handled.
When its value is *TRUE, the Multiple parameter can be used to not acknowledge all messages that have not yet been acknowledged, including the current message, and when its value is *FALSE, to not acknowledge the current message only.
When its value is *TRUE, the Requeue parameter is used to put the rejected message(s) back in the queue, and when its value is *FALSE, to reject and dead-letter the message(s) if the subscription configuration allows. |
BRK_RESPONSE '*REJECT' Requeue Requeue | → | <Boolean constant>|< BOOL variable> |
| When the "subconf/config/brokerConfig/subscribeTopic/autoAck" key is *FALSE, negatively acknowledges the message being handled.
When its value is *TRUE, the Requeue parameter is used to put the rejected message(s) back in the queue, and when its value is *FALSE, to reject and dead-letter the message if the subscription configuration allows. |
Redis Pub/Sub
| Redis Pub/Sub |
|---|
| No notion of message acknowledgment with this broker. |
After this instruction has been executed, the *RETURN_CODE reserved word can take the following values:
0 (*NORMAL) |
Operation completed successfully. |
-1 |
Internal error. |
-2 |
The AlphaPropertyName parameter corresponds to an unknown reserved word.
|
-3 |
The second parameter must be Boolean. |
| Kafka |
| -20 |
The second parameter must be NUM_BIN_8 type. |
| MQTT v3 |
| No specific errors. |
| MQTT v5 |
| No specific errors. |
| Nats JetStream |
| -20 |
Message *ACK acknowledgment error. |
| -21 |
Message *NACK acknowledgment error. |
| -22 |
Message *TERM acknowledgment error. |
-23 |
Message *IN_PROGRESS acknowledgment error. |
| -24 |
Message *ACK_SYNC acknowledgment error. |
| -25 |
*ACK_SYNC must have a NUM_BIN_8-type parameter. |
| -26 |
Long-to-Duration conversion error for *ACK_SYNC. |
| RabbitMQ AMQP |
| -20 |
The second parameter must be Boolean. |
| -21 |
The second and third parameters must be Boolean. |
| -22 |
Message *ACK acknowledgment error. |
| -23 |
Message *NACK acknowledgment error. |
| -24 |
Message *REJECT acknowledgment error. |
| Redis Pub/Sub |
| No specific errors. |
Example
* Positive acknowledgment in onStart block.
BRK_RESPONSE '*ACK'
* Stop Nats Jetstream subscriber
ALPHA(10) order
order = '*stop'
BRK_RESPONSE order
* Negative acknowledgment of RabbitMQ AMQP message
BRK_RESPONSE '*NACK' *TRUE *FALSE
IF *RETURN_CODE<> *NORMAL
ADD_TRACE '*NACK error' *ERROR
END↑ Top of page
