Addressing UI Data Errors and Enhancing Message Queue Testing

Monday, September 9, 2024 – Last week, while continuing to test the new button functionality, I encountered an error during the data cleanup process. The issue arose because the cleanup only read data from a single table, while the UI page displayed a combination of data from Table A and Table B. After identifying the problem, I created a new UI page to ensure the cleanup query also retrieves data from Table B, preventing discrepancies.

In addition to resolving the UI data issue, I needed to ensure the data cleanup logic was accurate and effective. Initially, the cleanup process was set up to automatically convert any null or zero values to zero. However, this approach did not fully address all potential data scenarios. After discussing the requirements with Mr. Peter, he provided insights into the different scenarios and the best approach for handling data cleanup, which refined my solution.

Next, I focused on the message queue implementation. I was tasked with creating a controller test to verify that the publish message functionality was correctly utilized. Although it took some time to understand the testing process for the message queue, Mr. Peter’s guidance helped me successfully create and execute the test. I then shifted my attention back to the consumer side, working on handling the execution after a message is received. I sought Mr. Peter’s advice to ensure the implementation was correct, and while there are still some adjustments and testing needed, I plan to continue with this next week.

Message Queue Publication and Data Cleanup Task

Monday, September 2, 2024 – Last week, I discovered that the issue with not receiving messages was due to a failure in publishing them correctly. I identified and corrected the problem, particularly focusing on the message format in the publish function. After several adjustments, the message was successfully queued in RabbitMQ. I verified this by checking the RabbitMQ management UI, where I confirmed that the message had been published successfully. With the publishing issue resolved, I turned my attention back to the consumer side and made necessary fixes to ensure that messages are read correctly.

In addition, I was assigned a new task to clean up existing data, which had some inaccuracies in previous calculations. The cleanup process involves resetting the data and updating it with the correct values. I started by creating an API query in context A to retrieve the latest invoice and its corresponding data price. This latest data price is then used in a query from context B to update the data in context B.

Once both queries were completed, I moved on to the UI updates. I utilized an existing cleanup page to incorporate a new button feature, given its similar functionality to the current cleanup process. By the end of the week, most of the new button functionality was implemented, although I haven’t fully tested it yet. Testing will be a priority for next week.

Encapsulating and Implementing Message Queue Methods

Monday, August 26, 2024 – Last week, I continued my exploration and implementation of RabbitMQ message queues. Following Mr. Peter’s advice, I focused on encapsulating methods to be used by multiple components, a best practice that helps reduce duplication and simplifies error detection. It took several attempts to perfect the encapsulation for both the publisher and consumer before I could move on to actually using them to publish messages.

When setting up message publication, I faced a few challenges. I had to consider the type of messaging pattern: whether the message queue would be from a single publisher to a single consumer, or from a publisher to multiple consumers. For scenarios involving multiple consumers, the publisher needs to implement an ‘exchange’. An exchange in RabbitMQ is a routing mechanism that decides how messages should be distributed to queues based on routing rules. It essentially determines where messages should go. There are different types of exchanges, such as direct, fanout, topic, and headers, each with its own routing logic.

Next, I turned my attention to implementing the consumer side. One tricky part was figuring out how to call the Consume method effectively and ensure it returned the published message for further processing. To handle message consumption, I used a background service provided by Microsoft. After setting up both the consume and publish methods, I checked the RabbitMQ management UI and confirmed that the published messages appeared in the queue. However, the messages were not being consumed as expected. After revising the consumer setup, I consulted Mr. Peter and discovered that the issue was with the publisher failing to send the message properly. I’ll be tackling this issue in the coming week.