ИНТЕГРИРОВАНИЕ УЧРЕЖДЕНЧЕСКИХ ПОИСКОВЫХ СИСТЕМ СО СПЕЦИАЛЬНЫМИ ИНТЕРФЕЙСАМИ ПРИКЛАДНОГО ПРОГРАММИРОВАНИЯ УПРАВЛЕНИЯ ДОСТУПОМ Российский патент 2012 года по МПК G06F17/30 G06F13/00 

УРОВЕНЬ ТЕХНИКИ

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

В отличие от поисковых служб с открытым доступом, которые осуществляют поиск общедоступных данных и позволяют фактически любому пользователю исполнять запросы относительно данных, таких как поисковые службы «Всемирной паутины» (Web), учрежденческие поисковые системы обычно индексируют данные, для которых может быть ограниченным доступ к ним. Например, документ, индексированный посредством учрежденческой поисковой системы, может иметь связанный с ним «список контроля доступа» (ACL), который включает в себя один или несколько элементов контроля доступа (ACE), устанавливающих права доступа, имеющиеся у пользователя по отношению к документу. В результате, при исполнении учрежденческой поисковой системой запроса, она должна обеспечивать, чтобы исполняющий запрос пользователь имел достаточные права доступа, чтобы просматривать результаты поиска, возвращенные в ответ на запрос.

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

Независимо от того, извлекаются ли права доступа во время добавления документа к поисковому индексу или во время запроса, учрежденческие поисковые системы для извлечения права доступа должны взаимодействовать с системами внутреннего компьютера, в которых хранятся индексированные документы. Зачастую, однако, подсистемы безопасности каждой разработанной сторонними разработчиками системы внутреннего компьютера используют прикладные программные интерфейсы (application programming interface, API), которые являются несовместимыми, секретными и составляющими собственность. В результате, может иметься необходимость создавать специальный программный код для осуществления интерфейса с API каждой внутренней подсистемы безопасности всякий раз при добавлении к учрежденческой поисковой системе нового типа внутреннего хранилища контента. Это обычно делает трудной, дорогостоящей, и трудоемкой интеграцию между учрежденческими поисковыми системами и разработанными сторонними разработчиками системами хранилищ данных.

В отношении этих и других соображений в документе представлено раскрытие сущности изобретения.

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

Согласно одному аспекту, представленному в документе, создаются и хранятся данные, которые описывают специальный API, предоставляемый внутренней вычислительной системой для получения прав доступа относительно документа. Хранимые данные могут включать информацию, например, идентифицирующую параметры метода, предоставляемого специальным API для получения прав доступа, и данные, указывающие, является ли каждый из параметров входным параметром или выходным параметром. Один из параметров может также быть помечен для указания, что параметр соответствует идентификатору документа, относительно которого запрашиваются права доступа. Другой из параметров может быть помечен для указания, что он соответствует поставляемому системой значению, например идентификатору пользователя для текущего пользователя. Также могут указываться и храниться заданные по умолчанию значения для каждого из параметров.

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 - схема архитектуры сети и программного обеспечения, показывающая иллюстративную операционную среду для процессов и вычислительных систем, описанных в документе, и несколько программных компонентов, используемых вычислительными системами, описанными в документе;

Фиг.2 - схема архитектуры программного обеспечения, показывающая аспекты программы API-преобразователя, представленной в одном варианте осуществления, описанном в документе;

Фиг.3 и 4 - схемы последовательности операций, иллюстрирующие процессы, представленные в документе в соответствии с вариантами осуществления, предназначенные для получения прав доступа относительно документа во время добавления документа к поисковому индексу и для получения прав доступа относительно документа во время поиска, соответственно;

Фиг.5 - схема архитектуры вычислительной системы, показывающая архитектуру вычислительной системы, подходящую для осуществления различных вычислительных систем, описанных в документе.

ПОДРОБНОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

В нижеследующем подробном описании изобретения выполняются ссылки на сопроводительные чертежи, которые составляют его часть и которые показаны в качестве иллюстрации конкретных вариантов осуществления или примеров. Далее со ссылками на чертежи, на которых сходные ссылочные позиции представляют сходные элементы на чертежах, описываются аспекты вычислительной системы и методы, предназначенные для интегрирования учрежденческих поисковых систем со специальными API управления доступом внутреннего хранилища контента. В частности, на Фиг.1 показана схема архитектуры программного обеспечения вычислительной системы и сети, иллюстрирующая некоторую операционную среду 100 для описываемого в документе объекта изобретения, которая включает в состав клиентский компьютер 102, сеть 122 и один или несколько компьютеров 104A-104B Web-серверов.

