Configuring User Name and Business Context

As part of detailed diagnosis, eG .NET BTM displays two columns, namely - User Name and Business Context. By default, these two columns will not display any values. This has been done so that administrators can use these columns to display any additional information that they deem useful for troubleshooting transaction slowness. For instance, administrators can configure eG Enterprise to capture the name of the user who initiated each transaction and display the same in the User Name column for every transaction URL in the Detailed Diagnosis page. Likewise, administrators can also tweak eG Enterprise to capture and display information such as fetch type, class name, method name, method signature, session attribute name, URL pattern, etc. against Business Context. Such custom information can also be captured for specific transaction URLs or URL patterns alone.

To achieve this, follow the steps below:

1. Edit the eg_DotNetBTM.ini file in the <EG_AGENT_INSTALL_DIR>\config directory.

2. First, you need to indicate the web sites for which this capability should be enabled - i.e., the web sites for which the detailed diagnosis should include the user name and/or business context. For that, first create a new section in the eg_DotNetBTM.ini file. The name of this section should be of the following format:

   [<AppPoolName>_APConf]

   Here, the <AppPoolName> is the name of the application pool to which the target web sites belong. For instance, for web sites that belong to the application pool named Contoso, you can create a section named [Contoso_APConf]. If the target web sites belong to different application pools, then, you will have to create a section per application pool.

3. Under each application pool-specific section, provide an entry of the following format:

   DATA_COLL=<WebSite1>|~|<WebSite2>|~|<WebSite3>|~|. . . . . .

   Against the DATA_COLL parameter, provide a list of web sites that belong to that application pool after which the section is named. For instance, against the DATA_COLL parameter under the section [Contoso_APConf], you need to specify the list of web sites that belong to the Contoso application pool. Note that you can configure the profiler to collect and display user name and/or business context in the detailed diagnosis of these web sites only. Each web site should be separated by |~|. A sample DATA_COLL specification is given below:

   DATA_COLL=eazykart|~|retailbanking|~|bookatrip|~|

4. Next, create a section for every web site that is specified against DATA_COLL. Each of these sections should be named in the following format:

   [<SiteName>_DC]

   Here, <SiteName> refers to the name of a web site that has been configured against the DATA_COLL parameter. For example, if the site name is bookatrip, then the section name should be [bookatrip_DC].

   Under each site-specific section, you have to configure the following:

   • The approach you want to use for fetching the user name and/or business context values for that web site;

   • The implementation logic of that approach.

   The following approaches are available:

   • The user name and/or business context can be read from the input arguments of an application method
   • You can retrieve the user name and/or business context from URL parameters
   • You can have the .NET Profiler execute a static function, which returns the user name and/or business context values

   • The user name and/or business context can be fetched from session attributes

   The contents of the site-specific section depends upon the approach you choose. The topics below discuss each of these approaches in great detail.

Reading the Values from Existing Application Method's Arguments

If the target web site/web application supports one/more methods that take the user name and/or business context values as input parameters/arguments, then you can configure the details of such methods and arguments in the site-specific section.

The format of this configuration is as follows:

[<SiteName1>_DC]

INFO_P1=<DC TYPE>,<ARG to Read>,<Fully Qualified(FQ) Class Name>,<Method name>,<Arg1 Data Type>,<Arg2 Data Type>,<Arg3 Data Type>|~|<DC TYPE>,<ARG to Read>,<Fully Qualified Class Name>,<Method name>,<Arg1 Data Type>,<Arg2 Data Type>,<Arg3 Data Type>|~|

The placeholders that are included in the above specification are explained below:

