Constant Learner
Constant Learner

Reputation: 525

REBUS Send message in Queue ,and receive in another application

I want to implement following scenario using rebus. I am creating on sender application and one receiving application. There will be a class suppose

   public class GetPersonRequest
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

    public class GetPersonResponse
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

I will send this class object in queue with values. And want to display those value in receiver. How to achieve this?

SENDER code like this:

  static void Main(string[] args)
       {
            GetPersonRequest objGetPersonRequest = new GetPersonRequest();
            objGetPersonRequest.Id = 12;
            objGetPersonRequest.Name = "Kumar";

        using (var activator = new BuiltinHandlerActivator())
        {
            activator.Register(() => new PrintName());

            var bus = Configure.With(activator)
  .Logging(l => l.None())
  .Transport(t => t.UseMsmq("rebus-application.input"))
  .Routing(r => r.TypeBased().Map<GetPersonRequest>("rebus.application.output"))
  .Start();

            bus.Send(objGetPersonRequest);

            Console.WriteLine("Press enter to quit");
            Console.ReadLine();
        }

RECEIVER Code like this in another console application:

   static void Main(string[] args)
        {
            using (var activator = new BuiltinHandlerActivator())
            {
            activator.Register(() => new PrintName());

            var bus = Configure.With(activator)
      .Logging(l => l.None())
      .Transport(t => t.UseMsmq("rebus-application.output"))
      .Routing(r => r.TypeBased().Map<GetPersonResponse>("rebus-application.input"))
      .Start();


            Console.WriteLine("Press enter to quit");
            Console.ReadLine();
        }
    }

 class PrintName : IHandleMessages<GetPersonResponse>
    {
        public async Task Handle(GetPersonResponse objGetPersonResponse)
        {
            Console.WriteLine("RebusDetails Name is {0}", objGetPersonResponse.Name);
        }
    }

How to achieve this?

Upvotes: 4

Views: 2789

Answers (1)

mookid8000
mookid8000

Reputation: 18628

I suggest you take a look at the request/reply sample from the RebusSamples repository - it shows the configuration needed in order to do proper request/reply.

From quickly glancing over your code, I can see the following issues/misunderstandings:

  • Rebus methods are asynchronous, hence bus.Send(objGetPersonRequest) will execute on another thread and you will not know if it failed - always either await bus.Send(...) or bus.Send(...).Wait()
  • In many cases, only "clients" (*) should have endpoint mappings - in your case, you should map GetPersonRequest (or possibly the entire assembly containing it?) to rebus.application.output, and then do an await bus.Reply(new GetPersonResponse(...)) in the handler - this way, the "server"(*) will not have any dependencies

Moreover - this might be a detail, but I think it leads to a better understanding and easier communication over time:

  • There's no such thing as an "output queue" - all queues are the input queue of the endpoint that has it as its input queue - therefore, I would argue that the name rebus-application.output is misleading
  • I suggest you change your queue names to something that identifies each endpoint better, e.g. since your server seems to be capable of returning a person's details, you could call it masterdata, crm, etc., possibly suffixing .input if you e.g. want to have an error queue for each endpoint (e.g. masterdata.input and masterdata.error).

I hope that makes sense :)


(*) In my experience, it's beneficial to have a pretty clear distinction between client and server roles for your endpoints, where clients are endpoints with no (or very few) afferent couplings, which allows for them to easily be added/removed/changed, and servers are endpoints with more afferent couplings.

When you await bus.Reply(...) from a server, it allows for the sender to remain a client and not have its endpoint address configured anywhere but in its own configuration.

Upvotes: 1

Related Questions