Жизненный цикл бизнес-процессов по требованию, Часть 2: Процесс создания шаблонов электронного бизнеса

Эта статья покажет вам, как применять шаблоны в электронном бизнесе, используя пошаговый процесс для создания динамической архитектуры Системы Отправки Заказов Производителю (Order to Manufacturing Processing System-OTMPS). Данный процесс включает в себя следующие понятия: бизнес, интеграция, композиция, приложение и динамические шаблоны. Вы можете также узнать, как преобразовывать динамические шаблоны в готовые продукты. Кроме того, авторы расскажут вам о новых, потенциальных составных, динамических шаблонах приложений: шаблоне составного бизнес-процесса, динамическом шаблоне многократного применения страниц приложения и динамическом шаблоне управления сотрудничеством.

Доктор Джерман Голдсзмидт, старший технический сотрудник, IBM

Доктор Джерман Голдсзмидт (Dr. German Goldszmidt) - старший технический сотрудник, работает в Программной Группе IBM, занимается архитектурой интегрированной платформы для поставки, настройки и развертывания решений по требованию. До этого он был исследователем в Исследовательском центре IBM Уотсона и руководил дизайном и реализацией нескольких технологий, включая Oceano, первого прототипа автономных вычислений eUtility и Сетевого Диспетчера, компонента стабилизатора загрузки WebSphere.



Навьен Сачдева, инженер-программист консультант, IBM

Навьен Сачдева (Naveen Sachdeva) - инженер-програмист, консультант группы Application Integration Middleware IBM. Он имеет более чем 10 лет опыта работы в крупномасштабной системной интеграции, дизайне и развитии распределенных вычислительных систем. В настоящее время, он помогает деловым партнерам IBM в разработке технических средств и создании концепций, при помощи продуктов WebSphere.



14.11.2004

Введение

Шаблоны для электронного бизнеса - это группа испытанных, многократно используемых ценных решений, которые могут помочь ускорить процесс разработки решений задач электронного бизнеса. IBM опубликовала шаблоны для электронного бизнеса в сети в 1999 году. Тогда многие сделали вклад в эти шаблоны, особенно Джонатан Адамс (см. Ресурсы), разработавший концептуальную структуру, которую бизнес аналитики и системные разработчики могут использовать при определении различных шаблонов для решения своих задач. Методы в данной статье используют эту концептуальную структуру.

В этой статье мы используем множество различных шаблонов, каждый из которых вы можете найти на сайте IBM Шаблоны IBM для электронного бизнеса. Для тех шаблонов, которые еще не доступны на Web-сайте, мы предоставляем ссылки. В некоторых случаях мы не нашли подходящих шаблонов. В данном примере мы предлагаем новые решения, которые в будущем могут стать шаблонами:

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

Здесь мы будем использовать пример OTMPS, описанный в первой статье цикла (см. Жизненный цикл бизнес-процессов по требованию, Часть 1), как контекстный сценарий для демонстрации использования шаблонов для электронного бизнеса при создании эффективной динамической архитектуры.


Процесс создания шаблонов для электронного бизнеса

Данный процесс состоит из следующих шагов:

  1. Разработка высокоуровневого описания бизнеса;
  2. Разработка Обзорной Диаграммы Решения;
  3. Определение шаблонов бизнеса;
  4. Определение шаблонов интеграции;
  5. Определение составных шаблонов;
  6. Определение шаблонов приложений;
  7. Интеграция пакета в решение;
  8. Определение динамических шаблонов;
  9. Преобразование данных в конечные продукты.

Шаг 1: Разработка высокоуровневого описания бизнеса

OTMPS позволяет пользователям запускать процесс представления заказа. Пользователи могут представить подтвержденные и скомпонованные заказы в виде Списка Материалов (Bill of Materials – BOM), составляемого в соответствии с производственной номенклатурой, и затем отправить их на завод-изготовитель для выполнения. В случае подтверждения, заказы, представленные пользователем, проходят различные стадии группирования из частей заказа, подтверждения заказов и процесса производства и представлены в виде Списка Материалов и других инструкций. Могут быть исключения из нормального процесса: обработка неверных заказов, работа с системными ошибками и другие. Эти обстоятельства требуют человеческого вмешательства на различных этапах: обработка неверных заказов или системных ошибок.

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

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

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


