Defining an Existing Exchange, a Queue name, and a wild card routing key on the Exchange

[pregenie]

We have an existing fully managed RabbitMQ implementation and would love to use micro services to update postgresql with data from new application exchanges. What would be great would be to define an existing exchange, a queue name, and a wild card routing key on the exchange. Something like the following so that the queue name can be specified and unique and the routing key is a wild card:

#!/usr/bin/env node
'use strict';

const path = require('path');


require('seneca')()
  .use('seneca-amqp-transport',{
    "amqp": {
      "type": "amqp",
      "url": "amqp://messaging.zanthion.com",
      "exchange": {
        "type": "topic",
        "name": "HH-Data",
        "options": {
          "durable": false
        }
      }
    }
  })
  .add('sensor_data_update:177, *', function(message, done) {
    return done(null, {
      id:
        Math.floor(Math.random() * (message.max - message.min + 1)) +
        message.min,
      message: `Hello ${message.name}!`,
      from: {
        pid: process.pid,
        file: path.relative(process.cwd(), __filename)
      },
      now: Date.now()
    });
  })
  .listen({
    type: 'amqp',
    pin: 'sensor_data_update:177, *',
    url: process.env.AMQP_URL
  });

A crazy shot in the dark hoping for an easy implementation. Thank you for your work. It is really awesome.

Trying to get this:

queue name: seneca.sensor_data_update:177
durable: true
binding from: HH-Data
routing key: *

Phil

[nfantone]

@pregenie Hi and thanks for writing that up!

Declaring exchanges and queues in AMQP (or re-declaring, in your case) is an idempotent action; meaning declaration of the same elements multiple times have no side-effects (as long as they define the exact same options). So using your existing topology should be supported.

What's the problem you're having, exactly?