Generic Message Buffering

Generic Message Buffering | Camunda 7

Imagine multiple messages waiting in a message catch event.  

When a single throw event is triggered, the data is processed without any issues. However, if multiple message events are thrown simultaneously, only the first one is successfully processed, while the others fail.  

This is because the message catch event is busy handling the first message event. 

We recently spotted this issue with Camunda 7’s message catch event. 

Unlocking The Solution To This Challenge 

Our team of experts fabricated a groundbreaking “Generic Message Buffering” logic, with which we’ve revolutionised the way messages are processed asynchronously, effectively resolving any scenario you may encounter.   

Fig. 1.1 unveils the powerful list of message catch events eagerly awaiting the trigger. 

 

Fig1.1

 In Figure 2.1, we present the logic for Generic Message Buffering. By sending a POST request, we can activate the BPM process described below. Additionally, we have the ability to specify the retry count and retry delay as request parameters. Once the request is triggered, we conduct a basic validation to ensure all necessary information, such as message name, payload, process instance id, and business key, is present.  

If all the required data is available, we proceed to send the message to its destination within the “Message Send Task” depicted in Figure 2.1.  

If the message is successfully picked up and processed by the message catch event, we encounter no issues.  

Fig2.1

In a situation where the message catch event is already occupied processing another message, throwing our own message will result in failure. This is a common occurrence in real-time scenarios, and it is up to the developers to determine how the flow should be handled in such cases. 

In our specific case, the failed message will be caught by the boundary event. The error message will then be examined in detail within the “Read Error Message” process (Fig 2.1). 

In the event of an error, we can:  

  • Distinguish between errors that require retry logic.  
  • Determine if it is a business error or a technical error.  
  • Necessitate the involvement of technical experts, if it happens to be a business error 

When encountering a retriable error, we make an attempt to retry the operation. The number of retries and the delay between retries is determined by the input request. 

Potential Scenarios In Re-try

In the context of re-try logic, there are two potential scenarios to consider: 

  • In one of the re-try attempts, the message can be successfully delivered to the end system. 

Fig 3.1

  • Alternatively, if the maximum number of re-try attempts is reached without success, the message will be marked as an error. 

 If the maximum re-try attempts have been exceeded and the message still hasn’t been delivered successfully, it will require manual re-processing (see Fig 3.2). 

Fig 3.2

 

 

  Key Advantages  

  • Streamlined Error Handling: By effectively managing busy message catch events, we can significantly mitigate potential errors during data processing. 
  • Efficient Data Re-processing: Our approach allows for a substantial reduction in the amount of data that needs to undergo re-processing. 
  • Versatile Solution: Utilizing the same bpmn models, we can easily adapt and apply them to various similar use cases simply by modifying the message name. 

 Optimizing Efficiency 

 In order to optimize efficiency, it is vital that both the target BPM and the message buffering BPM are connected to a centralized database. This will allow for seamless integration and streamlined performance. Maintaining a unified database instance is key to achieving optimal results. 

 

Picture of Janani Priya. Text: Janani Priya, Trainee Analyst

We Are Sandhata – Meet Janani

We talk to Janani Priya who recently joined Sandhata as a graduate. She shares how she managed joining Sandhata during COVID, and her experiences so far.

 

Tell us a bit about yourself

Hello, my name is Janani. I am from Chennai, India. In September 2020 I graduated from Dr. MGR Educational and Research Institute University with a degree in Engineering BTech (Information Technology). I really enjoyed my studies and am very proud to have secured the 2nd highest marks in my year.

During my course, I studied SQL, Java, Web Development and also achieved Prelims Level in “BEC – Business English Certificate”.

 

Read More

Do you want to achieve quick wins? (Hint: Focus on Minimum Viable Product)

DevOps is all about fast and frequent deployments, measuring value and continual improvement. I’m sure you have heard about reducing batch sizes in order to decrease lead time, increase deployment frequency and improve stability and quality. Well, focusing on the minimum viable product is one way to reduce batch sizes and enable more frequent deployments.

 

What is meant by Minimum Viable Product (MVP)?

A product which is delivered with just enough features/capabilities to satisfy a subset of users and validate a business use case. Once the product is released, the subset of users will provide feedback which will drive the direction and delivery of subsequent features (or halt development if the product does not appear to have viable business value). Products generally follow an iterative deployment model, and the product evolves through multiple deployments before the product is seen as ‘complete’.

 

Read More
DevOps innovation tools

How we built a Live DevOps Innovation Platform

We recently announced the arrival of our Live DevOps Innovation Platform built in-house here at Sandhata. I wanted to share some of the tools we have used for it so far, as well as my personal experiences on this platform, as it has been very interesting and a big learning experience for me.

Read More
From College to Career

From College to Career

Choices shape and define us. Past choices mould us into who we are today and the ones we make today shape who we become tomorrow. In this blog post, I will share a brief story of how my career choices have helped shape me into who I am today. After all, aren’t we are all ultimately responsible for our own actions?

Read More
Testing Automation and tools

Testing from a developer’s perspective

Having worked in the development side of projects for so long, donning a tester’s hat for some projects at my current workplace was a new experience, nevertheless a useful one. It was almost like starting from scratch. I always had this idea that testing was largely a manual process. Yes, I knew there was automation testing and I was aware of tools such as HPQC, QTP and so on. But, having never used them before, I was not sure how they were leveraged to test the multitude of requirements. So, here go a few of my observations when performing a tester role.

Read More
BIRT reporting

BIRT for Test Reports

Results reporting is one of the key stages in the testing phase where the interested project participants or the stakeholders are presented with information on the test progress. Although many of the test automation tools have inbuilt reporting capability, the information may either be too low-level or technical, or it may not be fully relevant for management. As part of test process improvement, I’m working on a requirement to present the test results in an efficient way, so the management can visualise the current status of testing or the overall status for a test cycle, and make decisions accordingly.

Read More
IBM integration bus IIB

IBM Integration Bus – A Developer’s Perspective

Having worked with some of the popular EAI tools like TIBCO BW, Vitria Businessware and SAP PI, it’s time for me now to familiarize myself with something from the IBM product catalogue as well. IIB – IBM Integration Bus. It is the next product offering from IBM in the ESB range; an extension to Websphere Message Broker and Websphere ESB. Going forward, users of Websphere ESB and Message Broker, would have to migrate to IIB. So, here’s few of my initial thoughts when working with IIB.

Read More