Шаг 2: Разработка Обзорной Диаграммы Решения

Вы можете разработать Обзорную Диаграмму Решения с помощью преобразования текста описания бизнеса в наглядное представление. Мы выполняли это действие во время анализа сценария поведения (см. Ресурсы); теперь мы получим Обзорную Диаграмму Решения, используя различные прецеденты, как показано на Рисунке 1.

Рисунок 1. Обзорная Диаграмма Решения для OTMPS
Рисунок 1. Обзорная Диаграмма Решения для OTMPS

Шаг 3. Определение бизнес шаблонов

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

Оператор может:

  • Разместить заказ;
  • Просмотреть статус заказа;
  • Отменить заказ;
  • Изменить бизнес правила.

Администратор может:

  • Запустить процессы выполнения заказа;
  • Остановить процессы выполнения заказа;
  • Приостановить процессы выполнения заказа;
  • Возобновить процессы выполнения заказа.

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

Цепь поставки OTMPS должна послать поставщикам заказы для дальнейшей их обработки и выполнения. Это взаимодействие за границами предприятия и оно показано шаблоном бизнеса расширенного предприятия.


Шаг 4: Определение шаблонов интеграции

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

Как очевидно из Обзорной Диаграммы Решения на Рисунке 1, вам нужны шаблоны интеграции процессов (подмножество шаблона интеграции приложений) для связи OTMPS с:

  • Приложением бизнес-метрики;
  • Обработчиком уведомлений;
  • Приложением управления правилами;
  • Системой поставщика;
  • Производственными приложениями;
  • Приложениями бизнес-метрики других систем.

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

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


Шаг 5: Определение составных шаблонов

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

Рисунок 2. Отсутствие образца состава для OTMPS
Рисунок 2. Отсутствие образца состава для OTMPS

Шаг 6: Определение шаблонов приложений

Шаг 6.1. Самообслуживание

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

Шаг 6.2. Сотрудничество

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

Шаг 6.3. Объединение информации

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

Шаг 6.4. Расширенное предприятия

Вы можете объединяться с различными поставщиками и заменять одного поставщика другим, без изменения OTMPS, до тех пор, пока их форматы сообщений совместимы. Другими словами, вам нужно 1:N преобразование данных с запросом, направленным по большей части на одну цель. Вариант шаблона маршрутизатора незащищенного посредника (см Ресурсы) является наиболее подходящим для этих требований.

Шаг 6.5. Интеграция Доступа

Вы хотите обеспечить общий интерфейс пользователя и ролевой доступ с одним запросом пароля в разных приложениях. Другими словами, необходимо представление и службы безопасности. Служба безопасности была достаточно хорошо представлена шаблоном(и) приложения единой регистрации. Можно реализовать интерфейс, используя вариант шаблона приложения непосредственно интегрированного выделенного канала, который является шаблоном самообслуживающегося приложения. Первичный драйвер используется для предоставления шаблону доступа в режиме реального времени к конечным приложениям и данным Web-приложений – конечные приложения и данные являются ключевыми. Но вы можете использовать его и для предоставления доступа к множественным Web-приложениям из одного Web-приложения и, следовательно, обеспечить общий уровень представления. Ниже есть ссылка на это изменение на Рисунке 4-8 документации IBM по сложным портальным шаблонам, использующим WebSphere Portal V5. К сожалению, он представлен в соединении изменений с исходным шаблоном DISC приложения и все еще именуется как шаблон приложения непосредственно интегрированного выделенного канала. В этой статье мы говорим об этом изменении как о шаблоне многократного применения страниц приложения (см. Рисунок 3), который представляет объединение только Web-приложений, т.е. не включает шаблон самообслуживания.

Рисунок 3. Шаблон многократного применения страниц приложения
Рисунок 3. Шаблон многократного применения страниц приложения

