NServiceBus как механизм трассировки кода: отправка сообщений из библиотеки классов и отображение в веб-приложении с помощью SignalR - PullRequest
1 голос
/ 12 октября 2011

Я изо всех сил пытаюсь использовать NServiceBus впервые, без фона ESB.После прочтения сообщений в блоге, примеров, документов и т. Д. Я не могу понять, почему моя библиотека классов C # не будет отправлять сообщения.на Bus.Send (msg) Я получаю сообщение «Не указан пункт назначения для сообщения Messages.TraceStatement. Сообщение не может быть отправлено. Проверьте раздел UnicastBusConfig в файле конфигурации и убедитесь, что MessageEndpointMapping существует для типа сообщения».

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

Я намереваюсь использовать SignalR и NServiceBus какБен сделал , но с двумя основными изменениями:

  1. Не использовать NServiceBus.Host.exe.Я хочу использовать только веб-интерфейс без консольной реализации.
  2. Сообщения отправляются из библиотеки классов среднего уровня с целью отслеживания кода в режиме реального времени.Другими словами, я хочу разбросать операторы Bus.Send вокруг моего кода и, таким образом, иметь возможность просматривать операторы трассировки выполнения кода (которые являются просто специальными строками, установленными разработчиком) на веб-странице.

Предполагая, что я не понял неправильно NServiceBus до такой степени, что то, что я предполагаю, даже невозможно (или неправильное использование технологии), я хотел бы выяснить, как отправлять сообщения из библиотеки классов.В настоящее время у меня есть dll "Managers", который имеет файл app.config следующим образом:

<configuration>
  <configSections>
    <section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" />
    <section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />
  </configSections>

    <MsmqTransportConfig InputQueue="TerminalQueue" ErrorQueue="TerminalErrorQueue" NumberOfWorkerThreads="1" MaxRetries="5"/>

    <UnicastBusConfig>
        <MessageEndpointMappings>
            <add Messages="Messages" Endpoint="WorkerQueue" />
        </MessageEndpointMappings>
    </UnicastBusConfig>
</configuration>

Примечание: в проекте Бена я переименовал "Commands" в "Messages".Таким образом (ссылаясь на сообщение об ошибке в верхней части моего поста), насколько я могу судить, я правильно определил MessageEndpointMapping.(Я проверил, что очередь существует в MSMQ.)

Может кто-нибудь сказать мне, что я делаю неправильно?

Кроме того, я был бы очень признателен за информацию о том, как удалить зависимость NServiceBus.Host.exe (см. Проект Worker в примере Бена).В идеале библиотека классов будет отправлять сообщение (как это сделал терминал в проекте Бена), а веб-приложение, как подписчик, сможет обрабатывать событие и использовать SignalR для отображения сообщения.

ОБНОВЛЕНИЕ

В настоящее время я отключил конфигурационную DLL в проекте библиотеки классов, потому что я думаю, что Web.config ее охватит.Итак, мой Web.config теперь выглядит следующим образом:

<section name="microsoft.web.services3" type="Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" />
<section name="MsmqSubscriptionStorageConfig" type="NServiceBus.Config.MsmqSubscriptionStorageConfig, NServiceBus.Core" />
<section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />

<MsmqTransportConfig
      InputQueue="WebQueue"
      ErrorQueue="WebErrorQueue"
      NumberOfWorkerThreads="1"
      MaxRetries="5"
/>

<UnicastBusConfig>
    <MessageEndpointMappings>
        <add Messages="MessageEvents" Endpoint="WebQueue" />
    </MessageEndpointMappings>
</UnicastBusConfig>

Я также создал личную очередь tramsactional под названием "NServiceBus_Subscription" согласно http://docs.particular.net/nservicebus/messaging/publish-subscribe/.

В моем Global.asax.cs есть это:

Bus = Configure
    .WithWeb()
        .DefaultBuilder()
        .XmlSerializer()
        .MsmqTransport()
        .PurgeOnStartup(false)
        .UnicastBus()
        .LoadMessageHandlers()
            .MsmqSubscriptionStorage()
        .CreateBus()
        .Start();

Ответы [ 2 ]

1 голос
/ 13 октября 2011

Это похоже на интересное упражнение. Это полезность может быть немного сомнительным. В конце концов, сообщения MSMQ не гарантированно поступают в каком-либо конкретном порядке, поэтому трудно точно сказать, что происходит в вашей библиотеке классов, на основе полученных сообщений. Правильно ли я понимаю, что проверяемая библиотека классов и диагностическая веб-страница находятся в одном веб-приложении? В таком случае было бы намного проще использовать простые события / делегаты .NET для трассировки, а затем доставлять их на веб-страницу с помощью SignalR.

Но, как я уже сказал, это интересное упражнение, так что ...

Как показывает ответ Бена, конфигурация для веб-приложения для отправки сообщений себе должна иметь MsmqTransportConfig InputQueue («домашняя база» шины, куда он получает сообщения), соответствовать очереди конечной точки UnicastBusConfig MessageEndpointMappings (куда оно будет отправлять сообщения этого типа или подписаться на сообщения этого типа от.)

Другой отсутствующей деталью может быть свободная конфигурация, которую вы используете для размещения шины в вашем веб-приложении. Вы должны убедиться, что ваша конфигурация содержит строку .LoadMessageHandlers(), как показано в Hosting NServiceBus в вашем собственном процессе . Многие примеры в Интернете пропускают это, потому что они являются конечными точками только для отправки, которые не обрабатывают сообщения.

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

1 голос
/ 13 октября 2011

Если вы собираетесь отправлять сообщения локально, значит, ваша конфигурация неверна. Должно быть:

<MsmqTransportConfig InputQueue="WebAppQueue" ErrorQueue="TerminalErrorQueue" NumberOfWorkerThreads="1" MaxRetries="5"/>

<UnicastBusConfig>
    <MessageEndpointMappings>
        <add Messages="Messages" Endpoint="WebAppQueue" />
    </MessageEndpointMappings>
</UnicastBusConfig>

Однако нет необходимости добавлять MessageEndpointMappings для локальной отправки. Вы можете позвонить Bus.SendLocal, чтобы сделать это. Если вы публикуете и подписываетесь на события (через Bus.Publish), тогда вам нужны сопоставления.

Недавно я опубликовал пример , который делает все это на одном хосте. Единственная разница в том, что вы не будете использовать общий хост, поэтому вам следует обратиться к http://docs.particular.net/samples/web/asp-mvc-application/

...