2

so far I have tried many different tutorials to get this to work but so far I have not been able to achieve this.

Currently I have a nodejs app that sends messages to the Service Bus Queue and another nodejs that polls continuously. My goal is to send a message to the queue with a specific time and date on which the polling system can process the message.

My results so far is that as soon as I send the message, it becomes visible and it is processed right away, here is what I have

//made some changes after the first suggestion, but still does not work
//what I'm doing here is offsetting the time difference with UTC(im in GMT-7 tz) by adding it manually 
//(this is just a test so if this would have worked I would have made it more elegant)
var scheduled_time = new Date().valueOf() + ((60000*60)*7.5);
  var current_time = Date.now();
  console.log(scheduled_time, current_time);

  var message = {
    body: 'Time ' + current_time.toString(),
    brokerProperties:{
      ScheduledEnqueueTimeUtc: scheduled_time,
      TimeToLive: 8
    },
    customProperties: {
      testproperty: 'TestValue'
    }};

  serviceBus.sendQueueMessage('myqueue', message, function(error){
    if(!error){
      // message sent
      console.log('message sent');
    }
  });

My receiver is very simple

function receiveMessages() {
  serviceBus.receiveQueueMessage(queue,
      function (error, message) {
        if (error) {
          console.log(error);
        } else {
          console.log('Process after ' + message.brokerProperties.ScheduledEnqueueTimeUtc);
        }
      });
};

so far I have read the GitHub page with the description of the properties of the message and it seems correct to what I have but it still does not work.

Thank you

Marcianin
  • 461
  • 3
  • 8

4 Answers4

2

Date.now() returns a date in your timezone, not in UTC. You need to convert it to UTC. This question can help you with that.

Community
  • 1
  • 1
TheDude
  • 3,796
  • 2
  • 28
  • 51
  • hmmmm i was following this convention [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now] by Mozilla. But I will give a try to the solution presented in your commented link hopefully it helps – Marcianin Apr 01 '16 at 21:50
  • I have tried the solutions in the link that you provided but it does not work either. I thought that by offsetting the time difference manually it would work but it didn't either. I manually create a point in time so far in the future that it would definitely be in UTC but still the message gets processed as soon as it is sent... – Marcianin Apr 01 '16 at 23:35
  • This seems to indicate Date.now() is in fact milliseconds from epoch UTC: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now – rjbez Mar 17 '18 at 01:53
1

It appears one of the problems is with the format of ScheduledEnqueueTimeUtc. I was able to successfully delay queue messages in Azure Service Bus from Node.js using moment.js to adjust and format the date:

// Delay message by 1 hour
var scheduled_time = moment().utc().add(1, 'hour').format('M/D/YYYY H:mm:ss A');
var message = {
    body: 'Time ' + Date.now().toString(),
    brokerProperties: {
        ScheduledEnqueueTimeUtc: scheduled_time
    },
    customProperties: {
        testproperty: 'TestValue'
    }
};

The Service Bus docs and JavaScript SDK unfortunately don't appear to mention anything about what format ScheduledEnqueueTimeUtc should be in other than that the type is a String. However, if you look at code examples in .NET languages, the value is being passed using DateTime.toString() which defaults to the 'G' general date and time format specifier (example: 5/1/2009 9:00:00 AM). Following these examples, we can duplicate the format using something like moment.js: "M/D/YYYY H:mm:ss A". As TheDude mentioned, bear in mind the value must be in UTC and not local time.

Also, your TimeToLive value of 8 may be too short to allow processing, and note that delaying or scheduling a queue using ScheduledEnqueueTimeUtc doesn't guarantee that it will be processed at the specified date and time. It only guarantees the message won't be processed beforehand. See remarks in https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.scheduledenqueuetimeutc.aspx

  • This is an interesting suggestion, im going to give this a shot and report back, thank you @Derek Seymour (and yes, i was already aware that the enqueued date does not guarantee that it will be processed at that exact moment, which Im ok with as long as it gets processed after the specified date) – Marcianin Apr 18 '16 at 17:41
0

Per my experience, I think you could try to check the region for the Service Bus and your Node.js Application on Azure for keeping the same regions.

More information, please refer to the broker properties for BrokeredMessage Class https://msdn.microsoft.com/en-us/library/azure/microsoft.servicebus.messaging.brokeredmessage.aspx.

Peter Pan
  • 23,476
  • 4
  • 25
  • 43
0

The above example uses the azure-sb package which in turn uses HTTP to talk to Azure Service Bus. The newer @azure/service-bus package uses AMQP and is more performant than the azure-sb.

If using the @azure/service-bus package, then you can set the scheduledenqueuetimeutc directly on the message and send it. This property is of type Date

Ramya Rao
  • 111
  • 5