Invoke Workflow Actions

A workflow can call another workflow using the Invoke Workflow action. The action configuration includes the name of the workflow to be called, which must exist in the same Logic App.

When unit testing a workflow that calls another workflow, the dependency needs to be removed. The testing framework does this by replacing the Invoke Workflow action with a HTTP action that is configured to call a mock HTTP server that is managed by the testing framework. This allows the action to run independently of other workflows.

Replacing the action like this does not affect the functionality of the action or change the behaviour. Every Invoke Workflow action generates an input JSON message which is then passed to the called workflow. The called workflow then generates an output JSON message which is then processed by the rest of the workflow. As long as the same message structures are used in the request and response for the HTTP connector and mock HTTP server, the rest of the workflow will execute in exactly the same way.

As an example, this is an Invoke Workflow action that calls a my-child-workflow workflow in the same Logic App, passing three headers and body content:

"Invoke_a_workflow": {
    "type": "Workflow",
    "inputs": {
        "host": {
            "workflow": {
                "id": "my-child-workflow"
            }
        },
        "headers": {
            "Content-Type": "@triggerOutputs()?['body']?['properties']?['contentType']",
            "DataSource": "@triggerOutputs()?['body']?['containerInfo']?['name']",
            "Priority": true
        },
        "body": "@triggerOutputs()?['body']?['content']"
    }
}

The testing framework will replace the action with a HTTP action that calls the mock HTTP server using a POST operation:

"Invoke_a_workflow": {
    "type": "Http",
    "inputs": {
        "method": "POST",
        "uri": "http://local-server-name:7075/Invoke_a_workflow",
        "body": {
            "host": {
                "workflow": {
                "id": "my-child-workflow"
                }
            },
            "headers": {
                "Content-Type": "@triggerOutputs()?['body']?['properties']?['contentType']",
                "DataSource": "@triggerOutputs()?['body']?['containerInfo']?['name']",
                "Priority": true
            },
            "body": "@triggerOutputs()?['body']?['content']"
        },
        "retryPolicy": {
            "type": "none"
        }
    },
    "operationOptions": "DisableAsyncPattern"
}

The contents of the inputs attribute in the original action configuration is included in the JSON request body that is sent to the mock HTTP server. This includes the name of the called workflow, any headers and the body content. The request is sent to the mock HTTP server using a URL that includes the action name. The test case can assert the contents of the request to ensure that the headers and body content match expectations.

The test execution log will include logging to show when an Invoke Workflow action has been replaced with a HTTP action:

Updating Workflow Invoke actions to replace call to child workflow with a HTTP action for the mock test server:
    Invoke_a_workflow:
      Mocked URL: http://local-server-name:7075/Invoke_a_workflow
    Invoke_another_workflow:
      Mocked URL: http://local-server-name:7075/Invoke_another_workflow

Example Requests and Responses

You can find examples of the requests that are generated by replacement HTTP actions here. There are also examples of responses that you can create in your test cases to simulate specific test scenarios, for example a successful workflow call or a failed workflow call.