Managing trigger parameter for an ADF pipeline

Question

Hi,

for a my pipeline I've created a storage event trigger with this int parameter: @int(replace(triggerBody().fileName,'.txt','')).
With this parameter, the publishing from the main branch fails because an int parameter is expected.

When I rewrite the trigger parameter as string one the publishing functions rightly: @replace(triggerBody().fileName,'.txt','')

With this parameter I can run the trigger succesfully.
So, can I not to use the @int() conversion function for a trigger parameter?

Which are the other functions that I cannot specify for a trigger parameter?

Thanks

Answer 1

The @int() function is designed to convert its argument to an integer. However, during the validation or publishing phase, ADF expects all parameters (including those derived from triggers) to be in a certain type that matches the expected type defined in the pipeline. If a parameter's type cannot be determined with certainty at the time of publishing (due to dynamic content conversion or transformation), it may lead to issues like the one you've encountered.

In your scenario, the conversion to an integer might be failing because the validation process does not execute the @int() function to evaluate its result as an integer. This could be because the publishing process requires static validation of parameter types, and the dynamic conversion provided by @int() doesn't satisfy this requirement.

The best practice in such cases is to maintain the parameter as a string if the dynamic content involves operations or functions that may not be evaluated as expected during the publishing phase. You can then convert the string to an integer within the pipeline itself, where dynamic content evaluation is fully supported. This approach provides more flexibility and avoids the publishing issues related to dynamic type conversion.

While ADF does not provide a specific list of functions to avoid in trigger parameters, the general rule is to be cautious with functions that dynamically change the data type of the parameter or rely heavily on the content that can only be evaluated at runtime. Functions that perform straightforward operations, such as string manipulations (for example @replace()), are usually safe. However, functions that involve type conversion (also I can mention @int(), @float()) or complex logic might not always be suitable for use in trigger parameters, especially if their result types are essential for the pipeline's configuration or validation phase.