Hi All,
Please suggest best option to implement a Error Handler mechanism.
- At Work Flow Service Level
- At Flow service Level
- At Project Level, Please share any references.
There is no fixed answer to this, it really depends on the context of what you are trying to resolve or do.
For instance if you are developing a flow service that references an external app, which potentially returns an obscure error, it might be a good idea to introduce a try/catch to reformulate the error message and report something that a developer using the service might better understand i.e. instead of “error 500 - null pointer exception”, you might instead want to return “Invalid request, a mandatory field is missing from the request to MyGreatAppServer”.
If you were then developing a workflow that calls that service, you might also want to trap the error so that you can then send a message to an administrator with the request details so that they could troubleshoot the missing field.
etc. etc.
context is everything.
regards,
John.
3 Likes
Hi John,
Thanks for clarifying and sharing the information. One more quick query
We are planning to design and implement the multiple projects under the specific tenant.
In this case, how can we share and use the common business logic/configurations and common frameworks across the Multiple projects ?
Please share your inputs
Thanks & Regards,
Jeevan
You may get some general guidelines and tips from the community regarding over-arching design of your integration space. But in general, you’ll likely want to engage a reputable consulting firm that has experience with this to help guide the approach. There are many factors to consider including organization, applications, relationships, etc. Most refer to this as “architecture” which a cynic may say is just a term used to charge a higher fee. 
Regarding an “error handler framwork” – I’ve seen this range from the extremely complex to minimal. The current approach we follow is minimalist and not a framework at all. Just a couple of helper services that top-level services can use to notify via email or ticketing system. The the top-level service has config that indicates which to do (none, either or both) and the data elements to give to each to notify the right group with the right info. In the catch block of the top-level service, it gathers the error info then calls the helper services to notify. Nothing more elaborate than that.
Other places have hierarchical schemes and config schemes for error handling/notification similar to what is done by logging facilities such as log4j. In the couple of places that did that, I thought it was overkill and overly complex. “If I change this setting, what will I break?” But that’s just my experience/opinion. Every place is different so you may find that such a scheme may be beneficial in some way.
1 Like
In the not to distant future we will be releasing a major update to webMethods.io Integration to unify our on premise platform and cloud platforms. As part of this we will allow developers to import packages into projects and hence allow you to share common code/tools across projects.
Initially you will use our Service Designer to create these package and use git to share the package between developers and projects. We will follow this up to allow you to also create packages and edit them via our web tools too.
However, you will will need to verify with your account manager of CSM (Customer Success Manager) to check if your existing contract will encompass these new features.
regards,
John.
3 Likes
Thanks, Reamon and John for clarifying the queries related to the Error Handler mechanism and new features of webMethods.io.Integration.
Thanks & Regards,
Jeevan
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.