azure-webjobs-sdk-extensions

Содержание

To understand how bindings work, it helps to understand at a high level the binding process both at startup, as well as at runtime.

on JobHost startup, in addition to registering it's own built-in binding providers (ITriggerBindingProvider/IBindingProvider), and will also register any extension binding providers it finds in the IExtensionRegistry.
the host reflects to find all job functions defined in referenced assemblies
For each job function and for each ParameterInfo of the function's parameters, the host will give all registered binding providers a chance to bind to the parameter (via the ITriggerBindingProvider/IBindingProvider interface). The provider to return a binding wins.
once all functions have been bound, the host creates internal representations for each job function, tying together the bindings, as well as all the details required to invoke the function at runtime
for any trigger bindings, the ITriggerBinding is called upon to return an IListenerFactory for the binding. The host then creates and starts all the listeners (e.g. for a QueueTrigger, the listener is now polling the queue for messages)
the host is now up and running, waiting for job function invocations

when a job function needs to be invoked (either because it was triggered by a trigger binding, or invoked manually), the runtime begins the bind process to bind all parameters before invoking the function
For each bound parameter of the function, the runtime calls the BindAsync method on the binding (ITriggerBinding.BindAsync/IBinding.BindAsync)
The binding performs any required conversions on the input value, to convert it to the correct type for the bound function
Finally, the runtime invokes the bound function with the final argument values. The function invocation is automaticallly wrapped by all the invocation management services the host provides (Dashboard logging, error handling, etc.).