This content has been marked as final. Show 5 replies
Yes, you can use entities - for example &instance_name; - in the pipeline.epx, then pass in the value for &instance_name; as a forge command line key/value, for example in your <forge /> element in the AppConfig.xml:1 person found this helpful
One caveat is that Developer Studio - on save - removes entities from the pipeline. To get around this, the usual in-field approach is to:
1) add the placeholder as a different format to an entity, e.g. @instance_name@
2) create a simple script that replaces any instance of @variable@ with &variable;
3) add the script to run in the BaselineUpdate script prior to the forge running
Note in the example above I've used instance_name as the variable here - I don't think you need to have different CAS ports, as (if I remember correctly) CAS will work as a single installation and you would have multiple crawling instances defined (one for each language, in your case). You might also need to parameterise the CLIENT_ID variable to be unique, too (if running different language baselines in parallel).
We are still getting some errors using your way, but it gave us another idea to work on. We decided to try to replace the values first inside the pipeline using a script before actually running the baseline for the specified language. We'll see how this goes.
It looks like there might be a limitation on what entities forge will replace using the -c param.
I was able to get this working using &default_path; which is one of the entities defined in Endeca_Root/conf/dtd/common.dtd.
I haven't tested it out, but you might be able to update the .dtd to include your new entity type, or use the -d param to point to your own custom .dtd.
From the ForgeGuide.pdf
Forge has a set of XML entity definitions whose values can be overridden at the command line, such as current_date, current_time, and end_of_line. You can specify a replacement string for the default entity values using the -c option, or in an .ini file specified with -i (described below).
The format is:
which would be specified on the command line with:
or included as a line in an .ini file specified with -i.
This allows you to assign pipeline values to Forge at the command line. In the above example, you would specify &end_of_line; in your pipeline file instead of hard-coding “\n”, then invoke Forge with the -c option shown above. Forge would substitute “\n” whenever it encountered &end_of_line;.
For a complete list of entities and their default values, see the ENTITY definitions in Endeca_Root/conf/dtd/common.dtd
Ah yes, forgot about that. The perl script that handles the replacement logic (you add the variables as @variable-name@ and it converts them to &variable-name; in the temporary pipeline.epx in ./data/processing just before the forge component runs, @variable-name@ avoids issues with Developer Studio save removing &variable-name; references) also adds any variable definitions to the DTD spec, so the top of the pipeline.epx gets rewritten to look like:
<!DOCTYPE PIPELINE SYSTEM "pipeline.dtd" [
<!ENTITY variable-name "">
This approach was put together by Matt Brandwein a few years back - he uploaded to Eden a perl script that can do this along with a simple guide on usage (it was primarily to get around having to include passwords for ODBC connections, if I remember rightly). Not sure if it has been migrated to the Oracle forums yet, would be worth a look if so.
That makes sense, thanks for clarifying that Michael. I'll give that try since its not really the cleanest approach to use the pre-defined entities for this.
Would've been great to have Matt's perl still - I think code snippets were pulled from all those EDeN threads before moving to OTN.