• <SiteName1> - This refers to the name of the web site/web application for which the user name and/or business context is to be obtained.
• <DC TYPE> - Indicate the data you want to collect - user name or business context. If its user name, then specify 1. If its business context, specify 2.
• <ARG to Read> - Specify the input argument that has to be read to obtain the user name or business context. This takes a numeric value between 1 and 3, indicating whether it is the 1st, 2nd, or 3rd argument that has to be read. For instance, if the first argument is to be read, then specify 1 in the place of <ARG to Read>.
• <Fully Qualified(FQ) Class Name> - Enter the fully qualified name of the class file in which the application method(s) has been declared.
• <Method name> - Specify the application method that takes the input argument from which the user name or business context can be gleaned.
• <Arg1 Data Type>,<Arg2 Data Type>,<Arg3 Data Type> - Enter the data type of the first three input arguments of the given <Method name> takes. For instance - System.String,System.Int,System.String. This is required where functional loading is practiced. In other words, if the target web site/web application supports two/more methods with the same name, then the data type of the input arguments can help the .NET profiler identify the correct method for data collection. If the method takes less than 3 arguments, then enter the data type for the available arguments, and leave the other arguments blank by typing '-' (hyphen)

Multiple such specifications can be configured against INFO_P1. Use |~| as the separator for these specifications. Ideally, each specification in the |~|-separated list should enable the collection of a specific type of information - for example, the first specification can be for obtaining the user name and the second can be for fetching the business context. Alternatively, you can have multiple specifications for obtaining the same type of information. For instance, you can have multiple specifications for obtaining the user name alone, with each specification pointing to a different method. In this case, the .NET profiler will read the specifications in the same sequence in which they have been provided here. If for any reason - say, owing to an incorrect <ARG to read> configuration - the first specification does not lead to the user name or business context , then the profiler will fetch the data using the second specification.

A sample site-specific configuration is provided below:

[bookatrip_DC]

INFO_P1=1,1,Namespace.Classname,GetMethod,System.String,-,-|~|2,3,Namespace.Class2,GetterMethod,System.String,System.Int,System.String|~|

The sample configuration consists of two specifications. The details of both these specifications are provided below:

Specification 1 Here: <DC TYPE> is 1; this means that the first specification seeks to obtain the user name. <ARG to Read> is 1; this means that the user name has to be read from first input argument of the specified application method. NameSpace.Classname is the <Fully Qualified(FQ) Class Name> to which the application method belongs GetMethod is the <MethodName>; the username information is to be obtained from the first input argument of this method GetMethod takes a single input parameter. The data type of this parameter is String. This is why, <Arg1 Data Type> is specified as System.String. The <Arg2 Data Type> and <Arg3 Data Type> configurations are left blank.

Specification 2 Here: <DC TYPE> is 2; this means that the second specification seeks to obtain the business context. <ARG to Read> is 3; this means that the business context has to be read from third input argument of the specified application method. NameSpace.Class2 is the <Fully Qualified(FQ) Class Name> to which the application method belongs GetterMethod is the <MethodName>; the business context is to be obtained from the third input argument of this method GetterMethod takes a three input parameters. The data type of the first parameter is String, the second is Integer, and the third is String again. This is why, <Arg1 Data Type>,<Arg2 Data Type>,and <Arg3 Data Type> are set as System.String, System.Int, and System.String.

Reading the Values from URL Parameters

The approach discussed earlier applies to all the .NET transactions that are monitored. This approach on the other hand applies to specific transaction URL patterns alone. Use this approach if you want the user name and/or business context to be read from specific parameter values passed to given transaction URL patterns.

To use this approach for a web site, your site-specific section should include a specification of the following format:

[<SiteName1>_DC]

INFO_P2=<DC TYPE>,<URL Pattern>,<Param Name>|~|<DC TYPE>,<URL Pattern>,<Param Name>|~|

The placeholders that are included in the above specification are explained below:

• <SiteName1> - This refers to the name of the web site/web application for which the user name and/or business context is to be obtained.
• <DC TYPE> - Indicate the type of data you want to collect - user name or business context. If its user name, then specify 1. If its business context, specify 2.
• <URL Pattern> - Specify the URL pattern to which this specification applies.
• <Param Name> - Specify the URL parameter, the value of which needs to be read to obtain the user name or business context.

Multiple such specifications can be configured against INFO_P2. Use |~| as the separator for these specifications. Ideally, each specification in the |~|-separated list should enable the collection of a specific type of information - for example, the first specification can be for obtaining the user name and the second can be for fetching the business context. Alternatively, you can have multiple specifications for obtaining the same type of information. For instance, you can have multiple specifications for obtaining the user name alone, where each specification applies to a different URL pattern.

