Workflow Triggers

Every workflow has a trigger that is used to start the execution of the workflow. There are many different types of trigger, for example the HTTP trigger which is used to start a workflow using a HTTP request, and a Service Bus trigger which is used to start a workflow when a message is available in a queue or topic.

A HTTP trigger does not have any dependencies on an external system, but other trigger types do. This includes Service Bus triggers, Event Hub triggers and Event Grid triggers. When unit testing a workflow with one of these trigger types, the dependency needs to be removed. The testing framework does this by replacing a non-HTTP trigger with a HTTP trigger. This allows each workflow to be started by the testing framework using a HTTP request.

Replacing the trigger like this does not affect the functionality of the workflow or change the behaviour. Every trigger creates a JSON message which is then processed by the actions in the workflow. The structure of the JSON message differs for each type of trigger, but as long as the message structure used in the request for the HTTP trigger matches the message structure created by the non-HTTP trigger, the rest of the workflow will execute in exactly the same way.

As an example, this is a Service Bus trigger that receives a message from a topic using a peek-lock:

"triggers": {
    "When_messages_are_available_in_a_topic_subscription_(peek-lock)": {
        "type": "ServiceProvider",
        "inputs": {
            "parameters": {
                "topicName": "topic-name",
                "subscriptionName": "subscription-name",
                "isSessionsEnabled": true
            },
            "serviceProviderConfiguration": {
                "connectionName": "service-bus-connection",
                "operationId": "peekLockTopicMessages",
                "serviceProviderId": "/serviceProviders/serviceBus"
            }
        }
    }
}

The testing framework will replace the Service bus trigger with a HTTP trigger that expects a JSON request using HTTP POST:

"triggers": {
    "When_messages_are_available_in_a_topic_subscription_(peek-lock)": {
        "type": "Request",
        "kind": "Http",
        "inputs": {
          "schema": {}
        }
    }
}

The structure of the HTTP trigger request used by a test case must match the JSON that would have been created by the original Service Bus trigger. This is an example of a request that matches the Service Bus trigger shown above:

{
    "contentData": {
        "id": 1234,
        "title": "Mr",
        "firstName": "Peter",
        "lastName": "Smith",
        "dateOfBirth": "1970-04-25"
    },
    "contentType": "application/json",
    "userProperties": {
        "operation": "update",
        "source": "hr",
        "type": "employee"
    },
    "messageId": "cdc0df50-4c73-4360-882a-af6400bf3aac",
    "label": "employee-1234",
    "scheduledEnqueueTimeUtc": "1/1/0001 12:00:00 AM",
    "sessionId": "1234",
    "timeToLive": "01:00:00",
    "deliveryCount": 1,
    "enqueuedSequenceNumber": 13961,
    "enqueuedTimeUtc": "2022-12-07T11:36:24.115Z",
    "lockedUntilUtc": "9999-12-31T23:59:59.9999999Z",
    "lockToken": "24da398b-3405-4acf-bc7c-d57ca2552d76",
    "sequenceNumber": 5850
}

The Service Bus message metadata is just attributes in the JSON message.

The test execution log will include logging to show when a non-HTTP trigger has been replaced with a HTTP trigger:

Replacing workflow trigger 'When_messages_are_available_in_a_topic_subscription_(peek-lock)' with a HTTP Request trigger.

Response Status Code

The testing framework does not add a Response action to the workflow definition. This means that the workflow being tested will return a synchronous HTTP 202 (Accepted) response to the test runner. The test case will see a HTTP 202 status code for the response to the TestRunner.TriggerWorkflow() method.