Administration
Contents
Resources Management
THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.
Generic Resources Management
In order to properly setup a VDL, several Generic Reosources are needed to be published on DIS. The VDL Administrator can create them by using the Generic Resource Portlet. Additionally, every time that a new schema appears on VDL, a MetadataSchemaInfo, a PresentationXSLT_<schemaName>_<xsltName> and a MetadataXSLT_<schemaName>_<xsltName> Generic Resources must be created for this schema.
DefaultUserProfile
The DefaultUserProfile Generic Resource contains information about the mandatory elements that all user's profiles must have.
The VDL Administrator must create this Generic Resource named "DefaultUserProfile".
The body of this resource must be in the following form:
<userprofile>
<userinfo>
<username></username>
<fullname></fullname>
<email></email>
</userinfo>
<userpreferences>
<language></language>
<langcolpairs></langcolpairs>
<xslts>
<metadataxslt></metadataxslt>
<presentationxslt></presentationxslt>
</xslts>
</userpreferences>
</userprofile>
If the DefaultUserProfile Generic Resource should be changed, the Profile Administration Portlet can be used in order to apply the changes.
ScenarioCollectionInfo
This Generic Resource contains information about the available collections for a specific VDL and their hierarchical structure.
The collections can be clustered in group so as to help end users to identify similar collections and to present the collections in a human managable way.
The VDL Administrator must create a Generic Resource named: "ScenarioCollectionInfo" whose body must be in the following form:
<DL name="<AbsoluteDLName>">
<collections name="collection group 1 name" shortname="short name" description="description of group of callections">
<collection name="collection 1.1 name" reference="reference url for this collection" shortname="short name for the collection" description="collection desription"/>
<collection name="collection 1.2 name" reference="reference url for this collection" shortname="short name for the collection" description="collection desription"/>
<collection name="collection 1.3 name" reference="reference url for this collection" shortname="short name for the collection" description="collection desription"/>
...
</collections>
<collections name="collection group 2 name" shortname="short name" description="description of group of callections">
<collection name="collection 2.1 name" reference="reference url for this collection" shortname="short name for the collection" description="collection desription"/>
<collection name="collection 2.2 name" reference="reference url for this collection" shortname="short name for the collection" description="collection desription"/>
...
</collections>
...
</DL>
The root element is DL and it has an attribute named "name". The name attribute is very important and it has to be in the form: /<VO>/<Community>/<DLName>
Additionally, the DL element, contains an arbitrary number of "collections" elements. Each of these elements represent a group of collections.
Its attributes are:
- name: The name of the group
- shortname: The shortname of the group
- description: Its description
Furthermore, its collections element contains an arbitrary number of "collection" elements. Each of these elements represents an actual collection.
Its attributes are:
- name: The name of the colection. This name must be a perfect match with the collection name as it exists in collection management service.
- shortname: The shortname of the collection
- description: Its description
- reference: A reference URL for this collection
MetadataSchemaInfo
One such Generic Resource must exist for each schema of the VDL.
It contains information about which are the searchable and the browsable fields in addition to what type of search must be applied.
The VDL Administrator must create one Generic Resource for each schema named "MetadataSchemaInfo ".
The body of this resource must be in the following form:
<schemaName>
<option>
<option-name>displayed name in search fields</option-name>
<option-value>actual xml-element name in metadata or an XPath expression</option-value>
<option-type>type of search to apply</option-type>
<option-sort>XPath expression to be used for sort (exist only for browsable fields)</option-sort>
</option>
...
</schemaName>
The root element is the name of the corresponding schema. This node contains an arbitrary nmber of "option" elements.
Each option element contains the following elements:
- option-name: This is the displayed name in the search fields.
- option-type: It can either be fielded or xpath. If it is fielded it means that the fielded search operator must be used in search. On the other hand, if it is xpath, the filter by xpath search operator must be used in search.
- option-value: If type is fielded the name of the field (xml-element) must be here. Otherwise, it must contain the xpath expression that identifies the field in xml schema. (Xpath is usually used when the corresponding field is not an element but an attribute in the metadata).
- option-sort:This is an optional element. If it exists, it means that this field is browsable (the user can browse the collection and receive the results sorted by this field). So, the XPath expression that identifies this field must exist here.
TitleXSLT
This Generic Resource contains an XSLT that extracts from every Result-Record the title field, regardless the schema, or where it came from (google, full text, quick serach etc).
The VDL Administrator must create a Generic Resource named "TitleXSLT" whose body must be an XSLT. Bellow you can find a template XSLT:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output encoding="UTF-8" method="html" omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:choose>
<xsl:when test="//*[local-name()='title'][1]">
<xsl:value-of select="//*[local-name()='title'][1]"/>
</xsl:when>
<xsl:when test="//*[local-name()='resTitle'][1]">
<xsl:value-of select="//*[local-name()='resTitle'][1]"/>
</xsl:when>
<xsl:when test="//titleStmt/title[@type='main'][1]">
<xsl:value-of select="//titleStmt/title[@type='main'][1]"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="/root/docFields/*[1]"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
GenericXSLT
This Generic Resource contains an XSLT that transforms Result-Record of QuickSearch to html records so as to be presented to the end user.
The VDL Administrator must create a Generic Resource named "GenericXSLT" whose body must be an XSLT. Bellow you can find a template XSLT:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output encoding="UTF-8" method="html" omit-xml-declaration="yes"/>
<xsl:template match="/">
<table width="100%">
<xsl:for-each select="root/docFields/*">
<tr>
<td align="right" class="window-title-inactive" width="120">
<b><xsl:value-of select="local-name()"/>:</b>
</td>
<td>
<xsl:value-of select="substring(self::node(),1,100)"/>
<xsl:if test="string-length(self::node()) > 100">
<i>... (more)</i>
</xsl:if>
</td>
</tr>
</xsl:for-each>
<tr>
<td align="right" class="window-title-inactive" width="120">
<b>Collection:</b>
</td>
<td>collection-name-here</td>
</tr>
</table>
</xsl:template>
</xsl:stylesheet>
GoogleXSLT
This Generic Resource contains an XSLT that transforms Result-Record of GoogleSearch to html records so as to be presented to the end user.
The VDL Administrator must create a Generic Resource named "GoogleXSLT" whose body must be an XSLT. Bellow you can find a template XSLT:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output encoding="UTF-8" method="html" omit-xml-declaration="yes"/>
<xsl:template match="/">
<a target="_blanck">
<xsl:attribute name="href"><xsl:value-of select="//*[local-name()</span>='URL']"/></xsl:attribute>
<i>
<xsl:value-of select="//*[local-name()</span>='title']"/>
</i>
</a>
<br/>
<xsl:value-of select="//*[local-name()</span>='snippet']"/>
</xsl:template>
</xsl:stylesheet>
PresentationXSLT_<schemaName>_<xsltName>
At least one such Generic Resource must exist for each schema of the VDL.
It contains an XSLT that transforms the Result-Record to html records so as to be presented to the end user.
The VDL Administrator must create at least one Generic Resource for each schema named "PresentationXSLT_<schemaName>_<xsltName>" whose body must be an XSLT, where schemaName is the name of the corresponding schema and xsltName is a name for the xslt.
Notice: There must be at least one xslt per schema. This xslt must be named "default" and it is the one that will be used in the user-profile as the selected xslt for this schema when the profile will be created.
Bellow you can see a template XSLT:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output encoding="UTF-8" method="html" omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:if test="//*[local-name()='creator']">
<xsl:value-of select="//*[local-name()='creator']"/>
,
</xsl:if>
<xsl:if test="//*[local-name()='title']">
<i>
<xsl:value-of select="//*[local-name()='title']"/>
</i>
</xsl:if>
(
<xsl:if test="//*[local-name()='date']">
<xsl:value-of select="//*[local-name()='date']"/>
,
</xsl:if>
<xsl:if test="//*[local-name()='language']">
<xsl:value-of select="//*[local-name()='language']"/>
,
</xsl:if>
collection-short-here)
</xsl:template>
</xsl:stylesheet>
MetadataXSLT_<schemaName>_<xsltName>
At least one such Generic Resource must exist for each schema of the VDL.
It contains an XSLT that transforms the metadata record to html so as to be presented to the end user.
The VDL Administrator must create at least one Generic Resource for each schema named "MetadataXSLT_<schemaName>_<xsltName>" whose body must be an XSLT, where schemaName is the name of the corresponding schema and xsltName is a name for the xslt.
Notice: There must be at least one xslt per schema. This xslt must be named "default" and it is the one that will be used in the user-profile as the selected xslt for this schema when the profile will be created.
Bellow you can see a template XSLT:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output encoding="UTF-8" indent="yes" method="html" version="1.0"/>
<xsl:template match="/">
<table border="1" style="border-collapse: collapse;" width="60%">
<xsl:if test="//*[local-name()='title']">
<th align="left" class="diligent-header">Title</th>
<xsl:for-each select="//*[local-name()='title']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='creator']">
<th align="left" class="diligent-header">Creator</th>
<xsl:for-each select="//*[local-name()='creator']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='subject']">
<th align="left" class="diligent-header">Subject</th>
<xsl:for-each select="//*[local-name()='subject']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='description']">
<th align="left" class="diligent-header">Description</th>
<xsl:for-each select="//*[local-name()='description']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='publisher']">
<th align="left" class="diligent-header">Publisher</th>
<xsl:for-each select="//*[local-name()='publisher']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='contributor']">
<th align="left" class="diligent-header">Contributor</th>
<xsl:for-each select="//*[local-name()='contributor']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='date']">
<th align="left" class="diligent-header">Date</th>
<xsl:for-each select="//*[local-name()='date']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='type']">
<th align="left" class="diligent-header">Type</th>
<xsl:for-each select="//*[local-name()='type']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='format']">
<th align="left" class="diligent-header">Format</th>
<xsl:for-each select="//*[local-name()='format']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='identifier']">
<th align="left" class="diligent-header">Identifier</th>
<xsl:for-each select="//*[local-name()='identifier']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='source']">
<th align="left" class="diligent-header">Source</th>
<xsl:for-each select="//*[local-name()='source']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='language']">
<th align="left" class="diligent-header">Language</th>
<xsl:for-each select="//*[local-name()='language']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='relation']">
<th align="left" class="diligent-header">Relation</th>
<xsl:for-each select="//*[local-name()='relation']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='coverage']">
<th align="left" class="diligent-header">Coverage</th>
<xsl:for-each select="//*[local-name()='coverage']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="//*[local-name()='rights']">
<th align="left" class="diligent-header">Rights</th>
<xsl:for-each select="//*[local-name()='rights']">
<tr>
<td>
<xsl:value-of select="self::node()"/>
</td>
</tr>
</xsl:for-each>
</xsl:if>
</table>
</xsl:template>
</xsl:stylesheet>
VO and Users Management
THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.
VRE Monitoring
The Information System Monitoring user interface grants access to all information handled by the D4Science Information System (IS) from a Graphical User Interface. It queries and shows on demand the latest information published on a IS instance, ranging from the profiles to the specific WS-Resource properties documents. By accessing to the Information System Monitoring user interface, it is possible to monitor the status of newly VRE deployed in the infrastructure.
On the left panel, named Resource Visualizer, the user has the opportunity to choose which type of resource he wants to monitor.
On the upper-right panel, named Resource Browser, the user can navigate the list of the resources of the type selected of the left panel.
The profile of the selected resource in the list is shown in the down right panel, named Profile Visualizer. By default the profile is shown in an user oriented view. Clicking on the button "XML View" the profile is shown in XML mode. Newly clicking on "Normal View" the profile is shown in an user oriented view.
Selecting "Map" on the Resource Visualizer the location Map of the hardware resources are shown.
The green icons 
represent gLite Nodes, instead the yellow icons 
represent gHN.
Clicking on the icon a zoom is performed if needed and a Tabbed Information Window is open. Each tab represents a part of the information available for the selected node. In some cases in the Tab Information Window there are some links which cause the opening of a new browser window.
VRE Management
Resources Management
Generic Resources Management
In order to properly setup a VRE, several Generic Reosources are needed to be published on the IS. The VRE Administrator can create them by using the Generic Resource Portlet. Additionally, every time that a new schema appears on VRE, a PresentationXSLT_<schemaName>_<xsltName> and a MetadataXSLT_<schemaName>_<xsltName> Generic Resources must be created for this schema.
DefaultUserProfile
The DefaultUserProfile Generic Resource contains information about the mandatory elements that all user's profiles must have.
The VRE Administrator must create this Generic Resource named "DefaultUserProfile".
The body of this resource must be in the following form:
<userprofile>
<userinfo>
<username></username>
<fullname></fullname>
<email></email>
</userinfo>
<preferences>
<language></language>
<moodleURL></moodleURL>
<searchpreferences>
<EngineType></EngineType>
<Persistence></Persistence>
<FaultTolerance></FaultTolerance>
</searchpreferences>
<langcolpairs></langcolpairs>
<xslts>
<metadataxslt></metadataxslt>
<presentationxslt></presentationxslt>
</xslts>
</preferences>
</userprofile>
If the DefaultUserProfile Generic Resource should be changed, the Profile Administration Portlet can be used in order to apply the changes.
Resources Registration
It is possible to register various types of resource on infrastructure. There is a dedicated user interface for each of them. After the registration process, each resource is going on a pending state and needs to be approved by one administrator with the approval user interface.
External Running Instance Registration
An External Running Instance is a WEB-Service which we want to make available in the infrastructure.
Service Archive Registration
A Service Archive is a software component compliant with gCube policies we want to register in the infrastructure.
DHN Registration
A DHN is a Server empowered by the DHN software component.
Archive/Data source Registration
Any existing data sources can be made available in the infrastructure defining the appropriate configuration file. The syntax of the configuration file is described in the Archive Import service documentation.
Resources Approval
For each kind of resource the user can register, the approving step needs to be performed by one administrator. After this step the resource is available on the infrastructure.
All these portlets are listed with a checkbox on each row. After the selection process the administrator has the opportunity to choose the action he want to do. Two actions are possible: Approve or Withdraw. This is performed on the selected resources by clicking on the relative button. The list is paginated and presents 10 resource for each page. The action affects only the selected resources on the current page.
External Running Instance Approval
Service Archive Approval
DHN Approval
Archive/Data source Approval
Services Deployment
This task offers a user interface that looks like the monitoring one. The administrator can select the DHN and the Services he wants to deploy on the nodes. DHNs that can be selected for deployment are those typed in bold in the Resource Browser panel, i.e., those made available by the local administrator according to institution policy or other reasons. Instead, all Services can be selected.
The selection/deselection of one DHN or Service can be done using the button on the header of Profile Visualizer panel. When a Node or a Service is selected, it is inserted into the "Selected Resource Tree". This tree can be browsed as the "Available Resource Tree". This allows the user to have a sort of basket to check the selected resources in each moment. For each selected DHN an additional entry is presented on the Resource Visualizer panel. In particular it is presented as Running Instance On <Name of Selected DHN> entry. Clicking on it, the Resource Browser panel lists the already available Running Instance on that DHN. This allows the administrator to evaluate a DHN. For example, the administrator can decide if the selected DHN is the proper one to host new Service[s] deployment.
When at least one DHN and one Service are selected a Deploy button appears on the left panel.
Clicking on it the deploy process starts after a confirmation request has been fullfilled.
During the deployment there appears a Dialog Box with the deployment status. The status is refreshed until the process is completed with a failure or with a success.
VRE Creation
THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.
Because of its nature, this graphical user interface is characterized by a high interaction with users.
Wizard mechanism is the way used to create a new VRE.
VRE Generator enables users/communities (VRE Designers) to define their own VREs and VRE Administrators to actually create them and monitor their operational status. It allows defining a set of criteria specifying the expected characteristics of the new VRE; starting from them, it identifies the set of resources required to provide the requested features.
Both the characterisation criteria and the resulting set of resources constitute the VRE Definition document. In particular, the facilities supported by the VRE Generator are to:
- Provide support to users/communities (VRE Designers) in specifying the criteria that characterize the new VRE, e.g. the information space, the required functionality;
- Provide support for selection of the appropriate pool of services, collections and, in general, resources required to implement a VRE that satisfies the specified criteria;
- Provide support to VRE Managers in developing the designed VREs and monitoring their operational status;
- Notify the VRE Management service of the identified set of resources constituting the VRE;
- Provide support for storage of the definition criteria, i.e. the VRE Definition documents, about the defined VREs for further usage.
The wizard is composed by 4 step at design time.
VRE Information
This step enables the VRE Designer to specify the name and the description the VRE will have. Moreover, it is possible to specify the users that play the role of VRE Designer (in addition to the user that is performing the design task) and the role of VRE Administrator. Additional and optional information provided through this step is about the specification of VRE desired start- and end- time. If specified this last information will constrain the VRE operational time.
VRE Content
It enables the VRE Designer to specify the characteristics of the VRE Content.
Two sub-steps are envisaged:
VRE Collections
The first sub-step allows to select the set of collections (Document Collections) constituting the VRE information space, i.e. the set of information objects that will be available into the VRE. For each collection, the portlet displays the minimal set of information supporting the user in selecting the appropriate ones, namely name and description. This step also provides a link with the Archive Importer portlet through which it is possible to add new Collections to the infrastructure.
VRE Metadata Format
The second sub-step allows specifying the set of metadata formats that will be available in the previously selected collections, i.e., this step selects the Metadata Collections for describing the Information Object Collections according to one or more metadata schemes.
VRE Functionality
This step allows the VRE Designer to specify the set of Functions the VRE will be equipped with. By default the majority of the gCube Functions are mandatory, thus the portlet only focuses on how optional functions can be selected.
VRE Architecture
When the Administrator approves the VRE, s/he will be able to see and modify each step. Further, s/he will do an additional step, named as VRE Architecture.
Index Management
THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.
Full Text Index
After opening the the FullTextManagementPortlet, you see a screen with an Index Explorer tree on the left side, and an (empty) Index Detail panel on the right. The IndexDetail Panel is empty as no index resource has currently been selected in the Index Explorer tree. The Index Explorer panel, however, always displays one or more folder icons when the portlet is ready for use:
The folder icons represent metadata collections available in the VO. A big green folder (marked with a [1] above) represents a collection name which has one or more related indices. A big blue folder (marked [2]) represents a collection name which does not have any related index. The single blue folder marked with a pencil and labeled as "Fake Collections" (marked [3]) is the only icon which is always present even if no collections exists. This icon represents all collection IDs which are related to one or more indices, but which can not be mapped to a true metadata collections. This is a usual scenario for test indices, in order to avoid other resources harvesting the epr of the test index from DIS when looking for valid indices of a specific collection.
A collection name is not necessarily unique, as many collections are allowed to have the same name though not the same ID. Actual metadata collections are represented by a smaller folder icon, along with its collection ID. Collections which have been indexed, are represented by a green folder (marked [4]), while collections which have not been indexed are represented by a grey folder (marked [5]).
Full Text Index Information
If you expand the green collection tree items (by clicking on the [+] beside them), one or more Index icons (marked [1] below) appear. These represent Index Managers. If some Index Lookups are connected to the Index Manager, the Index item can be expanded to reveal one or more Index Lookup icons (marked[2]):
If you select either an Index item or an Index Lookup item in the Index Explorer, the Index Detail panel will show a tab panel with information related to the selected resource (WS ResourceProperty values). If an Index item is chosen, the IndexDetail will look similar to the following illustration:
And if an Index Lookup item is chosen, it will look like the following:
Editing the IndexType
In order to edit the Index Type of an Index Manager, make sure the correct Index item is selected in the Index Explorer, then select the "Edit" tab in the Index Detail tab panel. This will reveal Index Edit panel:
The chosen Index items IndexType is displayed as a list of Index Type Fields with editable checkboxes. The save button saves the IndexType currently shown into the selected Index Management resource.
If a Index Lookup item has been selected, choosing the "Edit" tab will reveal the Index Lookup Edit panel:
This panel is identical to the Index Edit panel, however only the "Return" checkboxes are enabled. This is due to the fact that the Return Element is the only part of an IndexLookup's index type which is editable. Any other change has to be performed towards the Index Management (using the Index Edit panel)
Creating a Full Text Index
Creating a new Index can be accomplished by either selecting the "New Index" item (marked [1] below) or the "New Fake Collection" item (marked [2])in the Index Explorer:
Upon selecting one of the two items mentioned above, the Index Detail panel allows you to specify the properties of the new Index. The IndexID property textbox should usually be left empty, in which case the IndexService itself creates a unique ID for the Index. If the "New Fake Collection" item has been chosen, you also need to specify a collection ID (fake - e.g., "myTestCollection1" or something like this), however if the "New Index" item has been chosen, the collection ID will be retrieved from the parent collection item and will not be editable (as shown in the image above).
After specifying the properties of the new Index, push the "Create" button in order to create the new Index. Upon success, the new Index Item appears as the active element in the Index Explorer. The "Info" tab of the new Index is then shown in the Index Detail panel:
As shown in the image above, the Index Detail panel is usually unable to retrieve information about the newly created Index. This is due to the fact that there is a slight lag between the creation of an Index and the availability of information about it. Clicking the newly created Index item once more will update the Index Detail panel with valid data.
Creating a Full Text Index Lookup
In order to query an Index, an Index Lookup resource is needed. An Index Lookup can be created at any point in the life time of an Index, and will automatically be updated when new information is indexed by its Index Manager. In order to create a new Index Lookup resource for an Index, select the "New Lookup" item under the Index item in the Index Explorer:
The Index Detail panel shows a very simple interface, allowing you to specify the Lemmatizer plugin the new Index Lookup should use. Usually, this text box should be left empty, in which case the default Lemmatizer plugin is used. Pushing the "Create" button triggers the creation of the new Index Lookup. Upon success, an item with a new icon appears as the active element in the Index Explorer. This item represents the newly created Index Lookup. The "Info" tab of the Index Lookup is then shown in the Index Detail panel:
As it occurs in the creation of an Index, the Index Detail is usually not able to get information about the Index Lookup right after its creation, in which case you have to select the Lookup item once more if you need to see valid information about the new item.
Feeding a Full Text Index
The information to be indexed is fed to the Index through a ResultSet. In order to index the ResultSet, select the Index item to be used in the Index Explorer, and choose the "Feed" tab. Enter a valid RSLocator string in the textbox as shown below (the RSLocator string in the example is a bit strange one since it points to a local ResultSet):
Push the "Update" button to start the indexing of the provided ResultSet. A green label will indicate that the update has been successfully started:
Testing/Querying a Full Text Index
In order to test (by querying) an Index, an Index Lookup for the Index in question is needed. If no Index Lookup is available, it has to be created. If an Index Lookup is available for the Index to be queried, select the Index Lookup in the Index Explorer and select the "Query" tab in the Index Detail panel. This tab allows you to enter a query string as shown below:
Pushing the Query button will perform a query against the Index Lookup. Upon success, the first page of the results of the query will be shown in its raw XML format bellow the query text box:
Removing a Full Text Index or Index Lookup
In order to remove an Index or an Index Lookup, select the item to be removed in the Index Explorer and choose the "Remove" tab in the Index Detail. Clicking the remove button (marked [1] below), will cause a warning dialog (marked [2]) to be shown. Push the "OK" button to remove the resource (and keep in mind that removing an Index resource will automatically remove all Index Lookup and Index Updater resources connected to it):
Upon success, a green confirmation message will be shown:
Upon failure, a red error message is shown. This message is usually due to the fact that the resource just removed is still being present in the Index Explorer due to delays in the underlying infrastructure.
