The AMBSS is used to execute a specific type of Adelia program: EADELIA (Event Adelia). This type of program can only be used for users with the SOA license.
An EADELIA program is designed to handle messages sent by a broker. However, an EADELIA program is independent from the broker type: it can also consume messages from different brokers. Each instance of this program will consume a specific broker.
An EADELIA program is a Batch program generated for the "Event" Java platform. This program can only be called by the AMBSS. In addition, it can have the following type of parameters: ALPHA / NUM_BIN_2 / NUM_BIN_4 / NUM_BIN_8 / NUM_E / NUM_P / BOOL / DATE / TIME / TIMESTAMP.
An EADELIA program cannot call another EADELIA program but can call:
- A VA_B program (with or without report) generated for the "Event" Java platform,
- an SA_B program (from its server part).
Multilingual generation is authorized for this type of program to handle localized dictionary constants.
Finally, an EADELIA program works only with pooled DB connections.
Principles
An EADELIA program is linked to a subscriber via its description (in the config/adeliaPgm object).
The program is created by the factory then interacts with the native subscriber.
An EADELIA program handles events sent to it in a synchronous and sequential way. A corresponding handling block (a section) is associated with each event.
A single program instance is used throughout the lifecycle of an Adelia subscriber (start, message consumption, stop). An EADELIA program is stateful.
After creating the program instance, an ON_START event is sent to notify the user of the Adelia subscriber being started: the corresponding onStart instructions block is executed. If user initialization processing fails, the ON_START event can be negatively acknowledged to stop the Adelia subscriber. onError (ON_ERROR event) then onStop (ON_STOP event) blocks will be executed in sequence.
If the ON_START event is positively acknowledged, the factory creates the associated native subscriber which connects and subscribes to the broker. Then the broker sends the available messages to the native subscriber.
Case 1 describes standard message handling: It is sent by the broker to the native subscriber which sends it to the EADELIA program via the ON_MESSAGE event. The message is handled in the onMessage block and the user acknowledges the message (positively or negatively). The acknowledgment is then sent to the broker by the native subscriber.
Case 2 describes error handling: An error can be sent by the broker or the native subscriber. It is sent to the program via the ON_ERROR event. The error is handled in the onError block. If the error is critical, an ON_STOP event is sent to the program by the native subscriber. The onStop block releases the resources used by the program. The native subscriber disconnects from the broker and the program instance is destroyed.
Case 3 describes the handling of an Adelia subscriber stop request by the program: When handling the message in the onMessage block, the user can ask for the Adelia subscriber to be stopped. The onStop (ON_STOP event) block is executed at the end of onStop block execution. Then the native subscriber disconnects from the broker and the program instance is destroyed.
Associated instructions
The information flow between the factory/native subscriber and the EADELIA program is handled by the different blocks and their associated instructions.
| Instruction | Description | Scope |
|---|---|---|
| BRK_GET_CONF | Gets information about the program's execution context and the Adelia subscriber description. | onStart / onStop / onError / onMessage |
| BRK_GET_MSG | Gets the payload of the message to handle as well as its properties/Gets the properties of the current error. | onError / onMessage |
| BRK_RESPONSE | Acknowledges handling/Stops the subscriber. | onStart / onMessage |
Note: these instructions can only be used in an EADELIA program (and in procedures local to the program).
Execution
As an Adelia subscriber only knows the name and package (via its description in the config/adeliaPgm object) of the program to execute, the AMBSS needs to be informed of the program generation location in its configuration.
In addition, a packaging Gradle template can be used to build a standalone AMBSS application containing all the EADELIA program binaries to execute. These binaries may be from an interactive generation or an artifact from an Adelia application area-based build or an Adelia component-based build (support for this new program type has been added). ↑ Top of page