While I do think this feature can be helpful, I find this article a bit confusing in terms of how I would use the feature. There seems to be an assumption of the payload format for each trigger. For example, what is special about the HTTP POST body being {“input”: “test”}? Is that payload specific (an example) to an Azure Storage queue trigger? If I try a payload of {“cats”: “dogs”}, I do receive a 202 Accepted response, but the function execution fails, with a message of “Unable to convert trigger to IStorageQueueMessage.” Therefore, the {“input”: “VALUE-GOES-HERE”} format does appear to be special (as in text for the VALUE-GOES-HERE is the content of the queue message).
Is there documentation available for the payload for other triggers (e.g. Blob storage, Event Grid, Service Bus, etc.)? It would be helpful to reference that documentation from this article.
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@mcollier
Thanks for your feedback! We will investigate and update as appropriate.
@mcollier I think what you have observed is correct. I was not able to find it documented anywhere but I took a dive into the code and was able to find it. 😄
Here is the method triggered by the Admin API mentioned in the doc which is extracting the input value from the payload.
The FunctionInvocation class is just a simple class with one attribute named Input.
Based on the doc, a simple string is passed as the argument to the function as is. I tried a function expecting a JSON object.
The function had this code
public class QMsg
{
public string name;
}
[FunctionName("QTrigger")]
public static void Run(
[QueueTrigger("myqueue-items")] QMsg myQueueItem,
IBinder binder,
ILogger log)
{
log.LogInformation($"QueueTrigger processed: {myQueueItem.name}");
}
and I ran a request like this
curl --request POST \
--url http://localhost:7071/admin/functions/QTrigger \
--header 'Content-Type: application/json' \
--data '{"input": "{\"name\": \"eLMV\"}"}'
and it worked!
Since FunctionInvocation.Input is a string, I guess this probably won't work with Triggers expecting complex object types without String constructors.
Thanks for the additional info, @PramodValavala-MSFT. I think it would be helpful if the doc could be updated to explicitly state which Triggers can be used with this manual invocation approach, and a few examples as well.
@mcollier I agree. I have assigned this issue to the content author to review and update accordingly.
Thanks, @mcollier and @PramodValavala-MSFT! I will circle back with the Product Team and update the doc accordingly.
Thanks, again @mcollier for creating this issue.
Tracking for this update is in our internal backlog, but for now I need to close this issue. Due to the volume of issues in our queue, our policy is to close issues that have been inactive for the last 90 days.
I will still update this thread once the doc is updated.
Thanks again!
Since
FunctionInvocation.Inputis a string, I guess this probably won't work with Triggers expecting complex object types withoutStringconstructors.
I was able to specify JSON as the input value and it was smart enough to deserialize it into the message payload class we specified with a ServiceBusTrigger
Hi @craigshoemaker This doc doesn't seem to have been updated with the information originally asked for (and that I'm now lookign for as well) I was wondering whether it's perhaps in a different place? cc @PramodValavala-MSFT
@craigshoemaker Has this information been added anywhere besides this thread? Do we need to open up another issue for this?
Most helpful comment
@mcollier I think what you have observed is correct. I was not able to find it documented anywhere but I took a dive into the code and was able to find it. 😄
Here is the method triggered by the Admin API mentioned in the doc which is extracting the
inputvalue from the payload.The FunctionInvocation class is just a simple class with one attribute named Input.
Based on the doc, a simple string is passed as the argument to the function as is. I tried a function expecting a JSON object.
The function had this code
and I ran a request like this
and it worked!
Since
FunctionInvocation.Inputis a string, I guess this probably won't work with Triggers expecting complex object types withoutStringconstructors.