I want to use REST API to send message to a servicebus topic.
Everything's working fine, the message is sent on the topic.
My client received an ACK fron servicebus by receiving an HTTP code 201, a void body, and some headers.
But I didn't received the messageId. I need it to retrieve treatment status in my internal product.
However, as at described into the documentation (https://learn.microsoft.com/en-us/rest/api/servicebus/message-headers-and-properties), the MessageId should be returned.
Is it normal? And how can I retrieve the MessageId?
The only other option is to set the MessageId by the client way, but I don't like this solution because it is not the responsability of the client to do that.
Related
For getting envelop status, I followed these steps
docusign developer account, under connect, I created a connect with webhook url.
In code , I have given eventNotification with webhook listener url with https:// address of my application.
I am getting response in connect logs. But I am not getting any response in my application webhook listner .why?
I have used Laravel code, with route
Route::post('webhook', [TestController::class, 'webhook']);
But I am not getting any response in function?why?
Ensure that your server (the "listener") has an https URL that is visible (callable) from the public internet. Best way to confirm this: implement a GET function at a URL such as https://your-server.com/hello. It should reply with "hello" when called. Then try entering that URL on your mobile phone.
Look at DocuSign's Connect error log to see what it says.
To assure yourself that DocuSign is sending notification messages, first use https://webhook.site to get a test webhook listener URL, and configure DocuSign to use it.
If you feel that the messages are being sent to your server but are not being received by your software, check your web server's logs. For example, if you're including documents in your notifications, the notifications will be very large and may exceed your web server's default configuration limits.
One issue which I have found, the response which is sent from Webhook to our own custom API, which will receive request from webhook does not match
For e.g.argument webhook sends json payload , so make sure you have same object which is supported by your api from docusign connect
// this is C# code
public async Task Post([FromBody] JObject envelopeData)
To test locally, you can use ngrock, which will create local server but you will be able to debug
You can try something as below. The same worked for me.
if (!Request.Body.CanSeek) { Request.EnableBuffering(); }
Request.Body.Position = 0;
var reader = new StreamReader(Request.Body, Encoding.UTF8);
var body = await reader.ReadToEndAsync().ConfigureAwait(false);
I'm using Azure Alerts to use webhooks. I added the webhook in the action group. The URL I used is the one from Slack.
I also added a Notification Type Email. The notification email gets triggered but I am not receiving any message in the Slack channel.
I was able to push messages to the webhooks using postman hence I know my webhook is correct. But Azure Alert is not able to trigger the webhook. I am not receiving any messages in the Slack channel.
Azure Monitor sends a notification with its own schema definition. Slack doesn't recognize it, so you cannot see any notifications in the channel. It is possible to create a Logic App or Azure Function to transform the default schema.
Here the more information about it:
https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-common-schema
Slack expect a json object when using webhooks. When sending directly from azure alert you will get bad request.
Every slack channel has an e-mail adress. You can post messages to the channel using that email in azure alerts
Anyone looking for using Slack and Azure Alerts. This seems to work fine:
...
webhook_receiver {
name = "Slack"
service_uri = "https://hooks.slack.com/services/secret"
use_common_alert_schema = false
}
Then in the scheduled query rules alert:
...
action {
action_group = [data.azurerm_monitor_action_group.actiongroup.id]
email_subject = "Disk storage at less than 10%"
custom_webhook_payload = "{ \"text\" : \"Warning: Storage has less than 10% diskspace remaining!\"}"
}
I am setting up push notifications for gmail based on the guide provided by google (https://developers.google.com/gmail/api/guides/push). I want to have my node app register a client with .watch(), and then receive emails at a specified endpoint, as described in the documentation.
I have created the pub/sub topic, added gmail as a publisher, added a subscriber, and called watch() in my node app. watch() returns the appropriate { historyId: xxxx, expiration: yyyy } object which, according to google's documentation, means the call succeeded.
handler for receiving email notification on backend:
export const receiveGmailEmail: RequestHandler = async (req, res) => {
log('Received update from google!');
log(JSON.stringify(req.body, null, 2));
return res.status(200);
}
Registering:
const watchRes = await gmailClient.watch();
log('====> Watch Response <=====');
log(JSON.stringify(watchRes, null, 2));
Server log that shows it is registering properly:
====> Watch Response <=====
{
"historyId": "6560",
"expiration": "1562025255689"
}
I never receive messages at the receive endpoint on my node app. According to the server logs, I never actually receive any request when a message is published. The problem appears to be that my messages are undelivered. I have confirmed through the Stackdriver monitor that the pub/sub topic is publishing messages when I send an email to the email address, but if I view the details of the subscription in Stackdriver, it shows an increasing number of undelivered messages.
Any thoughts on why messages in a subscription are sitting around undelivered?
It turns out this wasn't a Google pub/sub issue. Amazon Cloudfront blocks POST requests by default, so I had to edit the caching behavior to enable POST requests. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesAllowedHTTPMethods
Is it possible to send messages to azure to any custom topic via mqtt. All example that I've found so far work with standard topics
'devices/' + hubName + '/messages/events/'
'devices/' + hubName + '/messages/devicebound/#'
Btw, I tried to send/subscribe on the topic/subscription above with MQTT.fx application and never received messages, although the connection was successful.
The topic filter of devices/{device_id}/messages/devicebound/# is to subscribe receiving message from IoT Hub(Cloud-To-Device message), it think you need to understand the difference about device-to-cloud message and cloud-to-device message from here.
The topic of devices/{device_id}/messages/events/ is for sending a device-to-cloud message from device.
You can use Device Explorer to test this issue. When you send a message to device with the tool, MQTT.fx will receive the message.
I am implementing AWS SNS with AWS SES.
I am registering notification that calls my http endpoint handler and i am receiving perfect notification object. But along with notification identity i want to send my extra payloads that can be received when registered endpoints called. I am doing it in nodeJS
here is the snippet of registering notification
var params = {
Identity: 'myemail#mydomain.com', /* required */
NotificationType: 'Bounce', //["Delivery","Bounce","Complaint"], /* required */
SnsTopic: 'arn:aws-arnstring'
};
ses.setIdentityNotificationTopic(params, function(err, data) {
if (err) console.log(err, err.stack); // an error occurred
else console.log(data); // successful response
});
is there anyway to send extra params like Identity and NotificationType ?
thanks in advance
There does not appear to b a mechanism for adding metadata, however... the notification should contain source inside the mail object, which looks like it would be the sending email address.
Arguably, there's no need for additional metadata, because there's also the messageId provided with the notifications. This is the same identifier you got back when you submitted the message.
If you saved the metadata locally (or even in simpledb, dynamodb, rds, or even S3) under that ID when the message was submitted, you'd be able to look it up again. If you don't save something with each message you send, then you don't have a way to "close the loop" and track the fact that you've received a notification of bounce, complaint, or delivery of each message to each recipient from SES.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/notification-contents.html
It isn't currently possible to send extra parameters along with the notification. You should submit this feature request to the Amazon SES team, either via the Amazon SES forums or through AWS Developer Support.