Binary documents have a “header” with properties that can be referenced using dollar variables. When looking at the preview data for a binary view in Designer, you should be able to see what properties are available, if any. Unfortunately, most Formatter snaps don’t have a way to fill in the header document with properties, which limits the possibilties. It’s a gap that needs to be addressed.
They are effectively variable when used through PipeExec, as you described, and that is the correct approach at this time. The reason parameters cannot be set is because all of the snaps are running in parallel. So, it’s impossible to say what the value of a parameter is at any point is if they can be changed. For example, if you had a Mapper setting a pipeline parameter followed by a JSON-Formatter and a File-Writer, the Mapper could have processed one to hundreds of documents before the Writer read the value of the pipeline parameter. Now, imagine if the value computed for the parameter changed for every document that it processed, you would never get consistent results.
I should apologize and make some corrections after re-reading the above… My last comment probably didn’t make much sense because my use case was around the File Writer instead of the File Reader, so it didn’t fit this post. Nevertheless, now that I’ve accidentally hijacked the post and the conversation has continued… 🙂
@mikeandrews, I agree @Bhavin’s previous post should resolve your issue. What has not been included (if it’s not obvious) is that you can configure the File Reader snap with an input view so that the variables can be passed through.
Now, back to my unintentional hijack… @tstack,
Thank you very much for that explanation; that makes complete sense!
I’ve personally not run into any other use case other than the above mentioned, so if the Formatter snap can be extended in some way to pass along variable header info, then the issue is solved (and I can reduce a small number of secondary pipelines).
Thanks
- Del