Шаг 6.6. Интеграция приложений

Интеграция процессов

Шаблон приложения прямого соединения достаточен для того, чтобы отследить взаимодействие между OTMPS и приложением бизнес-метрики, OTMPS и приложением управления правилами, между приложением бизнес-метрики и другими системами.

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

Шаблон приложения прямого соединения является достаточным для интеграции обработчика уведомлений и OTMPS.

Интеграция данных

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

Шаг 6.7. Конечное создание всех требуемых образцов приложений

Рисунок 4 содержит в себе все требуемые шаблоны приложений для OTMPS.

Рисунок 4. Набор шаблонов для решений электронного бизнеса
Рисунок 4. Набор шаблонов для решений электронного бизнеса

Шаг 7: Интегрирование пакета в решение

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


Шаг 8: Определение динамических шаблонов

Шаг 8.1. Единый вход в систему и шаблон объединения страниц

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

Рисунок 5. Интеграция доступа:: Единый вход в систему:: однотипный сервер приложения
Рисунок 5. Интеграция доступа:: Единый вход в систему:: однотипный сервер приложения

Для шаблона объединения страниц вы можете использовать разновидность непосредственно интегрированного выделенного канала: динамическая версия 1, как показано на Рисунке 6, в котором узел сервера приложения был заменен на узел портального сервера.

Рисунок 6. Интеграция доступа: объединение страниц: динамический шаблон объединения страниц
Рисунок 6. Интеграция доступа:: объединение страниц:: динамический шаблон объединения страниц

Шаг 8.2. Шаблон доступа к пользовательской информации

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

Рисунок 7. Доступ к информации - Только для чтения:: BI приложение во внутренней сети
Рисунок 7. Доступ к информации - Только для чтения:: BI приложение во цнутренней сети

Шаг 8.3. Шаблон непосредственно интегрированного выделенного канала

При широкой распространенности атак хакеров, динамическая версия 1, показанная на Рисунке 8, является рекомендованным шаблоном приложения непосредственно интегрированного выделенного канала.

Рисунок 8. Самообслуживание: непосредственно интегрированный выделенный канал:: динамическая версия 1
Рисунок 8. Самообслуживание: непосредственно интегрированный выделенный канал:: динамическая версия 1

Шаг 8.4. Шаблон управления сотрудничеством

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

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

Рисунок 9. Динамический шаблон управления сотрудничеством
Рисунок 9. Динамический шаблон управления сотрудничеством

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

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

Шаг 8.5. Шаблон прямого подключения

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

Рисунок 10.Прямое соединение:: шаблон простого сервисного канала
Рисунок 10.Прямое соединение:: шаблон простого сервисного канала

Шаг 8.6. Последовательный процесс

Шаблон динамического последовательного процесса (см. Ресурсы), показанный на Рисунке 11, позволяет OTMPS взаимодействовать с различными приложениями последовательным способом. Управляющая программа процесса контролирует это взаимодействие.

Рисунок 11. Шаблон динамического последовательного процесса
Рисунок 11. Шаблон динамического последовательного процесса

Шаг 8.7. Динамический шаблон приложения открытого маршрутизатора

Вам нужен шаблон, который соответствует шаблону приложения открытого маршрутизатора для интеграции с поставщиками. Он должен поддерживать преобразование 1:N, а также протокол преобразования для доступа к существующим системам. Этому требованию удовлетворяют либо шаблон открытого маршрутизатора (Рисунок 12), либо шаблон открытого сервисного канала передачи данных предприятия (ESB) (Рисунок 13). Шаблон открытого ESB это лучший выбор для вас, потому что вам надо построить решение SOA, и шаблон открытого ESB обеспечивает набор инфраструктурных возможностей, которые позволяют интегрировать сервисы в SOA (см. Ресурсы).

Рисунок 12. Открытый посредник:: шаблон маршрутизатора
Рисунок 12. Открытый посредник:: шаблон маршрутизатора
Рисунок 13. Шаблон сложного открытого ESB маршрутизатора
Рисунок 13. Шаблон сложного открытого ESB маршрутизатора

