Hi All,

Can someone please suggest on how to handle the Global Variable exception in the Try catch block.

Are you referring to global variable feature available from wM 9.0 on-wards?

did you define your global variable key value pair on IS. If the global variable that you specified for performing a variable substitution is not defined in Integration Server, at run time Integration Server throws an exception and
service execution fails.

Are you talking about using the Global variables in java service, within Try… catch block?

If you have already created the key/value pair of the global variable, you will be able to use it directly. But if the global variable you are trying to access is not defined then NullPointerException will be returned. You can handle the NullPointerException within the catch block.

Clarify if you are looking for something else.

Thanks Mahesh, Sam.

Global Variable: webMethods 9.6.

I have created the Global Variable in the IS Admin page and the happy side of the code works fine.

I just need to make sure that I am able to handle the flow service (not Java service) exception if the Global Variable is not configured in the IS.

sample example of a scenario:

Server A has the global variables and the code- Works fine.

Server B- No global variable setup but has the same code as in Server A. The flow service fails while executing. I need to handle this scenario in my code . Can this be achieved by usinbg try Catch block in flow service. If not how to achieve in flow service and not java service.

Appreciate your help in advance.

Although it’s technically possible (e.g. use a BRANCH), I would refrain from doing it. Global Variables can be included into Deployer projects and deployed to target environments just as you deploy the packages/services that depend on them. If you take this approach, a service wouldn’t get deployed to a target server without the global variables being deployed as well.

Percio

Why do you think that you will face this issue on Server B if you have moved your components thru deployer from Server A.

yes, you must make sure to deploy the global variables along with your flow services/package.

But in case if you want to handle this error, you can use the set of Sequence blocks and use it similar to try… catch.

Thank you all,

But we do not use deployer for deployment and there is customized script that takes care of the deployment process.

Sam,

Regarding the building blocks, I tried a couple of nested sequence of try Catch but it doesn’t work

Dev,

I suggest you look into ways of leveraging Deployer.

The issue you’re trying to address is a configuration / release management issue. If you start trying to address these issues with code, your application is soon going to be 99% exception handling and 1% real logic. Not a place you want to find yourself in. For example, if someone forgets to deploy a service that you depend on, are you also going to start checking if that service exists before trying to invoke it? Probably not. In that unlikely event, your application is just going to throw an exception (e.g. Unknown service). I’d apply the same rationale here. In the unlikely event that a global variable slips through the cracks, your application will certainly get to a point where the value will be needed and an exception will be raised… but again, the key here is to prevent this issue from happening via a solid deployment process. Even if you must use a custom deployment solution, then you must also find ways to incorporate global variables into your solution. I’d much rather see you adopt Deployer, but that’s up to you.

Good luck,
Percio

gotcha Thanks

Hi Dev,

The configuration issues tend to be the ugliest to verify/identify and the most time consuming.
Moreover, as Percio mentioned in one of the earlier posts: you don’t want to exaggerate with handling any possible exceptions. I agree with you, sometimes it proves difficult to identify the cases where exception handling brings no added value.

Regarding your example:

• I would go for having an utility service (deployed on both servers A and B) that checks on a regular basis whether all the global variables used in your code are deployed
• This means you will have to constantly maintain this list (it would be a mini-registry of used global variables)
• At each execution the utility service builds a list of the missing global variables. If any are found, flag it (in the way you prefer) and send the variable names and server name.
• the utility service could be triggered after each deployment as an initial check of the configuration related changes

If such a solution is in place, you don’t have to handle the exception in the normal code. Plus, apart from a robust deployment process that should handle configuration changes, you would also have an extra security step.

I am not sure what you mean here - can you please elaborate on what you tried?

Thanks,
Ana

Hi,

You could also create a configuration check utility which should be an easy task.

In my present project, the check config utility created can be run at any time to verify all dependencies for the service: global variables, extra settings, configuration files, connections, endpoints, referenced services, etc.

This list is created by developer (although partially filled by the utility’s self-discovery functions).

The final part of the Jenkins deployment job is to run that utility to verify the deployment.

We can also run it any time a defect is found (which usually caused modification of the configuration elsewhere - not a code defect).

Best Regards,