Saitistika 4.0.Руководство разработчика.2005

Например, Structure.

3.Создать таблицу дополнительных параметров с именем EventParamsИмя. Например, EventParamsStructure. Таблица должна содержать поле ID – INT NOT NULL IDENTITY(1,1) и другие поля, которые будут содержать информацию о событии. После создания таблицы дать на нее права роли public как минимум на SELECT и INSERT.

4.Создать хранимую процедуру с именем Events_AddИмяParams. Например, Events_AddStructureParams. Набор параметров процедуры должен соответствовать набору полей таблицы EventParamsИмя. Кроме того, в процедуру нужно добавить дополнительный параметр @Frontoffice BIT. Если заранее известно, что процедура будет вызываться только на бэкофисе или только на фронтофисе, то можно задать значение по умолчанию для этого параметра, 0 или 1 соответственно. В начало хранимой процедуры вставить следующий код (для поддержки отключания логирования):

Затем написать команду INSERT INTO EventParamsИмя (...) VALUES (...), где вместо многоточий подставить список полей таблицы и соответствующих параметров хранимой процедуры. Завершить хранимую процедуру следует командой RETURN @@IDENTITY. После создания хранимой процедуры дать право на ее выполнение роли public.

5.Добавить запись в таблицу EventTypes, заполнив поля следующим образом:

a.Name – понятное для пользователя название типа события.

b.Type – уникальная двухсимвольная мнемоника типа события. Именно она в дальнейшем будет использоваться в ASP-скриптах.

c.AdditionalParamTable – вписать имя таблицы дополнительных параметров (EventParamsИмя).

d.AdditionalNameMap – написать формат вывода дополнительных параметров в соотвтествии с его описанием.

База данных

Диаграмма таблиц

Хранимые процедуры

Процедуры для подсистемы журналирования начинаются с Events_ и Sait_Events_, кроме процедур подсистемы статистики.

Классы

UML-диаграмма

CUserSession

-Class_Initialize() +Initialize() +get_IsGuest() +get_GuestClient() +get_SessionID()

+ChangeGuestToUser(in uID) +ChangeGuestToGuest(in cID) +FailPageLoad(in Description) -NewGuestClientID()

+ChangeGuestToAuthorized()

+ChangeGuestToCurrentUser() -WriteClientHook() -GetDomain() -WriteGuestSyncHook() +WriteHooks()

+EndPage() +get_UserID() -InternalGetUserID()

-SetCookieOnSession(in Name, in Value) -SetCookieForever(in Name, in Value) +GetCookie(in Name)

-get_EventStack() -let_EventStack(in Value) -PushEvent(in Value) -PopEvent() -AddSessionParams() +GoBack(in num) +GoTop() +GetLastParent()

+Attach(in EventID, in IsTopLevel, in Push)

+NewEvent(in EventType, in ObjectID, in ObjectType, in AdditionalParams, in StaticString, in Status, in Reserved, in IsTopLevel, in Push) +NewEventSS(in EventType, in ObjectID, in ObjectType, in AdditionalParams, in ErrorStr, in Status, in Reserved, in IsTopLevel, in Push) -SetPersonal(in Name, in Value)

-GetPersonal(in Name)

+PersonalAttach(in Name, in EventID, in Link, in Push) +PersonalLink(in Name, in EventID, in Push) +PersonalGet(in Name)

+PersonalNewParent(in Name, in EventType, in ObjectID, in ObjectType, in AdditionalParams, in StaticString, in Status, in Reserved, in Push) +PersonalNewParentSS(in Name, in EventType, in ObjectID, in ObjectType, in AdditionalParams, in ErrorStr, in Status, in Reserved, in Push) +PersonalNewChild(in Name, in EventType, in ObjectID, in ObjectType, in AdditionalParams, in StaticString, in Status, in Reserved, in Push)

+PersonalNewChildSS(in Name, in EventType, in ObjectID, in ObjectType, in AdditionalParams, in ErrorStr, in Status, in Reserved, in Push) -get_LastTime()

-let_LastTime(in DateAndTime) -StartNewSession() +get_TimeBeforeNewSession() +NewSessionIfNeeded() -GetRegistrationList() -SetRegistrationList(in aList) -GetRegListValue(in Index) -GetRegListCount() -AddRegListValue(in Value) -SiteName(in s)

-SiteEqual(in a1, in a2) +BuildRegistrationList(in id, in key) -WriteRegistrationHook() +RegAuthorize(in id, in key, in v)

Рисунок 19. UML-диаграмма классов подсистемы журналирования

