Deployment Template and Endeca Workbench interaction

This topic summarizes information about Deployment Template and Endeca Workbench interaction.

If you use Endeca Workbench in your environment in addition to the Deployment Template, consider the following points that summarize their interaction:

Note: This topic provides a summary of interaction between these two components and lists recommendations for administrative practices. For detailed information on how to implement both Endeca Workbench and the Deployment Template in staging and production environments, see the Deployment Template Usage Guide.

Manage changes to the operational environment through the Deployment Template.
Endeca strongly recommends managing changes to your EAC component configuration, such as command line arguments to Forge, Dgidx and Dgraph, through the Deployment Template (once you choose to use it for your operational tasks), and not through EAC Admin Console in Endeca Workbench.
Manually upload changes to the instance configuration to Endeca Workbench.
If, after you have initially deployed your application, you make changes to the instance configuration files, such as add a new dimension, or define a new zone for dynamic business rules, and then run the Deployment Template scripts for baseline and partial updates, the Deployment Template does not automatically upload changed configuration files and settings to Endeca Workbench.

You can manually upload configuration updates to Workbench through a Deployment Template script, when needed. This may be necessary when changes to dynamic business rule zones and styles are updated, or dimensions are added or removed, and Workbench needs to be updated to allow business users to maintain rules based on the updated configuration.

Typically, it is useful to synchronize changes with Workbench before your Endeca implementation is deployed in the production environment, or during updates to your Endeca implementation. Use the update_web_studio_config.[sh|bat] script to deploy these pipeline changes through Workbench.

Calling update_web_studio_config.[sh|bat] requires all locks in Workbench to be available. This means all users must be logged out of the system and not holding any locks on resources. When you do run update_web_studio_config.[sh|bat], you are responsible for resolving any locking issues via the Workbench interface.
Manage some settings in Endeca Workbench.
In general, once you use the Deployment Template framework, its scripts become your designated environment through which you manage all changes to the EAC components and instance configuration files.

However, if you also use Workbench for managing rules, keyword redirects, search, dimension order, and reports, you can enable the Configuration Manager in the Deployment Template. The Configuration Manager informs the Deployment Template that for these changes, the Deployment Template should use Endeca Workbench, and not Developer Studio.

Note: The Deployment Template does not actually create, modify, or manage configuration files and operational settings; Developer Studio and Endeca Workbench perform these functions. However, when running its scripts, the Deployment Template needs to know which settings and files to use: from Developer Studio (this is the default assumption), or from Workbench. To decide whether changes that originated from Developer Studio or Workbench should be used, the Deployment Template uses its Configuration Manager. However, if you specify in the Configuration Manager the files as being maintained by Endeca Workbench, you ensure the Developer Studio version of these files is not used in scripts that run within the Deployment Template framework.

To summarize, if you prefer to maintain some changes through Endeca Workbench, enable the Configuration Manager component to ensure that these Workbench-maintained configuration files are used when running the scripts from the Deployment Template. For details on using this component, see the "Application Configuration" chapter of the Deployment Template Usage Guide.