[Azure Logic App] - Check multiple possible values in cases for Switch-Case structure

Question

Does Azure Logic Apps support matching multiple cases for a single code execution block?

I'm implementing a Logic App that contains a Switch structure that parses domains, but there are quite a number of cases in which multiple domains (example.com, example.io, subdomain.example.com etc) would end up executing the same logic when detected. I didn't want to pollute the program with multiple nested if/else blocks, so I was trying to use the Switch structure.

The switch/case declaration in various programming languages has a historical connotation supporting multiple case matches for a single routine. For example:

C/C++:

switch (a) {
	case 1:
		printf("I am One\n");
		break;
	case 2:
		printf("I am Two\n");
		break;
	case 3:
 	case 4:
 	case 5:
 		printf("I am Three, Four or Five\n");
		break;
	default:
		printf("I am default\n");
}

Java:

int numLetters = 0;
Day day = Day.WEDNESDAY;
switch (day) {
	case MONDAY:
	case FRIDAY:
	case SUNDAY:
		numLetters = 6;
		break;
	case TUESDAY:
		numLetters = 7;
		break;
	case THURSDAY:
	case SATURDAY:
		numLetters = 8;
		break;
	case WEDNESDAY:
		numLetters = 9;
		break;
	default:
		throw new IllegalStateException("Invalid day: " + day);
}

Ruby:

case x
when 1..5
  "It's between 1 and 5"
when 6
  "It's 6"
when "foo", "bar"
  "It's either foo or bar"
when String
  "You passed a string"
else
  "You gave me #{x} -- I have no idea what to do with that."
end

Javascript:

switch (expr) {
  case 'Oranges':
    console.log('Oranges are $0.59 a pound.');
    break;
  case 'Mangoes':
  case 'Papayas':
    console.log('Mangoes and papayas are $2.79 a pound.');
    // Expected output: "Mangoes and papayas are $2.79 a pound."
    break;
  default:
    console.log(`Sorry, we are out of ${expr}.`);
}

How can I do something similar in a Logic App without relying in awful hacks and ugly multilevel nesting of conditionals?

Currently my Logic App looks like this because I have to repeat the same instructions multiple times:

And it will probably grow with time. Is this solvable? Or should I move away from Logic Apps and implement it in a proper programming language from the start?

Answer 1

Hi Lucas Magalhães and thanks for the question

Logic Apps is very powerful for integration and can make a lot of things a great deal simpler vis-a-vis writing the same in code (where often a lot of "plumbing" code is required). In addition connectors often have added functionality for common patterns. An example here for the http action https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http#asynchronous-request-response-behavior

However, that all said, my personal opinion here is that the workflow logic should be as simple as possible and each workflow not too large (in the same way we dont typically have 100s of lines in a procedure/function in code, we refactor instead)

If you reach a situation where the workflow becomes hard to read or you're struggling (as you are in the above example with a large conditional statement) then i would consider the following two options

(1) Logic Apps provides the option of running JS code snips https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-add-run-inline-code?tabs=consumption which can be useful
(2) you can simply offload parcels of business logic to your own Az function in a language of your choice (supported by functions), leaving the logic app workflow to model the integration flow. Of course you're not limited to functions, any API or functionality Logic Apps can integrate with can be used to provide business logic

The trade off here is that business logic is executed out of process - in modern programming terms that's the equivalent of reaching out via an API versus executing a local function and the former is of course more "expensive" in terms of performance

So, again in my opinion, it's a trade-off between complexity and performance - but I do think it's counter productive to try and create a large and complex/unwieldy workflow / orchestration - which will be hard to keep maintained