I am following this tutorial to send a message from service bus topic to email using Event Grid.
When I run the Logic App, I get the following error:
Failed to start a run of logic app test-servicebusq. The template language expression evaluation failed: 'The execution of template trigger 'When_a_resource_event_occurs' failed: the result of the evaluation of 'splitOn' expression '#triggerBody()' is of type 'Null'. The result must be a valid array.'
When I send a message to the service bus, the logic app does not get triggered at all.
I have turned of the 'splitOn' and when I run the logic app manually, the trigger gets fired and the logic app is executed, but when I send a message to the service bus topic, the trigger does not get triggered automatically (unless I manually Run the logic app).
I want the logic app to be automatically triggered when a new message arrives in the service bus.
Is there something I am doing wrong? I followed the tutorial step by step and I am still unable to figure out what is the problem. Do I need to create an event grid resource somewhere? (it is not mentioned in the tutorial)
Edit: I am using the following code to send the message
from azure.servicebus import ServiceBusClient, ServiceBusMessage
connstr = <connection string>
topic_name = "fileincomplete"
with ServiceBusClient.from_connection_string(connstr) as client:
with client.get_topic_sender(topic_name) as sender:
sender.send_messages(ServiceBusMessage("Data12"))
After reproducing in my local environment, I could able to make this work after mentioning the Event Type Item. Below is my logic app flow.
I am using the below code to send the messages
from azure.servicebus import ServiceBusClient, ServiceBusMessage
CONNECTION_STR = "<YOUR_NAMESPACE_CONNECTION_STRING>"
TOPIC_NAME = "<YOUR_TOPIC_NAME>"
servicebus_client = ServiceBusClient.from_connection_string(conn_str=CONNECTION_STR, logging_enable=True)
with servicebus_client:
sender = servicebus_client.get_topic_sender(topic_name=TOPIC_NAME)
with sender:
message = ServiceBusMessage("Data12")
sender.send_messages(message)
print("Sent a single message")
RESULTS:
Related
I've been recently having problems with my Service Bus queue. Random messages (one can pass and the other not) are placed on the deadletter queue with the error message saying:
"DeadLetterReason": "Moved because of Unable to get Message content There was an error deserializing the object of type System.String. The input source is not correctly formatted."
"DeadLetterErrorDescription": "Des"
This happens even before my consumer has the chance to receive the message from the queue.
The weird part is that when I requeue the message through Service Bus Explorer it passes and is successfully received and handled by my consumer.
I am using the same version of Service Bus either for sending and receiving the messages:
Azure.Messaging.ServiceBus, version: 7.2.1
My message is being sent like this:
await using var client = new ServiceBusClient(connString);
var sender = client.CreateSender(endpointName);
var message = new ServiceBusMessage(serializedMessage);
await sender.SendMessageAsync(message).ConfigureAwait(true);
So the solution I have for now for the described issue is that I implemented a retry policy for the messages that land on the dead-letter queue. The message is cloned from the DLQ and added again to the ServiceBus queue and for the second time there is no problems and the message completes successfully. I suppose that this happens because of some weird performance issues I might have in the Azure infrastructure. But this approach bought me some time to investigate further.
In Azure WebJobs, in the OnMessageOptions class, I'm calling the QueueClient.Complete(Guid) method by setting the AutoComplete flag to true and messages seem to dequeue just fine when running the ProcessQueue function. Active messages count goes down by 1 after successful processing of each message. However, when I want to requeue a message (because it cannot be processed currently) back to the queue that triggers the service bus function, as a new brokered message after a minute, using BrokeredMessage.ScheduledEnqueueTimeUtc, it seems like it isn't working. Scheduled messages count seems to go up initially. I go back to the queue after a few hours and see active messages in the thousands. The copies are of the same message. What is happening? I'd expect the message to be taken off the queue because of QueueClient.Complete(Guid) and the new scheduled message to be its replacement.
Some detail:
To send the message I do the following:
var queueclient = QueueClient.CreateFromConnectionString(connectionString, queueName);
queueclient.Send(message);
queueclient.close();
Inside the WebJob I created a ServiceBusConfiguration object which requires a onMessageOptions object where I set the AutoComplete=true. I pass the ServiceBusConfiguration object to the JobHostConfiguration.UserServiceBus
method.
Inside the WebJob service bus queue triggered function I again do the following to requeue, by first creating a new instance of the brokered message again.
//if not available yet for processing please requeue...
var queueclient = QueueClient.CreateFromConnectionString(connectionString, queueName);
queueclient.Send(message);
queueclient.close();
I don't do the following/use callbacks which is may be why it isn't working?
var options = new OnMessageOptions();
options.AutoComplete = false; // to call complete ourselves
Callback to handle received messages
client.OnMessage(m =>
{
var clone = m.Clone();
clone.ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddSeconds(60);
client.Send(clone);
m.Complete();
}, options);
when I want to requeue a message (because it cannot be processed currently) back to the queue that triggers the service bus function, as a new brokered message after a minute, using BrokeredMessage.ScheduledEnqueueTimeUtc, it seems like it isn't working
If you fail to process your message, do not re-queue it. Instead, abandon (with a reason) and it will be picked up again.
BrokeredMessage.ScheduledEnqueueTimeUtc is intended to be used for messages added to the queue. When you receive a message, you can complete, dead-letter, defer, or abandon. If you abandon a message, it will be retried, but you can't control when that will happen. If you have no other messages in the queue, it will be retried almost immediately.
Note: when you see a behaviour that you suspect is not right, having a simple repro to share would be very helpful.
I am currently using two different platforms to perform sync actions. So, when action happens on platform 1 (C# -visual studio), that same action then needs to happen on platform 2 (Java). To do that, I use SB (Azure service bus) for sharing the Json messages between two platforms.
Action 1: platform 1 ----> Service bus -----> platform 2 .
Works fine. The message is sent and received exactly as it should be.
Action 2: platform 2 ----> Service bus ----> platform 1.
Does not work. The message is sent correctly to SB, but when it's picked up, the content property only contains an empty array, when it should be an array of bytes (containing the message). The other message attributes like contentType, replyTo and so on are set correctly, so the message is getting picked up fine. It's just that there is no content or in other words message body.
Action 3: Azure SB/Send messages -----> Service bus -----> platform 1.
Works fine. Another option is to send the JSON message directly to the Service Bus using Azure Service Bus/Send messages and put the JSON message in there.
For actions 2 and 3 exactly the same message is sent to the service bus (when I view it). One is sent directly to service bus, another is generated by the platform 2. I think the actual message somehow seems to be different in the background, which is why the message body is empty in the action 2.
Threads and processes are being handled correctly.
To set up receiver:
IMessageReceiver receive r= null;
if (config.isSessionsEnabled()) {
receiver = ClientFactory.acceptSessionFromConnectionStringBuilder(new ConnectionStringBuilder(connString), config.getSessionID(), ReceiveMode.PEEKLOCK);
} else {
receiver = ClientFactory.createMessageReceiverFromConnectionStringBuilder(new ConnectionStringBuilder(connString), ReceiveMode.PEEKLOCK);
}
For receiving message:
try {
message = receiver.receive(Duration.ofSeconds(1)); //message.Content will be empty array
if(message != null){
//process message
}
} catch (Exception e) {
}
}
Is my understanding correct or perhaps there is another explanation to it!
Is my understanding correct or perhaps there is another explanation to it!
It is very odd that if you send the message from Java platform and the content of message is empty.
Based on my understanding, it seems that message content is empty when you send to ABS. I recommand that you could check the Java send message code before sending to ABS.
You alse could use Azure Service bus exploer to get the message information after it sent to ABS [Before received from .Net platform].
I am encountering one major road block issue when trying to use ServiceBusTrigger in azureFunction. I am trying to abandon, or deadletter, a service bus message in V2 ServiceBusTrigger, How can I do so? I've tried the following solution, but I didn't get anywhere.
Here is the codeSample I used:
public async static Task Run(Message myQueueItem, TraceWriter log, ExecutionContext context)
{
log.Info($"C# ServiceBus queue trigger function processed message delivery count: {myQueueItem.SystemProperties.DeliveryCount}");
QueueClient queueClient = new QueueClient("[connectionstring]","[queueName]");
////await queueClient.DeadLetterAsync(myQueueItem.SystemProperties.LockToken);
await queueClient.AbandonAsync(myQueueItem.SystemProperties.LockToken);
}
Solution 1: I tried to substitute Message myQueueItem for BrokeredMessage like in V1, I then can call myQueueItem.Abandon, or deadletter, on the message lever. However It came back with exception:
Microsoft.Azure.WebJobs.Host: Exception binding parameter 'myQueueItem'. System.Private.DataContractSerialization: There was an error deserializing the object of type Microsoft.ServiceBus.Messaging.BrokeredMessage. The input source is not correctly formatted. System.Private.DataContractSerialization: The input source is not correctly formatted."
At least I can go one step further. to
solution 2. Solution 2: is to use:
QueueClient queueClient = new QueueClient("[connectionstring]","[queueName]");
////await queueClient.DeadLetterAsync(myQueueItem.SystemProperties.LockToken);
await queueClient.AbandonAsync(myQueueItem.SystemProperties.LockToken);
I can use the lock provided in the Message Object, however, when I try to send it with queueClient, It said the message gone from the queue. or no longer available.
Can anybody let me know if i am on the right track? If I am not, please kindly guide me in the right track.
Service Bus messages are automatically completed or abandoned by Azure Functions runtime based on the success/failure of the function call, docs:
The Functions runtime receives a message in PeekLock mode. It calls Complete on the message if the function finishes successfully, or calls Abandon if the function fails.
So, the suggested way to Abandon your message is to throw an exception from function invocation.
I am subscribing to a channel in Pusher on my local machine using the Javascript SDK, and I don't get any error.
However, when I publish an event to that channel it is not received by the subscriber.
I've looked at Pusher's debug console and saw that the message is indeed sent but the subscription never occurs, as the connection is somehow interrupted, apparently prior to the subscription request (i.e I get a disconnection message, as shown in the console screenshot below).
the code is pretty boilerplate:
var pusher = new Pusher('PUSHER_KEY');
channel = pusher.subscribe('game' + game.gameId);
channel.bind('statusChange', function(game) {
console.log("GOT PUSHER - STATUS " + game.status);
$scope.game.status = game.status;
});
Examining the channel.subscribed property shows that the subscription failed as it equals false. I am at the sandbox plan (max 20 connections) and am only using 2 connections.
What can disrupt the connection?
The channel object:
Console screenshot:
I don't know what's the issue exactly but enabling the logs on the client side might help your find it:
Pusher.log = function(message) {
if (window.console && window.console.log) {
window.console.log(message);
}
};
There's some resources on the website to debug that kind of problem too: http://pusher.com/docs/debugging