Экспорт (0) Печать
Развернуть все

Новости в выпуске за октябрь 2012 года

Обновлено: Март 2015 г.

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

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

  • Возможность возобновить блокировку сообщения.

  • Блокировки сообщений привязаны к сеансам.

  • Блокировка устанавливается на 60 секунд (по умолчанию), а ее максимальная длительность составляет 5 минут. Действует она так же, как и ранее.

Вызов RenewLock обновляет блокировку сообщения и обновляет свойство LockedUntilUtc после завершения RenewLock.

Для сеансов обмена сообщениями свойство LockedUntilUtc заполняется, когда пользователь принимает сеанс с помощью одного из методов клиента, например AcceptMessageSession, или одного из методов фабрики, например AcceptMessageSession.

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

Дополнительные сведения см. в разделе:

Теперь можно получить список всех разделов, очередей или подписок в соответствии с указанным фильтром ODATA. Пример:

IEnumerable<QueueDescription> qList = namespaceClient.GetQueues("startswith(path, 'I') eq true" );
foreach (QueueDescription qd in qList)
{
    Console.WriteLine("qd : {0}", qd.Path);
}

При использовании REST API синтаксис будет следующим:

?$Filter=encoded_odata_filter_string_here

Поддерживаются следующие сценарии.

  • Вывод списка всех разделов по пути. Например, «/test1/test2».

  • Вывод списка всех разделов, обновленных в течение последних 5 минут.

  • Вывод списка всех разделов, к которым был осуществлен доступ в течение последних 5 минут.

  • Вывод списка всех правил, созданных в течение последних 5 минут.

  • Вывод списка всех подписок по пути «/test1/test2» с не менее чем одним сообщением.

  • Вывод списка всех разделов по пути «/test1/test2» с не менее чем одним сообщением.

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

var msftSubscription = "MSFT";
var stocksTopic = "stocks";
var messageReceiver = factory.CreateMessageReceiver(msftSubscription);
var messageSender = factory.CreateMessageSender(stocksTopic,VIAENTITYPATH);
//…
var brokeredMessage1 = messageReceiver.Receive();
//…
using (var scope = new TransactionScope())
{
    //…
    var brokeredMessage2 = ProcessMessage(brokeredMessage1);
    //…
    messageSender.Send(brokeredMessage2);
    brokeredMessage1.Complete();
    scope.Complete();
}

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

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

QueueDescription destinationQ = new QueueDescription("myQ2");
QueueDescription sourceQ = new QueueDescription("myQ1");
sourceQ.ForwardTo = “myQ2";
NamespaceManager nm = NamespaceManager.Create();
nm.CreateQueue(destinationQ);
nm.CreateQueue(sourceQ);

Дополнительные сведения см. в разделе Последовательное соединение сущностей Service Bus с помощью автоматической пересылки.

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

Чтобы воспользоваться данной функцией, настройте перечисление EntityStatus, затем вызовите один из следующих интерфейсов API, указав в качестве параметра объект описания объекта:

Пример:

QueueDescription qd = namespaceManager.GetQueue("myQ");
qd.Status = EntityStatus.Disabled;
namespaceManager.UpdateQueue(qd);
qd.Status = EntityStatus.Active;
namespaceManager.UpdateQueue(qd);

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

PropertyNameOne=’ValueOne’ AND PropertyNameTwo=ValueTwo AND PropertyNameTest=’ValueThree’
CorrelationFilter filter = new CorrelationFilter();
filter.Properties.Add(
new KeyValuePair<string, object>("name", 10));

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

Пример:

IEnumerable<BrokeredMessage> messageSet;
messageSender.SendBatch(messageSet);
messageSet = messageReceiver.ReceiveBatch(100); // max message count

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

Чтобы воспользоваться этой функцией, присвойте свойству EnableFilteringMessagesBeforePublishing значение true. Пример:

TopicDescription td = new TopicDescription("Topic");
td.EnableFilteringMessagesBeforePublishing = true;

С помощью этой новой функции можно добавлять или изменять свойства сообщения при выполнении операций Abandon, Defer или DeadLetter. Эта функция может быть удобна в сценариях, при которых произошла ошибка обработки приложения, и пользователю необходимо отследить, приводит ли она к отказу от сообщения. Для этого можно добавить или изменить свойства сообщения в параметре propertiesToModify следующих интерфейсов API:

В Служебная шина представлен новый класс, который называется Microsoft.ServiceBus.Messaging.MessageCountDetails. Он содержит свойства, позволяющие получать сведения о сообщениях из подочередей основных объектов обмена сообщениями (очередей, разделов, подписок). Свойства MessageCountDetails перечислены ниже.

public long ActiveMessageCount { get; set; }
public long DeadletterMessageCount { get; set; }
public long ScheduledMessageCount { get; set; }
public long TransferMessageCount { get; set; }
public long TransferDeadLetterMessageCount { get; set; }

Класс BrokeredMessage включает в себя новое свойство, IsBodyConsumed, которое позволяет проверить, был ли использован текст сообщения. Например, если не удалось отправить сообщение, можно проверить, возможно ли отправить его повторно. Или ,если сообщение получено, можно проверить, был ли использован текст сообщения.

В случае одного из приведенных ниже событий IsBodyConsumed присваивается значение true:

  1. Какой-либо пользователь вызвал GetBody, чтобы использовать текст сообщения.

  2. После операции отправки сообщение было помечено как использованное.

Если значение — true, то любая операция GetBody или Send с этим сообщением возвращает исключение, которое означает, что сообщение использовано. Затем можно воссоздать сообщение, чтобы повторить операцию (например, Clone сообщение для отправки).

Класс BrokeredMessage включает в себя новый метод, Clone. Данный метод позволяет отправить клон сообщения как новое сообщение. Свойства и текст сообщения копируются в клон, однако системные свойства нового сообщения остаются «как есть», поэтому возможно избирательное копирование. Обратите внимание, что после операции клонирования можно вручную настроить свойство MessageId.

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

Дополнительные сведения см. в разделе Настройка строк подключения.

Теперь привязка WebHttpRelayBinding поддерживает формат содержимого JSON. Чтобы обновить прослушиватель для получения сообщений JSON, задайте свойство ContentTypeMapper для WebHttpRelayBinding. Например, см. пример WebContentTypeMapper.

Ранее поведение ConnectionStatusBehavior работало только с односторонними привязками. Теперь его можно использовать для всех привязок прослушивателя.

Для привязок ретрансляции Служебная шина используется поблочное шифрование передачи HTTP 1.1. Некоторые устаревшие прокси-серверы поддерживают только протокол HTTP 1.0 либо не обеспечивают правильную поддержку поблочного шифрования передачи HTTP 1.1. Это может привести к сбою подключений клиентов, проходящих через такие устаревшие прокси-серверы, к ретранслятору Служебная шина. Чтобы устранить данную проблему, теперь, в случае сбоя предыдущего подключения, при попытке подключения привязок ретрансляции Служебная шина используется протокол HTTPS. Чтобы использовать эту функцию, задайте для параметра Mode в свойстве SystemConnectivity значение AutoDetect или Http. Дополнительные сведения см. в разделе документации к перечислению ConnectivityMode.

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

Чтобы данная функция работала при размещении за брандмауэром, необходимо разрешить исходящие соединения HTTPS через порт 443.

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

Показ:
© 2015 Microsoft