This post describes steps you need to perform to migrate from OldSoundRabbitMqBundle (“the old sound”) to EnqueueBundle (“the enqueue”). This will be a smooth transition without breaking changes at all. Even more they can work together for some time till you are used to the enqueue.

Why should I bother at all? One may ask. In a nutshell here’s why:

I hope I have convinced you so let’s get down to business. I’ll take the examples from the official old sound documentation and show you how the same stuff works in the enqueue.

Installation

I suppose that everybody knows how to install the old sound bundle, if not here’s the guide. The enqueue bundle is easy to install too. Let’s move on.

Configuration

The old sound bundle requires a lot of manual work when it comes to configuration. You must define producers, consumers, their connections and callback services. You should also do that for every new producer or\and consumer you’ll happen to add. The enqueue needs tremendously less to configure in comparison with the old sound. You just have to configure the transport and enable the client, that’s it!

Here’s the old sound configuration example (stripped):

and here’s the enqueue equivalent:

Sending a message

In order to send a message the old sound way you ought to get a special producer service from the container. If you have 100 exchanges you’ll end up having 100 services which you must be dealing with throughout all code. If you happen to change the exchange name you have to go through all places where you are sending messages to that exchange and adjust the service name. Enqueue uses a single producer everywhere instead. By the way, there is no need to explicitly serialize the message, the enqueue takes care of it.

Message processing

The message processing looks similar: the processor receives a message, does something with it and returns the result. The old sound callback (the enqueue processor) does not require the result to be returned explicitly. If you return nothing or null it assumes everything is fine and the message could be acknowledged. The enqueue requires the result to be returned explicitly.

The old sound defines queues and exchanges in the configuration where the enqueue allows you to do that in the processor with getSubscribedCommand method. The method returns the subscription details.

The first snippet shows how to process the message in the old sound bundle consumer and the next one shows the same but the enqueue way.

You can send a message using the old sound producer and use the enqueue consumer to process it and vise versa.

Cli commands

The old sound by default runs a separate command for each queue. If you have 100 queues, you must run at least 100 consumers. Whenever you add a queue you have to update supervisord config on all production servers.

$ ./app/console rabbitmq:consumer upload_picture

The enqueue is much more flexible. You can run a single command for all available queues (good in development) or tell it to consume from the given queue(s).

$ ./app/console enqueue:consume -vvv

$ ./app/console enqueue:consume upload_picture default -vvv

The old sound bundle gives you a dedicated command to setup the broker. You have to call it every time you do changes in the configuration.

$ ./app/console rabbitmq:setup-fabric

The enqueue has a dedicated command for that as well as the ability to do it on consumption start.

$ ./app/console enqueue:setup-broker -vvv

$ ./app/console enqueue:consume --setup-broker -vvv

A little about RPCs

The old sound bundle supports RPCs but it leaves much to be desired. It has its own configuration section, own cli command and other standalone stuff. The setup process is verbose and requires quite a few steps to be done. With the enqueue you are about ready to perform remote calls. The client’s producer has a third argument called needReply just for that. If you set it true then it will return a promise which can be used to get a reply message.

The processor needs only one line change to start sending replies:

That’s what I call “real simple”.

Conclusion

The migration process is simple and completely backward compatible. The enqueue comes with so many great features that it is definitely worth it.

You can also visit our corporate blog to learn more about up-to-date IT trends and download some useful insights.