Перекрестные ссылки на родственные заявки
Данная заявка испрашивает приоритет патентной заявки США № 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 иллюстрирует примерный набор сообщений для системы последовательности выполняемых действий.
Примерные типы сообщений
Каждое из сообщений протокола может соответствовать схеме 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 использования фактов при применении ограничений. На этапе 1212 принимается запрос для факта в ходе обработки ограничения.
Например, может быть запрошен уровень безопасности или подразделение (департамент) действующего субъекта. На этапе 1222 факт извлекается. После этого на этапе 1232 извлеченный факт используется, чтобы применить ограничение.
На практике факты могут быть извлечены (к примеру, из одной или более баз знаний) на периодической основе или одноразовой основе и сохранены в центральном хранилище фактов под управлением служб последовательности выполняемых действий, из которых запросы могут быть удовлетворены.
Помимо этого, факты могут включать в себя текущее состояние хода выполнения потока деятельности, тип документа, ассоциированного с потоком деятельности, или какое-либо их сочетание.
Пример 12 - Примерная компонуемость для создания моделей деятельности
В любом из описанных в данном документе примеров одно или более действий могут быть скомпонованы в набор действий и ассоциированных (связанных с ним) ограничений, инициализируемых для создания потока деятельности. Этот набор действий иногда называется "моделью деятельности".
Исполнение модели деятельности иногда называют исполнением потока деятельности априори, поскольку действия уже были выбраны разработчиком модели деятельности. Если необходимо, разработчик модели деятельности может задать модель деятельности как неизменную, чтобы в ходе исполнения ассоциативно ассоциированного потока деятельности изменения не могли быть внесены.
Фиг. 13 иллюстрирует примерную модель 1300 деятельности. В этом примере множество ссылок на определения 1322, 1324, 1326, 1338 и 1330 действий было собрано в вызываемом блоке, который может быть выбран для исполнения действующим субъектом (к примеру, как разрешено ограничениями). Для удобства пользователя модели 1300 деятельности может быть дано понятное имя, посредством которого она может быть выбрана.
Фиг. 14 иллюстрирует примерный способ 1400 для реализации модели деятельности посредством компонуемых действий. На этапе 1412 запрос принимается (к примеру, от действующего субъекта-человека), чтобы запустить модель деятельности (к примеру, посредством клиентского программного обеспечения служб последовательности выполняемых действий). На этапе 1422 компонуемые действия потока деятельности инициализируются на основе определения модели деятельности. На этапе 1432 действия компонуются в поток деятельности на основе определения потока деятельности. Например, последовательность действий может быть задана моделью деятельности так, чтобы по завершении действия следующее действие в потоке деятельности исполнялось.
Пример 13 - Примерная возможность компоновки специального выбора действий
В любом из описанных в данном документе примеров одно или более действий могут быть скомпонованы в набор действий действующим субъектом-человеком, чтобы сформировать поток деятельности на специальной основе. Например, действующий субъект-человек может выбрать действие для обработки. Если необходимо, различные параметры, соответствующие конкретным обстоятельствам, могут быть предоставлены для инициализируемого действия действующим субъектом-человеком (к примеру, посредством электронной формы).
Фиг. 15 иллюстрирует пример потока 1500 деятельности, в котором набор действий 1522 и 1552 был скомпонован на специальной основе. В этом примере пользователь выбрал инициализацию действия 1522 анализа, которое приводит к созданию задачи для целевого действующего субъекта. В этом примере задача обнаруживает себя целевому действующему субъекту в форме пользовательского интерфейса 1532, показывающего, что целевой действующий субъект должен проанализировать элемент (к примеру, прикрепленный документ). Целевой действующий субъект может выбрать утвердить 1534 или отклонить 1536 элемент. Примечания 1538 могут быть предоставлены. На практике могут быть предоставлены более полнофункциональные или другие пользовательские интерфейсы.
Тем не менее, в этом примере целевой действующий субъект не проанализировал элемент за нужное время. Следовательно, действующий субъект (к примеру, тот же действующий субъект, который выбрал инициализацию действия 1522 анализа, или другой действующий субъект) выбрал добавить действие 1552 передачи (распространения) во время исполнения потока деятельности (к примеру, до того, как поток деятельности завершился). Следовательно, новое действие 1552 инициализируется и помещается в поток 1500 деятельности. В результате задача переназначается другому целевому пользователю. Если требуется, сообщение прерывания может быть отправлено действию 1522 анализа, которое может предпринять соответствующие шаги (к примеру, отмену задачи для первого целевого действующего субъекта).
В результате новой задачи новый пользовательский интерфейс 1562 появляется для целевого действующего субъекта. Кроме того, пользовательский интерфейс может включать в себя элементы 1564, 1566 и 1568.
Изображенные действия приведены только для примера. На практике множество специальных действий может быть предоставлено в свете ограничений.
Фиг. 16 иллюстрирует примерный способ 1600 для реализации специальных потоков деятельности. На этапе 1612 принимается запрос, чтобы добавить действие к потоку деятельности во время исполнения потока деятельности. На этапе 1622 действие компонуется в поток деятельности во время исполнения потока деятельности.
Пример 14 - Примерная возможность компоновки для добавления специальных действий в модель деятельности
Помимо поддержки моделей деятельности для исполнения потоков деятельности априори и специальной компоновки потоков деятельности службы последовательности выполняемых действий могут поддерживать добавление действий в потоки деятельности на основе модели деятельности на специальной основе.
Фиг. 17 иллюстрирует примерный поток 1700 деятельности на основе модели деятельности, к которому было добавлено действие 1788 на специальной основе. В этом примере поток деятельности - это экземпляр модели активности, и он включает в себя действия 1722, 1724, 1726, 1728 и 1730. На основе добавления действия 1788 поток исполнения может быть изменен. Хотя действующие субъекты не показаны, действия могут быть направлены к действующим субъектам (к примеру, чтобы назначить задачи).
Фиг. 18 иллюстрирует примерный способ 1800 для добавления действий к потоку деятельности на основе модели деятельности на специальной основе. На этапе 1812 доступные специальные действия определяются (к примеру, на основе ограничений). Например, доступные действия затем могут быть отправлены в клиентское программное обеспечение для представления действующему субъекту-человеку для выбора.
На этапе 1822 принимается указание о требуемом специальном действии. Например, клиентское программное обеспечение может показывать, какой параметр выбрал пользователь.
На этапе 1832 специальное действие компонуется в поток деятельности. Служба отслеживания служб последовательности выполняемых действий может быть обновлена, чтобы указать, что новое действие было добавлено и какой действующий субъект добавил его.
Пример 15 - Примерные специальные действия для задач
Специальный конкретный для задачи набор специальных действий может быть сделан доступным для задач. Эти специальные действия могут быть представлены для выбора действующим субъектом каждый раз, когда задача вовлечена (к примеру, даже если они появляются в ассоциированной модели деятельности). Такие специальные действия могут быть выборочно представлены на основе ограничений.
Примерные специальные действия для задач включают в себя передачу (распространение), делегирование полномочий и т.п. Например, когда снабжен задачей, действующий субъект может также быть снабжен опцией (возможностью) для передачи или делегирования задачи. Доступна ли такая опция, и могут ли вероятные цели быть контролируемы ограничениями. Эти опции могут быть также представлены в графическом виде хода выполнения потока деятельности. Таким образом, действующий субъект, отслеживающий ход выполнения, может легко передвинуть исполнение посредством передачи или делегирования полномочий.
Возможность задавать эти специальные действия, связанные с задачами, позволяет сделать службы последовательности выполняемых действий более полезными, поскольку обработка последовательности выполняемых действий имеет больше возможностей отвечать на непредвиденные обстоятельства.
Пример 16 - Примерные ограничения на основе личности пользователя
Фиг. 19 иллюстрирует примерную структуру 1900, в которой службы 1912 последовательности выполняемых действий поддерживают ограничения на основе личности (идентификационной информации) действующего субъекта. В примере действующий субъект-человек представлен действующим субъектом 1922 в службах 1912 последовательности выполняемых действий.
Заданные ограничения 1914 будут определять, может ли действующий субъект 1922 (к примеру, исходный действующий субъект) выбирать действие 1931 для инициализации и какие цели 1934 могут быть выбраны. Определение может быть основано на личности (идентификационной информации) действующего субъекта 1922. Такие пункты идентификационной информации могут включать в себя имя действующего субъекта, членом каких групп(ы) является действующий субъект и членом какой роли(ей) является действующий субъект 1922. Помимо этого, относительное ограничение позволяет задавать, что действующий субъект 1922 имеет взаимоотношение с другим действующим субъектом.
Дополнительно ограничения 1914 будут определять, какие целевые действующие субъекты 1934 могут быть заданы для действия 1931. Целевым действующим субъектом 1934 может быть один действующий субъект, группа или какое-либо другое обозначение. Различные ограничения могут ассоциировать (связывать) действие (к примеру, посредством идентификатора действия, ассоциированного с определением действия) с разрешенными инициализирующими действующими субъектами и целевыми действующими субъектами (к примеру, для конкретного подвергаемого обработке действующего субъекта).
На практике ограничения могут быть реализованы так, что действующий субъект-человек, ассоциированный с действующим субъектом 1922, видит только соответствующие опции, указанные ограничениями 1914. Таким образом, действующему субъекту-человеку не предоставляется слишком много вариантов, и он инструктируется в ходе обработки последовательности выполняемых действий.
Фиг.20 иллюстрирует примерный способ 2000 представления действия и целевых опций на основе ограничений действующего субъекта. На этапе 2012 вероятные действия представлены на основе идентификационной информации действующего субъекта. На этапе 2033 вероятные целевые действующие субъекты представлены на основе идентификационной информации действующего субъекта. На практике службы последовательности выполняемых действий могут контролировать такое представление посредством представления опций для представления клиентским программным обеспечением, которое может принимать варианты выбора (к примеру, из списка для выбора переключателей, комбинированного окна и т.п.).
Пример 17 - Примерные транзитивные действия
Последовательность выполняемых действий также может поддерживать ограничения для транзитивных действий. Транзитивные действия включают в себя такие действия, которые могут быть применены к другим действиям, которые обычно уже имеют ассоциированные целевые действующие субъекты. Примеры транзитивных действий включают в себя делегирование полномочий и передачу.
Фиг. 21 иллюстрирует примерную структуру 2100, в которой система 2112 последовательности выполняемых действий применяет ограничения к транзитивным действиям. В примере действие 2131 уже было применено к целевому действующему субъекту 2134 или "предписанному" действующему субъекту. Действующий субъект 2122 (к примеру, исходный действующий субъект) применяет транзитивное действие 2144 к действию 2131.
Появится ли транзитивное действие 2144 в качестве опции для действующего субъекта 2122, будет зависеть от ограничений 2114. Такое определение может быть основано на идентификационной информации действующего субъекта 2122, типе транзитивного действия 2144, типе действия 2131, предписанном действующем субъекте 2134 или их сочетании. Наконец, разрешенные цели 2148 также могут быть контролируемы посредством ограничений 2114 (к примеру, на основе тех же рассуждений или сочетания рассуждений, как и для того, появится ли опция).
Фиг.22 иллюстрирует примерный способ представления вероятных действий и вероятных целей на основе предписанного пользователя. На этапе 2212 вероятные действия представлены на основе, по меньшей мере, предписанного действующего субъекта. На этапе 2233 вероятные цели представлены на основе, по меньшей мере, предписанного действующего субъекта.
Относительные ограничения могут быть использованы в любом из сценариев. Например, действующий субъект может быть ограничен выполнением конкретного транзитивного действия только на тех действующих субъектах, управляемых действующим субъектом, и т.п.
Пример 18 - Примерное отслеживание
Фиг.23 иллюстрирует примерную структуру 2300, в которой службы 2312 последовательности выполняемых действий поддерживают отслеживание. В примере службы 2312 последовательности выполняемых действий поддерживают исполнение одного или более потоков 2322A-2322N деятельности. Информация об исполняющихся потоках может быть сохранена в базе 2332 данных отслеживания для дальнейшего извлечения. Например, индикации сообщений для и от действий могут быть сохранены с помощью настраиваемого под индивидуальные потребности блока перехвата, чтобы перехватывать и сохранять информацию, указывающую сообщения. Помимо этого, другая информация может быть сохранена для создания отчетов о состоянии, показывающих ход выполнения обработки последовательности выполняемых действий.
Фиг. 24 иллюстрирует примерный способ 2400 отслеживания состояния потока деятельности компонуемых действий. На этапе 2412 сообщение в и от компонуемого действия перехватывается. На этапе 2422 указание на сообщение сохраняется в базе данных отслеживания.
Пример 19 - Примерное изображение состояния последовательности выполняемых действий
Фиг. 25 иллюстрирует примерный пользовательский интерфейс 2500, представляющий графическое представление состояния последовательности выполняемых действий на основе отслеживания (к примеру, собранных сообщений). В примере различные окна 2521, 2522, 2523, 2524, 2525 и 2526 показывают действующих субъектов, участвующих в обработке последовательности выполняемых действий (к примеру, потока деятельности), которые назначили или которым были назначены задачи. Помимо этого, пользовательский интерфейс 2500 может представлять обмен данными между действующими субъектами. Например, стрелка может включать в себя индикацию 2534 того, что Джулиан утвердила документ. Эти индикации могут быть текстовыми, в виде значков и т.п. Другая стрелка включает в себя индикацию 2532 того, что задача была передана.
Фиг. 26 иллюстрирует примерный способ 2600 для представления состояния потока деятельности. На этапе 2612 хранилище отслеживания опрашивается. На этапе 2622 на основе результатов запроса поток деятельности изображается визуально.
На практике может быть представлено множество пользовательских интерфейсов. Помимо этого, пользовательский интерфейс может представлять дополнительные опции для действующих субъектов-людей, посредством которых они могут участвовать в последовательности выполняемых действий, когда они их отслеживают. Например, может быть представлена опция передать (распространить) или прервать опцию.
Пример 20 - Примерная реализация в качестве веб-служб
В любом из описанных в данном документе примеров службы последовательности выполняемых действий могут быть представлены клиентам в качестве веб-службы. Например, пользовательские интерфейсы могут быть предоставлены в форме HTML, которая может быть представлена клиентом.
Пример 21 - Примерные методики полнофункционального интерфейса
В любом из описанных в данном документе примеров службы последовательности выполняемых действий могут быть использованы посредством полнофункционального пользовательского интерфейса. Например, пользовательский интерфейс для служб последовательности выполняемых действий может быть интегрирован в стандартные программы программного обеспечения, например, программу электронной почты или программу текстового процессора. Таким образом, стандартное знакомое программное обеспечение может быть использовано в качестве клиента для служб последовательности выполняемых действий. Обмен может быть осуществлен посредством отправки сообщений XML (к примеру, согласно протоколу SOAP), и пользовательские интерфейсы могут быть изображены посредством HTML.
Фиг. 27 иллюстрирует примерный пользовательский интерфейс 2700, в котором службы последовательности выполняемых действий представлены в качестве части пользовательского интерфейса программы электронной почты. В этом примере программа электронной почты включает в себя знакомый список 2712 папок и папку 2722 входящих сообщений. В качестве части папки входящих сообщений появляется задача. При выборе предварительное изображение электронной почты появляется в панели 2762 предварительного просмотра.
Пользовательский интерфейс показывает, что задачей для целевого действующего субъекта (к примеру, пользователя, анализирующего электронную почту) является анализ бюджетного документа. Элементы 2764, 2766 и 2768 пользовательского интерфейса могут быть использованы, чтобы передавать данные обратно службам последовательности выполняемых действий. Например, при активации кнопки 2764 сообщение отправляется обратно действию, которое инициировало задачу для целевого действующего субъекта. После этого соответствующие шаги могут быть предприняты ассоциированным потоком деятельности.
Вместо панели 2762 может быть показана панель 2800 фиг. 28. В этом примере помимо стандартных опций задачи суб-панели 2862 (к примеру, элементов 2864, 2866 и 2868 пользовательского интерфейса) опции для специальных действий появляются в суб-панели 2872 (к примеру, элемент 2876 пользовательского интерфейса).
Фиг. 29 иллюстрирует примерный способ 2900 представления и принятия вариантов выбора посредством полнофункционального пользовательского интерфейса последовательности выполняемых действий. На этапе 2912 связанный с последовательностью выполняемых действий пользовательский интерфейс представляется в полнофункциональном приложении. На этапе 2922 выбор пользователя (к примеру, действующего субъекта-человека) принимается посредством пользовательского интерфейса.
Фиг. 30 иллюстрирует пользовательский интерфейс 3000, в котором элементы пользовательского интерфейса для осуществления доступа к службам последовательности выполняемых действий представляются как интегрированные в программу редактирования документа (к примеру, текстовый процессор или электронную таблицу). В этом примере документ представлен в панели 3062 документов. Наряду с панелью 3062 документов появляются опции 3072 последовательности выполняемых действий. В этом примере появляются специальные действия, посредством которых действующий субъект может выбрать действие и целевого действующего субъекта. Инициирование действия может быть выполнено посредством элемента 3076 пользовательского интерфейса. На практике могут быть представлены дополнительные или различные опции (к примеру, для утверждения редактируемого документа).
Пример 22 - Примерная открытость
Фиг.31 иллюстрирует примерную структуру 3100, посредством которой спецификация параметров активации для активации действия 3136 может быть получена. В этом примере клиентское программное обеспечение 3134 (к примеру, действие, службы последовательности выполняемых действий или какое-либо другое программное обеспечение) отправляет запрос действию 3136, которое отвечает спецификацией параметров для активации действия (к примеру, списком параметров, заданным разработчиком действия 3136). На практике, поскольку действие 3136 еще не инициализировано, запрос (к примеру, задание типа действия) может быть заполнен службами последовательности выполняемых действий, которые могут принимать во внимание список типов действий и параметров для каждого, чтобы определить спецификацию параметров активации.
Спецификация может быть предоставлена в форме или преобразована в форму HTML, посредством которой параметры могут быть собраны. Например, действие просмотра может задавать, что должны быть обеспечены цели, и таким образом генерировать надлежащую форму HTML для завершения действующим субъектом. Ограничения могут быть использованы, чтобы заполнить информацию надлежащим целевым действующим субъектам.
Фиг. 32 иллюстрирует примерный способ 3200 обнаружения спецификации параметров активации для действия. На этапе 3212 принимается запрос для спецификации параметров активации. На этапе 3222 спецификация предоставляется в ответ на запрос.
Аналогичный подход может быть использован для открытости спецификации параметров модели деятельности. Открытость может быть выполнена во время исполнения действия или потока деятельности.
Пример 23 - Пример шаблона действия
Чтобы облегчить разработку действий, разработчикам может быть предоставлен образец. Фиг. 33 иллюстрирует примерную структуру 3300, включающую определение 3314 действия-шаблона. Шаблон может быть отредактирован на языке визуального программирования, который затем может сгенерировать надлежащий исполняемый код для действия.
В этом примере интерфейсы для действия представлены контактами 3322, 3324, 3326 и 3328. Шаблон отвечает за прием сообщения активации посредством интерфейса 3322 активации. Логика 3332 активации, заключенная в действии, принимает сообщение активации и возвращает в цикле сообщение ответа на активацию себе, чтобы инициализировать значения, которые коррелируют другие сообщения, принятые шаблоном действия.
Шаблон 3314 дополнительно отвечает за зависимую компоновку (к примеру, сценарии синхронизации). Например, логика 3342 синхронизации и логика 3344 прослушивания могут быть исполняемы параллельно. Если действие было составлено зависимым способом (к примеру, его дальнейшее исполнение зависит от приема сообщения для другого действия), логика 3342 синхронизации может заблокировать исполнение до тех пор, пока сообщение не будет принято от интерфейса 3324 синхронизации.
Параллельно логика 3344 прослушивания прослушивает сообщения прерывания или завершения. Если сообщение прерывания принято от интерфейса 3326 прерывания, логика прерывания (к примеру, состояние отката) может быть исполнена.
Если не заблокирована или разблокирована специфическая для действия обработка (к примеру, бизнес-логика) 3352 может быть исполнена. Наконец, логика 3362 завершения может быть исполнена, и сообщение завершения отправлено в интерфейс 3328 завершения. Сообщение принимается действием в логике 3344 прослушивания и также служит причиной завершения параллельной ветки.
На практике может быть включена дополнительная или другая логика. После того, как разработка завершена, определение действия может быть установлено в службы последовательности выполняемых действий и соответствующие ограничения заданы как ассоциативно связанные с действием.
Пример 24 - Примерное исполнение технологий последовательности выполняемых действий
Фиг. 34, 35, 36, 37 показывают примерное исполнение технологий последовательности выполняемых действий. В этом примере клиент отправляет запрос на предложения (RFP) менеджеру по счетам, который привлекает группу экспертов, чтобы скоординировать ответ на RFP.
Фиг. 34 иллюстрирует вовлеченных действующих субъектов. Клиент 3410 отправляет менеджеру 3420 по счетам документ RFP (к примеру, посредством электронной почты). Например, документом может быть документ текстового процессора. Менеджер по счетам может отправить задачи экспертам 3430A-3430D, чтобы завершить обработку, необходимую для ответа на RFP.
Фиг. 35-37 иллюстрируют примерные снимки экрана. Фиг. 35 иллюстрирует примерную программу 3510 электронной почты, в которой электронная почта 3520 была принята менеджером по счетам от клиента. В электронную почту включен документ RFP в форме вложения 3530 в электронную почту. В этом примере менеджер по счетам может запустить поток деятельности на основе модели деятельности посредством переадресации электронной почты 3520 псевдониму электронной почты (к примеру, "Утверждение RFP"). Программное обеспечение электронной почты может обработать электронную почту на основе правил обработки электронной почты, чтобы запустить поток деятельности на основе модели деятельности, который генерирует надлежащие задачи для экспертов 3430A-3430D и может включать в себя вложение 3530 (или ссылку на него) в качестве части задачи.
Фиг. 36 иллюстрирует примерный пользовательский интерфейс, представленный одному из экспертов 3430A-3430D, когда документ, ассоциированный с задачей, открывается. Пользовательским интерфейсом может быть знакомая программа 3610 редактирования документов (к примеру, текстовый процессор), которая представляет документ 3620 (к примеру, на основе вложения 3530).
Пользовательский интерфейс также может включать в себя панель 3630, которая дает возможность одному из экспертов 3430A-3430D передать или делегировать задачу другому действующему субъекту. В этом примере просматривающий действующий субъект делегирует задачу действующему субъекту "Керри" и активирует элемент 3635 пользовательского интерфейса.
Благодаря признаку отслеживания технологий последовательности выполняемых действий представление 3700 позволяет показывать состояние вышеописанной последовательности выполняемых действий. Клиент Петер 3721 инициировал последовательность выполняемых действий посредством отправки электронной почты. Например, вместо переадресации электронной почты вручную действующий субъект Дженни 3722 могла настроить правило в своей папке входящих сообщений электронной почты, чтобы автоматически запускать модель деятельности на основе распознавания "Новый RFP" в теме сообщения. Эксперты 3723-3725 приняли RFP для анализа. Джулиан 3723 утвердила RFP, а Майкл 3725 делегировал свою задачу Керри 3726, как показано индикатором 3732.
Пример 25 - Примерное уведомление о задаче
Фиг. 38 иллюстрирует снимок экрана примерного уведомления 3800, отправляемого (к примеру, посредством электронной почты), когда задача назначена действующему субъекту-получателю. Уведомление может давать инструкции о том, как отвечать на задачу. Уведомление может включать в себя гиперссылку на документ и гиперссылку на задачу.
Пример 26 - Примерные схемы для типов сообщений
Примерные схемы для различных типов сообщений показаны ниже. Типы сообщений могут включать в себя активацию, ответ на активацию, синхронизацию, задачу, завершение и прерывание. Хотя некоторые примеры указывают, что схема не должна быть модифицирована в целях соответствия схемы, альтернативные реализации могут использовать другой набор схем, выполняющих аналогичную функциональность. Например, хотя в примерах заданы глобально-уникальные идентификаторы (GUID), другие идентификаторы (к примеру, другой уникальный идентификатор) могут быть использованы вместо них. В примерах система последовательности выполняемых действий иногда называется человеческой системой последовательности выполняемых действий (HWS).
Пример 27 - Примерная схема для типа сообщения активации
Сообщение HwsActivate - это примерное сообщение активации, используемое, чтобы предоставлять параметры действию в ходе его активации. Действие может иметь, по большей части, одну схему сообщения активации, ассоциированную с ним. В этом примере сообщение HwsActivate имеет три дочерних элемента в узле HwsMessage. Это HwsSection, ActionSection и Payloads. Они описаны ниже.
HwsSection: HwsSection содержит определения элементов и атрибутов XML, которые зарезервированы для использования системой Hws. Элементы или атрибуты, заданные в данном разделе, не должны быть модифицируемы. Таблица 2 показывает примерный список элементов/атрибутов, заданных в узле HwsSection.
Типичные элементы/атрибуты в узле HwsSection
макс. вхож-дение
Свойство
Свойство\Имя
Свойство\Описание
Свойство\Тип
ActionSection: ActionSection настраивается разработчиками действия и может содержать любые конкретные для действия параметры и значения, которые должны быть доставлены действию в ходе обработки. Этот раздел может содержать элементы, которые соответствуют целям-людям для действия. Значения элементов/атрибутов в ActionSection не отслеживаются блоком перехвата Hws. Если необходимы свойства, которые должны отслеживаться, их задают в документе экземпляра в рамках заранее заданного набора HwsSection\ActionProperties.
Payloads: Узел Payloads в схеме - это заполнитель для приложений, чтобы задавать дополнительную информацию, которая может быть необходима для включения в другие сообщения, отправляемые действием.
Annotations: Схема сообщения активации содержит примечания, используемые системой Hws. Это некоторые свойства, которые задаются на уровне корневого узла схемы, и некоторые свойства, которые задаются на уровне узла элементов.
Свойства узла схемы: Следующие свойства задаются на уровне узла схемы:
Description: Значение этого свойства используется, чтобы описать действие, с которым ассоциировано сообщение активации.
Incoming Sync messages: Это свойство задает целевое пространство имен сообщений синхронизации, которые принимаются гармоничным сочетанием, ассоциированным с сообщением активации.
Incoming Sync messages: Это свойство задает целевое пространство имен сообщений синхронизации, которые отправляются гармоничным сочетанием, ассоциированным с сообщением активации.
Свойства узла элементов: Для узлов элементов, заданных в элементе ActionSection схемы, документ Hws задает следующее свойство:
Target: Это свойство - булево значение. Истинное значение показывает, что узел элементов - это цель-человек, который является получателем одного или более сообщений задач, отправленных действием, ассоциированных с сообщением активации. Ложное значение или если значение не задано, показывает, что узел не является целью-человеком.
Каждая схема сообщения активации может иметь целевое пространство имен, которое уникально определяет ее в наборе развернутых схем.
Пример 28 - Примерная схема для типа сообщения ответа на активацию
Сообщение HwsActivateResponse - это примерное сообщение ответа на активацию, используемое внутренне шаблоном действия, чтобы инициализировать набор переменных корреляции, которые используются для приема других сообщений в образце.
Сообщение HwsActivateResponse имеет только один дочерний элемент в узле HwsMessage. Это HwsSection. Он описан ниже.
HwsSection: HwsSection содержит определения элементов и атрибутов XML, которые зарезервированы для использования системой Hws. Элементы или атрибуты, заданные в данном разделе, не должны быть модифицируемы. Таблица 3 показывает примерный список элементов/атрибутов, заданных в узле HwsSection.
Примеры элементов/атрибутов в узле HwsSection
Type
Annotations: Схема сообщения ответа на активацию имеет примечание для описания сообщения. Значение этого примечания не доступно для редактирования.
TargetNamespace данной схемы задается посредством URL-адреса (к примеру, http://[базовый]/Hws_ActivateResponse). Эта схема может быть скомпилирована в скомпонованный блок (к примеру, DLL) и использована шаблоном действия. Сообщение создается в действии и отправляется/принимается по порту прямой связи.
Пример 29 - Примерная схема для типа сообщения синхронизации
Сообщение HwsSynchronize - это примерное сообщение синхронизации, отправляемое от одного действия другому, чтобы разблокировать исполнение принимающего действия. Экземпляр принимающего действия должен быть активирован с помощью свойства IsDependentOnParent в своем сообщении активации, установленном равным значению «истина», чтобы иметь возможность ждать сообщения синхронизации.
Сообщение Hws_Synchronize имеет три дочерних элемента в узле HwsMessage. Это HwsSection, ActionSection и Payloads. Они описаны ниже.
HwsSection: HwsSection содержит определения элементов и атрибутов XML, которые зарезервированы для использования системой Hws. Элементы или атрибуты, заданные в данном разделе, не должны быть модифицируемы. Таблица 4 показывает примерный список элементов/атрибутов, заданных в узле HwsSection.
Пример элементов/атрибутов в узле HwsSection
ActionSection: ActionSection является настраиваемым разработчиками действия и может содержать любые специфические для сценария параметры и значения, которые должны быть доставлены принимающему действию.
Payloads:
Annotations: Схема сообщения синхронизации имеет примечание для описания сообщения. Это свойство задается на уровне корневого узла схемы.
Свойства узла схемы: Следующие свойства могут быть заданы на уровне узла схемы:
Description: Значение этого свойства используется, чтобы описать сообщение синхронизации.
Каждая схема сообщения синхронизации может иметь целевое пространство имен, которое уникально определяет ее в наборе развернутых схем. Если целевое пространство имен TargetNamespace сообщения синхронизации изменяется или если новая схема сообщения синхронизации добавляется к действию, то свойства Incoming Sync Messages и Outgoing Sync Messages сообщения активации (действия, которое либо отправляет это сообщение синхронизации, либо принимает его) должны также быть обновлены. Сообщения синхронизации отправляются и принимаются по портам прямой связи.
Пример 30 - Примерная схема для типа сообщения задачи
Схема сообщения HwsTask - это пример схемы, используемой для сообщений, которые отправляются участвующим целям действия. Действие может отправлять сообщение задачи одного или более типов. Оно также может отправлять один или более экземпляров данного типа сообщения задачи. Сообщение HwsTask также может быть использовано для отправки ответов обратно в действие.
Сообщение HwsTask имеет три дочерних элемента в узле HwsMessage. Это HwsSection, ActionSection и Payloads. Они описаны ниже.
HwsSection: HwsSection содержит определения элементов и атрибутов XML, которые зарезервированы для использования системой Hws. Элементы или атрибуты, заданные в данном разделе, не должны быть модифицируемы. Таблица 5 показывает примерный список элементов/атрибутов, заданных в узле HwsSection.
Примерные элементы/атрибуты в узле HwsSection
ActionSection: ActionSection является настраиваемым разработчиками действия и может содержать любые конкретные для сценария параметры и значения, которые должны быть доставлены участвующим целям. Он также может быть использован, чтобы задавать любые параметры, которые цели могут предоставлять в своих ответах.
Payloads: Узел Payloads в схеме - это заполнитель для приложений, чтобы задавать дополнительную информацию, которая может быть необходима для включения в другие сообщения, отправляемые действием.
Annotations: Схема сообщения задачи содержит примечания, используемые системой Hws. Эти свойства задаются на уровне корневого узла схемы.
Свойства узла схемы: Следующие свойства могут быть заданы на уровне узла схемы:
Description: Значение этого свойства используется, чтобы описать схему сообщения задачи.
Target XPath: Это свойство задает Xpath целевых узлов в сообщении активации, которым передается это сообщение задачи.
Каждая схема сообщения задачи может иметь целевое пространство имен, которое уникально определяет ее в наборе развернутых схем.
Пример 31 - Примерная схема для типа сообщения завершения
Сообщение HwsFinish - это пример сообщения завершения, используемого внутренне действием, и оно отправляется, когда сообщение завершает исполнение. Сообщение HwsFinish имеет только один дочерний элемент в узле HwsMessage. Это HwsSection. Он описан ниже.
HwsSection: HwsSection содержит определения элементов и атрибутов XML, которые зарезервированы для использования системой Hws. Элементы или атрибуты, заданные в данном разделе, не должны быть модифицируемы. Таблица 6 показывает примерный список элементов/атрибутов, заданных в узле HwsSection.
Примерные элементы/атрибуты в узле HwsSection
Annotations: Схема сообщения ответа на активацию имеет примечание для описания сообщения. Значение этого примечания не доступно для редактирования.
TargetNamespace данной схемы задается посредством URL-адреса (к примеру, http://[базовый]/Hws_Finish). Эта схема может быть скомпилирована в скомпонованный блок (к примеру, DLL) и использована шаблоном действия. Сообщение создается в действии и отправляется/принимается по порту прямой связи.
Пример 32 - Примерная схема для типа сообщения прерывания
Сообщение Hws_Interrupt - это пример сообщения прерывания, используемого, чтобы прерывать запуск экземпляра действия. Сообщение прерывания может быть отправлено отдельному экземпляру действия, всему потоку деятельности или всему экземпляру модели деятельности. Предусмотрено два типа прерывания - прекращение выполнения и откат.
Сообщение Hws_Interrupt имеет только один дочерний элемент в узле HwsMessage. Это HwsSection. Он описан ниже.
HwsSection: HwsSection содержит определения элементов и атрибутов XML, которые зарезервированы для использования системой Hws. Элементы или атрибуты, заданные в данном разделе, не должны быть модифицируемы. Таблица 7 показывает примерный список элементов/атрибутов, заданных в узле HwsSection.
Примерные элементы/атрибуты в узле HwsSection
Выбор/ActionlnstancelD
Вариант/ActivityFlowED
Вариант/ActivityModellnstanceID
Annotations: Схема сообщения прерывания имеет примечание для описания сообщения. Значение этого примечания не доступно для редактирования.
TargetNamespace данной схемы задается посредством URL-адреса (к примеру, http://[базовый]/Hws_Finish). Эта схема может быть скомпилирована в скомпонованный блок (к примеру, DLL) и использована шаблоном действия. Экземпляр сообщения прерывания принимается по ActionInterruptPort в образце. Сообщение прерывания на уровне потока деятельности или уровне экземпляра модели деятельности отправляется каждому действию, активному в данный момент в потоке деятельности или экземпляре модели деятельности. Тип прерывания "прекращение выполнения" служит причиной того, что прерванное действие завершается без компенсации за работу, выполненную действием. Тип прерывания "откат" вынуждает действие компенсировать работу, уже выполненную действием.
Пример 33 - Примерная реализация архитектуры
Фиг.39 иллюстрирует примерную реализацию архитектуры системы 3900, включающую в себя службы 3902 последовательности выполняемых действий. В этом примере клиентские приложения 3904 могут использовать службы 3902 последовательности выполняемых действий, чтобы разрешить действующим субъектам создавать и участвовать в последовательности выполняемых действий. Службы 3902 последовательности выполняемых действий могут предоставлять три основные службы клиентским приложениям: компоновки 3908 последовательности выполняемых действий, ограничения 3906 последовательности выполняемых действий и отслеживания и просмотра 3910 последовательности выполняемых действий.
Последовательности выполняемых действий могут быть созданы посредством компоновки действий 3912 в рамках потока деятельности. Компоновка действий 3912 управляется ограничениями 3914, которые активируются службами 3902 последовательности выполняемых действий. Ограничения 3914 могут быть заданы в любом числе известных способов, в том числе посредством администрирования и управления последовательностью выполняемых действий (к примеру, MMC) или посредством административных API-интерфейсов программируемым способом.
Определение этих ограничений 3914 может использовать факты, раскрытые средствами извлечения фактов. Средства извлечения фактов могут реализовать стандартный интерфейс так, чтобы служба 3906 ограничения могла запрашивать эти факты и применять их к последовательности выполняемых действий. Средство извлечения фактов может раскрывать факты из любого базового источника 3916 данных, например, базы данных Active Directory или SQL.
Клиентские приложения 3904 могут регистрироваться в службах 3902 последовательности выполняемых действий, когда хотят принимать участие в потоке деятельности. Служба 3908 компоновки может ассоциировать уникальный идентификатор с клиентским запросом и использовать этот идентификатор, чтобы отслеживать действия 3912, которые действующий субъект выполняет в качестве части потока деятельности.
Служба 3910 отслеживания может быть использована, чтобы отслеживать состояние потока деятельности и восстанавливать поток деятельности, запрошенный клиентом. Когда клиент пытается присоединить действие 3912 к потоку деятельности, служба 3906 ограничения позволяет проверить ограничения (к примеру, на основе хранилища 3916 фактов или состояния потока), чтобы узнать, какие действия 3912 могут быть присоединены в поток деятельности. Например, отображаемые опции могут быть ограничены опциями, доступными в рамках ограничений. После того, как пользователь выбирает действие из ограниченного набора, служба 3908 компоновки позволяет скомпоновать выбранные действия, которые уже используются.
Действия могут быть оснащены, чтобы опускать события отслеживания, которые потреблены (обработаны) службой 3910 отслеживания. К этим событиям затем может быть осуществлен доступ клиентом, чтобы предоставить новую последовательность выполняемых действий действующему субъекту.
Пример 34 - Примерная реализация пользовательского интерфейса для осуществления доступа к службам последовательности выполняемых действий
Фиг.40 иллюстрирует примерную реализацию пользовательского интерфейса 4000 для осуществления доступа к службам последовательности выполняемых действий. В этом примере показано графическое изображение потока деятельности, и пользователю предоставляется вариант передать задачу (к примеру, посредством щелчка правой кнопкой мыши на действующем субъекте).
Пример 35 - Пример реализации шаблона для создания действий
Фиг. 41 иллюстрирует пример образца 4100 для создания действий. В этом примере шаблон 4100 представлен в среде визуального программирования, но он может быть представлен другими способами. Шаблон 4100 может включать в себя множество сценариев, так чтобы разработчикам нужно было только выбрать логику для конкретного сценария. Например, зависимая компоновка может быть поддерживаема шаблоном.
Шаблон 4100 может включать в себя логику 4110 приемника активации. Действие может принимать сообщение активации по однонаправленному порту, который привязан к протоколу HTTP. Затем оно может создавать экземпляр сообщения ActivateResponse. Сообщение ответа используется, чтобы инициализировать наборы корреляции, используемые далее в гармоничном сочетании. Действие отправляет сообщение самому себе. Оно может использовать операцию SendOrReceiveActivateResponse для ActionDirectBoundOutPort, чтобы отправить сообщение, и принимает его обратно с помощью ActionDirectBoundlnPort. Сегмент 4110 шаблона может также проверять, выступают ли в качестве значения ParentActionlnstancelD или ActivityModellnstancelD пустые идентификаторы (к примеру, пустые GUlD). Если выступают, оно может сгенерировать новые значения идентификатора для этих свойств. Значения будут пустыми идентификаторами, если инициализированное действие не имеет родительского действия или если действие не инициализируется как часть модели деятельности. Если имеется множество таких экземпляров действия, равное количество неуникальных подписок на типы сообщения завершения и прерывания может быть создано, что может неблагоприятно повлиять на производительность.
Эта ситуация исключается посредством генерирования новых идентификаторов и не представляет опасности, поскольку подписки, вероятнее всего, не будут удовлетворены в таких сценариях в любом случае. Уникальность подписки гарантирует, что производительность маршрутизации сообщений для допустимых подписчиков не будет снижаться.
Параллельное предложение 4120 имеет две ветви. Левая ветвь дает возможность компоновки действия в другое (к примеру, 4130) и также предоставляет узел для настраиваемой разработки в рамках шаблона (к примеру, 4140). Правая ветвь позволяет действию прослушивать сообщения прерывания и завершения (к примеру, 4150).
Модель 4130 принятия решений (увеличенная как фиг.42) проверяет, было ли активировано действие с намерением его компоновки как зависимого или другого действия. На этапе 4210 она проверяет предложенное свойство IsDependentOnParent в сообщении активации. Если да, действие ждет приема сообщения синхронизации или сообщения завершения от родителя на этапе 4230.
Формы приема сообщения 4250 синхронизации или сообщения 4240 завершения используют наборы корреляции на основе идентификатора экземпляра родительского действия. После получения сообщения синхронизации исполнение переходит к ScopeAllActionSpecificLogic и может исполнять логику, выбранную разработчиком на этапе 4255.
Прием вместо этого сообщения завершения служит причиной для завершения действия на этапе 4245. В этом случае перед завершением действие отправляет сообщение завершения в окно сообщений по порту прямой связи, чтобы указать свое окончание.
Набор корреляции, используемый в сообщении синхронизации, может быть дополнен, чтобы включать в себя дополнительные свойства, предложенные сообщением активации. Дополнительные наборы корреляции могут быть использованы также в форме приема для сообщения 4250 синхронизации.
Прослушивание сообщения завершения параллельно с сообщением синхронизации дает возможность заканчивать зависимые действия, если родительское действие завершается без отправки сообщения синхронизации.
Настраиваемая логика (к примеру, бизнес-логика) может содержаться в узле для настраиваемой разработки 4240. Имеется область транзакций и блок компенсации, заданный в узле 4240. Это дает возможность создания настраиваемой компенсации, если в действии отправляется сообщение прерывания, запрашивающее операцию отката, или если возникло неизвестное исключение в действии.
4250 прослушивает экземпляр сообщения прерывания на основе множества подписок. Оно также прослушивает сообщение завершение от самого себя. Действие подписывается на сообщения прерывания на трех уровнях детализации: уровень экземпляра действия, уровень потока деятельности и уровень модели деятельности. Сообщение прерывания может запросить прекращение выполнения или откат операций действия. Прием сообщения прерывания вызывает исключение того, чтобы прекращение выполнения или откат происходили в действии. Эти исключения фиксируются в шаблоне (к примеру, на этапе 4260), и блок обработки исключений запрашивает компенсацию за область ScopeAllActionSpecificLogic на этапе 4240.
Другое сообщение в блоке 4250 прослушивания - это сообщение завершения от самого себя. Это сообщение генерируется самим действием и отправляется в окно сообщений через порт прямой связи в левой ветви параллельного предложения 4220. Сообщение отправляется сразу после того, как область ScopeAUActionSpecificLogic (к примеру, на этапе 4240) завершается. Прием этого сообщения в правой ветви служит причиной того, что модель прослушивания ListenForAbortOrFinish завершается, и ветвь заканчивается.
Сегмент 4260 действия имеет блоки обработки исключений для исключений "прекращение выполнения", "откат" и "неизвестное". Исключения "прекращение выполнения" и "откат" генерируются в действии после получения сообщения прерывания. Блок обработки исключений для исключения "прекращение использования" создает и затем отправляет сообщение завершения, указывающее, что действие завершается, и затем переходит в состояние завершения. Блок обработки исключений для исключения "откат" вызывает блок компенсации CompensateForAllActionSpecificLogic перед созданием и отправкой сообщения завершения. После этого он переходит в состояние завершения.
Блок обработки исключений для исключения "неизвестное" также вызывает блок компенсации CompensateForAllActionSpecificLogic перед созданием и отправкой сообщения завершения и завершением.
Каждый блок обработки исключений может отправлять сообщение завершения в окно сообщений через порт прямой связи. Это сообщение указывает на другие дочерние действия, которые были зависимо скомпонованы к этому действию и не приняли сообщение синхронизации, чтобы завершиться. Сообщение завершения принимается зависимо скомпонованными дочерними действиями (к примеру, на этапе 4230).
4270 прослушивает сообщение завершения от родительского действия. Оно превышает тайм-аут (к примеру, после 5 секунд), если сообщение еще не принято; в этом случае действие завершается. Это осуществляется так, что действие получает (потребляет) сообщение завершения от родительского действия, которое было направлено к нему, но не получено (потреблено). Это условие возникает, если родительское действие отправляет сообщение синхронизации и также отправляет сообщение завершения практически друг за другом. Только сообщение синхронизации получается зависимым дочерним действием в модели прослушивания (к примеру, 4230). Сообщение завершения доставляется дочернему действию, но оно не получается, поскольку модель прослушивания принимает только первое из двух сообщений. Если дочернее действие завершается без получения этого сообщения и шаблон (образец) также переходит к следующим экземплярам, количество записей лишившихся родителей сообщений может появиться в базе данных окна сообщений, неблагоприятно влияя на производительность. Наличие модели 4270 прослушивания исключает завершение действия без получения сообщения завершения, если оно уже было направлено ему.
Пример 36 - Сочетания технологий
Технологии из любого описанного в данном документе примера могут быть объединены с технологиями в любом сочетании из одного или более других описанных в данном документе примеров.
Пример 37 - Примерная вычислительная система
Любые описанные в данном документе примерные системы могут быть реализованы посредством программного обеспечения, выполняющегося в вычислительной системе, такой как программируемая вычислительная машина общего назначения, включая системы на базе микропроцессоров, работающие под управлением любой из множества операционных систем, включая операционную систему Microsoft® Windows® и другие. Эти вычислительные системы могут включать в себя или работать совместно с машиночитаемой средой, такой как ОЗУ, ПЗУ, жесткие диски, CD-ROM, DVD-ROM и т.п.
Пример 38 - Примерные машиноисполняемые инструкции
Любой из описанных в данном документе примеров способов может быть реализован посредством программного обеспечения, содержащего машиноисполняемые инструкции, которые могут быть сохранены в машиночитаемой среде.
Альтернативы
Принимая во внимание множество вероятных вариантов осуществления, к которым могут быть применены принципы изобретения, следует учитывать, что проиллюстрированные варианты осуществления являются примерами изобретения и не должны восприниматься как ограничение области применения изобретения. Вместо этого область применения изобретения включает в себя то, что охвачено следующей формулой изобретения. Поэтому изобретение определено в формуле в объеме и форме этой формулы.
| название | год | авторы | номер документа |
|---|---|---|---|
| СИСТЕМА И СПОСОБ ПРИГЛАШЕНИЯ К ВЗАИМОДЕЙСТВИЮ | 2005 |
|
RU2385487C2 |
| ПЕРЕДАЧА И ПРИЕМ СООБЩЕНИЙ ПОСРЕДСТВОМ ИНДИВИДУАЛЬНО КОНФИГУРИРУЕМЫХ КАНАЛА ОБМЕНА ДАННЫХ И МОДЕЛИ ПРОГРАММИРОВАНИЯ | 2004 |
|
RU2356089C2 |
| МОДЕЛИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ВВОДА И ВЗАИМОДЕЙСТВИЯ В ПРИЛОЖЕНИЯХ НА ОСНОВЕ РАБОЧЕГО ПРОЦЕССА | 2006 |
|
RU2445688C2 |
| ОРКЕСТРОВКА СЛУЖБ ДЛЯ ИНТЕЛЛЕКТУАЛЬНОГО АВТОМАТИЗИРОВАННОГО ПОМОЩНИКА | 2011 |
|
RU2556416C2 |
| ВЫВЕДЕНИЕ НАМЕРЕНИЯ ПОЛЬЗОВАТЕЛЯ НА ОСНОВЕ ПРЕДЫДУЩИХ ВЗАИМОДЕЙСТВИЙ С ГОЛОСОВЫМ ПОМОЩНИКОМ | 2011 |
|
RU2544787C2 |
| ПОДДЕРЖАНИЕ КОНТЕКСТНОЙ ИНФОРМАЦИИ МЕЖДУ ПОЛЬЗОВАТЕЛЬСКИМИ ВЗАИМОДЕЙСТВИЯМИ С ГОЛОСОВЫМ ПОМОЩНИКОМ | 2018 |
|
RU2785950C2 |
| ОПРЕДЕЛЕНИЕ НАМЕРЕНИЯ ПОЛЬЗОВАТЕЛЯ НА ОСНОВЕ ОНТОЛОГИЙ ПРЕДМЕТНЫХ ОБЛАСТЕЙ | 2011 |
|
RU2541221C2 |
| АКТИВНОЕ ЗАПРАШИВАНИЕ ВВОДА ИНТЕЛЛЕКТУАЛЬНЫМ АВТОМАТИЗИРОВАННЫМ ПОМОЩНИКОМ | 2011 |
|
RU2541208C2 |
| РАЗРЕШЕНИЕ НЕОДНОЗНАЧНОСТИ НА ОСНОВЕ АКТИВНОГО ЗАПРАШИВАНИЯ ВВОДА ИНТЕЛЛЕКТУАЛЬНЫМ АВТОМАТИЗИРОВАННЫМ ПОМОЩНИКОМ | 2011 |
|
RU2546605C2 |
| ПЕРЕФРАЗИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКИХ ЗАПРОСОВ И РЕЗУЛЬТАТОВ ПОСРЕДСТВОМ ИНТЕЛЛЕКТУАЛЬНОГО АВТОМАТИЗИРОВАННОГО ПОМОЩНИКА | 2011 |
|
RU2541202C2 |
Изобретение относится к технологиям автоматизированной последовательности выполняемых действий. Технический результат заключается в упрощении технологии автоматизированной последовательности выполняемых действий. Он достигается тем, что система служб автоматизированной последовательности выполняемых действий может осуществлять множество сценариев последовательности выполняемых действий. Служба компоновки, служба ограничения и служба отслеживания могут быть предоставлены клиентским программам. Служба компоновки может поддерживать направленную клиенту инициализацию действий для потоков деятельности. Потоки деятельности могут быть основаны на модели деятельности, созданной на специальной основе или их сочетании. Действия могут быть добавлены в поток деятельности во время исполнения потока деятельности. 42 ил., 7 табл.
Система служб автоматизированной последовательности выполняемых действий, содержащая:
процессор
память, оперативно подсоединенную к процессору;
службу последовательности выполняемых действий, которая выполняется в процессоре из памяти, при этом служба последовательности выполняемых действий содержит
службу компоновки потока деятельности, выполненную с возможностью обмениваться данными с клиентом посредством основанного на SOAP протокола и инициализировать множество инициализируемых действий в ответ на запросы от клиента, причем служба компоновки потока деятельности дополнительно выполнена с возможностью добавлять экземпляр действия к потоку деятельности во время исполнения потока деятельности в ответ на информацию от клиента;
хранилище фактов, содержащее множество фактов, извлеченных из множества баз знаний посредством адаптеров базы знаний, имеющих соответствующие схемы для баз знаний;
службу ограничения, выполненную с возможностью обмениваться данными с клиентом посредством основанного на SOAP протокола и выполненную с возможностью применять ограничения на основе идентификационной информации участвующего действующего субъекта потока деятельности, при этом служба ограничения дополнительно выполнена с возможностью применять ограничения на основе фактов в хранилище фактов; и
службу отслеживания, выполненную с возможностью отслеживать сообщения к инициализируемым действиям и от них.
| ХР 010595206, 26.06.2002 | |||
| Машина для штемпелевания бланков, денежных переводов и т.п. | 1931 |
|
SU25613A1 |
| СПОСОБ ПРЕДОСТАВЛЕНИЯ ПОЛЬЗОВАТЕЛЯМ ТЕЛЕКОММУНИКАЦИОННОЙ СЕТИ ДОСТУПА К ОБЪЕКТАМ | 1998 |
|
RU2169437C1 |
| СПОСОБ И УСТРОЙСТВО ДЛЯ СОЗДАНИЯ ИНТЕРАКТИВНОЙ ГИПЕРСРЕДЫ | 1996 |
|
RU2188450C2 |
