7

Using an output binding with Azure function to a Storage Blob, I can specify for the Storage Blob output the path. The path is either hard-coded or a special "template" can be used. Example: {rand-guid}. Is there a way to provide a custom template to specify value during Function execution? For example, use the trigger queue message ID as the blob name. Or set extension of the blob based on the logic in the function. Was looking for the documentation on this topic, but there's not much that would help on the topic.

Update 2016-10-05 Have created a detailed post to show how it works.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Hey Sean, do you know if it is possible with the webjob sdk ? – Thomas Oct 02 '16 at 08:07
  • Thomas, I'm not sure about that. There's a binding to use a property for a name that is deducted from the content of an incoming content, but something I could set in the function itself. Or at least I can't find that. – Sean Feldman Oct 02 '16 at 15:50
  • Ok, I an asking because Functions are built on top of the webjob sdk so if it is not possible with the sdk, it will not be possible with functions – Thomas Oct 02 '16 at 21:57
  • Looks like it's possible, but doco is falling behind... – Sean Feldman Oct 03 '16 at 00:00

1 Answers1

5

For the declarative template based naming many of the supported binding expressions vary per trigger type. E.g. for a queue trigger, you can actually already use {Id} which will bind to the message Id. Some of these built in binding parameters are listed on the Bindings Quick Reference but that document is somewhat out of date.

{rand-guid} is a recent extension we added and applies to all bindings. Note that we're looking to expand the set of built ins like this and have an open issue here for that. Please chime in on that issue with any scenarios you have.

All of the above is for declarative specifications. In C# you there is an advanced way for you to do this imperatively in your function as well using IBinder. See this post for an example showing this. Eventually we'll expose that dynamic binding capability to Node as well, but it's not there yet. We're tracking that in this issue.

Community
  • 1
  • 1
mathewc
  • 13,312
  • 2
  • 45
  • 53
  • 1
    the link to Bindings Quick Reference is not working :( Datetime open issue is good, but doesn't fulfill my requirement. I've raised an issue here: https://github.com/Azure/azure-webjobs-sdk-script/issues/736 What is really frustrating, is that documentation is outdated and lagging behind substantially. Samples talk about `out` keyword that is a no go for `async` variants. Code that is "reused" from webjobs needs to be manually crafted in the portal which is relatively much more time consuming due to no intellisense and tooling. The recent change to UI also makes debugging so clumsy. – Sean Feldman Oct 02 '16 at 16:28
  • 3
    Quick reference (2014) MSFT link is dead. Alternative location is here https://jhaleyfiles2016.blob.core.windows.net/public/Azure%20WebJobs%20SDK%20Cheat%20Sheet%202014.pdf Important to remember: technology w/o proper documentation is going to lead to a lesser adoption. – Sean Feldman Oct 02 '16 at 16:37
  • when using IBinder, should an output binding be used? When a blob binding is used, it requires a Path parameter. Unless IBinder will overwrite Path parameter, those appear to be conflicting. – Sean Feldman Oct 02 '16 at 16:50
  • In `IBinder` scenarios the binding is completely dynamic, driven by imperative code in your function. You should not include a corresponding binding in function.json for the `IBinder` parameter. I've notified our doc team about the dead link to the PDF - we'll fix that. We also need to catch up on documentation for advanced scenarios like `IBinder` in general, agreed. – mathewc Oct 03 '16 at 04:10
  • tried the sample and used using (var writer = binder.Bind(new BlobAttribute($"audits/{id}.json"))) { writer.Write(myQueueItem); }. While message from the queue is processed, no output is generated. – Sean Feldman Oct 04 '16 at 07:00
  • I suspect that the issue is that you're using {id} in the path. In C# functions, you can only use binding parameters if you're binding to a POCO object. Then, the object properties are available for binding. I just wrote up a detailed post on this. See [here](https://stackoverflow.com/questions/39855409/how-do-i-use-ibinder-to-perform-dynamic-bindings-in-my-c-sharp-function) – mathewc Oct 04 '16 at 14:57
  • That might be an issue... messages I get contain BOM chars. So binding would fail. Also, {id} is not coming from the content, but is a property of the incoming message that is bound (i.e. I can log it's value and see it). – Sean Feldman Oct 04 '16 at 17:48