Making decisions in your code is one of the most common operations. It is also one that causes a lot of problems in practice. Because we often approach it without the necessary level of care. Or shall we say paranoia? So in this article I will look at this for a few common scenarios in the integration context.
In the webMethods Flow language the most important construct to make decisions is the “branch” operation. The “repeat” command also falls into this category, but at least I haven’t used it that much compared to branch. However, the thoughts I am going to present here, do apply 100% to the repeat statement as well.
The typical starting point
Most people I know (incl. me) started with the following approach. It is a bit like translating a business requirement directly into code.
This is ok, until the “input” value contains something other than true or false. Of course everybody will tell you that this situation will never occur. I know, that’s a good one ;-). Even if people told you so, perhaps you even have it in writing, that doesn’t help if your organization just lost a few millions on this. Or a multi-billion satellite launch failed. Such disasters have indeed been caused by the equivalent of not checking for “other” values.
The problem
The core issue is that you will receive invalid (or better: unexpected) data all over the place. In fact data quality issues are one of the most common reasons for operational and sometimes even strategic problems in organizations. This has literally been the case for decades and will hardly go away any time soon. There is simply too much complexity and too little time/resources.
Interestingly the most common “other” value is “null“, i.e. no value at all. Why is that so? Well, it usually means that something has gone wrong upstream. Typical examples are
- A mapping was missed during implementation altogether
- A data field name was changed at the source (e.g. your ERP or CRM system) but nobody told the integration team to adjust their mapping
- A conversion went wrong and instead of reporting the error, it silently returned nothing
- A lookup returned nothing because someone forgot to update the mapping table
- A record was silently removed because of an unhandled exception
- Data arrived in the wrong order and therefore a reference points to a non-existing entry
- …
In all those cases two things came together: 1) a system did not act according to its specification, and 2) this was not detected by a sanity check. This is how a lot of new systems start their live. People have been happy to deliver new functionality to the business. But with tight deadlines and no-one willing to allocate budget for situations that “cannot happen”, most checks were omitted.
What happens then is what I call “learning through pain”. If you are lucky, although it will not feel that way initially, you notice issues quickly because your system sort-of crashes. This has the great advantage (no irony here) that no faulty data can propagate further. The latter is a much bigger problem than your system not behaving as expected. Because we may now have to perform a cleaning exercise.
If you ever had the pleasure to be involved in such an activity, you will nod heavily. If not, consider yourself lucky. Such things often mean that parts or even the entire organization needs to stop working to prevent further damage. This means C-level attention, negative publicity, impact on stock price (with all its potential consequences), and perhaps even regulatory interventions. All in all it’s a truly unpleasant experience.
Your chance to shine
Having painted such a grim picture, let’s now turn this around. Because it is your chance to shine. Not too many technical people I have met seem to care about such issues in a pro-active way. You will therefore stand out (positively 😉 ) by discussing such topics with the business upfront. Because we are not talking about implementation details anymore. Instead this is a business discussion. More specifically it is about risk management.
Let’s now talk a bit about the communication side of this. We all like to get the feeling that our conversation partner cares for our needs. If someone always just nods and tells me that what I want is no problem to implement, I have zero confidence in their ability to deliver on that promise. Instead it signals the following things to me (and many others I have talked with about this):
- I do not understand what you want me to implement. But I rather say nothing and waste your money and time.
- I do not really own the problem, in the sense that I make it my own and take pride and delivering something of value.
- I am afraid to speak up and defer the conflict until later, when it will cost at least 10 times more of your money.
- I see this as an opportunity to get more money from you. Because I first implement some crap and when you realize this, I a demand more budget for the next iteration. And perhaps we repeat this game a few more times.
So whenever you ask thoughtful questions, nobody in their right mind will perceive this as you not being competent in your job. On the contrary. Watch your senior colleagues and you will see that they ask a lot of questions (probably even more than you). They often do this with a short explanation why they want to clarify something. The reason is to make the other side aware of the complexity of the discussion.
Here is a bit of background and it is critical for your career: We all live in our own worlds. The things we know well are all very obvious to us. And when (not if) others have a problem to follow our thoughts, we instinctively wonder if they are a bit slow in their head. But they are not. They simply didn’t spend the same amount of time on these details as we. And the same goes the other way around, of course.
Some folks are more aware of this than others. It is usually people who have worked in many different contexts. Whenever they enter a new environment, they start from scratch. This is one of the advantages that a good(!) consultant brings to the game. If you have a lot of experience in a particular field, but know little about the project details, you can ask a lot of good questions.
But let me quickly get back to why it helps so much to lay out the reason for asking a question. It basically avoids that the other person feels stupid or thinks you are stupid. Because that reason highlights that you both know your stuff and still operate with different knowledge sets.
You will sometimes come across people that still think you are stupid because you don’t know what they do. Resist the temptation to return the favor. Yes, that can be hard and I sometimes failed here, too. Yet, the saying is right: Don’t argue with fools. There is even a bonus for you. Most other people in the room will see that in addition to being right in the first place, you also handled an unprofessional response in a professional manner.
Here is another example: My knowledge about Integration Server. I have been working with it since early 2002 and spent way more than 10k hours on it. I know most of its areas inside-out, incl. a lot of the internal API. Yet there are parts where my knowledge is relatively sketchy, at least compared to others.
Let me close this section with a practical tip: If you are in a meeting and what you were just told did completely overwhelm you, and you didn’t understand much, don’t simply say that you have no questions. That would come with a connotation of “I understood what you just told me”. Instead say something like “I don’t have any questions right now, but there is a chance that some things come up once I have read through the material you gave us. In that case I would like to get back to you.” That is a perfectly valid and professional response. And you keep all your options.
Now back to the coding side …
Default behavior
The next approach you can take with the branch operation is to use the “$default” value. As its name implies it will be chosen, if all previous options didn’t match. That is also the reason why it must always be placed at the last position. This is what it would like in our example:
While this is technically working, it is not a good approach for our scenario. Because we are basically looking at a fallback approach here. A suitable situation for $default would be something like this: The order can arrive with the status approved (indicated by “true”), denied (indicated by “false”), or needs_manual_approval (indicated by the name of the default approver).
While I would personally not recommend such a design, it is conceivable to exist. And in this case the $default branch would be used to trigger the manual approval.
Checking for invalid values
A much better approach for a simple yes/no decision, is to check for illegal values. Then you can react in whatever way makes sense from a business perspective.
The code above is the simplest such case. It does not distinguish further. The latter can make sense to react in a more specific manner to various illegal values. As an example, a $null value probably indicates a different problem than “xxx“. See below for a code snippet to illustrate that.
There is more than literal values
In addition two checking for strings like “true” literally, there are two additional and very powerful ways to use the branch operation. I will not go into details here, because this is article is not meant to replace the product documentation. But since those options seem to be missed by people relatively easily, I want to mention them. You can then look up all the details in the documentation.
The first option is use regular expressions instead of simple strings. By putting the expression between two forward slashes (the established syntax for regexes) you trigger this special evaluation. As an example you could use “/.+/” to check for not-empty fields. Mastering regular expressions is absolutely necessary for your career in software development, so why not start here.
The ultimate flexibility comes when you enable the evaluation of labels. Then you can place pretty much any boolean expression in there. If possible, however, I recommend to use string literals or regular expressions. Simply because they are easier to read and comprehend. (The screenshot below is not a realistic combination of conditions. But I wanted to convey how flexible you are with this approach in a single picture.)
In closing
The reality often looks a bit more nuanced. But my aim was not to equip you with some copy-paste knowledge anyway. Instead I wanted to share the thought process. At the end of the day all situations are different and the so-called “best practices” are a two-edged sword. They are applicable (without modification) only to a pretty specific context. Without understanding what that context is, and more importantly how it determines the choices made for the best-practice approach, this is a pretty dangerous situation.
I hope you found this post helpful and would be interested in your thoughts. Thanks.
If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.
© 2024, 2025 by JahnTech GmbH and/or Christoph Jahn. No unauthorized use or distribution permitted.
