Vault Server and Client Concepts

What Is a Vault?

The vault is the repository in which all ENOVIA V5 documents (CATIA V4 models, CATIA V5 documents, text files, html files, cgr files, etc.) are saved.

The use of the vault offers the following advantages:

  • optimized data flow: the flow of data over the network is optimized; documents are not stored in the database because a database is used mainly for querying operations. If the ENOVIA V5 documents were stored in a database, access to the documents in the database would be too complicated, especially in the case of very large documents
  • secured storage: the vault is a set of data repositories (directories on one or more disks) structured and organized like a database and all documents in the vault are secured
  • access by non-ENOVIA applications: access data in a vault is possible by using not only the ENOVIA V5 Life Cycle Applications, but also by using Version 5 applications involved in interoperability.
 

Vault Servers and Clients

The vault is built on a client/server model. On a machine running the ENOVIA VPM Product Editor client, the vault client is also installed: access to the vault server is implemented through the vault client mechanism. The vault client is simply the definition of all the necessary information required by the client machine to contact the vault server, both parts being separately managed.

Access to the vault server from the vault client is resolved as follows: through CORBA, the vault client contacts the vault server which listens (for incoming requests) on the Orbix port specified at installation. The whole point is to set up on the client side an "Alias" that will describe the target to be reached:

  • Orbix service name
  • host name
  • port number.

Zoom On Vault Server/Client Architecture

The vault client is a thin component enabling an application to access the vault, and hides the communication from the application.

The vault client application requires the vault client properties file. The vault client process may run on a separate machine from the vault server, or on the same machine. The vault client application knows how to connect the vault server by reading the properties in the vault client properties file (if needed, it can connect several vault servers simultaneously).

Each vault server must have its own database structures, file repositories and properties file. Vault database setup and  repository management are independent from each other, but are integrated within the same vault setup tool.

Each vault server process may run on a separate workstation, and does not need to be installed on a machine hosting Version 5 code (except of course the vault code). The server can deal with multi-processing and can answer several vault client applications simultaneously. When running, it keeps a set of database connections open in order to improve performance and database access.

Which Objects Are Created?

Setting up a vault client and vault server creates the following objects:

  • the vault database tables
  • the following files:

    XXXVaultServer.properties
    VaultClient.properties
    VaultLocalServerList.properties

    are created, where "XXXVaultServer" is the appropriate name of the vault server (Orbix service name) in:

    install_dir/docs/java

    For example, the default vault server name and resulting file are named: ENOVIAVaultServer.properties

  • the following files:

    ENOVIAVaultServer.imp

    are created with the appropriate name (Orbix service name) in:

    install_dir/startup/orbix/config/Repositories/ImpRep

Standard Vault Server/Client Configuration Example

The following figure illustrates a standard vault installation configuration:

  • VaultClientA is the vault client name, with its corresponding properties file
  • Vault1OrbSrv is the name of the vault server and the Orbix service name, with its corresponding properties file, database and repository.

 

 

 

 


 

How Do I Create a Vault Server and Client?

A vault server can be created on its own without the rest of the ENOVIA V5 VPM software, and can be created without having created an associated vault client previously.

If you installed the Vault Administration configuration, the Vault Server dialog box is displayed instead of the Vault Client Setup dialog box, and contains two tabs:

  • Vault Server
  • Vault Client.

You can create the vault server in a number of ways:

  • from within the installation procedure
  • after installing the ENOVIA V5 VPM code by running a command from the command line to access the vault setup graphic user interface
  • using the corresponding batch tools
  • or manually as explained in Installing the Vault Server Manually.

Note: the vault administration tool does not manage the vault cache.
It is quite possible to install the ENOVIA V5 VPM code in one location, and the Vault Server Administration configuration in another location on the same machine.

You MUST NOT attempt to set up this kind of installation on the same machine. If you need the ENOVIA V5 VPM code and vault server on the same machine, install them both at the same location.
 

More About Vault Architecture

Supported Protocols

Several protocols are supported for document transfer:

  • Corba
  • NFS
  • HTTP.

Multi-user Document Server

Several applications configured as vault clients can simultaneously access documents from the vault server.

Security

The vault server process is the only one that has access to the vault contents.

In the file implementation, vault directories do not need to be mounted on the client workstation (except when using the NFS access or datalink implementation).

Enhanced scalability: Multi-threaded Vault

The vault server has the ability to serve several users at the same time.

The server will work with a pool of pre-allocated threads:

  • performance and scalability are predictable
  • the server will not collapse in case of a temporary large amount of incoming requests
  • the number of threads can be tailored according to the capabilities of the machine

When all the threads are busy, an incoming request is queued.
 

Vault Server Licensing

When the vault server or vault cache is started, a license request for the ENOVIA - Vault Administration (VAR) configuration is transmitted to the LUM license database. Each vault server or vault cache takes one concurrent VAR license. If either fail to get a license, an error message is written to the log file and the operation stops.
 

PCS Considerations

For vault server memory settings on AIX with JVM 1.5 to support a large number of simultaneously connected users, we recommend you set the following options on the java command line in the runENOVVaultServer shell located in:

install_dir/code/command directory:

Java parms (in runENOVVaultServer)
Xmx 1280m
Xms 1280m
Xss 64k
Xmso 64k
Xgcpolicy subpool

So the modified command line looks like:

exec $JAVA_HOME/bin/java -Xmx1280m -Xms1280m -Xss64k -Xmso64k -Xgcpolicy:subpool $JAVA_OPT ...

Moreover, the V5MEM environment variable has to be set to 8:

V5MEM=8