Send messages outside of a handler

[adamjones-lhpt]

We have a few cases where we send a message at endpoint startup to do things like self register or self initialize a saga. I would like to be able to send a message when the FunctionEndpoint is created, but not in the context of the message being handled. Would it be possible to have FunctionEndpoint expose a getter for iMessage session?

[SeanFeldman]

@adamjones-lhpt, would this be used with scenarios that do not require a trigger message? For instance timer triggered functions? If yes, this request makes sense.

As a workaround, you could crate a send-only full NServiceBus endpoint stored as a static member field.

[adamjones-lhpt]

@SeanFeldman Precisely! We have a scheduler endpoint. Our other endpoints will send a request to this scheduler endpoint on startup to "self-register" for the period of the scheduled notification they are interested in. For instance, an endpoint might request to be sent an IEvaluateConditions message every 6 hours. In our current CloudService based deployment, the endpoint sends this request as part of endpoint startup. The scheduler endpoint will then send the requested command on the requested period.

In addition, we also have endpoints that use a saga in order to implement timed events. On endpoint startup, the endpoint performs a send-local of the ICreateSaga message with a well known saga ID. In this way, if the saga does not exist it is created, otherwise the request is ignored. As part of saga creation, the saga then performs a send-local of a IPerformScheduledWork message with a scheduled due time. As part of the handler for this message it sends the next scheduled message.

Our cloud services rarely restart, so these on-startup messages are fairly infrequent. With Functions I can see how we would have quite a bit more due to the dynamic scaling nature of the host. Even so, it is handy to have the option to send a message on endpoint startup for these types of self-initializing actions.

[seankearney]

Similar to @adamjones-lhpt - we require a timer triggered Azure Function that will be used to send a number of messages. This Az Function requires dependency injection (for various services and entity Framework things) and a static function will not work for us here.

[SeanFeldman]

@seankearney do you need IMessageSession specifically or do you need the IFunctionEndpoint to be able to perform the operations provided by IMessageSession, similar to what an IEndpointInstance provides (send/publish/subscribe/unsubscribe) minute the Stop method?

[seankearney]

@SeanFeldman - we just need to be able to leverage the API IMessageSession is offering. Having it on FunctionEndpoint is fine and would be consistent as we'd be injecting that everywhere in our Az Functions code.

[andrekiba]

@SeanFeldman my comment here is related to #110. I was wondering if there is a way to "start a conversation" starting from an http triggered function (a serverless api for example). I want to send a message, using azure service bus, that is then managed by an nservicebus endpoint (maybe hosted in a function).
If I understood correctly you said

You could have an HTTP or Timer triggered functions that spoofs a message and invokes FunctionEndpoint.Process()

that means create the message inside the function statement (with the info that come from the http payload) and then pass it to the Process method...but then I do not want to handle the message in the "same" function app.
And it is ok to start up an endpoint just to send a message?
I understand that it is something like a "send only" endpoint (and from the nservicebus point of view you have to know who starts the conversation)...but in this case I also have to pay for another endpoint to be able to send the message, correct?
Could the native integration be enough here (ok, I understand also that in this way maybe we are also "outside" of the nservicebus scope...)?

Otherwise I'm agree with @seankearney, having IMessageSession would be nice.

[SeanFeldman]

Let's sort out a few assumptions.

but then I do not want to handle the message in the "same" function app.

This means you need a physical (durable) message. How you generate that one doesn't matter. Native integration would work just fine. The source where it would be generated doesn't matter. Could be a webapp, another Function (native) or Function endpoint.

And it is ok to start up an endpoint just to send a message?

I'm not sure I understand this. You cannot start an endpoint w/o a trigger. Really depends on the scenario you're dealing with.

I'd suggest keeping this issue focused on the feature request and information associated with the requirement and move over the conversation about your specific scenario over to support. If it helps, point to this comment/thread to provide the context.