Using Nested Azure Logic Apps … or Invoking Flows from another Logic App

Article
05/31/2015

Logic Apps has built-in functionality to allow organizing and splitting your workflows in small manageable units that can then be invoked from another workflow. At this moment that functionality is not exposed through the User Interface, but it is still possible to do that.

The high level steps to enable that is to:

Create the Child Logic App that will be invoked by the parent logic app and any logic to it.
Create an Access Key in the Child Logic App so that the Parent Logic App can use that as the user name and password to invoke it.
Create the Parent Logic App that uses an action of type “Workflow” and specify the Basic Credentials with the access keys created above.
That is all…

Now the biggest challenge right now is that the User Interface does not currently support managing Access Keys for flows as well as adding an Action for it, so we will be using the great ARMClient that David Ebbo built to do that easily through command line.

Create a Child Logic App

Here you can build any logic app the way you would like, in my case I called the Resource Group “logicNewRG”. The most important thing here is to Copy the full URL of the Endpoint since you will be using that to invoke this workflow from the Parent Logic App. You can do that in the Blade that shows the Endpoint, in my case since I deployed it to North Central US it looks something like: https://northcentralus.logic.azure.com/subscriptions/049c02d1-000-0000-0000-0000000/resourceGroups/logicNewRG/providers/Microsoft.Logic/workflows/ChildLogicApp

Create an Access Key for the Logic App

This is the most complicated part today since there is currently no support for the UI to manage the access keys, however it is simple enough to do that through command line.

Install ARM Client: Using Chocolatey it is very easy to install ARM Client, you can just run: choco install armclient

Once you do that you can run the following:

List the Subscriptions
armclient GET /subscriptions?api-version=2014-04-01
set SUB=/subscriptions/049c02d1....e734c

Create the Access Key sending a PUT and use a POST to list the generated keys
armclient PUT %SUB%/resourceGroups/logicNewRG/providers/Microsoft.Logic/workflows/ChildLogicApp/accessKeys/mykey?api-version=2015-02-01-preview "{}"

armclient POST %SUB%/resourceGroups/logicNewRG/providers/Microsoft.Logic/workflows/ChildLogicApp/accessKeys/mykey/list?api-version=2015-02-01-preview

And that will return the actual keys: (note that there are two so you can rollover your keys and have no downtime easily):

{
"primarySecretKey": "uzdaaa18wbccccccc….FpdQ",
"secondarySecretKey": "4Kpdddp7Rccc….DPyUVX6HeKw"
}

Create the Parent Logic App

To create the parent logic app you will need to edit manually the Code in the designer for the actual invocation of the Workflow by entering an action of type “Workflow”.

"actions": {
"flow": {
"type": "Workflow",
"inputs": {
"apiVersion": "2015-02-01-preview",
"method": "GET",

"uri": "https://northcentralus.logic.azure.com/subscriptions/049c02d1...734c/resourceGroups/logicNewRG/providers/Microsoft.Logic/workflows/ChildLogicApp",

"trigger": {
"Name": "Parentflow"

"outputs": {
"somedata": {
"type": "string",
"value": "@{guid()}"
}
}
},

"authentication": {
"Type": "Basic",
"UserName": "mykey",
"Password": "uzdEC...PfUFpdQ"
}
}
}
},

Passing data to the child logic app

Notice that in this case I’m also passing some data, like a generated GUID to the flow that then can be referenced in the child logic app with something like: @triggers().outputs.somedata.

Returning data back to the Parent Logic App

You can send data back to the parent workflow by using the Outputs in the child logic app, such as:

"outputs": {
"endTime": {
"type": "String",
"value": "Child Flow completed at: @{utcnow()}"
}
}

Partager via