I have been playing around with Logic Apps during the last couple of weeks. Actually I have first real customer case that I would like to implement with Logic Apps as it seems to be rather perfect match for the product (syncing data between two REST APIs). My last encounter with Logic Apps is from the very early days when the product was initially published and it took quite a while to recover from that experience. It seems that lots has happened especially within the last six months or so and it seems to be perfect time to get more familiar with the current capabilities of Logic Apps.
I must say that I was really impressed what I was able to put together within the first couple of hours: connecting two well documented REST APIs seemed to be child’s play. It was only after I tried to implement more logic that I hit the wall of frustration. You could say that the painpoint of my issues was nested for-each loops. It simply is not yet possible, but the Logic Apps team replied to my tweet telling that the feature is just about to ship. Its not that long ago when you couldn’t add more than one action to for-each loop so the pace of development is rather impressive. What to do when you can’t have nested for-each loops? Child workflows.
You can’t nest for-each loops, but you can start child workflow from within your loop and pass an array of objects to be looped within the child process. There’s even a web UI for generating a json schema for the request so that you can easily pass the values from the parent to the child. There’s dozens of examples in the internet showing how you can implement this kind of parent-child interaction with very simple object structure. I still haven’t found a single example showing how you can pass an json array through and I might know why…
The purpose of this post is to tell other people with the same issue (or am I alone?) not to waste time banging your head to the wall as I did. Additional purpose is to tell the Logic Apps team what the source of my frustration has been so that they maybe can fix things in the future. Or improve the documentation if this is just me not knowing what to do.
Lets start with the simple version of my process. I have CaringParent workflow which wants to call InnocentChild workflow. The information model that I want to pass from the parent to the child is really simple:
{ "Family": { "Surname" : "Foo", "Size" : 5 } }
As I wrote, Logic Apps designer provides web-UI that generates json schema from a json example so getting started is made really efficient:
Nice and clean schema:
{ "type": "object", "properties": { "Family": { "type": "object", "properties": { "Surname": { "type": "string" }, "Size": { "type": "number" } } } } }
When you move to the parent side and open the Azure Logic Apps action and select your child, you see the Surname and Size properties as expected:
Easy and fast, let’s write a blog post telling how smooth this all is… But wait, what if there are multiple families? Let’s tweak our json model a bit:
{ "Family": [{ "Surname" : "Foo", "Size" : 5 }] }
You can see how the Family has changed from object to array in the schema:
{ "type": "object", "properties": { "Family": { "type": "array", "items": { "type": "object", "properties": { "Surname": { "type": "string" }, "Size": { "type": "number" } }, "required": [ "Surname", "Size" ] } } } }
When setting up the parent, you would expect to be able to pass an array of families to the child, right? In reality you can still only pass properties of one family and the only difference is that you can see that the properties belong to an object called Family. Where are the rest of my families?
Let’s imagine that the family has children:
{ "Family": [{ "Surname" : "Foo", "Size" : 5, "Children" : [ "Name" : "Bar", "Age" : 3 ] }] }
Everything works as expected on the child workflow side:
Also the schema that gets generated looks fine:
{ "type": "object", "properties": { "Family": { "type": "array", "items": { "type": "object", "properties": { "Surname": { "type": "string" }, "Size": { "type": "number" }, "Children": { "type": "array", "items": { "type": "object", "properties": { "Name": { "type": "string" }, "Age": { "type": "number" } }, "required": [ "Name", "Age" ] } } }, "required": [ "Surname", "Size", "Children" ] } } } }
And when you are just about to tweet about your heroic success, you’ll face this:
So on the parent side you still have possibility to pass Surname and Size as expected. Then you can pass Age and name of one Child. And then object called Children. And then something called Family.Children-key-item-output. What?
I tried to find a combination of parameters that would allow me to save the parent workflow with this schema, but I couldn’t find what kind of input was expected and what is the meaning of all these fields. After few hours of trying to find if there was something wrong with my schema or the workflows, I gave up. I was frustrated as I thought that it was not even possible to implement the logic that I needed and that I had to go back to the drawing board and find a way to implement my process without using Logic Apps.
The next day I was reborn and ready to try one more time. I had been so fixated to the examples that I had read about calling the child processes that I didn’t realize that defining the json-schema was optional. After removing the schema all together I was greeted with this kind of dialog on the parent side:
Just one field for the whole body that gets passed to the child as is. Now I was able to implement the process that I needed, but obviously lost some control from the parent-child communication. It also meant that I had to add some extra steps to the child as the input was just a generic json message. For me this means that I can proceed implementing my customer’s case with Logic Apps, but I also really hope that this issue gets fixed or documented better.
My name is Juha Ryhänen. I’m interested in everything related to productivity, remote work, automation and cool gadgets. This is my personal website where I write about the things I find interesting. Maybe you do too? [More]
Contact:
[email protected]