Шаг 8.8. Результат объединения динамических шаблонов

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

Рисунок 14. Объединенные динамические шаблоны
Рисунок 14. Объединенные динамические шаблоны

Шаг 9: Преобразование данных в конечные продукты

Вы можете преобразовывать динамические шаблоны в различные конфигурации продуктов. Например, вы можете преобразовать менеджер обработки в серверную основу бизнес-интеграции WebSphere или технологический процесс WebSphere MQ (см. Ресурсы). У вас, также, есть возможность реализации ESB в WebSphere Business Integration Message Broker или WebSphere Business Integration Server Foundation и т.д. (см. Ресурсы) Выбор зависит от многих факторов, таких как:

  • Возможности продукта;
  • Цена;
  • Существующие навыки;
  • Простота разработки;
  • Индустриальное направление.

Для менеджера процессов вы можете использовать управление потоком данных на сервере WebSphere Business Integration Server Foundation (см. Рисунок 15), потому что он основан на открытых стандартах J2EE и Исполнительного Языка Бизнес Процессов для Web-сервисов (BPEL4WS). Таким же образом для портального сервера, вы можете использовать WebSphere Portal Express, так как он предоставляет все необходимые функции. Иногда ни один существующий продукт не удовлетворяет требованиям полностью. Вы должны решить использовать или нет частичное исполнение требований или разрабатывать новое решение. Для гибкости вы могли бы предпочесть потерю связи между сервером сотрудничества и менеджером процессов, но в продукте WebSphere Business Integration Server Foundation, они тесно связаны. Кроме того, подразумеваемое приложение сотрудничества, которое поставляется вместе с WebSphere Business Integration Server Foundation Business Portal, имеет техпроцесс сотрудничества, вложенный в приложение. Мы решили использовать его, потому что его ограничения минимальны, а цена альтернативы потенциально высока.

Рисунок 15. Преобразование продукта для OTMPS
Рисунок 15. Преобразование продукта для OTMPS

Потенциальный составной шаблон

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

Рисунок 16. Составной шаблон бизнесс-процесса
Рисунок 16. Составной шаблон бизнесс-процесса

Потенциальный составной шаблон бизнес-процесса

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

Шаблон составного бизнес-процесса состоит из следующих частей:

  • Шаблон обслуживания бизнеса, способствующий взаимодействию между заказчиком и бизнес-процессами. Действия, такие как размещение заказа, утверждение размещения или создание счета выполняются с использованием этого шаблона. Он также помогает системному администратору в управлении бизнес-процессами;
  • Шаблон сотрудничества способствует взаимодействию между:
    • заказчиком и операторами;
    • между операторами;
    • между бизнес-процессами и заказчиками или операторами.
  • Шаблон информационного объединения бизнеса предоставляет доступ на чтение к данным исполнения бизнес-процесса. По желанию вы можете использовать его для передачи данных исполнения процесса в исполнительные бизнес-метрики;
  • Шаблон интеграции приложений объединяет шаблоны обслуживания, сотрудничества, расширенного предприятия и информационного объединения бизнеса. Вы можете также использовать их для интеграции бизнес-процессов с существующими приложениями/системами поддержки, например, интеграция между процессами OTMPS и системой производства.

Шаблон составного бизнес-процесса также может включать в себя следующее:

  • Шаблон расширенного бизнес-предприятия взаимодействует с приложениями бизнес-партнеров (например, обеспечивает взаимодействие между OTMPS и приложением размещения заказа поставщика);
  • Шаблон интеграции доступа обеспечивает портальный интерфейс, функции SOS и специфические функции для клиентов.

Вывод

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

Благодарности Авторы хотели бы поблагодарить Джонатана Адамса и Джорджа Галамбоса за их помощь в рецензировании этой статьи.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, WebSphere
ArticleID=106461
ArticleTitle=Жизненный цикл бизнес-процессов по требованию, Часть 2: Процесс создания шаблонов электронного бизнеса
publish-date=11142004