Как показано на Фиг.1, клиентский компьютер 102 и компьютеры 104A-104B Web-серверов коммуникативно соединены между собой посредством соответственных соединений с сетью 122. Согласно одному исполнению сеть 122 содержит Интернет. Однако должно быть оценено, что сеть 122 может содержать LAN, WAN или другой тип сети, подходящей для соединения клиентского компьютера 102 и компьютеров 104A-104B Web-серверов. Компьютеры 104A-104B Web-серверов также соединены с внутренней системой 112. Серверная система 112 является вычислительной системой, способной хранить документы в хранилище 114 контента. Как используется в документе, термин «документ» означает любую индексируемую единицу данных. Дополнительные подробности относительно действия внутренней системы 112 представлены ниже.

На Фиг.1, также иллюстрируется ряд программных компонентов, используемых клиентским компьютером 102 и компьютерами 104A-104B Web-серверов. В частности, компьютеры 104A-104B Web-серверов действуют, чтобы исполнять «поисковые агенты» 106A-106B, соответственно. Поисковые агенты 106A-106B являются прикладными программами, разработанными для сбора документов из различных источников, например документов, хранимых в хранилище 114 контента в составе внутренней системы 112. Серверная система 112 может содержать любой тип вычислительной системы, используемой для хранения контента, такой как сервер внутренней сети организации, система управления документами или контентом, файловый сервер, учрежденческое хранилище писем или документов, бизнес-приложения, такие как приложения для управления взаимоотношениями с клиентами и интеллектуальными ресурсами предприятия или другие типы хранилищ контента.

Для выполнения этого процесса идентификации и индексирования документа поисковые агенты 106A-106B первоначально наполняются информацией о хранилищах контента. Поисковые агенты 106A-106B затем извлекают документы из хранилищ контента, индексируют документы и сохраняют индексированный контент, и любые связанные с ним метаданные в базе данных, вызываемой поисковым индексом 108. Поисковые агенты 106A-106B также могут определять содержащиеся в каждом документе гипертекстовые ссылки на другие документы и следовать ссылкам, чтобы получать и индексировать дополнительные документы. Этот процесс именуется "ползанием".

В течение процесса следования ссылкам поисковые агенты 106A-106B могут также получить права доступа относительно каждого документа, который индексируется. Например, поисковые агенты 106A-106B могут получать перечень авторизованных пользователей для каждого документа. Согласно одному исполнению права доступа получают путем использования надлежащего API-преобразователя 110A-110B, чтобы запрашивать внутреннюю систему 112 относительно перечня авторизованных пользователей. Дополнительные подробности, относящиеся к использованию и действию API-преобразователей 110A-110B, представлены ниже.

Согласно одному исполнению клиентский компьютер 102 включает в себя программу 116 Web-браузера (именуемую в документе "браузер"). Браузер 116 действует, чтобы запрашивать, принимать и отображать страницы информации, такие как Web-страницы, от внутренних компьютеров 104A-104B. В частности, браузер 116 действует, чтобы установить соединение с одним из приложений Web-серверов 118A-118B, исполняющимся на внутренних компьютерах 104A-104B. Посредством соединения браузер 116 может запрашивать Web-страницу для исполнения запроса поискового индекса 108. Такой поисковый запрос обрабатывается процессором 120A-120B запросов, выполняющемся на компьютере 104A-104B Web-сервера, который заполняет поля поискового запроса.

Процессоры 120A-120B запросов отвечают на пользовательские запросы согласно идентификации документов в поисковом индексе 108, который содержит ключевые слова из пользовательского запроса. Процессоры 120A-120B запросов также оценивают, следует ли возвращать каждый документ в качестве результата поиска, на основании того, имеет ли пользователь, выполняющий запрос, достаточные права доступа для просмотра каждого документа. Как будет описано более подробно ниже, каждый процессор 120A-120B запросов может динамически запрашивать внутреннюю систему 112 относительно прав доступа, указывающих, имеет ли пользователь, исполняющий запрос, разрешения для просмотра каждого документа из результатов поиска. Этот запрос активизируется посредством надлежащего API-преобразователя 110A-110B.

Как будет обсуждено более подробно в документе, API-преобразователи 110A-110B предоставляют нормализованный API для получения права доступа относительно документа. Например, в одном исполнении, API-преобразователи 110A-110B предоставляют метод для использования поисковыми агентами 106A-106B, предназначенный для извлечения прав доступа относительно документов, выявленных в течение процесса следования ссылкам. В ответ на вызов такого метода API-преобразователи 110A-110B преобразуют нормализованный вызов, принятый от поискового агента, в конкретный специальный API прав доступа, предоставляемый внутренней системой 112. Права доступа, возвращенные из внутренней системы, затем возвращаются вызывающему поисковому агенту.

