I have a Logic Apps instance with a variable AddedPoKey set out of parsed JSON
"Set_PO_Key_variable_": {
"inputs": {
"name": "AddedPoKey",
"value": "#{body('Parse_JSON')?['poKey']}"
},
"runAfter": {
"Parse_JSON": [
"Succeeded"
]
},
"type": "SetVariable"
},
I want to use the value to set the Id in a RESTful API collection resource. I have not been able to get it to work, though I am sure it should. I am possible not finding the best MS documentation on this and if any could be pointed out to me, I would appreciate it. I have tried:
"Set_Po_Lin_Add_url_": {
"inputs": {
"name": "CreatePoLineResourceUrl",
"value": "#{replace('https://api.plex.com/EDI/sales-orders/{PoKey}/lines','{PoKey}',triggerBody()['AddedPoKey'])}"
},
"runAfter": {
"Set_PO_Key_variable_": [
"Succeeded"
]
},
"type": "SetVariable"
}
Which results in InvalidTemplate. Unable to process template language expressions in action 'Set_Po_Lin_Add_url_' inputs at line '1' and column '2459': 'The template language expression 'replace('https://api.plex.com/EDI/sales-orders/{PoKey}/lines','{PoKey}',triggerBody()['AddedPoKey'])' cannot be evaluated because property 'AddedPoKey' doesn't exist, available properties are 'ContentData, ContentType, ContentTransferEncoding, Properties, MessageId, To, ReplyTo, ReplyToSessionId, Label, ScheduledEnqueueTimeUtc, SessionId, CorrelationId, SequenceNumber, LockToken, TimeToLive'. Please see https://aka.ms/logicexpressions for usage details.'.
and then
"#{replace('https://api.plex.com/EDI/sales-orders/{PoKey}/lines','{PoKey}',variables('AddedPoKey')}"
which works.
Note that https://aka.ms/logicexpressions had been my main references, but does not even have the word "variable" on the page at this time.
Related
I have LogicApp which get HTTP Post from Azure Alerts.
I would like to create "DimensionNames" string variable, which includes all names in array.
DimensionNames value could be "name1,name2, name3, name4".
Finally I would use DimenstionNames string in "call Webhook".
How do it?
Request Body Json in "When a HTTP request is received"
{
"dimensions": {
"items": {
"properties": {
"name": {
"type": "string"
},
"value": {
"type": "string"
}
},
"required": [
"name",
"value"
],
"type": "object"
},
"type": "array"
}
}
Using variables and Join action you can convert array to a string variable. I have reproduced from my side and below are steps I followed,
Created an alert and configured a HTTP trigger logic app to it.
Designer of logic app will be,
The payload of http request is,
{
"dimensions": {
"items": {
"properties": {
"name": {
"type": "string"
},
"value": {
"type": "string"
}
},
"required": [
"name",
"value"
],
"type": "object"
},
"type": "array"
}
}
4. Next taken Initialize variable action as shown below,
Taken Join action to divide values from array with comma,
Next taken another initialize variable action to store value as a string,
In webhook action the value of string variable is used as body,
Outputs are shown below,
Http trigger:
Output of initialize variable,
Output if Join,
Output of initialize variable 2,
Reference link
For a few weeks now, there is a new "Parameter" section in the Designer of Logic Apps. We can create parameters and use these parameters in the Logic Apps:
Unfortunately, there are two things that are missing (or not working yet):
We are not able to set the "current value" of a parameter (as shown below, the field Actual Value is grayed)
When we export the Logic App as an ARM template, parameters are not used in the ARM template as ARM parameters.
Am I missing something or is it just due to the fact that there are features not yet deployed?
I'm not either sure how default/actual values should work in the Logic App designer but for the export of the ARM template with the (designer) parameters I'm using the last build of LogicAppTemplateCreator and it works for me.
The template snippet contains "paramDateFrom" parameter with its default value and it is used in the parameters section of ARM:
...
"paramDateFrom": {
"type": "string",
"defaultValue": "2019-12-19"
}
},
"variables": {},
"resources": [
{
"type": "Microsoft.Logic/workflows",
"apiVersion": "2016-06-01",
"name": "[parameters('logicAppName')]",
"location": "[parameters('logicAppLocation')]",
"dependsOn": [],
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"DateFrom": {
"defaultValue": "[parameters('paramDateFrom')]",
"type": "String"
}
},
...
The template parameters file contains the actual value:
...
"parameters": {
"paramDateFrom": {
"value": "2019-12-20"
}
I need to send null under a certain if case to a CRM Endpoint.
Since I need the value on multiple parts of the Logic App I would like to use a variable.
This code only set the variable to "" but not to null.
I need the null in the case when the IC_CODE is not '05'.
"Set_variable_conditional_interchangability": {
"type": "SetVariable",
"inputs": {
"name": "conditional_interchangability",
"value": "#{if(equals(items('For_each')?['IC_CODE'], '05'), 928350000, null)}"
},
"runAfter": {
"Set_variable_direction": [
"Succeeded"
]
}
}
Because you are using curly braces {} in the value, the runtime is converting the null value to an empty string.
Try this:
"Set_variable_conditional_interchangability": {
"type": "SetVariable",
"inputs": {
"name": "conditional_interchangability",
"value": "#if(equals(items('For_each')?['IC_CODE'], '05'), 928350000, null)"
},
"runAfter": {
"Set_variable_direction": [
"Succeeded"
]
}
}
HTH
I'm trying to get into JSON schema definitions and wanted to find out, how to achieve a deeper object uniqueness in the schema definition. Please look at the following example definition, in this case a simple IO of a module.
{
"$schema": "http://json-schema.org/draft-06/schema#",
"type": "object",
"required": ["modulIOs"],
"properties": {
"modulIOs": {
"type": "array",
"uniqueItems": true,
"items": {
"allOf": [
{
"type": "object",
"required": ["ioPosition","ioType","ioFunction"],
"additionalProperties": false,
"properties": {
"ioPosition": {
"type": "integer"
},
"ioType": {
"type":"string",
"enum": ["in","out"]
},
"ioFunction": {
"type":"string"
}
}
}
]
}
}
}
}
When I validate the following with i.E. draft-06 I get a positive validation.
{"modulIOs":
[
{
"ioPosition":1,
"ioType":"in",
"ioFunction":"240 V AC in"
},
{
"ioPosition":1,
"ioType":"in",
"ioFunction":"24 V DC in"
}
]
}
I'm aware that the validation is successfull because the validator does what he's intended to - it checks the structure of a JSON-object, but is there a possibility to validate object value data in deeper objects or do i need to perform the check elsewhere?
This is not currently possible with JSON Schema (at draft-7).
There is an issue raised on the official spec repo github for this: https://github.com/json-schema-org/json-schema-spec/issues/538
If you (or anyone reading this) really wants this, please thumbsup the first issue comment.
It's currently unlikely to make it into the next draft, and even if it did, time to impleemntations picking it up may be slow.
You'll need to do this validation after your JSON Schema validation process.
You can validate data value of your object fields by using JSON schema validation.
For example, if you need to check if ioPosition is between 0 and 100 you can use:
"ioPosition": {
"type": "integer",
"minimum": 0,
"maximum": 100
}
If you need to validate ioFunction field you can use regualr expression such as:
"ioFunction": {
"type": "string",
"pattern": "^[0-9]+ V [A,D]C"
}
Take a look at json-schema-validation.
I'm writing a simple JSON schema and using minItems to validate the number of items in a given array. My schema is as follows:
{
"title": "My Schema",
"type": "object",
"properties": {
"root": {
"type": "array",
"properties": {
"id": {
"type": "string"
},
"myarray": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 4,
"uniqueItems": true
},
"boolean": {
"type": "boolean"
}
},
"required": ["id","myarray","boolean"]
}
},
"required": [
"root"
],
"additionalProperties": false
}
Now I would expect the following JSON to fail validation given the element myarray has nothing in it. But when using this online validator, it passes. Have I done something wrong or is the schema validator I'm using faulty?
{
"root":[
{
"id":"1234567890",
"myarray":[],
"boolean":true
}
]
}
I am not sure why or what it is called, but the correct schema definition for your requirement should be as shown further down.
From what I understand from the JSON Schema definitions, you should declare the properties of an array inside the items declaration. In your schema you where defining properties outside of the array item declaration.
In your schema you have the two different types of array declaration:
Once with just a single object (a string for the "myarray" object)
Once with a complex object (the object name "myComplexType" in the code below)
Have a look at the definitions of both, how they are structured and how they would be interpreted.
The corrected schema:
{
"title": "My Schema",
"type": "object",
"properties": {
"root": {
"type": "array",
"items": { <-- Difference here - "items" instead of "properties"
"type": "object", <-- here - define the array items as a complex object
"title": "myComplexType", <-- here - named for easier referencing
"properties": { <-- and here - now we can define the actual properties of the object
"id": {
"type": "string"
},
"myarray": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 4,
"uniqueItems": true
},
"boolean": {
"type": "boolean"
}
}
},
"required": [
"id",
"myarray",
"boolean"
]
}
},
"required": [
"root"
],
"additionalProperties": false
}
Remove the comments I added with <-- when copying over to your code, added for pointing where there changes are.
As a note, I do however don't understand why the validator didn't give an error for the 'malformed' schema, but might just be that it saw the definition as you had it as additional properties, not entirely sure.
The only thing wrong with your schema is that the root property should have type object instead of array. Because the properties keyword is not defined for arrays, it is ignored. Therefore, the part of the schema you were trying to test was completely ignored even though it was correct.
Here is the relevant passage from the specification
Some validation keywords only apply to one or more primitive types. When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.
http://json-schema.org/latest/json-schema-validation.html#rfc.section.4.1