Список классов

CUserSession

Подсистема статистики

Технически представляет собой производную подсистемы журналирования. Подсистема статистики служит для анализа и отображения пользователю в понятной форме данных, собранных подсистемой журналирования.

Логика работы

Фильтры и опции

В настройках системы можно установить фильтры для определения Intranet-пользователей и Intranet-адресов, а также настроить параметры страниц статистики по умолчанию.

Фильтр по Intranet-пользователям

Данный фильтр определяет группы, пользователи которых являются Intranet-пользователями, отдельные логины Intranet- пользователей, сайты для которых пользователи, попадающие под фильтры их авторизации, являются Intranet- пользователями, IP-адреса и маски Intranet-пользователей и ряд других параметров. Настройки этого фильтра хранятся в разных таблицах базы данных. Для получения текущего списка идентификаторов и логинов Intranet-пользователей согласно выбранным и введенным на странице настройки фильтра параметрам, не зависящим от IP-адреса пользователя, служит представление (VIEW) EventsIntranetLogins. Для точного определения, является ли пользователь, который произвел событие, Intranet-пользователем, следует учитывать его IP, записанный в таблице Events, а также настройку «Взаимная обработка IP- адресов и логинов».

Для облегчения построения запросов по выбору событий, произведенных только Internet- или только Intranet- пользователями, служит хранимая процедура Events_DynamicIntranetProcessing. Использование этой процедуры подразумевает построение динамического запроса к таблице Events, построенного по определенным правилам. Этот запрос затем комбинируется с куском SQL-запроса, возвращаемым процедурой, для построения условия, выбирающего записи для требуемых типов пользователей.

Порядок использования процедуры Events_DynamicIntranetProcessing при написании новой хранимой процедуры следующий:

1.Определяем переменную @SQL типа VARCHAR(8000), которая будет использоваться для построения динамического запроса: DECLARE @SQL VARCHAR(8000). Может потребоваться определение дополнительных переменных, значения которых затем будут комбинироваться для получения полного текста запроса.

2.Определяем переменную @IntranetSQL типа VARCHAR(2000): DECLARE @IntranetSQL VARCHAR(2000)

3.Формируем в переменной @SQL начало динамического запроса. Это запрос обязательно должен содержать SELECT … FROM Events e … LEFT JOIN EventsIntranetLogins el ON el.[ID] = e.UserID. Алиасы для таблицы Events и представления

EventsIntranetLogins могут быть любыми, но обязательно должны присутствовать. Условие «el.[ID] = e.UserID» здесь приведено для простоты, на самом деле оно может меняться в зависимости от других требований (т.е. параметров, выбранных пользователем на странице статистики). Например, сформируем начало запроса следующим образом: SET @SQL = 'SELECT EventID FROM Eevnts e LEFT JOIN EventsIntranetLogins el ON el.[ID] = e.UserID'. К этой строке можно добавлять «LEFT JOIN <какие-то другие таблицы> ON <другие условия>».

4.Вызываем процедуру Events_DynamicIntranetProcessing со следующими параметрами (перечислены по порядку): @EventTable – алиас таблицы Events в созданном в пункте 3 фрагменте запроса; @LoginTable – алиас таблицы EventsIntranetLogins в созданном в пункте 3 фрагменте запроса; @Internet – значение типа BIT, определяющее, следует ли выбирать события для Internet-пользователей; @Intranet – значение типа BIT, определяющее, следует ли выбирать события для Internet-пользователей; @WhereSQL – это OUTPUT-параметр, в который передаем созданную в пункте 2 переменную @IntranetSQL. Для нашего примера вызов будет следующий (если мы хотим выбрать записи только для

Intranet-пользователей): EXEC Events_DynamicIntranetProcessing 'e', 'el', 0, 1, @IntranetSQL OUTPUT. В результате выполнения процедуры в @IntranetSQL будет находиться SQL-условие, которое можно будет подставить в WHERE через AND. Следует отметить, что при комбинации @Intranet=0 и @Internet=0 будет возвращена строка '(1=0) ', в результате @Intranet=1 и @Internet=1 будет возвращено '(1=1)', а остальные две комбинации параметров дадут в результате два взаимно противоположных условия, одно из которых получается логическим отрицанием другого. Каждое возвращаемое условие будет заключено в скобки, так что его можно безопасно использовать в WHERE.

5.Логически складываем строки и выполняем запрос. В случае более сложных запросов можно добавить дополнительные условия. В нашем простом примере нужно выполнить следующую команду: EXEC(@SQL + ' WHERE ' + @IntranetSQL).

