I’ve read through the Help section a few times to try to get a better understanding, but I’m still confused about the differences between Properties and Runtime Parameters. Sometimes it helps to get other people’s understanding. What is the difference? How are you using them?
While we are at it, are there any examples of how to actually use a RunTime parameter in a template? And why does the runtime parameter have to be defined in both the data map and the template? I’m thoroughly confused.
A runtime parameter can be used directly in a template by setting it in the template Parameters pane and then injecting it via the Create Print Content or Create Web Content plugin. To use within the template’s programming, you could call it using: merge.template.parameters
I think of properties as more like local variables for that DataMapper or Template.
I very often need my templates and my DM configs to receive information from Workflow. In the past, I passed that information through JobInfos or through Workflow variables that I then had to define in my DM config.
The problem was remembering which DM config/Template needs what information. While desigining my Workflow process, I would often ask myself: “Does my DM config expect that info in JobInfo 7 or 8?”. I would then have to open my config or my template and look it up.
Runtime parameters achieve the exact same thing, except they are explicitly displayed in Workflow, allowing you to set the proper values that the template or the DM Config expects. Let’s say, for instance, Workflow needs to pass the name and path of a dynamic image to the template. Well in that template I create a Runtime Parameter named Dynamic_Image_Path. In my Workflow process, when I select that template for content creation, I immediately see that the Dynamic_Image_Path value is expected and I can set it to whatever value makes sense for the process.
Note that the runtime parameters are specific to each operation: you may pass a set of runtime parameters to your DM Config, and you may pass a completely different set to your template.
Having explicit values like the runtime parameters also makes working in collaboration easier. The person who designs the template can create a set of expected parameters. The person who designs the workflow config will then know what values the template expects (provided the runtime parameters use descriptive names, obviously) instead of having to ask the designer in which JobInfos the values should be stored.
In and of themselves, Runtime Parameters do not introduce new functionality. But they make the passing of information between Workflow and Connect much more explicit and user-friendly.
Thanks. I tried dragging/dropping a Runtime Parameter onto the template and nothing happened. I did get the value to display by dragging a field from the data model, and then editing the resulting script. I replaced the “record.fields” with the “merge.template.parameters.MyParam” and that worked. Why can’t Runtime Parameters be used directly, same as with fields from the data model? Is that an upcoming improvement?
Phil,
If I have a RP in the data map, which I use to calculate the values of a Field… and in Workflow, I set that value via Metadata, how does that work? It seems circular or a chicken/egg paradox.
For example, if I want the “record count”, which I can get from the Metdata, and pass that in as a RP, and in the Data Map, set a Field to “BigRun” or “SmallRun” based on the value of that RP, would that work? Because it seems that I don’t have metadata until I map all the fields, but if one of those fields is based on a value from an RP that is set via metadata… my head hurts.
I have already did an improvement request to allow drag and drop for Runtime Parameters.
You’re right, it’s a chick&egg issue: you can’t pass a RP to a process if it’s that very process that gives you the value for that RP. That’s why I mentioned earlier that the RP is not a new feature, it’s simply a more convenient way of passing the same information you could before.
Although you could set your field to BigRun or SmallRun after the DM into the ContentCreation while checking the Update Records from Metadata