The sender channel will consume messages from the queue named ‘order’. The message sent from the publisher iFlow is a JSON message. In order to simulate failure, XML to JSON converter block is added . 

Notice the acknowledgement mode is ‘Automatic Immediate’ at Cloud Integration (Consumer).

Step 5:

Now, change the acknowledge mode to ‘Automatic on Exchange Complete’.

Now, after 4 retries, in Cloud Integration, failed status is sent back to the AEM. 

During the 5th run, we can see the local processing attempt as 5.

As we have provided, the re-delivery count as 3 in AEM, the AEM re-delivers it 3 times.

Below shows 1st re-delivery i.e, 2nd delivery from AEM (Run 5 at Cloud Integration)

3rd re-delivery from AEM (Run 5 at Cloud Integration)

Then the message is moved to DMQ (Dead Message Queue). Please note, the DMQ queue must be created beforehand. DMQs are not automatically created during message failure.

Scenario 4: Direct Message

For direct message, if we use topic, no queue or topic endpoint configuration is required at AEM. If consumer is available during publishing of message, the message will be consumed, else the message will be lost.

Step 1:

Configure Publisher iFlow.

Step 2:

Configure Consumer iFlow.

Step 3:

Test and validate.

Scenario 5: Durable topic endpoint

Step 1:

Create a topic endpoint at AEM.

Step 2:

Configure the AEM receiver adapter which acts as a publisher.

Configure the AEM sender adapter which acts as a subscriber.

Durable Topic endpoint supports a single subscription. Once a consumer is attached, the topic name gets populated.

Now, currently the topic endpoint has 2 messages queued.

Step 3:

Change the topic name at Cloud Integration side to ‘product/create’.

After changing the topic name to ‘product/create’ and deploying the consumer iFlow, all existing messages are deleted automatically without delivering it to the consumer and the recent topic name gets reflected.

Scenario 6: Use of Selector

Step 1:

Configure Publisher iFlow as below.

 Set event type, priorty and status as user properties.

Step 2:

Populate the selector field at AEM sender adapter as below.

Step 3:

Test with payload field values as below:

Check the trace of consumed message at Cloud Integration.

Now, test with payload field values as below:

The message is not consumed from the queue as the selector does not match.

Scenario 7: Send NACK to Publisher

General behavior is 

• If topic subscription does not exist for delivery mode persisted(guaranteed) or direct, no error response is sent to the publisher
• If queue does not exist for delivery mode persisted(guaranteed), error response is sent to the publisher

• If the queue does not exist for delivery mode direct, no error response is sent to the publisher.

The profile related to used client username (solace-cloud-client) is ‘default’ at AEM.

 Go to ‘default’ profile at AEM.

After ‘Reject Messages to Sender On No Subscription Match Discard’ is enabled, if no matching topic subscription is found for persistent delivery mode, an error message is returned to the publisher.

Now, if we stop the incoming calls to the queue,

we will get the error message as below.

Now, we change the property ‘Reject Messages to Sender on Discard’ on the queue to ‘Always’,

we will get the error message as below,

Scenario 8: TTL (Time to Live) 

Enable TTL feature of queue at AEM.

If the message is not consumed, the message will be moved to DMQ after 1 min. Here, no TTL specific settings are configured in the receiver channel at Cloud Integration.

If we don’t want to store it in the DMQ and discard the message after TTL, set DMQ eligible to false at publisher iFlow.

After TTL, the stats will reflect the same at AEM.

If TTL is set at receiver adapter, the minimum of the queue level TTL and the publisher level TTL takes effect.

Scenario 9: RDP (REST Delivery Point)

We have a common DMQ queue for all processes and the Rest Delivery points to Cloud Integration endpoint. Based on the endpoint, Cloud Integration forwards it for relevant processing of the DMQ messages.

Step 1:

Design the publisher iFlow as below.

User Property named ‘identifier’ is added in AEM receiver adapter.

Step 2:

Create RDP at AEM.

Create Rest Consumer with authentication type ‘OAuth2’ for Cloud Integration

Bind the AEM queue to the RDP endpoint.

On the queue bindings settings, turn on the ‘Substitution Expressions’ for ‘Request Target Evaluation’. The below substitution expression is used for target endpoint genertion. The expression ${topic(1)} represents the 1st level of the topic.

/http/redeliver/${topic(1)}/${userPropertyAsString(“identifier”)}

In case of failure at RDP, it retries forever unless we disable ‘Try Forever’ and set ‘Maximum Redelivery Count’ at DMQ.

Step 3:

The generated endpoint for order message is shown below:

The generated endpoint for business partner message is shown below:

Scenario 10: Replay Log

If replay log is enabled, the messages can be replayed from Broker without publisher intervention. To avoid saving the log for all queues, we can enable logging based on topic subscription.

For example, the consumer ‘Cloud Integration’ forwards message to a target but the target system is down. All the messages from that point need to be replayed. For that, we need a start pointer and ‘ReplicationGroupMessageId’ can be used. As a pre-requisite, replication group message id for each message should be logged as a custom header at Cloud Integration.

Now, replay all the messages after the above replication group message id. Please note that selective replay of messages or providing an end replication group message id is not possible. Therefore, idempotency must be implemented on the target side to avoid processing duplicate messages.

Messages after Replication Group Message ID will be replayed.

Similarly, we can create a new queue and attach it to a new consumer and replay the previous log related to its topic subscription from the beginning or from a particular date and time or based on replication group message id.

Scenario 11: Parallel Consumers

No. of consumers = (no. of worker node) * (no. of parallel consumer).

If the tenant has 2 worker nodes and 1 parallel consumer, the consumer attached the queue will show up as below:

If we increase the parallel consumer to 5,

the consumer count becomes 10.

Only 1 consumer is active, the remaining 9 consumers are in inactive state. This is because the queue type is ‘Exclusive’.

Now, if we change the queue type to ‘Non-Exclusive’,

 all the consumers are active. 

E.g., if we want a particular object id (say Business Partner) to be processed by the same consumer, we can utilize the partition concept.

Set the partition count as 5.

Set the parallel consumers as 3

As the tenant has 2 worker nodes, the total no. of consumer will show up as 6. Only 1 consumer is inactive. Remaining consumers are in active state as the number of partition count is 5.

If we set ‘JMSXGroupID’ value, it will be used as a partition key. 

For example, for BP number ‘10001234’, the message was consumed by Flow ID 248 and for BP number ‘10001236’, it was consumed by Flow ID 281.

All the updates related to BP ‘10001236’, are lined up for the same consumer.

Scenario 12: Request Reply Pattern

The publisher iFlow is designed as below:

Configure the AEM receiver channel as below. 

This will create a non-durable queue at AEM when the message is sent from publisher iFlow.

Consumer iFlow receives the headers populated from Publisher iFlow related to response propagation, such as ReplyToDestination, ReplyToEndpointType and CorrelationId

Design Consumer iFlow as below

Please note: The delay is used here only to simulate processing time instead of adding additional pallets. 

AEM receiver adapter is used to send back the response.

After ‘request-reply’ step in the publisher iFlow message trace, we will see the response headers.

Lets test the publisher iFlow.

As we can see, the response message is received.

Thank you for reading this blog post.