Hi All BizTalk Developers,
I need some input and guidance on how to design an Orchestration that can take few parameters as Input and log them in SQL server table (tblTrackingData)
I want to start this orchestration at various points, for example when I am calling a webservice so I want to log the request in DB and when I get the response then I want to log the response xml also in the same table.
In case of any exception I want to log error message and other details in the same table for tracking purpose.
Can some one guide me, direct me to some existing blogs/posts on how to handle this generic tracking / exceptions etc by starting a new Orchestration.
The purpose of a new Orchestration is to call it from anywhere, please suggest if it could be handled in a better way also.
Thanks.
The best advice, don't do this.
The reason? Everything you describe is already done by BizTalk Server automatically by BizTalk Tracking and the Event Log.
I can tell you from experience, you will not need anything else beyond Tracking and the Event Log.
I do recommend you implement proper exception handling within you app and log custom events, but they would also be written to a Windows Event Log only as well.
Related
I'm very new to Application Insights, and I'm thinking of using it for a set of services I plan on implementing with asp.net webapi. I was able to get the basic telemetry up and running very easily (right-clicking on a project on VS, Add Application Insights), but then I hit a block. I plan to have a correlation id set in the request headers for calls to downstream services, and I would like to tag all the telemetry related to one outside call with the same correlation id.
So far I've found that there is a way to configure a TelemetryInitializer, but if I understood correctly, this is run before I get to access the request, meaning I can't check if there is a correlation id that I should attach.
So I guess there might be 2 ways to solve this: 1) if I can somehow actually get access to the request headers before the initializer, that would obviously solver the problem, or 2) somehow get a hold of the TelemetryClient instance that is used to report the automatically generated telemetry.
Perhaps the last resort would be to turn off all of the automatic stuff and do all of it manually, when I could of course control what properties are set on the TelemetryClient. But this would be quite a lot more work, so I'd prefer to find some other solution.
You were rights saying that you should use TelemetryInitializer. All TelemetryInitializers are called when Track method is called on any telemetry item. Autogenerated request telemetry is "tracked" on request OnEnd, you should have all your custom headers available for you at that time.
Please also have a look at OperationId - this is part of the standard context managed by App Inisghts and is used exactly for the purpose of correlating requests with downstream execution. This is created and passed automatically, including traces (if you use trackTrace).
Moreover, we have built-in support in our UX for easily seeing all telemetry for a particular operation - it can be found in "Search->Details-->Related Items-->All telemetry for this operation"
Is there any error logging option in APIGee?
I am enabling a proxy endpoint in APIGee for a customer. If there is any error in the flow, how can I log it to a persistent store?
Specifically, I am using javascript policies and parsing some of the returned by back-end service, format to a different format. If there is any parsing error, where and how can I log it?
I am able to catch the error with try catch block.
Can I send an email in the catch block to a specific email address?
Thanks,
Deepak
You can catch the error in your catch block and then set the appropriate variable to contain the detailed error message you might have ran into.You can use syslog/messagelogging policy to send all the request details along with any parsing exception that you might have. You need some kind of a logging server at your end to be sent the logs to or you could also use public log management services, such as loggly. Refer to this section for more details - http://apigee.com/docs/api-services/content/log-messages-using-messagelogging
Vineet I think you are looking to solve the following problems here:
During the coding process you want to debug and understand what is going on? Something that lets you log.debug equivalent.
You want to also trigger exception flows or external processes when things go wrong in your proxy flow.
For #1 you can assign variables and trace using apigee's debug view. Any flow variable assignment in Apigee policies is printed in the debug view, if the policy is executed. So that provides you with log.debug mechanism, whenever you trace.
For #2 you can take a variety of approaches based on rest of your systems and processes. The previous answer by #Mike Dunker is a good approach. I can suggest a few more alternates
As an alternate you can also use Apigee's analytics views to monitor errors, albeit after the fact.
You can set up external monitoring scripts on your backend or on the apigee endpoint based on some synthetic transaction that touches upon the entire logic of your flow. When the services return error you can measure metrics and/or raise alert from your monitoring system.
If you have an on-premise installation of Apigee, you may want to consume apigee log files on the servers and raise appropriate actions on errors.
You can raise a desired error message to a JMS queue when error happens. Refer to Apigee's JMS support here
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
Everyone probably notices that most modern applications nowadays has a way for user to send crash/bug report either automatically or with user permission. Some examples are Mozilla Crash Reporter or most Microsoft applications.
I really like this feature since it allows me to collect the bugs report quickly with helpful information than just let my user reports the bug/issue traditionally such as submit a help ticket.
I wonder if there is an easy or systematic way to implement that capability in ASP.NET web application.
Have you guys had any experience or knowledge to share for both WebForms and MVC applications? Or if this could be implemented in Client-side like JavaScript/JQuery, that'd be good.
Thanks!
ASP.NET 2.0 introducted Health monitoring, which allows you to do this by just adding some stuff to the web.config. See: http://msdn.microsoft.com/en-us/library/ms998306.aspx
It can log to mail, sql, eventlog, etc. and allows you to set buffers. So it for example won't kill your mailserver if the sql database goes down or if some user discovers a bug and tries to call it too often a second :-)
You can also log failed authentication and app pool restarts with it, it's pretty usefull if you just need it working quick. It's still questionnable if it is the best solution to manage all the errors. Because it might not got all the information you need, for example browser version or smt like that.
ELMAH is a library that plugs in and detects exceptions. You can also log an event yourself. The events and a great deal of data like url parameters and browser information can be emailed to administrators and optionally stored in a database for display. (Rather like an event log for the web site.) It doesn't have a built-in user form that I've seen, but can probably be extended to include such an option.
I've been using/customizing it for about two years now and it is really exceptional.
Another option might be to use Kampyle which includes a feedback box on the bottom right of your web site. You could use Javascript to trigger the box to appear if an issue is detected on the web site.
For an ASP.NET applicatino--or any Web application for that matter--isn't this just a two-step process of:
Logging the error (obviously); and
Put a form on the error document to allow the user to enter feedback.
Or is there more to this?
Your errors will pass through the Application_Error method of the Global.asax.cs file (which you may have to create). I use this fact to capture the error and log it to a database:
void Application_Error(object sender, EventArgs e)
{
try
{
SqlConnection errConnection = new SqlConnection("Your connection string");
// After setting up a command object, I call a stored procedure to save information about
// the crash. I pass two primary arguments. The first is the URL:
errCommand.Parameters.Add("#URL", SqlDbType.VarChar).Value = Request.Url.ToString();
// The second is the error information.
errCommand.Parameters.Add("#EI", SqlDbType.Text).Value = Server.GetLastError().ToString();
// I pass some other information from my session as well...
// After setting up an output parameter called ErrorID, I call the command...
errCommand.ExecuteNonQuery();
// Now Error ID is stored in the session.
Session["ErrorID"] = (int)ErrorID.Value;
}
catch { } // I do NOT want the error handling call to throw an error.
}
Now, you should have set up your Web.Config file so that a specific page gains control when an error occurs. In this page, you'll check the session for the error ID and show it to the user. In the output, I ask the user to write down the error if they would like to call us for more information. If we do receive a request, I can go into the database and get a complete trace of the error.
You can checkout my tutorial on how to implement exception logging in asp.net - http://jesal.us/blog/index.php/2008/04/08/exception-logging-using-the-database/
I'm looking for the best way to log errors in an ASP.NET application.
I want to be able to receive emails when errors occurs in my application, with detailed information about the Exception and the current Request.
In my company we used to have our own ErrorMailer, catching everything in the Global.asax Application_Error. It was "Ok" but not very flexible nor configurable.
We switched recently to NLog. It's much more configurable, we can define different targets for the errors, filter them, buffer them (not tried yet). It's a very good improvement.
But I discovered lately that there's a whole Namespace in the .Net framework for this purpose : System.Web.Management and it can be configured in the healthMonitoring section of web.config.
Have you ever worked with .Net health monitoring? What is your solution for error logging?
I use elmah. It has some really nice features and here is a CodeProject article on it. I think the StackOverflow team uses elmah also!
I've been using Log4net, configured to email details of fatal errors. It's also set up to log everything to a log file, which is invaluable when trying to debug problems. The other benefit is that if that standard functionality doesn't do what you want it to, it's fairly easy to write a custom appender which can process the logging information as required.
Having said that, I'm using this in tandem with a custom error handler which sends out a html email with a bit more information than is included in the standard log4net emails - page, session variables, cookies, http server variables, etc.
These are both wired up in the Application_OnError event, where the exception is logged as a fatal exception in log4net (which then causes it to be emailed to a specified email address), and also handled using the custom error handler.
First heard about Elmah from the Coding Horror blog entry, Crash Responsibly, and although it looks promising I'm yet to implement it any projects.
I've been using the Enterprise Library's Logging objects. It allows you to have different types of logging (flat file, e-mail, and/or database). It's pretty customizable and has a pretty good interface for updating your web.config for the configuration of the logging. Usually I call my logging from the On Error in the Global.asax.
Here's a link to the MSDN
I use log4net and where ever I expect an exception I log it to the appropriate level. I tend not to re-throw the exception because it doesn't really allow for as-nice user experience, there is less info you can provide at the current state.
I'll have Application_Error also configured to catch any exception which was not expected and the error is logged as a Fatal priority through log4net (well, 404's are detected and logged as Info as they aren't that high severity).
My team uses log4net from Apache. It's pretty lightweight and easy to setup. Best of all, it's completely configurable from the web.config file, so once you've got the hooks in your code setup, you can completely change the way logging is done just by changing the web.config file.
log4net supports logging to a wide variety of locations - database, email, text file, Windows event log, etc. My team has it configured to send detailed error information to a database, and also send an email to the entire team with enough information for us to determine in which part of the code the error originated. Then we know who is responsible for that piece of code, and they can go to the database to get more detailed information.
I recently built an asp.net webservice with NLog, which I use for all my desktop apps. The logging works fine when I'm debugging in Visual Studio, but as soon as I switch to IIS the log file isn't created; I've not yet determined why, but it the fact that I need to look for a solution makes me want to try something else for my asp.net needs!
We use EnterpriseLibrary.ExceptionHandling.Logging. I like it a bit better than log4net because not only do we control the logging completely, but we can control the Throw/NoThrow decision within config as well.
We use a custom homegrown logging util we wrote. It requires you to implement logging on your own everywhere you need it. But, it also allows you to capture a lot more than just the exception.
For example our code would look like this:
Try
Dim p as New Person()
p.Name = "Joe"
p.Age = 30
Catch ex as Exception
Log.LogException(ex,"Err creating person and assigning name/age")
Throw ex
End Try
This way our logger will write all the info we need to a SQL database. We have email alerts set up at the DB level to look for certain errors or frequently occurring errors. It helps us identify exactly where the errors are coming from.
This might not be exactly what you're looking for. Another approach similar to using Global.asax is to us a code injection technique like AOP with PostSharp. This allows you to inject custom code at the beginning and end of every method or on every exception. It's an interesting approach but I believe it may have a heavy performance overhead.