Azure-docs: The example query for routing leaf messages is incorrect

[mill5james]

The example in the "Declare routes" to route messages from leaf devices is incorrect.

Incorrect
FROM /messages/* WHERE NOT IS_DEFINED($connectionModuleId) INTO $upstream

Correct
FROM /messages/* WHERE NOT IS_DEFINED({$ConnectionModuleId}) INTO $upstream

The instructions for using system properties states:

• System properties: $<propertyName> or {$<propertyName>}

but I have found the first format with the $ prefix does not work and the property must be enclosed with {} in addition to the $

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: ad3731a8-f0df-f1a1-d1a1-e89a769a0908
• Version Independent ID: 50a5190e-eafa-7dde-c18f-be9505b00a0a
• Content: Declare modules and routes with deployment manifests - Azure IoT Edge
• Content Source: articles/iot-edge/module-composition.md
• Service: iot-edge
• GitHub Login: @kgremban
• Microsoft Alias: kgremban

[shashishailaj]

@mill5james Thank you for pointing that out . We will have this reviewed and updated as required.

[asergaz]

Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

[kgremban]

@mill5james I'm surprised to see this issue because I have seen both versions working successfully. It's also not just relevant to this code sample, but would mean that something has changed in the IoT Hub message routing query language.

What method are you using to deploy? The Azure portal, Visual Studio/Visual Studio Code, CLI, etc? Perhaps some tool you're using needs the curly brackets in order to escape the $ character.

[mill5james]

we use a deployment.json from azure cli and VS Code

[kgremban]

Very strange. I don't think this means that system properties must always have curly brackets, but that there are some scenarios in which curly brackets are needed. I'll change the code sample to cover those corner cases, but will keep the system property syntax explanation as-is. Does that work for you?

[mill5james]

Sure. This just caused issues where we literally cut-and-pasted from the documentation into the deployment.json and it did not work. It took a second reading with some trial and error to get the routing working. But then again, my team is doing identity translation on the edge and there is no documentation for that anywhere. :)

[kgremban]

Yes, the product group is still working on the identity translation pattern. You can cast your vote on the feedback site to have this feature prioritized: https://feedback.azure.com/forums/907045-azure-iot-edge/suggestions/32497981-code-sample-for-identity-translation-pattern

For the query example, I will create the pull request now and automatically close this issue when the update gets merged. Thanks for providing your feedback.

[betsy-c]

Not to say there are never any edge cases where curly brackets are required, but I think the issue in this example is casing, rather than brackets.

Working:
FROM /messages/* WHERE NOT IS_DEFINED($ConnectionModuleId) INTO $upstream
Not working:
FROM /messages/* WHERE NOT IS_DEFINED($connectionModuleId) INTO $upstream

[kgremban]

Thanks for adding that info, @betsy-c. I'm also adding @varunpuranik for visibility and will hold off on updating the article until we all come to a consensus.

[kgremban]

@mill5james Did you have a chance to test whether the difference in your two code samples was the capitalization of the parameter, rather than the use of brackets?

[AshokPeddakotla-MSFT]

@mill5james Have you had a chance to see the above response? Please update if that helps.

[mill5james]

Feel free to close it. I have two people that swear it didn't work but now it does.
meh.