Согласно другим аспектам нормализованный API, предоставляемый API-преобразователями 110A-110B, может также использоваться процессорами 120A-120B запросов во время запроса, чтобы извлекать права доступа относительно документов, идентифицированных в результатах поискового запроса. В этом случае процессоры 120A-120B запросов могут вызывать нормализованный API, предоставляемый соответственным API-преобразователем 110A-110B. В ответ на такой запрос API-преобразователи 110A-110B преобразуют нормализованный запрос, принятый от поискового агента, в запрос конкретного специального API прав доступа, предоставляемого внутренней системой 112. Права доступа, возвращенные из внутренней системы 112, затем возвращаются вызывающему процессору запросов. Дополнительные подробности относительно использования и действия API-преобразователей 110A-110B представлены ниже. Должно быть оценено, что хотя на Фиг.1 были проиллюстрированы только два компьютера 104A-104B Web-серверов, одна внутренняя система 112 и один клиентский компьютер 102, может присутствовать любое количество этих вычислительных устройств.

Теперь с обращением к Фиг.2 будет описана схема архитектуры программного обеспечения, показывающая аспекты иллюстративной архитектуры 200 программного обеспечения для учрежденческой поисковой системы, которая включает в состав API-преобразователь 110. В частности, как показано на Фиг.2, API-преобразователь 110 предоставляет нормализованный API для извлечения прав доступа относительно документа. Нормализованный интерфейс, представленный посредством нормализованного API, является согласованным интерфейсом, который различные приложения, исполняющиеся в рамках учрежденческой поисковой системы, могут использовать, чтобы получать права доступа относительно документа независимо от внутреннего хранилища контента, в котором документ постоянно находится. Например, поисковый агент 106 и процессор 120 запросов могут оба использовать метод, предоставляемый нормализованным API, чтобы получать права доступа относительно документов. Как будет описано более подробно в документе, методы, предоставляемые нормализованным API, принимают параметр, идентифицирующий документ, относительно которого запрашиваются права доступа, и могут необязательно принимать идентификатор пользователя для целей аутентификации.

В одном исполнении нормализованный API, предоставляемый API-преобразователем 110, включает в состав метод CHECKACCESS (проверка доступа), посредством которого могут быть извлечены права доступа относительно группы документов для отдельного пользователя. В одном исполнении метод CHECKACCESS в качестве параметра принимает массив идентификаторов документов и возвращает «длинное» значение, которое указывает, имеет ли текущий пользователь доступ для каждого из упомянутых документов. Метод CHECKACCESS обычно используется процессором 120 запросов, чтобы определить, имеет ли текущий пользователь права доступа для просмотра совокупности результатов поиска.

Нормализованный API, предоставляемый API-преобразователем 110, может также включать в состав метод PERMITTEDUSERS (разрешенные пользователи), посредством которого могут быть извлечены права доступа для всех пользователей относительно совокупности документов. Этот способ принимает массив идентификаторов документов в качестве входного параметра и возвращает строку, указывающую права доступа всех пользователей для каждого документа, идентифицированного в массиве. Метод PERMITTEDUSERS обычно используется поисковым агентом 106 для извлечения прав доступа для всех пользователей для просмотра документов, извлеченных в течение следования ссылкам. Как будет описано более подробно ниже, API-преобразователь 110 действует, чтобы динамически преобразовать вызовы нормализованных API в вызовы, совместимые со специальным API, предоставляемым внутренними системами 112A-112B.

Как упомянуто выше, внутренние системы 112A-112B могут предоставлять специальные API для извлечения данных прав доступа относительно документов, хранимых в хранилищах 114A-114B контента. Например, в одном исполнении система, которая использует программное обеспечение компании SAP AG, может предоставлять метод GETDISPLAYABLECUSTOMERS (получить отображаемых заказчиков), предназначенный для извлечения прав доступа пользователя относительно одного или нескольких «заказчиков». Этот метод принимает в качестве входных параметров идентификационные данные конечного пользователя и номер заказчика и возвращает булево значение, указывающее, имеет ли конечный пользователь права, чтобы просматривать «заказчика». Система SAP может также предоставлять метод GETAUTHORIZEDUSERSFORCUSTOMER (получить авторизованных пользователей для заказчика), посредством которого могут быть извлечены все права доступа по отношению к конкретному заказчику. Этот метод принимает в качестве входных параметров номер заказчика и возвращает перечень строк, указывающих права доступа для обозначенного заказчика.

