I have an Alert configured to my app service. Consider I have server down check alert.
Whenever the alert gets triggered , I want the mail to be delivered to our mailbox with sufficient details. To achieve this, Iam directly calling the sendgrid api from Azure Alert Webhook. Im able to send mail with hardcoded data. I would want to utilise the details , Azure Alert possess, to include in the mail.
Webhook url is as follow:
https://api.sendgrid.com/api/mail.send.json?api_user=********&api_key=****&to=*****&toname=*&subject=&text=#workspaceid%20#applicationid&from=**
"#workspaceid" is a parameter of json that is being sent.
However the approach does not work.
I would like to have entire json content that is initiated by Azure alerts to be included in mail body.
The JSON payload send by the alert needs to be parsed, somehow, and sent onwards to SendGrid. I haven't found any way to do this elegantly, so that you could just call a parameter from the JSON and pass it along the mail call.
However, there are still way we could build this :)
Microsoft Flow
Using a flow we can trigger it from a HTTP request and have it parse the input. Once the input is parsed we can get the relevant parameters and form the SendGrid URL for sending the email.
This approach is a bit more involved but it opens a lot more doors for setting up all kinds of logic an alert could trigger.
See this link for how to create a flow triggered from a HTTP request.
Related
I need to know what am I doing wrong with my integration. I will explain first our main goal.
We need to detect new synced projects or created projects on Everhour API using a webhook.
Use that webhook to trigger automation on Zapier and do other APIs we need to do.
The process of creating a webhook using their API is like this:
Use the create a webhook endpoint ( link )
Pass the custom webhook(I created on Pipedream with custom header)
The Everhour API requirements say that I need to reply back a custom header of "X-Hook-Secret ":
So far I have created a webhook on Pipedream which you can create a custom header response see reference here:
This is the request body from the Everhour API to create a webhook, I passed in the Pipedream's custom webhook created.
Now, the problem is when I create a new project on Everhour the webhook doesn't get triggered. I don't know if it's because of the custom webhook from Pipedream that I miss something or else others.
Any useful tips will be a huge help.
I am trying to create a logic app with email received trigger.
When email has multiple attachments, I am able to loop and make a http call per attachment
However we have to send the whole email as http call by creating .eml file of the email with attachments.
Pls advise
While the built-in actions do not seem to support this out of the box, you can make a Microsoft Graph API call to get the MIME content of a message.
There is no official connector for all available Microsoft Graph APIs, so you would need to use the HTTP with Azure AD Connector instead.
The response body content could then be written to a file in blob storage using the Create Blob Action.
I have created a post api and did put that post api inside the event webhook settings of sendgrid. But when i enabled it and check the json response on my api in local, i am getting fake messages and not real data.
Anyone know whats the reason. I checked their documentation, it is not telling anything else.
Source of information : https://sendgrid.com/docs/for-developers/tracking-events/getting-started-event-webhook/
If you are using event webhook according to above documentation in the question. You wont get the real data as for testing purpose sendgrid sends that data from your account. Instead try implementing the API. Then you will get the real response as it would contain your sendgrid api key.
In Azure Application Insights Alerts we have configured Webhooks to send Json Payload to ServiceNow (third party ticket generation app). Alerts are fired and we can view that on Azure Portal but is there anyway to know what was the PAYLOAD that was sent at that specific time when the Alert was fired. I can see the history of the Alerts fired but there is no view/information on what was the payload that was generated and sent thru webhook.
is it possible?
You can view the alert's payload by running a query against the Alerts Management REST API: https://learn.microsoft.com/en-us/rest/api/monitor/alertsmanagement/alerts/getbyid
If you're using the common alerts schema, the payload you'll get is exactly the one that was sent through the webhook. Otherwise, some fields might appear under the 'essentials' section instead of under the 'context' section.
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..