RDP to Solace REST API
I want to cover the scenario that a queue forwards messages to another queue (on another Cluster/VPN) so:
1. I configured a RDP REST consumer for a queue (named Q-test) and filled in https://xxxxxxx.messaging.solace.cloud etc. bind it to the this queue
2. The status link is UP.
3. Tested the endpoint as well with Postman (https://xxxxxxx.messaging.solace.cloud).
4. Then I posted so messages to Q-test and expected the messages to be delivered on a queue that the RDP is posted to.
5. It works if I replace https://xxxxxxx.messaging.solace.cloud with something like requestbin (https://requestbin.com/) but on a Solace REST API endpoint it's not delivered.
6. Stats of the REST consumer shows Reason Peer TCP Closed..
What do I need to fix that it also successful can be delivered to an endpoint of another Solace queue via RDP? Any pointer for me? 
Comments
-
Hi @PimvdNoll , Some general things to check:
a) Are you able to post with to the target VPN (with cUrl / Postman) ? Make sure REST ingress is configured correctly on the target VPN and your post URL is correct.
https://docs.solace.com/Open-APIs-Protocols/Using-REST.htmb) Have you considered using VPN bridging / Dynamic message routing ?
https://docs.solace.com/Overviews/Message-VPN-Bridges-Overview.htm
https://docs.solace.com/Overviews/DMR-Overview.htm0 -
I've never thought of using RDPs and the REST interface to bridge messages between Solace brokers..!? Interesting approach.
I'm assuming you have the ports correct and everything? Is the "source" Message VPN in REST Messaging mode? (as opposed to Gateway mode)? Have you set the post-request-target on the queue binding to specify the request target? Specifically, I guess it would be the queue name on your target broker that you want to send the message into? E.g. "
QUEUE/Q-target" ?But yeah, as Ramesh said, we'd typically recommend using a VPN bridge or something to send messages from a queue on one broker to another broker.
0 -
@Aaron @PimvdNoll it is possible to set the RDP target to the Ingress REST interface of the same MessageVPN/Cloud Service. It's also possible to have your queue subscribe to the topic your RDP posts to, and create an infinite loop.
While an interesting way to stress the broker (I've used it to validate performance/behaviiur under load) it's obviously not a good idea otherwise and the risk of doing this inadvertently is another reason not to use REST to send messages between brokers. Some of the others are:
1. Bridges/DMR are easier to configure;
2. Bridges/DMR were created to do this job so it's immediately obvious what you're doing;
3. The rules for forwarding messages over bridges are easier to configure and understand;
4. DMR does the message forwarding dynamically (and is very cool);
5. Bridges/DMR offer better performance.2
