Solace .NET API

Poornima

Hi,
I am able to connect Solace through Solace API from C# and I have a query whenever I consume messages it reads one message at a time. If we have more than 1000 messages at a time do we have any properties to set how many messages to consume at a time? or we need to loop to the count of messages in the queue.?

Could anyone share your ideas please?

TomF

Hi @Poornima, remember this is an asynchronous API. Messages are sent as soon as they can be. If you have 1000 messages on the queue, we will send you 1000 messages (subject to some window concerns that I won't talk about now.) Now, each message will result in a separate call to the receive delegate. If you wish to process a batch of the messages, simply take the individual messages from the delegate and create a batch structure to hold the batch.

Poornima

Thank you TomF. Its working as you said. I was having single message in queue so i digged in detail and found out as per your suggestion.

TomF

Glad to hear it @Poornima !

Poornima

@TomF one more query? I have created another discussion. Let me clarified from you.

I need some guidance and help regarding acknowledgement process of Solace.
1.I have Boomi process which gets input (payload) from external system and sending xml to Solace topic.Here how to acknowledge the source system the message is received in Solace in success. What settings are to be done in Solace Pubsub + connector (Boomi)
2. Another part . Boomi process reads from queue and sends to destination. in case of success destination gets data but in case of failure how can i notify Solace queue this message is failed in destination so it can be retained in queue or dead letter queue.

Can any one please guide /suggest your ideas/thoughts.

TomF

@swenhelge can you help with this Boomi question?

Poornima

@TomF - @cmorneau helped me regarding this question and got it worked . thank you for wonderful support. I got another question though - any one can guide me please .
I want to test the scenarios of - how can I forcefully push messages to dead letter queues. Any properties to be set in Boomi or Solace.?

TomF

@Poornima , well, you can always send the message directly to the DMQ by sending it to the DMQ name directly. Is this so you can test your DMQ logic?

Poornima

thank you @TomF .But I want to forcefully send message to DLQ not publishing message to queue directly.

TomF

@Poornima a DLQ is just a queue that is named as the DLQ for another queue. So, imagine you have:
Queue A_Queue with setting DMQ = DLQ
Queue DLQ.
So if you want to send something directly to A_Queue's DLQ, simply send the message directly to DLQ instead of A_Queue.

TomF

Ah, a quick thought. It may be that you are sending a message to a topic that A_Queue subscribes to: I hope so, as this is definitely our best practice. For a specific test, it's fine to send to a queue (in this case DLQ).

Poornima

I will try this out and one more thing @cmorneau suggested enabling Creating queue and Topic subscriptions in Listen Operation in Solace Pubsub connector but receiving as access type mismatch error in connector. Do you have idea what access is required for this fixing this error

swenhelge

Hi,
Our boomi connector supports different message delivery and transaction (ack) modes.

Here's the high level documentation - https://help.boomi.com/bundle/connectors/page/int-Solace_PubSub_operation.html

It sounds like you are working on a per-document/record basis - and you want to make sure messages are acknowledged by the broker (the first case) or messages received in a process are not acknowledged unless the process completes.

In the first case you use the "send" operation and you should set the operation "Mode" to "Persistent Non-Transacted". This makes sure your message is acknowledged by the broker on a per document basis (if you are batching and you want the full batch to fail if one message fails to be sent use "Persistent Transacted").

In the second case you use the "Listen" operation. You only want the message receipt to be acknowledged once the boomi process completes successfully. Again you need to use a "persistent" mode so an acknowledgement process with the broker is executed. You then set the "Mode" of the operation to "Persistent Transacted" - this will make sure you consume from an endpoint on the broker and that the message is only acknowledge once the process succeeds.

Poornima

Yes @swenhelge I followed the same way as per documentation. Only issues I am facing here is I enabled checkbox 'Create Queue and Subscriptions' in Listen operation - after that I get error in Boomi Listner -access type mismatch. And also for DLQ I am looking for if any other properties are to be set and what values need to be for retries as well.
I was having error in my process before reaching destination so the message stays in queue - how many retries will happen in order for message to go DLQ and which properties to be configured for that.

swenhelge

@Poornima said:
Yes @swenhelge I followed the same way as per documentation. Only issues I am facing here is I enabled checkbox 'Create Queue and Subscriptions' in Listen operation - after that I get error in Boomi Listner -access type mismatch.

Access type mismatch has been reported before - the user was able to resolve the problem: https://solace.community/discussion/460/boomi-solace-listener-com-solacesystems-jcsmp-propertymismatchexception-access-type-mismatch
I'll dig a bit deeper later this week.

And also for DLQ I am looking for if any other properties are to be set and what values need to be for retries as well.
I was having error in my process before reaching destination so the message stays in queue - how many retries will happen in order for message to go DLQ and which properties to be configured for that.

These are setting on the queue that you do not have control over when creating queues automatically. Defaults will be used for this (the documentation currently doesn't list the defaults, I'll add an enhancement request for it). You can change the retry, DMQ behaviour, default TTL of messages etc via the Solace PS+ admin UI (or any of the other admin tools/protocols in case you are automating broker configuration)