This will make a complete clone of the index, notifications and all.

On the Profile page there is an “Enable Toggle” button which will enable/disable the account for message receiving.  If you disable the account and try to submit a test message on the Indexes page you will get a note saying your quota is met or the account in disabled.

This post will show a simple demo of Unified Logging.

1) Visit the site http://demo.unifiedlogging.com/

- This site uses Unified Logging for multiple things such as what paint was purchased and errors

- Click around a bit

2) Go to https://portal.unifiedlogging.com

- Log in as user: demo with password: demo_123!
- Look at the Messages that were sent in as a result of clicking around
- Review the Indexes and see how they work.  Add/modify indexes and then go click around more and see what happens.
- Look at the Trends

3) Download the code for Pedro’s Paint Shop and see how the magic works.

- Note that the sample is in .NET MVC and uses Tracing.
- The project uses the Unified Logging NuGet package and has the listener defined in the web.config

1) Test Drive Unified Logging with the demo HERE

2) Signup HERE

3) Review the posts on Indexes HERE

- You will probably circle back to these posts at a later time

4) Use It!  Start sending messages using a connector from the Use It! Page

- Remember that some of these connectors are available from other sources such as NuGet and WordPress.org

5) Learn more about connectors HERE

Posted on Linked:

The things you are talking about are many of the driving forces behind Unified Logging (http://www.unifiedlogging.com/) and let me explain why.

Yes adding an email notification with Enterprise Library is easy though if thousands of email “events” (could be errors) happen you get thousands of emails.  On top of that to change when an email is sent you have to go touch production to make the change.  Lastly, you may not be the only one who wants to be notified for specific events, say application support wants to be notified when a specific event happens every evening but you do not really care about that.

I’m a firm believer of disconnecting the notification configuration and notifications themselves from the application itself and let people get notified when they want to be notified.

I too use Enterprise Library 5 and since Unified Logging is not a logging framework but rather a bucket for your logging information it comes down to about 10 seconds or work to add the Unified Logging NuGet Package and the one line of configuration in the logging configuration for entlib (http://blog.unifiedlogging.com/getting-started-with-net-nuget-package/).  Don’t forget to add the listener to category sources in the entlib config.   Next setup a notification index (http://blog.unifiedlogging.com/indexes-102-notifications/ ), most likely adding a notification to the “error” index that is created for you will get you started.  Most .NET applications (though there are many connectors for many languages) will just use the trace listener that ships with the NuGet package and leverage the logging framework of their choice.

I would point out that you are not limited to one trace listener as it is a collection. I myself use the event log listener, Azure Diagnostics Listener, Unified Logging Listener, and a couple custom listeners.

It is also worth pointing out that order of listeners for a category source does sometime matter with entlib, if the Event Log listener throws (and it could) the other listeners for the category source will not process so it is best to put that listener last in the category sources.

First, let’s assume data is being cached from a SQL Azure database, though what is outlined in this post is applicable to other data stores as well. First off let’s outline what could go wrong.

1) The cache becomes unavailable (could be because of a variety of reasons)

2) The database become unavailable

There are many reasons for number one to happen and the easiest way to handle it is to fall back to retrieving from the database.  You can have code that looks something like the below:

public RealyCoolCacheItem GetRealyCoolCacheItem(string key)
{
     try
     {
          var cacheItem = GetCacheItem(key);

          if (cacheItem == null)
          {
               var reallyCoolItem = RetrieveReallyCoolCacheItemFromDb(key);

          if (reallyCoolItem != null)
          {
               DataCache.Put(key, reallyCoolItem, TimeSpan.FromHours(2));
          }

               return reallyCoolItem;
          }
          else
          {
               return (RealyCoolCacheItem)cacheItem.Value;
          }
     }
     catch (Exception ex)
     {
          //Log the Error
     }

     //Would end up here if working with the cache throws
     return RetrieveReallyCoolCacheItemFromDb(key);
}

The second situation of a database going down is a bit more interesting.  The common direction is to have a fail over database though this is a big stick for a simple problem.  The cache is used to read frequently used data.

The solution Unified Logging has implemented is to serialized cache data to blob storage each time it is retrieved from the database overwriting the existing blob if necessary.  If the retrieval from the database fails it then reads the last blob written and things keep working.  This is how the submission endpoints of Unified Logging keep up and running when these undesirable events occur.

private RealyCoolCacheItem RetrieveReallyCoolCacheItemFromDb()
{
     try
     {
          //Retrieve from DB HERE
          var reallyCoolDbItem = magicDb.GetReallyCoolItem();

          //Save the item to the secondary failover datastore
          //In this case the secondary store is blob storage
          // RetrieveReallyCoolCacheItemFromDb_Failover is a constant
          failover.Save(RetrieveReallyCoolCacheItemFromDb_Failover, reallyCoolDbItem);

          return reallyCoolDbItem;
     }
     catch (Exception ex)
     {
           //Log the error

          //The retrieval from the db has failed so get the item form the secondary datastore
          return failover.Retrieve<RealyCoolCacheItem>(RetrieveReallyCoolCacheItemFromDb_Failover);
     }
}

At this point you are probably saying, all well and good but what is “failover”.  It is a simple class which implements a simple interface which has Save and Retrieve.

public interface ICacheFailover
{
      void Save<T>(string key, T serializableObject) where T : class;

      T Retrieve<T>(string key) where T : class;
}

For the purpose of this post the code samples will be from the php connector.

1)  If you desire a certain format for your messages make sure you do it prior to sending the message

2)  To start building the request you will need

• create a hash of the content using your secret key
• headers for your access key
  • hash
  • content length
  • content type being application/json.

3)  Create the hash using your Secret Key (dots are for concatenation).  Note the false parameter on the sha1 function which will return a 40-character hexadecimal number.  Take note that the input format to create the hash is <message>|<secret key>

$validation_string = $message.”|”.UL_SECRETKEY;

$computed_hash = sha1( $validation_string , false );

4)  Json encode the message so it has the format {“Content”:”[your message]”}

$fields = array( ‘Content’ => $message );

$json_data = json_encode( $fields );

5)  Set the headers

curl_setopt( $ch, CURLOPT_HTTPHEADER,

array(‘Content-Type: application/json’,

‘Content-Length: ‘.strlen( $json_data ),

 ‘Authorization: ‘.UL_ACCESSKEY,

 ‘MD5: ‘.$computed_hash ) );

6)  Set the post data

curl_setopt( $ch, CURLOPT_POSTFIELDS, $json_data );

7)  Send the http request to your submission url

8)  Handle the response, a 201 means the http post was successful.

9) Feel free to reach out to support for help
Some things to consider

• Send asynchronously where possible
• If a 201 response is not received consider a retry
• Log locally as well as to Unified Logging

For a an example of a more robust connector look at the .NET Trace Listener implementation which sends everything async and has a retry queue if a message fails for some reason.

Enjoy!

Now, when you click on that link you will be taken in as a view only user and can only see messages, trends and regions.  You will know you are in view only mode if you see the green bar.

Why is this important?  The notification will likely be shared, either the email is forwarded or it is copied / pasted into a ticket.