Skip to main content Skip to footer

Best Practice

Messages Filters

Each module has a message filter that can be used for filtering of message based on their properties.

The default behavior for modules in Crosser Flows is to process every message they receive. Sometimes this is not desirable, this is where message filters come into play. Message filters are added on the ‘Common’ tab (soon ‘General’), available in the settings dialog of all modules. You can add multiple filters and in this case a message must pass all criterias (AND).

The first use case is to block messages with invalid data, so that they don’t continue along the Flow and create issues in other modules. The output of each module contains a ‘crosser’ object that has a ‘success’ property that can be used in message filters to check that the data received from a previous module is generated by that module without issues. That doesn’t necessarily mean that the actual content of the message is without issues, but at least you know that the previous module operated without issues. This is especially useful with modules that make external requests to get data, like database queries, HTTP requests or pulling data from a PLC. If these modules report a failure it is very unlikely that the output will contain valid data, hence it makes sense to block these messages in the next module.

Another scenario is when you want to apply different processing based on message data. Connecting multiple modules to the output of one module and configuring them with different filters allows messages to be routed along different paths. This type of routing can also be achieved with the Split module, that offers the same kind of filter conditions, but with the advantage that it’s more visually apparent what is happening.

About the author

Goran Appelquist (Ph.D) | CTO

Göran has 20 years experience in leading technology teams. He’s the lead architect of our end-to-end solution and is extremely focused in securing the lowest possible Total Cost of Ownership for our customers.

"Hidden Lifecycle (employee) cost can account for 5-10 times the purchase price of software. Our goal is to offer a solution that automates and removes most of the tasks that is costly over the lifecycle.

My career started in the academic world where I got a PhD in physics by researching large scale data acquisition systems for physics experiments, such as the LHC at CERN. After leaving academia I have been working in several tech startups in different management positions over the last 20 years.

In most of these positions I have stood with one foot in the R&D team and another in the product/business teams. My passion is learning new technologies, use it to develop innovative products and explain the solutions to end users, technical or non-technical."

Close