Blob identifiers must be in the format 'container/blob'. #webjobs rocks.

... Or binding to a blob that your web job method wants to generate.

As we've learned with WebJobs, the payload processed by our QueueTriggers work in tandem with our other bindings. Now, what if we want to bind to a blob that doesn't yet exist and that the requester couldn't possibly know about? As it turns out, we can add custom data to our payload object and use that data in our binding:

        public class JobDescription

        {

            public string BlobPath { get; set; }

            public string ProjectId { get; set; }

            public string Method { get; set; }

            public string GeneratedBlobId { get; set; } = Guid.NewGuid().ToString("n");

        }

The GeneratedBlobId above, is nothing that we expect the client to send in, but instead generate as the binding engine instantiate our JobDescription object to perform its magic (as a matter fact, I tend to declare my WebJob input classes as a part of the static class performing the job, only sharing a JSON schema with my consumers). We can then use this GeneratedBlobId field in our blob binding:

        public static async Task OnParsePdfDocument(

            [QueueTrigger("parse-pdf-file-using-guess")] JobDescription jobDescription,

            [Blob("{ProjectId}/{BlobPath}")] CloudBlockBlob pdfDocument,

            [Blob("{ProjectId}/{GeneratedBlobId}.json")] CloudBlockBlob jsonResults,

            [Table("projects")] CloudTable projects)

This made me happy and felt like something worth sharing. WebJobs rock!