none
Servicebus multiple jobs RRS feed

  • Question

  • We have 7-8 Webjobs running that are supposed to process the same info in a specific order. What is the preferred way of doing this with servicebus? Is there best practice to use the servicebus for this?

    At the moment I'm at something like this:


    The packet comes in from our clients, goes through 2 jobs, and then gets sent to 3 jobs (not all of them are always necessary, they're sharing jobs. Some packets go to facebook, some to FTP, some both,.. And only after all 3 of them are done the last Job can proceed, since it's based on the info the 3 jobs give.

    We could write states to the database, but we're specfically switching to servicebus to work transactional with our packets, have an easy way to recover on crashes and so on.

    Also, would the best way be 4 different servicebusses or 1 bus where (if that is even possible) we requeue the same packet with a state field? For example add a statefield "Job1=OK" and Job 2 has a subscription on that field, so that it gets the packet when it's passed Job1. That would be ideal, it would also miminize the traffic to the servicebus since the packet stays on it until the end..

    After some searching I found that I can forward messages, but can I forward them to the same topic too? And can I add data to them? And if I forward a message, does that count as an extra message in pricing?

    Monday, November 14, 2016 8:22 AM

All replies

  • You can leverage sessions for the last job. Say those 3 parallel jobs know what session they need to write on then they can send a "completed" message to the session. Last job won't continue until it gets 3 messages from the session. Pretty simple solution I think.

    Regarding your number of queues question, use separate Service Bus queues/topics for each job to read. It will be hard to maintain the logic on a single messaging entity.

    Monday, November 14, 2016 6:15 PM
  • Looks like a good candidate for Logic App.


    Frank

    Wednesday, November 30, 2016 4:48 PM