В одном варианте осуществления, если API-преобразователь 110 принимает вызов метода CHECKACCESS, он динамически преобразует вызов в вызов, совместимый с методом GETDISPLAYABLECUSTOMERS. Например, если принятым вызовом является PERMITTEDUSERS (BDC://HOST/123/456?ID=34) (где внутренняя система 112A идентифицирована посредством номера 123), API-преобразователь 110 динамически преобразует этот вызов в GETDISPLAYABLECUSTOMERS(34). Затем вызов исполняется во внутренней системе 112A. API-преобразователь 110 будет формировать многократные вызовы метода GETDISPLAYABLECUSTOMERS, поскольку этот API выдает результаты для одного документа заказчика, тогда как метод CHECKACCESS проверку авторизации обычно запрашивает в виде пакетов. API-преобразователь 110 также преобразует данные неявной идентификации конечного пользователя, содержащиеся в потоке операционной системы, в строковое значение идентификационных данных, которое использует внутренняя система.

Если API-преобразователь 110 принимает вызов метода CHECKACCESS, такой как CHECKACCESS(BDC://HOST/333/456?ID=36) (где внутренняя система 112B идентифицирована номером 333), API-преобразователь 110 этот вызов динамически преобразует в вызов в форме GETAUTHORIZEDUSERSFORCUSTOMER(36), направленный внутренней системе 112B. Должно быть оценено, что эти API внутренней части являются лишь иллюстративными и что представленные в документе варианты осуществления могут использоваться вместе с любым специальным API для извлечения прав доступа относительно документа.

Для того чтобы выполнять такую обработку, API-преобразователь 110 использует метаданные, хранимые в хранилище метаданных 202, чтобы преобразовывать вызов нормализованного API в вызов специального API, предоставляемого внутренними системами 112A-112B. Хранилище метаданных 202 используется, чтобы хранить данные, которые описывают фактический API, предоставляемый внутренними системами 112A-112B, и тип соединений, необходимый для связи с каждой из внутренних систем 112A-112B. Например, в одном исполнении, пользователь, знакомый с внутренней системой 112A, может создать описание фактического API, предоставляемого системой, и информацию соединения в виде файла на расширяемом языке разметки гипертекста (XML). XML-файл загружается в учрежденческую поисковую систему и сохраняется в хранилище метаданных 202. Как только XML-файл был загружен, соединение с интерфейсами API прав доступа, обеспечиваемыми внутренней системой 112A, непосредственно доступно для использования. Посредством представления возможности пользователю декларативно определять интерфейс для извлечения прав доступа из внутренней системы, и посредством обработки метаданных описанным в документе образом не требуется программирование для осуществления интерфейса с новым типом внутренней системы хранения контента.

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

Согласно вариантам осуществления данные, хранимые в хранилище метаданных 202 для каждой внутренней системы 112, могут также включать описание каждого типа данных, обеспечиваемого внутренней системой 112, и какие поля уникально идентифицируют экземпляр данных этого типа. Например, могут храниться данные, указывающие, что типом данных является «заказчик» во внутренней системе SIEBEL или «заказ» в системе SAP. Взаимосвязи, называемые тегами, также могут храниться в хранилище метаданных 202 для базовых типов специального API и параметров в API, соответствующих экземпляру типа данных. Например, параметр, который используется для уникальной идентификации документа в API, может быть помечен в качестве такового. Когда поисковый агент 106 или процессор 120 запросов предоставляет идентификатор документа, относительно которого запрашиваются права доступа, API-преобразователь 110 может вставить идентификатор документа в надлежащее положение в вызове API, обеспечиваемом внутренней системой 112. Дополнительные подробности относительно этого процесса представлены ниже.

Согласно вариантам осуществления параметры внутреннего API, которые соответствуют поставляемым системой значениям, могут быть помечены тегом в качестве таковых в хранилище метаданных 202. Например, согласно одному варианту осуществления поставляемым системой значением является параметр, идентифицирующий текущего пользователя. Таким образом, процессор 120 запросов может поставлять идентификационные данные текущего пользователя на API-преобразователь 110. API-преобразователь 110 затем может выполнить подстановку идентификационных данных текущего пользователя для соответствующего параметра в вызове внутренней системы 112. Дополнительные подробности относительно этого процесса представлены ниже.

Согласно другим аспектам данные, хранимые в хранилище метаданных 202 для каждой внутренней системы 112, могут также включать информацию соединения, предназначенную для разработанной сторонними разработчиками системы хранилища данных, так что может выполняться соединение с системой для исполнения проверки доступа. Данные могут также включать в состав тип протокола, необходимый для исполнения внутреннего API. Например, в вариантах осуществления могут использоваться удаленный вызов процедуры (RPC) или Web-служба, чтобы исполнять вызов внутреннего API.

В одном варианте осуществления хранимые в хранилище метаданных 202 данные организованы в виде ряда таблиц данных. Например, одна таблица может использоваться для хранения данных, идентифицирующих различные внутренние системы, а другая таблица может использоваться для хранения информации, идентифицирующей тип данных, хранимых в каждом хранилище контента. Еще одна таблица может использоваться, чтобы хранить данные, идентифицирующие методы защиты, предоставляемые каждым хранилищем контента согласно типу данных. Например, доступ к «коммерческим заказам» во внутренней системе может использовать API, отличный от доступа к «заказчикам». Может также использоваться таблица для хранения данных, идентифицирующих каждый из параметров специального внутреннего API, и могут использоваться другие таблицы, чтобы хранить информацию, определяющую элементарные типы данных, используемые каждым параметром. Должно быть оценено, что хранилище метаданных 202 может быть организовано различными другими способами.

Как также проиллюстрировано на Фиг.2, API-преобразователь 110 использует один или несколько модулей обеспечения совместимости вызовов API (shim) 204A-204N, чтобы выполнять зависящие от протокола вызовы специальных API, предоставляемых внутренними системами 112A. Например, может обеспечиваться модуль 204A обеспечения совместимости Web-службы для вызовов Web-службы, может обеспечиваться модуль 204B обеспечения совместимости RPC для удаленного вызова процедур, и может обеспечиваться модуль 204C обеспечения совместимости баз данных для взаимодействия с базой данных. Может также использоваться другой модуль 204N обеспечения совместимости. Как кратко описано выше, в хранилище метаданных 202 могут храниться данные, определяющие конкретный модуль 204A-204N обеспечения совместимости для использования для каждой внутренней системы 112A или тип данных. Например, могут храниться данные, указывающие, что должен использоваться модуль 204A обеспечения совместимости Web-службы для некоторых типов документов, хранимых в хранилище 114A контента внутренней системы 112A. В хранилище метаданных 202 также могут храниться данные, указывающие, что модуль 204C обеспечения совместимости базы данных должен использоваться для извлечения прав доступа к документам, хранимым в хранилище 114B контента внутренней системы 112.

Далее со ссылкой на Фиг.3 приведены дополнительные подробности относительно представленных в документе вариантов осуществления интегрирования учрежденческих поисковых систем со специальными API управления доступом внутреннего хранилища контента. В частности, на Фиг.3 показана схема последовательности операций, иллюстрирующая действие учрежденческой поисковой системы, включающей в состав API-преобразователь 110 для получения прав доступа относительно документа, во время следования ссылкам. Должно быть оценено, что описанные в документе логические операции осуществляются (1) в виде последовательности реализуемых компьютером действий или программных модулей, исполняющихся на вычислительной системе и/или (2) в виде взаимосвязанных схем машинной логики или схемных модулей в рамках вычислительной системы. Реализация является вопросом выбора, зависящего от требований рабочей характеристики вычислительной системы. Соответственно, логические операции, описанные в документе, именуются различно как операции, структурные устройства, действия, или модули. Эти операции, структурные устройства, действия и модули могут быть реализованы в виде программного обеспечения, микропрограммного обеспечения, в виде специализированной цифровой логики и любой комбинации.

Программа 300 начинается с операции 302, где поисковый агент 106 запрашивает документ от одной из внутренних систем 112A-112B. Программа 300 затем переходит к операции 302, где поисковый агент 106 вызывает API-преобразователь 110 с унифицированным указателем ресурса (URL-адрес) для извлекаемого документа. Программа 300 затем переходит к операции 306, где API-преобразователь 110 из принятого URL извлекает для документа адрес внутренней системы, тип данных документа и идентификатор документа. Например, если принятым URL является bdc://hostname/123/456?id=34, адресом внутренней системы является 123, типом данных является 456 и идентификатором документа является 34. Затем могут осуществляться ссылки на данные в хранилище метаданных 202, чтобы определить, что внутренней системой является система SAP, типом данных является «заказчик» в SAP, и идентификатор документа относится к «заказчику» с номером заказчика 34.

Как только были извлечены адрес внутренней системы, тип данных и идентификатор документа, программа 300 переходит к операции 308. В операции 308 API-преобразователь 110 создает экземпляр вызова надлежащего метода внутренней системы. В одном варианте осуществления экземпляр вызова создается с использованием заданных по умолчанию значений для каждого из параметров, хранимых в хранилище метаданных 202. Программа 300 затем переходит к операции 310, где API-преобразователь 110 осуществляет подстановку идентификатора документа, принятого вместе с вызовом нормализованного API, для надлежащего параметра созданного экземпляра вызова API внутренней системы. API-преобразователь 110 использует данные, хранимые в хранилище метаданных 202, чтобы определить корректное положение для параметра идентификатора документа. В варианте осуществления идентификатор пользователя, принятый вместе с вызовом нормализованного API, также может вставляться в соответствующее положение в вызове API внутренней системы.

Как только создан экземпляр вызова специального API, обеспечиваемого внутренней системой, и все параметры установлены, программа 300 переходит к операции 312, где API-преобразователь 110 исполняет вызов надлежащей внутренней системы 112. Как описано выше, может использоваться надлежащий модуль 204A-204N обеспечения совместимости, чтобы фактически выполнить вызов удаленного метода. В ответ на исполнение метода внутренняя система возвращает запрошенные права доступа в операции 314.

API-преобразователь 110 затем поставляет возвращенные права доступа на поисковый агент 106 в ответ на первоначальный вызов нормализованного API, предоставляемого API-преобразователем 110. Это происходит в операции 316. В операции 318 поисковый агент 106 сохраняет возвращенные права доступа в поисковом индексе 108 или другом надлежащем хранилище данных. Процессор 120 запросов может использовать эту информацию, чтобы обработать результаты поиска во время запроса без необходимости взаимодействия с внутренней системой, которая поставила права доступа. От операции 318 программа 300 переходит к операции 320, где она завершается.

Далее со ссылкой на Фиг.4 описана иллюстративная программа 400, предназначенная для получения прав доступа относительно документа во время поиска в учрежденческой поисковой системе, которая включает в состав API-преобразователь 110. В частности, программа 400 начинается с операции 402, где клиентский компьютер 102 исполняет поисковый запрос в процессоре 120 запросов. В ответ на исполнение поискового запроса программа 400 переходит от операции 402 к операции 404, где процессор 120 запросов извлекает URL-адреса документов, совпадающие с заданными поисковыми терминами из поискового индекса 108. Процессор 120 запросов затем вызывает нормализованный API, предоставляемый API-преобразователем 110, с идентифицированными URL-адресами. Это происходит в операции 406.

От операции 406 программа 400 переходит к операции 408, где API-преобразователь 110 извлекает для документа из принятых URL-адресов адрес внутренней системы, тип данных для документа и идентификатор документа. Например, если принятым URL-адресом является bdc://hostname/123/456?id=34, адресом внутренней системы является 123, типом данных является 456 и идентификатором документа является 34. Затем могут осуществляться ссылки на данные в хранилище метаданных 202, чтобы определить, что внутренней системой является система SAP, типом данных является «заказчик» в SAP и идентификатор документа относится к «заказчику» с номером заказчика 34.

Как только были извлечены адрес внутренней системы, тип данных и идентификатор документа, программа 400 переходит к операции 410. В операции 410 API-преобразователь 110 создает экземпляр вызова надлежащего метода внутренней системы. В одном варианте осуществления экземпляр вызова создается с использованием заданных по умолчанию значений для каждого из параметров, хранимых в хранилище метаданных 202. Программа 400 затем переходит к операции 412, где API-преобразователь 110 вставляет идентификатор документа и идентификатор пользователя, принятый вместе с вызовом нормализованного API, в надлежащее положение в вызове API внутренней системы.

Как только был создан экземпляр вызова специального API, обеспечиваемого внутренней системой, и все параметры были установлены, программа 400 переходит к операции 414, где API-преобразователь 110 исполняет запрос надлежащей внутренней системы 112. Как описано выше, может использоваться надлежащий модуль 204A-204N обеспечения совместимости, чтобы выполнять вызов удаленного метода. В ответ на исполнение метода внутренняя система в операции 416 возвращает запрошенные права доступа. API-преобразователь 110 затем поставляет возвращенные права доступа на процессор 120 запросов в ответ на первоначальный вызов нормализованного API, предоставляемого API-преобразователем 110. В операции 418 процессор 120 запросов обрабатывает результаты поиска на основании возвращенных прав доступа. Например, не будут отображаться результаты, для которых текущий пользователь не имеет разрешения «на чтение», тогда как будут отображены результаты, для которых текущий пользователь имеет разрешение «на чтение». От операции 418 программа 400 переходит к операции 420, где она завершается.

Далее со ссылкой на Фиг.5 описана иллюстративная архитектура вычислительной системы для компьютера 500, используемая в различных вариантах осуществления, представленных в документе. Показанная на Фиг.5 архитектура вычислительной системы иллюстрирует традиционный, в настольном исполнении, портативный компьютер или внутренний компьютер. Показанная на Фиг.5 архитектура вычислительной системы включает в состав центральный процессор 502 (CPU), системную память 508, включающую в себя оперативное запоминающее устройство 514 (RAM), и постоянное запоминающее устройство (ROM) 516, и системную шину 504, которая соединяет память с CPU 502. Базовая система ввода-вывода, содержащая базовые подпрограммы, которые помогают передавать информацию между элементами внутри компьютера 500, например в течение запуска, хранится в ROM 516. Компьютер 500 дополнительно включает в состав запоминающее устройство 510, чтобы хранить операционную систему 518, прикладные программы и другие программные модули, которые будут описаны более подробно ниже.

Запоминающее устройство соединено с CPU 502 посредством контроллера запоминающего устройства (не показано), соединенного с шиной 504. Запоминающее устройство 510 и связанный с ним машиночитаемый носитель обеспечивают энергонезависимое запоминающее устройство для компьютера 500. Хотя содержащееся в документе описание машиночитаемого носителя относится к запоминающему устройству, такому как накопитель на жестком диске или ROM на компакт-диске (CD-ROM), специалистам в данной области техники должно быть понятно, что машиночитаемым носителем могут быть любые доступные носители, к которым может быть осуществлен доступ посредством компьютера 500.

В качестве примера, а не ограничения, машиночитаемый носитель может включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные. Например, машиночитаемый носитель включает в себя, но без ограничения, RAM, ROM, стираемое программируемое ROM (EPROM), электрически стираемое программируемое ROM (EEPROM), флэш-память или другую технологию твердотельной памяти, ROM на компакт-диске (CD-ROM), цифровые многофункциональные диски (DVD), DVD высокой плотности записи (HD-DVD), диск по технологии BLU-RAY или другое оптическое запоминающее устройство, носители на магнитных кассета, магнитной ленте, магнитом диске, или другие магнитные запоминающие устройства, или любой другой носитель, который может использоваться для хранения требуемой информации и к которому можно осуществлять доступ компьютер 500.

В соответствии с различными вариантами осуществления изобретения компьютер 500 может работать в сетевой среде, используя логические соединения с удаленными компьютерами по сети 122, например Интернет. Компьютер 500 может соединяться с сетью через сетевой интерфейсный блок 506, соединенный с шиной 504. Должно быть оценено, что сетевой интерфейсный блок 506 также может использоваться для соединения с другими типами сетей и удаленными вычислительными системами. Компьютер 500 также может включать в себя контроллер 22 ввода/вывода для приема и обработки входных данных от ряда других устройств, включая клавиатуру, мышь, или электронное перо (не показано на Фиг.5). Подобным образом контроллер ввода/вывода может обеспечивать вывод на экран устройства отображения, принтер или другой тип устройства вывода (также не показано на Фиг.5).

Как кратко упомянуто выше, в запоминающем устройстве 510 и RAM 414 компьютера 500 может храниться ряд программных модулей и файлов данных, включая операционную систему 518, подходящую для управления функционированием сетевого настольного или внутреннего компьютера, такую как операционная система WINDOWS VISTA корпорации MICROSOFT (Редмонд, Вашингтон). Могут использоваться другие операционные системы, такие как операционная система LINUX или операционная система OSX корпорации APPLE COMPUTER, INC. Должно быть оценено, что, хотя представленные в документе варианты осуществления описаны в контексте настольного или портативного клиентского компьютера 102 и удаленного внутреннего компьютера 104, могут использоваться многие другие типы вычислительных устройств и систем для осуществления различных аспектов, представленных в документе.

Запоминающее устройство 510 и RAM 514 могут также хранить один или несколько программных модулей. В частности, запоминающее устройство 510 и RAM 514 могут хранить Web-браузер 116, приложение Web-сервера 118 и другие программные модули, описанные выше относительно Фиг.1 и 2. Другие программные модули также могут храниться в запоминающем устройстве 510 и использоваться компьютером 500.

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

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

Изобретение относится к интегрированным учрежденческим поисковым системам. Техническим результатом является расширение функциональных возможностей интеграции между учрежденческими поисковыми системами и системами хранилищ данных, разработанными сторонними разработчиками. Используется декларативная модель метаданных, чтобы создавать и хранить данные, описывающие специальный API, предоставляемый внутренними хранилищами контента для извлечения прав доступа относительно документов, хранимых в нем. Нормализованный API для получения прав доступа относительно документа также предоставляется. При выполнении вызова нормализованного API используются хранимые данные, чтобы преобразовать вызов нормализованного API в вызов специального API. 3 н. и 17 з.п. ф-лы, 5 ил.

1. Способ интегрирования учрежденческой поисковой системы со специальным прикладным программным интерфейсом (API) управления доступом к документам, содержащий этапы, на которых:
сохраняют данные (202), описывающие специальный API, предназначенный для получения одного или более прав доступа относительно документа;
предоставляют нормализованный API для получения прав доступа относительно документа;
принимают (304) вызов предоставляемого нормализованным API метода, запрашивающего права доступа относительно указанного документа;
в ответ на прием вызова метода, предоставляемого нормализованным API, преобразуют (310) вызов метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API, для получения прав доступа относительно указанного документа;
принимают (314) права доступа в ответ на вызов метода, предоставляемого специальным API; и
возвращают (316) запрошенные права доступа в ответ на вызов метода, предоставляемого нормализованным API.

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

3. Способ по п.2, в котором данные, описывающие специальный API, дополнительно содержат заданные по умолчанию значения параметров.

4. Способ по п.3, в котором данные, описывающие специальный API, дополнительно содержат данные, идентифицирующие один из параметров в качестве соответствующего идентификатору документа, относительно которого запрашиваются права доступа, при этом метод, предоставляемый нормализованным API, принимает параметр, идентифицирующий документ, относительно которого запрашиваются права доступа.

5. Способ по п.4, в котором этап преобразования вызова метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API, для запрашиваемых прав доступа относительно указанного документа содержит этапы, на которых:
создают экземпляр вызова метода, предоставляемого специальным API, с использованием заданных по умолчанию значений для параметров;
подставляют параметр, идентифицирующий документ, относительно которого запрашиваются права доступа, принятого вместе с вызовом нормализованного API, вместо заданного по умолчанию значения параметра, соответствующего идентификатору документа, относительно которого запрашиваются права доступа; и
исполняют вызов метода, предоставляемого специальным API.

6. Способ по п.5, в котором данные, описывающие специальный API, дополнительно содержат данные, идентифицирующие один из параметров в качестве соответствующего поставляемому системой значению, и при этом метод, предоставляемый нормализованным API, принимает параметр, идентифицирующий текущего пользователя.

7. Способ по п.6, в котором этап преобразования вызова метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API, для прав доступа относительно указанного документа дополнительно содержит этап, на котором:
подставляют параметр, идентифицирующий текущего пользователя, вместо заданного по умолчанию значения параметра, соответствующего поставляемому системой значению.

8. Способ по п.3, в котором вызов метода, предоставляемого нормализованным API, формируется программой поискового агента.

9. Способ по п.3, в котором вызов метода, предоставляемого нормализованным API, формируется процессором поисковых запросов.

10. Машиночитаемый носитель с хранящимися на нем машиноисполнимыми командами, которые при исполнении компьютером побуждают компьютер
предоставлять нормализованный прикладной программный интерфейс (API) для получения одного или более прав доступа относительно документа;
принимать (302) вызов метода, предоставляемого нормализованным API для извлечения прав доступа относительно документа, причем вызов включает в себя идентификатор документа относительно документа и идентификатор пользователя;
создавать (310) вызов метода, предоставляемого специальным API для получения прав доступа относительно документа, в ответ на вызов метода, предоставляемого нормализованным API, причем запрос создается с использованием хранимых данных, описывающих один или несколько параметров метода, предоставляемого специальным API, идентификатора документа и идентификатора пользователя;
исполнять (312) вызов метода, предоставляемого специальным API;
принимать (316) права доступа относительно документа в ответ на вызов метода, предоставляемого специальным API; и
возвращать (318) права доступа относительно документа в ответ на вызов метода, предоставляемого нормализованным API.

11. Машиночитаемый носитель по п.10, в котором данные, описывающие один или несколько параметров метода, предоставляемого специальным API, дополнительно содержат заданные по умолчанию значения для одного или нескольких параметров.

12. Машиночитаемый носитель по п.11, в котором данные, описывающие один или несколько параметров метода, предоставляемого специальным API, дополнительно содержат данные, идентифицирующие один из параметров в качестве соответствующего идентификатору документа и один из параметров в качестве соответствующего идентификатору пользователя.

13. Машиночитаемый носитель по п.12, в котором метод, предоставляемый нормализованным API, содержит метод для извлечения прав доступа для множества документов, при этом метод, предоставляемый специальным API, содержит метод для извлечения прав доступа относительно одиночного документа, при этом машиночитаемый носитель содержит хранимые на нем дополнительные машиноисполнимые команды, предназначенные для создания отдельного вызова метода, предоставляемого специальным API, для каждого из множества документов, идентифицированных в вызове метода, предоставляемого нормализованным API.

14. Машиночитаемый носитель по п.12, в котором вызов метода, предоставляемого нормализованным API, принимают из программы поискового агента.

15. Машиночитаемый носитель по п.12, в котором вызов метода, предоставляемого нормализованным API, принимают от процессора поисковых запросов.

16. Способ интегрирования учрежденческой поисковой системы со специальным прикладным программным интерфейсом (API) управления доступом к документам, содержащий этапы, на которых:
сохраняют данные (202), которые описывают один или несколько методов, предоставляемых специальным API управления доступом к документам, причем данные содержат заданные по умолчанию значения для одного или нескольких используемых методами параметров, данные, идентифицирующие параметры, которые соответствуют идентификатору документа, и данные, идентифицирующие параметры, которые соответствуют идентификатору пользователя;
предоставляют нормализованный API для получения одного или более прав доступа относительно документа, причем права доступа сохранены во внутренней вычислительной системе (112) и доступны с использованием одного из методов, предоставляемых специальным API управления доступом к документам;
принимают (302) вызов метода, предоставляемого нормализованным API, причем вызов включает в себя идентификатор документа, соответствующий документу, для которого нужно получать права доступа, и идентификатор пользователя для текущего пользователя;
в ответ на вызов метода, предоставляемого нормализованным API, преобразуют (310) вызов метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API управления доступом к документу с использованием заданных по умолчанию значений, идентификатора документа и идентификатора пользователя;
в ответ на вызов метода, предоставляемого специальным API управления доступом к документу, принимают (316) один или более прав доступа относительно документа; и
возвращают (318) права доступа относительно документа в ответ на вызов метода, предоставляемого нормализованным API.

17. Способ по п.16, в котором вызов метода, предоставляемого нормализованным API, формируется посредством программы поискового агента.

18. Способ по п.17, в котором метод, предоставляемый нормализованным API, действует для извлечения прав доступа для одного или нескольких пользователей относительно одиночного документа.

19. Способ по п.16, в котором вызов метода, предоставляемого нормализованным API, формируется посредством процессора поисковых запросов.

20. Способ по п.18, в котором метод, предоставляемый нормализованным API, действует для извлечения прав доступа к одному или нескольким документам для текущего пользователя процессора поисковых запросов.