Архитектура служб последовательности выполняемых действий

Архитектура служб последовательности выполняемых действий

Иллюстрации

Показать все

Реферат

Перекрестные ссылки на родственные заявки

Данная заявка испрашивает приоритет патентной заявки США № 10/742696, поданной 19 декабря 2003 года, которая является частичным продолжением патентной заявки США № 10/304589 "SYSTEM AND METHOD FOR COMPOSING AND CONSTRAINING AUTOMATED WORKFLOW", поданной 25 ноября 2002 года, каждая из которых полностью включена в данный документ по ссылке.

Область техники, к которой относится изобретение

Область техники относится, в целом, к технологиям автоматизированной последовательности выполняемых действий.

Предшествующий уровень техники

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

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

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

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

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

Сущность изобретения

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

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

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

Фиг. 4 иллюстрирует блок-схему последовательности операций примерного способа обработки сообщений в компонуемом действии.

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

Фиг. 6 иллюстрирует блок-схему последовательности операций примерного способа выполнения синхронизации посредством обмена "действие-действие".

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

Фиг. 8 иллюстрирует блок-схему последовательности операций примерного способа обработки задач.

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

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

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

Фиг. 12 иллюстрирует блок-схему последовательности операций примерного способа использования фактов при применении ограничений.

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

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

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

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

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

Фиг. 18 иллюстрирует блок-схему последовательности операций примерного способа для добавлений специальных действий к потоку деятельности на основе модели деятельности.

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

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

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

Фиг. 22 иллюстрирует блок-схему последовательности операций примерного способа представления параметров на основе предписанного для действующего субъекта в свете ограничений.

Фиг. 23 иллюстрирует блок-схему, показывающую примерную структуру отслеживания.

Фиг. 24 иллюстрирует блок-схему последовательности операций примерного способа отслеживания состояния потока деятельности компонуемых действий.

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

Фиг. 26 иллюстрирует блок-схему последовательности операций примерного способа графического представления состояния потока деятельности.

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

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

Фиг. 29 иллюстрирует блок-схему последовательности операций примерного способа представления и принятия вариантов посредством полнофункционального пользовательского интерфейса последовательности выполняемых действий.

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

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

Фиг. 32 иллюстрирует блок-схему последовательности операций примерного способа обнаружения подробного описания параметров активации действия.

Фиг. 33 иллюстрирует блок-схему, показывающую пример образца поддержки шаблона компонуемого действия.

Фиг. 34, 35, 36 и 37 показывают примерное выполнение технологий последовательности выполняемых действий.

Фиг. 38 иллюстрирует примерное уведомление о задаче с помощью гиперссылок.

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

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

Фиг. 41 иллюстрирует снимок экрана, показывающий примерный образец компонуемого действия.

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

Подробное описание типичных вариантов осуществления

Пример 1 - Примерная система последовательности выполняемых действий

Фиг. 1 иллюстрирует примерную систему 100 для реализации автоматизированной последовательности выполняемых действий посредством компонуемых действий. В примере множество клиентских программ 122A-122N осуществляют доступ к службам 140 последовательности выполняемых действий через сеть 132 (к примеру, по сетевому подключению). На практике клиентские программы 122A-122N управляются соответствующими действующими субъектами-людьми. Действующие субъекты-люди - люди-участники обработки последовательности выполняемых действий, выполняемой в службах 140 последовательности выполняемых действий, и они могут быть представлены в системе с помощью идентификационной информации (к примеру, информации 125).

Службы 140 последовательности выполняемых действий могут работать независимо от пользовательских интерфейсов и других особенностей клиентских программ 122A-122N. Таким образом, клиентские программы 122A-122N могут принимать множество форм или быть единообразными, как требуется. Поскольку к службам 140 может быть осуществлен доступ от множества клиентов (к примеру, различных типов клиентского программного обеспечения), они иногда называются "неосведомленными о клиенте".

Службы 140 последовательности выполняемых действий могут выполнять обработку последовательности выполняемых действий посредством службы 141 составления, которая может собирать (компоновать) компонуемые действия (к примеру, действие 142) в потоки деятельности. Компонуемые действия позволяют отправлять и принимать сообщения (к примеру, сообщение 143) согласно стандартным интерфейсам.

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

На практике система 100 может иметь любое количество клиентских программ, исполняться во множестве сетей и поддерживать множество параллельно выполняемых действий и потоков деятельности.

Пример 2 - Примерный способ обработки последовательности выполняемых действий

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

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

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

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

