Difference between revisions of "Administration"

Latest revision as of 19:02, 6 July 2016

THIS SECTION OF GCUBE DOCUMENTATION IS OUTDATED.

Resources Management

Generic Resources Management

In order to properly setup a VDL, several Generic Reosources are needed to be published on IS. 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 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>InternalEngine</EngineType>
			<Persistence>false</Persistence>
			<FaultTolerance>false</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.

Profile Administration Portlet

Using this portlet it is able to edit the generic resource mentioned above

The Profile Administration portlet can be accessed only by users with privileged accounts. Using this portlet, you can create and/or delete a user profile by typing the user's username. You can also upload the Default User Profile on the Information System as a generic resource. This can be done through this portlet. The Default User Profile should be a valid XML document (More about the DefaultUserProfile).

ScenarioCollectionInfo

This Generic Resource contains information about the available collections for a specific VRE 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.
More informations about the ScenarioCollectionInfo resource can be found here.

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:

1. option-name: This is the displayed name in the search fields.
2. 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.
3. 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).
4. 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()) &gt; 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()='URL']"/></xsl:attribute>
            <i>
                <xsl:value-of select="//*[local-name()='title']"/>
            </i>
        </a>
        <br/>
        <xsl:value-of select="//*[local-name()='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>

Generic Resource Management Portlet

The Generic Resource Management portlet can be accessed only by the portal's administrator. Using this portlet, the administrator can edit or delete the existing generic resources or he/she can a create a new generic resource.

Metadata Broker Management Portlet

The Metadata Broker Management portlet can be accessed only by the portal's administrator. Using this portlet, the administrator can edit or delete the existing transformation programs or he/she can a create a new transformation program.

VO and Users Management

Through this portlet, the vo administrator can add/remove VOs, edit users, roles and the layout.

Edit Layout

When the vo administrator clicks on the edit layout link, a text area appears presenting the layout that defines the order and location where the portlet will be rendered. More information about how to configure the layout can be found here.

Edit Users

In order to add more users with specific roles in a VO, the admin has to select these users as well as the roles and then click on the "Add" button. In the list with the users that can be added to the VO, the ones that have requested access to the corresponding VO while registering to the portal are preselected. On the other hand, the admin can dismiss a group of users from a VO by selecting them and then clicking on the "Remove User(s) from VO" buttom. Finally, the admin can change the roles of a user regarding this VO by clicking on the "Change Roles" buttom.

Edit Roles

Dismiss VO

VRE Monitoring

THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.

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.

Monitoring

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.

Monitoring

Selecting "Map" on the Resource Visualizer the location Map of the hardware resources are shown.

Monitoring

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.

Monitoring

VRE Management

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.

Software Archive Registration

A Software Archive is a software component compliant with gCube policies we want to register in the infrastructure.

GHN Registration

A GHN is a Server empowered by the GHN software component.

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

Software Archive Approval

GHN Approval

Services Deployment

This task offers a user interface that looks like the monitoring one. The administrator can select the GHNs and the Services he wants to deploy on the nodes. GHNs 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 GHN or Service can be done using the button on the header of Profile Visualizer panel. When a GHN 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 GHN an additional entry is presented on the Resource Visualizer panel. In particular it is presented as Running Instances On <Name of Selected GHN> entry. Clicking on it, the Resource Browser panel lists the already available Running Instances on that GHN. This allows the administrator to evaluate a GHN. For example, the administrator can decide if the selected GHN is the proper one to host new Service[s] deployment.

When at least one GHN 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 fulfilled.

During the deployment the status is presented in profile visualizer panel. The status is refreshed until the process is completed with a failure or with a success.

VRE Definition

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.

VRE Deployment

THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.

This portlet allows to edit, approve or withdraw a VRE already designed.

When the VRE is already been approved the deployment status is also available.

The deployment status is shown on the left.

Index Management

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:

Generic Editor

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]):

Generic Editor

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:

Generic Editor

And if an Index Lookup item is chosen, it will look like the following:

Generic Editor

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:

Generic Editor

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:

Generic Editor

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:

Generic Editor

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:

Generic Editor

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:

Generic Editor

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:

Generic Editor

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):

Generic Editor

Push the "Update" button to start the indexing of the provided ResultSet. A green label will indicate that the update has been successfully started:

Generic Editor

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:

Generic Editor

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:

Generic Editor

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):

Generic Editor

Upon success, a green confirmation message will be shown:

Generic Editor

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.

Generic Editor

Geo Index

Overview

Geo Index Information

Editing the GeoIndexType

Creating a Geo Index

Testing a Geo Index

Removing a Geo Index