Each binding has an HTTP endpoint for local testing and debugging.
- https://localhost:7071/admin/functions/{FUNCNAME}
That's available for QueueTrigger, ServiceBusTrigger, TimerTrigger, EventHubTrigger at least.
Send a POST request with the expected data as JSON.
{ "input": "YOUR JSON SERIALIZED AND ESCAPED DATA" }
For triggers that need data put the data as serialized string into "input". See EventHubTrigger example further below.
TimerTrigger
For TimerTrigger use this:
{ "input": null }
EventGridTrigger
To execute this on some triggers it's bit tricky. Here it is for EventGridTrigger:
- https://localhost:7071/runtime/webhooks/EventGrid/functionName={FUNCNAME}
Send a POST request to execute. See here for details. The object must be an array.
EventHubTrigger
The EventHubTrigger receives data like the other triggers, as single JSON object. The structure follows the EventData
class, but the only required field is "SystemProperties". There seems no serializer specific settings, property names do not change case etc.
Post this as body;
{
"input": "{\"SystemProperties\":{},\"SomeId\":\"123\",\"Status\":\"Available\"}"
}
The event hub's body is the escaped and serialized value of "input".
Note that the same applies for the IoT Hub
Meta Data
For ALL triggers you can get meta data with a GET request. For an EventHubTrigger this could look like this:
{
"name": "StateChange",
"script_root_path_href": "http://localhost:7071/admin/vfs/StateChange/",
"script_href": "http://localhost:7071/admin/vfs/bin/MyApp.Notifications.Functions.dll",
"config_href": "http://localhost:7071/admin/vfs/StateChange/function.json",
"test_data_href": null,
"href": "http://localhost:7071/admin/functions/StateChange",
"invoke_url_template": null,
"language": "DotNetAssembly",
"config": {
"generatedBy": "Microsoft.NET.Sdk.Functions-3.0.11",
"configurationSource": "attributes",
"bindings": [
{
"type": "eventHubTrigger",
"consumerGroup": "regular",
"connection": "EventHub_Hub_Status",
"eventHubName": "%EventHub_Status%",
"name": "statusUpdateMessage"
}
],
"disabled": false,
"scriptFile": "../bin/MyApp.Notifications.Functions.dll",
"entryPoint": "MyApp.Notifications.Functions.StateChange.Run"
},
"files": null,
"test_data": null,
"isDisabled": false,
"isDirect": true,
"isProxy": false
}
And, of course you can use all the paths to retrieve the data, including the binaries. Very handy to write sophisticated integration tests.