Enrich clone parameter

What Does the clone parameter in the Enrich mediator mean?

In the context of the WSO2 Micro Integrator (MI) <enrich> mediator:

<enrich>
    <source clone="false" type="body"/>
    <target property="ORIGINAL-PAYLOAD" type="property"/>
</enrich>

clone="false" → Ensures the payload is referenced directly instead of creating a deep copy (duplication) of the message.

Why Does This Matter?

In WSO2 MI, the message context (including the payload) is stored in memory as an OM (Object Model) structure, which is part of the AXIOM (AXis Object Model) framework.

• clone="false" → References the existing payload without copying data in memory.
• clone="true" → Creates a new copy of the payload (uses additional memory and CPU cycles).

Example to Illustrate the Difference

Payload Before Enrich Mediator

Incoming XML payload:

<order>

    <id>12345</id>

    <amount>100</amount>

</order>

Enrich Mediator with clone="false" (Recommended for Performance)

<enrich>

    <source clone="false" type="body"/>

    <target property="ORIGINAL-PAYLOAD" type="property"/>

</enrich>

Result:

• No new copy is created.
• The ORIGINAL-PAYLOAD property points to the same memory reference as the original payload.
• If the payload is modified later, the ORIGINAL-PAYLOAD will reflect those changes.

Fastest method when you only need to reference the payload.

Enrich Mediator with clone="true" (Data Duplication)

<enrich>

    <source clone="true" type="body"/>

    <target property="ORIGINAL-PAYLOAD" type="property"/>

</enrich>

Result:

• A new copy of the payload is created in memory.
• Changes made to the original payload later will not affect the copy stored in ORIGINAL-PAYLOAD.

Safer if you need to preserve the original state of the payload before modifying it.
Slower because it consumes more memory and CPU.

When to Use Each Option?

Use Case	Recommended Option
Log the payload without modifying it	clone="false"
Backup the payload before modifying it	clone="true"
Capture large payloads in performance-critical flows	clone="false"
Ensure payload integrity for error handling	clone="true"

Example Flow Using Both Options

Scenario: Capture the original payload for logging and modify the message later.

<sequence xmlns="http://ws.apache.org/ns/synapse" name="ExampleSequence">

    <!-- Capture Original Payload for Logging (Best Performance) -->

    <enrich>

        <source clone="false" type="body"/>

        <target property="ORIGINAL-PAYLOAD" type="property"/>

    </enrich>

    <!-- Log Original Payload -->

    <log level="custom">

        <property name="Original Payload" expression="get-property('ORIGINAL-PAYLOAD')"/>

    </log>

    <!-- Modify the Payload -->

    <payloadFactory media-type="xml">

        <format>

            <response>

                <status>Success</status>

                <originalAmount>$1</originalAmount>

            </response>

        </format>

        <args>

            <arg evaluator="xml" expression="//order/amount"/>

        </args>

    </payloadFactory>

    <!-- Log Modified Payload -->

    <log level="custom">

        <property name="Modified Payload" expression="get-property('body')"/>

    </log>

</sequence>

Expected Logs:

[Original Payload] 

<order>

    <id>12345</id>

    <amount>100</amount>

</order>

[Modified Payload] 

<response>

    <status>Success</status>

    <originalAmount>100</originalAmount>

</response>

After <payloadFactory> Modification:
Since clone="false" was used earlier, ORIGINAL-PAYLOAD is updated as well.
Value of ORIGINAL-PAYLOAD (and the modified payload):

<response>

    <status>Success</status>

    <originalAmount>100</originalAmount>

</response>

Key Takeaways

• clone="false" — Best for performance; avoids unnecessary memory duplication but reflects changes made to the original payload.
• clone="true" — Creates a deep copy of the payload, ideal for protecting the original data from modifications.

For performance-critical scenarios or large payloads, clone="false" is generally preferred.

How does AMQP protocol work?

1.- How Does the AMQP Protocol Work?

2.- Key Concepts of AMQP

3.- AMQP Workflow (Step-by-Step)

4.- Message Flow in AMQP (Visual Flow)

5.- Core AMQP Features

6.- AMQP Example Architecture in Node.js

7.- Best Practices for Using AMQP

1.- How Does the AMQP Protocol Work?

The AMQP (Advanced Message Queuing Protocol) is an open standard protocol for messaging systems designed for reliable, flexible, and secure communication between distributed systems. RabbitMQ uses AMQP 0-9-1, a widely adopted version, particularly in Node.js environments using libraries like amqplib.

2.- Key Concepts of AMQP.

AMQP introduces several fundamental components to structure messaging effectively:

1. Connection

• A TCP/IP socket connection is established between a client (like a Node.js application) and the RabbitMQ broker.
• AMQP uses port 5672 (default) for non-TLS and port 5671 for TLS.

2. Channel

• A virtual connection within a TCP connection that minimizes resource consumption.
• Multiple channels can exist over a single TCP connection to handle concurrent tasks.

3. Exchange

• An exchange receives messages from producers and routes them to queues based on routing rules and binding keys.

