Stores, Sites, and Locations

Stores, Sites, and Locations are an integral part of how the ENOVIA Live Collaboration Server and the FCS work together.

The following topics are discussed:

Stores

A store is a logical view of a storage location for checked-in files. A store typically comprises, among other features, an FCS URL and a storage path (which can be considered to be the default location.) Only FCS manages stores.

To create a new store to replace an existing one, you must change the policies referencing the old store to reference the new one. This ensures that all new files checked into objects governed by the policies are placed in the new store.

With replicated stores, a store can be distributed using asynchronous replication—where data is duplicated to all mirrored locations only when commands are passed telling the database to do so. In this case, when files are checked in, they are written to the store location that is part of the user's preferred site, or if no match is found, to the store's default location. Files are not replicated to alternate locations until specifically told to do so.

A multi-site installation is an ENOVIA V6 deployment containing at least two sites and two locations with replicated stores. See Replication. Store replication makes sense when an ENOVIA V6 deployment spans through network links with low bandwidth or high latency, or both.

Sites

Sites comprise a set of locations. A site is an administrative object that refers to one or more locations. A site can be added to the definition of a person or group object. When associated with a person, the site defines the list of locations preferred by a particular person. When associated with a group, the site defines the list of locations preferred by all members of the group. Only System Administrators can create sites. Sites are needed primarily when using multiple, distributed FCSs for performance purposes, leading to a need for replication. Refer to the Business Modeler Guide or MQL Guide for more information.

Additionally, you can configure a File Collaboration Server to optimize the performance of file checkin and checkout in a replicated environment.

The Preferred Site

When a client machine requests a file checkin/checkout operation, the FCS first determines the preferred site for the client machine based on:

  • The preference set in the user's person or group definition.
  • If not set in the user's person or group definition, the preference set in the user's role definition.

When files are accessed via an ENOVIA Live Collaboration Server, the server's initialization file (enovia.ini) should contain the following to set the preference for all of its users:

MX_SITE_PREFERENCE = SITENAME

where SITENAME is the name of the site object.

The MX_SITE_PREFERENCE is optional and is normally not set. This setting overrides the setting in the person, group, or role definition for the site preference, and should be set to the site local to the server. See "ENOVIA Live Collaboration Server Environment Settings" in the ENOVIA Live Collaboration Server Administration Guide for details on this and other .ini settings.

The Studio Customization Toolkit includes an API that allows implementors to override this setting in specific instances. See the Studio Customization Toolkit Programmer's Reference Guide (JavaDoc) for more information.

Locations

A location references alternate FCSs to be used by a store when distributing and replicating files. The location specifies the URL of an FCS and a storage path.

Think of a location as another store--it is defined as an FTP/NFS or UNC location. The same rules apply as in specifying a store.

Locations contain alternate host, path and FTP information for a captured store. The host, path and FTP information in the store definition is considered to be the default location for the store, while any associated location objects identify alternate file servers.

Each location must have a name unique in the database. The name can be up to 127 characters and can contain spaces. Because names are so flexible, you should assign a name that has meaning to both you and your users.

After you have created locations, assign them to captured stores. Any number of locations can be associated with a captured store. Locations can be shared by multiple stores. However, it is recommended that if one store is hashed, all stores that use any of its locations are also hashed especially if full text search is used.

You can define a protocol for a location as: ftp, ftps, and nfs. If a location does not have a protocol specified, ENOVIA Live Collaboration looks at other object attributes to determine which protocol was intended. If the host is localhost (or empty), the system uses the file (local file system) protocol. If the host is NOT localhost and a username/password is given, then the location uses ftp. If the host is NOT localhost and there is NO username/password, the location uses file.

Synchronization of Stores and Locations

Synchronization of a store using one of its locations is the process of updating the store's files by using the location's files. Synchronization of a location using its store is the process of updating the location's files by using the store's files. Synchronization on demand is a synchronization process that is triggered by an ENOVIA V6 checkout user request. If the user checks out at least one file that is not up to date in their preferred location, this checkout request triggers a synchronization of that preferred location. FCS compressed synchronization can improve FCS server synchronization performance in a WAN environment. For MQL commands to enable and configure compressed synchronization, see the MQL Guide.