I am trying to trigger my Azure Pipeline using an HTTP request. I am doing this using the Runs API provided by Azure DevOps,
https://learn.microsoft.com/en-us/rest/api/azure/devops/pipelines/runs/run-pipeline?view=azure-devops-rest-6.0
I want to be able to access the message body sent along with the POST request, within my pipeline.
I know that it is possible to do the following,
Add parameters to my pipeline similar to what has been shown below,
parameters:
- name: id
type: string
Send the message body of my request to the Runs API within templateParameters to be able to access the values as parameters.
The issue that I am facing is, my pipeline will actually be triggered by a Webhook and as a result, I don't have control over the structure of the message body. I cannot put the data within templateParameters for the values to be accessible through the parameters.
Is there any other way that I can access the values of the message body? Is there some other solution to my problem?
As #Thomas mentioned, the body of the request sent will need to be as defined in the DevOps API, therefore, I had to use an Azure Function as an intermediary to take my initial request, put it inside of templateParameters and re-route it to Azure DevOps.
Related
I have a web activity within ADF pipeline which calls the Logic app to get a file from azure blob storage depending on some switch conditions and send email notification with the file as an attachment.
adf pipeline -> web activity -> logic app http trigger -> switch condition -> gets file content from azure blob storage if the condition is satisfied -> send email with file as attachment
I was testing this component for scenarios where the switch condition is satisfied and the file doesn't exists. The logic app as expected fails with the resource not found error, but the web activity completes successfully.
Has anyone faced similar situation, any pointers would be useful.
Your http triggered logic app is by default asynchronous. This means when you call the API/logic app, you will get a 201 response code indicating that the Logic app has received the request but does not indicate if it has finished processing the request. This is what is happening in your case. To confirm, you can check if the response code is 201. The behavior is similar when you attempt to execute the logic app via a request from Postman.
To fix this, you will need to make the logic app synchronous. To do this, you will need to add a success response step at the end of the logic app to respond with a 200. You will need to add additional response steps to respond with a failure response code wherever your logic app may fail. You can refer how to set your logic app using this LINK.
How do I send a JSON payload to a Zabbix Trapper Item without using Zabbix Sender?
I see the documentation on how to format the sender request and I see the documentation related to the header, but I haven't found how to use the header with a JSON payload.
My goal is to send Azure Activity Logs to Zabbix a Trapper Item using Azure Alerts.
I don't want to setup a Script Item or equivalent that would pull the information from the Azure API, as I would then have to worry about hitting the query limit for the Azure Management APIs and being throttled by the Azure platform.
How is the header incorporated into the request payload?
You need to use an implementation of the same protocol, for example:
in go: https://github.com/adubkov/go-zabbix
in python: https://github.com/adubkov/py-zabbix
and put that in a cloud function to send the payload to Zabbix.
My InvokeRESTAPI displays the following if executed:
I can see a Response field printed that is empty.
Can I somehow use this to get a value back from the API reply and use it to call another template with it?
On the task itself I am using this parameter:
successCriteria: eq(root["status"], "successful")
So I would assume that if there is some custom success criterion then I would be able to use a value from the response in order to define it.
Based on your screenshot, you are using the API to post the json content to Azure Logic App workflow.
So you need to add the Response Action in Azure Logic App to add response content to the work flow.
Here are the steps:
In Logic App:
Then when you run the API in Invoke Rest API task, it will show the customer response.
For more detailed info, you could refer to this doc: Construct the response
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.
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..