Пример сложного запроса с использованием описанной техники можно увидеть, например, в хранимой процедуре Events_GetEventLogFolders. В ней же можно посмотреть, какое условие должно реально стоять вместо «el.[ID] = e.UserID» (см. пункт 2).

Фильтр по Intranet-ссылкам

Этот фильтр во многом аналогичен предыдущему. Для использования его в динамических запросах служит хранимая процедура Events_DynamicLinkProcessing. Она имеет параметры: @EventTable – алиас для таблицы Eevnts в динамическом запросе; @Internet – значение типа BIT, определяющее, нужна ли статистика по Internet-пользователям; @Intranet – значение

типа BIT, определяющее, нужна ли статистика по Intranet-пользователям; @WhereSQL – это OUTPUT-параметр типа VARCHAR(2000), который также пожно использовать в WHERE, комбинируя с другими условиями через AND. Для использования возвращаемого SQL-условия в исходном SQL-запросе должно присутствовать только SELECT … FROM Events e, где e – любой алиас для таблицы Events.

Настройки по умолчанию для страниц отчетов

Настройки по умолчанию, заданыые на странице настроек журналирования и статистики, хранятся в таблице EventsLogViewDefaults. Для использования их на страницах отчетов следует воспользоваться классом CLogViewDefaults или

CParameterBlock.

Отчеты

На примере суммарного отчета «Внешние ссылки» покажем, как создавать новые суммарные отчеты. Логика суммарного отчета «Внешние сылки» находится в файле /aspscripts/eventlogs/summary-report-links.asp.

1.Все суммарные отчеты выводятся через один asp-файл (summary-report.asp). Для различия отчетов используется параметр mode, передаваемый через QueryString. Поэтому для нового отчета нужно придумать новое значение параметра mode. Для нашего отчета это «links».

2.Открываем файл /aspscripts/eventlog/summary-constants.asp. В определяемый в этом файле массив aTitles дописываем новый режим и название отчета: aTitles = Array( …, "links", "Внешние ссылки", … ). В массив aHints аналогичным образом дописываем новый режим и подсказку для него, выводимую на странице детальной статистики. В массив aFunctions дописываем режим и шаблонную строку ASP-кода, представляющую из себя вызов процедуры, производящей вызов отчета (сама процедура будет написана позже). В нашем примере это «ShowLinksReport ""%Sites%"", ""%Title%""». %Sites% при вызове процедуры заменяется на сайты для отображения статистики по ним (через точку), %Title% - на название текущего сайта, %% на %. ASP-код исполняется через вызов функции Execute. Процедура может вызываться невколько раз: по одному разу для каждого выбранного пользователем сайта и еще один раз, если выбран вариант «Все сайты». В том же файле в массив aComponents дописываем новый режим и список компонентов через точку. Более подробно формат списка компонентов и возможные значения описаны в комментарии в этом файле.

3.Создаем новую ASP-страницу с логикой для отчета. В нашем примере это summary-report-links.asp. Можно также добавлять функции на одну из существующих страниц суммарных отчетов, тогда пункт 4 выполнять не следует, но это не рекомендуется, т.к. снижает понятность кода. В код ASP-страницы добавляем процедуру, имя которой было указано в пункте 2 в массиве aFunctions (см. Sub ShowLinksReport (Sites, SiteTitle) в summary-report-links.asp). Реализуем требуемую логику. Для вывода Flash-графиков можно воспользоваться классом CFlashGraph. Также можно пользоваться стандартными вспомогательными функциями из файлов /aspscripts/eventlog/statistics/array-functions.asp и /aspscripts/eventlog/statistics/statistics-functions.asp.

4.В начало файла /aspscripts/eventlog/summary-functions.asp дописываем директиву #include для созданного в пункте 3

файла. В нашем примере это <!-- #include file=”summary-report-links.asp”-->

5.Обновляем навигацию на страницах /aspscripts/eventlog/summary-report.asp и /aspscripts/eventlog/summary-buildreport.asp.

База данных

Диаграмма таблиц

См. раздел «Подсистема журналирования»

Описания таблиц

См. «Подсистема журналирования»

Хранимые процедуры

Названия процедур этой подсистемы, начинаются с Events_Dynamic, Events_Get, Events_Log, Events_SummaryReport_.

Классы

UML-диаграмма

Подсистема кэширования

Логика работы

Кэширование реализовано в системе на разных уровнях – автоматическом и принудительном.

Автоматическое кэширование