You can also have multiple specifications for the same URL pattern, but pointing to different URL parameters. In this case, the .NET profiler will read the specifications in the same sequence in which they have been provided here. If for any reason - say, owing to an incorrect <Param> configuration - the first specification does not provide a user name or business context , then the profiler will fetch the data using the second specification.

A sample site-specific configuration is provided below:

[eazykart_DC]

INFO_P2=1,,*/paymentProcess*,paymentID|~|2,*/addtocart*,numofitems|~|

The sample configuration consists of two specifications. The details of both these specifications are provided below:

Specification 1 Here: <DC TYPE> is 1; this means that the first specification seeks to obtain the user name. <URL Pattern> is */paymentProcess*. This means that this specification applies to all URLs that contain the string 'paymentProcess'. <Param Name> is paymentID. The .NET Profiler will read the value of the parameter named paymentID in the URLs containing the string 'paymentProcess' to obtain the user name.

Specification 2 Here: <DC TYPE> is 2; this means that the second specification seeks to obtain the business context. <URL Pattern> is */addtocart*. This means that this specification applies to all URLs that contain the string 'addtocart'. <Param Name> is numofitems. The .NET Profiler will read the value of the parameter named numofitems in the URLs containing the string 'addtocart' to obtain the business context.

Reading the Values from the Output of a Static Method

You need to provide a static method that will return the user name and/or business context . The .NET BTM module will then call this method either at the beginning or end (as configured) of each transaction. The value returned by the method will be displayed as user name / business context (as the case may be).

Note:

The static method that you use for fetching the user name/business context should fulfill the following requirements:

• The method should NOT TAKE ANY ARGUMENTS

• The method should only return a String value.

A sample static method definition is given below:

public static String SampleStaticMethod() { return UserID.ToString(); }

To enable this capability, you have to configure a specification of the following format in a site-specific section.

[<SiteName1>_DC]

INFO_P3=<DC_TYPE>,<at Begin(1) or at End(2)>,<URL Pattern>,<Module Path>,<FQ Class name>,<Method name>|~|

The placeholders that are included in the above specification are explained below:

• <SiteName1> - This refers to the name of the web site/web application for which the user name and/or business context is to be obtained.
• <DC TYPE> - Indicate the type of data you want to collect - user name or business context. If its user name, then specify 1. If its business context, specify 2.
• <at Begin(1) or at End(2)> - Indicate when the .NET BTM module should call the static method - at the beginning of a transaction or at the end of it. Enter 1 to call the method at the beginning of the transaction and 2 to call the method at the end.
• <URL Pattern> - Specify the URL pattern to which this specification applies.
• <Module Path> - Specify the full path to the module - i.e., the DLL that contains the library files required for the static method to execute.
• <FQ Class name> - Specify the fully-qualified name of the class that contains the method declaration.
• <Method name> - Mention the name of the static method that the .NET profiler should call

Multiple such specifications can be configured against INFO_P3. Use |~| as the separator for these specifications. Ideally, each specification in the |~|-separated list should enable the collection of a specific type of information - for example, the first specification can be for obtaining the user name and the second can be for fetching the business context. Alternatively, you can have multiple specifications for obtaining the same type of information. For instance, you can have multiple specifications for obtaining the user name alone, where each specification applies to a different URL pattern.

You can also have multiple specifications for the same URL pattern, where each specification can invoke a different static method. In this case, the .NET profiler will read the specifications in the same sequence in which they have been provided here. If for any reason the first method does not return a user name or business context , then the profiler will fetch the data using the second method

A sample site-specific configuration is provided below:

[retailbanking_DC]

INFO_P3=1,2,*/userLogin*,C:\inetpub\wwwroot\application.dll,ClassSample.MyWebForm,MyFunction|~| 2,2,*/addbenef*,C:\inetpub\wwwroot\application1.dll,ClassSample1.MyWebForm,MyFunction2

 

The sample configuration consists of two specifications. The details of both these specifications are provided below:

