Of the data that you are testing what parts are static vs variable in nature. e.g. is IND static thus have something like /IND[A-Z|0-9].*/

Alternatively offload the test to a java service that returns a boolean then branch on that

Hi Jerome,

Thanks for your response.

Yes the data is like :   IND001A , IND211D, IND417B and so on.

So Java Service is an option here.

But my attempt to use Variable Substitution in BRANCH will not work out is what you suggest.

Thanks, 

Of the data that you are testing what parts are static vs variable in nature. e.g. is IND static thus have something like /IND[A-Z|0-9].*/

Alternatively offload the test to a java service that returns a boolean then branch on that

So in terms of a test we are saying if the value starts with IND and has numbers and or uppercase characters then go to this branch else go to default branch.

If this statement is true then the regex is shared, /IND[A-Z|0-9].*/ will match any of the values you shared. What other permutations would you have on the expression?

But no, you cannot set the regex in a variable and try to substitute it in. Ideally best to avoid that as

1. your code is more readable and supportable where you can see the expression directly
2. should be more efficient than building a java service as you have one less invoke to perform

Hi Jerome,

Thanks for your response.

Yes the data is like :   IND001A , IND211D, IND417B and so on.

So Java Service is an option here.

But my attempt to use Variable Substitution in BRANCH will not work out is what you suggest.

Thanks, 

Of the data that you are testing what parts are static vs variable in nature. e.g. is IND static thus have something like /IND[A-Z|0-9].*/

Alternatively offload the test to a java service that returns a boolean then branch on that

Thanks @Jerome Green for your insights on this.

Your suggestion of /IND[A-Z|0-9].*/ was great.

But I see that the current code is like 

BRANCH on /messageType

     /DU001A|DU211D|DU417B|DU611A|DU031C/   : MAP  ( Do some logic )

    /DU901A|DU731D|DU555B|DU312A|DU030C/   : MAP  ( Do some logic )

    $default : MAP ( do some logic)

So say if I use the Regex /DU[A-Z|0-9].*/  then it will always match the first MAP under the BRANCH

BRANCH on /messageType

     /DU[A-Z|0-9].*/   : MAP  ( Do some logic )

    /DU901A|DU731D|DU555B|DU312A|DU030C/   : MAP  ( Do some logic )

    $default : MAP ( do some logic)

Thanks

So in terms of a test we are saying if the value starts with IND and has numbers and or uppercase characters then go to this branch else go to default branch.

If this statement is true then the regex is shared, /IND[A-Z|0-9].*/ will match any of the values you shared. What other permutations would you have on the expression?

But no, you cannot set the regex in a variable and try to substitute it in. Ideally best to avoid that as

1. your code is more readable and supportable where you can see the expression directly
2. should be more efficient than building a java service as you have one less invoke to perform

Hi Jerome,

Thanks for your response.

Yes the data is like :   IND001A , IND211D, IND417B and so on.

So Java Service is an option here.

But my attempt to use Variable Substitution in BRANCH will not work out is what you suggest.

Thanks, 

Of the data that you are testing what parts are static vs variable in nature. e.g. is IND static thus have something like /IND[A-Z|0-9].*/

Alternatively offload the test to a java service that returns a boolean then branch on that

Thanks @Jerome Green for your insights on this.

Your suggestion of /IND[A-Z|0-9].*/ was great.

But I see that the current code is like 

BRANCH on /messageType

     /DU001A|DU211D|DU417B|DU611A|DU031C/   : MAP  ( Do some logic )

    /DU901A|DU731D|DU555B|DU312A|DU030C/   : MAP  ( Do some logic )

    $default : MAP ( do some logic)

So say if I use the Regex /DU[A-Z|0-9].*/  then it will always match the first MAP under the BRANCH

BRANCH on /messageType

     /DU[A-Z|0-9].*/   : MAP  ( Do some logic )

    /DU901A|DU731D|DU555B|DU312A|DU030C/   : MAP  ( Do some logic )

    $default : MAP ( do some logic)

Thanks

------------------------------
Kailash Kumar Mishra
------------------------------


Original Message:
Sent: Fri April 10, 2026 02:28 AM
From: Jerome Green
Subject: BRANCH step with Regex modification

So in terms of a test we are saying if the value starts with IND and has numbers and or uppercase characters then go to this branch else go to default branch.

