A customized document format is used to provide an intuitive configuration format for EAC script developers and system administrators.
However, this customization restricts the flexibility of the configuration document. The following sections describe elements available in the custom namespace defined by the eacToolkit.xsd XML schema. Each element name is followed by a brief description and an example configuration excerpt. For details, refer to the eacToolkit.xsd schema file distributed within the file eacHandlers.jar.
This section describes the application elements available in the custom namespace defined by the eacToolkit.xsd XML schema.
For more details, refer to the eacToolkit.xsd schema file distributed within the file eacHandlers.jar.
|
Element |
Description |
|---|---|
|
|
This element defines the global application settings inherited by all other objects in the document, including application name, EAC central server host and port, data file prefix, the lock manager used by the application and whether or not SSL is enabled. In addition, this object defines global defaults for the working directory and the logs directory, which can be inherited or overridden by objects in the document.
<app appName="myApp" eacHost="devhost.company.com" eacPort="8888"
dataPrefix="myApp" sslEnabled="false" lockManager="LockManager" >
<working-dir>C:\Endeca\apps\myApp</working-dir>
<log-dir>./logs/baseline</log-dir>
</app>
|
|
|
This element defines a LockManager object used by the application to interact with the EAC's synchronization web service. Lock managers can be configured to release locks when a failure is encountered, ensuring that the system returns to a "neutral" state if a script or component fails. Multiple lock managers can be defined.
<lock-manager id="LockManager" releaseLocksOnFailure="true" />
|
This section describes the host element available in the custom namespace defined by the eacToolkit.xsd XML schema.
The host element defines a host associated with the application, including the ID, hostname and EAC agent port of the host. Multiple host elements can be defined.
<host id="ITLHost" hostName="itlhost.company.com" port="8888" />
This section describes the component elements available in the
custom namespace defined by the
eacToolkit.xsd XML schema.
For more details, refer to the
eacToolkit.xsd schema file distributed within the
file
eacHandlers.jar.
|
Element |
Description |
|---|---|
|
|
This element defines a Forge component, including attributes
that define the functionality of the Forge process as well as custom properties
and directories used to configure the functionality of the Forge object's
methods. Multiple
<forge id="Forge" host-id="ITLHost">
<properties>
<property name="numStateBackups" value="10" />
<property name="numLogBackups" value="10" />
</properties>
<directories>
<directory name="incomingDataDir">./data/incoming</directory>
<directory name="configDir">./data/complete_config</directory>
<directory name="wsTempDir">./data/web_studio_temp_dir</directory>
</directories>
<args>
<arg>-vw</arg>
</args>
<input-dir>./data/processing</input-dir>
<output-dir>./data/forge_output</output-dir>
<state-dir>./data/state</state-dir>
<temp-dir>./data/temp</temp-dir>
<num-partitions>1</num-partitions>
<pipeline-file>./data/processing/pipeline.epx</pipeline-file>
</forge>
|
|
|
This element defines a Forge cluster, including a list of ID references to the Forge components that belong to this cluster. This object can be configured to distribute data to Forge servers serially or in parallel.
<forge-cluster id="ForgeCluster" getDataInParallel="true"> <forge ref="ForgeServer" /> <forge ref="ForgeClient1" /> <forge ref="ForgeClient2" /> </forge-cluster>
|
|
|
This element defines a Dgidx component, including attributes
that define the functionality of the Dgidx process as well as custom properties
and directories used to configure the functionality of the Dgidx object's
methods. Multiple
<dgidx id="Dgidx" host-id="ITLHost">
<args>
<arg>-v</arg>
</args>
<input-dir>./data/forge_output</input-dir>
<output-dir>./data/dgidx_output</output-dir>
<temp-dir>./data/temp</temp-dir>
<run-aspell>true</run-aspell>
</dgidx>
|
|
|
This element defines an indexing cluster, including a list of ID references to the Dgidx components that belong to this cluster. This object can be configured to distribute data to indexing servers serially or in parallel.
<indexing-cluster id="IndexingCluster" getDataInParallel="true"> <dgidx ref="Dgidx1" /> <dgidx ref="Dgidx2" /> </indexing-cluster>
|
|
|
This element defines a Dgraph component, including
attributes that define the functionality of the Dgraph process as well as
custom properties and directories used to configure the functionality of the
Dgraph object's methods. Multiple
<dgraph id="Dgraph1" host-id="MDEXHost" port="15000">
<properties>
<property name="restartGroup" value="A" />
<property name="updateGroup" value="a" />
</properties>
<log-dir>./logs/dgraphs/Dgraph1</log-dir>
<input-dir>./data/dgraphs/Dgraph1/dgraph_input</input-dir>
<update-dir>./data/dgraphs/Dgraph1/dgraph_input/updates</update-dir>
</dgraph>
|
|
|
This element defines the default settings inherited by all
<dgraph-defaults>
<properties>
<property name="srcIndexDir" value="./data/dgidx_output" />
<property name="srcIndexHostId" value="ITLHost" />
<property name="numLogBackups" value="10" />
</properties>
<directories>
<directory name="localIndexDir">
./data/dgraphs/local_dgraph_input
</directory>
</directories>
<args>
<arg>--threads</arg>
<arg>2</arg>
<arg>--spl</arg>
<arg>--dym</arg>
</args>
<startup-timeout>120</startup-timeout>
</dgraph-defaults>
|
|
|
This element defines a Dgraph cluster, including a list of ID references to the Dgraph components that belong to this cluster. This object can be configured to distribute data to Dgraph servers serially or in parallel.
<dgraph-cluster id="DgraphCluster" getDataInParallel="true"> <dgraph ref="Dgraph1" /> <dgraph ref="Dgraph2" /> </dgraph-cluster>
|
|
|
This element defines a LogServer component, including
attributes that define the functionality of the LogServer process as well as
custom properties and directories used to configure the functionality of the
LogServer object's methods. Multiple
<logserver id="LogServer" host-id="ITLHost" port="15002">
<properties>
<property name="numLogBackups" value="10" />
<property name="targetReportGenDir" value="./reports/input" />
<property name="targetReportGenHostId" value="ITLHost" />
</properties>
<log-dir>./logs/logserver</log-dir>
<output-dir>./logs/logserver_output</output-dir>
<startup-timeout>120</startup-timeout>
<gzip>false</gzip>
</logserver>
|
|
|
This element defines a ReportGenerator component, including
attributes that define the functionality of the ReportGenerator process as well
as custom properties and directories used to configure the functionality of the
ReportGenerator object's methods. Multiple
<report-generator id="WeeklyReportGenerator" host-id="ITLHost">
<properties>
<property name="webStudioReportDir"
value="C:\Endeca\MDEXEngine\workspace/reports/MyApp" />
<property name="webStudioReportHostId" value="ITLHost" />
</properties>
<log-dir>./logs/report_generators/WeeklyReportGenerator</log-dir>
<input-dir>./reports/input</input-dir>
<output-file>./reports/weekly/report.xml</output-file>
<stylesheet-file>
./config/report_templates/tools_report_stylesheet.xsl
</stylesheet-file>
<settings-file>
./config/report_templates/report_settings.xml
</settings-file>
<time-range>LastWeek</time-range>
<time-series>Daily</time-series>
<charts-enabled>true</charts-enabled>
</report-generator>
|
|
|
This element defines a custom component, including custom
properties and directories used to configure the functionality of the custom
component object's methods. Multiple
The custom component is also used to implement the IFCR components.
<custom-component id="IFCR" host-id="ITLHost" class="com.endeca.soleng.eac.toolkit.component.IFCRComponent">
<properties>
<property name="repositoryUrl" value="http://localhost:8006/ifcr" />
<property name="username" value="admin" />
<property name="password" value="admin" />
<property name="numExportBackups" value="3" />
</properties>
</custom-component>
|
This section describes the utility elements available in the custom namespace defined by the eacToolkit.xsd XML schema.
For more details, refer to the eacToolkit.xsd schema file distributed within the file eacHandlers.jar.
|
Element |
Description |
|---|---|
|
|
This element defines a copy utility invocation, including the source and destination and whether or not the source pattern should be interpreted recursively. Multiple
<copy id="CopyData" src-host-id="ITLHost" dest-host-id="ITLHost"
recursive="true" >
<src>./data/incoming/*.txt</src>
<dest>./data/processing/</dest>
</copy>
|
|
|
This element defines a shell utility invocation, including the command to execute and the host on which the command will be executed. Multiple
<shell id="ProcessData" host-id="ITLHost" > <command>perl procesDataFiles.pl ./data/incoming/data.txt</command> </shell>
|
|
|
This element defines a backup utility invocation, including the directory to archive, how many archives should be saved and whether the archive should copy or move the source directory. Multiple
<backup id="ArchiveState" host-id="ITLHost" move="true" num-backups="5"> <dir>C:\Endeca\apps\myApp\data\state</dir> </backup>
|
|
|
This element defines a rollback utility invocation, including the directory whose archive should be recovered. Multiple
<rollback id="RollbackState" host-id="ITLHost"> <dir>./data/state</dir> </rollback>
|
Most configuration tasks are performed by simply altering an element in the configuration document, by adding elements to the document, or by removing elements from the configuration.
These three actions enable users to alter the behavior of objects in their application, change which objects make up their application and change the way scripts acts on the objects in their application.
In addition to these simple actions, users can customize the
behavior of objects in their application or create new objects
while continuing to use the EAC development toolkit's XML
configuration document format. The following are examples of
customization that are possible within the constructs of the XML
schema defined in the eacToolkit.xsd schema file.
Users can develop new custom components by extending the class com.Endeca.soleng.eac.toolkit.component.CustomComponent. This class and its associated XML element allow any number of properties and directories to be specified and accessed by methods in the object. This customization method may be appropriate for cases where functionality needs to be developed that is not directly associated with an Oracle Endeca process.
Users can implement customizations on top of existing objects by creating a new class that extends an object in the toolkit. Most elements in the configuration document (with the notable exception of the "app" element, which specifies global configuration, but does not directly correspond to an object instance) can specify a class attribute to override the default class associated with each element. For example, a user could implement a MyForgeComponent class by extending the toolkit's ForgeComponent class.
package com.Endeca.soleng.eac.toolkit.component;
import java.util.logging.Logger;
import com.Endeca.soleng.eac.toolkit.exception.AppConfigurationException;
import com.Endeca.soleng.eac.toolkit.exception.EacCommunicationException;
import com.Endeca.soleng.eac.toolkit.exception.EacComponentControlException;
public class MyForgeComponent extends ForgeComponent
{
private static Logger log =
Logger.getLogger(MyForgeComponent.class.getName());
protected void getIncomingData() throws AppConfigurationException,
EacCommunicationException, EacComponentControlException,
InterruptedException
{
// custom data retrieval implementation
}
}
The new class can override method functionality to customize the behavior of the object. As long as the new object does not require configuration elements unknown to the ForgeComponent from which it inherits, it can continue to use the forge element in the XML document to specify object configuration.
<forge class="com.Endeca.soleng.eac.toolkit.component.MyForgeComponent" id="CustomForge" host-id="ITLHost"> ... </forge>
Users can implement custom functionality by writing new code in the XML document in new or existing BeanShell scripts. This form of customization can be used to add new functionality or to override functionality that is built in to toolkit objects. While this customization approach is very flexible, it can become unwieldy and hard to maintain and debug if a large amount of custom code needs to be written.
Customization approaches within the existing schema will be sufficient for the majority of applications, but some developers will require even greater flexibility than can be supported by the XML document exposed by the toolkit.
This type of customization can still be achieved, by switching
out of the default eacToolkit namespace in the XML document and
leveraging the highly flexible and extensible Spring Framework bean
definition format.
As an example, a developer might implement a new class,
PlainOldJavaObject, which needs to be loaded and accessed by EAC
scripts. If the object is implemented, compiled and added to the
classpath, it can be loaded based on configuration in the XML
document by specifying its configuration using the "spr"
namespace.
<spr:bean id="MyPOJO" class="com.company.PlainOldJavaObject">
<spr:constructor-arg>true</spr:constructor-arg>
<spr:property name="Field1" value="StrValue" />
<spr:property name="Map1">
<spr:map>
<spr:key>one</spr:key>
<spr:value>1</spr:value>
<spr:key>two</spr:key>
<spr:value>2</spr:value>
</spr:map>
</spr:property>
</spr:bean>
