Connectors : Consolidation Server : Configuring the Consolidation Server : Configuring the Consolidation
 
Configuring the Consolidation
 
Configuring the Processors
Trigger and Synchronize Consolidation
Forwarding Documents to Other Build Groups
This section describes the overall Consolidation Server configuration. Details and examples are given further in this guide.
Configuring the Processors
Trigger and Synchronize Consolidation
Forwarding Documents to Other Build Groups
Configuring the Processors
By default, the consolidation configuration pushes the documents they receive without transformation.
For more information, see Writing Transformation and Aggregation Processors and the examples provided in Use Cases.
Define a Consolidation Configuration
1. Go to Index > Consolidation.
2. The documents received by the Consolidation Server first go through transformation processor(s). The purpose of this transformation step is mainly to add arcs between documents to create the object graph.
Note: If you are using a custom connector, you can configure it to handle the generation of arcs directly. For more information, see "Consolidation Server directives" in the Exalead CloudView Connector Programmer's Guide.
3. The second step is the definition of the aggregation processor(s), which creates a consolidation view on top of the object graph.
4. Once processors are defined, click Apply.
5. Go to the Home page and under the connectors list, click Scan for the connectors managed by the Consolidation Server.
In the Connectors list, a consolidation-<instance name> row displays status information about consolidation.
Take into Account New Transformation Processors
To take into account changes made on your transformation processors, you need to rescan the impacted sources. You can clear the sources and scan them again or clear the Consolidation Server as described in Clearing the Consolidation Server.
1. Go to the Home page.
2. Clear the source connectors’ documents.
3. Re-scan your connectors.
Take into Account Aggregation Processors
1. In the Administration Console, go to the Home page
2. Clear the index.
3. Under Consolidation, start a Force aggregation operation.
Note:  
You can also start Force aggregation from the API Console.
A force aggregation behaves as a commit operation. The consolidation storage is fully synchronized at the end of the operation.
If you specify a type, the force aggregation operation is not managed as a commit operation. If the consolidation storage has not yet been synchronized (either by triggering an aggregation or with a force commit operation), it stays in the same state after the operation. It only aggregates the targeted content of the consolidation storage.
Important: Dynamically computed impact rules are based on old aggregation jobs. If you change your aggregation processors, these rules may no longer be consistent. To get back to a correct behavior, you either have to start a full Force aggregation operation or clear the Consolidation Server and rescan all its source connectors.
Trigger and Synchronize Consolidation
This section describes how consolidated data is sent to the index.
Commit triggers define when to write documents to the index. You can link commit conditions to inactivity, number, or size of documents, or elapsed time.
Aggregation triggers define when transformed documents and documents stored or synchronized in the Consolidation Server storage are aggregated. You can also link these conditions to inactivity, number, or size of documents, or elapsed time. Once complete, the result of the aggregation job is sent to the target Indexing Server specified in the Forward rules section.
When launching a Force commit operation, you commit the transformation job and then start an aggregation.
Important: By default, a connector does not send a synchronization order to the Consolidation Server when its scan is finished. To enable this behavior, go to Connectors > Deployment > Push API and select the Force indexing after scan option.
Forwarding Documents to Other Build Groups
By default, consolidated documents are forwarded to the Indexing Server of a specific build group, for example, bg0. However, for advanced cases, consolidated documents can also be useful for several build groups or other Consolidation Servers. To fulfill these needs, you can define forward rules in your Consolidation configuration to forward consolidated documents to the target of your choice.
The following diagram shows the forward of consolidated documents to another build group on the same Exalead CloudView instance. Documents are sent to another Indexing Server and stored in another Index.
Important: Delete orders are pushed to all build groups without checking forward rules.
Write Forward Rules in the Administration Console
1. Go to Index > Consolidation > Forward rules.
2. In Forward to, select the target build group or Consolidation Server on which you want to forward consolidated documents.
3. In the Document types field, enter the comma-separated list of document types that to forward, that is to say the document types specified in the transformation and aggregation processors. Leave this field empty to forward all document types.
4. Select Trigger indexing if you want to trigger an indexing job on the target build group or Consolidation Server automatically. This bypasses the commit conditions defined on the target build group or Consolidation Server.
5. Click Apply.
6. Clear and reindex your documents with the main Consolidation Server.
Write Forward Rules in the API Console
1. Open the Exalead CloudView API Console, <HOSTNAME>:<BASEPORT+1>/api-ui/
2. Click Manage.
3. Search for the setConsolidationConfigList method.
4. Edit the AggregationForwardProcessorConfigList node to write your forward rules.
<conso:ConsolidationConfig ...>
<conso:AggregationForwardProcessorConfigList>
<conso:AggregationForwardProcessorConfig triggerIndexing="true" pushAPIServer="bg1"/>
</conso:AggregationForwardProcessorConfigList>
</conso:ConsolidationConfig>
5. Click Save.
6. Click Apply.
7. Clear and reindex your documents with the main Consolidation Server.