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:
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).
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.