Identifying the artifacts that make up an application

The AppConfig.xml file

The AppConfig.xml file describes each of the application's provisioning information and is stored in the EAC Central Server. The Deployment Template control scripts use AppConfig.xml as the authoritative source for application definition. The Deployment Template stores a copy of the AppConfig.xml file in the [appdir]/config/script directory.

Although you can modify an application configuration with the Workbench, we recommend that modifications only be made in the AppConfig.xml file. That way, the application configuration will be saved on disk, ready for sharing between environments. You can use the Workbench for other tasks that do not involve modifying the configuration, such as reviewing the configuration, and starting or stopping individual components.

The instance configuration

The instance configuration is a set of files that control the ITL process and the data loaded into the MDEX Engine servers. The instance configuration files are controlled by the Developer Studio, and optionally by the Workbench.

These files include configuration data such as dimension definition, search configuration, the Forge pipeline, and Page Builder landing pages.

Page Builder templates

Page Builder templates are used to drive dynamic landing pages that can be created in Page Builder. They are defined by xml files stored by the Workbench, and accessed through the emgr_update command utility.

Command-line scripts

An application deployment typically includes command-line scripts that perform common operations related to the application's functionality. By convention, these scripts are stored in the Deployment Template's [appdir]/control directory.

The Deployment Template includes scripts such as baseline_update and set_baseline_data_ready_flag.

You can create additional scripts under the [appdir]/control directory. These scripts, together with their input data and output directories, are a part of the application definition. For example, a developer might create scripts to crawl web pages in preparation for a baseline update. These scripts might take as input a seed-list file, and create an output file in a custom directory under [appdir].

These command-line scripts, along with their input data and output directories, should be shared among the development, staging and production environments.

Library files

Many parts of an application use library files. For example, a Forge pipeline using a Java or Perl manipulator typically requires access to library files implementing those manipulators. BeanShell scripts may use application- or Endeca-specific Java classes. By convention, library files are kept under [appdir]/config/lib.

Forge state files

Forge state files reside in the [appdir]/data/state directory.

In most cases these files do not need to be included as part of an application definition. However, when an application uses dimension values from auto-generated or external dimensions, then Forge state files do need to be synchronized across the environments. In this situation, the state files contain the IDs of these dimension values and ensure that the same dimension value always gets the same ID no matter how many times Forge is run. These dimension values may be used in a variety of ways, including dynamic business rules, landing pages, dimension ordering, and precedence rules.

In other words, Forge state files should be identified as part of the application definition if the application uses auto-generated dimensions or external dimensions, and values from these dimensions are referenced anywhere in the application configuration (for example, in dynamic business rules, Page Builder landing pages, explicit dimension ordering, or in precedence rules).