Azure / azure-webjobs-sdk

Azure WebJobs SDK
MIT License
738 stars 358 forks source link

Guidance for implementing a binding with return value #659

Open mteper opened 8 years ago

mteper commented 8 years ago

I am working on a custom binding for the AWS Simple Workflow service, and having a hard time figuring out how to return a result of an activity from a function invocation. Any guidance would be much appreciated as it seems most classes and interfaces that would appear relevant to override currently have internal visibility.

mathewc commented 8 years ago

Yeah, the extensibility model for custom bindings is pretty new, and we've taken a conservative approach with public surface area. With the what we've opened so far, many new extensions have been possible (see the all the active work on new extensions in the last month here https://github.com/Azure/azure-webjobs-sdk-extensions). Our goal is to support any and all new extensions like yours in a way that makes your job as an extension author as easy as possible :) We realize that that will mean opening up more extensibility points to facilitate more complicated bindings like the one you're looking at.

Do you have are repo/fork that you're working in that illustrates the problems you're having?

mteper commented 8 years ago

@mathewc

I don't have the code in a public place, but here's fundamentally what I am trying to support:

An SWF client works by establishing a blocking long polling request to the server that either returns as soon as a new task is available for processing or in 60 seconds. The consumer interrogates the response, and if there is work to be done, performs it, otherwise loops back to a new request. So, unlike with the Azure Queue implementation, a backoff strategy probably doesn't make sense here and the client requests can be wrapped in a tight loop (at least that's what I have implemented so far). Once work for the given task is complete, the server has to be notified of success or failure explicitly. Optionally, a result can be supplied that will be made available to workflow tasks downstream.

That last bit is what I am struggling with. I see no way by which I can return a result to the trigger listener from my task execution. The only avenue that seems promising is to create a separate result attribute, distinct from the trigger, and tightly couple the trigger attribute binder to the result attribute binder at instantiation. Then, to somehow try and combine the interworkings of the two attributes that way. I haven't yet attempted it, so can't tell if that's the right path. Is that a direction that makes sense to you?

mteper commented 8 years ago

In the end, I settled on a static intermediary class where, on the trigger side (in the listener) I registered each new function invocation, and then on the result attribute binding side, I set the result. The intermediary class maintains a dictionary keyed on function invocation ID.

christopheranderson commented 8 years ago

Sorry for the delay on this since we've been pretty busy with the Azure Functions release. We hope to have some time to think about this and get back to you soon.

MikeStall commented 7 years ago

@mteper - we're in the middle of a bunch of extensibility work and I wanted to check back in on this. Is this still an issue?

What would the ideal user code look like for this? Here's what I infer so far:


void First([AwsTrigger(...) ...) {  
// do stuff 
} // succeeds. 
// Your AwsTrigger implementation calls back to AWS to notify complete, you get some result XYZ 
// now what happens with XYZ?? 
mteper commented 7 years ago

I've switched jobs and moved off this project, so don't have this well loaded up in my head (or access to the code). Here's a restatement of the problem that might help:

In other words, the part I had to jump through hoops to implement was connecting the trigger function output back to the triggered invocation.

Hope that helps.