none
Using %% syntax in function.json RRS feed

  • Question

  • I have been using %% syntax in my function.json files in Azure Function Apps to replace values in the function.json with Application Settings.

    It works well for storage and binding endpoints.

    There were issues with schedule cron expressions which supposedly have been addressed. See:

    https://social.msdn.microsoft.com/Forums/en-US/81e07785-a4ea-4bf7-aa0f-44faa592b39d/storing-timer-trigger-cron-expression-in-application-settings?forum=AzureFunctions

    However, now I am having an issue with using %% syntax with the disabled attribute in function.json.

    In my Application Settings I have:

    "Disabled_GetTankReadings": "true"

    I tried doing this:

    "disabled": %Disabled_GetTankReadings%

    But I got an error in the Functions UI:

    Error: Unexpected character encountered while parsing value: %. Path 'disabled', line 2, position 14.

    When I try it as a string like this:

    "disabled": "%Disabled_GetTankReadings%",

    I don't get an error. And the Functions UI shows the Function as Disabled. But, the function still runs as if it is not Disabled.

    If I switch back to a hard-coded:

    "disabled": true,

    The function does not run, as expected.

    So:

    1. Can I use %% syntax for the disabled attribute and if so how?
    2. There is an inconsistency in the Functions UI that would show a function as Disabled but it still be running.
    3. And, while I am on the subject, the VS tooling for functions does not seem to be fully aware of the use of the %% syntax.

    Wednesday, March 1, 2017 8:14 AM

Answers

All replies

  • You can use an app setting name without the %%. Try that. The value of the app setting should be a "1" or "true".

    Mathew Charles [MSFT]

    Wednesday, March 1, 2017 8:16 PM
  • I did not get an error if did:

    "disabled": "Disabled_GetTankReadings",

    But it also did nothing. It always evaluated to true. So, it does not seem to work as you suggest.

    Also, the %% syntax does seem to be required in the bindings section. I tried removing the %% and I got errors. I would expect the replacement syntax to be the same throughout the file otherwise it is confusing.

    Seems like this area needs a little love.

    Thursday, March 2, 2017 6:44 AM
  • I just tried this myself in production. I have an app setting "IS_DISABLED" (name can be whatever you want). I have its value set to 1. In my function.json I have "disabled": "IS_DISABLED". The function is disabled as expected, and if you look in your host logs in Kudu under D:\home\LogFiles\Application\Functions\Host you'll see a log to the effect "Function 'XXX' is disabled". When I change the app setting value to 0, the function starts running.

    This isn't working for you?

    Regarding the %% syntax and when it is allowed/used. It is only allowed in expressions that allow string replacement anywhere in the string. E.g. binding expressions will allow you to have things like "ABC%Test%" where part of the string is a literal, and the rest comes from a setting. Other properties like this disabled property as well as the "connection" property found in many of the bindings do not support %% - they must be an app setting name. This was a conscious decision, not an oversight :)


    Mathew Charles [MSFT]


    Friday, March 3, 2017 1:21 AM
  • Sorry. Looking at the logs in Kudu it does appear that the Function is responding properly to the changes in my App Settings. My functions were timer triggers and only ran periodically so I didn't actually see if they ran or not. I was relying on the portal interface which is not properly reflecting the disabled/enabled state of the function even after a browser refresh and hitting the refresh button in the Functions App portal ui. I made several changes in the App Settings and while the logs showed the restart and change in disable state the UI did not.

    Friday, March 3, 2017 9:55 AM
  • Ah, yes - the portal is just simple UI expecting a boolean value. It is not dynamically reflecting an app setting value. I logged a portal bug here for that: https://github.com/projectkudu/AzureFunctionsPortal/issues/949 to see what we can do there. Thanks.

    Mathew Charles [MSFT]

    Friday, March 3, 2017 7:09 PM