Why does flow service Exception handling does not work global variables

Dear Experts,

Seems like Exception Handling does not work with Global Variables that does not exist.

Control never goes to catch block and flow service fails with com.wm.lang.flow.FlowException:[ISC.0049.9031] Global Variable globalval does not exist.

1 Like

Invoking this service in trycatch block of parent service does work(i.e calling this service in another one’s trycatch).

That is indeed strange. It looks like a bug to me, so I’d file a ticket with support and see if it’s possible for them to address it in a fix. Now, if I may make one small suggestion, one thing you can do to avoid exceptions due to missing global variables is to create a Java service for fetching a global variable value, and if the global variable does not exist, it returns an optional default value instead of throwing an exception. For example, I have a Java service in my common utilities package that takes in the variable name and an optional default value as input. It then performs this logic:

IDataCursor cursor = pipeline.getCursor();
try {
	String name = IDataUtil.getString(cursor, "name");
	String defaultValue = IDataUtil.getString(cursor, "default");
	if(GlobalVariablesManager.getInstance().globalVariableExists(name)) {
		String value = GlobalVariablesManager.getInstance().getGlobalVariableValue(name).getValue();
		IDataUtil.put(cursor, "value", value);
	else if(defaultValue != null) {
		IDataUtil.put(cursor, "value", defaultValue);
catch(Throwable t) {
	throw new ServiceException(t);
finally {

Yet another option is to have a startup service in your package that creates the global variables it needs when the package is loaded if the global variable doesn’t exist. Here’s a snippet from one such startup service:

if(!GVM.globalVariableExists(LOGGING_VERSION_GV)) {
	GVM.addGlobalVariable(LOGGING_VERSION_GV, Integer.toString(version), false);

GVM in this case is defined as:

private static final GlobalVariablesManager GVM = GlobalVariablesManager.getInstance();

I’ve used both approaches in the past and they work well.

Hope this helps,

Thanks @Percio_Castro1 - It is indeed a bug; thought I will bring this up to forum. I usually avoid using global variables as much as possible. This is one among them.

Should not be using this way until this work around is really required. Ideally the Product should handle this.

1 Like

Thank you @srikanth.prathipati1803 for setting me straight…hoping to learn more from this tech community…

1 Like

Hi @Rameez071,
I am the Product Manager for Integration here at Software AG and I agree with @srikanth.prathipati1803, this is bug and so I have raised this as an internal defect. In the meantime use roll your own java service as recommended,

@srikanth.prathipati1803, by the way, just to clarify, my main reason for having those Java services is to prevent the creation of certain global variables unless they are absolutely needed, which makes for simpler deployments and it makes for a more manageable list of variables in my environments. So, for example, let’s say one of my global variables is for a timeout value and I feel that 60000 milliseconds is a reasonable default. Then, in my code, I can use the getVariable Java service above and pass it a default of 60000. My Operations team can then safely deploy my package without worrying about creating the global variable until they actually have a need to change that default timeout, which may or may not ever occur. Even if globalVariables.cnf is being automatically deployed, which eliminates the need for manual creation of the variables, this approach helps keep that file smaller and more manageable. The fact that using this service prevents exceptions from being thrown when the global variable isn’t present is just a bonus. :slight_smile:


1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.