If this statement is true then the regex is shared, /IND[A-Z|0-9].*/ will match any of the values you shared. What other permutations would you have on the expression?

But no, you cannot set the regex in a variable and try to substitute it in. Ideally best to avoid that as

1. your code is more readable and supportable where you can see the expression directly
2. should be more efficient than building a java service as you have one less invoke to perform

------------------------------
Jerome Green


Original Message:
Sent: Fri April 10, 2026 01:58 AM
From: Kailash Kumar Mishra
Subject: BRANCH step with Regex modification

Hi Jerome,

Thanks for your response.

Yes the data is like :   IND001A , IND211D, IND417B and so on.

So Java Service is an option here.

But my attempt to use Variable Substitution in BRANCH will not work out is what you suggest.

Thanks, 

------------------------------
Kailash Kumar Mishra


Original Message:
Sent: Fri April 10, 2026 01:30 AM
From: Jerome Green
Subject: BRANCH step with Regex modification

Of the data that you are testing what parts are static vs variable in nature. e.g. is IND static thus have something like /IND[A-Z|0-9].*/

Alternatively offload the test to a java service that returns a boolean then branch on that

------------------------------
Jerome Green

What you describe is conceptually a configuration management topic for business logic.

This is important to keep in mind, because it has implications on the suitability of branch conditions. These are great for things like true/false.

But in a scenario where the message type determines what business logic should be applied, it is not an ideal approach. I am not saying that you cannot do this. But it has implications on ease-of-maintenance, compliance checks, deployment, testing, and more.

Ideally there are two stages. First, determine what action should be taken on a given message. Here the use of a configuration file is the appropriate approach. And second, take action via the `branch` step.

This has already been touched upon, but I wanted to add the conceptual side. Because technically there are many possible ways, but some fit better than others.

How exactly the configuration is managed, depends on your deployment and other aspects that have not been covered. In general a properties file and a small Java service can help here. I have a free tool for this, if you don't want to write something yourself.

It is also possible to use a separate service (Flow or Java) and do a lookup there. But a config file is more explicit and makes auditing, updates, and other aspects a lot easier.

I would advise against a database approach. It makes deployment, updates, and testing a lot more complicated.

Thanks @Jerome Green and @Graham and @Christoph Jahn for the detailed information and options which I can implement.

Both your inputs were really helpful. I will try the suggested methods.

Thanks,

What you describe is conceptually a configuration management topic for business logic.

This is important to keep in mind, because it has implications on the suitability of branch conditions. These are great for things like true/false.

But in a scenario where the message type determines what business logic should be applied, it is not an ideal approach. I am not saying that you cannot do this. But it has implications on ease-of-maintenance, compliance checks, deployment, testing, and more.

Ideally there are two stages. First, determine what action should be taken on a given message. Here the use of a configuration file is the appropriate approach. And second, take action via the `branch` step.

This has already been touched upon, but I wanted to add the conceptual side. Because technically there are many possible ways, but some fit better than others.

How exactly the configuration is managed, depends on your deployment and other aspects that have not been covered. In general a properties file and a small Java service can help here. I have a free tool for this, if you don't want to write something yourself.

It is also possible to use a separate service (Flow or Java) and do a lookup there. But a config file is more explicit and makes auditing, updates, and other aspects a lot easier.

I would advise against a database approach. It makes deployment, updates, and testing a lot more complicated.

Hi @Kailash Kumar Mishra,

Rephrasing what @Jerome Green and @Christoph Jahn have said: you are facing a problem where you are using static code to deal with a dynamic business condition.

In most cases, code should only handle deterministic operations, leaving business logic and decisions on other kinds of tools (decision models, aggregated queries, named/filter topics/queues, etc.).

However, not knowing what architectural decisions were made in the environment you have to work with, and your particular constraints, it may well be that code branches are the optimal solution: sometimes we have to compromise on code maintainability in the interests of performance; but alert management that it carries a _recurring_ cost as each new business condition requires recoding.

IF, and this is a big if, you were in greenfield project, you could have made incoming data to be classified before or as it entered your system, so that it could be routed directly into specific services (for instance, using handles with filters on queues or topics).

Using configuration files with conditions, trades lookup time (of the property lists) against branching, for the sake of visibility and ease of editing, but it should be considered as programming too, as you now have another type of object to deploy. If processing time is a concern, you could event think of using a property file with the classification rules, compiled on startup time as something as simple as a hash, used by a classification service to tag the data which would then feed a more concise structure of branches.

