Overview
In order to make MultiTerm Server termbases available to WorldServer, the MultiTerm Integration Service must first be installed on the GroupShare server. The MultiTerm Integration Service uses a specific GroupShare user account (usually
sa) to provide a connection to WorldServer. The default port for the MultiTerm Integration Service is TCP port
10007. When WorldServer connects to MultiTerm Server it has all of the permissions that the GroupShare user account has in relation to termbases, and there is no authentication between WorldServer and MultiTerm Server, so any other WorldServer instance connecting to that MultiTerm Server instance will be granted the same permissions.
Basic Configuration
- Install the correct version of MultiTerm Integration Service for your version of GroupShare server by following the instructions in this article. Do not forget to restart the GroupShare services afterwards.
- Log into WorldServer and go to Management -> Linguistic Tool Setup -> MultiTerm Servers -> Add.
- Fill in the details of the GroupShare server and click Save.
- Go to Management -> Linguistic Tool Setup -> Term Database Setup -> Connect, select the server and termbase you want to connect to WorldServer, and then click Save.
Troubleshooting
If you are unable to connect to MultiTerm Server then check the following:
Is the MultiTerm Integration Service listening?
To check this, open a Command Prompt and run the following command (substituting
10007 for the port number MultiTerm Integration Service is listening on).
netstat -a | find "10007"
If the service is listening then you should see output similar to this:
TCP 0.0.0.0:10007 mtserver:0 LISTENING
TCP [::]:10007 mtserver:0 LISTENING
If it is not running then no output will be returned.
Is there a firewall running on the GroupShare server?
If there is a firewall running on the GroupShare server, make sure there is an exception for the incoming TCP port you configured MultiTerm Integration Service to run on.
Is the correct version of MultiTerm Integration Service installed on the GroupShare server?
The correct version must be installed for the integration to work.
Security Considerations
As there is no authentication between WorldServer and MultiTerm Server, you may want to create a new user with a role that has a lower level of access than the
sa user (which is GroupShare's built-in system administrator). You could also consider creating a custom role specifically for that user. As any other WorldServer instance could potentially connect to the MultiTerm Server, you may also consider adding a firewall rule to restrict the IP connecting to the MultiTerm Integration Service's port to that of your WorldServer instance.
Connecting over Internet
The MultiTerm Integration Service was not designed to be used over the internet, nor has it been tested for this purpose. If you intend to use it in this way, you do so at your own risk, and should consider doing the following:
- Configure a custom GroupShare role with the absolute minimum permission level necessary for the functionality you intend to have (e.g. read-only access to termbases if they are not to be updated) and create a new user account that only has this role in the GroupShare root organisation.
- Configure MultiTerm Integration Service to run on a random port rather than the default port.
- Restrict access to the MultiTerm Integration Service's port to the IP of the WorldServer server using firewall rules.
- Bear in mind that traffic is not encrypted between the source and destination so it would potentially be able to be read by any machine on the route.
Including MultiTerm terms in Studio export packages (WSXZ)
The ability to export relevant terms with a WSXZ package depends on their status as viewed from WorldServer. If the status is
Active (Approved), the terms will be visible in the Lookup window in Browser Workbench and will be exported with the WSXZ package.
However, quite often the Multiterm Term Database terms display in status Proposed in WorldServer, although they might be set to Approved in Multiterm. This happens because there is a limited mapping of term status between WorldServer and Multiter. The Multiterm Term statusses that "translates" Multiterm Terms to
Active (Approved) in WorldServer are
admitted and/or
preferred. You can find more details in this
article.
You can still include
Proposed terms from MultiTerm termbases when working with WorldServer export packages (WSXZ files). To do so, you will need to modify the
%WS_CONFIG%\exchange.properties file. If this file does not exist then first copy it from
tomcat\webapps\ws-legacy\WEB-INF\classes\config in the WorldServer application folder. Once the file is present, add/modify the following line:
multiterm.export.proposed.terms = true
Do not forget to restart the
IdiomRun Windows service for the new setting to take effect.
Limitations and Known Issues
Limitations
- The integration is one-way. MultiTerm terms and the termbase itself is read-only in WorldServer so existing terms cannot be modified, and new terms cannot be created from within the application.
- As explained above, the status of most MultiTerm terms appears in WorldServer with Proposed status within WorldServer, and statuses cannot not be changed in the WorldServer UI. Please see this article for an explanation of how the status mappings between MultiTerm termbases and WorldServer work.
Known Issues
Please see the
Reference section below for links to
Related Articles documenting known issues, and possible workarounds.