Где реализовано: в объектах Configuration и SystemInfo.

Где применяется: для ускорения доступа к редко изменяемым системным переменным.

В объекте Configuration сохраняется:

1.имя базы данных SQL Server;

2.номер сервера в базе данных.

В объекте SystemInfo сохраняется:

1.Общие установки системы (домен бэкофиса, e-mail администратора бэкофиса, настройки SMTP-сервера);

2.Системные переменные сервера (идентификатор и название корневого раздела, домен, физический путь к файлам на диске, e-mail службы поддержки);

3.Идентификаторы, названия тем и имена файлов разделов сервера по-умолчанию.

При изменении системных настроек и свойств сервера кэш очищается автоматически.

Принудительное кэширование

Где реализовано: в объекте Cache.

Где применяется: для ускорения вывода динамических данных, хранящихся в базе, либо статических блоков. Кэширование этого типа также встроено в некоторые классы, применяемые в работе с объектами и списками объектов системы (материалы, разделы и т.д.).

При применении принудительного кэширования программисту нужно явно проверять, актуальность данных в кэше, и, при необходимости, перезагружать кэш. При просмотре страницы подсистема кэширования автоматически вычисляет ключ который определяет, какой именно вариант страницы нужно выбрать из кэша. Нулевое значение ключа означает, что данные в кэше устарели.

Ключ вычисляется на основе ряда параметров (идентификатор пользователя, принадлежность пользователя к той или иной группе и т.д.), согласно набору правил, определенных для кэша. Правила хранятся в базе данных и, для ускорения доступа, загружаются в системных кэш при первом вычислении ключа. Кроме правил при вычислении ключа используется набор исключений. Технически исключения - это те же правила, но они, в отличие от правил, задают условия, отменяющие кэширование страницы.

Кроме принудительного кэша на основе правил и исключений существует так называемый уникальный кэш. Он отличается от обычного тем, что новые варианты страницы генерируются по какому-либо заранее заданному условию (идентификатору пользователя или группы пользователей). Такой кэш применяется в случаях, когда трудно описать все варианты страницы при помощи правил и исключений, например на сильно персонализированных сайтах.

Необходимо помнить, что избыточное применение кэширования (особенно в случае большого количества вариантов кэша) приводит к увеличению расхода памяти сервера и является неэффективным.

Применение исполнимых инструкций

Появление типа правила «Исполнимая инструкция» вызвано неопределенностью (кроме простых случаев) набора типов правил, участвующих в выборе варианта кэша. Применение исполнимых инструкций позволяет гибко настроить логику работы кэша без исправления существующего кода. Таким образом, исполнимые инструкции – это часть программной

реализации зависимостей кэширования, управляемая пользователем из бэкофиса. При этом логику работы кэша можно настроить и при непосредственном программировании фронтофиса.

Пример реализации без использования исполнимых инструкций. Внешний вид навигации зависит от персональной настройки Navigator.ShowMenuPanels:

...

'Загрузить профиль 1. Cache.Load 1

'Получить номер удовлетворяющего варианта. Dim CacheKey : CacheKey = Cache.Key

'Сгенерировать уникальную строку. Dim Key

Key = "Navigator_" & IFolderID & "_" & Navigator.ShowMenuPanels & "_" & CacheKey

'Выполнить обычные операции по выборке/записи данных.

...

Пример реализации с использованием исполнимых инструкций. В профиле есть вариант, срабатывающий при

Navigator.ShowMenuPanels = 1 и есть вариант, срабатывающий при Navigator.ShowMenuPanels = 0:

...

'Загрузить профиль 2. Cache.Load 2

'Получить номер удовлетворяющего варианта. Dim CacheKey : CacheKey = Cache.Key

'Сгенерировать уникальный ключ кэша для хранения данных. Dim Key

Key = "Navigator_" & IFolderID & "_" & CacheKey

'Выполнить обычные операции по выборке/записи данных.

...

Эти два примера отличаются тем, что в первом примере логика зависимости от переменной Navigator.ShowMenuPanels находится в скрипте, а во втором примере эта логика вынесена в исполнимые инструкции.

Классы

Список классов

CCache

Примеры использования

Кэширование списка материалов

‘Загрузить настройку кэша 1 (из базы данных или системного кэша). Cache.Load 1

‘Сгенерировать ключ.

Dim CacheKey : CacheKey = Cache.Key

If Cache.Expired("ContentPage_" & FolderID & "_" & CacheKey) Or CacheKey = 0 Then