• Types of exchanges include:
• Direct — Routes messages based on exact routing key matches.

• Topic — Uses wildcard patterns for flexible routing.

• Fanout — Broadcast messages are sent to all bound queues.

• Headers — Uses message headers instead of routing keys.

4. Queue

• A storage area for messages until they are consumed by consumers.
• Queues are durable (survive broker restarts) or transient (lost if the broker restarts).

5. Binding

• Binding creates a link between an exchange and a queue, specifying a routing key to determine which messages should be routed to the queue.

6. Message

• A packet of data that includes:
• Payload (the actual data)
• Properties (metadata like content type, priority, etc.)
• Headers (additional metadata for routing logic)

3.- AMQP Workflow (Step-by-Step)

Here’s how the AMQP protocol operates in practice:

Step 1: Establish a Connection

• The client opens a TCP connection to the RabbitMQ broker.
• The broker authenticates the client (e.g., via username and password).

Example in Node.js (using amqplib):

javascript
const amqp = require('amqplib');

async function connect() {
    const connection = await amqp.connect('amqp://localhost');
    console.log('Connected to RabbitMQ!');
    return connection;
}
connect().catch(console.error);

Step 2: Open a Channel

• Channels are created within the established connection to handle individual messaging workflows.

javascript
async function createChannel(connection) {
    const channel = await connection.createChannel();
    console.log('Channel created!');
    return channel;
}

Step 3: Declare an Exchange

• Producers publish messages in an exchange rather than directly in a queue.
• Exchanges determine how messages are routed.

javascript
await channel.assertExchange('logs', 'direct', { durable: true });

Step 4: Declare a Queue

• Queues are declared on the broker and can be durable or transient.

javascript
await channel.assertQueue('error_queue', { durable: true });

Step 5: Bind Queue to Exchange

• The queue must be bound to the exchange with a specific routing key.

javascript
await channel.bindQueue('error_queue', 'logs', 'error');

Step 6: Publish a Message

• Messages are published to the exchange with a routing key.

javascript
channel.publish('logs', 'error', Buffer.from('Critical system failure!'));
console.log('Message published!');

Step 7: Consume Messages

• Consumers subscribe to queues and process incoming messages.

javascript
await channel.consume('error_queue', (msg) => {
    console.log(`Received message: ${msg.content.toString()}`);
    channel.ack(msg);  // Acknowledge message to remove it from the queue
});

4.- Message Flow in AMQP (Visual Flow)
rust
Producer -> Exchange -> [Binding] -> Queue -> Consumer
Example with Routing Key:
scss
Producer -> Exchange (Direct) --(error)--> Queue (Error Logs) -> Consumer
5.- Core AMQP Features
Reliable Messaging
Ensures message delivery through acknowledgments, retries, and dead-letter queues.
Flexible Routing
Using direct, topic, fanout, and headers exchanges for dynamic message distribution.
Message Acknowledgments
AMQP supports:
Auto-acknowledgment — Messages are auto-removed once delivered.
Manual acknowledgment — Messages are removed only after explicit confirmation.
Durability
Messages can be persistent, ensuring they survive broker restarts.
Flow Control
The prefetch count feature limits the number of unacknowledged messages per 
consumer for better throughput control.
6.- AMQP Example Architecture in Node.js
Imagine a system that logs application events:
Exchange: app_logs
Queues:
error_logs (Binding Key: error)
info_logs (Binding Key: info)
Routing Logic:
Messages tagged error route to error_logs
Messages tagged info route to info_logs
Producer Code
javascript
const amqp = require('amqplib');

async function sendLog(type, message) {
    const connection = await amqp.connect('amqp://localhost');
    const channel = await connection.createChannel();
    const exchange = 'app_logs';

    await channel.assertExchange(exchange, 'direct', { durable: true });
    channel.publish(exchange, type, Buffer.from(message));

    console.log(`[x] Sent '${type}': ${message}`);
    await channel.close();
    await connection.close();
}

sendLog('error', 'Critical server error!');
sendLog('info', 'Server started successfully.');
Consumer Code (for error_logs)
javascript
async function receiveLogs() {
    const connection = await amqp.connect('amqp://localhost');
    const channel = await connection.createChannel();
    const exchange = 'app_logs';
    const queueName = 'error_logs';

    await channel.assertExchange(exchange, 'direct', { durable: true });
    const q = await channel.assertQueue(queueName, { durable: true });

    await channel.bindQueue(q.queue, exchange, 'error');

    channel.consume(q.queue, (msg) => {
        console.log(`[!] Error Log: ${msg.content.toString()}`);
        channel.ack(msg);
    });
}

receiveLogs();
7.- Best Practices for Using AMQP
Use durable exchanges and queues for persistent messages.
Apply routing key patterns to improve message filtering.
Use manual acknowledgments in critical processing pipelines to ensure message reliability.
Implement Dead Letter Exchanges (DLX) for unprocessable messages.
Use prefetch limits to control message flow and avoid consumer overload.