Mashup : Building Mashup Applications : Configuring Data Storage for Collaborative Widgets
 
Configuring Data Storage for Collaborative Widgets
 
Configure storage to index collaborative data
Storage Administration
Troubleshooting
With collaborative widgets (Comments, Star Rating, etc.) you can enrich your document with added data saved in the data storage.
Note: Collaborative widgets are available in Mashup Builder Premium only.
Storage in Mashup allows you to:
Get arbitrary chunks of data (JSON strings, images, Java objects, etc.) attached to your Mashup Builder application.
Delete, replace and append metas and categories to Exalead CloudView documents.
Store private data per user.
By default collaborative widgets only save and retrieve data from the data storage. They manage their own data display and safeguard. They do not communicate with the index. This default behavior guarantees that each action performed within the collaborative widgets will be instantaneously propagated to all search pages.
Optionally, you can choose to index storage data to improve your data model. You will then be able to apply all index features on collaborative data (analysis, processing, search, refinement, etc.). Every change made to the document will be notified to Exalead CloudView. Changes will therefore be available after the next indexing action. The elapsed time between each indexing action can be configured in the Administration Console.
Configure storage to index collaborative data
Storage Administration
Troubleshooting
Configure storage to index collaborative data
The following procedures describe how to configure your index to use data coming from the storage.
It includes:
the Exalead CloudView document cache has to be enabled on the document build group.
the RepushFromCache setting must be set to true in StorageService.xml.
the StorageServiceDocumentProcessor must be configured in the Analysis pipeline.
the data of the collaborative widget should be mapped to metas.
Requirements
When you use a collaborative widget with the “DOCUMENT” scope, it uses the build group, the source and the doc URI, to identify each document. These values are required and must be set to be used for hit content.
1. In the Administration Console, go to Search Logics > Facets, expand the Source category.
2. Make sure that the Root property is set to Top/source. This source category is required to retrieve the hit information used to create primary keys in the storage mechanism, so as to link the collaborative widget to a document.
3. Make sure that the Use for hit content option is selected. Otherwise, your collaborative will have no source on the Mashup Builder.
Enable the build group cache
1. In the Administration Console, go to Deployment > Build groups.
2. Select Document cache.
Enable the RepushDocuments property
1. Go to your Exalead CloudView <DATADIR>/config/360 directory.
2. Open the StorageService.xml file.
3. Set the RepushDocuments property to true.
Configure the StorageServiceDocumentProcessor in the Analysis pipeline
1. In the Administration Console, go to Index > Data Processing.
2. Select your analysis pipeline, for example ap0.
The Document Processors tab displays.
3. From the Processor Types panel:
a. expand the Other node,
b. drag a Storage Service Document Processor to the list of Current Processors (preferably near the top of the list).
4. Click the StorageServiceDocumentProcessor link and define the Instance property.
Usually the instance is sts0. You can check the instance name from the Roles menu, by expanding the Storage Service role.
5. Click Save and then Apply your configuration changes.
Make data searchable
1. In Mashup Builder, check the meta name property of your collaborative widget.
For example, the Tags meta name for a Tags widget is set by default to tags[].
2. In the Administration Console, go to Data Model.
3. Click Add Property to add a property matching the meta name specified in the Mashup Builder (see step 1). For example:
Name: tags
Data Type: Alphanum
Semantic Type: text
Field Type: Dedicated field only
4. Click Accept.
By default the property is searchable.
5. Select the Preview to check your configuration changes.
6. Click Apply.
You should now be able to search on your meta in the Mashup Builder. For example, you can search on your tag values by entering tags:MyTag
Index aggregated results
1. Make sure you followed the standard indexing workflow described in the previous procedures.
2. Go to your Exalead CloudView <DATADIR>/config/360/applications/<APPLICATION NAME> directory.
3. Open the Storage.xml file.
4. Add as many StorageKey nodes containing Aggregate nodes as necessary. In the following example, we want to index the COUNT and SUM aggregation values for the bagkey StorageKey.
<Storage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=">
<Indexing>
<StorageKey name="bagKey[]">
<Aggregate type="COUNT"/>
<Aggregate type="SUM"/>
</StorageKey>
</Indexing>
</Storage>
5. Build your configuration:
a. Go to your Exalead CloudView <DATADIR>/bin/directory.
b. Launch the following command: buildgct.<sh|bat>
The StorageServiceDocumentProcessor will create the corresponding metas with aggregate operations as suffixes. For our example: bagKey_count and bagKey_sum
Storage Administration
Back up the Storage SQLite database
1. Go to <DATADIR>/storageService/storage.db.sqlite
2. Back up the database.
Enhance the Storage performance
By default the storage works with an SQLite engine and is therefore limited in terms of concurrent accesses, as each write action blocks the whole database; and scalability, when the number of entries is really big.
However, you can configure its JDBC connection to work with compatible databases (SQL Server, MySQL or Oracle) if you need the storage to be more scalable.
1. For more information, see "Creating Collaborative Widgets Using Storage Service" in the Mashup Programmer Guide .
Set up a storage linked to a replicated MySQL server
The storage service uses a standard JDBC configuration. A JDBC URL can therefore be configured to manage failover.
For example, with MySQL, we could have:
jdbc:mysql://[host][,failoverhost...][:port]/[database] » ?propertyName1[=propertyValue1][&propertyName2]
[=propertyValue2]...
However, this MySQL failover configuration does not guarantee real High Availability, as database queries will be read-only queries, preventing users to enrich documents with storage information (for example, saving the preferences of the advanced table widget, comments, star rating, saved queries, etc.).
See the MySQL documentation: ​ http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-configuration-proper­ties.html
Troubleshooting
Repush is not launched after document modifications
1. Enable the cache before indexing. Note that dumping the storage database will not trigger an automatic repush from cache.
I can’t search on my collaborative data
A meta corresponding to the collaborative data must be mapped to a "searchable" field or facet in your data model.
1. Check that the collaborative widget data has been properly indexed.
To do so, you can use a debug processor as explained in Troubleshoot all issues related to the storage service behavior.
Apply actions fail if the search server and the related storage service are not on the same host
Storage can't be used from a remote search server due to SQLite limitations.
It is yet fully compatible with MySQL and Oracle.
Troubleshoot all issues related to the storage service behavior
1. In the Administration Console, go to Logs.
2. Set the Default logging level to Debug and check the storage service's logs.
3. Make sure that the repushFromCache request is issued without problems.
Important: If you get an error saying invalid source:", it means that the source is empty, that is to say that there is no source category to display. Go to Search Logics > Facets, expand the Source category and set the Root property to Top/source
Troubleshoot indexing issues
1. In the Administration Console>, go to Index > Data Processing > pipeline name > Document Processors.
2. Add a Debug Processor to the bottom of your analysis pipeline.
3. Make sure that values are indexed.
a. Go to Logs.
b. From the Processes select box, select analyzer-<BUILD GROUP NAME>.
The Debug Processor will write explicit logs.