Пример 3 - Примерные действия

В любом из описанных в данном документе примеров компонуемое действие может принимать форму примерного компонуемого действия 300, показанного на фиг. 3. Действие 300 может быть подвергнуто обработке из определения компонуемого действия, которое обычно включает в себя определение конкретной для действия обработки 308 последовательности выполняемых действий (к примеру, бизнес-логики).

Действие может отправлять и принимать сообщения через набор интерфейсов 312, 322, 332, 342, 352, 362 связи, чтобы поддерживать множество сценариев возможности компоновки. Например, когда направлено пользователем или в соответствующем месте последовательности выполняемых действий, службы последовательности выполняемых действий могут подвергнуть действие обработке и отправить ему сообщение активации.

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

Интерфейсы 312, 322, 332, 342, 352, 362 могут принимать форму стандартных интерфейсов. Например, интерфейсы 312, 322, 332, 342, 352, 362 могут принимать сообщения, соответствующие схеме XML (к примеру, спецификации XSD), используемой в системе последовательности выполняемых действий. Таким образом, разработчик может разрабатывать новые действия; если действия соответствуют схеме XML, они могут быть скомпонованы с другими действиями в службах последовательности выполняемых действий и использовать преимущества признаков служб последовательности выполняемых действий. Различная схема может быть использована для каждого из интерфейсов 312, 322, 332, 342, 352, 362. Например, схема, относящаяся к интерфейсу 322 задачи, может включать в себя то, как задавать действующего субъекта, ассоциированного (связанного) с задачей.

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

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

Пример 4 - Примерный способ обработки сообщений посредством интерфейсов

Фиг.4 иллюстрирует примерный способ обработки сообщений в компонуемом действии, например, посредством компонуемого действия 300 фиг.3. На этапе 412 сообщение принимается посредством одного из стандартных интерфейсов действием с помощью логики, заключенной в действии (инкапсулированной действием). На этапе 422 сообщение обрабатывается. На этапе 432 сообщение отправляется от одного из стандартных интерфейсов действием посредством логики, заключенной в действии.

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

Пример 5 - Примерные потоки деятельности

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

Пример 6 - Примерные сообщения

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

Таблица 1Примерные типы сообщений
Имя типа сообщения	Описание
Активация	Отправляется действию, чтобы активировать его.
Ответ на активацию	Отправляется действием, чтобы указать, что оно было подвергнуто обработке и активировано. Сообщение может быть возвращено в цикле самому действию, чтобы инициализировать значения, используемые для корреляции с другими сообщениями, принятыми действием.
Синхронизация	Может быть отправлено или принято действием. Используется для обмена данными "действие-действие". Может разрешать зависимое составление между действиями. Например, может быть использовано, чтобы разблокировать обработку в рамках действия, когда принято.
Задача	Отправляется действием действующему субъекту и может обозначать назначение задачи действующему субъекту.
Ответ	Отправляется действующим субъектом (к примеру, посредством клиентского программного обеспечения) действию и может обозначать ответ на сообщение "Задача" (к примеру, что задача была принята, и результаты).
Завершение	Отправляется действием в конце его исполнения. Может также быть принято, чтобы указать, что действие нужно закончить (к примеру, для завершения зависимых действий в сценарии синхронизации).
Прерывание	Отправляется действию (к примеру, посредством действующего субъекта), чтобы прервать исполнение. Действие может реализовывать функциональную возможность отката в ответ.

Каждое из сообщений протокола может соответствовать схеме XSD. Таким образом, сообщения могут быть отправлены в XML.

Пример 7 - Примерный сценарий синхронизации

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

Фиг. 5 иллюстрирует примерный обмен (данными) "действие-действие" посредством сообщений. Такая структура 500 может быть использована для обеспечения функциональных возможностей компоновки зависимых действий и синхронизации.

В этом примере вследствие деятельности действующего субъекта A исполнение потока деятельности достигло действия 512, которое назначает задачу действующему субъекту B. После этого действующий субъект B активирует действия 514 и 516, делая действие 516 зависимым от действия 514. Например, действием 514 может быть действие "делегирования полномочий", а действием 516 может быть действие "передачи". Действующий субъект B может выбрать действующего субъекта C в качестве цели для делегирования полномочий, а также задать, что если C не отвечает в течение некоторого промежутка времени, передача должна быть отправлена диспетчеру C. Действие 516 может в таком случае заблокироваться до тех пор, пока не истечет тайм-аут действия 514, и оно не отправит сообщение 572 синхронизации.

