Enhancing Event Subscription: Version Tag Filtering

The Core of the Problem: Version Tags and Event Subscriptions

Version tag filtering is a crucial aspect of managing process definitions, especially when dealing with multiple versions and message correlation. Our current system uses version tags to bundle process and decision definitions, essentially creating what we refer to as a “case definition.” However, the existing system's method of handling event subscriptions can create significant challenges. Presently, the system focuses on the latest version of a process definition. When a new version is saved, the old subscriptions are removed, and new ones are created. While this approach might seem straightforward, it creates problems when dealing with different versions of the same process definition, each with its own version tag.

Imagine a scenario where you have three distinct versions of a process definition, all under different version tags. In this case, there's no way to correlate messages to the correct process definition because only the latest version’s subscriptions are stored. This limitation severely hampers the system's ability to accurately route messages to the appropriate process instances. Furthermore, if a new process definition shares the same key as an existing one but is designed for a different use case (perhaps belonging to a different case definition), it can lead to situations where process definitions become inaccessible through message correlation. This results in the case definitions being in a broken state, unable to function correctly because messages aren't correctly routed. The core issue revolves around the system's inability to differentiate between versions based on their unique version tags during event subscription management and message correlation. This restriction directly impacts the operational integrity and message handling capabilities of the system.

The challenge is compounded by the fact that the current system is not equipped to handle multiple versions of the same process definition simultaneously, each requiring its own set of event subscriptions. This inadequacy makes it difficult to maintain data integrity and message routing accuracy, which can lead to significant operational disruptions. To solve the issues, we need to consider some changes to the system. This enhancement is about improving event subscription functionality, particularly when using version tags to differentiate between process definition versions. The focus is on ensuring messages are routed to the right process instances, even when dealing with multiple versions.

The Proposed Solution: Implementing Version Tag Filtering

The proposed solution aims to enhance the system's message correlation capabilities by incorporating version tag filtering. Functionally, this means the system will be able to correlate messages based on version tags, allowing users to specify which version of a process definition should receive the message. The default behavior will remain as it is currently, correlating to the latest version. This setup ensures that new implementations do not disrupt existing functionalities. This new approach offers several key advantages, ensuring that messages are correctly routed to the appropriate process instances. The current behavior will continue to be the default, maintaining backward compatibility while adding advanced filtering.

The core of the solution is to maintain event subscriptions for older versions of a process definition, which can be configured (toggled) as needed. This approach is intended to provide greater flexibility in managing event subscriptions and process versions. From a technical perspective, the solution involves several key changes. First, it ensures that event subscriptions in act_ru_event_subscr are not deleted if a process definition already has subscriptions. This change allows the system to retain subscriptions for multiple versions of a process definition, enhancing its ability to handle different versions simultaneously. Second, a new column, version_tag_, will be added to the act_ru_event_subscr table. This column will hold the version tag of the corresponding process definition, enabling the system to differentiate between different versions. Lastly, support will be added to the message correlation builder and related classes. This support will allow the version tag to be provided as a way to filter the subscriptions. Without providing a version tag, the system will correlate the event to the latest subscription, maintaining the current behavior.

Technical Implementation: A Deeper Dive

The technical implementation of version tag filtering is multi-faceted, involving careful database schema changes, and modifications to the message correlation logic.

The first critical step is to modify the act_ru_event_subscr table. The addition of the version_tag_ column is essential for differentiating between event subscriptions for different process definition versions. This column acts as a key for version-specific message routing, ensuring that messages are directed to the correct process instance.

Next, the message correlation builder and related classes need to be updated to incorporate the version tag filtering. This will involve modifying the existing code to accept a version tag as an additional filtering criterion. This enhancement allows developers to specify which version of a process definition should receive a particular message during message correlation. The system will then use the version tag to identify the relevant event subscriptions, ensuring the message reaches the correct process instance. This new functionality will provide developers with more control over message routing and will improve the system's ability to handle multiple versions of process definitions simultaneously.

By not deleting event subscriptions upon the saving of a new process definition, the system will retain the necessary data for all active versions of the process. This guarantees that messages intended for any version can be correctly routed, avoiding any operational downtime or message loss.

Benefits and Considerations

The implementation of version tag filtering offers significant benefits to the system. It ensures that message correlation is performed accurately, regardless of the version of the process definition. This feature helps to avoid broken case definitions and significantly enhances operational efficiency. The ability to route messages to specific process instances based on version tags improves data integrity and message routing accuracy, which reduces operational disruptions. This approach provides greater flexibility in managing event subscriptions, which allows the system to handle multiple versions of process definitions.

However, it's essential to consider the implications of this feature. One important consideration is the increase in storage requirements due to retaining event subscriptions for multiple versions. The system must be carefully monitored to ensure performance is maintained, and adequate storage capacity is available. Another critical consideration is to ensure that the user interface (UI) and other related systems are updated to handle the added functionality of version tag filtering. Users will need to specify the version tag when initiating message correlation, and the UI should be designed to accommodate this requirement. Additionally, thorough testing is essential to ensure that the implementation doesn't create any compatibility issues or performance bottlenecks. All components must work seamlessly to support the new filtering capabilities. The ultimate goal is to provide a robust and flexible solution that enhances event subscription management and optimizes message correlation processes.

Additional Context and Future Steps

The decision to implement version tag filtering internally, rather than relying on an external solution, was based on a comprehensive evaluation of the potential benefits and drawbacks. Implementing a custom message correlation system could have brought many challenges, including significant deviations from the existing operational standards. This approach could risk compatibility with future versions and the overall operational integrity of the system. By integrating the feature directly into the system, the development team can maintain control over the implementation and ensure seamless integration with the existing infrastructure.

The next steps involve detailed planning, design, and implementation of the technical changes. This includes database schema modifications, code updates for the message correlation builder, and related classes. Thorough testing and validation will be conducted to ensure the new feature functions correctly and doesn’t introduce any regressions. The development team will also focus on updating the UI to allow users to specify the version tag when performing message correlation. The development will be phased in such a way that it minimizes disruption and maintains system stability throughout the rollout process. The goal is to provide a robust and efficient solution for event subscription management.

In summary, the implementation of version tag filtering is a necessary enhancement that will significantly improve the system's capabilities in managing event subscriptions and message correlation. The proposed solution provides a solid technical foundation, and the team is committed to the successful implementation of this feature.

For more information, consider exploring these resources:

• Operaton Documentation