ОРИЕНТИРУЕМАЯ НА ОБСЛУЖИВАНИЕ АРХИТЕКТУРА, ОСНОВАННАЯ НА КОНВЕЙЕРЕ

Уровень техники

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

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

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

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

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

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

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

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

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

фиг.2 иллюстрирует главные компоненты в ориентируемой на обслуживание системе с конвейерной архитектурой;

фиг.3 иллюстрирует примерную ориентируемую на обслуживание систему (CRM) с конвейерной архитектурой;

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

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

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

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

Подробное описание

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

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

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

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

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

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

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

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

В операции, предоставляемая через хост услуга принимает входные данные (например, информацию о новых контактах в услуге CRM) и запрашивает обработку у пользователя 102. Пользователь 102 может быть связан с отдельной системой прикладных программ пользователей, инструментальных средств и/или встраиваемых расширений 104 для настраивания предоставляемых через хост услуг. Данные, связанные с отдельной системой, могут храниться в хранилище (хранилищах) 106 данных пользователей. Пользователь 102 может обеспечивать расширения (встраиваемые расширения) для предоставляемой через хост услуги для дополнительных или специализированных функциональных возможностей, где встраиваемые расширения регистрируются и выполняются наряду с основными операциями платформы. В соответствии с некоторыми вариантами осуществления, такие встраиваемые расширения могут не только обеспечивать дополнительные функциональные возможности, но также и расширять существующие задаваемые по умолчанию функциональные возможности услуги.

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

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

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

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

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

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

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

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

Как показано на чертеже, Web-сервисы 212 взаимодействуют с прикладными программами 222, инструментальными средствами 224 и последовательностью выполняемых операций (бизнес-процессом) 226, чтобы обрабатывать запросы пользователей. Кроме того, Web-сервисы 212 принимают встраиваемые расширения пользователей (например, 231, 232, 235, 236), чтобы выполнять определяемые пользователем действия. Определяемые пользователем действия через встраиваемые расширения могут включать в себя настройку с помощью расширения существующих функциональных возможностей или новую функциональную возможность, которая является параллельной существующей функциональной возможности. Встраиваемые расширения регистрируются в API через метаданные, которые могут включать в себя и порядок, и стадию встраиваемых расширений (например, была ли операция отменена, завершена и т.д., прежде, чем должно быть активизировано другое встраиваемое расширение). Тогда встраиваемые расширения могут выполняться (конвейером 230 выполнения команд) наряду с операциями 234 платформы, некоторые прежде (например, 231, 232), некоторые после (например, 235, 236), в зависимости от их порядка регистрации, как определено метаданными.

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

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

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

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

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

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

В примерной системе 300 на фиг.3, такие запросы пользователей обрабатывают Web-сервисы 312 CRM, выполняя основные операции 334 платформы (задаваемые по умолчанию функциональные возможности), наряду со встраиваемыми расширениями 331, 332, 335, 336, которые обеспечивают расширенные или альтернативные функциональные возможности, позволяющие настраивать услугу для пользователя. Встраиваемые расширения последовательно выполняются на конвейере 330 выполнения команд CRM, и их последовательность может быть определена пользователем (331, 332, 335, 336). В соответствии с одной реализацией, встраиваемые расширения могут быть сгруппированы, как операции предшествующего события и последующего события для данных предварительной обработки или последующей обработки, обрабатываемых посредством основных функциональных возможностей, но это группирование не является ограничением. В системе согласно вариантам осуществления, встраиваемые расширения и основные операции могут группироваться любым способом или вообще не группироваться.

Web-сервисы 312 CRM могут взаимодействовать с конкретной прикладной программой 322 CRM, использовать инструментальные средства 324 CRM и сохранять бизнес-процессы, как последовательность 326 выполняемых операций CRM. В соответствии с примерной реализацией, применения Web-сервисов 312 CRM могут использоваться в качестве транспортного средства для запросов пользователей. Реляционная база данных, такая как база данных языка структурированных запросов (SQL), может использоваться в качестве репозитория конвейерной конфигурации, а другая база данных может использоваться в качестве репозитория модулей кодов встраиваемых расширений.

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

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

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

Запросы на обработку могут исходить от пользователей через индивидуальные клиентские устройства 441-443. Непосредственно пользователи или поставщик услуг третьей стороны (через сервер 444) могут обеспечивать встраиваемые расширения для расширенных или дополнительных функциональных возможностей к обслуживанию конвейерной архитектуры, управляемому одним или больше серверами (например, сервером 452). Обслуживание также может быть реализовано в одном или больше серверах. Базы данных участников могут быть воплощены в хранилищах 458 данных. Выделенные серверы баз данных (например, сервер 456 базы данных) могут использоваться для того, чтобы координировать поиск и сохранение данных в одном или больше таких хранилищах данных.

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

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

Фиг.5 и связанное обсуждение предназначены для того, чтобы обеспечить краткое, общее описание подходящей вычислительной среды, в которой могут быть реализованы варианты осуществления. Со ссылкой на фиг.5 отметим, что там иллюстрируется блок-схема примерной вычислительной операционной среды, такой как вычислительное устройство 500. В базисной конфигурации, вычислительным устройством 500 может быть сервер, обеспечивающий услуги, связанные с ориентируемой на обслуживание системой, использующей конвейерную архитектуру, и оно обычно включает в себя по меньшей мере один блок 502 обработки данных и системную память 504. Вычислительное устройство 500 также может включать в себя множество блоков обработки данных, которые взаимодействуют в выполняющихся программах. В зависимости от точной конфигурации и типа вычислительного устройства, системная память 504 может быть энергозависимой (такой как ОЗУ (оперативное запоминающее устройство)), энергонезависимой (такой как ПЗУ (постоянное запоминающее устройство), флэш-память и т.д.) или некоторой комбинацией из двух упомянутых устройств. Системная память 504 обычно включает в себя операционную систему 505, подходящую для управления функционированием сетевого персонального компьютера, такую как операционные системы WINDOWS® от корпорации MICROSOFT CORATION, Redmond, Washington. Системная память 504 также может включать в себя одну или больше прикладных программ программного обеспечения, таких как программные модули 606 (506), Web-сервисы 522 и встраиваемое расширение (встраиваемые расширения) 524.