‘ Если содержимое материала устарело, прочитать его из базы и поместить в кэш. MaterialsList.GetInfoLite FolderID, UserInfo.UserID

If CacheKey <> 0 Then

MaterialsList.Store "ContentPage_" & FolderID & "_" & CacheKey, 300 End If

Else

‘ Иначе получить содержимое материала из кэша. MaterialsList.Fetch "ContentPage_" & FolderID & "_" & CacheKey

End If

Подсистема обработки ошибок

Предназначена для перехвата ошибочных ситуаций и оповещения о них пользователей и администратора в настраиваемом и унифицированном виде. Сообщения об ошибках могут выводиться пользователю на странице, отправляться администратору системы или сайта (на фронтофисе) по E-mail, а также записываться в журнал событий.

Логика работы

1.Обработка ошибочных ситуаций происходит на страницах /errors/error.asp в бэкофисе и error.asp текущей темы во фронтофисе. При этом обрабатываются следующие способы попадания на эту страницу:

1.1.Возникла ошибка, настроеная в IIS на эту страницу. В этом случае страница вызывается с параметрами: <номер ошибки>;<url страницы, вызвавшей ошибку>, например: error.asp?404;http://www.server.ru/unknown.asp. Таким

способом оповещения подсистемы управления ошибками об ошибочной ситуации можно воспользоваться при программировании внешних модулей, сделав редирект на error.asp с соответствующими параметрами. При этом и номер ошибки, и url страницы должны быть указаны.

1.2.Возникла ошибка компиляции или выполнения скрипта (500-100), настроенная в IIS на эту страницу. В этом случае IIS вызывает эту страницу без параметров, а информация об ошибке получается из Server.GetLastError.

1.3.Ошибка вызвана из функций Сайтистики. Функциями, порождающими ошибки, являются Error, RaiseError, RaiseErrorDesc.

1.4.Если страница вызывается другим способом, то порождается ошибка 404.

2.На странице формируется отладочная информация об ошибке. Форма этой отладочной информации унифицирована для всех типов ошибок и может содержать код ошибки, url страницы с ошибкой, описание ошибки, имя файла, в котором произошла ошибка и т.д. Сформированная отладочная информация может в зависимости от различных условий (описаны ниже) выводиться на странице для пользователя, отправляться по электронной почте и записываться в журнал событий.

3.Для ошибки 500 и ее подтипов показывается либо ее детальное описание (отладочная информация), либо страница ошибки 500 (зависит от настроек системы).

4.Существует понятие «second-change exception». Это ошибка, возникшая при обработке ошибок. Такая ошибка всегда выводится в виде отладочной информации с указанием, что это «second-chance exception» и обработка страницы на этом завершается.

5.В зависимости от настроек системы службе поддержки сайта или (на бэкофисе) администратору системы посылается письмо по Email. В этом письме находится отладочная информация об ошибке.

6.Переход между страницами в подсистеме обработки ошибок производится не редиректами, а функцией Server.Transfer, в результате чего достигается уменьшение числа редиректов при обработке ошибки. Например, в случае возникновения ошибки 500 в результате неверного обращения к базе данных на ASP-странице редиректов при обработке ошибок вообще не происходит.

Функции

Ниже перечислены функции порождения ошибок из ASP-страниц. Эти функции следует вызывать для порождения ошибок, вызванных, например, некорректными параметрами запросов. Функции эти доступны как из бэкофиса, так и со всех сайтов фронтофиса.

1.RaiseError (Code) – порождает ошибку с кодом Code. Вместо этой функции рекомендуется использовать функцию

RaiseErrorDesc.

2.RaiseErrorDesc (Code, Desc) – порождает ошибку с кодом Code. В качестве параметра Desc можно передать описание ошибки (почему порождается эта ошибка, например «Неверный идентификатор объекта»). Описание ошибки выводится

вполе Description в отладочной информации об ошибке.

3.Если требуется указать более подробные сведения об ошибке, томожно воспользоваться следующим способом:

a.Задать значение одной или нескольких переменных сессии (пример: Session(“saitistika-error-file”) = “My file.ext”):

i.saitistika-error-file – файл, в котором произошла ошибка.

ii.saitistika-error-line – строка файла, в которой произошла ошибка (должна быть целым числом).

iii.saitistika-error-position – позиция в строке, в которой произошла ошибка (должна быть целым числом).

iv.saitistika-error-srctext – исходный текст, вызвавший ошибку. Значение saitistika-error-position должно указывать на позицию, вызвавшую ошибку, в этой строке.

b.Вызывать функцию RaiseError или RaiseErrorDesc.