Products Downloads


French version


 

      

      

      


EADELIA





(B) (C)

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

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

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

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

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.

Nats Streaming

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.

BRK_RESPONSE '*STOP_DURABLE'

Stops the subscriber at the end of the onMessage section of the current message and reinitializes its durable subscription.

When a subscriber has a durable subscription ("subconf/config/brokerConfig/subscribeTopic/durableName" key), when it is stopped (*STOP), restarts and resubscribes with the same clientId and durableName value, the broker continues message distribution starting with the first message, without acknowledgment for this durable subscription.

When the subscriber is stopped with *STOP_DURABLE, the subscription is reinitialized and the broker distributes the messages according to the defined configuration.

As the stop request from the consumer is made asynchronously, one or more messages may be sent to the subscriber before its closure.

Note:

*STOP and *STOP_DURABLE are exclusive.

RabbitMQ AMQP

BRK_RESPONSE '*STOP'

Stops the subscriber at the end of the onMessage section of the current message.
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

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

<Numeric constant> | <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

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

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

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

<Numeric constant> | <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.

Nats Streaming

BRK_RESPONSE '*ACK'

When the "subconf/config/brokerConfig/subscribeTopic/manualAcks" key is *TRUE, positively acknowledges the message being handled.

BRK_RESPONSE '*NACK'

When the "subconf/config/brokerConfig/subscribeTopic/manualAcks" key is *TRUE, negatively acknowledges the message being handled.

The broker will subsequently redistribute the message.

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
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.
Nats Streaming
No specific errors.
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

 


  • Aucune étiquette