Web-сервисы 522 могут быть отдельной прикладной программой или интегральным модулем прикладной программы предоставляемой через хост услуги, который обеспечивает данные и услуги обработки данных для клиентских прикладных программ, связанных с вычислительным устройством 500. Встраиваемые расширения 524 могут обеспечивать дополнительные функциональные возможности, настраивающие операции Web-сервисов 522 для конкретных пользователей и/или операций, как было описано выше. Эта базисная конфигурация иллюстрируется на фиг.5 теми компонентами, которые находятся в пределах пунктирной линии 508.

Вычислительное устройство 500 может иметь дополнительные признаки или функциональные возможности. Например, вычислительное устройство 500 также может включать в себя дополнительные устройства накопления данных (съемные и/или несъемные), например, такие как магнитные диски, оптические диски или магнитная лента. Такое дополнительное запоминающее устройство иллюстрируется на фиг.5 устройством 509 хранения данных со съемным накопителем и устройством 510 хранения данных с несъемным накопителем. Компьютерные запоминающие носители могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные посредством любого способа или технологии для хранения информации, такой как считываемые компьютером команды, структуры данных, программные модули или другие данные. Системная память 504, устройство 509 хранения данных со съемным накопителем и устройство 510 хранения данных с несъемным накопителем, все представляют собой примеры компьютерных запоминающих носителей. Компьютерные запоминающие носители включают в себя, но не ограничены этим, ОЗУ, ПЗУ, ЭСППЗУ (электрически стираемое программируемое ПЗУ), флэш-память или другую технологию запоминающих устройств, CD-ROM (неперезаписываемый компакт-диск), универсальные цифровые диски (DVD) или другие оптические накопители, кассеты с магнитной лентой, магнитную ленту, накопитель на магнитных дисках или другие запоминающие устройства на магнитных накопителях, или любую другую среду, которая может использоваться для сохранения требуемой информации и к которой может получать доступ вычислительное устройство 500. Любые такие компьютерные запоминающие носители могут быть частью устройства 500. Вычислительное устройство 500 также может иметь устройство (устройства) 512 ввода, такое как клавиатура, мышь, перо, устройство речевого ввода данных, устройство сенсорного ввода данных и т.д. Также может быть включено устройство (устройства) 514 вывода, такое как дисплей, динамик, принтер и т.д. Эти устройства известны в технике и в данном описании подробно обсуждать их не требуется.

Вычислительное устройство 500 также может содержать соединения 516 связи, которые обеспечивают устройству возможность связываться с другими вычислительными устройствами 518, такие как связь через беспроводную сеть в распределенной вычислительной среде, например, интранет или Интернет. Другие вычислительные устройства 518 могут включать в себя сервер (серверы), которые выполняют прикладные программы, связанные с другой услугой или поставщиками услуг третьей стороны, обеспечивающими встраиваемые расширения. Соединение 516 связи представляет собой один пример сред передачи данных. Среды передачи данных обычно могут воплощаться посредством считываемых компьютером команд, структур данных, программных модулей или других данных в модулируемом данными сигнале, таком как несущая или другой транспортный механизм, и включают в себя любые среды предоставления информации. Термин "модулируемый данными сигнал" означает сигнал, который имеет одну или больше своих характеристик, устанавливаемых или изменяемых таким способом, чтобы кодировать информацию в сигнале. Посредством примера, а не ограничения, среды передачи данных включают в себя проводные средства, такие как проводная сеть или прямое проводное подключение, и беспроводные средства, такие как акустические, РЧ, основанные на инфракрасном излучении и другие беспроводные средства. Термин "компьютеро-читаемые носители", как используется в данном описании, включает в себя и носители хранения, и среду передачи данных.

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

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

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

Процесс 600 начинается с операции 602, где созданная пользователем схема (и/или операция) принимается обслуживанием конвейерной архитектуры. Схема (и/или операция) связана с одним или больше встраиваемыми расширениями, которые может обеспечивать пользователь или третья сторона, санкционированная пользователем. Обработка перемещается от операции 602 к операции 604.

При проведении операции 604, схема конфигурируется автоматически. Например, в системе CRM, использующей базы данных SQL, данные SQL (запросы) могут генерироваться на основании схемы, связанных метаданных и непосредственно операций. Система еще не выполняет никакие операции, поскольку никакие действия не запрашивались пользователем, связанным с данными пользователя. Обработка переходит от операции 604 к операции 606.

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

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

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

Фиг.7 иллюстрирует логическую блок-схему последовательности операций программы для процесса 700 обнаружения циклов в ориентируемой на обслуживание системе с конвейерной архитектурой. Процесс 700 может быть реализован в пределах процесса 600 управления операциями, показанного на фиг.6.

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

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

Пропуская пока необязательные операции 710 и 712, при проведении операции 714 принятия решения делается определение, израсходован ли назначенный бюджет. Если бюджет израсходован, операции останавливаются. Если все еще имеется доступный бюджет, операции, связанные с вызовом, выполняются при проведении последующей операции 716.

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

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

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

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