0

I’m trying to make a AMQP integration layer for my app. This layer would only consume messages from my customer’s queues and the result would be a specific action in my application. My application is a type of CRM. It manages recipients and it can send emails to these recipients. What I would like my customers to be able to do is the following:

  1. Through my application admin panel, a user would be able to input their AMQP connection information (host, port, username, etc.)

  2. Once they have setup a connection, they would be able to add queues to this connection.

  3. To add a queue, they would input the queue name and choose the desired action on the application. Example of these would be “Create a contact” or “Send X email”.

  4. The application would then attempt to connect to the queue and grab a single message.

  5. Upon successfully grabbing a message, it would map out the message fields and the user would be able to map these against the application data field.

  6. Then they would choose the synchronisation setting. This would be either live data or pre configured setting such have “Every 5/10/15/30minutes”

This process would basically create a consumer for the customer’s queue that would feed my application with data. The possible callback for the consumers would be the different available ‘Actions’ the user can choose at step 3.

The necessary information would be stored in a database for my application to use whenever it needs to consume a message.

Does this sound right and / or do you see any issue with the above?

My main concern would be how to handle all the consumers this can potentially create? In the past, whenever I had to integrate a customer’s queue I would make a microservice that would consume a single queue and have the appropriate callback function. That is pretty straight forward but it would have been hard to maintain in the future as I add more queues and other customers since it clearly goes against the DRY principle.

Would it be best to handle this as a plugin or is it plausible to handle all these consumers within a single app?

Improve this question
2
  • I may be misunderstanding, but from the way you describe what you're trying to do it sounds rather like you're exposing the underlying implementation/architecture of your software to the user. If a user's requirement is to send an e-mail to a customer, then surely that's all their UI should be concerned with and not AMQP or queues. While AMQP may be part of the underlying implementation, a user usually wants a simple, intuitive UI/UX and workflow which makes their life easier without the technical detail.
    – Ben Cottrell
    Feb 15, 2019 at 20:06
  • This process is actually just another way to synchronize data for my clients who already implement AQMP queues on their end. Instead of having them do everything through our API, I'd like to offer them the possibility to consume their queue. There's already an intuitive UI in place to handle recipient imports through csv/excel files and a drag and drop UI to build and send emails :)
    – Jean-Francois Paquin
    Feb 16, 2019 at 22:19

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.