Specification 1 Here: <DC TYPE> is 1; this means that the first specification seeks to obtain the user name. <at Begin(1) or at End(2)> is 2. This means that the .NET profiler will call the static method at the end of the transaction. <URL Pattern> is */userLogin*. This means that this specification applies to all URLs that contain the string userLogin. C:\inetpub\wwwroot\application.dll is the <Module path>. The .NET Profiler will use the library file, application.dll, stored in this path to call the static method. ClassSample.MyWebForm is the <FQ Class name>. This class contains the static method declaration. MyFunction is the method that the .NET profiler will call at the beginning of all transactions containing the string 'userlogin' to retrieve the user name.

Specification 2 Here: <DC TYPE> is 2; this means that the second specification seeks to obtain the business context. <at Begin(1) or at End(2)> is 2. This means that the .NET profiler will call the static method at the end of the transaction. <URL Pattern> is */addbenef*. This means that this specification applies to all URLs that contain the string 'addbenef'. C:\inetpub\wwwroot\application1.dll is the <Module path>. The .NET Profiler will use the library file, application1.dll, stored in this path to call the static method. ClassSample1.MyWebForm is the <FQ Class name>. This class contains the static method declaration. MyFunction2 is the method that the .NET profiler will call at the end of all transactions containing the string addbenef' to retrieve the business context.

Reading the Values from the Session Attributes

You can configure the .NET profiler to read the user name and/or business context from the values of specific session keys. To enable this capability, you have to configure a specification of the following format in a site-specific section.

[<SiteName1>_DC]

INFO_P4=<DC_TYPE>,<at Begin(1) or at End(2)>,<URL Pattern>,<Attribute Name(Key)>|~|

The placeholders that are included in the above specification are explained below:

• <SiteName1> - This refers to the name of the web site/web application for which the user name and/or business context is to be obtained.
• <DC TYPE> - Indicate the type of data you want to collect - user name or business context. If its user name, then specify 1. If its business context, specify 2.
• <at Begin(1) or at End(2)> - Indicate when the session attribute has to be read - at the beginning of a transaction or at the end of it. Enter 1 to read at the beginning of the transaction and 2 to read at the end.
• <URL Pattern> - Specify the URL pattern to which this specification applies.
• <Attribute Name (Key)> - Specify the session key, the value of which has to be read to collect the user name or business context.

Multiple such specifications can be configured against INFO_P4. Use |~| as the separator for these specifications. Ideally, each specification in the |~|-separated list should enable the collection of a specific type of information - for example, the first specification can be for obtaining the user name and the second can be for fetching the business context. Alternatively, you can have multiple specifications for obtaining the same type of information. For instance, you can have multiple specifications for obtaining the user name alone, where each specification applies to a different URL pattern.

You can also have multiple specifications for the same URL pattern, where each specification can read from a different session key. In this case, the .NET profiler will read the specifications in the same sequence in which they have been provided here. If for any reason the first key does not provide a user name or business context , then the profiler will fetch the data using the second key.

A sample site-specific configuration is provided below:

[bookatrip_DC]

INFO_P4=1,2,*/userLogin*,userName|~|1,2,*/userLogin*,userId

 

The sample configuration consists of two specifications. The details of both these specifications are provided below:

Specification 1 Here: <DC TYPE> is 1; this means that the first specification seeks to obtain the user name. <at Begin(1) or at End(2)> is 2. This means that the .NET profiler will read the value of the specified session key at the end of the transaction. <URL Pattern> is */userLogin*. This means that this specification applies to all URLs that contain the string userLogin. userName is the session key/attribute. The .NET profiler will read the value of this key/attribute to obtain the user name.

Specification 2 Here: <DC TYPE> is 1; this means that the second specification seeks to obtain the user name. <at Begin(1) or at End(2)> is 2. This means that the .NET profiler will read the value of the specified session key at the end of the transaction. <URL Pattern> is */userLogin*. This means that this specification applies to all URLs that contain the string 'userLogin'. userId is the session key/attribute. The .NET profiler will read the value of this key/attribute to obtain the user name.