I'm working with an Azure LogicApp where the workflow have fixed values. Our DevOps tool is VSTS (Visual Studio Team Services) and because we have multiple environments to handle, I have to do some refactoring (using parametrized values) so in VSTS we'll be able to provide environment-specific values.
Thanks to 2 websites I found on Internet I managed to understand that there are 3 kind of parameters :
To understand my problem, here's my action :
I want to have my string "/work/documents" in a parameter value. So in the "Code view" I managed to use a parameter instead of a hard-coded value :
"triggers": {
"When_a_file_is_added_or_modified": {
"type": "ApiConnection",
"inputs": {
"host": {
"connection": {
"name": "#parameters('$connections')['sftp_1']['connectionId']"
}
},
"method": "get",
"path": "/datasets/default/triggers/onupdatedfile",
"queries": {
"folderId": "#{parameters('pathToRootFolder')}"
}
},
"recurrence": {
"frequency": "Hour",
"interval": 1
}
}
}
And in my parameters.json :
"sftp_1_path_root_folder": {
"value": "/work/documents"
}
Here's the final result in Visual Studio:
Am I missing something ? Why isn't the value displayed in the Designer ? Thank you for your help in advance !
When you are using Logic Apps parameters inside your Logic App definition, they are not resolved at design-time, but at run-time. Thus, you are not supposed to see them in the designer. If you run the workflow, you should be able to see the actual value at run-time.
If you want to resolve those parameters at deployment-time, then you would need to write directly from the ARM template using ARM parameters into the workflow definition. This is possible, but in some cases, it can become a bit more complex. That's why I prefer to make use of Logic Apps parameters as described here.
Related
I'm trying to use a Logic App to convert a PDF File into an Image (JPG). I did every configuration with this article showed but it's not working. When I send it to API, that returns this error:
Not sure whether this is a fix. I have raised a thread in the Adobe Forum as well
I switched the logic app to code view
I moved the below piece of code
{
"body": "JPEG",
"headers": {
"Content-Disposition": "form-data; name=\"targetFormat\""
}
},
Above :
{
"body": "this ith",
"headers": {
"Content-Disposition": "form-data; name=\"InputFile0\""
}
},
Final Version :
Save it, Don't switch it to designer view. Run the Flow. You will be able to run the flow without the above error.
I'm experimenting with a Conversation where I would like to modify the output in a couple of different ways:
different output for speech or text
different output depending on the tone of the conversation
It looks like I can add extra output details which make it through to the client ok. For example, adding speech alongside text...
{
"output": {
"speech": {
"Hi. Please see my website for details."
},
"link": "http://www.example.com",
"text": {
"Hi. Please see http://www.example.com for details."
}
}
}
For the tone, I wondered about making up a custom selection policy, unfortunately it seems to treat it the same as a random selection policy. For example...
{
"output": {
"text": {
"values": [
"Hello. Please see http://www.example.com for more details.",
"Hi. Please see http://www.example.com for details."
]
},
"append": false,
"selection_policy": "tone"
}
}
I could just add a separate tone-sensitive object to output though so that's not a big problem.
Would there be any issues adding things to output in this way?
You can definitely use the output field to specify custom variables you want your client app to see with the benefit that these variables will not persist across multiple dialog rounds (which they would if you would add them to the context field).
Now currently there is no "easy" way how to define your custom selection policy (apart from the random and sequential supported by the runtime right now) - but you could still return an array of possible answers to the client app with some attribute telling the client app which selection policy to use and you would implement this policy in the client app.
I'm creating an ARM template that deploys an Web App (an Mvc Api) and a Logic App.
I'm attempting to define an HTTP Action within the Logic App such that it dynamically concatenates the base Uri of the Api as well as a property of the current item using splitOn and #triggerBody(). The base Uri itself is concatenated from a set of parameters in the ARM template into a variable variables('hockeyAppAPISettings').Uri.
Here's the relevant snipped of the action definition:
"actionName": {
"conditions": [ ],
"inputs": {
"authentication": {
"audience": "[variables('apiSettings').Authentication.Audience]",
"clientId": "[variables('apiSettings').Authentication.ClientId]",
"secret": "[variables('apiSettings').Authentication.Secret]",
"tenant": "[variables('apiSettings').Authentication.Tenant]",
"type": "ActiveDirectoryOAuth"
},
"method": "patch",
"uri": "[concat(variables('apiSettings').Uri, '/#{triggerBody()['Id']}/ScanningInProgress')]"
//"uri": "[concat(variables('apiSettings').Uri, '//#{triggerBody()[/'Id/']}//ScanningInProgress')]"
//"uri": "[concat(variables('apiSettings').Uri, '//##{triggerBody()[/'Id/']}//ScanningInProgress')]"
},
"type": "Http"
},
The "uri" section is what i'm struggling with. I've sprinkled various escape characters (\ and #) in differing patterns through out this.
I either can't get the deployment to succeed w/deployment errors like:
Unable to parse template language expression
'concat(variables('apiSettings').Uri,
'//#{triggerBody()[/'Id/']}//ScanningInProgress')': expected token
'RightParenthesis' and actual 'Identifier'. Please see
http://aka.ms/arm-template-expressions for usage details..'.
Or if I get the deployment working and then look at the code in the portal after deployment, the string concatenation doesn't seem to work properly. The variable doesn't get converted to its value.
I have validated that if I edit the Uri directly (via the portal HTML editor) using this: "uri" : "https://edited.azurewebsites.net/api/Packages/#{triggerBody()['Id']}/ScanningInProgress" the Logic App will make a patch call for each item that comes from the HTTP trigger.
What am I doing wrong?
You need to escape the inner single quotes, i.e. try
"uri": "[concat(variables('apiSettings').Uri, '/#{triggerBody()[''Id'']}/ScanningInProgress')]"
Alternatively you can use the dot notation to reference the property, i.e.
"uri": "[concat(variables('apiSettings').Uri, '/#{triggerBody().Id}/ScanningInProgress')]"
For me changing this
"uri": "[concat(parameters('APIMUrl_param'), '/sales-management/differential-reference-codes/v1/?instance=', parameters('APIDRCInstance_param'), '&filter=differentialReferenceCode%20eq%27', variables('varDRC'), '%27')]",
to this has worked
"uri": "#concat(parameters('APIMUrl_param'), '/sales-management/differential-reference-codes/v1/?instance=', parameters('APIDRCInstance_param'), '&filter=differentialReferenceCode%20eq%27', variables('varDRC'), '%27')",
I have a successful connection setup between a FTP site and dropbox using a azure logic app. But while setting it up it kept just downloading the file then, since I had the next step wrong, deleting.
In a test environment this is annoying. In production, pretty awful.
Here is the code I am using on the action part:
"operation": "UploadFile",
"parameters": {
"FilePath": "#{triggers().outputs.body.FilePath}",
"content": {
"Content": "#{triggers().outputs.body.Content}",
"ContentTransferEncoding": "None"
},
"overwrite": true
},
Is there anything I can do so that if it fails it leave the file on the server?
I'm not 100% sure what you mean, but I will give it a try. Maybe you can reformulate the question if I misinterpret you.
But yes, there exists "conditions" in Logic Apps which can be used. If you are new to Logic Apps I'd suggest you use "designer view" and you can then click "Add condition to be met". This would visualize a text box in which you can formulate conditions. For instance:
#equals({your data}, bool('true'))
To check if some value is true, or something similar to check if data is null.
I'm trying to get a grip on Ext.direct. On the official page there is this description of the API:
The purpose of the API component of the Ext Direct stack is to output the method configurations for Ext Direct to create client-side stubs. By generating these proxy methods, we can seamlessly call server-side methods as if they were client-side methods without worrying about the interactions between the client and server-side.
I just don't quite get what it means by ...to output the method configurations for Ext Direct to create client-side stubs. Would someone care to explain what this means at a grassroots level?
This will make more sense if you look at the output from the api.php resource included in the following example.
Note that this is being loaded on the page as a <script/> tag, ie:
<script type="text/javascript" src="php/api.php"></script>
When you open the src link you'll see the following JavaScript being generated by server-side PHP (see block of javascript code below).
In other words, PHP is doing the bit where it ... output(s) the method configurations for Ext Direct to create client-side (ie JavaScript) stubs.
Now the next question you should be asking if you want to make sense of this is: Why bother generating client side JavaScript using server side PHP (or other language of choice)?.
Ext.ns("Ext.app");
Ext.app.REMOTING_API={
"url": "php\/router.php",
"type": "remoting",
"actions": {
"TestAction": [{
"name": "doEcho",
"len": 1
}, {
"name": "multiply",
"len": 1
}, {
"name": "getTree",
"len": 1
}, {
"name": "getGrid",
"len": 1
}, {
"name": "showDetails",
"params": [
"firstName",
"lastName",
"age"
]
}],
"Profile": [{
"name": "getBasicInfo",
"len": 2
}, {
"name": "getPhoneInfo",
"len": 1
}, {
"name": "getLocationInfo",
"len": 1
}, {
"name": "updateBasicInfo",
"len": 0,
"formHandler": true
}]
}
};
This seems to be mimicking the way a WSDL works in that it can provide a service description and list all the options available for quering. In other words: Ext.Direct API is taking a concept from SOAP and applying it to a Javascript setting.
The back-end contains the API so this is the easiest place to generate a service definition with all the method names and signatures. Once the Ext.Direct API method stubs are provided (in the back-end), the front-end Ext.Direct library will do the plumbing and turn these into actual functionality that can be queried and used in JavaScript. Much in the same way as SOAP proxy classes can be automatically generated (in PHP/C# or Java) using the WSDL.
Personally I think this is a bit too airy-fairy for my liking. Most APIs are pretty straight forward and trying to implement something akin to WSDL actually makes consumption a lot harder than it would be if you just talk to it directly.