Сообщение 572 синхронизации отправляется между интерфейсами 562 и 564. После приема сообщения 572 синхронизации действие 516 разблокируется и выполняет свои функциональные возможности, отправляя сообщения диспетчеру C. Диспетчер C после этого может распространить поток на следующее действие 518.

Фиг. 6 иллюстрирует примерный способ 600 выполнения синхронизации посредством обмена "действие-действие". На этапе 612 исполнение действия блокируется. На этапе 622 блокированное действие приняло сообщение синхронизации. На этапе 632 блокированное действие возобновляет исполнение.

Структура 500 или 600 может быть полезной для координации исполнения по параллельным путям исполнения и может быть использована, чтобы реализовывать условия тайм-аута, например, когда действующему субъекту назначена задача, но задача передается кому-нибудь другому, если действующий субъект не отвечает в течение тайм-аута. Сообщения синхронизации могут быть использованы во множестве других сценариев обмена "действие-действие" (к примеру, чтобы отслеживать ход выполнения другого действия).

Пример 8 - Примерные задачи

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

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

Фиг.7 иллюстрирует типичную структуру 700, посредством которой службы 712 последовательности выполняемых действий могут поддерживать задачи. В этом примере действие 714 может отправить сообщение 724 задачи посредством стандартного интерфейса 722. Сообщение 724 задачи направляется в клиентское программное обеспечение 732, которое включает в себя функциональные возможности выполнения задачи, функциональные возможности завершения задачи или и те и другие 734.

Службы 724 последовательности выполняемых действий могут перехватывать сообщение 724 для отслеживания и сохранять указание на сообщение 724 в базе 732 данных. Например, таблица 734 может указывать назначенную задачу и ассоциированного (связанного) с ней действующего субъекта. На практике дополнительная информация может быть сохранена (к примеру, когда задача была назначена, результаты задачи и т.п.). Информация может быть взята или представлена сообщениями, отправленными в и от действий.

Фиг. 8 иллюстрирует примерный способ 800 обработки задач. На этапе 812 сообщение задачи отправляется программному обеспечению поддержки задачи. На этапе 822 результат задачи принимается службами последовательности выполняемых действий от программного обеспечения поддержки задачи.

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

Пример 9 - Примерная возможность компоновки действий

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

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

Пример 10 - Примерные ограничения

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

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

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

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

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

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

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

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

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

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

Фиг. 9 иллюстрирует примерную структуру 900, влекущую за собой ограничения для определения следующего доступного действия. В примере службы последовательности выполняемых действий определяют следующие вероятные действия для действия 912. В примере вероятны любые из действий 922A-922N. В зависимости от обстоятельств вокруг сценария (к примеру, личности, группы или роли действующего субъекта, выбирающего следующее действие, и т.п.) набор следующих действий 922A-922N ограничен поднабором действий, указанным ограничениями, сохраненными службами последовательности выполняемых действий. Определение следующего действия может быть выполнено механизмом ограничения, применяющим ограничения к текущей ситуации.

Фиг.10 иллюстрирует примерный способ 1000 для реализации ограничений в потоке деятельности. На этапе 1012 действия для потока деятельности инициализируют. После этого может начинаться исполнение. Во время исполнения потока деятельности на этапе 1022 действия, доступные для компоновки как следующего действия, ограничиваются на основе фактов.

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

Пример 11 - Примерное приобретение фактов для ограничений

Фиг.11 иллюстрирует примерную структуру 1100, в которой службы 1112 последовательности выполняемых действий взаимодействуют с одной или более базами 1162A-1162N знаний для применения ограничений 1132. В этом примере один или более соответствующих адаптеров 1122A-1122N используются, чтобы взаимодействовать с базами 1162A-1162N знаний для приобретения фактов.

Доступность фактов в базе знаний (к примеру, базе 1162A знаний) может быть достигнута посредством установки соответствующего адаптера базы знаний (к примеру, адаптера 1122A) в службах последовательности выполняемых действий. Адаптер 1122A включает в себя соответствие, посредством которого информация в базе 1162A знаний может быть извлечена для использования службами 1112 последовательности выполняемых действий. Например, службы 1112 последовательности выполняемых действий могут пожелать обратиться за справкой к фактам относительно действующих субъектов, их положения, уровня безопасности и т.п. при применении ограничений 1132. Таким образом, факты, доступные службам 1112 последовательности выполняемых действий, могут приходить из множества источников.

Фиг. 12 иллюстрирует примерный способ 1200 исп