Given:
An XML test case calling a template with a send message action.
When:
Utilizing this template across various XML tests.
Then:
The sent messages should exhibit unique message IDs.
The rationale behind this expectation is crucial. The message ID assigned to each sent message serves as a means to correlate it with the corresponding received message, facilitated by the correlation manager. In scenarios where tests execute concurrently and messages share identical IDs, inbound messages might erroneously correlate with incorrect outgoing messages, potentially leading to test failures.
Actual Behavior
Currently, messages sent from templates consistently possess identical message IDs. This behavior stems from the HttpSendRequestActionParser, which generates a BeanDefinition featuring a fixed HttpMessage. Despite the builder consistently crafting new SendMessageAction instances, the message creation relies on the original HttpMessage residing within the BeanDefinition. Consequently, the IDs of messages generated from the SendMessageAction consistently match, leading to the observed behavior.
Citrus Version 4.x
Expected behavior
Given: An XML test case calling a template with a send message action.
When: Utilizing this template across various XML tests.
Then: The sent messages should exhibit unique message IDs.
The rationale behind this expectation is crucial. The message ID assigned to each sent message serves as a means to correlate it with the corresponding received message, facilitated by the correlation manager. In scenarios where tests execute concurrently and messages share identical IDs, inbound messages might erroneously correlate with incorrect outgoing messages, potentially leading to test failures.
Actual Behavior Currently, messages sent from templates consistently possess identical message IDs. This behavior stems from the HttpSendRequestActionParser, which generates a BeanDefinition featuring a fixed HttpMessage. Despite the builder consistently crafting new SendMessageAction instances, the message creation relies on the original HttpMessage residing within the BeanDefinition. Consequently, the IDs of messages generated from the SendMessageAction consistently match, leading to the observed behavior.