Admin: RPI Realtime
Overview
RPI Realtime consists of the following:
RPI Realtime http://ASP.NET application.
RPI Realtime Agent http://ASP.NET application: used by RPI Realtime to communicate with the RPI data warehouse and operational databases.
RPI’s relationship with a client’s website is discussed in the Redpoint Interaction Realtime section of the RPI User Guide. To summarize briefly, an integration between RPI and a public website can take place in the following contexts:
Landing pages can be created in RPI and published to a website.
Web forms can be included in landing pages, which, when completed and submitted by a site visitor, can serve as a useful data capture tool.
An outbound RPI communication (e.g. an email offer) can contain a link to a landing or other web page, and results can be collated in respect of visitors’ behavior at the same and presented in the context of the outbound offer activity within an interaction.
In the same context, a target web page can contain dynamic content, which can be varied in accordance with the known visitor’s characteristics.
Realtime decisions can be used to personalize content in a dynamic asset hosted in a landing or other web page. Such personalization can be effected on several bases – e.g., the visitor’s browser, location, time of day, current weather conditions or, if a known visitor, her or his attribute values.
Goals, such as the clicking of a link or the submission of a web form, can be defined within a landing page, and visitor’s attainment of the same can be monitored as conversion rates.
Goal driven assets can be used to effect A/B/n testing within a website, with the results of the initial presentation to visitors of random pieces of content being analyzed statistically to determine the most efficacious piece of content in encouraging goal attainment. The winning content can then be served to subsequent visitors.
The RPI Realtime application is available in the following subfolders in the RPI DeploymentFiles folder:
InteractionRealtimeAPI: the files within this folder should be used to install RPI Realtime in a Microsoft .NET Framework environment. Realtime web service configuration settings are managed in the appsettings.json.config file.
InteractionRealtimeAgent
To set up RPI Realtime, the following pre-requisites must exist for each client that intends to use RPI Realtime:
A public-facing web server.
An RPI Realtime website.
The public-facing website that hosts RPI landing pages, and the RPI Realtime website, which facilitates e.g., Realtime decisions, web events, web form processing, must be hosted separately, and not combined into a single website.
The following illustrates the logical relationship between the components of RPI Realtime:
Installing RPI Realtime – Microsoft .NET Framework
To install RPI Realtime under the .NET Framework, please follow these steps for each client:
Copy the contents of DeploymentFiles\InteractionRealtimeAPI into the RPI Realtime website’s root folder.
In RPI’s Configuration Workbench, open the System Configuration interface, and set configuration setting RealtimeAPIAddress set to the RPI Realtime website’s full URL.
Follow instructions in the sections below to configure the following. Note that it is only necessary to undertake configuration in the areas that support relevant functionality; for example, if you wish to use landing pages, but not Realtime decisions, you only need to follow the instructions in the Web events section.
Web events: used the following contexts:
RPI landing pages.
Collation of state and metric information relating to visitors’ behavior at a website, to which directed in an outbound communication.
Tracking of goals.
Web forms
Realtime decisions
For added security, at the RPI Realtime website’s web.config file, locate setting Access_Control_Allow_Origin. Change the “*” value to the landing page website address.
Configuration of the RPI Realtime website is carried out using settings defined in the appsettings.json.config file. Please see here for more information.
If required, you can generate an appsettings.json.config file from the Server Workbench’s Realtime Profiles tab. Please see here for more information.
appsettings.json Configuration File
The appsettings.json.config file is used to manage RPI Realtime website settings.
Note that, on saving changes made within the file, an IIS restart is not required unless made within the Logging section.
Properties are exposed in sections within the file as follows:
AppSettings
RPIAuthToken: authorization token used when connecting to the RPI Realtime API. Note that this setting’s default value should be changed to a fresh GUID at RPI Realtime installation.
RPIClientID: the ID (GUID) of the RPI client the Realtime API engine is associated with. The client ID can be obtained from Server Workbench.
RealtimeAgentAddress: the address of the RPI Realtime Agent service, which is used by RPI Realtime to communicate with the RPI data warehouse and operational database.
RealtimeAgentAuthToken: authorization token to be used by the RPI Realtime API when connecting to the Realtime Agent. Note that this setting’s default value should be changed to a fresh GUID at RPI Realtime installation.
ThresholdBetweenPageVisitsMinutes: defines the time, in minutes, after which a visitor's visiting a previously-visited web page will be deemed a new visit.
MessageDaysExpiry: the number of days after which entries in a visitor's message history will expire.
CacheWebFormData: defines whether to persist submitted web form data in a visitor's profile.
CachedAttributeLoadTimeoutMS: the time, in milliseconds, after which RPI Realtime will time out when attempting to load data from the data warehouse into the realtime cache. If a call times out, the retrieval will be performed asynchronously. A value of 0 indicates that no timeout will be applied.
MessageHistoryRefreshIntervalMinutes: defines the period, in minutes, after which a visitor's cached message history will be refreshed from the data warehouse.
EnableHelpPages: controls whether documentation will be made available at the RPI Realtime API website.
NoDaysPersistWebEvents: the length of time, in days, for which web events data will be persisted in a visitor's profile.
NoMinsCacheSelectionResults: the time period, in minutes, for which the results of selection rules, executed in the context of selection rule realtime decisions, are persisted.
RedpointMLServiceAddress: the address of the Redpoint Machine Learning service.
OverrideMinThreadPoolSize: facilitates specification of a minimum thread pool size different to the default setting.
MinThreadPoolSizeOverride: used in conjunction with the setting above; specifies the overridden minimum thread pool size.
ParameterToDataMappings: facilitates the mapping of querystring parameters to cached attribute list lookup keys, as per the following example:
JSON"ParameterToDataMappings": [ { "ParameterName": "Email", "CALName": "CAL01" }, { "ParameterName": "Employee", "CALName": "CachedTable01" }, { "ParameterName": "CustomerKey", "CALName": "Cassandra" } ]HashVisitorID: if set to True, visitor IDs as returned from the Realtime API are hashed and therefore obfuscated.
CacheOutputExclusions: allows for the specification of a series of parameters that are not output when cache data is written to the database or file.
CheckForProfileUpdatesOnSave: if True, a check will be performed to ensure that no intervening changes have occurred when a visitor profile is updated.
MessageHistoryProfileRecordLimit: allows the maximum number of message history records per visitor that can be stored in the visitor profile to be defined.
MessageHistoryDaysInProfile: controls the length of time for which message history data can be stored in the visitor profile.
RealtimeServerCookieEnabled: specifies whether or not server-side cookies are enabled for RPI Realtime. Defaults to False.
RealtimeServerCookieHttpOnly: specifies whether or not the server-side visitor cookie will be set using the HTTPOnly parameter. When set to true, the cookie will be inaccessible to web browsers through JavaScript. Defaults to False.
RealtimeServerCookieName: specifies the name of the server-side visitor cookie. Defaults to 'rg-visitor'.
RealtimeServerCookieExpires: specifies the number of days that the cookie expiration will be set for. Defaults to 60
RealtimeServerCookieDomain: specifies the domain that the cookie will be set for. Default is blank. When blank, the cookie domain will be set using the FQDN that the Realtime request was made on.
CORSOrigins: specifies the valid domain names that can make requests to Realtime. Default is an empty list. When empty, RPI Realtime will uses the value sent in the origin header of the request in its CORS response header.
CacheOutputCollectIPAddress: controls whether visitor IP addresses are stored in the RPI_WebDevices table.
RealtimeAgentInProcessEnabled: when set to True, the RPI Realtime Agent will run inprocess. For more information, please see elsewhere in the Admin Guide.
SaveProfilePostDecisionResponse: this setting defaults to False. When false, visitor profile changes are saved using the main RPI Realtime execution thread, prior to return of results. When true, visitor profile changes are saved using a separate execution thread.
ThresholdBetweenSiteVisitsMinutes: defines period after which a visit to a previouslyvisited site by a given visitor is considered a new visit.
NoMinsCacheRecommendResults: defines the length of time, in minutes, for which recommendation results are stored in a visitor’s profile.
EnableProfileMergeEvents: if this setting is set to true, a ProfileMerge event is raised on the merging of two visitor profiles.
TrackProfileMergeInSourceProfile: if this setting is set to true, when two profiles are merged, the profile from which merged is updated with the merge details.
MaxNoEventMetadataInstances
EnableAuditMetricsInHeaders: this setting enables or disables the output of audit trace information in endpoints' response headers. By default, it is set to False. When enabled, the following audit headers are made available:
RPI-SmartAssets: the number of smart assets evaluated during the call o RPI-Rules: the number of rules evaluated during the call
RPI-DatabaseRules: the number of rules executed involving database execution via the Realtime Agent during the call o RPI-Cals: the number of cached attribute list lookups performed during the call o RPI-Models: the number of AML predictions made during the call o RPI-MergeProfile: the number of visitor profile merges made during the call
RPI-RecLookup: the number of recommender field lookups made to directly fetch fields from a database table or value list during the call
RPI-RecTableLoad: the number of recommender field table loads made to cache recommender fields in the Realtime cache during the call
RPI-Context: any layout or area Realtime context path used for smart asset evaluation during the call o RPI-View: any view name requested during the call
RPI-StartTime o RPI-EndTime
DecisionCacheDuration: this setting controls the number of seconds for which smart asset logic is stored in memory. It is set to 5 seconds by default. If set to 0, logic is not cached.
WebVisitorCacheDuration: controls the number of seconds for which visitor profiles are cached in memory. This feature is designed to increase the performance of operations upon visitor profiles, as it reduces the number of calls to the realtime cache. It should only be used in environments where only a single system is interacting with a particular visitor profile at a time, and, in the case of a multi-node RPI Realtime setup, the load balancer should have sticky sessions enabled.
EventDaysToPersistOverride: facilitates the setting of a separate expiry date duration for a visitor's web events key.
When server-side cookies are enabled, RPI will set a server-side cookie that contains visitor and device IDs for a request. For every incoming request, if the visitor and/or device IDs specified in the request do not match the server side values, the service will override the values sent in with the request with the values from the server-side cookie. The response will include the updated visitor and device IDs and the consuming application will need to handle that appropriately. The Realtime Web Client (JavaScript SDK) will automatically pick up this change and set the client-side visitor cookie appropriately.
Queues
FormQueuePath: the path of the queue used to manage web form submissions.
EventsQueuePath: the path of the queue used to manage the processing of web events
CacheOutputQueueEnabled: controls whether visitor profile changes are sent to the queue defined in WebCacheQueuePath.
CacheOutputQueuePath: the path of the queue used to process visitor profile data.
RecommendationsQueuePath: the path of the queue used to manage RPI Realtime recommendations.
ClientQueueSettings: facilitates definition of the queue technologies to be used by RPI Realtime. In this example, queues are hosted by the Microsoft Azure Service Bus provider:
JSON{ "ClientQueueSettings": { "Assembly": "Redpoint.Resonance.AzureQueueAccess", "Type": "Redpoint.Resonance.AzureQueueAccess.AzureServiceBusQueueFactory", "Settings": [ { "Key": "xxx", "Value": "Endpoint=sb://xxx.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=xxx" } ] } }ListenerQueuePath: path of the Listener queue. For more information, please see the Queue Listener section within the Interaction Designer documentation.
ListenerQueueSettings: facilitates definition of the queue technology to be used to host the Listener queue.
IdentitySettings
MasterKeyName: the name of the primary attribute used to key entries in a known visitor's profile.
MasterKeyAliases: aliases by which the master key can be referenced.
AlternativeKeys: alternative keys by which a known visitor's profile can be indexed.
IdentityParameters: facilitates the mapping of a visitor profile data parameter to a key in the data warehouse.
The following settings control whether profile parametervalues/database values are to be merged on the occurrence of a ProfileMerge event. They provide for more granular control of the data that is carried over when a Realtime visitor moves from an anonymous to a known state
MergeParameters
MergeCALAttributes
ParameterMergeExclusions (array)
CALMergeExclusions (array)
CacheSettings
Caches: facilitates definition of the cache technologies to be used by RPI Realtime. In this example, caches could be hosted using the Azure Redis and Cassandra providers:
JSON{ "Caches": [ { "Name": "AzureRedis", "Assembly": "Redpoint.Resonance.AzureRedisCache", "Class": "Redpoint.Resonance.AzureRedisCache.AzureRedisCacheHandler", "Settings": [ { "Key": "ConnectionString", "Value": "rpidevjh.redis.cache.windows.net:6380,password=QbFkhPcomFWoeOGOvsJihUAW/eguwAhZVX1jffeU04c=,ssl=True,abortConnect=False" } ] }, { "Name": "Cassandra", "Assembly": "Redpoint.Resonance.Web.Shared", "Class": "Redpoint.Resonance.Web.Shared.Cache.DatabaseCache", "Settings": [ { "Key": "ClientID", "Value": "D2A8B022-E87E-45E4-B9CD-3FC5809FD9C8" }, { "Key": "DatabaseID", "Value": "45E3C456-B8D4-4EA0-9496-BD24AA4FD842" } ] } ] }DataMaps: allows you to specify which cache providers are to be used in which contexts by RPI Realtime. Data of the following types can be stored in separate caches:
Visitor profile (profile, parameter value and database values)
Visitor history
Non-visitor data (e.g. published Realtime decisions and landing pages)
Product Recommendations
Visitor Backup: allows you to define a secondary backup cache, to which visitor profile data will be written automatically. When a visitor record is removed from the main cache and a parallel visitor cache has been configured, on the visitor profile’s being loaded, the missing record is repopulated in the main cache from the parallel cache.
Message History: this cache type is supported at the MongoDB, Couchbase and Database cache providers only. It allows for the configuration of a separate cache to persist visitors' message history (as served by advanced smart assets).
Visitor Readonly Parameters: this cache is typically populated by external processes. When the visitor profile is loaded into memory, the visitor profile and visitor readonly parameters are loaded in parallel and merged. Visitor readonly parameters can be leveraged in Realtime decisions (the use of attribute list decisions is recommended), but you cannot include them within personalized content.
If a parameter is present in both, the visitor readonly parameter value takes precedence. If the visitor profile and visitor readonly parameters are hosted in the same physical cache, a datamap KeySetting setting is used to avoid key clashes; the key is set to '[Key value]+[KeySetting]'.
The DataMaps section allows you to specify which of the configured cache providers is to be used to support each type of cache. In addition, it allows you to specify the number of days for which data is to be persisted at each cache, as well as to whether data should be compressed when stored in a cache (note that a Cache Decompression utility is available to facilitate viewing compressed data; details can be found here). Caching data will reduce the size of the profile in the cache and improve performance persisting to remote caches. There is a performance impact compressing and decompressing profiles; if the cache is local then performance may be improved by switching off compression.
The ability to use separate caches and disparate technologies facilitates attainment of an optimal balance between data durability and performance.
In this example, the Cassandra database cache configured above is used to persist visitor history data; the aforementioned Azure Redis cache is used to hold all other types of cache data:
{
"DataMaps": [
{
"Type": "Visitor Profile",
"Cache": "AzureRedis",
"DaysToPersist": 28,
"CompressData": "False"
},
{
"Type": "Visitor History",
"Cache": "Cassandra",
"DaysToPersist": 28,
"CompressData": "False"
},
{
"Type": "Non Visitor Data",
"Cache": "AzureRedis",
"DaysToPersist": 365,
"CompressData": "False"
},
{
"Type": "Product Recommendations",
"Cache": "AzureRedis",
"DaysToPersist": 365,
"CompressData": "False"
}
]
}ProductRecommentations
This section is used to configure one or more Product Recommendation endpoints at the current RPI Realtime installation.
The product recommendation endpoint allows you to perform lookups from the Realtime cache or data warehouse. This provides third party web pages or applications with the ability to perform personalization (e.g. to provide product recommendations).
The productRecommendations section can contain one or more productRecommendation nodes, as per the following example:
{
"ProductRecommendations": [
{
"Name": "Foo",
"ClientID": "xxx8b022-e87e-45e4-b9cd-3fc5809fdxxx",
"PersistLookupHash": "True",
"SendResponseToDatabase": "True",
"ResponseTableName": "ProductRecommendations",
"Lookup": [
{
"Type": "Table",
"ResponseName": "Response1",
"DatabaseID": "",
"SchemaName": "dbo",
"TableName": "ProdRecLookup",
"RefreshTriggerMinutes": 1,
"DefaultResponse": "",
"AdditionalFields": [
{
"Name": "Additional1",
"DefaultValue": ""
},
{
"Name": "Additional2",
"DefaultValue": ""
}
]
},
{
"Type": "Profile",
"ResponseName": "PersonalizedResponse",
"DBParameter": "MyResponse",
"DefaultResponse": "[{'ProductID': 'xxx'},{'ProductID': 'yyy'}]"
}
]
}
]
}The following documents the above:
productRecommendations: multiple product recommendations can be supported per RPI Realtime instance.
name: the name by which the productRecommendation will be uniquely identified.
clientID: GUID value unique to the current RPI client.
persistLookupHash: this attribute defaults to False. If true, the lookup hash passed to the product recommendation endpoint will be persisted for a given visitor and used as a key for performing database lookups.
sendResponseToDatabase: this attribute controls whether a recommendation will be persisted at the data warehouse. If true, data will be written to the table defined by responseTableName, at execution of the Web events importer system task.
responseTableName: used in conjunction with sendResponseToDatabase. If that attribute is True, responseTableName is mandatory.
lookup: RPI Realtime supports the provision of multiple lookups within a product recommendation.
type: this attribute defines whether the lookup will be made from a database table
('Table'), or a visitor's profile ('Profile').responseName: this attribute represents the JSON attribute that contains the product recommendation response. If the lookup's type is Table, it also represents the field in the database table that holds the response.
databaseID: this attribute can be used to define whether the lookup should be made from the data warehouse (if set to blank), or from an auxiliary database (if set to a database's ID GUID).
refreshTriggerMinutes: for performance, the database lookup table is cached in the realtime cache. This attribute represents the period, in minutes, after which a refresh of the cached values will be triggered.
defaultResponse: in the case of the Table lookup, if a matching lookup hash is not supplied to the product recommendation service, the defaultResponse is returned. For a Profile lookup, if the database parameter is missing, the defaultResponse is returned
dbParameter: the name of the visitor profile database parameter that is used to persist the recommendation.
additionalFields: this node is used to persist details of additional JSON packet data as returned from a database ‘Table’ lookup. A default can be provided for each.
The product recommendation endpoint can be invoked using the following HTTP GET call:
http://[server]/api/Recommendations/[visitorID]?
LookupHash=[value]
[&ReturnAll=true/false]
[&recommendationName=name]
[&LogEvent=true/false]Where the above reference the following:
visitorID: the visitor’s unique Realtime cache key.
LookupHash: a value used as the key when performing the lookup.
ReturnAll: if set to True, all of the product recommendation’s lookups will be returned.
recommendationName: if the name of the specific product recommendation to be called. If blank, the first is invoked.
LogEvent: facilitates overriding of productRecommendation setting sendResponseToDatabase.
Plugins
The Plugins section is used to record details of the pre- and post-processing plugins configured at the current RPI installation.
Pre-processing plugins can be used to manipulate visitor profiles prior to a call being made for a Realtime decision content.
A pre-processing plugin is defined as per the following example:
{
"Name": "PreProcessing",
"Factory": {
"Assembly": "Redpoint.Resonance.Web.Shared",
"Type": "Redpoint.Resonance.Web.Shared.Plugins.PreDecisionExampleFactory"
},
"Type": {
"Name": "Predecision",
"ApiContentFilterOperator": "Include",
"ApiContextFilters": [
"PrePluginTest"
]
},
"Settings": [
{
"Key": "Param",
"Value": "Foo"
}
]
}The value passed in an API call's apiContext property is used to determine whether a pre-processing plugin is to be applied. You can specify multiple comma-delimited values in a list. apiContentFilterOperator is used to Include or Exclude whether a preprocessing plugin is to be invoked.
For example, if a value passed in apiContext when an API call is made matches a value in the web config setting ‘apiContextFilter’, and apiContentFilterOperator is set to Include, pre-processing plugin functionality will be called. The functionality would not be called if apiContentFilterOperator was set to Exclude.
Post-processing plugins are defined as per the following example:
JSON{ "Name": "PostProcessingExample", "Factory": { "Assembly": "Redpoint.Resonance.Web.Shared", "Type": "Redpoint.Resonance.Web.Shared.Plugins.PostDecisionExampleFactory" }, "Settings": [ { "Key": "Prefix", "Value": "pre " }, { "Key": "Suffix", "Value": "post" } ] }For more information, please see the RealtimeContentPlugins configuration setting, and Realtime dynamic asset/goal driven asset/inbound message list documentation elsewhere in the User Guide.
Web form processing plugins can be used to manipulate data received during web form submission.
CODE{ "Name": "FormProcessing", "Factory": { "Assembly": "Redpoint.Resonance.Web.Shared", "Type": "Redpoint.Resonance.Web.Shared.Plugins.FormProcessingExampleFactory" }, "Settings": [ { "Key": "PluginField1", "Value": "Rhubarb" }, { "Key": "PluginField2", "Value": "Custard" } ] }Geolocation functionality can be provided by geolocation plugins:
JSON{ "GeolocationSettings": { "Provider": "My geo provider", "APIKey": "", "WeatherUnits": "Metric", "CoordsCacheTimespanMinutes": 10, "PluginAssembly": "RedPoint.Resonance.Web.Shared", "PluginType": "RedPoint.Resonance.Web.Shared.Plugins.GeolocationExamplePlugin", "PluginSettings": [] } }
VisitorViews
Visitor views can be used to define the attributes of a site visitor that can be retrieved using the Visitor Views RPI Realtime API endpoint. An example VisitorViews section is provided below:
{
"VisitorViews": [
{
"Name": "ViewA",
"ParameterNames": [
"Stringie",
"DMTitle",
"TestParam"
],
"DatabaseFieldNames": [
"First Name",
"Yearly Income"
]
}
]
}QueueListenerConfiguration
This section defines the parameters to be sent to a queue listener. More detail is provided in the RPI Reference Guide. An example QueueListenerConfiguration section is provided below:
{
"QueueListenerConfiguration": [
{
"Name": "Default",
"SendAddressParameter": "EmailAddress",
"Parameters": [
"FirstName",
"LastName"
]
}
]
}IDValidationSettings
This section allows you to specify rules around the type of data values that are acceptable to be used as visitor and device identifiers. An example IDValidationSettings section is provided below:
{
"IDValidationSettings": {
"EnableVisitorIDValidation": true,
"VisitorID": {
"MinimumLength": 1,
"MaximumLength": 36,
"EnableLetters": true,
"EnableNumbers": true,
"PermittedCharacters": [
"-",
"_",
"/",
".",
"@",
"#",
"&",
"?"
]
},
"EnableDeviceIDValidation": true,
"DeviceID": {
"MinimumLength": 1,
"MaximumLength": 36,
"EnableLetters": true,
"EnableNumbers": true,
"PermittedCharacters": [
"-",
"_",
"/",
".",
"@",
"#",
"&",
"?"
]
}
}
}Logging
Logs can be written to a daily log file, defined in appsettings.json’s FileLogging section. E.g.:
{
"FileLogging": {
"LogDirectory": "C:\\Redpoint\\Web Processing\\Logs",
"FileName": "EntryLog_"
}
}Trace information can also be sent to other destinations as defined in the Logging section.
The level of logging detail can be set for each log destination. The options are:
None
Trace
Information
Warning
Error
You can reference environment variables at the LogDirectory and FileName settings; e.g.:
"LogDirectory": "C:\\RedPoint\\Web Processing\\Logs_[EnvironmentVariableName]"
The '[MachineName]' hard-coded variable is also supported in the same context.
For a .NET Framework deployment, logging to Azure and other sources requires configuration in both the appsettings.json and the web.config.
First, configure which level of information to set in the appsettings.json.config using the “SystemDiagnostics” element.
{
"SystemDiagnostics": {
"LogLevel": {
"Default": "Trace"
}
}
}Then set any destinations in the web.config “system.diagnostics” section.
<system.diagnostics>
<switches>
<!--( 0=Off, 1=Error, 2=Warning, 3=Info, 4=Verbose )-->
<add name="TraceLevel" value="2" />
<!--( 0=Off, 1=On )-->
</switches>
<trace autoflush="true">
<listeners>
<!--Use this to put trace messages to the event log-->
<!--<add name="eventLogListener"
type="System.Diagnostics.EventLogTraceListener"
initializeData="InteractionRealtime" />-->
<!--To use, you will need to add a trace element to System.Web. Log can be viewed at address /trace.axd-->
<!--<add name="WebPageTraceListener"
type="System.Web.WebPageTraceListener, System.Web,
Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />-->
</listeners>
</trace>
<sources>
</sources>
</system.diagnostics>