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
Related
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.
This is in relation to the question : -
How can I pass Body Parameters to API Post operation using API Management Action in Logic App?
Now I am able to pass JSON through the body of my logic app.
I would like to pass CSV or XML data as Body Parameters to API Post operation using API Management Action in Logic App.
Currently, the APIM accepts JSON sample only.
I am able to pass CSV or XML data using postman without any issues. Please find the attached pictures for details of this issue.
Thanks,
Paul
As I mentioned in comments, the solution is:
Add representation with "CONTENT TYPE" as text/csv and leave the "SAMPLE" and "DEFINITION" box empty like below screenshot:
And then in your logic app, request the api like this:
I'm looking at the Logic Apps Yammer connector.
When we put a message on Yammer we want to find out who has read it. Is there a way to find a list of people in a Yammer group who have not read a Yammer message?
If it can't be done in Logic Apps, is there another way to do it?
As a workaround, I'm trying to do this on the basis of who has liked a message and have done this in Logic apps. It gives a message that the response is not in JSON format. Also, it gives me the number of likes rather than a list of people who have liked it.
This is what I put into the HTTP request
After our chat I tried this
and this
and got this error message.
"error": "invalid_request",
"error_description": "AADSTS900144: The request body must contain the following parameter: 'grant_type'.\r\nTrace ID: d41c78c7-afa5-405f-8f52-8b587ecf1a00\r\nCorrelation ID: 9ffd2247-78ca-4be2-8111-c17a95a830d6\r\nTimestamp: 2020-01-23 10:09:55Z",
"error_codes": [
900144
]
I also tried putting in my Azure directory id in place of tenant id. It failed with and without the directory id.
It seems there isn't an action in logic app Yammer connector which can get the list of users in a group who haven't read a message. And I checked all of the rest api in Yammer api document. Just find a rest api which can get the users in a group:
https://www.yammer.com/api/v1/users/in_group/:Group_Id.json
So I think neither yammer rest api nor logic app can not implement this requirement of get the list of users in a group who haven't read a message.
Update:
For your question about how to implement the workaround in logic app, as I don't have yammer app and account, so I can just provide some suggestions for your reference.
Since the yammer actions in logic app are very limited, so we can just use yammer Apis in logic according to HTTP action.
First we need to get access token from yammer, you can refer to this tutorial and refer to the C. App Authentication title in it. Put this post url in HTTP action in logic app and get the response body. Parse the response body and get the token property under the access_token property. Then we can use this token in the apis which we will call in the next HTTP actions.
Then, call this api in HTTP action(choose "Get" as the method) with the token which we got above to get the users who like the message, the url should be like this:
https://www.yammer.com/api/v1/users/liked_message/:Message_id.json?access_token=<<ACCESSTOKEN>>
Get the response body(and parse it in json type in array) from the api above and then call the other api in HTTP action(with access token) to get the users in one group. Also get the response body from it and parse it in json type and store in array.
After that, use two nested "For each" actions in logic app to loop the two array and compare them. Then we can get the result which you want.
Update 2:
I am using azure logic app which consumes a web API via a connector and based on some condition, I want to send some data to a controller of my web application.
any ideas how this can be done ?
You can use an HTTP action in your Logic App to send data to a specific endpoint:
As you can see you're also able to add dynamic content to the body you would like to send.
For more information, check Get started with the HTTP action.
I would say don't over think this too much. It's a pretty basic process.
Get the response form your API.
Extract the values you need to test for the condition
Test the values in a Condition Action
Call the end points based on each Condition.
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..