We're building a large web app that has numerous layers. In order to communicate to the business layer we're using a service layer that the web layer calls when data is needed. Unfortunately, it seems that if exceptions are thrown in the business layer, it seems that the services on the web side are wrapping the exceptions and re-throwing them. We're looking for a clear way to encapsulate the error and log it, without WCF wrapping a new exception around the original.
Thanks
FWIW, each of our exposed WCF Service Layer methods catches a System.Exception and passes it off to a HandleException helper (this could also be a base service class method I guess)
HandleException:
Logs the error
Applies the exception reformatting to SOAP faults (currently we are using WCF Exception Shielding)
Applies any exception-specific handling (of the format if (ex is SomeTypeOfException) ...)
There are various ways to do this. The solution you presented isn't half bad I believe, though it doesn't scale much (mixing business specific error handling with web-related code creates some sort of coupling). All this depends on your achitecture: you could add a superficial, lightweight layer that translates business errors into web errors, that are handled in the web layer error handling code. You could also you AoP and intercept the calls and translate the errors for the layers above.
Related
With my team, we are trying to set up an error handling policy common to several microservices (for the majority of cases). My team and I are struggling to understand the difference between a listener-level error handler and a container-level error handler. What are the real implications behind this choice? Is it only the fact that the container error handler does not have access to the message?
The KafkaListenerErrorHandler allows a more fine grained exception handling, we can use on the content of the exception to define if it is retryable or not.
In the error handler containers it seems more complicated, before it was possible to provide a custom classifier but not anymore, we can only pass a classification map.
In the past we used to use the SeekToCurrentErrorHandler (now DefaultErrorHandler), which was recommended in the documentation. I saw another StackOverflow thread related to this topic but I can't quite make the connection with our questions. The documentation doesn't seem to address the implications of this choice.
Thank you very much.
The main use case for the listener-level error handler is for request/reply processing; it allows the error handler to send some other result to the sender to indicate the request wasn't processed. As you say, it also provides access to the spring-messaging converted Message<?> (possibly with a converted payload); e.g. for logging; it can re-throw the exception to invoke the container EH.
Regarding classification, that change was to allow classifications to be added and removed dynamically. If you prefer to have the old behavior (allowing a custom classifier) to be restored, please open an issue on GitHub.
I have inherited supporting and making BizTalk applications as part of my development role.
I'm a general C# developer so I was pleased to see I can create Classes and call the Methods from the Expression shape of an Orchestration.
This means I can do all the data manipulation using code I am familiar and faster with rather than learn the BizTalk ways.
At this point I am not concerned with if it's a good idea or not.
Are there any purely technical reasons I should not do this?
You would have to make sure that whatever external methods you are calling is muli-threading capable and can handle high throughput.
If you don't achieve the above then you will either get some very strange issues (caused by cross thread contamination) or you will cause a bottle neck in BizTalk which will reduce message throughput.
You also need to make sure that errors are handled, retried and propagated back correctly to the calling Orchestration on failure. I came across one solution where the developer for some reason had decided to call a web service using an external class. Every so often this web service would throw an error, but the class would just pass the error message as it was back to the Orchestration as if it was a valid response message. This would cause a failure later on in the Orchestration when it tried to use the message and it did not match the expected message. When I got allocated budget I replaced this class with a properly configured send port, which also automatically retried the message when it encountered the web service error and then it successfully processed.
Technically you are adding deployment and maintaining complexity with the externals assemblies, for example any change in some contract will require changes in the assembly and the orchestration.
And you're losing all the advantages of the BizTalk mapping engine for data transformation which is in general an easy part to learn.
I say this, it's very important for future maintainability to develop BizTalk apps in the "BizTalk Way".
For example, if you did message manipulation in an external class that should have been done in a Map or with XPath, I would fail that in Code Review and you'd have to refactor.
The reason is because whoever might take this over from you should expect a BizTalk app. I've seen situations such as you describe and it does make it harder to upgrade, enhance, support new business requirements because now the developer has to accommodate the BizTalk and external processes.
Technically using .NET classes does not break anything in the BizTalk. Lots of BizTalk components are based of .NET framework such as Adapters, pipeline components etc. In my view, use the best of both BizTalk and .NET depending on the scenarios. e.g. if you need to map an inbound XML to outbound XML use BizTalk maps as they are lot easier and quicker to implement, in this scenario using a .NET class is more tedious then using map. I don't think there is a big learning curve in using BizTalk features such as Maps, orchestrations, pipeline components.
I got a question about exception handling.
I guess it may be quite easy for you but for me I just don't know how to handle exception in multi-tier projects.
Let's say in my solution, I have several project.
I have (lower) DataAccess, BizComponent, WCF, Proxy and Presentation (upper).
I try to "try catch" in DataAccess and throw the exception to BizComponent and in BizComponent I try again "try catch" and log the error and throw the exception again to WCF.
In WCF and Proxy layers, I do the same thing. In presentation layer, I show come custom message to end user.
My senior told me that I only need to start doing "try catch" in WCF and upper layers.
And I don't need to do in DataAccess and BizComponent because it will be caught in
WCF.
Should I try to catch the exception in DataAccess,BizComponent and
throw exception or should I just try to catch only in WCF and starts
throwing to upper layers?
Which one is better practice ?
If you are not clear about my question, please let me know.
This is my first multi-tier projects so it makes me confused.
Thanks in advance.
As a rule of thumb only handle (catch) exceptions if you are going to do something with them.
For example, if you could catch a database exception in the data layer if you wanted to provide additional information in the "upper" layers.
An approach I use personally is to catch and log exceptions in the business layer and then rethrow the same exception or a wrapping exception that provides more friendly information for layers higher in your stack. This provides a consistent logging process and does not require boiler plate logging code in the application.
If you reuse the code in multiple applications and need different log stores this can be handled using dependancy injection.
I have a complex ASP.NET application and it's running since 2009.
I need to monitor it's performance and determine which methods in which layers are time or resource consuming. Then I can optimize methods.
Right now, I'm using SQL Profiler to check the queries and I tune the database step by step. I want to do the same for other layers (UI, Service, and Repository).
I've used Postsharp and Enterprise Library Policy Injection Application Block.
I've implemented some attributes and add them to some classes which helps me to get BeforeMethodEntry and AfterMethodEntry (AOP model) automatically. Therefore, I can get the execution time of each method. It also handles exception log and page view log.
But, I think there may be another implemented/standard solution to monitor the running application.
PS: I've implemented some other solution like implementing ExceptionHttpModule and PageViewHttpModule which don't need any Third Party libraries. It doesn't meet my requirements.
*In a simple words, I want to log and monitor layer's activities (specially mehod execution duration). *
You may want to look into Spring.Net Aop. If you an AroundAdvice, you will be able to start a StopWatch before the execution of the method, and stopping right after it finishes. There is a way to use it as you would with PostSharp (i.e. using attributes).
In an effort to understand MVC 2 and attempt to get my company to adopt it as a viable platform for future development, I have been doing a lot of reading lately. Having worked with ASP.NET pretty exclusively for the past few years, I had some catching up to do.
Currently, I understand the repository pattern, models, controllers, data annotations, etc. But there is one thing that is keeping me from completely understanding enough to start work on a reference application.
The first is the Service Layer Pattern. I have read many blog posts and questions here on Stack Overflow, but I still don't completely understand the purpose of this pattern. I watched the entire video series at MVCCentral on the Golf Tracker Application and also looked at the demo code he posted and it looks to me like the service layer is just another wrapper around the repository pattern that doesn't perform any work at all.
I also read this post: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx and it seemed to somewhat answer my question, however, if you are using data annotations to perform your validation, this seems unnecessary.
I have looked for demonstrations, posts, etc. but I can't seem to find anything that simply explains the pattern and gives me compelling evidence to use it.
Can someone please provide me with a 2nd grade (ok, maybe 5th grade) reason to use this pattern, what I would lose if I don't, and what I gain if I do?
In a MVC pattern you have responsibilities separated between the 3 players: Model, View and Controller.
The Model is responsible for doing the business stuff, the View presents the results of the business (providing also input to the business from the user) while the Controller acts like the glue between the Model and the View, separating the inner workings of each from the other.
The Model is usually backed up by a database so you have some DAOs accessing that. Your business does some...well... business and stores or retrieves data in/from the database.
But who coordinates the DAOs? The Controller? No! The Model should.
Enter the Service layer. The Service layer will provide high service to the controller and will manage other (lower level) players (DAOs, other services etc) behind the scenes. It contains the business logic of your app.
What happens if you don't use it?
You will have to put the business logic somewhere and the victim is usually the controller.
If the controller is web centric it will have to receive its input and provide response as HTTP requests, responses. But what if I want to call my app (and get access to the business it provides) from a Windows application which communicates with RPC or some other thing? What then?
Well, you will have to rewrite the controller and make the logic client agnostic. But with the Service layer you already have that. Yyou don't need to rewrite things.
The service layer provides communication with DTOs which are not tied to a specific controller implementation. If the controller (no matter what type of controller) provides the appropriate data (no mater the source) your service layer will do its thing providing a service to the caller and hiding the caller from all responsibilities of the business logic involved.
I have to say I agree with dpb with the above, the wrapper i.e. Service Layer is reusable, mockable, I am currently in the process of including this layer inside my app... here are some of the issues/ requirements I am pondering over (very quickly :p ) that could be off help to youeself...
1. Multiple portals (e.g. Bloggers portal, client portal, internal portal) which will be needed to be accessed by many different users. They all must be separate ASP.NET MVC Applications (an important requirement)
2. Within the apps themselves some calls to the database will be similar, the methods and the way the data is handled from the Repository layer. Without doubt some controllers from each module/ portal will make exactly or an overloaded version of the same call, hence a possible need for a service layer (code to interfaces) which I will then compile in a separate class project.
3.If I create a separate class project for my service layer I may need to do the same for the Data Layer or combine it with the Service Layer and keep the model away from the Web project itself. At least this way as my project grows I can throw out the data access layer (i.e. LinqToSql -> NHibernate), or a team member can without working on any code in any other project. The downside could be they could blow everything up lol...