There are various methods that can be used to establish communication between systems. In the Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions it is stated that there are 65 ways that the author has successfully documented how between systems can communicate (read: https://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html) .
This article will contain a simple implementation explanation in building communication between systems (services) using RabbitMQ where each services is created using the PHP programming language.
Once upon a time, in an company information technology ecosystem, there were 3 services consisting of payment-service, logistics-service and notification-service. These three services are able to communicate with each other in 2 ways, namely using API calls and messaging. Specifically for messaging, these three services use rabbitMQ as a message broker.
In this case study, payment-services acts as a message sender (publisher) to the other two services every time there is a verified payment by carrying payment information made by the user.
The other two services will act as consumers and payment-services as publishers and do not need to know what actions the two services will take.
On the other hand, logistics-services besides only acting as consumers when interacting with payment-services can also send messages to notification-services every time a logistics package has reached a certain checkpoint before being received by the user.
Simply put, it can be concluded that;
- payment-service acts as a publisher,
- notification-service acts as a consumer and
- logistic-service acts as a consumer as well as a publisher.
- RabbitMQ Management Image
- PHP:7.4-cli Image
- PHP Framework-X
- PHP library php-amqplib
- PHP library bunny
- PHP extension sockets & amqp
RabbitMQ will act as a message broker whenever the service needs to interact other than using an Api Call. We'll set up a few things about rabbitmq so that each service and rabbitmq can communicate properly.
The exchanger can be thought of as a message distributor to every available queue. Simply put, each service does not need to have its own "logic" for routing where messages should be sent. Each service simply communicates with this exchanger. Each service will have its own exchanger which will be used as a message distributor.
Queue is a collection of data that will be consumed directly by the consumer. Incoming data is data distributed by related exchangers. Each service that acts as a consumer must later "listen" to the queue related to the features that exist on it.
The description of the configuration that will be implemented is as follows;
All source code related to this article can be downloaded in the repository https://github.com/Mhakimamransyah/php-long-connection-messaging .
To test the communication related to the approval-payment scenario, we can hit the approval end-point available in the payment-service.
curl --location 'http://127.0.0.1:8001/api/v1/approval' \ --form 'id="12345"' \ --form 'type="VIRTUAL-ACCOUNT"' \ --form 'price="400000"' \ --form 'approved-by="system"' \ --form 'bank="BCA"'
To see if the payment information has been successfully received by the other two services, we can enter the container of each service and see the response via the logs.
To test communication via logistics-services we can hit end-point packages.
curl --location --request PUT 'http://127.0.0.1:8003/api/v1/packages' \ --form 'tracking-number="12345"' \ --form 'status="delivering"' \ --form 'checkpoint="Palembang"'
Thus my brief sharing for this tutorial. See you on another occasion.