Muse Search FAQ
Muse Search
MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights
Load More
The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.
Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.
Note that Muse allows administrators to set these logon limits at both the application and system levels.
These setting are kept in the MAX_USER_CONCURRENT_SESSIONS
variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml
file and change the value of the MAX_USER_CONCURRENT_SESSIONS
tag.
– application level ($APPLICATION_HOME/profile.xml)
: access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.
Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.
The following must be done to achieve this functionality:
1. Search the $APPLICATION_HOME/www
folder for files containing an HTML form called “logoffForm”.
2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with.
3. In the $MUSE_HOME/web/www/logon
folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with.
4. In the $MUSE_HOME/web/www/logon/app_name
folder create a redirect.html file such as the example below:
Simply use the URL of the target page you want in place of "http://www.museglobal.com".
The Application ID must begin with a letter and can contain only letters, numbers, and underscores. However, the first character of an application ID can only be alphabetic (NOT a numeric or underscore). There is no limitation on the number of characters that the Application ID can contain (no length restrictions). Alphabetic characters can be upper or lower case.
Some suggestions regarding how Application IDs should be created might be:
– add a identifying prefix for each customer if a single customer has many Applications
– add a suffix with the creation date
– keep the ID as brief as possible, but still efficient and easy to identify/intelligible.
There are three inactivity timeouts levels in Muse. In ascending order they are:
– application level
– WebBridge level
– ICE level
So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).
Default values for these levels are as follows:
– application level15 minutes
– WebBridge level20 minutes
– ICE level30 minutes
To set each of the above timeouts, the user have to:
a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff)
and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.
b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.
c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml
and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.
The “:” character is a keyword in Muse syntax, used to search on the simple search formfor a complex query (example: to search on both author and title on the simple search form : “:CREATOR john AND :TITLE design”).
Note that words that contain a “:” character can be searched if the text is in quotes (ex: “asthma:”).
To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.
A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:
– log into the MCAA console as a mcaa based user;
– select the desired Muse application, then click Login Modules;
– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP
login module; click Add;
– click Edit to edit the ICELoginModuleIP
module;
– click Edit User Access Rules
and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);
– click “Update”.
B) For Muse versions before 2500, the modifications to be done are:
– $MUSE_HOME/use/ice/jaas.config
– locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:
appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};
Note: if the above entry already exists for the appid application, then only the bold line must be added.
– $MUSE_HOME/use/ice/profiles/hosts
– an entry like next must be added:
Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:
The URL to access the autologon page is:
http://Muse_host:PORT/muse/logon/appid/autologon_page.html
where:
- Muse_host is the hostname of the Muse system;
- PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
- appid is the application ID;
- autologon_page.html is the page which contains the above HTML form.
The record enrichment feature from Muse mainly brings imaging content that is presented next to the data extracted by the Source Package via a specialised key within Muse, like SyndeticDirectKey.
The enrichment is based on the ISBN value (already extracted by a Source Package) which is then searched for using specialised services. Such a service is the Syndetics Solutions one, which provides a lot of data if queried, like: cover images, abstract, TOC, etc.
To be able to check if the enrichment feature works well for this service, one must access a URL such as the following:
http://syndetics.com/index.aspx?isbn=ISBN/index.html&client=ACCESSCODE,
where
– ISBN – with the ISBN value extracted by the Source Package
– ACCESSCODE – user access code to the service
Note: to be able to identify the ISBN of a record (not all records have such a field), one must run a search using the MCAA console and use the XML display format. After the records are retrieved, expand them and look for the
tag, inside the
one. Its value is the one that must be filled in the above URL.
The Application ID may contain alphabetic, numeric or underscore characters. The first character in an Application ID must be alphabetic (NOT numeric or an underscore). No other characters are allowed. There is no limitation on the number of characters the ID can have.
The difference in the Content Mining (CM) results is given by the difference in the results returned by the sources.
Using “Full Text” limiters limits the number and the ‘quality’ (with regard to the CM) of the results returned by the search sources. The configuration of the module and the different results returned by the different searches are factors that limit the number of terms in the “Refine your results” window. We actually don’t display any term unless its threshold weight is above 3, which usually means that the term must be found at least 2-3 times in the returned records.
Of course the limit can be lowered to 1 so that the CM always returns something, no matter the search, but the results will not always be meaningful with respect to the search query. It will also waste quite a lot of heap memory since we will have to keep more terms into the main memory until they are being sent to the browser to be displayed. Having many CM terms is less important than having only the relevant terms even if it means that there is only one relevant term. The CM process must be focused on quality and not quantity.
The procedure to change/remove the default sorting algorithm in an application (Muse 2.3.0.2. or above) is:
– log into the MCAA/MCCS,
– select an application,
– click Application Modules,
– click Ranking Keys,
– click Update Interface,
– select for which language to make the change,
– select the desired default ordering method/key (right side),
– click Update,
– click Close Window button.
Note that this applies for applications based on a MuseFoundation application template. To verify the changes relogin into the application.
For applications that are based on an older application template, the settings must be manually done because they are not compatible with the newer Muse admin consoles (MCAA/MCCS).
Below are the changes that must be done to configure the default sorting algorithm in applications based on older templates. Edit the
- $APPLICATION_HOME/www/application/searchOptions.db file and/or the
- $APPLICATION_HOME/www/international/XYZ/application/searchOptions.db file(s), where XYZ is the language code.
The line
which is equivalent to None (no ordering), must be replaced with:
or any other sorting key, such as:
– ICERankingKeyAuthor
– ICERankingKeyAuthorTitle
– ICERankingKeyDate
– ICERankingKeyField
– ICERankingKeyRelevance
– ICERankingKeyRetrieved
– ICERankingKeySource
– ICERankingKeyTitle
depending on the needes.
1) At the application level:
This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml
, field:
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
2) At the system level:
In the $ICE_HOME/ICECore.xml
file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.
By default the configured values are:
This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS
field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS
value. Also, when changing the value of MAX_CONCURRENT_SESSIONS
one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS
set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS
from applications.
Please Note:
The MAX_USER_CONCURRENT_SESSIONS
value set in the $ICE_HOME/ICECore.xml
file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.
“Total number of unique sources from all applications” is the total number of SPs from all applications listed in the report. In this case, unique means that if the same SP appears in many applications it is counted only once. Also they are counted no matter if they are part or not of any group (they appear or not in the interface).
“Total number of unique sources used in groups from all applications” – This is the total number of SPs from all applications listed in the report. Unique meaning that if the same SP appears in many applications it is counted only once. Furthermore only the SPs that belong to a group (they are visible in the interface) are counted here.
Here are some details about the query remapping mechanism in Muse: if a search on one or more search attributes is performed on a Muse Source Package, the ICE Search module analyses the Source Package CPB (capabilities) file and all the search attributes included in query which are not present in the CPB file are remapped to the default attribute. The default attribute to be used for unsupported search attributes is defined in the Source Package PMF (PreMappingFile) file.
If a search with limiters is performed on a Muse Source Package then all the limiters which are not supported by that Source Package are ignored – only supported ones are processed. There will never be an unsupported query caused by the presence of some search limiters in the query. This is valid for all Muse Source Packages.
The reason why the search is not automatically starting when using the following search form:
is that there are no SP targets provided on which to perform the search.
Specifying/providing the SP targets can be done in 2 ways:
a) Setting in the application the default sources for the searches. This can be done using the Muse Console for Customer Support or Muse Console for Applications Administration as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration, select the desired application and click on the “Setup and Organize Sources” left menu item;
– go to “Organize Sources” left menu item and click on the “Update Interface” sub-item;
– in the right section of the “Update Interface” panel check the Source Packages that should be selected as default from each defined group;
– press the Update button; this will update the interface for the default language with the selected Source Packages; if you want to specify default selected Source Packages for other languages available than the default one, select the desired language from the “Language” combobox and make the same operations, e.g. select the sources and press the “Update” button.
b) Extend the HTML form presented below and include the targets on which to perform the search. For example if one wants to perform the search on the XX and YY SPs, add the following lines inside the form:
The dbList parameter is documented in the “2.0 Use of MusePeer – Auto-logon and Pass-through mechanisms” chapter from the Muse Web Bridge Communication Interface.pdf document.
The Source Packages installed in a Muse application can be seen in the Muse Administrator Consoles (Muse Console for Customer Support or Muse Console for Applications Administration) as follows:
– login into the Muse Console for Customer Support or Muse Console for Applications Administration console, select the desired application and click on the “Setup and Organize Sources” left menu item;
– the source IDs (dbList values) are in the “ID” column of the sources listing.
Additionally, another parameter could be added: “reuseSession=true” parameter (also documented in the above mentioned chapter) in the HTML form so that the sessions are reused for consecutive usage of the passthrough form from the same end-user. For this add int he form above:
Muse maintains a set of internally recognized index labels or attributes for use in queries. These are recognized within the Muse Query Syntax by the parser on input and stored internally. When a search statement is translated for a particular Source, the internal forms are translated (using a Source-specific Translator) into the actual indices the Source recognizes. This preserves a mapping for all the indices the user is allowed to use to all the indices the particular Source recognizes.
An internal index can be mapped to one or more Source indices. If it is mapped to no Source index and it appears in a search statement then it will use either the default index (almost universally “keyword”) or it produces an “unsupported query” error message for that Source. This behavior is controlled by the designer.
The internal indices can be exposed to users in many different ways, and can be given labels which will be meaningful to users. If an index is not made available through the search interface (human or machine) then it will not be recognized by the parser, and an “unsupported query” error will be returned for that search.
The internal indices are based on the Standard Dublin Core set of bibliographic descriptor fields. Some remain as indices, others are treated as limiters.
Standard Internal Indices
- Keyword
- Title
- Subject
- Creator
Standard Internal Limiters
- Date
- Type
- Language
- Format
Other Indices which are nonstandard and are only available for special use
- Contributor
- Coverage
- Description
- Identifier
- Publisher
- Source
- Relation
- Rights