If you cannot do much more than recoding regex conditions, REMEMBER to have a _very large_ test set to be sure you are catching all possibilities AND that your change did not affect previous branching cases (a good advice, whatever your choices are).

All the best,

Gerardo.

Thanks @Jerome Green and @Graham and @Christoph Jahn for the detailed information and options which I can implement.

Both your inputs were really helpful. I will try the suggested methods.

Thanks,

What you describe is conceptually a configuration management topic for business logic.

This is important to keep in mind, because it has implications on the suitability of branch conditions. These are great for things like true/false.

But in a scenario where the message type determines what business logic should be applied, it is not an ideal approach. I am not saying that you cannot do this. But it has implications on ease-of-maintenance, compliance checks, deployment, testing, and more.

Ideally there are two stages. First, determine what action should be taken on a given message. Here the use of a configuration file is the appropriate approach. And second, take action via the `branch` step.

This has already been touched upon, but I wanted to add the conceptual side. Because technically there are many possible ways, but some fit better than others.

How exactly the configuration is managed, depends on your deployment and other aspects that have not been covered. In general a properties file and a small Java service can help here. I have a free tool for this, if you don't want to write something yourself.

It is also possible to use a separate service (Flow or Java) and do a lookup there. But a config file is more explicit and makes auditing, updates, and other aspects a lot easier.

I would advise against a database approach. It makes deployment, updates, and testing a lot more complicated.

Thanks @Gerardo Lisboa for your sharing your insights on this. 

It is really great that a lot if ideas have been shared and some really interesting points have come up throughout this discussion in terms of the problem in hand, its categorization and numerous ways in which we may approach each. Quite enlightening it has been this conversation so far.

Hi @Kailash Kumar Mishra,

Rephrasing what @Jerome Green and @Christoph Jahn have said: you are facing a problem where you are using static code to deal with a dynamic business condition.

In most cases, code should only handle deterministic operations, leaving business logic and decisions on other kinds of tools (decision models, aggregated queries, named/filter topics/queues, etc.).

However, not knowing what architectural decisions were made in the environment you have to work with, and your particular constraints, it may well be that code branches are the optimal solution: sometimes we have to compromise on code maintainability in the interests of performance; but alert management that it carries a _recurring_ cost as each new business condition requires recoding.

IF, and this is a big if, you were in greenfield project, you could have made incoming data to be classified before or as it entered your system, so that it could be routed directly into specific services (for instance, using handles with filters on queues or topics).

Using configuration files with conditions, trades lookup time (of the property lists) against branching, for the sake of visibility and ease of editing, but it should be considered as programming too, as you now have another type of object to deploy. If processing time is a concern, you could event think of using a property file with the classification rules, compiled on startup time as something as simple as a hash, used by a classification service to tag the data which would then feed a more concise structure of branches.

If you cannot do much more than recoding regex conditions, REMEMBER to have a _very large_ test set to be sure you are catching all possibilities AND that your change did not affect previous branching cases (a good advice, whatever your choices are).

All the best,

Gerardo.

Thanks @Jerome Green and @Graham and @Christoph Jahn for the detailed information and options which I can implement.

Both your inputs were really helpful. I will try the suggested methods.

Thanks,

What you describe is conceptually a configuration management topic for business logic.

This is important to keep in mind, because it has implications on the suitability of branch conditions. These are great for things like true/false.

But in a scenario where the message type determines what business logic should be applied, it is not an ideal approach. I am not saying that you cannot do this. But it has implications on ease-of-maintenance, compliance checks, deployment, testing, and more.

Ideally there are two stages. First, determine what action should be taken on a given message. Here the use of a configuration file is the appropriate approach. And second, take action via the `branch` step.

This has already been touched upon, but I wanted to add the conceptual side. Because technically there are many possible ways, but some fit better than others.

How exactly the configuration is managed, depends on your deployment and other aspects that have not been covered. In general a properties file and a small Java service can help here. I have a free tool for this, if you don't want to write something yourself.

It is also possible to use a separate service (Flow or Java) and do a lookup there. But a config file is more explicit and makes auditing, updates, and other aspects a lot easier.

I would advise against a database approach. It makes deployment, updates, and testing a lot more complicated.