Ориентация сообщений
Брокер служб SQL Server 2005: Создание сообщений технологии корпорации Майкрософт расположенную
Olamendy Turruellas Juan Карлос (John Чарльз)
В SQL Server 2005 Корпорация Майкрософт представила технологию Service Broker (SSB), которая поддерживает шаблон разработки брокера и принципы ориентированных на сообщения по промежуточного слоя (MOM). Эта технология тем не менее, был немного использован, несмотря на возможность SSB, в отличие от традиционных синхронный запрос ответ подход, позволяющие разработчикам создавать надежные, масштабируемые, распределенных и асинхронного обмена сообщениями приложения путем реализации механизмов очереди сообщений, которые объединяются с возможностями реляционной базы данных SQL Server.
Брокера — это компонент программного обеспечения, располагается между корпоративных приложений, требующих интеграции и взаимодействует с ними. Это по промежуточного слоя скрывает сложность протоколов связи и топологии при необходимости приложения подключаются друг к другу для обмена данными. Он также предоставляет возможности, например преобразование и маршрутизации сообщений управление выполнения бизнес-логику процесса таким образом.
В этой модели функциональность предоставляемое как служба и обмен данными между службами выполняется с помощью сообщения независимо ли используемых приложений подключены одновременно. Эта модель также позволяет слабо связанных составных приложений и гарантирует, что сообщения не будут утеряны. В этой статье я опишу основные концепции SSB, иллюстрирующих бизнес-реальных сценария, показывающий потенциал комплексных решений на основе сообщения.
Применение SSB с бизнес-сценарием реальном мире
Основной контекст, в котором можно применить технологию SSB находится в разработке решения интеграции для корпоративных приложений. Эти приложения обычно поддерживают управление и автоматизацию бизнес-процессов, требующих промежуточного надежного ориентированных на сообщения по (не сообщения будут утеряны) для обмена данными между ними. Кроме того эти приложения находятся в сложной среде с большим числом систем и пользователей. Не все приложения являются сети в одно и то же время, и их обработке запросов в слабо связанных способ может занять много времени.
В модели традиционных запрос ответ является синхронной связи между серверными системами и бизнес-логику процесса реализуется (используя высокого уровня языка, например C# или Java) через компоненты бизнес-слой решения и как ряд операций базы данных. Если один обслуживающей системе вниз, в этот подход весь процесс передает ждущего режима состояние. Например кредитной карты не может авторизовать Если система оплаты вниз.
Основной целью SSB приложений является интеграция корпоративных систем через общий канал связи. Некоторые внешних приложений (ERP, управление цепи поставок, CRM и других) или внутренних модулей (код T-SQL и CLR управляемых триггеров и хранимых процедур), помещение сообщения в очереди, во время их аналоги получать уведомления, сообщения находятся в очереди (и необходимость извлечения и выводе из очереди) через триггера или обычные операции SEND и получения. Здесь концепция основана на корпоративной системы которого серверные компоненты могут принимать запросы немедленно, но отложить обработку запросов, возвращая информационное сообщение клиенту, указывающее, что он должен ждать ответа позже.
Асинхронные SSB решение примера показано в этой статье (см. рис. 1) включает узла портала и базы данных хранилища и запасов. Узла портала, имеет два веб-страницы: один для ввода данных, связанных с запросом заказа и другой для просмотра статуса заказа. Приложения базы данных хранилища получает запросы заказа от узла портала, сохраняет эти данные в таблице tbOrder и отправляет данные запроса заказа в форме сообщений в очереди на общие шины в канал связи, прослушивает приложения базы данных запасов. База данных запасов получает входящий запрос заказы и обрабатывает Склад хранения и распространения доставки. Также создает основной порядок ответа и отправляет его, используя другой очереди для базы данных хранилища. Наконец базы данных хранилища прослушивает заказа ответные сообщения и обновляет состояние основной порядок запроса строки (ОК или НЕДОПУСТИМЫЙ статус) в tbOrder таблицы, который позволяет пользователям проверять состояние заказов. Таким образом распределенных решение делегирует все процедуры обмена сообщениями, резервного копирования, администрирования и отказоустойчивого инфраструктуру SSB (Применение шаблона разработки Broker) и сосредоточено его усилия на домене проблемы.
.png)
Рисунок 1 электронной коммерции сценарий как составной решений из корпоративные системы
С точки зрения принципов SSB приложения базы данных хранилища начинается диалог с приложения базы данных запасов отправляя сообщение запроса заказа очередь запасов приложения с помощью общих интерфейсов на основе служб. Службы являются логические конечные точки в SSB технологий, которые используют очереди в качестве хранилища сообщений и указания их функций с помощью контрактов. Контракты указать направление сообщений и их базовый тип сообщения в данного диалога. После сообщения помещается в очередь (поставлены в очередь), хранилище приложение продолжает с другими задачами. Когда приложение запасов является готовый (это может быть ночью или в другое время простоя), служба принимает программа, вместе с конечным результатом обрабатывалось сообщение из очереди и процессов, а приложение базы данных запасов отправляет сообщение, подтверждающее, порядок. (См. рис. 2).
.png)
Рисунок 2 SSB архитектуры решения
Как проанализировать архитектуру решения SSB может распознать, что базового решения интеграции может понял технологии других обмена сообщениями, такие как MSMQ и Microsoft BizTalk Server. Однако Microsoft SQL Server вместе с компонент Service Broker предоставляет надежную инфраструктуру для создания комплексных приложений и имеет уровень восстанавливаемости, сопровождаемость, надежность, производительность и масштабируемость можно найти в системе базы данных. Средства качество обновления в SSB относятся следующие:
- Транзакции. Если сообщение извлекается из очереди и возникает ошибка, сообщение не теряются.
- Возможности восстановления. Если в системе происходит сбой из-за сбоев носителей, проблемы в процессора или в оперативной памяти или в системе подвергается длительного отключения электричества, сообщения должны сохраняться долговременной основе продолжить обработку при ее восстановлении системы.
- Масштабируемость. После учета сообщения в очередь они обрабатываются скоростью, не предоставляет проблем с производительностью при добавлении дополнительных ресурсов. Рабочая нагрузка может увеличиваться многие тысячи сообщений в секунду, но рабочей нагрузки может быть сбалансирована путем распределения работы между много участников SSB экземпляров.
Реализация решения
В этом разделе я перебора как реализовать решение SSB для бизнес-сценарием. Основной базы данных являются базе хранилище и складских запасов, размещенных на разных серверах. Это означает, что нужно подключения этих систем с помощью SQL Server Management Studio.
Первым шагом является для включения функций компонента Service Broker и безопасность транспорта в обеих базах данных (см. рис. 3) путем настройки базового уровня экземпляров в системном каталоге (базы данных master).
Включение SSB на рис. 3 и средства безопасности транспорта в участие базы данных
--- Configure Instance1.
use master;
alter database Store set ENABLE_BROKER;
alter database Store set TRUSTWORTHY ON;
use Store;
create master key encryption by password = 'Store*-';
--- Configure Instance2.
use master;
alter database Inventory set ENABLE_BROKER;
alter database Inventory set TRUSTWORTHY ON;
use Inventory;
create master key encryption by password = 'Inventory*-';
Параметры безопасности
Следующим шагом является Настройка инфраструктуры связи между двумя экземплярами SQL Server и баз данных для установления безопасного канала, включающие проверки подлинности и при необходимости шифрования сообщения. Можно использовать Windows или проверку подлинности на основе сертификатов.
Под механизм Windows каждый экземпляр SQL Server входит в систему на другой, используя учетные данные учетными записями, под которой выполняется процессов. Он является обязательным, обоих экземпляров SQL Server используется учетная запись пользователя домена с правами войти как служба и отправлять сообщения.
Под механизм сертификатов каждый экземпляр SQL Server проверяет в другой с использованием цифрового сертификата. В SQL Server 2005 он требуется создать пару открытого и закрытого ключа на первом этапе установки инфраструктуры открытого ключа. Закрытый ключ защищен главным ключом базы данных из базы данных master и главным образом используется для установления расположенную системы идентификации, interchanging данные, зашифрованные с помощью закрытого ключа и проверена с помощью открытого ключа с другой стороны. Затем каждая конечная точка SSB настроен на использование созданных сертификаты для проверки подлинности и шифрования.
Структура сообщения и проверка
Далее необходимо указать базовых объектов связи, таких как схемы XML, типы сообщений, очередь, контракты и службы, которые используются через безопасный канал. Сообщение является содержимого владелец передаваемых данных и каждый экземпляр имеет тип соответствующего сообщения. Чтобы определить структуру interchanged сообщений, позволяет типы сообщений Указание структуры и ограничений базовые экземпляры сообщения. Это может быть простой двоичный объект, является допустимым документом XML или XML-документом правильного формата. Я использовал стандарты XML для представления и формат сообщения в наших решений интеграции. В этом случае бизнес первое сообщение представляет порядок, отправляемые из базы данных хранилища в базу данных запасов с помощью правильного формата документа XML (описанный, тип сообщения OrderRequestMsgType OrderRequestSchema схемы и содержащий данные о идентификатор заказа, идентификатор клиента, дата заказа и запрошенный элемент с идентификатором, цена и количество). Второе сообщение представляет коррелированные ответа, отправляемые целевой базы данных с помощью корректного XML-документа, слишком (описано тип сообщения OrderResponseMsgType OrderResponseSchema схемы и содержит данные о запросе ответное сообщение, обработки состояния и описание). На рис. 4 определяет XML-схем используется для указания и проверить структуру запроса заказа и порядок ответа сообщения.
рис. 4 Сообщения схемы XML для запроса заказа и заказа ответа
--- Create the schemas.
create xml schema collection OrderRequestSchema as
N'
<xs:schema xmlns="http://www.mycorporation.com/2007_schemas/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.mycorporation.com/2007_schemas/"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Order">
<xs:complexType>
<xs:sequence>
<xs:element name="LineItem">
<xs:complexType>
<xs:attribute name="ItemNumber"
type="xs:int"/>
<xs:attribute name="Quantity"
type="xs:int"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Id" type="xs:int"/>
<xs:attribute name="Customer" type="xs:int"/>
<xs:attribute name="Order_date" type="xs:dateTime"/>
</xs:complexType>
</xs:element>
</xs:schema>
'
go
create xml schema collection OrderResponseSchema as
N'
<xs:schema xmlns="http://www.mycorporation.com/2007_schemas/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.mycorporation.com/2007_schemas/"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="OrderConfirmation">
<xs:complexType>
<xs:sequence>
<xs:element name="Id" type="xs:int"/>
<xs:element name="Processing_Status" type="xs:int"/>
<xs:element name="Processing_Description"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
'
Go
Следующий код создает на обоих компьютерах типы сообщений в зависимости от предыдущей схемы, которые являются частью интерфейса SSB служб.
create message type OrderRequestMsgType validation= VALID_XML
with schema collection OrderRequestSchema;
create message type OrderResponseMsgType validation=VALID_XML
with schema collection OrderResponseSchema;
go
Предложение WITH SCHEMA COLLECTION означает, что SSB для проверки сообщений от определенного XML-схем. SSB выполняет проверку, как только целевая служба получает сообщения. Если содержимое doesn’t пройдет проверку, SSB возвращает сообщение об ошибке. ’S отметить сообщение проверки может быть довольно дорого. Таким образом рекомендуется включенного проверки сообщения для обработки сообщений из ненадежных источников, так как раннее; обнаруженных поврежденных сообщенийв противном случае эта функция может быть отключено. Можно обратиться к документации по SQL Server для лучшего понимания синтаксиса Создание типа сообщений.
Определение инфраструктуры связи
После создания типы сообщений, необходимо определить контрактов на обоих компьютерах укажите, какие сообщения (и в каком направлении) служба может отправить или получить. Контракт определяет также ли сообщение отправлено инициатором диалога, по цель диалога или по инициатором или целевой диалога. В этом случае инициатор является базой данных хранилища, а конечный является базой данных запасов. Предложение SENT BY определяет участвующих конечные точки и их основной роли. SSB гарантирует, что только типы сообщений, определяются в контракт обработки и обработки. Если служба отправляет другой тип сообщения, сообщение будет отклонено, и сообщение об ошибке отправляется обратно.
create contract OrderProcessingContract
(OrderRequestMsgType sent by initiator,OrderResponseMsgType sent by
target)
go
Также необходимо создать таблицу с именем tbOrder в базе хранилище для записи данных в запросе порядке вместе с его состояние обработки и описание (возвращается из базы данных запасов) таким образом, клиент может проверить порядок с помощью веб-страницы. Код, который следует показано, как создать таблицу. OrderStatus поля в таблице может иметь одно из трех значений:
- Значение = 0. Порядок обработки не;поле OrderStatusDescription является null.
- Значение = 1. Порядок обработки без ошибок;поле OrderStatusDescription является null.
- Значение = 2. Порядок обработки ошибок;Дополнительные сведения в поле OrderStatusDescription.
create table tbOrder
(
nOrderID int identity(1,1) primary key,
nCustomer int,
dtOrderDate datetime,
nItemNumber int,
nItemQuantity int,
nOrderStatus int,
vcOrderStatusDescription varchar(50)
);
Для вставки данных заказа, которые введены в портала фронтальный веб-в tbOrder таблицы, можно определить хранимую процедуру, показанный на рис. 5, как основной интерфейс для отправки базовых данных и возвращения номер заказа. Номер заказа отображается в некоторой точке в времени и использоваться пользователем для запроса основной статус заказа.
На рис. 5 Создание хранимой процедуры spInsertOrder
create procedure spInsertOrder
@nOrderID int output,
@nCustomer int,
@dtOrderDate datetime,
@nItemNumber int,
@nItemQuantity int
as
begin
insert into tbOrder(nCustomer, dtOrderDate, nItemNumber, nItemQuantity,
nOrderStatus)
values(@nCustomer, @dtOrderDate, @nItemNumber, @nItemQuantity, 0);
set @nOrderID=@@IDENTITY;
end;
Следующим шагом является создание очередей для хранения полученных сообщений (либо с целевой службы или сервера инициатора), которые должны быть обработаны. Когда SSB получает и проверяет сообщение (как описано выше), вставляет сообщение в очередь. (Можно обратиться к электронной документации по SQL Server для более документации инструкцию CREATE QUEUE.)
Очередь можно привязать к хранимую процедуру, которая автоматически обрабатывает сообщения (когда один отправлено в очередь) и обрабатывает их. Одним важным параметром при создании очереди является MAX_QUEUE_READERS, который указывает максимальное число экземпляров хранимой процедуры активации, которую запускает очередь в то же время. Значение MAX_QUEUE_READERS должно быть числом от 0 до 32 767. Если запросы заказа ожидается скоростью быстрее, чем один читатель может обработать их, можно указать несколько агентов чтения очереди для создания более читателей по мере необходимости вплоть до достижения максимального числа. ’S упоминания этой хранимой процедуры должен быть создан перед очереди, но в целях обеспечения данной статьи, бизнес-логики эта хранимая процедура рассматривается в разделе значение разговор между службы в SSB технологии. ” В примере мы чтения очереди и обработку сообщений автоматически, но некоторые бизнес-сценарии требуют вмешательства пользователей, это означает, что очереди должны быть считаны с помощью основной логики предоставляются как хранимую процедуру вызываться из графического интерфейса пользователя.
На данном этапе мы создали для обоих систем объекты базы данных, определение двунаправленный канал связи и общие понимание. Далее необходимо создать артефакты для каждой системы, предоставляющие функциональность обработки заказов.
Сначала нужно создать очередь на базе данных магазина (базовой spStoreDB_QueueReader хранимая процедура должна быть создана сначала;в разделе рис. 8) для хранения и обработки входящих сообщений порядок ответа и обновление статус заказа в таблице tbOrder.
--- Create the queue on the Store database
create queue StoreQueue with status=on,
activation (procedure_name=spStoreDB_QueueReader,max_queue_readers=5,
execute as 'dbo');
go
Далее вы создадите другой очереди в базе данных запасов (базовой spStoreDB_QueueReader хранимая процедура должна быть создана сначала;см. рис. 7) для получения заказа сообщения запроса из хранилища базы данных и обработать их.
--- In the Inventory database
create queue InventoryQueue with status=on,
activation (procedure_name=spInventoryDB_QueueReader,max_queue_readers=5,
execute as 'dbo');
go
Теперь необходимо определить службы, показанный в следующем примере кода. Служба представляет конечную точку на уровне приложений в решении SSB и может быть инициатора и целевой объект сообщения. Службы можно связать несколько комбинаций очереди и контракт. При поступлении нового сообщения в очередь и SSB также можно назначить события для активации или вручную выполнять службу SSB можно автоматически активировать службы. Службы SSB создаются независимо друг от друга в обеих систем баз данных.
--- In the Store database
create service StoreService on
queue StoreQueue(OrderProcessingContract);
go
--- In the Inventory database
create service InventoryService on
queue InventoryQueue(OrderProcessingContract);
go
И требуется создать маршрут для передачи сообщений из службы удаленной конечной точке. Маршруты являются каналы связи, привязки службы вместе.
--- Create route to InventoryService from Store database
create route Route2Inventory
with service_name = 'InventoryService',
address = 'tcp://Instance2:4037';
--- Create route to StoreService from Inventory database
create route Route2Store
with service_name = 'StoreService',
address = 'tcp://Instance1:4037';
На этом этапе заметкой готов создать привязку удаленной службы, сопоставляет учетные данные, используемые для открытия диалога с удаленной конечной точке SSB. Здесь ’s код для привязки.
--- Create remote service binding on Store database
create remote service binding ToInventory_RSB
to service 'InventoryService'
with user = InventoryUser;
--- Create remote service binding on Inventory database
create remote service binding ToStore_RSB
to service 'StoreService'
with user = StoreUser;
Диалог между службы в SSB технологии
Для установления канала связи между службами SSB все что нужно сделать — это начать беседу. Беседе создается с помощью инструкции BEGIN DIALOG CONVERSATION, и каждый экземпляр имеет уникальный дескриптор, представляющий канал для обмена данными. Инструкция SEND можно использовать для передачи сообщений через определенный открытые диалоги, определяя тип сообщения и его содержимое. Наконец Чтобы закончить беседу, используется инструкция END CONVERSATION.
На рис. 6 показана хранимая процедура вызывается пользователя, который будет введите данные заказа запрос записывать эту информацию в таблице tbOrder, запуск транзакций диалог между базы данных хранилища и базе данных запасов с помощью контракта и службы, созданного ранее и отправить экземпляре документа заказа запроса XML-схемы OrderRequestSchema через эту беседу. Эта хранимая процедура вызывается пользователем через заказ данных запись страницу запроса в веб-портале.
Рис 6 унок EnterOrderRequest хранимую процедуру в базу данных хранилища
--- Create the stored procedure EnterOrderRequest on the Store database
create procedure spEnterOrderRequest
@nOrderID int output,
@nCustomer int,
@nItemNumber int,
@nItemQuantity int
as
begin
declare @dialog_handle uniqueidentifier;
declare @Order_XDoc xml(OrderRequestSchema);
declare @dtNow datetime;
set @dtNow = getdate();
begin transaction
exec spInsertOrder @nOrderID
output,@nCustomer,@dtNow,@nItemNumber,@nItemQuantity;
set @Order_XDoc =
'<Order xmlns="http://www.mycorporation.com/2007_schemas/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mycorporation.com/2007_schemas/"
Id="'+cast(@nOrderID as varchar(10))+
'" Customer="'+cast(@nCustomer as varchar(10))+'"
Order_date="'+convert(varchar,@dtNow,126)+'-05:00">
<LineItem ItemNumber="'+cast(@nItemNumber as varchar(10))+
'" Quantity="'+cast(@nItemQuantity as varchar(10))+'"/>
</Order>';
begin dialog conversation @dialog_handle
from service StoreService
to service 'InventoryService'
on contract OrderProcessingContract;
send on conversation @dialog_handle
message type OrderRequestMsgType(@Order_XDoc);
commit;
end;
Чтобы проверить состояние передачи, выполнение запроса следующим на sys.transmission_queue системные таблицы и transmission_status поля в результирующем наборе для обнаружения ошибок.
---- Check the transmission status on the Store database.
select *
from sys.transmission_queue;
Теперь вы можете также просмотреть сообщение, которое поступает в очередь получателя (в данном случае очередь InventoryQueue) с помощью инструкция SELECT через основной очереди и анализ результирующего набора.
select message_type_name, cast(message_body as xml) message, queuing_order,
conversation_handle, conversation_group_id
from InventoryQueue;
Далее необходимо обработать сообщение запроса входящего заказа и отправить ответ заказа в базу данных хранилища со статусом фактической обработки. Сначала создадим хранимой процедуры, который реализует логику чтения очереди, связанные с очередью InventoryQueue. Чтобы начать, необходимо получать сообщение запроса заказа из запасов очереди с помощью инструкцию RECEIVE TOP (1). Извлечь идентификатор заказа и номенклатуры, с помощью метода значение XQuery типов данных XML и проверьте, существует ли в тестовой базы данных AdventureWorks в таблице Production.Product продукта. Далее создать ответное сообщение заказа с правильной обработки состояния и описание, отправить сообщение через диалоговое окно открыть диалог, с помощью оператора ON CONVERSATION SEND и наконец закончить беседу, используя инструкцию END CONVERSATION. Код показан на рис. 7.
Инструкция RECEIVE похож на оператор SQL SELECT что запроса объекта базы данных (в данном случае очереди) и присвоить значения результатов переменных. Инструкция RECEIVE удаляет сообщения из очереди после получения их, в отличие от инструкция SELECT, не удаляет записи из таблицы. XQuery является развивающихся язык запросов для источников данных XML. Он использует выражения XPath к определенным частям адреса документы. Например, выражение (или ns:Order/@Id)[1] позволяет выбрать дочернего код атрибута первого элемента заказа в передаваемых XML-документе. Хотя XQuery основном было придумано как язык запросов, теперь оно не усовершенствовано для обеспечения возможности преобразования, такие как XSLT.
На рис. 7 Создание хранимой процедуры spInventoryDB_QueueReader прочитанные сообщения из очереди InventoryQueue
--- Create stored procedure to process the incoming order request message
create procedure spInventoryDB_QueueReader
as
begin
declare @Conv_Dialog_Handle uniqueidentifier;
declare @Conv_Group_Handle uniqueidentifier;
declare @Order_XDoc xml(OrderRequestSchema);
declare @OrderConfirmation_Text varchar(8000);
declare @OrderConfirmation_XDoc xml(OrderResponseSchema);
declare @nOrderId int;
declare @nItemNumber int;
declare @nItemQuantity int;
declare @nItemNumberResult int;
declare @nProcessing_Status int;
declare @vcProcessing_Description varchar(120);
begin transaction;
--- Receive the message from the queue
receive top(1) @Order_XDoc = message_body,
@Conv_Dialog_Handle = conversation_handle,
@Conv_Group_Handle = conversation_group_id
from InventoryQueue;
--- Retrieve the order identifier
select @nOrderId = @Order_XDoc.value
('declare namespace ns="http://www.mycorporation.com/2007_schemas/";(/ns:Order/@Id)[1]', 'int');
select @nItemNumber = @Order_XDoc.value
('declare namespace ns="http://www.mycorporation.com/2007_schemas/";
(/ns:Order/ns:LineItem/@ItemNumber)[1]', 'int');
--- Process the incoming order request
select @nItemNumberResult=ProductID
from AdventureWorks.Production.Product
where ProductID=@nItemNumber;
if (@nItemNumberResult is null)
begin
set @nProcessing_Status = 2;
set @vcProcessing_Description = 'Processing transaction not
'successfully. No product in the
'Inventory database';
end
else
begin
set @nProcessing_Status = 1;
set @vcProcessing_Description = 'Processing transaction successfully.
'Found product in the Inventory
'database';
end;
--- Create the Order Confirmation message as a response
set @OrderConfirmation_Text =
'<OrderConfirmation xmlns="http://www.mycorporation.com/2007_schemas/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mycorporation.com/2007_schemas/">
<Id>'+cast(@nOrderId as varchar(10))+'</Id>
<Processing_Status>'+cast(@nProcessing_Status as varchar(10))+'</Processing_Status>
<Processing_Description>'+@vcProcessing_Description+'</Processing_Description>
</OrderConfirmation>';
set @OrderConfirmation_XDoc = @OrderConfirmation_Text;
---- Send the message through the open conversation dialog (@Dialog_Handler)
send on conversation @Conv_Dialog_Handle
message type OrderResponseMsgType(@OrderConfirmation_XDoc);
---- End the conversation
end conversation @Conv_Dialog_Handle;
commit;
end;
go
В базе данных магазина можно проверить подтверждения ответ на запрос заказа со следующим кодом.
---- Check the messages on the StoreQueue on the Store database.
select message_type_name, cast(message_body as xml) message, queuing_order,
conversation_handle, conversation_group_id
from StoreQueue;
Теперь мы создать spStoreDB_QueueReader хранимой процедуры, который реализует логику чтения очереди, связанные с очередью StoreQueue. Он использует ту же логику как spInventoryDB_QueueReader для получения сообщения из StoreQueue и обновления tbOrder таблицы обработки состояния и описание. Код показан на рис. 8.
На рис. 8 Создание spStoreDB_QueueReader хранимой процедуры для чтения сообщений из очереди StoreQueue.
--- Create stored procedure to process the order response message
create procedure spStoreDB_QueueReader
as
begin
declare @Conv_Dialog_Handle uniqueidentifier;
declare @Conv_Group_Handle uniqueidentifier;
declare @Order_XDoc xml(OrderResponseSchema);
declare @nOrderId int;
declare @nProcessing_Status int;
declare @vcProcessing_Description varchar(50);
begin transaction;
--- Receive the message from the queue
receive top(1) @Order_XDoc = message_body,
@Conv_Dialog_Handle = conversation_handle,
@Conv_Group_Handle = conversation_group_id
from StoreQueue;
--- Retrieve the order identifier
select @nOrderId = @Order_XDoc.value('declare namespace
ns="http://www.mycorporation.com/2007_schemas/";(/ns:OrderConfirmation/ns:Id)[1]', 'int');
select @nProcessing_Status = @Order_XDoc.value('declare namespace
ns="http://www.mycorporation.com/2007_schemas/";(/ns:OrderConfirmation/ns:Processing_Status)[1]', 'int');
select @vcProcessing_Description = @Order_XDoc.value('declare namespace
ns="http://www.mycorporation.com/2007_schemas/";
(/ns:OrderConfirmation/ns:Processing_Description)[1]', 'varchar(50)');
update tbOrder
set nOrderStatus=@nProcessing_Status,
vcOrderStatusDescription=@vcProcessing_Description
where nOrderID=@nOrderId;
commit;
end;
go
Наконец необходимо реализовать компонентов узла портала, клиентскую наше решение. Узла портала имеет две страницы, страницу операции запроса заказа и статус заказа страницы. Страницу записи запроса заказа позволяет пользователям ввести данные для запроса заказа и вызова spEnterOrderRequest хранимой процедуры, который реализует основной бизнес-логики связанных с заказом обработки с помощью брокера коммуникации, упоминалось ранее. Идентификатор заказа отображается позже проверить состояние заказа. На страницу состояния заказа позволяет проверить состояние заказа, указав идентификатор заказа.
Я использовать Visual Studio для создания нового веб-узла и добавляются два веб-форм. Первый OrderRequest_EntryPage.aspx, содержит три подписи описывают поля введите три веб управления TextBox (m_tbItemQuantity m_tbItemNumber, m_tbCustomerID) для получения данных о запрос заказа и кнопки управления веб (m_btSubmit), который разрешает выполнение бизнес-логики наше решение и отображение идентификатора заказа в вывод метки (m_lbOutput). На рисунке 9 показан код для страницы. Код, связанный с OrderRequest_EntryPage.aspx, отображается в рис. 10.
Рисунок 9 Макет OrderRequest_EntryPage.aspx.
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="OrderRequest_EntryPage.aspx.cs" Inherits="OrderRequest_EntryPage" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
<title>Order Request Entry page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<table border="0" width="100%" cellpadding="0" cellspacing="0">
<tr>
<td style="width:25%">
<asp:Label ID="Label1" runat="server" Text="Enter
CustomerID"></asp:Label>
</td>
<td style="width:75%">
<asp:TextBox ID="m_tbCustomerID"
runat="server"></asp:TextBox>
</td>
</tr>
<tr>
<td style="width:25%">
<asp:Label ID="Label2" runat="server" Text="Enter Item
Number"></asp:Label>
</td>
<td style="width:75%">
<asp:TextBox ID="m_tbItemNumber"
runat="server"></asp:TextBox>
</td>
</tr>
<tr>
<td style="width:25%">
<asp:Label ID="Label3" runat="server" Text="Enter Item
Quantity"></asp:Label>
</td>
<td style="width:75%">
<asp:TextBox ID="m_tbItemQuantity"
runat="server"></asp:TextBox>
</td>
</tr>
<tr>
<td style="width:25%">
<asp:Button ID="m_btSubmit" runat="server" Text="Submit" />
</td>
<td style="width:75%">
</td>
</tr>
<tr>
<td style="width:25%">
<asp:Label ID="m_lbOutput" runat="server"
Text=""></asp:Label>
</td>
<td style="width:75%">
</td>
</tr>
</table>
</div>
</form>
</body>
</html>
Рис. 10 Код программной части для страницы OrderRequest_EntryPage.aspx.
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Data.SqlClient;
public partial class OrderRequest_EntryPage : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void m_btSubmit_Click(object sender, EventArgs e)
{
using (SqlConnection objConnection = new SqlConnection())
{
objConnection.ConnectionString = "Data Source=localhost;Initial
Catalog=ServiceBrokerDB_Test;Integrated Security=True";
using (SqlCommand objCmd = new SqlCommand())
{
objCmd.Connection = objConnection;
objCmd.CommandType = CommandType.StoredProcedure;
objCmd.CommandText = "spEnterOrderRequest";
SqlParameter objOutputParam =
objCmd.Parameters.Add("@nOrderID",SqlDbType.Int);
objOutputParam.Direction = ParameterDirection.Output;
objCmd.Parameters.Add("@nCustomer",SqlDbType.Int).Value =
Convert.ToInt32(this.m_tbCustomerID.Text) ;
objCmd.Parameters.Add("@nItemNumber", SqlDbType.Int).Value =
Convert.ToInt32(this.m_tbItemNumber.Text);
objCmd.Parameters.Add("@nItemQuantity", SqlDbType.Int).Value
= Convert.ToInt32(this.m_tbItemQuantity.Text);
try
{
objConnection.Open();
objCmd.ExecuteNonQuery();
this.m_lbOutput.Text = "The Order Identifier is " +
objOutputParam.Value;
}
catch (SqlException ex)
{
this.m_lbOutput.Text = "Exception: " + ex.Message;
}
finally
{
objConnection.Close();
}
}
}
}
}
Далее является реализацией OrderStatus_Page.aspx, содержащий один элемент управления веб Label (Label1) и веб одного TextBox-элемент управления (m_tbOrderID) для получения идентификатора заказа и элемент веб управления "Кнопка" (m_btSubmit), позволяющий запрос статуса заказа. Состояние отображается с использованием последнего один выходной (m_lbOutput) веб-метка элемента управления. Код для страницы показан на рисунке 11, и ее программной части на рис. 12.
Рис. 11 Макет OrderStatus_Page.aspx.
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="OrderStatus_Page.aspx.cs" Inherits="OrderStatus_Page" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Order Status page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<table border="0" width="100%" cellpadding="0" cellspacing="0">
<tr>
<td style="width:25%">
<asp:Label ID="Label1" runat="server" Text="Enter
OrderID"></asp:Label>
</td>
<td style="width:75%">
<asp:TextBox ID="m_tbOrderID" runat="server"></asp:TextBox>
</td>
</tr>
<tr>
<td style="width:25%">
<asp:Button ID="m_btSubmit" runat="server" Text="Submit"
OnClick="m_btSubmit_Click" />
</td>
<td style="width:75%">
</td>
</tr>
<tr>
<td style="width:25%">
<asp:Label ID="m_lbOutput" runat="server"
Text=""></asp:Label>
</td>
<td style="width:75%">
</td>
</tr>
</table>
</div>
</form>
</body>
</html>
Рис. 12 Код программной части для страницы OrderStatus_Page.aspx
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Data.SqlClient;
public partial class OrderStatus_Page : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void m_btSubmit_Click(object sender, EventArgs e)
{
using (SqlConnection objConnection = new SqlConnection())
{
objConnection.ConnectionString = "Data Source=localhost;
Initial Catalog=ServiceBrokerDB_Test;Integrated Security=True";
using (SqlCommand objCmd = new SqlCommand())
{
objCmd.Connection = objConnection;
objCmd.CommandType = CommandType.Text;
objCmd.CommandText = "select vcOrderStatusDescription " +
"from tbOrder " +
"where nOrderID=@nOrderID";
objCmd.Parameters.Add
("@nOrderID", SqlDbType.Int).Value = Convert.ToInt32(this.m_tbOrderID.Text);
try
{
objConnection.Open();
SqlDataReader objReader = objCmd.ExecuteReader();
objReader.Read();
string strStatusDescription = objReader.GetString(0);
this.m_lbOutput.Text = "The Order Status is " + strStatusDescription;
}
catch (SqlException ex)
{
this.m_lbOutput.Text = "Exception: " + ex.Message;
}
finally
{
objConnection.Close();
}
}
}
}
}
С образцом, описанный теперь имеется шаблон для создания надежного, распределенных сообщениями решений с использованием технологий брокера служб SQL Server 2005. Необходимо иметь возможность и адаптировать примера в данной статье, расположенную на размеру бизнес-сценария.
Хуан Карлос Оламенди Турруеллас - старший архитектор и консультант по интеграционным решениям. Основными направлениями является объектно ориентированный анализ и разработки, проектирования базы данных, интеграции приложений предприятия, единого языка моделирования, шаблоны разработки, архитектуры приложения предприятия и процессов разработки программного обеспечения, с помощью гибких методологий. Он был награждается состояние наиболее ценный Professional корпорацией Майкрософт в 2007, 2008 и 2009 г., а также статусом ACE Oracle в 2008. Можно обратиться к Хуано по электронной почте на johnx_olam@fastmail.fm.