i'm wonder if there is any good error handling strategies for biztalk project? and how many is there that i can choose between? example using ESB Toolkit, logging all the error to file or sending to mail.
all tips is thankful and it would be great if there is a lite describe about the strategy or link to a blogger or article about it.
Thanks in advance!
Remember, there is a distinction between 'error handling' and 'notification'.
Error handling is implemented using the same patterns you would use in any .Net application. Scopes with Exception Blocks are analogous to Try...Catch in C#.
Notification is where you have a lot of options. But, before considering how, you need to define the what. Meaning what exactly do the users or administrators need to know? Figure that out, then choose the tools that let you implement to that requirement.
In order of complexity:
Windows Event Log
Failed Message Routing
BizTalk 360
Custom notification such as e-mail
Microsoft System Center with the BizTalk Management Pack
ESB Toolkit Portal
SharePoint with custom Message Repair and Resubmit
Related
We are using the online version of CRM. I have created a custom workflow but I can't seem to locate anything that will tell me how to debug it. Everything I've read refers to copying the pdb file into the server bin/assemblies folder. Since we're not using the on-premise version I'm not sure where to go from here. Can anyone point me to some type of documentation to do this?
Please refer this post to debug Custom Workflow in CRM Online.
Click here
You need to use the ITracingService, which is more like alert("I'm here!") rather than proper debugging.
In any case it's just like debugging a plugin and is described here: Debug a Plug-In - Logging and Tracing
An alternative method to debug a plug-in is to use tracing. Tracing
assists developers in troubleshooting plug-ins by providing run-time
plug-in information as an aid in diagnosing the cause of plug-in
failure. Tracing is especially useful to debug Microsoft Dynamics CRM
Online registered plug-ins as it is the only supported debugging
method for that scenario.
...
The tracing service was implemented to provide sandboxed plug-ins and
custom workflow activities with a means to output run-time information
when an exception is thrown.
I am building website, which is using ASP.NET, MS-SQL and AJAX.
I wonder, what is the best way to log errors in the entire website?
What I was thinking about, is just create some global log class (accessible from entire application) and log errors to "asperror.txt" file using try catch blocks in asp.net.
Is this good way to track errors? Maybe there is some better ways?
Thank you.
My humble opinion, and to not to reinvent the wheel, is to use ELMAH, which is great and easy to configure in ASP.NET.
It allows logging to Database, File, Email and so forth. It catches all unhandled exceptions and even allows you to see the last X (certain buffer is available, I believe is 500) number of messages through a web page. It even has a RSS feed if you want to subscribe to it.
Use ELMAH:
ELMAH with initial configuration for getting started quickly. ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.
I am involved in designing a asp.net webforms application using .NET 3.5. I have a requirement where we need to log exceptions.
What is the best approach for exception handling, given that there would be concurrent users for this application?
Is there a need or possibility to log in exceptions at a user level? My support team in-charge wants to have a feature where the support team can get user specific log files.
To give you a background, this application is currently on VB 6.0 and we are migrating it along with some enhancements. So, today the support personnel have a provision to get user specific log files.
My vote is for ELMAH. It is the easiest to set up and automagically lets you find bugs that never get reported back from the end-user.
While this is a bit self promotion, CuttingEdge.Logging allows native support for logging the user name in who's context a log event occured. When you configure the AspNetSqlLoggingProvider with the userNameRetrievalType set to "Membership", it allows retrieving the user name from from the HttpContext.
The AspNetSqlLoggingProvider logs to a database. The framework does not contain any tools for analyzing logs. When you want this, you can take a look at ELMAH, and I believe there are tools (both open source and commercially) available for log4net.
Good luck.
I'm looking at a fresh asp.net site in 3.5 that has absolutely no error handling or logging. What are some good options for logging and handling errors? I've used Log4Net on the 1.1 framework but hear there are potentially better options in 3.5.
One option is ELMAH. I asked a question about it here: ASP.NET Error Handling.
Since then, I have implemented a slightly modified version of it and the logging plus e-mail is great and easy to integrate via the web.config file.
We use two options for our logging:-
ELMAH for unexpected exception handling
NLog for expected, manual (debug, info and error) information.
ELMAH is a great out-of-the-box plugin that automatically captures exceptions (from 404's (page not found) to 500 exception thrown) and has a built in web-ui to visualize these errors. So it's a really quick and effective way of grabbing unexpected errors that occur.
Now NLog compliments this by having our developers manually insert debugging information into the code at specific spots, so when we need to get information out of a non-locahost system, it's very easy. For example, we litter log.Debug(..) code in most of our methods to see what the local variables are or returned values, etc. For more important information, we then use log.Info(..) .. but use this a lot less. Finally, for serious errors which we have trapped and handle, we use log.Error(..) or log.Warn(..) .. generally inside some try/catch scopes. So on our test or live servers, we then turn on all logging states (eg. Debug and greater) if we need to grab LOTS of data, live... or just the general important information, such as Info states and greater. We always have Warn, Error and Fatal states always on. Debug state generates a LOT of data, so we use that only sparingly.
So to summarize, I suggest you use TWO approaches to your WebApp. Elmah for excellent unexpected error trapping and NLog for expected information and errors.
Finally, NLog is WAAAY easier to use/get working than Log4Net. It basically superceeds it, IMO.
If you are used to log4net, stick with what you know. It's easy, fast, and works well. I've used it for years in 1.1, 2.0, and now 3.5.
ASP.NET Health Monitoring actually does a pretty decent job right out of the box!
MSDN, How to: Send E-mail for Health Monitoring Notifications
Enterprise Library maybe has a learning curve but is a good project.
In Asp.Net follow david hayden's article Enterprise Library 2.0 Logging Application Block
Personally, I havent tried log4net but seen the specs and examples for winforms, but my organization coded our own logging mechanism that reports and logs errors that are caught in the global.asax that reports everything we need to know about the stack trace, session (if exists), form's NVC, version of the app, URL that originated the error with querystring, and HTTP headers. Though I noticed that not all errors get logged there; such as forms authentication expiration or application pool restart/shutdown or anything reported by IIS that was not thrown by the application executing.
I'd like to be able to view the event log for a series of asp.net websites running on IIS. Can I do this externally, for example, through a web interface?
No, but there are two solutions I would recommend:
Adiscon EventLogger is a third-party product that will send your Windows EventLog to a SQL database. You can either send all events or create filters. Of course, once the events are in a SQL database, you can use any of the usual tools to create a web interface.
You can use ASP.NET's HealthMonitoring configuration section to configure .NET to send all ASP.NET-related events directly to a SQL database. This covers exceptions, heartbeats, and a host of other event types. The SqlWebEventProvider is a cinch to setup.
Do you want to know if you can home-roll something or are you looking for an app you can get off the shelf?
I'm not a Windows guy, but I think Microsoft's MOM/SCOM solution will probably let you view the event log over a web UI - probably really heavy and expensive if that's all you need though.
A quick google found http://www.codeproject.com/KB/XML/Event_Logger.aspx which shows that you can get in if you want to roll your own... also an MS tool on msdn
Sorry I can't be more help