MSE Logging Behavior

Topics: Technical Questions, Usage Scenarios
Oct 8, 2009 at 1:56 PM

I've been playing around with the BAM Behavior, and it is nice but I was wanting to log more than just the operational metrics.  I saw an assembly called Microsoft.MSE.Behaviors.Logging.dll in the MSE folder and started playing around with that.  I was able to create a policy that logs to the file system by using the assertion below.  Values for LogDirection can be Both, Request, or Response.  Values for LogMessagePartType include Body, Full, Header, None.  Other providers include MsmqLogProvider, SqlDBLogProvider, and SqlSSBLogProvider.  I'm working on getting the SqlDBLogProvider next...I just have to create a stored procedure that accepts the sql command submitting via Reflector.  When I have it finished I can post that too.  Hopefully someone finds the useful.

<log:LoggingBehaviorExtensionElement xmlns:log="clr-namespace:Microsoft.MSE.Behaviors.Logging;assembly=Microsoft.MSE.Behaviors.Logging" xmlns:prov="clr-namespace:Microsoft.MSE.Behaviors.Logging.Providers;assembly=Microsoft.MSE.Behaviors.Logging">
  <log:LoggingConfiguration>
    <log:LoggingConfiguration.IsEnabled>true</log:LoggingConfiguration.IsEnabled>
    <log:LoggingConfiguration.LogDirection>Both</log:LoggingConfiguration.LogDirection>
    <log:LoggingConfiguration.LogMessagePartType>Header</log:LoggingConfiguration.LogMessagePartType>
    <log:LoggingConfiguration.Provider>
        <prov:FileLogProvider>
            <prov:FileLogProvider.LogFile>c:\temp</prov:FileLogProvider.LogFile>
        </prov:FileLogProvider>
		
    </log:LoggingConfiguration.Provider>
  </log:LoggingConfiguration>
</log:LoggingBehaviorExtensionElement>

 

<log:LoggingBehaviorExtensionElement xmlns:log="clr-namespace:Microsoft.MSE.Behaviors.Logging;assembly=Microsoft.MSE.Behaviors.Logging" xmlns:prov="clr-namespace:Microsoft.MSE.Behaviors.Logging.Providers;assembly=Microsoft.MSE.Behaviors.Logging">
  <log:LoggingConfiguration>
    <log:LoggingConfiguration.IsEnabled>true</log:LoggingConfiguration.IsEnabled>
    <log:LoggingConfiguration.LogDirection>Both</log:LoggingConfiguration.LogDirection>
    <log:LoggingConfiguration.LogMessagePartType>Header</log:LoggingConfiguration.LogMessagePartType>
    <log:LoggingConfiguration.Provider>
        <prov:FileLogProvider>
            <prov:FileLogProvider.LogFile>c:\temp</prov:FileLogProvider.LogFile>
        </prov:FileLogProvider>
        
    </log:LoggingConfiguration.Provider>
  </log:LoggingConfiguration>
</log:LoggingBehaviorExtensionElement>
Oct 8, 2009 at 2:20 PM

Ok, here is what I did to get the SqlLogProvider working.  Again maybe someone will find this useful.

Created a database table:

CREATE TABLE [dbo].[MSELog](
	[MessageID] [nvarchar](128) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[ActivityID] [nvarchar](128) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[CallerName] [nvarchar](64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[CreationDateTime] [datetime] NULL,
	[EndpointUri] [nvarchar](128) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[InspectorLocation] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[MachineName] [nvarchar](64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[ProcessingTime] [int] NULL,
	[RequestMessageData] [nvarchar](max) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[ResponseMessageData] [nvarchar](max) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
	[IsFaultResponse] [bit] NULL
) ON [PRIMARY]

Created a simple stored procedure to insert data:

CREATE PROCEDURE InsertMSELoggingData 
	-- Add the parameters for the stored procedure here
	@MessageID as nvarchar(128) = null,
	@ActivityID as nvarchar(128) = null,
	@CallerName as nvarchar(64) =null,
	@CreationDateTime as datetime = null,
	@EndpointUri as nvarchar(128) = null,
	@InspectorLocation as nvarchar(50) = null,
	@MachineName as nvarchar(64) = null,
	@ProcessingTime as int = null,
	@RequestMessageData as nvarchar(max) = null,
	@ResponseMessageData as nvarchar(max) = null,
	@IsFaultResponse as bit = null

AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;

    -- Insert statements for procedure here
	INSERT INTO [MSE_REPOSITORY].[dbo].[MSELog]
           ([MessageID]
           ,[ActivityID]
           ,[CallerName]
           ,[CreationDateTime]
           ,[EndpointUri]
           ,[InspectorLocation]
           ,[MachineName]
           ,[ProcessingTime]
           ,[RequestMessageData]
           ,[ResponseMessageData]
           ,[IsFaultResponse])
     VALUES
           (@MessageID
           ,@ActivityID
           ,@CallerName
           ,@CreationDateTime
           ,@EndpointUri
           ,@InspectorLocation
           ,@MachineName
           ,@ProcessingTime
           ,@RequestMessageData
           ,@ResponseMessageData
           ,@IsFaultResponse)
END

And finally used the following XAML:

<log:LoggingBehaviorExtensionElement xmlns:log="clr-namespace:Microsoft.MSE.Behaviors.Logging;assembly=Microsoft.MSE.Behaviors.Logging" xmlns:prov="clr-namespace:Microsoft.MSE.Behaviors.Logging.Providers;assembly=Microsoft.MSE.Behaviors.Logging">
  <log:LoggingConfiguration>
    <log:LoggingConfiguration.IsEnabled>true</log:LoggingConfiguration.IsEnabled>
    <log:LoggingConfiguration.LogDirection>Both</log:LoggingConfiguration.LogDirection>
    <log:LoggingConfiguration.LogMessagePartType>Full</log:LoggingConfiguration.LogMessagePartType>
    <log:LoggingConfiguration.Provider>
        <prov:SqlDBLogProvider>
            <prov:SqlDBLogProvider.ConnectionString>Integrated Security=true;Data Source=dbhostname;Initial Catalog=MSELoggingDatabase</prov:SqlDBLogProvider.ConnectionString>
            <prov:SqlDBLogProvider.StoredProcedureName>InsertMSELoggingData</prov:SqlDBLogProvider.StoredProcedureName>
        </prov:SqlDBLogProvider>
		
    </log:LoggingConfiguration.Provider>
  </log:LoggingConfiguration>
</log:LoggingBehaviorExtensionElement>

 

Oct 9, 2009 at 8:27 AM

This interesting, I didn't realise that you could do this. We have built our own behaviour that does something similar, but we have a little more advance functionality, such as error masking (the primary reason we built the behaviour), and the ability to log certain elements for correlation, WS-addressing header flow, as well as strip away sensitive information before we log certain messages. Maybe we should have built on this instead?

 

When I looked at what we had built, I began to see parallels with BizTalk's HAT, and even the logging functionality in Dublin. A problem that might turn up in the future is how to link all these logs together for end-to-end tracing. We already have a plan to link them to BizTalk using pipeline components, but Dublin is as yet an unknown. I wonder if the guys behind MSE have thought about this?