Использование фильтра

Перейдем к рассмотрению фильтра. Сразу скажем, что данный фильтр взят из конфигурации Exchange 2000 и в текстовой форме эквивалентен:

(&(mailNickname=*)(|(objectClass=user)(objectClass=contact) (objectCategory=group)(objectCategory=publicFolder)))

Раскроем фильтр сначала до первого уровня (Рис.3):

Рис.3

Глядя на этот фильтр, нетрудно догадаться, какие объекты пропустит данный фильтр. Это объекты, которые имеют атрибут mailNickname и, кроме того, являются либо пользователем, либо контактом, либо группой, либо общей папкой. Такая читабельность – следствие способности фильтров LTC совмещать в себе информацию, необходимую для построения запроса к каталогу (в данном случае LDAP-запроса) и смысловую информацию, ориентированную на пользователя. Чтобы последний фильтр порождал правильную часть LDAP-запроса, нужно, чтобы он содержал информацию об атрибутах. Мы увидим ее, раскрыв этот узел, являющийся составным фильтром (Рис.4):

Рис.4

Знаки операций слева от узлов указывают на то, что для прохождения через фильтр «Все пользователи, контакты, группы и общие папки», объекту необходимо и достаточно пройти через один из четырех указанных фильтров.

Преимущества ltc при формировании целевых множеств

Приведенный пример позволяет наглядно продемонстрировать следующие важные особенности LTC:

• Характерные подмножества каталога (такие как поддеревья) и запросы (в виде структурных фильтров) объединены в рамках одного операционного пространства. В стандартных средствах такая интеграция отсутствует. Чтобы подчеркнуть насколько это может быть важно, заметим, что в свое время объединение данных и программ (методов) привело к появлению понятия классов и такому направлению, как объектно-ориентрованное программирование.

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

• По сравнению с текстовым запросом, фильтр в LTC имеет ряд преимуществ. В частности, он позволяет варьировать степень детализации при просмотре фильтра и добавлять смысловую информацию (наименование фильтра).

• С точки зрения выбора генераторов узлов LTC существенно функциональнее стандартных средств, где в качестве области поиска используется одно поддерево каталога. В LTC можно определить несколько поддеревьев сразу и, кроме того, использовать механизм исключений произвольных внутренних поддеревьев на любом уровне вложенности.

Кроме того LTC позволяет использовать фильтры, которые не могут быть обработаны стандартным LDAP-запросом. Например, узел «Нестандартная фильтрация»:

Рис.5

позволяет найти всех пользователей текущего домена, у которых не совпадают атрибуты CN и displayName. Выражение @(CN) в LTC означает ссылку на значение атрибута (в данном случае CN).

Вот как будет выглядеть приведенный узел после построения результирующего множества (кроме того здесь раскрыт узел «Только пользователи»).

Рис.5

Однако традиционной фильтрацией, пусть даже и с расширенными возможностями, средства управления множествами в LTC далеко не исчерпываются. Рассмотрим следующую ситуацию. Пусть нам необходимо найти пользователей, у которых определен атрибут scriptPath, и при этом сам скрипт-файл отсутствует. Вот решающий эту задачу узел LTC:

Рис.6

Здесь в текущем домене сначала осуществляется поиск всех пользователей, имя CN которых начинается на “Ан” и имеющих непустой атрибут scriptPath. Фильтр (CN=Ан*) добавлен для того, чтобы результирующие множества помещались на снимках экрана. Интересующая нас проверка на наличие соответствующего NT-скрипта в NETLOGON выполняется в узле «Проверка на наличие скрипт-файла в NETLOGON». Прежде чем остановиться на нем несколько подробнее покажем, как будет выглядеть узел после раскрытия трех последних узлов.

Рис.7

На рисунке 6 видно, что из 11-ти пользователей один имеет ошибку в атрибуте scriptPath.

Чтобы прояснить, как была осуществлена проверка на существование файла, указанного в атрибуте scriptPath, сфокусируем внимание на узле «Проверка на наличие скрипт-файла в NETLOGON». Этот узел относится к классу исполняемых узлов LTC. Это означает, что данный узел должен быть однократно исполнен в контексте каждого из входных объектов, то есть в нашем случае для каждого из 11-ти пользователей.

Начнем с того, что при смене контекстного объекта меняется и первый подузел исполняемого узла на узел, соответствующий текущему пользователю. Далее объект пользователя (на рисунке это пользователь Андриянов) попадает на вход папки «NT-скрипт текущего пользователя». Эта папка является преобразователем объектов. Над папкой видно выражение, через которое выполняется преобразование:

\\$CurrentDomainDnsName\NETLOGON\@(scriptPath)

Здесь $CurrentDomainDnsName – это макрос, который заменяется на dns-имя текущего домена. Аналогично выражение @(scriptPath) заменяется на содержимое атрибута scriptPath текущего объекта. В случае с данным пользователем после таких замен была получена строка:

\\samara.yukos.ru\NETLOGON\КНПЗ\Заводоуправление_Отдел_комплектации_оборудования\AndriyanovSA.BAT

LTC распознает эту строку как имя файла и вставляет в папку «NT-скрипт текущего пользователя» узел, соответствующий этому файлу. Если же указанный файл не будет найден, то папка будет пуста.

Рис.8

Узел «Проверка на наличие скрипта» настроен таким образом, что объекты, в контексте которых получается пустой результат продвигаются дальше и попадают на следующий узел. Остальные (в нашем случае пользователи с корректными скриптами) - отбрасываются.

Данный пример показывает как интеграция различных каталогов (здесь это Active Directory и NTFS) в одном операционном пространстве даёт возможность использовать связи между разнородными объектами (пользователи и файлы) для построения целевого множества. Нужно ли опять подчёркивать, что стандартные средства даже не намекают на фильтрацию подобного типа.