Configuring a Distributed File Server Worker

Spezielle Verwaltung > Unterstützung von Visualisierung und Publizierung > Configuring the Distributed File Server Worker > Configuring a Distributed File Server Worker

The following sections describe how to convert an existing worker to a Distributed File Server Worker.

Prerequisites for Setting up a Distributed File Server Worker

• A worker must be set up and configured on an empty machine.

• There must be a common file system so that the data can be transferred to and from the DFS Worker from the background method machine.

• The Distributed File Server Worker requires the creation of a dedicated Windchill user account for the exclusive use of the worker. In addition, this user account's Preferred File Server preference must be set to the file server from which the worker retrieves the files.

If a worker has not been set up, configure one before continuing with this configuration. See Configuring the Worker Agent for instructions on configuring a worker.

Perform the following steps to convert a worker into a DFS worker:

Dedicating a Windchill User Account for the Worker

Add the new user to the Site Administrators group.

1. Log in to Windchill as the site administrator.

2. Access Site > Utilities > Participant Administration and create a new user.

3. Access Site > Administrators and add the new user to the Site Administrators table.

4. Log in to Windchill using the new user's credentials.

5. From the Home location

, navigate to Quick Links > My Settings > Preferences > Vaulting and Replication to locate the Preferred File Server preference. Change the Preferred File Server preference to the server from which this worker retrieves its data.

For more information on setting the Preferred File Server preference, see Replication.

Enabling Distributed File Server Worker Functionality

To enable the Distributed File Server Worker functionality, make the following property changes on the Master Site, either with the xconfmanager command, or by manually editing the <Windchill>/site.xconf file, and then propagating the file with xconfmanager -p.

1. Set the property value as follows:

If using the xconfmanager command, set the value as:

xconfmanager -t <Windchill>/codebase/WEB-INF/conf/wvs.properties -s
"distributedcadagent.enabled=true"

If editing the site.xconf file manually, add the value:

2. The property usewcfileserverlookup=true is the argument used to specify a publisher in the publisher's publish.cadconvert property. By enabling this property, the publisher looks up the site name for the content that is being published, and communicate this information to the Worker Agent. The Worker Agent then targets workers configured for this site to process the Publish Job. The following is an example of how to set this property for the PROE Publisher:

If using the xconfmanager command, set the value as:

xconfmanager -t <Windchill>/codebase/WEB-INF/conf/wvs.properties -s "publish.cadconvert.
PROE=com.ptc.wvs.server.publish.CadConvertPROE,useworkerdownload=$(wt.home)$
(wvs.dir.sep)auth.properties,usewcfileserverlookup=true"

If editing the site.xconf file manually, add the value:

3. Open a Windchill shell and propagate the property changes using xconfmanager. Execute the following command:

xconfmanager -p

4. Shut down and restart the servlet engine (e.g., Tomcat) and the Windchill method server.

Set up File Synchronization

The publisher must first be configured to use file synchronization. See File Synchronization for details. When file synchronization is enabled, the property useworkerdownload is set to the location of an authentication file, auth.properties (refer to Step 2 of the previous section). This file must have a default username and password for all the publishers that use file synchronization. The following is the syntax for defining these defaults:

auth=<worker username>:<worker password>

For Distributed File Server Workers, the dedicated worker user account's username and password created previously must be added as a new property in the authentication file auth.properties. This new property includes the site name and authoring application in the following syntax:

auth.<Site Name>.<Authoring Application>=<worker
username>:<worker password>

For example, a Distributed File Server Worker is set up to publish Creo Parametric files that reside on the file server at site "RemoteSiteA". A dedicated Windchill user account "WorkerAUserName" with password "WorkerAPassword" has been set up, with its Preferred File Server preference set to "RemoteSiteA." In this case, the following property would be added to auth.properties:

auth.RemoteSiteA.PROE=WorkerAUserName:WorkerAPassword

Using auth.properties file entries like auth.RemoteSiteA.PROE is only supported in the context of Distributed File Server (DFS) Workers and must not be used for controlling the credentials used for non-DFS workers, for example, for different Authoring Applications.

Setting the Rule to Invoke the Worker

Log in to Windchill as the site administrator and access Site > Utilities > Worker Agent Administration. Edit the existing worker and change the Rule used to invoke the worker to the remote site name. Using the example in the previous section, "RemoteSiteA" is specified as the Rule.

If you want a Distributed File Server Worker to be used for more than one site, add all site names to the rule, each separated by a comma. In the screen below, to create a rule for multiple sites, the “Rule used to invoke Worker” field would appear as “RemoteSiteA,RemoteSiteB,RemoteSiteC”.

Verification

In order to verify that the Distributed File Server Worker is configured properly, publish a file that has been uploaded to the specific file server. When publishing is complete, access WVS Job Monitor and look for a message in the Job Detail pane similar to the following:

Feb 11, 2008 10:20:36 AM:Located worker system1.mycompany.com-
PROE:1 that could process the request

If such a message appears, the Distributed File Server Worker is configured properly. In this case, the Publisher finds the name of the site where the content resides. It then looks for a matching authentication property in auth.properties using the site name and the authoring application. If a match is found, then the site name is communicated to the worker agent. The worker agent looks for a worker with a matching rule that is equal to the site name. When the worker agent finds a match, the preceding message is printed to the log.