Service Bus Trigger Bindings IN empty

[EwertonJordao]

Hy everyone, my recent experience with Azure Functions I implement Sevice Bus Trigger and when using name parameter $mySbMsg for reading content from trigger this hashtable is empty, but when I use $TriggerMetadata all content is there. function.json

{
  "bindings": [
    {
      "name": "mySbMsg",
      "type": "serviceBusTrigger",
      "direction": "in",
      "topicName": "topic-sbpwsh",
      "subscriptionName": "mongo",
      "connection": "AzureServiceBus"
    }
  ]
}

settings.json

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "powershell",
    "FUNCTIONS_WORKER_RUNTIME_VERSION": "~7",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "AzureServiceBus": "",
    "MongoConnection": "",
    "MongoDatabase": "DBAcoes",
    "MongoCollection": "HistoricoAcoes"
  }
}

run.ps1

param($TriggerMetadata,[string] $mySbMsg)
$returnFromTopic=[PSCustomObject]@{
    Codigo = $TriggerMetadata.Codigo
    Valor = $TriggerMetadata.valor
    MessageID = $TriggerMetadata.MessageId
    data = $(get-date -Format "MM/dd/yyyy HH:mm:ss K")
}
$returnFromTopic2=[PSCustomObject]@{
    Codigo = $mySbMsg.Codigo
    Valor = $mySbMsg.valor
    MessageID = $mySbMsg.MessageId
    data = $(get-date -Format "MM/dd/yyyy HH:mm:ss K")
}
Write-Host $returnFromTopic 
Write-Host $returnFromTopic2 

[enoorden]

any update on this ? I'm seeing the same behaviour if the servicebus message is plain text it ends up in $mySbMsg if the message contains valid JSON it is deserialised and mixed with the other message properties!

test function :

param([string] $mySbMsg, $TriggerMetadata)

Write-Host "---mySbMsg---"
Write-Host $mySbMsg

Write-Host "---TriggerMetaData---"
$TriggerMetadata.keys | % { Write-Host "$_"}

Body : 'Plain Text Message 123!!'

Body : '{"property1":"value1", "property2":"value2"}'

[enoorden]

found a solution if you remove the default '[string]' cast from the $mySbMsg parameter you get a hashtable with just the properties in the json message

param($mySbMsg, $TriggerMetadata)

Write-Host "---mySbMsg---"
Write-Host ($mySbMsg | ConvertTo-Json -Compress)
Write-Host $mySbMsg.property1
Write-Host $mySbMsg.property2

Body : '{"property1":"value1", "property2":"value2"}'

guess the 'hidden serialization magic' comes into play here.. but this is workable https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads#payload-serialization

[EwertonJordao]

found a solution if you remove the default '[string]' cast from the $mySbMsg parameter you get a hashtable with just the properties in the json message

param($mySbMsg, $TriggerMetadata)

Write-Host "---mySbMsg---"
Write-Host ($mySbMsg | ConvertTo-Json -Compress)
Write-Host $mySbMsg.property1
Write-Host $mySbMsg.property2

Body : '{"property1":"value1", "property2":"value2"}'

guess the 'hidden serialization magic' comes into play here.. but this is workable https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads#payload-serialization

I think by design haved be the same implementation for $mySBMsg and $TriggerMetadata(include some informations about trigger when start to running, etc...), why input bingind it is a string? if you user httptrigger you get a json automatic transform in hashtable.

PowerShell users don't need looking for convert an string to JSON, You will acess the properties with $mySBMsg.something from IN binding maybe make changes and send to next step like cosmosDB or SQL Server.

Good workaround, but in this case I prefer to recive the data on $TriggerMetaData.

[LuckyLub]

@enoorden Thanks for sharing your solution! This is super confusing. Especially because the string that $mySbMsg produced was Systems.Collections.Hashtable