Muse Hybrid FAQ
Muse Hybrid
General-
Generate the Service Provider Metadata
Access the administration end point for SAML at an URL of the form:https://your_domain/muse/saml/web/metadatawhere replaceyour_domainwith the actual domain of the Muse installation. Useadminas the username and the configured password. In the Muse SSO Metadata Administration page click on the Generate new service provider button to access the metadata generation page. In the Metadata Generation page, make sure the Signing key and Encryption key values are the proper ones. Fill in an alias value in the Entity alias input. The rest of configurations should be left with the default values. When done click the Generate metadata button. In the Metadata Details page follow the steps listed in section “In order to permanently store the metadata follow these instructions:“. After the restart of the Muse web service, access again the Muse SSO Metadata Administration page, the metadata details for the newly added entity and click the Download entity metadata button to download it. -
Setup a new application in the Azure Portal
Access the Azure Portal at:https://portal.azure.com/and navigate to Azure Active Directory -> Enterprise applications from the menu and click New Application. Add the custom application by accessing Create your own application link and add the name of the application (e.g. Muse Search), making sure the option Integrate any other application you don’t find in the gallery (Non-gallery) is selected. Then chose the application created and select Setup single sign-on from the Manage menu, and then click the “SAML” button to access the configuration guide. In the new page click the Upload metadata file and select the metadata file which was downloaded at the previous step. All necessary values will be loaded in the Basic SAML Configuration, click the Save button to store them. From the Set up Single Sign-On with SAML page, copy the value of App Federation Metadata Url to be used at the next step. Make sure that the necessary user groups and users are configured to access the newly created Azure application. See the below instructions for doing this: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/add-application-portal-assign-users -
Generate a new IDP
Access the Muse SSO Metadata Administration pages (as described at #1) and click the Add new identity provider metadata button. In the Add New IDP Metadata files page, enter the URL copied from the Azure Portal in the Take metadata from URL: input and click the Test IDP metadata button. Next follow the instructions listed in the page to finalize the setup of the new IDP entity. -
Wire the Muse Search Application for SAML authentication
Follow the instruction from below to finalize the setup of SAML authentication with Microsoft Azure AD. – Edit the${MUSE_HOME}/aas/jaas.configfile and add at the end of the file the below entry: MuseKnowledge.Azure { com.edulib.ice.security.authentication.ICELoginModulePropertiesExtractor requisite config="${ICE_HOME}/profiles/ICELoginModulePropertiesExtractor.Azure.xml"; com.edulib.ice.security.authentication.ICELoginModule requisite ; }; – Download this file and place it in the following location${USE_HOME}/profiles/. Edit the downloaded file, locate the following placeholders:PLACE_HERE_THE_IDP_ENTITY_ID,MuseSearchApplicationIDandMuseSearchApplicationPasswordand replace them with the appropriate values. – Test the integration using an URL of the form:https://your_domain/muse/servlet/MusePeer/logon/alias/ALIAS?action=logon&userID=MuseKnowledge.Azure&templateFile=passThrough.html&errorTemplate=logon/logon.html&reuseSession=true&idp=IDP_ENTITY_IDwhere replaceyour_domain,ALIASandIDP_ENTITY_IDwith the appropriate values.
In the $MUSE_HOME/tomcat/docs/Apache Tomcat embedded within Muse.pdf manual, chapter “3.2.1.1 Secured Connections” you can find all details about securing the access to the Muse Embedded Tomcat server using SSL certificates.
Basically you need to generate a keystore from the private key and certificate, and enable it into the Tomcat’s configuration file: $MUSE_HOME/tomcat/conf/server.xml by uncommenting or adding if not already existing the connector:
Make sure the keystore name is correct and its password. Also inbound access on port 443 must be opened in the firewall.
Alternatively, for creating the keystore file, you can use EduLib’s CERTivity® KeyStores Manager tool. Get the free license, download and install it and follow the steps below for creating the keystore:
- File menu –> New KeyStore
File name: keystore
New KeyStore Type: jks
Click on Save. - KeyStore menu –> Import Key Pair
– select PKCS #8
– uncheck Private Key Encrypted
– Private Key File: browse to your (.KEY) private key file
– Certificate(s) File: browse to your (.CRT) certificates file
– then OK
– Alias should remain as suggested –> then OK
– enter pass “changeit” without quotes (as it is default into the${MUSE_HOME}/tomcat/conf/server.xmlfile) –> then OK - File menu –> Save
- KeyStore menu –> Change Keystore Password
– enter pass “changeit” without quotes (as it is configured into the${MUSE_HOME}/tomcat/conf/server.xmlfile) –> then OK - File –> Save
- Rename the resulted file from “keystore.jks” to “keystore” and place it into the
${MUSE_HOME}/tomcat/conf/directory.
The access into the Muse Administration Consoles such as the MCAA (Muse Console for Applications Administration) is secured by IP authentication, besides Username/Password.
The access point for the MCAA console is:
http(s)://your_Muse_host:Port/mmc/
There are 2 methods for adding a new IP as an allowed IP address from where the MCAA console can be accessed:
1. From the MCAA console (reommmended). Login into the MCAA console from an already allowed IP address and follow the below steps:
- Access the Users top menu;
- From the Users page access the left menu item – Muse Authentication and Authorization Users;
- In the new page select the mcaa user (or the desired administrator user from the list) and click the left menu item – Edit Access Rules;
- In the Edit Access Rules pop-up page, click an Insert link corresponding to the last entry from the list;
- For the new item that was added, edit the IP value and add the desired IP address. When done click the Update button.
- Access the Muse server remotely, the access method differs, depending on the Operating System
(RDP/VNC/TeamViewer,etc. for Windows based systems, SSH/VNC, etc. for Linux based systems); - Edit the file
${MUSE_HOME}/aas/hosts.xmlfile. - Locate the
USER_RULEsection corresponding to the mcaa user (or the desired administrator). It should look like:mcaa - Add next to the existing IP rules a new entry as following:
Your_IP_Address
Below are the steps to enable and configure the “IP on campus/personal account off campus” authentication workflow for a MuseKnowledge Application. Note that they apply for versions starting with 7.6.
1) Configure the login modules.
Edit the ${ICE_HOME}/jaas.config file, locate the application entry for which to make the settings
(refered below ad AppID). It should look like below:
AppID {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
};
The entry must be modified to look like below:
AppID {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml" justUser="true";
com.edulib.ice.security.authentication.ICELoginModuleIP sufficient hosts="${ICE_HOME}/profiles/hosts.xml";
com.edulib.ice.security.authentication.ICELoginModulePPMS required xmldbLocation="xmldb:exist:http://admin:@localhost:8000/xmldb/exist/xmlrpc";
};
(the 8000 port must be adjusted accordingly as per the Tomcat’s installation port)
2) Add the allowed IP(s) for the IP authentication
Login into the MCAA console, select the application from the list (AppID) and click on the “Login Modules” left menu. In the login modules listing click the “Edit” link corresponding to the ICELoginModuleXML module. In the new panel click the “Insert” link and start adding the IP(s). Consult the available help details to see the accepted format entries.
3) Make the end-user interface changes
Login into the MCAA console, select the application from the list (AppID) and click on the “Application General Settings->Interface Options” left menu link. In the Branding tab, “Login Page” section, press the “Load remap U/P Form”, then click the Update button from the bottom of the page.
4) Enable the “My Account” functionality
Login into the MCAA console, select the application from the list (AppID) and click on the “Application General Settings->Interface Options” left menu link. In the Functionality tab, locate the My Account” section and enable the “Enable Account:”, “Enable Saved Searches” and “Enable WorkRoom” features.
From this moment the “IP on campus/personal account off campus” authentication workflow should work, the access URL to use is:
http://hostname:port/muse/logon/AppID/autologin.html
For searching IEEE content we provide Source Packages based on API, currently two are available for download in Muse Source Factory:
1) IEEEXploreAPIXML. This is a generic Source Package retrieving content without any filtering.
2) IEEEASPPXploreAPIXML. This is a Source Package specifically built to retrieve content from IEEE All-Society Periodicals Package. More exactly it has pre-configured the following filters:
CONTENT_TYPE=Journals;STARTING_YEAR_PUBLICATION=2010;
To use any of the above SPs you need an API key from IEEE, to get it follow the steps below:
1) Register for an account on the IEEE Developer website: https://developer.ieee.org/
2) Apply for an API key.
Once you have the API key you must configure it through the Muse Console for Applications Administration (MCAA) in the “Custom Parameters” section, as value for the API_KEY parameter.
Follow these steps to backup and recover the database:
1. Login to the server as the user under which Muse runs.
2. Run the ${MUSE_HOME}/xmldb/startConverter tool to backup the database. For example, to dump the database from the server to /tmp/backup directory, you need to run:
- cd ${MUSE_HOME}/xmldb
- ./startConverter -src xmldb:exist:http://admin:@localhost:HTTP_SERVER_PORT/xmldb/exist/xmlrpc -dst file:/tmp/backup -type xml
where replace HTTP_SERVER_PORT with the actual value (8000 default).
Note *: that the “backup” folder is created by the converter tool. Wait for the converter to finish. You may see some errors on screen as it runs. This is normal, as the database is corrupt and some documents from the database won’t be recovered.
Note **: The Local InfoBase maintains local information about the Source Packages installed in the Muse System. Documents that aren’t recovered will be evident in the Consoles as Source Packages in the Console’s Status tab SP list with missing installation date, version, and Test Status information. This information will be restored the next time these Source Packages are updated.
Note ***: if the database is so corrupt that the Converter tool does not even start, please refer to the special note at the end of this question.
3. Stop HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version). Wait for it to finish; verify it is stopped using “ps” command.
4. Backup the previous database location:
- mv $MUSE_HOME/xmldb/db $MUSE_HOME/xmldb/db.TIMESTAMP
- mkdir $MUSE_HOME/xmldb/db
5. Start HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version). Allow a few seconds (5-10) for the servers to start.
6. Restore the database content from the backup you made in step #2 above:
- cd ${MUSE_HOME}/xmldb
- ./startConverter -src file:/tmp/backup -dst xmldb:exist:http://admin:@localhost:8000/xmldb/exist/xmlrpc -type xml
Special note:
If the Converter tool at step #2 above does not start, follow the next steps:
a) Stop HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version).
b) Delete the files matching the *.log and *.lck patterns from ${MUSE_HOME}/xmldb/db. This typically means running the commands:
- rm -f $MUSE_HOME/xmldb/db/*.log
- rm -f $MUSE_HOME/xmldb/db/*.lck
c) Start HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version).
d) Continue with the #2 above.
- mv $MUSE_HOME/xmldb/db $MUSE_HOME/xmldb/db.TIMESTAMP
The eXist XMLDB can get corrupted after an unclean database shutdown. An unclean shutdown may be caused by power failures, OS reboots, or hanging processes that are subsequently killed.
A good improvement was seen after adding the recovery parameter, which configures the journaling and recovery of the database. With recovery enabled, it is much easier to recover an unclean database. For this to work correctly, all database operations must be logged to a journal file.
To add the recovery parameter, one must follow these steps:
a) make a backup for the ${MUSE_HOME}/xmldb/webapps/exist/WEB-INF/conf.xml file;
b) edit the ${MUSE_HOME}/xmldb/webapps/exist/WEB-INF/conf.xml file and just before the ““(no quotes) add the lines from below:
c) Restart Apache Embedded Tomcat server.
The first step to try to resolve this issue is to update the Source(s) in question. If the installation date and status information still does not display after the Source(s) are updated, it is possible that the XML database is corrupted.
Use our backup & restore utility to recover from this problem. This procedure is detailed under the XMLDB category.
The configuration file for setting the SMTP_HOST, SUPPORT_EMAIL (the email address where problems are reported) and other SMTP characteristics such as port, SSL/TLS, username/password, certificates, is $MUSE_HOME/admin/MuseAdmin.xml. A description for each SMTP property can be found in the comments area of the MuseAdmin.xml file and in the “Muse Administrator.pdf” manual.
The email settings from this file are used for sending a Source Problem Report using a Muse Administrator Console, like Muse Console for Applications Administration or Muse Console for Customer Support.
Notes:
- The SMTP_HOST must be configured to relay emails for the Muse server;
- If the SMTP server uses a secure connection (SSL/TLS) you must provide the necessary certificates. If the SMTP certificate is signed by a known Certificate Authority like Verisign for example, which is in the JDK’s keystore, there is no need to provide the certificate anymore;
- If the SMTP requires authentication then you must provide a working username/password too;
- In order for the changes in the $MUSE_HOME/admin/MuseAdmin.xml file to take effect, the Muse HTTP or Muse Embedded Apache Tomcat server (depending on which is available in your Muse version) must be restarted.
The “An error occured when list personal users for application applicationid: Personal Profile Management System will not be used because it could not be initialized. Probably xmldb location is not properly set. [Connection refused]” error is caused by a wrong port setting in MuseAdmin.xml file.
Please check the $MUSE_HOME/admin/MuseAdmin.xml file, locate the
Deleting a Source through the Console deletes all entry points to that Source from the Console. The backup files are not deleted, however, so the way to access the .bak files for the Source is to add the Source to the Application again. The backups will be available through the Backup/Restore tab once the Source is relinked to the Application. Previous settings will be restored to the Source once the Restore process is done. (Please note that your restore is successful even though there is no on-screen confirmation.)
Updating a Source Package installed in a Muse Application or adding a new one make use of the Global InfoBase service. The access to the Global InfoBase service is done with a username/password combination that were assigned to you by MuseGlobal.
The fact that you get “Source package decode error” messages when updating Muse Source Packages in the Muse Administration Console shows that you did not configure in your Muse installation the username/password for accessing the Global Source Factory service.
There are 2 ways for configuring the access details for the Global Source Factory service in a Muse installation:
- At the Muse system level. This means that you configure the username/password for accessing the Global Source Factory service at the system level and all administrative users like mcaa and mccs make use of it. To do this setting edit the ${MUSE_HOME}/factory/SourceFactory.xml file and fill in the GLOBAL_IB_USERand GLOBAL_IB_PASSWORD fields with the username/password that were provided to you by MuseGlobal. You should have there the startersf default restrictive details, just replace them with the ones provided to you. A restart of the Muse Embedded Tomcat server is required for this setting to take effect.
- At the administrative user level. This means that you can configure the username/password for accessing the Global InfoBase service individually, for each Muse Administration user (like mcaa, mccs). The advantage of this configuration is that you can specify different access details for the Global InfoBase service for each Muse Administration user. Another advantage is that the restart of the Muse Embedded Tomcat server is no longer required. Specifying the access details for the Global InfoBase service for a Muse Administration user is done through the Muse Console for Applications Administration interface (mcaa user) as follows:
- login into the Muse Console for Applications Administration interface as the mcaa user.
- go to the Users tab, locate the desired administration user, select it and click on the "Edit Properties" leftmenu item.
- in the "Edit MAB User Properties" panel fill in the "Global InfoBase User Name" and "Global InfoBase User Password" fields with the appropriate values.
- re-login into the Muse Administration Console if the setting was done for the mcaa user or login with the user for which the Global InfoBase details were updated.
Such and error may occur in 2 cases:
A. the username and password used to access the Global InfoBase are not correct and/or
B. the Muse communication with Global InfoBase is not successful.
A. The u/p used to access the Global InfoBase are set for each admin user via Designer console or Muse Console for Applications Administration.
Using Muse Console for Applications Administration (starting with Muse 2300), the Global InfoBase u/p can be changed as following:
– log in Muse Console for Applications Administration,
– go to “Users”,
– select a user and click “Edit Properties”,
– in the window that opens, set the “Global InfoBase User Name” and “Global InfoBase User Password”.
Using Designer Admin console (before Muse 2300), the Global InfoBase u/p can be changed as following:
– log in Designer console,
– go to “Users”,
– click “Muse Admin Bridge” ,
– click “Properties” of the admin user that must be checked,
– in the window that opens, set the “Global InfoBase User Name” and “Global InfoBase User Password”.
B. Unsuccessful communication between Muse and Global InfoBase can be caused by a transparent HTTP proxy between the two. The communication with Global InfoBase is based on XML requests and responses over TCP sockets. Many HTTP proxies cannot handle such XML requests and responses because the communication is not over the HTTP protocol and thus a HTTP proxy cannot handle it, because it tries to understand HTTP headers. Because of that, the message presented to the user is (Global InfoBase error: … Wrong user name or password.) since Muse does not get back a message confirming the successful authentication to Global InfoBase.
The best solution for this case is to give full Internet access to the Muse server or at least to factory.museglobal.com:80. If this is not possible due to special security policies, we recommend the following workarounds:
- if the outgoing communication to port 8005 is not passed through the transparent proxy (and if there is no firewall blocking such requests on client side), change the port in the
$MUSE_HOME/factory/SourceFactory.xmlfrom 80 to 8005 (e.g. enter 8005 as value in the"field)." - switch the communication of the Muse server with SourceFactory on SSL. Even if the traffic passes through proxy, being on SSL, the proxy will not interfere and the communication will stand. To do this, change the port in the
$MUSE_HOME/factory/SourceFactory.xmlfrom 80 to 443 (e.g. enter 443 as value in the"field) and also set"
Note: After such a port change, Muse HTTP server/Apache Tomcat must be restarted.
Not seeing the SPs related data, as status, version, install and build dates, can point an issue with the Local InfoBase.
The most comon issues that have these results are:
1) XMLDB corruption
For more information about this, please see the “How do I perform a backup/restore operation of the XML database?” (1019) FAQ.
2) InfoBase Bridge not started due to a port conflict
Muse InfoBase Bridge is using the 8005 port, so please check the Embedded Apache Tomcat logs to see if there are any entries of the form (which point a conflict):
Address already in use: JVM_Bind:8005
This port can cause a conflict if on the machine there is an external Apache Tomcat (or other software) running and listening on this port. In case of Apache Tomcat, the 8005 port is used for shutdown and it is configured in the $TOMCAT_HOME/conf/server.xml. For other servers, please consult their documentation.
The advice is to change the port of external Apache Tomcat or any other software (not Muse) to something else, eg: 8115, and restart that server and Embedded Apache Tomcat.
The procedure of creating a new admin user is fully described in the “Muse Console for Application Administration.pdf” document, chapter “Administrative Users Setup and Maintenance”.
A particular case of creating a new admin user is if that user must has rights only on one application. Thus, when selecting a grant entry to grant a permission, from the list of available options one must chose “Modify Application”. Having only this grant added, then only one application will be available to be selected for administration. In the list of available applications, the new admin user will only see the selected aplication.
There is a “Forgot your password? Recover it.” feature in the Muse applications. When clicking on it, an email containing the configured password will be sent at the user’s email address. For this feature to work, the email settings configured at the application level must be correct and working.
Also, this feature is accessible from within the application, in other words you must login into the application in order to access the “Forgot your password? Recover it.” feature.
In the case of an application configured with IP authentication for “in Campus” and Personal User for “off Campus” access, the end user can access the “Forgot your password? Recover it.” feature only from in Campus.
There are two ways to set the default result display:
1. At the individual user level: this can be done directly by the end user within the Application when the user is logged into his personal account. Note that setting this preference will not result in a global change for the Application, just for the personal account in which it is configured.
2. At the Application level (as a global change to the Application) by modifying the “displayLevel” setting in the ${APPLICATION_HOME}/www/application/searchOptions.db file. The values that can be set in this parameter are: “oneLine”, “brief” and “full”. For example, if the full display is wanted, the line within the searchOptions.db files should be:
Note that the setting at the Application level is superseded by the setting at the user level.
Yes, multiple email addresses can be specified in the $MUSE_HOME/admin/MuseAdmin.xml file using a semicolon as the delimiter. After modifying the $MUSE_HOME/admin/MuseAdmin.xml file the Muse HTTP server must be restarted.
We strongly recommend using a Muse admin console to do an Application backup instead of creating a copy of the Application’s directory.
The backup/restore feature is available starting Muse 2.2.0.0 and was especially created for such purposes. It backs up an entire Application under the "${MUSE_HOME}/admin/tmp/backup/" directory by creating a file with the name "${APPLICATION_ID}.${timeStamp}.bak" for each backup action.
Multiple Applications can be backed up simultaneously – however, the restore is a “one Application at a time” process. Also, a single Application can be backed up multiple times; upon restore, the user is prompted with all the backups ever made for that Application.
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.
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
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:
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
Muse displays results as they are returned, fastest first, if ranking or sorting are not applied. The “Banded Retrieval” functionality allows you to specify the order of retrieval of Source records in the interface display.
More exactly banded retrieval is the concept of creating groups of sources – e.g. Group A, B and C. For any Search the results display will follow the order of banded retrieval – as in resources under Group A will display first, and the resources from Group B will display second, and the results from Group C will display last. This is often used for placing something that retrieves quickly at a lower ranking so that it is not always the first set of results to display – for example placing Google in Band B or C. Or if you want to always display first the records from the customer’s catalog source place the catalog source in the first defined band – A.
To set up “Priority Retrieval Bands” you have to do the following:
1) define the “Priority Retrieval Bands”. This is accomplished through the MCAA console and it is described in the “Muse Console for Application Administration.pdf” manual, chapter “2.1.1.2.3.30 Organize Sources – Priority Retrieval Bands”.
2) enable the use of the Retrieval Bands. This is also documented in the above mentioned manual in the same chapter; the Ranking feature is documented in chapter “2.1.3.4 Ranking Keys”. Mainly this consists in the following steps:
– add the “ICERankingKeySource” key in the “Ranking Keys Sequence” group from the “Application Modules -> Ranking Keys” section if not already existing. Make sure the “ICERankingKeySource” key is the first key in the “RankingKeysSequence” sequence, if not then move it up position by position until it reaches the first position.
– update the interface from the “Update Interface” button. At this section, for each language available in the application perform the “Update” interface, making sure that the “ICERankingKeySource” and “Banded Retrieval” are checked.
Note that enabling the “Priority Retrieval Bands” may slow down the records display in the interface, this depends on how fast the records are coming from the defined priority bands with the highest priority.
For example if you add in the first defined priority band a source that is retrieving records slower, no records will be displayed in the interface until the highest priority sources retrieve records. This may be falsely perceived by the end user as slow performance.
Without “Priority Retrieval Bands” enabled the Muse records are displayed in the interface as quickly as they are retrieved, the quickest sources records will display first.
There are 2 settings that need to be made in the MCAA console to enable deduplication:
1) Configure the deduplication algorithm. This is done as following:
– login in the MCAA console at your Muse Admin Consoles URL (http://Muse_host:Muse_Port/mmc/)
– select the application from the applications list and click on the left menu
“Application Modules” -> “DeDupe Keys”. The opening page will display the list of
all dedupe keys available and the ones currently installed in the application;
– click on the “Update Interface” button;
– in the “Update Interface” page, for each language available in the Language dropdown
select the ICEKeyTitle title from right in the “Groups” section and click the “Update” button.
2) Configure the default display behavior, whether to show or hide the duplicates:
– login in the MCAA console at your Muse Admin Consoles URL (http://Muse_host:Muse_Port/mmc/)
– select the application from the applications list and click on the left menu
“Application General Settings” -> “Interface Options”;
– Go to the “Search Options” tab and select for the “Display Duplicates:” section either
“Yes” or “No” as desired.
The functioning principle of this authentication scenario is as follows:
– the enduser accesses the provided Muse URL;
– if the enduser’s IP is among the IPs/subnets configured for the desired application then he/she will be successfully logged in;
– if the enduser is not IP authenticated then he/she will be presented with a Muse logon form where to enter the personal LDAP authentication details.
Below are the steps to implement this scenario:
1) configure the necessary Muse login modules for the desired application. Below is their list in order along with the correct flag values:
– ICELoginModuleXML – required;
– ICELoginModuleIP – sufficient;
– ICELoginModuleParametersRemap – required;
– ICELoginModuleLDAP – requisite.
The configuration of the login modules is done through the Muse Console for Applications Administration as follows: select the desired application from the list of application and click on the left menu – “Login Modules”; from this location manage the login modules: add, delete or edit them. The ICELoginModuleParametersRemap login module must have the following attributes and values: ldapUserPwd=”wwwAuthPwd” ldapUserID=”wwwAuthID” (see below).
The context for the desired application in the $ICE_HOME/jaas.config file should look like:
ApplicationID {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP sufficient hosts="${ICE_HOME}/profiles/hosts.xml";
com.edulib.ice.security.authentication.ICELoginModuleParametersRemap required ldapUserPwd="wwwAuthPwd" ldapUserID="wwwAuthID";
com.edulib.ice.security.authentication.ICELoginModuleLDAP requisite config="${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml";
};
2) Configure the login modules’ properties.
– copy ${ICE_HOME}/profiles/ICELoginModuleLDAP.xml to ${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml (is not already existing);
– for the ICELoginModuleIP login module add a new entry in the ${ICE_HOME}/profiles/hosts.xml file for the desired application along with the list of IPs/subnets that will access the application by IP.
– for the ICELoginModuleLDAP login module make the necessary configurations in the ${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml with the access details and settings for the LDAP server. The following fields from the ${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml must be filled in with proper values: LDAP-URL, BASE-DN and USER-AUTHENTICATION.
3) Add the necessary HTML files for the desired application for handling the IP/LDAP authentication scenario:
– an index (index.html) file which will be the access point for the enduser; the role of this is to transparently submit the username and password of the application.
- a page (index2.html) which presents the logon form for the LDAP details in case the IP authentication fails;
- an error (error.html) page which is displayed in case the LDAP authentication fails too.
Note: replace all ApplicationID and ApplicationPassword occurrences with the exact application ID and application password you wish to configure. Also, the html code above is the basic one, with no formatting. Please format it as needed and enclose it in complete/valid html pages.
A new Muse session starts every time you perform a LOGON action through the Bridge. The session is then active until you perform a LOGOFF action or until it times out. You may do multiple SEARCH actions through the Bridge in one LOGON session.
This is explained in the “Adding a new slave machine to the environment” chapter from the “Muse Advanced Configuration.pdf” manual.
In a shared Muse environment all files are shared, including the $ICE_HOME/serial.properties file containing licensing information and necessary for the ICE to start.
When adding new servers to a Muse cluster one cannot just run the Registration process to register the new machine because of the following reason: Muse was not installed on the new machine using the Muse setup kit, hence the InstallShield files necessary for running the Registration do not exist.
In the shared Muse environment the Muse files are loaded/mounted from the master machine.
Below are the steps to be performed when a new slave machine is added into the Muse environment after the initial setup an it needs to be registered:
1. An “Extension Request” procedure for the Serial Number is performed to add all IPv4 and IPv6
IPs of the new machine to the Serial Number in use. In case the Serial Number already contains the IPs of the new machine then there is no need to run the “Extension Request” and the Muse servers can be started on the new machine (step 4).
2. After the extension request is processed by MuseGlobal, the Muse Registration Setup must be run on the master machine.
3 A synchronization of the slave machines with the master must be performed in order for the new serial.properties file to get on the new machine.
4 The Muse servers can now be started on the new machine.
The hosts.xml files are used to allow/deny access to different products from some IPs or classes of IPs. The client’s IP is tested against the rules in the hosts.xml file and the first one that matches is applied – all the following rules are ignored.
When getting the hostname related to a given IP the Java mechanism has a spoof protection that, sometimes, will not give optimal results.
The following situation will not give the expected results:
1. Java asks the DNS server for the hostname related to an IP address (reverse DNS)
2. When the DNS server replies with the hostname, Java asks the same DNS server for the IP address of that particular hostname
3. If the initial IP address and the one returned as the result of request #2 above do not match, then Java returns the initial IP address.
This process may interfere with the way we compare the client IP address against the ones stored in the hosts.xml file. Due to the above Java protection, some IP addresses will not match against a given domain even if their reverse DNS name belongs to that particular domain.
When unistall Muse Proxy 3101 or Muse 2700 (and any interanl 2601,2602, 2603) on a common installation of both of them on some machines the following error is obtained:
Errors occurred during the uninstallation.
com.installshield.product.service.registry.LoggedSoftwareObject cannot be cast to com.installshield.product.ProductBean
This seems to be related to having components with the same UIDs (using two or more Assemblies (in a dynamic installer) where some features and components had the same key (UUID)).
The workaround to solve this problem is:
1) Go to the folder
C:\Program Files\Common Files\InstallShield\Universal\common\Gen1
2) Delete the entire folder named “_vpddb”
3) Restart the uninstallation.
See: [http://cdac.in/index.aspx?id=hi_hs_HL7Tutorial#Uninstallation instructions for SDK for HL7 Java Edition(Windows/Linux/Mac)]
f you get the “bc: command not found” error when running the Muse bin installer, stop the installation and install “bc” package.
The package installation depends on the Linux distribution you are running. Here are some examples:
– RedHat using the yum package manager – run “yum install bc” or
– Debian using the apt package manager – run “apt-get install bc”.
After installing “bc”, relogin to console and rerun the Muse installer.
The Muse Embedded Tomcat is needed because it entirely replaces Muse HTTP Server which was also used for the internal XML protocol and for the XMLDB. The external Tomcat could not have been used for the XML protocols and XMLDB.
If there are no other services than Muse in the External Tomcat then this can be disabled. Muse contexts should be deactivated from there. The Muse Embedded Tomcat will come with its own Muse contexts, thus everything will be ok. Also consider lowering the Java memory for the external Tomcat because Muse servers will not run in it anymore.
If there is an External Tomcat running on the same machine which didn’t have anything in common with the Muse Servers then normally one doesn’t have to worry about the embedded Muse Tomcat server, because this one just takes the place of Muse HTTP Server, and since there were no conflicts between that External Tomcat and Muse HTTP Server there shouldn’t be any here. If it is a fresh install of Muse then the only conflicts are given by port 8005 as described below. This conflict was always present between the Muse HTTP Server and an External Tomcat. But in case there was no service running in that External Tomcat we recommend that is shut down and disabled so that it doesn’t start at boot time.
In the rare event that there is an external Tomcat that is used both for Muse and for other external services and both Muse and the other services contexts are all defined on the same port (e.g. 80) and you don’t want to change the Muse port to another port (e.g. 8000) then the front end Muse Servlets will remain defined and further used in the External Tomcat server and the Muse Embedded Tomcat will be used for what Muse HTTP Server was used, namely for XML protocols and XMLDB.
Regarding the port conflicts there should be none effecting you in normal situation. For rare events, the cases below would help troubleshooting a port conflict in case it would appear.
– The Muse HTTP Server already conflicted with an external Tomcat on port 8005 used for internal XML Muse protocols in Muse and for Shut Down in Tomcat. Hence, because Muse HTTP Server and the external Tomcat co-existed it means that the port value was changed from 8005 on one side or another so that both were running. As the Muse Embedded Tomcat takes the Muse HTTP Server configuration the port 8005 should not be an issue.
– In case the External Tomcat was connected to the Apache Web Server then the AJP ports will conflict and only one Tomcat will be able to run through the Apache Web Server. For this change the AJP 8009 port from the Muse Embedded Tomcat. However note that other changes to the interconnection between Apache Web Server and both Tomcats are necessary in order to differentiate which requests received by the Apache Web Server are redirected to which Tomcat. These are described in the document Muse External Servlets Engine (Tomcat), chapter entitled “Web service adapters for Tomcat”.
– There can be other applications on the same machine conflicting to the External Tomcat. For this a netsat or fuser command can be run on Unix like environments. The Tomcat files were ports are defined are tomcat/conf/server.xml. Check these files both for the External Tomcat and for the Embedded also for the case when one modified in the past the default values of the External Tomcat server.
Typically, this means that the version of the installer you are running does not match your license. For instance, if you downloaded a 2.5.0.0 installer, but you have a 2.6.0.0 license (or vice versa), you will receive this error.
Please download the right Muse version.
If this is not the case then check the copied Serial Number for extra characters due to a faulty copy/paste operation. After copying the Serial Number string please first paste it in a plain text document and check it to make sure it does not contain extra characters at the beginning or at the end of the string.
The procedure to increase the memory for a Muse server installed as a service under Windows is:
a) Stop the service by typing at the command prompt:
– net stop “Muse Proxy Service” (for Muse Proxy) and/or
– net stop “Muse ICE Server” (for Muse ICE) and/or
– net stop “Muse HTTP Server” (for Muse HTTP) or net stop “Embedded Apache Tomcat” (for Apache Tomcat)
or by navigating to Control Panel -> Administrative Tools -> Services and stop whatever is needed.
b) Uninstall the service(s) using the provided script(s):
– “UnInstallMuseProxyService.bat” (available in the %MUSE_HOME%\proxy folder) and/or
– “UnInstallICEService.bat” (available in the %MUSE_HOME%\use\ice folder)and/or
– “UnInstallHTTPService.bat” (available in the %MUSE_HOME%\http folder – if using Muse HTTP Server) or “service.bat remove” (available in the %MUSE_HOME%\tomcat\bin folder – if using Apache Tomcat server)
c1) For Muse before 2500, modify the corresponding “JavaService.jvm” file(s) available in the location(s) above mentioned by changing the following lines (using a text editor):
– Xms64M
– Xmx256M
to whatever memory amount needed. Please consider the available physical memory of the machine ().
c2) If using Apache Tomcat HTTP server (Muse 2500 or newer), all changes described above still hold, except for the Apache Tomcat – the changes must be made in the %MUSE_HOME%\tomcat\bin\configure.bat file, by modifying the TOMCAT_XMS and/or TOMCAT_XMX values.
d) Re-install the service(s) using the provided script(s):
– “InstallMuseProxyService.bat” (available in the %MUSE_HOME%\proxy folder) and/or
– “InstallICEService.bat” (available in the %MUSE_HOME%\use\ice folder) and/or
– “InstallHTTPService.bat” (available in the %MUSE_HOME%\http folder – if using Muse HTTP Server) or “service.bat install” (available in the %MUSE_HOME%\tomcat\bin folder – if using Apache Tomcat server)
e) Start the service(s) by typing at the command prompt:
– net start “Muse Proxy Service” (for Muse Proxy) and/or
– net start “Muse ICE Server” (for Muse ICE) and/or
– net start “Muse HTTP Server” (for Muse HTTP) or net start “Embedded Apache Tomcat” (for Apache Tomcat)
or by navigating to Control Panel -> Administrative Tools -> Services and start whatever is needed.
Note: when editing “JavaService.jvm” like files, one must be aware that each line of the file must end with a “space” and “ENTER” and the last line of it must not have either the “space” nor the “ENTER”.
When one or more new IPs are added to a machine running Muse ICE, ICE will not start again until the Muse product is re-registered. Running the Muse Registration process ensures that all the current IPs of the machine are added to the serial.properties file, which is required for the Muse ICE server to start successfully.
For more details about the Muse Resistration procedure, please see the "$MUSE_HOME/doc/Muse Install.pdf" document, the “Product Registration” and “Running the Muse Registration Setup” chapters.
There are files used by Muse that reside outside of the ${MUSE_HOME} folder. Below is a list of such files along with their location, depending on the Operating System.
1a) The vpd.properties file (before Muse 2104). This is the InstallShield’s installation database. It keeps track of all Muse products installed and it is located under the installing user home directory on non-Windows platforms and in the Windows directory (if the user has write permissions) or in user’s home directory (if the user has no write permissions in the Windows directory).
1b) The InstallShield directory. This is the InstallShield’s installation database. It keeps track of all Muse products installed and it is located under the installing user home directory on non-Windows platforms and in the %HOMEDRIVE%/Program Files/Common Files/ directory or in user’s home directory (if the user has no write permissions in the %HOMEDRIVE%/Program Files/ directory).
2) For running Muse servers as Windows services, each server will be registered to Windows as a regular service (using Windows registry).
2a) Before Muse 2210. The following files refer to Muse Services on non-Windows platforms:
/etc/rc.d/startMuseServices - used to start Muse Services;
/etc/rc.d/rc.muse - used to start/stop/restart Muse Services;
2b) After Muse 2210 (including). The following files refer to Muse Services on non-Windows platforms:
/etc/init.d/muse - used to start/stop/restart Muse Services;
2c) The following files refer to Muse Services on non-Windows platforms. These are symbolic links to /etc/init.d/muse and belong to the service management system on Linux:
/etc/rc3.d/K99Muse - used to stop Muse Services in run level 3;
/etc/rc3.d/S99Muse - used to start Muse Services in run level 3;
/etc/rc4.d/S99Muse - used to start Muse Services in run level 4;
/etc/rc4.d/K99Muse - used to stop Muse Services in run level 4;
/etc/rc5.d/S99Muse - used to start Muse Services in run level 5;
/etc/rc5.d/K99Muse - used to stop Muse Services in run level 5;
Note: the rc[x].d directories could also be located under the /etc/rc.d directory (depending on your Operating System).
3) Temporary files: InstallShield creates a number of temporary files and directories in the user’s temporary directory, necessary for running the Muse Setups. These files are are created and managed by the InstallShield installation software and are not under control of Muse Setups.
4) The options file (options or fields entered by the user when running a Muse Setup will be recorded here for later usage) will be stored by default in the user’s home directory.
5) Files installed in order to create the Desktop or Start Menu shortcuts for GUI interfaces. This is very dependent of the Operating Systems on which Muse is installed.
We suggest that you use the following parameters for the ICE Server as the HTTP Server and Muse Proxy Server do not request many resources and may stay as installed. If you still encounter Out of Memory problems with these servers, we suggest you add or increase the values of the memory parameters.
The –Xmx and –Xms parameters should already be present in the Java command line. It is recommended that both have the same values. Setting -Xmx and -Xms to the same value will avoid heap resizing, the most common cause of OutOfMemory errors. If -Xmx and -Xms have the same value, the JVM will try to allocate all heap memory at startup, exiting with an OutOfMemory error if this memory is not available.
Make sure the system has enough memory to accommodate the Java Virtual Machine and other programs. It is not a good option to choose values larger than the physical memory, because the host operating system will swap a part of the memory, and the speed advantage will be lost due to frequent disk accesses. For example, one may set –Xmx512M –Xms512M. The respective machine should have at least 512Mbytes of physical RAM. It is recommended that you set these values as high as possible, taking into consideration the requirements for the other servers running on that machine – including all the Muse Servers.
For Muse 2500 and newer, the Xmx and Xms memory settings (as well other settings) are set in the configure scripts (configure.bat, configure, configure.csh – depending on the operating system and shell used – Linux), one for each Muse server. Apache Tomcat and Muse Proxy servers have as default values TOMCAT_XMS=128M, TOMCAT_XMX=512M respectively PROXY_XMS=64M, PROXY_XMX=512M now.
For more information please refer to the “Muse Advanced Configuration.pdf”, chapter “Java Virtual Machine enhancements.”
The ports that need to be locally accessible are:
1. 2100 – Muse Z39.50 Bridge
Configuration file: – ${MUSE_HOME}/z3950/MuseZBridge.xml
Note: This port works as a client for the Information Connection Engine (ICE) server, but it is also a server for all the Z39.50 clients connecting to it.
2. 2504 – Muse ICE Server
Configuration file: – ${ICE_HOME}/ICECore.xml
Files that contain references to this port:
${MUSE_HOME}/web/MusePeer.xml;
${MUSE_HOME}/use/tools/ICEClient.xml;
${MUSE_HOME}/z3950/MuseZBridge.properties
Note: This port is also configured in all Muse bridges used for the Muse ICE Server (in either one of the following two files) (${MUSE_HOME}/ and in ${MUSE_HOME}/
3. 2505 – 3000 – Muse ICE Server
Note: This is the control port for the Muse ICE Server. If it is not accessible, the next port is used, and so on. An error is retrieved if none of the ports up to 3000 can be opened.
4. 8001 –8004, 8006 – Custom XML Bridges
Configuration file: – ${MUSE_HOME}/http/conf/contexts.xml or ${MUSE_HOME}/tomcat/conf/server.xml; ${MUSE_HOME}/
5. 8005 – Muse Local Infobase Bridge
Configuration file: – ${MUSE_HOME}/http/conf/contexts.xml or ${MUSE_HOME}/tomcat/conf/server.xml
Files that contain references to this port: ${MUSE_HOME}/factory/SourceFactory.xml
Note: This port acts as a bridge, the communication protocol being XML.
6. 8007 – Muse Admin
Configuration file: ${MUSE_HOME}/http/conf/contexts.xml or ${MUSE_HOME}/tomcat/conf/server.xml
Note: This port handles XML connections.
7. 8010 – Muse HTTP Server
Configuration file: ${MUSE_HOME}/http/MuseHTTPServer.xml or ${MUSE_HOME}/tomcat/conf/server.xml
Note: This is the Muse HTTP Server or Tomcat control port.
Note: If you want to access some of the above Muse services from the Internet or from machines other than localhost, then the port(s) corresponding to the desired service must be open to the machine making the request.
Further information about this can be found in the "$MUSE_HOME/doc/Muse Advanced Configuration.pdf"document, “Server Type Ports Opened by Muse within Local LAN Scope” chapter.
The ports that need to be accessible from the Internet are:
1. 8000 – Apache Tomcat or Muse HTTP Server
Configuration file – ${MUSE_HOME}/tomcat/conf/server.xml or ${MUSE_HOME}/http/conf/contexts.xml
Files that contain references to this port:
- ${MUSE_HOME}/factory/MuseInfoBase.xml
- ${ICE_HOME}/ICECore.xml
- ${ICE_HOME}/jaas.config
- ${MUSE_HOME}/proxy/jaas.config
- ${MUSE_HOME}/web/MusePeer.xml
2. 8443 – Apache Tomcat or Muse HTTP Server
Configuration file – ${MUSE_HOME}/tomcat/conf/server.xml or ${MUSE_HOME}/http/conf/contexts.xml
Files that contain references to this port:
- ${MUSE_HOME}/web/MusePeer.xml
- ${MUSE_HOME}/enrich/MuseEnrichmentService.xml
- ${MUSE_HOME}/enrich/index/index.xml
- ${MUSE_HOME}/z3950/MuseZBridge.properties
3. 9797 – Muse Proxy
Configuration file – ${MUSE_HOME}/proxy/MuseProxy.xml
Files that contain references to this port:
- ${MUSE_HOME}/web/MusePeer.xml;
- ${MUSE_HOME}/enrich/MuseEnrichmentService.xml;
- ${MUSE_HOME}/enrich/index/index.xml;
- ${MUSE_HOME}/z3950/MuseZBridge.properties
Note: Also configured in all Muse bridges that use the MNM: (${MUSE_HOME}/ and in ${MUSE_HOME}/
Note: This is the secured mode of the Muse HTTP server (SSL connections).
Warning: One of the server type ports Muse opens for its components may be occupied by other server programs. One
such example is the Ajp12 connector from Tomcat. See “${MUSE_HOME}/doc/Muse External Servlets Engine (Tomcat).pdf" manual for further reference regarding the ports used by Tomcat.
Warning: If one of the Muse Servers fails to start the user is advised to check the log file for detailed information.
Finding the message below in the log file means that the port is already used by some other Application. When such a
situation occurs a reconfiguration is necessary to change the port used by the respective Muse server or by the already
existing service.
Cannot listen on port
Note: Not all ports are required by all Muse installations. They are required only if the corresponding components are installed. For example, port 9797 is only required if the Muse Proxy is installed.
Note: All server type ports can be remapped. The best way to accomplish this remapping is by using the Muse PostInstall Configuration package, which makes this process simple and ensures that the correct files are updated.
Further information about this can be found in the "$MUSE_HOME/doc/Muse Advanced Configuration.pdf"document, “Server Type Ports Opened by Muse within Internet Scope” chapter.
We unify all the information from all the sources into Unicode using UTF-8, and we pass it from ICE and all of our Bridges as UTF-8 and XML-encoded entities. However, we are not limited to extracting data just from UTF-8 bytes, and we should not extract bytes as UTF-8 when it is not appropriate. All our extraction in Muse is to UTF-8 but from a wide range of encodings (including UTF-8).
We accommodate this large number of encodings, detailed in the documentation, when we extract data; only then is it converted into Unicode (with UTF-8 encoding) on our side.
Muse has the possibility to control the behavior of searches in cases when queries having unsupported limiters are launched. By unsupported limiter, we mean that one wants to search a source for records between 2 dates, even if the native site does not support this (i.e., does not have this option).
The control is done by means of the of the “Stop If Limiter Not Supported” parameter. It is a property of the Search Module and can be set by:
– logging into the MCAA Muse Console;
– selecting the desired application;
– selecting “Application Modules” from the left panel;
– clicking on the “Search Module” link.
The “Stop If Limiter Not Supported:” field appears along with 2 values that can be set:
– “Stop If Limiter Not Supported:” field on YES – if the limiters are not supported, the search will stop and no records will be retrieved;
– “Stop If Limiter Not Supported:” field on NO – if the limiters are not supported the search will bring results (searching by default without any limiter) with the warning “Unsupported limiter(s): …”
Statistics are logged into special log files by Muse. This statistics data is available into the $ICE_HOME/logs/ICECoreStatistics.log files and are available for the following areas of activity:
– User sessions – for gathering overall usage statistics such as number of sessions logged on, length of sessions, IP addresses of sessions, failed login attempts, etc.
– Muse Instructions – for gathering information about the activities within Muse – searches – including queries, databases searched, parameters used. These may be related to logged-on sessions by session id for analysis per user session.
– Muse Modules – more detailed statistics from individual search source or transaction modules including numbers of hits, time taken for query, download and processing time, etc.
– System information – available and used memory.
There is a dedicated monitoring tool in Muse – Muse Statistics Monitor – which extracts the information from the $ICE_HOME/logs/ICECoreStatistics.log files and present various statistics. Note that the Muse Statistics Monitor is a graphical standalone application. Please refer to the documentation of Muse Statistics Monitor for further information – $MUSE_HOME/monitor/doc/Muse Statistics Monitor.pdf.
When using Muse applications, one has the choice to set “strict” or “loose” limits for the searches. With “strict” limits, Muse returns “Unsupported Query” errors if a Source Package which does not support the selected limit is included, while with the “loose” configuration unsupported limits are dropped.
To set one behavior or another, one must login into MCAA > select application > expand "Application Modules" > click "Search Module" > "Stop If Limiter Not Supported" option.
If there is no proxy defined (Proxy Host field) in either the application level or Source Package level, then no proxy will be used, no matter the other proxy related settings (Proxy Port, Proxy PAC also) from either level.
Secondly, if there are proxy settings both at application level and at the Source Package level, then the Source Package ones will have priority over the application level ones.
A Source Package can be added only once in each source group defined in an application. The Source Package name cannot be different – it will have the same name in all the groups it belongs to.
Although ANSI/NISO Z39.50 is a standard for common search and retrieval, it is implemented differently and in different versions by various commercial library catalog software vendors. For this reason MuseGlobal has several vendor/product-specific Source Packages (SPs) all based on the common Z39.50 protocols. These vendor or product-specific SPs are customized to accommodate specific data and query syntaxes maintained by different Z39.50 servers. These Source Packages come with multiple copies so you can use two or more in a single application by simply filling in the necessary profile values for your target server.
In all cases, you should use the Z39.50 Source Package most specific to the vendor or product. For example, to profile a Millennium catalog, you should use the INNOPACZ_0001 Source Package because Millennium and InnoPac both are products with Z39.50 servers from the same vendor. To profile a Voyager catalog, use the Voyager Z39.50 Source Package.
Additionally, there are some specific, but widely known Z39.50 servers. For example, we created the LOCZ (Library of Congress Z39.50 connector) specifically for the Library of Congress’ catalog. So, even though that library currently uses a Voyager catalog system, you should use the more specific LOCZ SP for this catalog.
There is a generic Z39.50 source known simply as Z3950. Generally, this is a “template”. It may work on any given Z39.50 server, but it does not have any specific mapping files for query or data. Even in cases where you get a successful connection or search using this, there may be a data mapping or other problems you are not aware of. This should only be tried if there is not a specific vendor or catalog Z39.50 package available. The better course is to order a new Source Package from MuseGlobal when you need to profile a Z39.50 server which does not already have a working vendor/product-specific SP.
Below is a list of currently available Source Package IDs for commonly used Z39.50 Servers currently available via Source ID in Source Factory:
ALEPH500Z
DynixClassicZ
Horizon73Z
INNOPACZ
SoftlinkZ
UnicornZ
VoyagerZ
VTLSZ
Keep in mind that most of these SPs have several “clones” available in the Source Factory. For example, you’ll find ALEPH500Z_0001, ALEPH500Z_0002, ALEPH500Z_0003, . . . ALEPH500Z_0010. This is in cases where you need to profile more than one catalog using the same Source Package in the same application.
A certificate is a binary file which provides certain information about that site. Such certificates are signed by authorities.
To save a SSL certificate one must follow the below steps:
– using the Internet Explorer browser navigate to site address;
– select File/Properties, and on the General tab select Certificates;
– a window will appear from which select the Details tab;
– in the next step click the Copy to File button (this will open a wizard to be used to export the certificate of the site);
– when prompted for export file format please choose DER encoded binary format;
– specify the name and the location of the certificate to be saved, press Next and then Finish.
This a known/intermittent behavior of some old browsers, like Internet Explorer 6.
By default, Muse HTTP Server closes client sockets as soon as it finishes sending out the response, in order to recycle sockets as soon as possible. However, there are some problems with certain browsers (like IE6) that send data after the socket was closed by the server. Since the socket was already closed by the server, the browser displays the “The page cannot be displayed” error instantly.
To work around this, Muse Http Server was adapted to wait a configurable amount of time after sending all the data back to the browser and before closing the socket. This amount of time is configurable through thesocketCloseDelay parameter for the desired Connector in ${MUSE_HOME}/http/conf/contexts.xml file. The value for socketCloseDelay parameter is specified in milliseconds.
Note: This value represents the time that the server waits before closing down the socket to the client. Setting a too high value for this parameter can degrade performance of the Muse Http Server. In general, this value should never be set higher than 100 milliseconds.
To activate the socket close delay for Muse HTTP Server please follow the next steps:
1. Stop the Muse HTTP Server;
2. Edit the "${MUSE_HOME}/http/conf/contexts.xml" file and add the following line:
after the lines (port 8000 below can be any port that Muse HTTP Server was set to run on):
3. start the Muse HTTP Server.
If the problem still persists, a tunning is necessary till a proper value is found (please consider the note above):
1. Shutdown the Muse HTTP Server;
2. Change the value of the “socketCloseDelay” parameter;
3. Start the Muse HTTP Server;
4. Run new tests.
We now provide generic template Source Packages for NewsBank’s Access World News product, to take full advantage of its flexibility.
*** NOTE: The “America’s Newspapers” database is different than “Access World News”. We already have a dedicated source package for the “America’s Newspapers” database: the NewsBankFTN SP.
The fields that need to be configured via the console for these SPs are:
USER_NAME
USER_PASSWORD
DATABASE_NAME
PROXY_HOST (if applicable)
PROXY_PORT (if applicable)
CUSTOM_PARAMETERS
Please note that are 4 possibilities to configure the NewsBankAWN generic Source Packages:
——————————————————-
1. Search on the entire “Access World News” database:
The NewsBankAWN generic Source Package offers the possibility to search the entire database (the “Access World News” database has the code = AWNB).
*** NOTE: This is equivalent to using the non-generic NewsBankAWN SP.
Example:
http://infoweb.newsbank.com/?p_product=AWNB
Access World News
To search on the entire database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below:
——————————————————-
2. Search the entire “America’s News Magazines” sub-database (the “America’s News Magazines” is a sub-database of the “Access World News” database) :
Example:
http://infoweb.newsbank.com/?p_product=AWNB&d_custom=AMNP
America's News Magazines (AMNP)
Access World News >> America’s News Magazines
To search the entire “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below :
——————————————————-
3. Search the regions and journals desired from the “Access World News” database:
The JOURNALS parameter will be filled with the codes of the needed journals separated with commas (“,”), see for example a few journal codes below:
– The Advertizer (from New South Wales) has the code: ZANA.
– Bath Chronicle – has the code:ZNCAB
– Mail Tribune – has the code: ZMEK, etc.
You can determine the code of a needed publication viewing the source of the page with the list of journals and seeing the value assigned to its corresponding checkbox.
If the JOURNALS parameter is null, the connector will search all the journals available in the subscription.
The REGIONS parameter would contain one or more of the following (separated with commas):
* Continents
– Africa
– Asia
– Australia/Oceania
– Europe/UK
– Middle East
– North America
– South America
* Country name
* State postal code or province name
The REGIONS value corresponds to the d_loc parameter of the URL when browsing NewsBank’s locations hierarchy.
REGIONS Example 1 = North America
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=North America&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 2 = United States
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=United States&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 3 = California
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=CA&d_place=&f_view=src&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
If the REGIONS parameter is left blank the connector will search all regions.
Example of use:
Example:
http://infoweb.newsbank.com/?db=WPIW
Washington Post, The (WPIW)
Access World News – North America » United States » DC
To search the regions and journals desired from the “Access World News” database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that you can search:
– only on one or more regions :
– only on one or more journals :
– on one or more regions and one or more journals at the same time:
——————————————————-
4. Search the desired regions and journals from the “America’s News Magazines” sub-database:
Example:
http://infoweb.newsbank.com/?db=BTKB
Baby Talk (BTKB)
Access World News – North America » United States » Baby Talk
To search the desired regions and journals from the “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values:
Also please note that you can search:
– only on one region :
– only on one or more journals :
– on one region and one or more journals at the same time:
——————————————————-
The message “Global InfoBase error: UnknownHostException:factory.museglobal.com” clearly states that the factory.museglobal.com host cannot be solved by the DNS servers configured on the Muse server.
This is not a Muse problem, but a network/server configuration issue. This may lead to other side efects, like populating the Status values of the Source Packages with “Not working” values.
Why am I obtaining different results in two cosecutive for the same search on same Source Packages?
This a normal behavior considering how Muse works and how different sites on Internet respond to consecutive searches.
A search performed in a Muse application starts at the ICE server level a number of connectors, each working on a native data service. Each such connector, as it searches the native data service and obtains records, sends these records to ICE which further sends records to the Muse application to be displayed.
So, the records come and are displayed in the Muse application www interface in the order in which they are received from the native sites and parsed. From one search to another the native sites might have different speeds of response and also the order in which the connectors are launched and run into execution may differ because they are run in parallel as threads.
Considering this, it is possible that at a second search performed in a Muse application, using the same term and on the same sources, to show records in different order.
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:
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:
The Group ID may contain alphabetic, numeric or underscore characters. The first character in an Group 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.
Note: A Group ID cannot match any Source ID in the same application.
Elsevier does not permit HTTP access to their resources through federated search products. For federated search Elsevier provides specialized APIs for which we have the following Source Packages: ScienceDirectRESTXML, ScienceDirectRESTXMLBooks, ScienceDirectRESTXMLJournals and ScopusRESTXML.
Arrangements with Elsevier for this access must be handled by you (the partner), or by your customer, following the steps below:
Install Procedure:
1. You (the partner) or your customer must contact the Elsevier E-Helpdesk (for APAC: sginfo@elsevier.com) and tell helpdesk that MuseGlobal federated search or API needs to be enabled.
2. Helpdesk will be able to find the customer’s account (based on C* numbers), API key based on name (MuseGlobal) and generate appropriate instTokens.
3. Confirm with the representative that they have enabled the MuseGlobal federated search or API (not a different federated search product).
4. After Elsevier staff has enabled access for the customer, they will report this back to the customer or to you, the vendor, and will disclose the appropriate instTokens to the customer.
5. Using the Muse Source Console, upload appropriate the ScopusRESTXML or the ScienceDirectRESTXML Source Packages, as covered by your subscription.
6. Configure the Source Package(s), making sure to fill the API_KEY, INST_TOKEN parameters from “Custom Parameters:” at bottom of the page with the two instTokens provided by Elsevier. Contact Muse Support if this is not the case.
7. Test the Source Package while in the Console.
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
The MNM entries are set:
A) at individual Source Package level
B) at the Application level
To stop the rewriting for a Source Package, one must:
A) Remove the MNM entries at individual Source Package level
The MNM entries can be removed from the individual Source Package level through the Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button next to the Source Package to be edited
– the value for MNM entered in the “Link URLs” field must be empty
B) Removing additional MNM entries from Application level
The MNM entries can be removed from Application level using Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level in the “Link URLs” field sould be empty, or that particular Source Package moved to the exclude section.
Note*: The MNM entries at the Application level are additional to the ones for individual Source Package level. So for each Source Package the the MNM entries set up for that Source Package plus the MNM entries set up at application level (A + B above) will be used.
Note**: in old Muse systems use for rewriting purposes the settings found in ${MUSE_HOME}/web/Users.properties. This method is obsolete now, so all the entries inside it of the form “application_id.navigationManagerMode” should be set to “none” (application_id.navigationManagerMode=none). This operation must be done after the values set here were merged with the ones from application level (see point B above).
Follow these steps to save the list of licensed Source Packages (SPs):
– Login to Source Factory, then go to “Source Factory” > “Source Packages List”;
– Select “All” from “Per Page” drop down from the top right page. This will take a few minutes while it builds a list of several thousand Source IDs;
– Perform a search using no specific keywords but by selecting “Released” (instead of “All Values”) as your search criteria in the “Production Status” drop down near the bottom of the page. This search will result in a display of released SPs. This will take a few minutes while it builds a list of several thousand Source IDs;
– When the Source Package list is complete go to the top right hand side of the list. A button labeled “Export to CSV” is displayed. Select this option, let the export run, and then format the report as needed
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.
First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See FAQ “Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?”
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?
We unify all the information from all the sources into Unicode using UTF-8, and we pass it from ICE and all of our Bridges as UTF-8 and XML-encoded entities. However, we are not limited to extracting data just from UTF-8 bytes, and we should not extract bytes as UTF-8 when it is not appropriate. All our extraction in Muse is to UTF-8 but from a wide range of encodings (including UTF-8).
We accommodate this large number of encodings, detailed in the documentation, when we extract data; only then is it converted into Unicode (with UTF-8 encoding) on our side.
The MNM entries can be set:
A) at the individual Source Package level
B) additional MNM entries can be set at the Application level
A) Setting MNM entries at the individual Source Package level:
The MNM entries can be set at individual Source Package level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button near the Source Package in the list that is to be edited
– the value for MNM must be entered in the “Link URLs” field
B) Setting additional MNM entries at application level
The MNM entries can be set at the Application level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level must be entered in the “Link URLs” field
Note*: The MNM entries at the Application level are additional to the ones set for individual Source Package level. So for a Source Package the MNM entries set up for that Source Package plus the MNM entries set up at Application level (A + B above) will be used.
Note**: The MNM entries at the Application level are usually used when many sources at the Application level are using a WAM (Web Access Management) software such as ezProxy as this provides a way to add a MNM entry that is to be used by multiple sources. Except in the case of WAM software it is not recommended that MNM entries be set at the Application level.
There are two parameters involved here:
CONNECT_TIME_OUT: specifies the timeout value, in milliseconds, to be used when opening the communication link for each resource (e.g. URL) used by this source.READ_TIME_OUT: specifies the timeout value, in milliseconds, that is involved upon reading on the communication channels.
One can increase the timeout for a given Source Package by increasing the value in the CONNECT_TIME_OUT and READ_TIME_OUT fields (the entry is in milliseconds; 1,000 milliseconds = 1 second). To edit these fields of the source profile one must use the Muse Source Console:
- login into the Muse Source Console
- select the desired application from the list of applications
- go to the “Configure” tab
- click on the “Modify” button for the desired source
- update the “Connect Time Out” and “Read Time Out” inputs with the desired values
- to submit the modifications click on the “Update” button
Note: The values for the “Connect Time Out” and “Read Time Out” fields must be given in milliseconds.
Muse source packages, by default, return only the metadata found in the native source’s list of results. The Ex functionality of a source means that when a search is performed on that source from the Muse interface the information brought back for each record includes information that normally can be found when the link to that record in the native web interface is accessed from the results list.
If this functionality is desired, then the USE_EX_PARSER field from the SP profile must be “yes”(no quotes).
Example:
Please note that even if the source is free and the Ex functionlaity is desired, this field must be filled with “yes”. By default, this field is set to “no”. So such a connector will behave normally if the USE_EX_PARSER field from the profile is missing or has the “no” value, and will have an extended parsing if the USE_EX_PARSER field from the profile has the “yes” value.
You can configure LDAP authentication as a single authentication method. The steps are:
– copy the ${MUSE_HOME}/use/ice/profiles/ICELoginModuleLDAP.xml file into the application which is to be configured, into the ${MUSE_HOME}/home/ApplicationID/profiles/ folder, where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– configure the necessary Muse login modules for the application. Below is their list in the correct order along with the correct flag values:
– ICELoginModuleXML – required;
– ICELoginModuleParametersRemap – required;
– ICELoginModuleLDAP – requisite.
The configuration of the login modules is done through the Muse Console for Applications Administration as follows: select the desired application from the list of applications and click on the left menu – “Login Modules”; from this location manage the login modules: add, delete or edit them. The ICELoginModuleParametersRemap login module must have the following attributes and values: ldapUserPwd=”wwwAuthPwd” ldapUserID=”wwwAuthID” .
– Configure the properties of the ICELoginModuleLDAP login module:
– in the MCAA console select the desired application from the list of applications and click on the left menu – “Login Modules” and in the “Login Modules” panel click on the “Edit” link from next to the ICELoginModuleLDAP entry;
– in the editor page change the value for the “config” field from the default "${ICE_HOME}/profiles/ICELoginModuleLDAP.xml" to
${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml
where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– click the “Update” button;
– click the “Edit Config File” and configure the elements specific to the LDAP server, such as LDAP-URL, BASE-DN…etc.
– Create a login page where the enduser will enter his/hers LDAP credentials to login into the application:
– create a backup copy of the ${MUSE_HOME}/web/www/logon/ApplicationID/index.html file, where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– edit the ${MUSE_HOME}/web/www/logon/ApplicationID/index.html file, locate the line:
with
| User Name: | |
| Password: | |
where replace the 2 ApplicationID occurrences with the exact application ID you wish to configure with LDAP authentication and ApplicationPassword with the right password.
– the access URL for authenticating with LDAP credentials in this application is:
http://MUSE_SERVER:MUSE_PORT/muse/logon/ApplicationID/
where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication
The .cpb file describes the search capabilities of a source. The .pmf is the pre-mapping file that allows administrators to map search/index attributes that apply before the Muse ISR stylesheet is used to format the search for the source (thus “Pre”-mapping).
The .cpb file lists all the search indexes and Boolean operators which are supported by the Source (whatever the actual, native syntax of the attribute). It is also a place where other source capabilities could be added later for easy import into the Muse InfoBase. The search limiter sets are one example.
The .pmf file provides a mapping from one attribute in ISR to one attribute in translator. The .pmf mapping is TO an attribute which is handled into the ISR translator. All of the attributes handled (supported) in the ISR translator have been automatically extracted and recorded into the appropriate section in .cpb file.
By default, the PMF files map unsupported attributes to keyword.
MuseGlobal provides the following method for search and retrieval of EBSCOhost content: EBSCO Integration Toolkit (EIT)
This is a SOAP-based Web Service approach which provides the optimal combination of performance and completeness. You can find the EIT Source Packages by searching in your Muse Console’s “Add Sources” section in the “IDs Containing” field for the term EIT. EIT SPs have Source IDs which start with the string EBSCOEIT.
URLs:
The HTTP Source Packages for EBSCO search on the URL
http://search.ebscohost.com/. The EIT Source Packages use
http://eit.ebscohost.com/Services/SearchService.asmx as the Home URL and Search URL.
AUTHENTICATION:
Authentication for the EBSCOEIT Source Packages is two-fold.
1) Authentication for search and retrieval can done by user/pw (with the USER_NAME and USER_PASSWORD fields of the profile) or IP (with the CUSTOM_PARAMETERS field of the profile).
For search/retrieval authentication by IP, a value must be placed in the CUSTOM_PARAMETERS tag from the EBSCOEIT* source profile. Again, this is used to connect to and search a certain database. Using this IP authentication, you may be authenticated to a number of databases.
Example :
where : IP_ADDRESS=your IP which authenticates to EIT.
Please note that your EBSCO account must be specifically enabled in order to use of EIT. The user/pw used for connecting to http://search.ebscohost.com/ will not work for EIT. Also note that the IP_PROFILE will be either eit or eitws; — this string matches the 3rd section of your 3-part EIT authentication string (ex. s123456.main.eit or s123456.main.eitws). Please check with EBSCO if you are not sure which it is.
2) The aforementioned authentication by IP or user/pw gives us access to the EBSCOEIT API, but it does not provide successful link navigation on the record links obtained.
For this, the PROXY_HOST and PROXY_PORT in the profile must be configured. IMPORTANT: authentication to EBSCO for link navigation is only done by IP.
Example :
So, in conclusion, 2 IP authentication settings are needed: one (user/pw or IP) for accessing and searching the EBSCOEIT database desired and the other one (proxy IP) to successfully navigate on the record links obtained.
Questions about your EIT account status should be referred to Gregory Julien [GregoryJulien@ebscohost.com].
Under $ICE_HOME/, there is a script called “version”. Running this script will allow you to see what version of ICE you are running. The version of the ICE server also tells you the Muse version.
This can be run as a normal script on a Unix based Operating Systems ($ICE_HOME/version) or from a Command Prompt window under Windows Operating Systems (%ICE_HOME%/version.bat).
There is a more comprehensive script in Muse which prints out the version of all installed Muse components and tools called startSystemInformation. This script is available only if the “Muse Admin Bridge” product is licensed. It can be run as a normal script on a Unix based Operating Systems ($USE_HOME/tools/startSystemInformation) or from a Command Prompt window under Windows Operating Systems (%USE_HOME%/tools/startSystemInformation.bat).
Load More
Follow the instructions from bellow for configuring the authentication for the Muse Search Application with Microsoft’s Azure Active Directory, using SAML.
In this scenario, the Muse Search Application is the Service Provider (SP), while Azure AD is the Identity Provider (IDP).
-
Generate the Service Provider Metadata
Access the administration end point for SAML at an URL of the form:
https://your_domain/muse/saml/web/metadata
where replaceyour_domainwith the actual domain of the Muse installation.
Useadminas the username and the configured password.In the Muse SSO Metadata Administration page click on the Generate new service provider button to access the metadata generation page.
In the Metadata Generation page, make sure the Signing key and Encryption key values are the proper ones. Fill in an alias value in the Entity alias input. The rest of configurations should be left with the default values. When done click the Generate metadata button.In the Metadata Details page follow the steps listed in section “In order to permanently store the metadata follow these instructions:“.
After the restart of the Muse web service, access again the Muse SSO Metadata Administration page, the metadata details for the newly added entity and click the Download entity metadata button to download it. -
Setup a new application in the Azure Portal
Access the Azure Portal at:
https://portal.azure.com/and navigate to Azure Active Directory -> Enterprise applications from the menu and click New Application. Add the custom application by accessing Create your own application link and add the name of the application (e.g. Muse Search), making sure the option Integrate any other application you don’t find in the gallery (Non-gallery) is selected. Then chose the application created and select Setup single sign-on from the Manage menu, and then click the “SAML” button to access the configuration guide.In the new page click the Upload metadata file and select the metadata file which was downloaded at the previous step. All necessary values will be loaded in the Basic SAML Configuration, click the Save button to store them.
From the Set up Single Sign-On with SAML page, copy the value of App Federation Metadata Url to be used at the next step.
Make sure that the necessary user groups and users are configured to access the newly created Azure application. See the below instructions for doing this:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/add-application-portal-assign-users -
Generate a new IDP
Access the Muse SSO Metadata Administration pages (as described at #1) and click the Add new identity provider metadata button.
In the Add New IDP Metadata files page, enter the URL copied from the Azure Portal in the Take metadata from URL: input and click the Test IDP metadata button.Next follow the instructions listed in the page to finalize the setup of the new IDP entity.
-
Wire the Muse Search Application for SAML authentication
Follow the instruction from below to finalize the setup of SAML authentication with Microsoft Azure AD.
– Edit the
${MUSE_HOME}/aas/jaas.configfile and add at the end of the file the below entry:
MuseKnowledge.Azure {
com.edulib.ice.security.authentication.ICELoginModulePropertiesExtractor requisite config="${ICE_HOME}/profiles/ICELoginModulePropertiesExtractor.Azure.xml";
com.edulib.ice.security.authentication.ICELoginModule requisite ;
};
– Download this file and place it in the following location${USE_HOME}/profiles/. Edit the downloaded file, locate the following placeholders:PLACE_HERE_THE_IDP_ENTITY_ID,MuseSearchApplicationIDandMuseSearchApplicationPasswordand replace them with the appropriate values.
– Test the integration using an URL of the form:
https://your_domain/muse/servlet/MusePeer/logon/alias/ALIAS?action=logon&userID=MuseKnowledge.Azure&templateFile=passThrough.html&errorTemplate=logon/logon.html&reuseSession=true&idp=IDP_ENTITY_ID
where replaceyour_domain,ALIASandIDP_ENTITY_IDwith the appropriate values.
In the $MUSE_HOME/tomcat/docs/Apache Tomcat embedded within Muse.pdf manual, chapter “3.2.1.1 Secured Connections” you can find all details about securing the access to the Muse Embedded Tomcat server using SSL certificates.
Basically you need to generate a keystore from the private key and certificate, and enable it into the Tomcat’s configuration file: $MUSE_HOME/tomcat/conf/server.xml by uncommenting or adding if not already existing the connector:
Make sure the keystore name is correct and its password. Also inbound access on port 443 must be opened in the firewall.
Alternatively, for creating the keystore file, you can use EduLib’s CERTivity® KeyStores Manager tool. Get the free license, download and install it and follow the steps below for creating the keystore:
- File menu –> New KeyStore
File name: keystore
New KeyStore Type: jks
Click on Save. - KeyStore menu –> Import Key Pair
– select PKCS #8
– uncheck Private Key Encrypted
– Private Key File: browse to your (.KEY) private key file
– Certificate(s) File: browse to your (.CRT) certificates file
– then OK
– Alias should remain as suggested –> then OK
– enter pass “changeit” without quotes (as it is default into the${MUSE_HOME}/tomcat/conf/server.xmlfile) –> then OK - File menu –> Save
- KeyStore menu –> Change Keystore Password
– enter pass “changeit” without quotes (as it is configured into the${MUSE_HOME}/tomcat/conf/server.xmlfile) –> then OK - File –> Save
- Rename the resulted file from “keystore.jks” to “keystore” and place it into the
${MUSE_HOME}/tomcat/conf/directory.
The access into the Muse Administration Consoles such as the MCAA (Muse Console for Applications Administration) is secured by IP authentication, besides Username/Password.
The access point for the MCAA console is:
http(s)://your_Muse_host:Port/mmc/
There are 2 methods for adding a new IP as an allowed IP address from where the MCAA console can be accessed:
1. From the MCAA console (reommmended). Login into the MCAA console from an already allowed IP address and follow the below steps:
- Access the Users top menu;
- From the Users page access the left menu item – Muse Authentication and Authorization Users;
- In the new page select the mcaa user (or the desired administrator user from the list) and click the left menu item – Edit Access Rules;
- In the Edit Access Rules pop-up page, click an Insert link corresponding to the last entry from the list;
- For the new item that was added, edit the IP value and add the desired IP address. When done click the Update button.
- Access the Muse server remotely, the access method differs, depending on the Operating System
(RDP/VNC/TeamViewer,etc. for Windows based systems, SSH/VNC, etc. for Linux based systems); - Edit the file
${MUSE_HOME}/aas/hosts.xmlfile. - Locate the
USER_RULEsection corresponding to the mcaa user (or the desired administrator). It should look like:mcaa - Add next to the existing IP rules a new entry as following:
Your_IP_Address
Below are the steps to enable and configure the “IP on campus/personal account off campus” authentication workflow for a MuseKnowledge Application. Note that they apply for versions starting with 7.6.
1) Configure the login modules.
Edit the ${ICE_HOME}/jaas.config file, locate the application entry for which to make the settings
(refered below ad AppID). It should look like below:
AppID {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
};
The entry must be modified to look like below:
AppID {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml" justUser="true";
com.edulib.ice.security.authentication.ICELoginModuleIP sufficient hosts="${ICE_HOME}/profiles/hosts.xml";
com.edulib.ice.security.authentication.ICELoginModulePPMS required xmldbLocation="xmldb:exist:http://admin:@localhost:8000/xmldb/exist/xmlrpc";
};
(the 8000 port must be adjusted accordingly as per the Tomcat’s installation port)
2) Add the allowed IP(s) for the IP authentication
Login into the MCAA console, select the application from the list (AppID) and click on the “Login Modules” left menu. In the login modules listing click the “Edit” link corresponding to the ICELoginModuleXML module. In the new panel click the “Insert” link and start adding the IP(s). Consult the available help details to see the accepted format entries.
3) Make the end-user interface changes
Login into the MCAA console, select the application from the list (AppID) and click on the “Application General Settings->Interface Options” left menu link. In the Branding tab, “Login Page” section, press the “Load remap U/P Form”, then click the Update button from the bottom of the page.
4) Enable the “My Account” functionality
Login into the MCAA console, select the application from the list (AppID) and click on the “Application General Settings->Interface Options” left menu link. In the Functionality tab, locate the My Account” section and enable the “Enable Account:”, “Enable Saved Searches” and “Enable WorkRoom” features.
From this moment the “IP on campus/personal account off campus” authentication workflow should work, the access URL to use is:
http://hostname:port/muse/logon/AppID/autologin.html
For searching IEEE content we provide Source Packages based on API, currently two are available for download in Muse Source Factory:
1) IEEEXploreAPIXML. This is a generic Source Package retrieving content without any filtering.
2) IEEEASPPXploreAPIXML. This is a Source Package specifically built to retrieve content from IEEE All-Society Periodicals Package. More exactly it has pre-configured the following filters:
CONTENT_TYPE=Journals;STARTING_YEAR_PUBLICATION=2010;
To use any of the above SPs you need an API key from IEEE, to get it follow the steps below:
1) Register for an account on the IEEE Developer website: https://developer.ieee.org/
2) Apply for an API key.
Once you have the API key you must configure it through the Muse Console for Applications Administration (MCAA) in the “Custom Parameters” section, as value for the API_KEY parameter.
Follow these steps to backup and recover the database:
1. Login to the server as the user under which Muse runs.
2. Run the ${MUSE_HOME}/xmldb/startConverter tool to backup the database. For example, to dump the database from the server to /tmp/backup directory, you need to run:
- cd ${MUSE_HOME}/xmldb
- ./startConverter -src xmldb:exist:http://admin:@localhost:HTTP_SERVER_PORT/xmldb/exist/xmlrpc -dst file:/tmp/backup -type xml
where replace HTTP_SERVER_PORT with the actual value (8000 default).
Note *: that the “backup” folder is created by the converter tool. Wait for the converter to finish. You may see some errors on screen as it runs. This is normal, as the database is corrupt and some documents from the database won’t be recovered.
Note **: The Local InfoBase maintains local information about the Source Packages installed in the Muse System. Documents that aren’t recovered will be evident in the Consoles as Source Packages in the Console’s Status tab SP list with missing installation date, version, and Test Status information. This information will be restored the next time these Source Packages are updated.
Note ***: if the database is so corrupt that the Converter tool does not even start, please refer to the special note at the end of this question.
3. Stop HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version). Wait for it to finish; verify it is stopped using “ps” command.
4. Backup the previous database location:
- mv $MUSE_HOME/xmldb/db $MUSE_HOME/xmldb/db.TIMESTAMP
- mkdir $MUSE_HOME/xmldb/db
5. Start HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version). Allow a few seconds (5-10) for the servers to start.
6. Restore the database content from the backup you made in step #2 above:
- cd ${MUSE_HOME}/xmldb
- ./startConverter -src file:/tmp/backup -dst xmldb:exist:http://admin:@localhost:8000/xmldb/exist/xmlrpc -type xml
Special note:
If the Converter tool at step #2 above does not start, follow the next steps:
a) Stop HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version).
b) Delete the files matching the *.log and *.lck patterns from ${MUSE_HOME}/xmldb/db. This typically means running the commands:
- rm -f $MUSE_HOME/xmldb/db/*.log
- rm -f $MUSE_HOME/xmldb/db/*.lck
c) Start HTTP Server (Muse HTTP or Embeded Tomcat, depending on your Muse version).
d) Continue with the #2 above.
- mv $MUSE_HOME/xmldb/db $MUSE_HOME/xmldb/db.TIMESTAMP
The eXist XMLDB can get corrupted after an unclean database shutdown. An unclean shutdown may be caused by power failures, OS reboots, or hanging processes that are subsequently killed.
A good improvement was seen after adding the recovery parameter, which configures the journaling and recovery of the database. With recovery enabled, it is much easier to recover an unclean database. For this to work correctly, all database operations must be logged to a journal file.
To add the recovery parameter, one must follow these steps:
a) make a backup for the ${MUSE_HOME}/xmldb/webapps/exist/WEB-INF/conf.xml file;
b) edit the ${MUSE_HOME}/xmldb/webapps/exist/WEB-INF/conf.xml file and just before the ““(no quotes) add the lines from below:
c) Restart Apache Embedded Tomcat server.
The first step to try to resolve this issue is to update the Source(s) in question. If the installation date and status information still does not display after the Source(s) are updated, it is possible that the XML database is corrupted.
Use our backup & restore utility to recover from this problem. This procedure is detailed under the XMLDB category.
The configuration file for setting the SMTP_HOST, SUPPORT_EMAIL (the email address where problems are reported) and other SMTP characteristics such as port, SSL/TLS, username/password, certificates, is $MUSE_HOME/admin/MuseAdmin.xml. A description for each SMTP property can be found in the comments area of the MuseAdmin.xml file and in the “Muse Administrator.pdf” manual.
The email settings from this file are used for sending a Source Problem Report using a Muse Administrator Console, like Muse Console for Applications Administration or Muse Console for Customer Support.
Notes:
- The SMTP_HOST must be configured to relay emails for the Muse server;
- If the SMTP server uses a secure connection (SSL/TLS) you must provide the necessary certificates. If the SMTP certificate is signed by a known Certificate Authority like Verisign for example, which is in the JDK’s keystore, there is no need to provide the certificate anymore;
- If the SMTP requires authentication then you must provide a working username/password too;
- In order for the changes in the $MUSE_HOME/admin/MuseAdmin.xml file to take effect, the Muse HTTP or Muse Embedded Apache Tomcat server (depending on which is available in your Muse version) must be restarted.
The “An error occured when list personal users for application applicationid: Personal Profile Management System will not be used because it could not be initialized. Probably xmldb location is not properly set. [Connection refused]” error is caused by a wrong port setting in MuseAdmin.xml file.
Please check the $MUSE_HOME/admin/MuseAdmin.xml file, locate the
Deleting a Source through the Console deletes all entry points to that Source from the Console. The backup files are not deleted, however, so the way to access the .bak files for the Source is to add the Source to the Application again. The backups will be available through the Backup/Restore tab once the Source is relinked to the Application. Previous settings will be restored to the Source once the Restore process is done. (Please note that your restore is successful even though there is no on-screen confirmation.)
Updating a Source Package installed in a Muse Application or adding a new one make use of the Global InfoBase service. The access to the Global InfoBase service is done with a username/password combination that were assigned to you by MuseGlobal.
The fact that you get “Source package decode error” messages when updating Muse Source Packages in the Muse Administration Console shows that you did not configure in your Muse installation the username/password for accessing the Global Source Factory service.
There are 2 ways for configuring the access details for the Global Source Factory service in a Muse installation:
- At the Muse system level. This means that you configure the username/password for accessing the Global Source Factory service at the system level and all administrative users like mcaa and mccs make use of it. To do this setting edit the ${MUSE_HOME}/factory/SourceFactory.xml file and fill in the GLOBAL_IB_USERand GLOBAL_IB_PASSWORD fields with the username/password that were provided to you by MuseGlobal. You should have there the startersf default restrictive details, just replace them with the ones provided to you. A restart of the Muse Embedded Tomcat server is required for this setting to take effect.
- At the administrative user level. This means that you can configure the username/password for accessing the Global InfoBase service individually, for each Muse Administration user (like mcaa, mccs). The advantage of this configuration is that you can specify different access details for the Global InfoBase service for each Muse Administration user. Another advantage is that the restart of the Muse Embedded Tomcat server is no longer required. Specifying the access details for the Global InfoBase service for a Muse Administration user is done through the Muse Console for Applications Administration interface (mcaa user) as follows:
- login into the Muse Console for Applications Administration interface as the mcaa user.
- go to the Users tab, locate the desired administration user, select it and click on the "Edit Properties" leftmenu item.
- in the "Edit MAB User Properties" panel fill in the "Global InfoBase User Name" and "Global InfoBase User Password" fields with the appropriate values.
- re-login into the Muse Administration Console if the setting was done for the mcaa user or login with the user for which the Global InfoBase details were updated.
Such and error may occur in 2 cases:
A. the username and password used to access the Global InfoBase are not correct and/or
B. the Muse communication with Global InfoBase is not successful.
A. The u/p used to access the Global InfoBase are set for each admin user via Designer console or Muse Console for Applications Administration.
Using Muse Console for Applications Administration (starting with Muse 2300), the Global InfoBase u/p can be changed as following:
– log in Muse Console for Applications Administration,
– go to “Users”,
– select a user and click “Edit Properties”,
– in the window that opens, set the “Global InfoBase User Name” and “Global InfoBase User Password”.
Using Designer Admin console (before Muse 2300), the Global InfoBase u/p can be changed as following:
– log in Designer console,
– go to “Users”,
– click “Muse Admin Bridge” ,
– click “Properties” of the admin user that must be checked,
– in the window that opens, set the “Global InfoBase User Name” and “Global InfoBase User Password”.
B. Unsuccessful communication between Muse and Global InfoBase can be caused by a transparent HTTP proxy between the two. The communication with Global InfoBase is based on XML requests and responses over TCP sockets. Many HTTP proxies cannot handle such XML requests and responses because the communication is not over the HTTP protocol and thus a HTTP proxy cannot handle it, because it tries to understand HTTP headers. Because of that, the message presented to the user is (Global InfoBase error: … Wrong user name or password.) since Muse does not get back a message confirming the successful authentication to Global InfoBase.
The best solution for this case is to give full Internet access to the Muse server or at least to factory.museglobal.com:80. If this is not possible due to special security policies, we recommend the following workarounds:
- if the outgoing communication to port 8005 is not passed through the transparent proxy (and if there is no firewall blocking such requests on client side), change the port in the
$MUSE_HOME/factory/SourceFactory.xmlfrom 80 to 8005 (e.g. enter 8005 as value in the"field)." - switch the communication of the Muse server with SourceFactory on SSL. Even if the traffic passes through proxy, being on SSL, the proxy will not interfere and the communication will stand. To do this, change the port in the
$MUSE_HOME/factory/SourceFactory.xmlfrom 80 to 443 (e.g. enter 443 as value in the"field) and also set"
Note: After such a port change, Muse HTTP server/Apache Tomcat must be restarted.
Not seeing the SPs related data, as status, version, install and build dates, can point an issue with the Local InfoBase.
The most comon issues that have these results are:
1) XMLDB corruption
For more information about this, please see the “How do I perform a backup/restore operation of the XML database?” (1019) FAQ.
2) InfoBase Bridge not started due to a port conflict
Muse InfoBase Bridge is using the 8005 port, so please check the Embedded Apache Tomcat logs to see if there are any entries of the form (which point a conflict):
Address already in use: JVM_Bind:8005
This port can cause a conflict if on the machine there is an external Apache Tomcat (or other software) running and listening on this port. In case of Apache Tomcat, the 8005 port is used for shutdown and it is configured in the $TOMCAT_HOME/conf/server.xml. For other servers, please consult their documentation.
The advice is to change the port of external Apache Tomcat or any other software (not Muse) to something else, eg: 8115, and restart that server and Embedded Apache Tomcat.
The procedure of creating a new admin user is fully described in the “Muse Console for Application Administration.pdf” document, chapter “Administrative Users Setup and Maintenance”.
A particular case of creating a new admin user is if that user must has rights only on one application. Thus, when selecting a grant entry to grant a permission, from the list of available options one must chose “Modify Application”. Having only this grant added, then only one application will be available to be selected for administration. In the list of available applications, the new admin user will only see the selected aplication.
There is a “Forgot your password? Recover it.” feature in the Muse applications. When clicking on it, an email containing the configured password will be sent at the user’s email address. For this feature to work, the email settings configured at the application level must be correct and working.
Also, this feature is accessible from within the application, in other words you must login into the application in order to access the “Forgot your password? Recover it.” feature.
In the case of an application configured with IP authentication for “in Campus” and Personal User for “off Campus” access, the end user can access the “Forgot your password? Recover it.” feature only from in Campus.
There are two ways to set the default result display:
1. At the individual user level: this can be done directly by the end user within the Application when the user is logged into his personal account. Note that setting this preference will not result in a global change for the Application, just for the personal account in which it is configured.
2. At the Application level (as a global change to the Application) by modifying the “displayLevel” setting in the ${APPLICATION_HOME}/www/application/searchOptions.db file. The values that can be set in this parameter are: “oneLine”, “brief” and “full”. For example, if the full display is wanted, the line within the searchOptions.db files should be:
Note that the setting at the Application level is superseded by the setting at the user level.
Yes, multiple email addresses can be specified in the $MUSE_HOME/admin/MuseAdmin.xml file using a semicolon as the delimiter. After modifying the $MUSE_HOME/admin/MuseAdmin.xml file the Muse HTTP server must be restarted.
We strongly recommend using a Muse admin console to do an Application backup instead of creating a copy of the Application’s directory.
The backup/restore feature is available starting Muse 2.2.0.0 and was especially created for such purposes. It backs up an entire Application under the "${MUSE_HOME}/admin/tmp/backup/" directory by creating a file with the name "${APPLICATION_ID}.${timeStamp}.bak" for each backup action.
Multiple Applications can be backed up simultaneously – however, the restore is a “one Application at a time” process. Also, a single Application can be backed up multiple times; upon restore, the user is prompted with all the backups ever made for that Application.
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.
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
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:
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
Muse displays results as they are returned, fastest first, if ranking or sorting are not applied. The “Banded Retrieval” functionality allows you to specify the order of retrieval of Source records in the interface display.
More exactly banded retrieval is the concept of creating groups of sources – e.g. Group A, B and C. For any Search the results display will follow the order of banded retrieval – as in resources under Group A will display first, and the resources from Group B will display second, and the results from Group C will display last. This is often used for placing something that retrieves quickly at a lower ranking so that it is not always the first set of results to display – for example placing Google in Band B or C. Or if you want to always display first the records from the customer’s catalog source place the catalog source in the first defined band – A.
To set up “Priority Retrieval Bands” you have to do the following:
1) define the “Priority Retrieval Bands”. This is accomplished through the MCAA console and it is described in the “Muse Console for Application Administration.pdf” manual, chapter “2.1.1.2.3.30 Organize Sources – Priority Retrieval Bands”.
2) enable the use of the Retrieval Bands. This is also documented in the above mentioned manual in the same chapter; the Ranking feature is documented in chapter “2.1.3.4 Ranking Keys”. Mainly this consists in the following steps:
– add the “ICERankingKeySource” key in the “Ranking Keys Sequence” group from the “Application Modules -> Ranking Keys” section if not already existing. Make sure the “ICERankingKeySource” key is the first key in the “RankingKeysSequence” sequence, if not then move it up position by position until it reaches the first position.
– update the interface from the “Update Interface” button. At this section, for each language available in the application perform the “Update” interface, making sure that the “ICERankingKeySource” and “Banded Retrieval” are checked.
Note that enabling the “Priority Retrieval Bands” may slow down the records display in the interface, this depends on how fast the records are coming from the defined priority bands with the highest priority.
For example if you add in the first defined priority band a source that is retrieving records slower, no records will be displayed in the interface until the highest priority sources retrieve records. This may be falsely perceived by the end user as slow performance.
Without “Priority Retrieval Bands” enabled the Muse records are displayed in the interface as quickly as they are retrieved, the quickest sources records will display first.
There are 2 settings that need to be made in the MCAA console to enable deduplication:
1) Configure the deduplication algorithm. This is done as following:
– login in the MCAA console at your Muse Admin Consoles URL (http://Muse_host:Muse_Port/mmc/)
– select the application from the applications list and click on the left menu
“Application Modules” -> “DeDupe Keys”. The opening page will display the list of
all dedupe keys available and the ones currently installed in the application;
– click on the “Update Interface” button;
– in the “Update Interface” page, for each language available in the Language dropdown
select the ICEKeyTitle title from right in the “Groups” section and click the “Update” button.
2) Configure the default display behavior, whether to show or hide the duplicates:
– login in the MCAA console at your Muse Admin Consoles URL (http://Muse_host:Muse_Port/mmc/)
– select the application from the applications list and click on the left menu
“Application General Settings” -> “Interface Options”;
– Go to the “Search Options” tab and select for the “Display Duplicates:” section either
“Yes” or “No” as desired.
The functioning principle of this authentication scenario is as follows:
– the enduser accesses the provided Muse URL;
– if the enduser’s IP is among the IPs/subnets configured for the desired application then he/she will be successfully logged in;
– if the enduser is not IP authenticated then he/she will be presented with a Muse logon form where to enter the personal LDAP authentication details.
Below are the steps to implement this scenario:
1) configure the necessary Muse login modules for the desired application. Below is their list in order along with the correct flag values:
– ICELoginModuleXML – required;
– ICELoginModuleIP – sufficient;
– ICELoginModuleParametersRemap – required;
– ICELoginModuleLDAP – requisite.
The configuration of the login modules is done through the Muse Console for Applications Administration as follows: select the desired application from the list of application and click on the left menu – “Login Modules”; from this location manage the login modules: add, delete or edit them. The ICELoginModuleParametersRemap login module must have the following attributes and values: ldapUserPwd=”wwwAuthPwd” ldapUserID=”wwwAuthID” (see below).
The context for the desired application in the $ICE_HOME/jaas.config file should look like:
ApplicationID {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP sufficient hosts="${ICE_HOME}/profiles/hosts.xml";
com.edulib.ice.security.authentication.ICELoginModuleParametersRemap required ldapUserPwd="wwwAuthPwd" ldapUserID="wwwAuthID";
com.edulib.ice.security.authentication.ICELoginModuleLDAP requisite config="${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml";
};
2) Configure the login modules’ properties.
– copy ${ICE_HOME}/profiles/ICELoginModuleLDAP.xml to ${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml (is not already existing);
– for the ICELoginModuleIP login module add a new entry in the ${ICE_HOME}/profiles/hosts.xml file for the desired application along with the list of IPs/subnets that will access the application by IP.
– for the ICELoginModuleLDAP login module make the necessary configurations in the ${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml with the access details and settings for the LDAP server. The following fields from the ${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml must be filled in with proper values: LDAP-URL, BASE-DN and USER-AUTHENTICATION.
3) Add the necessary HTML files for the desired application for handling the IP/LDAP authentication scenario:
– an index (index.html) file which will be the access point for the enduser; the role of this is to transparently submit the username and password of the application.
- a page (index2.html) which presents the logon form for the LDAP details in case the IP authentication fails;
- an error (error.html) page which is displayed in case the LDAP authentication fails too.
Note: replace all ApplicationID and ApplicationPassword occurrences with the exact application ID and application password you wish to configure. Also, the html code above is the basic one, with no formatting. Please format it as needed and enclose it in complete/valid html pages.
A new Muse session starts every time you perform a LOGON action through the Bridge. The session is then active until you perform a LOGOFF action or until it times out. You may do multiple SEARCH actions through the Bridge in one LOGON session.
This is explained in the “Adding a new slave machine to the environment” chapter from the “Muse Advanced Configuration.pdf” manual.
In a shared Muse environment all files are shared, including the $ICE_HOME/serial.properties file containing licensing information and necessary for the ICE to start.
When adding new servers to a Muse cluster one cannot just run the Registration process to register the new machine because of the following reason: Muse was not installed on the new machine using the Muse setup kit, hence the InstallShield files necessary for running the Registration do not exist.
In the shared Muse environment the Muse files are loaded/mounted from the master machine.
Below are the steps to be performed when a new slave machine is added into the Muse environment after the initial setup an it needs to be registered:
1. An “Extension Request” procedure for the Serial Number is performed to add all IPv4 and IPv6
IPs of the new machine to the Serial Number in use. In case the Serial Number already contains the IPs of the new machine then there is no need to run the “Extension Request” and the Muse servers can be started on the new machine (step 4).
2. After the extension request is processed by MuseGlobal, the Muse Registration Setup must be run on the master machine.
3 A synchronization of the slave machines with the master must be performed in order for the new serial.properties file to get on the new machine.
4 The Muse servers can now be started on the new machine.
The hosts.xml files are used to allow/deny access to different products from some IPs or classes of IPs. The client’s IP is tested against the rules in the hosts.xml file and the first one that matches is applied – all the following rules are ignored.
When getting the hostname related to a given IP the Java mechanism has a spoof protection that, sometimes, will not give optimal results.
The following situation will not give the expected results:
1. Java asks the DNS server for the hostname related to an IP address (reverse DNS)
2. When the DNS server replies with the hostname, Java asks the same DNS server for the IP address of that particular hostname
3. If the initial IP address and the one returned as the result of request #2 above do not match, then Java returns the initial IP address.
This process may interfere with the way we compare the client IP address against the ones stored in the hosts.xml file. Due to the above Java protection, some IP addresses will not match against a given domain even if their reverse DNS name belongs to that particular domain.
When unistall Muse Proxy 3101 or Muse 2700 (and any interanl 2601,2602, 2603) on a common installation of both of them on some machines the following error is obtained:
Errors occurred during the uninstallation.
com.installshield.product.service.registry.LoggedSoftwareObject cannot be cast to com.installshield.product.ProductBean
This seems to be related to having components with the same UIDs (using two or more Assemblies (in a dynamic installer) where some features and components had the same key (UUID)).
The workaround to solve this problem is:
1) Go to the folder
C:\Program Files\Common Files\InstallShield\Universal\common\Gen1
2) Delete the entire folder named “_vpddb”
3) Restart the uninstallation.
See: [http://cdac.in/index.aspx?id=hi_hs_HL7Tutorial#Uninstallation instructions for SDK for HL7 Java Edition(Windows/Linux/Mac)]
f you get the “bc: command not found” error when running the Muse bin installer, stop the installation and install “bc” package.
The package installation depends on the Linux distribution you are running. Here are some examples:
– RedHat using the yum package manager – run “yum install bc” or
– Debian using the apt package manager – run “apt-get install bc”.
After installing “bc”, relogin to console and rerun the Muse installer.
The Muse Embedded Tomcat is needed because it entirely replaces Muse HTTP Server which was also used for the internal XML protocol and for the XMLDB. The external Tomcat could not have been used for the XML protocols and XMLDB.
If there are no other services than Muse in the External Tomcat then this can be disabled. Muse contexts should be deactivated from there. The Muse Embedded Tomcat will come with its own Muse contexts, thus everything will be ok. Also consider lowering the Java memory for the external Tomcat because Muse servers will not run in it anymore.
If there is an External Tomcat running on the same machine which didn’t have anything in common with the Muse Servers then normally one doesn’t have to worry about the embedded Muse Tomcat server, because this one just takes the place of Muse HTTP Server, and since there were no conflicts between that External Tomcat and Muse HTTP Server there shouldn’t be any here. If it is a fresh install of Muse then the only conflicts are given by port 8005 as described below. This conflict was always present between the Muse HTTP Server and an External Tomcat. But in case there was no service running in that External Tomcat we recommend that is shut down and disabled so that it doesn’t start at boot time.
In the rare event that there is an external Tomcat that is used both for Muse and for other external services and both Muse and the other services contexts are all defined on the same port (e.g. 80) and you don’t want to change the Muse port to another port (e.g. 8000) then the front end Muse Servlets will remain defined and further used in the External Tomcat server and the Muse Embedded Tomcat will be used for what Muse HTTP Server was used, namely for XML protocols and XMLDB.
Regarding the port conflicts there should be none effecting you in normal situation. For rare events, the cases below would help troubleshooting a port conflict in case it would appear.
– The Muse HTTP Server already conflicted with an external Tomcat on port 8005 used for internal XML Muse protocols in Muse and for Shut Down in Tomcat. Hence, because Muse HTTP Server and the external Tomcat co-existed it means that the port value was changed from 8005 on one side or another so that both were running. As the Muse Embedded Tomcat takes the Muse HTTP Server configuration the port 8005 should not be an issue.
– In case the External Tomcat was connected to the Apache Web Server then the AJP ports will conflict and only one Tomcat will be able to run through the Apache Web Server. For this change the AJP 8009 port from the Muse Embedded Tomcat. However note that other changes to the interconnection between Apache Web Server and both Tomcats are necessary in order to differentiate which requests received by the Apache Web Server are redirected to which Tomcat. These are described in the document Muse External Servlets Engine (Tomcat), chapter entitled “Web service adapters for Tomcat”.
– There can be other applications on the same machine conflicting to the External Tomcat. For this a netsat or fuser command can be run on Unix like environments. The Tomcat files were ports are defined are tomcat/conf/server.xml. Check these files both for the External Tomcat and for the Embedded also for the case when one modified in the past the default values of the External Tomcat server.
Typically, this means that the version of the installer you are running does not match your license. For instance, if you downloaded a 2.5.0.0 installer, but you have a 2.6.0.0 license (or vice versa), you will receive this error.
Please download the right Muse version.
If this is not the case then check the copied Serial Number for extra characters due to a faulty copy/paste operation. After copying the Serial Number string please first paste it in a plain text document and check it to make sure it does not contain extra characters at the beginning or at the end of the string.
The procedure to increase the memory for a Muse server installed as a service under Windows is:
a) Stop the service by typing at the command prompt:
– net stop “Muse Proxy Service” (for Muse Proxy) and/or
– net stop “Muse ICE Server” (for Muse ICE) and/or
– net stop “Muse HTTP Server” (for Muse HTTP) or net stop “Embedded Apache Tomcat” (for Apache Tomcat)
or by navigating to Control Panel -> Administrative Tools -> Services and stop whatever is needed.
b) Uninstall the service(s) using the provided script(s):
– “UnInstallMuseProxyService.bat” (available in the %MUSE_HOME%\proxy folder) and/or
– “UnInstallICEService.bat” (available in the %MUSE_HOME%\use\ice folder)and/or
– “UnInstallHTTPService.bat” (available in the %MUSE_HOME%\http folder – if using Muse HTTP Server) or “service.bat remove” (available in the %MUSE_HOME%\tomcat\bin folder – if using Apache Tomcat server)
c1) For Muse before 2500, modify the corresponding “JavaService.jvm” file(s) available in the location(s) above mentioned by changing the following lines (using a text editor):
– Xms64M
– Xmx256M
to whatever memory amount needed. Please consider the available physical memory of the machine ().
c2) If using Apache Tomcat HTTP server (Muse 2500 or newer), all changes described above still hold, except for the Apache Tomcat – the changes must be made in the %MUSE_HOME%\tomcat\bin\configure.bat file, by modifying the TOMCAT_XMS and/or TOMCAT_XMX values.
d) Re-install the service(s) using the provided script(s):
– “InstallMuseProxyService.bat” (available in the %MUSE_HOME%\proxy folder) and/or
– “InstallICEService.bat” (available in the %MUSE_HOME%\use\ice folder) and/or
– “InstallHTTPService.bat” (available in the %MUSE_HOME%\http folder – if using Muse HTTP Server) or “service.bat install” (available in the %MUSE_HOME%\tomcat\bin folder – if using Apache Tomcat server)
e) Start the service(s) by typing at the command prompt:
– net start “Muse Proxy Service” (for Muse Proxy) and/or
– net start “Muse ICE Server” (for Muse ICE) and/or
– net start “Muse HTTP Server” (for Muse HTTP) or net start “Embedded Apache Tomcat” (for Apache Tomcat)
or by navigating to Control Panel -> Administrative Tools -> Services and start whatever is needed.
Note: when editing “JavaService.jvm” like files, one must be aware that each line of the file must end with a “space” and “ENTER” and the last line of it must not have either the “space” nor the “ENTER”.
When one or more new IPs are added to a machine running Muse ICE, ICE will not start again until the Muse product is re-registered. Running the Muse Registration process ensures that all the current IPs of the machine are added to the serial.properties file, which is required for the Muse ICE server to start successfully.
For more details about the Muse Resistration procedure, please see the "$MUSE_HOME/doc/Muse Install.pdf" document, the “Product Registration” and “Running the Muse Registration Setup” chapters.
There are files used by Muse that reside outside of the ${MUSE_HOME} folder. Below is a list of such files along with their location, depending on the Operating System.
1a) The vpd.properties file (before Muse 2104). This is the InstallShield’s installation database. It keeps track of all Muse products installed and it is located under the installing user home directory on non-Windows platforms and in the Windows directory (if the user has write permissions) or in user’s home directory (if the user has no write permissions in the Windows directory).
1b) The InstallShield directory. This is the InstallShield’s installation database. It keeps track of all Muse products installed and it is located under the installing user home directory on non-Windows platforms and in the %HOMEDRIVE%/Program Files/Common Files/ directory or in user’s home directory (if the user has no write permissions in the %HOMEDRIVE%/Program Files/ directory).
2) For running Muse servers as Windows services, each server will be registered to Windows as a regular service (using Windows registry).
2a) Before Muse 2210. The following files refer to Muse Services on non-Windows platforms:
/etc/rc.d/startMuseServices - used to start Muse Services;
/etc/rc.d/rc.muse - used to start/stop/restart Muse Services;
2b) After Muse 2210 (including). The following files refer to Muse Services on non-Windows platforms:
/etc/init.d/muse - used to start/stop/restart Muse Services;
2c) The following files refer to Muse Services on non-Windows platforms. These are symbolic links to /etc/init.d/muse and belong to the service management system on Linux:
/etc/rc3.d/K99Muse - used to stop Muse Services in run level 3;
/etc/rc3.d/S99Muse - used to start Muse Services in run level 3;
/etc/rc4.d/S99Muse - used to start Muse Services in run level 4;
/etc/rc4.d/K99Muse - used to stop Muse Services in run level 4;
/etc/rc5.d/S99Muse - used to start Muse Services in run level 5;
/etc/rc5.d/K99Muse - used to stop Muse Services in run level 5;
Note: the rc[x].d directories could also be located under the /etc/rc.d directory (depending on your Operating System).
3) Temporary files: InstallShield creates a number of temporary files and directories in the user’s temporary directory, necessary for running the Muse Setups. These files are are created and managed by the InstallShield installation software and are not under control of Muse Setups.
4) The options file (options or fields entered by the user when running a Muse Setup will be recorded here for later usage) will be stored by default in the user’s home directory.
5) Files installed in order to create the Desktop or Start Menu shortcuts for GUI interfaces. This is very dependent of the Operating Systems on which Muse is installed.
We suggest that you use the following parameters for the ICE Server as the HTTP Server and Muse Proxy Server do not request many resources and may stay as installed. If you still encounter Out of Memory problems with these servers, we suggest you add or increase the values of the memory parameters.
The –Xmx and –Xms parameters should already be present in the Java command line. It is recommended that both have the same values. Setting -Xmx and -Xms to the same value will avoid heap resizing, the most common cause of OutOfMemory errors. If -Xmx and -Xms have the same value, the JVM will try to allocate all heap memory at startup, exiting with an OutOfMemory error if this memory is not available.
Make sure the system has enough memory to accommodate the Java Virtual Machine and other programs. It is not a good option to choose values larger than the physical memory, because the host operating system will swap a part of the memory, and the speed advantage will be lost due to frequent disk accesses. For example, one may set –Xmx512M –Xms512M. The respective machine should have at least 512Mbytes of physical RAM. It is recommended that you set these values as high as possible, taking into consideration the requirements for the other servers running on that machine – including all the Muse Servers.
For Muse 2500 and newer, the Xmx and Xms memory settings (as well other settings) are set in the configure scripts (configure.bat, configure, configure.csh – depending on the operating system and shell used – Linux), one for each Muse server. Apache Tomcat and Muse Proxy servers have as default values TOMCAT_XMS=128M, TOMCAT_XMX=512M respectively PROXY_XMS=64M, PROXY_XMX=512M now.
For more information please refer to the “Muse Advanced Configuration.pdf”, chapter “Java Virtual Machine enhancements.”
The ports that need to be locally accessible are:
1. 2100 – Muse Z39.50 Bridge
Configuration file: – ${MUSE_HOME}/z3950/MuseZBridge.xml
Note: This port works as a client for the Information Connection Engine (ICE) server, but it is also a server for all the Z39.50 clients connecting to it.
2. 2504 – Muse ICE Server
Configuration file: – ${ICE_HOME}/ICECore.xml
Files that contain references to this port:
${MUSE_HOME}/web/MusePeer.xml;
${MUSE_HOME}/use/tools/ICEClient.xml;
${MUSE_HOME}/z3950/MuseZBridge.properties
Note: This port is also configured in all Muse bridges used for the Muse ICE Server (in either one of the following two files) (${MUSE_HOME}/ and in ${MUSE_HOME}/
3. 2505 – 3000 – Muse ICE Server
Note: This is the control port for the Muse ICE Server. If it is not accessible, the next port is used, and so on. An error is retrieved if none of the ports up to 3000 can be opened.
4. 8001 –8004, 8006 – Custom XML Bridges
Configuration file: – ${MUSE_HOME}/http/conf/contexts.xml or ${MUSE_HOME}/tomcat/conf/server.xml; ${MUSE_HOME}/
5. 8005 – Muse Local Infobase Bridge
Configuration file: – ${MUSE_HOME}/http/conf/contexts.xml or ${MUSE_HOME}/tomcat/conf/server.xml
Files that contain references to this port: ${MUSE_HOME}/factory/SourceFactory.xml
Note: This port acts as a bridge, the communication protocol being XML.
6. 8007 – Muse Admin
Configuration file: ${MUSE_HOME}/http/conf/contexts.xml or ${MUSE_HOME}/tomcat/conf/server.xml
Note: This port handles XML connections.
7. 8010 – Muse HTTP Server
Configuration file: ${MUSE_HOME}/http/MuseHTTPServer.xml or ${MUSE_HOME}/tomcat/conf/server.xml
Note: This is the Muse HTTP Server or Tomcat control port.
Note: If you want to access some of the above Muse services from the Internet or from machines other than localhost, then the port(s) corresponding to the desired service must be open to the machine making the request.
Further information about this can be found in the "$MUSE_HOME/doc/Muse Advanced Configuration.pdf"document, “Server Type Ports Opened by Muse within Local LAN Scope” chapter.
The ports that need to be accessible from the Internet are:
1. 8000 – Apache Tomcat or Muse HTTP Server
Configuration file – ${MUSE_HOME}/tomcat/conf/server.xml or ${MUSE_HOME}/http/conf/contexts.xml
Files that contain references to this port:
- ${MUSE_HOME}/factory/MuseInfoBase.xml
- ${ICE_HOME}/ICECore.xml
- ${ICE_HOME}/jaas.config
- ${MUSE_HOME}/proxy/jaas.config
- ${MUSE_HOME}/web/MusePeer.xml
2. 8443 – Apache Tomcat or Muse HTTP Server
Configuration file – ${MUSE_HOME}/tomcat/conf/server.xml or ${MUSE_HOME}/http/conf/contexts.xml
Files that contain references to this port:
- ${MUSE_HOME}/web/MusePeer.xml
- ${MUSE_HOME}/enrich/MuseEnrichmentService.xml
- ${MUSE_HOME}/enrich/index/index.xml
- ${MUSE_HOME}/z3950/MuseZBridge.properties
3. 9797 – Muse Proxy
Configuration file – ${MUSE_HOME}/proxy/MuseProxy.xml
Files that contain references to this port:
- ${MUSE_HOME}/web/MusePeer.xml;
- ${MUSE_HOME}/enrich/MuseEnrichmentService.xml;
- ${MUSE_HOME}/enrich/index/index.xml;
- ${MUSE_HOME}/z3950/MuseZBridge.properties
Note: Also configured in all Muse bridges that use the MNM: (${MUSE_HOME}/ and in ${MUSE_HOME}/
Note: This is the secured mode of the Muse HTTP server (SSL connections).
Warning: One of the server type ports Muse opens for its components may be occupied by other server programs. One
such example is the Ajp12 connector from Tomcat. See “${MUSE_HOME}/doc/Muse External Servlets Engine (Tomcat).pdf" manual for further reference regarding the ports used by Tomcat.
Warning: If one of the Muse Servers fails to start the user is advised to check the log file for detailed information.
Finding the message below in the log file means that the port is already used by some other Application. When such a
situation occurs a reconfiguration is necessary to change the port used by the respective Muse server or by the already
existing service.
Cannot listen on port
Note: Not all ports are required by all Muse installations. They are required only if the corresponding components are installed. For example, port 9797 is only required if the Muse Proxy is installed.
Note: All server type ports can be remapped. The best way to accomplish this remapping is by using the Muse PostInstall Configuration package, which makes this process simple and ensures that the correct files are updated.
Further information about this can be found in the "$MUSE_HOME/doc/Muse Advanced Configuration.pdf"document, “Server Type Ports Opened by Muse within Internet Scope” chapter.
We unify all the information from all the sources into Unicode using UTF-8, and we pass it from ICE and all of our Bridges as UTF-8 and XML-encoded entities. However, we are not limited to extracting data just from UTF-8 bytes, and we should not extract bytes as UTF-8 when it is not appropriate. All our extraction in Muse is to UTF-8 but from a wide range of encodings (including UTF-8).
We accommodate this large number of encodings, detailed in the documentation, when we extract data; only then is it converted into Unicode (with UTF-8 encoding) on our side.
Muse has the possibility to control the behavior of searches in cases when queries having unsupported limiters are launched. By unsupported limiter, we mean that one wants to search a source for records between 2 dates, even if the native site does not support this (i.e., does not have this option).
The control is done by means of the of the “Stop If Limiter Not Supported” parameter. It is a property of the Search Module and can be set by:
– logging into the MCAA Muse Console;
– selecting the desired application;
– selecting “Application Modules” from the left panel;
– clicking on the “Search Module” link.
The “Stop If Limiter Not Supported:” field appears along with 2 values that can be set:
– “Stop If Limiter Not Supported:” field on YES – if the limiters are not supported, the search will stop and no records will be retrieved;
– “Stop If Limiter Not Supported:” field on NO – if the limiters are not supported the search will bring results (searching by default without any limiter) with the warning “Unsupported limiter(s): …”
Statistics are logged into special log files by Muse. This statistics data is available into the $ICE_HOME/logs/ICECoreStatistics.log files and are available for the following areas of activity:
– User sessions – for gathering overall usage statistics such as number of sessions logged on, length of sessions, IP addresses of sessions, failed login attempts, etc.
– Muse Instructions – for gathering information about the activities within Muse – searches – including queries, databases searched, parameters used. These may be related to logged-on sessions by session id for analysis per user session.
– Muse Modules – more detailed statistics from individual search source or transaction modules including numbers of hits, time taken for query, download and processing time, etc.
– System information – available and used memory.
There is a dedicated monitoring tool in Muse – Muse Statistics Monitor – which extracts the information from the $ICE_HOME/logs/ICECoreStatistics.log files and present various statistics. Note that the Muse Statistics Monitor is a graphical standalone application. Please refer to the documentation of Muse Statistics Monitor for further information – $MUSE_HOME/monitor/doc/Muse Statistics Monitor.pdf.
When using Muse applications, one has the choice to set “strict” or “loose” limits for the searches. With “strict” limits, Muse returns “Unsupported Query” errors if a Source Package which does not support the selected limit is included, while with the “loose” configuration unsupported limits are dropped.
To set one behavior or another, one must login into MCAA > select application > expand "Application Modules" > click "Search Module" > "Stop If Limiter Not Supported" option.
If there is no proxy defined (Proxy Host field) in either the application level or Source Package level, then no proxy will be used, no matter the other proxy related settings (Proxy Port, Proxy PAC also) from either level.
Secondly, if there are proxy settings both at application level and at the Source Package level, then the Source Package ones will have priority over the application level ones.
A Source Package can be added only once in each source group defined in an application. The Source Package name cannot be different – it will have the same name in all the groups it belongs to.
Although ANSI/NISO Z39.50 is a standard for common search and retrieval, it is implemented differently and in different versions by various commercial library catalog software vendors. For this reason MuseGlobal has several vendor/product-specific Source Packages (SPs) all based on the common Z39.50 protocols. These vendor or product-specific SPs are customized to accommodate specific data and query syntaxes maintained by different Z39.50 servers. These Source Packages come with multiple copies so you can use two or more in a single application by simply filling in the necessary profile values for your target server.
In all cases, you should use the Z39.50 Source Package most specific to the vendor or product. For example, to profile a Millennium catalog, you should use the INNOPACZ_0001 Source Package because Millennium and InnoPac both are products with Z39.50 servers from the same vendor. To profile a Voyager catalog, use the Voyager Z39.50 Source Package.
Additionally, there are some specific, but widely known Z39.50 servers. For example, we created the LOCZ (Library of Congress Z39.50 connector) specifically for the Library of Congress’ catalog. So, even though that library currently uses a Voyager catalog system, you should use the more specific LOCZ SP for this catalog.
There is a generic Z39.50 source known simply as Z3950. Generally, this is a “template”. It may work on any given Z39.50 server, but it does not have any specific mapping files for query or data. Even in cases where you get a successful connection or search using this, there may be a data mapping or other problems you are not aware of. This should only be tried if there is not a specific vendor or catalog Z39.50 package available. The better course is to order a new Source Package from MuseGlobal when you need to profile a Z39.50 server which does not already have a working vendor/product-specific SP.
Below is a list of currently available Source Package IDs for commonly used Z39.50 Servers currently available via Source ID in Source Factory:
ALEPH500Z
DynixClassicZ
Horizon73Z
INNOPACZ
SoftlinkZ
UnicornZ
VoyagerZ
VTLSZ
Keep in mind that most of these SPs have several “clones” available in the Source Factory. For example, you’ll find ALEPH500Z_0001, ALEPH500Z_0002, ALEPH500Z_0003, . . . ALEPH500Z_0010. This is in cases where you need to profile more than one catalog using the same Source Package in the same application.
A certificate is a binary file which provides certain information about that site. Such certificates are signed by authorities.
To save a SSL certificate one must follow the below steps:
– using the Internet Explorer browser navigate to site address;
– select File/Properties, and on the General tab select Certificates;
– a window will appear from which select the Details tab;
– in the next step click the Copy to File button (this will open a wizard to be used to export the certificate of the site);
– when prompted for export file format please choose DER encoded binary format;
– specify the name and the location of the certificate to be saved, press Next and then Finish.
This a known/intermittent behavior of some old browsers, like Internet Explorer 6.
By default, Muse HTTP Server closes client sockets as soon as it finishes sending out the response, in order to recycle sockets as soon as possible. However, there are some problems with certain browsers (like IE6) that send data after the socket was closed by the server. Since the socket was already closed by the server, the browser displays the “The page cannot be displayed” error instantly.
To work around this, Muse Http Server was adapted to wait a configurable amount of time after sending all the data back to the browser and before closing the socket. This amount of time is configurable through thesocketCloseDelay parameter for the desired Connector in ${MUSE_HOME}/http/conf/contexts.xml file. The value for socketCloseDelay parameter is specified in milliseconds.
Note: This value represents the time that the server waits before closing down the socket to the client. Setting a too high value for this parameter can degrade performance of the Muse Http Server. In general, this value should never be set higher than 100 milliseconds.
To activate the socket close delay for Muse HTTP Server please follow the next steps:
1. Stop the Muse HTTP Server;
2. Edit the "${MUSE_HOME}/http/conf/contexts.xml" file and add the following line:
after the lines (port 8000 below can be any port that Muse HTTP Server was set to run on):
3. start the Muse HTTP Server.
If the problem still persists, a tunning is necessary till a proper value is found (please consider the note above):
1. Shutdown the Muse HTTP Server;
2. Change the value of the “socketCloseDelay” parameter;
3. Start the Muse HTTP Server;
4. Run new tests.
We now provide generic template Source Packages for NewsBank’s Access World News product, to take full advantage of its flexibility.
*** NOTE: The “America’s Newspapers” database is different than “Access World News”. We already have a dedicated source package for the “America’s Newspapers” database: the NewsBankFTN SP.
The fields that need to be configured via the console for these SPs are:
USER_NAME
USER_PASSWORD
DATABASE_NAME
PROXY_HOST (if applicable)
PROXY_PORT (if applicable)
CUSTOM_PARAMETERS
Please note that are 4 possibilities to configure the NewsBankAWN generic Source Packages:
——————————————————-
1. Search on the entire “Access World News” database:
The NewsBankAWN generic Source Package offers the possibility to search the entire database (the “Access World News” database has the code = AWNB).
*** NOTE: This is equivalent to using the non-generic NewsBankAWN SP.
Example:
http://infoweb.newsbank.com/?p_product=AWNB
Access World News
To search on the entire database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below:
——————————————————-
2. Search the entire “America’s News Magazines” sub-database (the “America’s News Magazines” is a sub-database of the “Access World News” database) :
Example:
http://infoweb.newsbank.com/?p_product=AWNB&d_custom=AMNP
America's News Magazines (AMNP)
Access World News >> America’s News Magazines
To search the entire “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that the CUSTOM_PARAMETERS tag should have empty parameters as you can see below :
——————————————————-
3. Search the regions and journals desired from the “Access World News” database:
The JOURNALS parameter will be filled with the codes of the needed journals separated with commas (“,”), see for example a few journal codes below:
– The Advertizer (from New South Wales) has the code: ZANA.
– Bath Chronicle – has the code:ZNCAB
– Mail Tribune – has the code: ZMEK, etc.
You can determine the code of a needed publication viewing the source of the page with the list of journals and seeing the value assigned to its corresponding checkbox.
If the JOURNALS parameter is null, the connector will search all the journals available in the subscription.
The REGIONS parameter would contain one or more of the following (separated with commas):
* Continents
– Africa
– Asia
– Australia/Oceania
– Europe/UK
– Middle East
– North America
– South America
* Country name
* State postal code or province name
The REGIONS value corresponds to the d_loc parameter of the URL when browsing NewsBank’s locations hierarchy.
REGIONS Example 1 = North America
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=North America&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 2 = United States
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=United States&d_place=&f_view=loc&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
REGIONS Example 3 = California
NATIVE URL = http://infoweb.newsbank.com/iw-search/we/InfoWeb?p_product=AWNB&p_theme=aggregated5&p_action=explore&d_loc=CA&d_place=&f_view=src&d_selLoc=&d_selSrc=
PROFILE EXCERPT =
If the REGIONS parameter is left blank the connector will search all regions.
Example of use:
Example:
http://infoweb.newsbank.com/?db=WPIW
Washington Post, The (WPIW)
Access World News – North America » United States » DC
To search the regions and journals desired from the “Access World News” database you should have configured the NewsBankAWN generic profile with the following tag values :
Also please note that you can search:
– only on one or more regions :
– only on one or more journals :
– on one or more regions and one or more journals at the same time:
——————————————————-
4. Search the desired regions and journals from the “America’s News Magazines” sub-database:
Example:
http://infoweb.newsbank.com/?db=BTKB
Baby Talk (BTKB)
Access World News – North America » United States » Baby Talk
To search the desired regions and journals from the “America’s News Magazines” sub-database you should have configured the NewsBankAWN generic profile with the following tag values:
Also please note that you can search:
– only on one region :
– only on one or more journals :
– on one region and one or more journals at the same time:
——————————————————-
The message “Global InfoBase error: UnknownHostException:factory.museglobal.com” clearly states that the factory.museglobal.com host cannot be solved by the DNS servers configured on the Muse server.
This is not a Muse problem, but a network/server configuration issue. This may lead to other side efects, like populating the Status values of the Source Packages with “Not working” values.
Why am I obtaining different results in two cosecutive for the same search on same Source Packages?
This a normal behavior considering how Muse works and how different sites on Internet respond to consecutive searches.
A search performed in a Muse application starts at the ICE server level a number of connectors, each working on a native data service. Each such connector, as it searches the native data service and obtains records, sends these records to ICE which further sends records to the Muse application to be displayed.
So, the records come and are displayed in the Muse application www interface in the order in which they are received from the native sites and parsed. From one search to another the native sites might have different speeds of response and also the order in which the connectors are launched and run into execution may differ because they are run in parallel as threads.
Considering this, it is possible that at a second search performed in a Muse application, using the same term and on the same sources, to show records in different order.
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:
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:
The Group ID may contain alphabetic, numeric or underscore characters. The first character in an Group 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.
Note: A Group ID cannot match any Source ID in the same application.
Elsevier does not permit HTTP access to their resources through federated search products. For federated search Elsevier provides specialized APIs for which we have the following Source Packages: ScienceDirectRESTXML, ScienceDirectRESTXMLBooks, ScienceDirectRESTXMLJournals and ScopusRESTXML.
Arrangements with Elsevier for this access must be handled by you (the partner), or by your customer, following the steps below:
Install Procedure:
1. You (the partner) or your customer must contact the Elsevier E-Helpdesk (for APAC: sginfo@elsevier.com) and tell helpdesk that MuseGlobal federated search or API needs to be enabled.
2. Helpdesk will be able to find the customer’s account (based on C* numbers), API key based on name (MuseGlobal) and generate appropriate instTokens.
3. Confirm with the representative that they have enabled the MuseGlobal federated search or API (not a different federated search product).
4. After Elsevier staff has enabled access for the customer, they will report this back to the customer or to you, the vendor, and will disclose the appropriate instTokens to the customer.
5. Using the Muse Source Console, upload appropriate the ScopusRESTXML or the ScienceDirectRESTXML Source Packages, as covered by your subscription.
6. Configure the Source Package(s), making sure to fill the API_KEY, INST_TOKEN parameters from “Custom Parameters:” at bottom of the page with the two instTokens provided by Elsevier. Contact Muse Support if this is not the case.
7. Test the Source Package while in the Console.
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
The MNM entries are set:
A) at individual Source Package level
B) at the Application level
To stop the rewriting for a Source Package, one must:
A) Remove the MNM entries at individual Source Package level
The MNM entries can be removed from the individual Source Package level through the Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button next to the Source Package to be edited
– the value for MNM entered in the “Link URLs” field must be empty
B) Removing additional MNM entries from Application level
The MNM entries can be removed from Application level using Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level in the “Link URLs” field sould be empty, or that particular Source Package moved to the exclude section.
Note*: The MNM entries at the Application level are additional to the ones for individual Source Package level. So for each Source Package the the MNM entries set up for that Source Package plus the MNM entries set up at application level (A + B above) will be used.
Note**: in old Muse systems use for rewriting purposes the settings found in ${MUSE_HOME}/web/Users.properties. This method is obsolete now, so all the entries inside it of the form “application_id.navigationManagerMode” should be set to “none” (application_id.navigationManagerMode=none). This operation must be done after the values set here were merged with the ones from application level (see point B above).
Follow these steps to save the list of licensed Source Packages (SPs):
– Login to Source Factory, then go to “Source Factory” > “Source Packages List”;
– Select “All” from “Per Page” drop down from the top right page. This will take a few minutes while it builds a list of several thousand Source IDs;
– Perform a search using no specific keywords but by selecting “Released” (instead of “All Values”) as your search criteria in the “Production Status” drop down near the bottom of the page. This search will result in a display of released SPs. This will take a few minutes while it builds a list of several thousand Source IDs;
– When the Source Package list is complete go to the top right hand side of the list. A button labeled “Export to CSV” is displayed. Select this option, let the export run, and then format the report as needed
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.
First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See FAQ “Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?”
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?
We unify all the information from all the sources into Unicode using UTF-8, and we pass it from ICE and all of our Bridges as UTF-8 and XML-encoded entities. However, we are not limited to extracting data just from UTF-8 bytes, and we should not extract bytes as UTF-8 when it is not appropriate. All our extraction in Muse is to UTF-8 but from a wide range of encodings (including UTF-8).
We accommodate this large number of encodings, detailed in the documentation, when we extract data; only then is it converted into Unicode (with UTF-8 encoding) on our side.
The MNM entries can be set:
A) at the individual Source Package level
B) additional MNM entries can be set at the Application level
A) Setting MNM entries at the individual Source Package level:
The MNM entries can be set at individual Source Package level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button near the Source Package in the list that is to be edited
– the value for MNM must be entered in the “Link URLs” field
B) Setting additional MNM entries at application level
The MNM entries can be set at the Application level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level must be entered in the “Link URLs” field
Note*: The MNM entries at the Application level are additional to the ones set for individual Source Package level. So for a Source Package the MNM entries set up for that Source Package plus the MNM entries set up at Application level (A + B above) will be used.
Note**: The MNM entries at the Application level are usually used when many sources at the Application level are using a WAM (Web Access Management) software such as ezProxy as this provides a way to add a MNM entry that is to be used by multiple sources. Except in the case of WAM software it is not recommended that MNM entries be set at the Application level.
There are two parameters involved here:
CONNECT_TIME_OUT: specifies the timeout value, in milliseconds, to be used when opening the communication link for each resource (e.g. URL) used by this source.READ_TIME_OUT: specifies the timeout value, in milliseconds, that is involved upon reading on the communication channels.
One can increase the timeout for a given Source Package by increasing the value in the CONNECT_TIME_OUT and READ_TIME_OUT fields (the entry is in milliseconds; 1,000 milliseconds = 1 second). To edit these fields of the source profile one must use the Muse Source Console:
- login into the Muse Source Console
- select the desired application from the list of applications
- go to the “Configure” tab
- click on the “Modify” button for the desired source
- update the “Connect Time Out” and “Read Time Out” inputs with the desired values
- to submit the modifications click on the “Update” button
Note: The values for the “Connect Time Out” and “Read Time Out” fields must be given in milliseconds.
Muse source packages, by default, return only the metadata found in the native source’s list of results. The Ex functionality of a source means that when a search is performed on that source from the Muse interface the information brought back for each record includes information that normally can be found when the link to that record in the native web interface is accessed from the results list.
If this functionality is desired, then the USE_EX_PARSER field from the SP profile must be “yes”(no quotes).
Example:
Please note that even if the source is free and the Ex functionlaity is desired, this field must be filled with “yes”. By default, this field is set to “no”. So such a connector will behave normally if the USE_EX_PARSER field from the profile is missing or has the “no” value, and will have an extended parsing if the USE_EX_PARSER field from the profile has the “yes” value.
You can configure LDAP authentication as a single authentication method. The steps are:
– copy the ${MUSE_HOME}/use/ice/profiles/ICELoginModuleLDAP.xml file into the application which is to be configured, into the ${MUSE_HOME}/home/ApplicationID/profiles/ folder, where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– configure the necessary Muse login modules for the application. Below is their list in the correct order along with the correct flag values:
– ICELoginModuleXML – required;
– ICELoginModuleParametersRemap – required;
– ICELoginModuleLDAP – requisite.
The configuration of the login modules is done through the Muse Console for Applications Administration as follows: select the desired application from the list of applications and click on the left menu – “Login Modules”; from this location manage the login modules: add, delete or edit them. The ICELoginModuleParametersRemap login module must have the following attributes and values: ldapUserPwd=”wwwAuthPwd” ldapUserID=”wwwAuthID” .
– Configure the properties of the ICELoginModuleLDAP login module:
– in the MCAA console select the desired application from the list of applications and click on the left menu – “Login Modules” and in the “Login Modules” panel click on the “Edit” link from next to the ICELoginModuleLDAP entry;
– in the editor page change the value for the “config” field from the default "${ICE_HOME}/profiles/ICELoginModuleLDAP.xml" to
${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml
where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– click the “Update” button;
– click the “Edit Config File” and configure the elements specific to the LDAP server, such as LDAP-URL, BASE-DN…etc.
– Create a login page where the enduser will enter his/hers LDAP credentials to login into the application:
– create a backup copy of the ${MUSE_HOME}/web/www/logon/ApplicationID/index.html file, where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– edit the ${MUSE_HOME}/web/www/logon/ApplicationID/index.html file, locate the line:
with
| User Name: | |
| Password: | |
where replace the 2 ApplicationID occurrences with the exact application ID you wish to configure with LDAP authentication and ApplicationPassword with the right password.
– the access URL for authenticating with LDAP credentials in this application is:
http://MUSE_SERVER:MUSE_PORT/muse/logon/ApplicationID/
where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication
The .cpb file describes the search capabilities of a source. The .pmf is the pre-mapping file that allows administrators to map search/index attributes that apply before the Muse ISR stylesheet is used to format the search for the source (thus “Pre”-mapping).
The .cpb file lists all the search indexes and Boolean operators which are supported by the Source (whatever the actual, native syntax of the attribute). It is also a place where other source capabilities could be added later for easy import into the Muse InfoBase. The search limiter sets are one example.
The .pmf file provides a mapping from one attribute in ISR to one attribute in translator. The .pmf mapping is TO an attribute which is handled into the ISR translator. All of the attributes handled (supported) in the ISR translator have been automatically extracted and recorded into the appropriate section in .cpb file.
By default, the PMF files map unsupported attributes to keyword.
MuseGlobal provides the following method for search and retrieval of EBSCOhost content: EBSCO Integration Toolkit (EIT)
This is a SOAP-based Web Service approach which provides the optimal combination of performance and completeness. You can find the EIT Source Packages by searching in your Muse Console’s “Add Sources” section in the “IDs Containing” field for the term EIT. EIT SPs have Source IDs which start with the string EBSCOEIT.
URLs:
The HTTP Source Packages for EBSCO search on the URL
http://search.ebscohost.com/. The EIT Source Packages use
http://eit.ebscohost.com/Services/SearchService.asmx as the Home URL and Search URL.
AUTHENTICATION:
Authentication for the EBSCOEIT Source Packages is two-fold.
1) Authentication for search and retrieval can done by user/pw (with the USER_NAME and USER_PASSWORD fields of the profile) or IP (with the CUSTOM_PARAMETERS field of the profile).
For search/retrieval authentication by IP, a value must be placed in the CUSTOM_PARAMETERS tag from the EBSCOEIT* source profile. Again, this is used to connect to and search a certain database. Using this IP authentication, you may be authenticated to a number of databases.
Example :
where : IP_ADDRESS=your IP which authenticates to EIT.
Please note that your EBSCO account must be specifically enabled in order to use of EIT. The user/pw used for connecting to http://search.ebscohost.com/ will not work for EIT. Also note that the IP_PROFILE will be either eit or eitws; — this string matches the 3rd section of your 3-part EIT authentication string (ex. s123456.main.eit or s123456.main.eitws). Please check with EBSCO if you are not sure which it is.
2) The aforementioned authentication by IP or user/pw gives us access to the EBSCOEIT API, but it does not provide successful link navigation on the record links obtained.
For this, the PROXY_HOST and PROXY_PORT in the profile must be configured. IMPORTANT: authentication to EBSCO for link navigation is only done by IP.
Example :
So, in conclusion, 2 IP authentication settings are needed: one (user/pw or IP) for accessing and searching the EBSCOEIT database desired and the other one (proxy IP) to successfully navigate on the record links obtained.
Questions about your EIT account status should be referred to Gregory Julien [GregoryJulien@ebscohost.com].
Under $ICE_HOME/, there is a script called “version”. Running this script will allow you to see what version of ICE you are running. The version of the ICE server also tells you the Muse version.
This can be run as a normal script on a Unix based Operating Systems ($ICE_HOME/version) or from a Command Prompt window under Windows Operating Systems (%ICE_HOME%/version.bat).
There is a more comprehensive script in Muse which prints out the version of all installed Muse components and tools called startSystemInformation. This script is available only if the “Muse Admin Bridge” product is licensed. It can be run as a normal script on a Unix based Operating Systems ($USE_HOME/tools/startSystemInformation) or from a Command Prompt window under Windows Operating Systems (%USE_HOME%/tools/startSystemInformation.bat).