6.2. Specifying General Server Settings

Engineering Knowledge Manager

Administration Guide | Chapter 6: Configuring EKM Server Settings |

6.1. Schema Definition for an EKM Server |  | 6.3. Optional Settings
Prev |  | Next

## 6.2. Specifying General Server Settings

General server settings are mandatory settings that are used to specify global policies in EKM. You can edit server settings by editing the ekm.xml located in the `EKM_HOME/conf` folder.

General server settings include:

- `ekmUrl`

- `defaultDomain`

- `defaultRootUser`

- `retentionPolicy`

- `modules`

- `localprocess`

- `remoteProcess`

- `cache`

- `scheduledTasks`

- `pluginRegistry`

- `superUser`

- `cluster`

- `memoryLimits`

- `email`

- `customResourcesPath`

- `fileTransferService`

### Specifying the URL of the EKM Server (<ekmUrl>)

The value of `ekmUrl` must be set to the URL of the EKM server. If a front-end web server is used, the value should be set to the URL of the front-end web server.

This setting is used in certain situations. For example, when the EKM server sends an automatic email such as those generated during a process execution or lifecycle signoff, it uses the `ekmUrl` setting to create HTML links to objects that are referenced in the emails. This setting is also used for the data management process that manages a user’s server data and connects it to EKM. See The Data Management Process for details. If this setting is incorrectly specified the data management process will fail to launch.

Figure 6.2: Sample Value for ekmUrl

    <ekmUrl>http://webserver.yourdomain.com</ekmUrl>

### Specifying the Default Workspace (<defaultDomain>)

When the EKM server starts up, it will automatically create the default workspace specified in this setting if one does not exist. This is the workspace that all users will be signed in to by default when they sign in to EKM.

Figure 6.3: Default Value for defaultDomain Setting

    <defaultDomain>Default</defaultDomain>

Note: If you are changing the default workspace to another existing workspace, ensure that user accounts exist for users in that workspace (see Adding and Modifying Users), or that automatic account creation is enabled for that workspace (see Automatic Creation of User Accounts). Otherwise, users will not be able to sign in to it. In this case EKM will then attempt to sign users in to another workspace in which automatic account creation is enabled, or in which user accounts exist for them.

### Specifying the Default Root User (<defaultRootUser>)

When the EKM server starts up, it will automatically create a user account for the user that was specified as the Designated Root User during installation. This user will have `Shared` access. The Root User is the primary administrator for all workspaces defined in EKM, and the only user who can make restricted configuration changes.

You can change the default Root User by specifying the EKM user name of another user as defined by their OS or LDAP account. This is case-sensitive. See How User Logins Work in the EKM Installation Guide to see how EKM user names are defined.

Figure 6.4: defaultRootUser Setting

    <defaultRootUser>ekmadmin</defaultRootUser>

Note:

- When changing the Root User to an existing EKM user who currently has `Analyst` or `Basic` access, that user's access level will be automatically changed to `Shared` in his or her profile.

- You can override the `defaultRootUser` setting for a specific workspace by editing the WorkspaceConfig.xml file. For details see Designating a Root User for a Workspace.

Once the Root User has been changed, and the server has been restarted, the previous EKM user will no longer be treated as the Root User, but their account will still exist.

### Specifying the Object Retention Policy (<retentionPolicy>)

EKM uses a bundled content management system for managing files and metadata. The `repository` setting in ekm.xml can be used to configure the `retentionPolicy` setting.

The `retentionPolicy` setting specifies the global default expiration time (in days) for those objects that are marked as perishable in EKM. It can also be used to specify the default expiration time on a per-type basis. Figure 6.5: Default Values for retentionPolicy Setting shows the default values for this setting. You will seldom need to change this value.

In the listing, the default expiration time for any perishable object is `365` days. For objects of type `File` or `Folder`, the expiration time is `1825` days (or 5 years). For an `Audit Log`, the default expiration time is `30` days. For a `Job` object it is `30` days, and for a `Data Extraction Monitor` object it is `7` days. Jobs are not marked as perishable until they have finished executing.

Figure 6.5: Default Values for retentionPolicy Setting

        <repository>
            <retentionPolicy>
                <defaultExpiration>365</defaultExpiration>
                <customRetentionSetting>
                    <objectType>AuditLog</objectType>
                    <expiration>30</expiration>
                </customRetentionSetting>
                <customRetentionSetting>
                    <objectType>File</objectType>
                    <expiration>1825</expiration>
                </customRetentionSetting>
                <customRetentionSetting>
                    <objectType>Folder</objectType>
                    <expiration>1825</expiration>
                </customRetentionSetting>
                <customRetentionSetting>
                    <objectType>Job</objectType>
                    <expiration>30</expiration>
                </customRetentionSetting>
                <customRetentionSetting>
                    <objectType>DataExtractionMonitor</objectType>
                    <expiration>7</expiration>
                </customRetentionSetting>
            </retentionPolicy>
        </repository>

Note: The retention setting for `Job` objects does not apply to jobs submitted to EKM from Workbench. Such jobs expire when they are released by RSM, as detected by the scheduled batchJobMonitor task.

For more information about how these types of jobs are handled, see Submitting Jobs to EKM from Workbench in the EKM User’s Guide.

### Configuring Modules (<modules>)

The `modules` setting configures modules that provide groupings of functionality. The default value for this setting is shown below.

Figure 6.6: Default Value for modules Setting

    <modules>
            <module name="ekmServer" enabled="true"/>
    </modules>

When defining a module you need to specify a `module name`, and specify whether or not the module is enabled by entering either a `true` or `false` value. `ekmServer` is the only module that is defined, and it should be enabled.

### Specifying Local Process Policies (<localProcess>)

The `localprocess` setting specifies policies for executing a predefined set of external applications directly on the EKM server that perform metadata and report extraction on simulation files. The default values for this setting are shown below.

Figure 6.7: Default Values for localProcess Setting

    <localProcess>
           <dataExtractionTimeout>3600</dataExtractionTimeout>
           <dataExtractionThreads>1</dataExtractionThreads>
           <maxDataExtractionMemory>16</maxDataExtractionMemory>
    </localProcess>

`dataExtractionTimeout`

  Specifies the timeout value (in seconds) for the predefined set of metadata and report extraction applications. If an application takes longer than the timeout value to complete, it will be terminated by EKM. The default value is 3600 seconds (or 1 hour).

`dataExtractionThreads`

  The maximum number of simultaneous data extractions that can occur on the EKM server (or cluster node in the case of a cluster setup). To prevent data extractions from occurring, set this value to `0`.

`maxDataExtractionMemory`

  The maximum amount of memory (in GBs) that can be used for data extraction. This is the cumulative memory of all extraction threads. The value should be based on the available RAM as well as the memory required by EKM and other processes on the server. For example, for a 64GB server, this value might be set to `48` to keep the server functioning optimally when data extraction is taking place.

  If the memory required to extract data from a file exceeds the `maxDataExtractionMemory` limit, data will not be extracted from that file. For Fluent (.cas) and CFX (.def, .res) files, which support partial data extraction, metadata may be extracted from the file but not a report or image if there is insufficient memory. The same applies to the component files of a Workbench archive (.wbpz) file.

### Specifying Remote Process Policies (<remoteProcess>)

The `remoteProcess` setting specifies policies for executing external applications on a remote machine using ANSYS' Remote Solve Manager (RSM). The default values for this setting are shown below.

Figure 6.8: Default Values for remoteProcess Setting

    <remoteProcess>
        <jobSourceRootPath>{$EKM_TEMP}/jobRoot</jobSourceRootPath>
        <!-- Uncomment the following to specify the default starting folder for
             job file system as User’s Home folder (UserHome) instead of default user’s jobRoot (JobRoot) -->
        <!-- <jobFileSystemHome>UserHome</jobFileSystemHome> -->
        <clusterVisibleDirectories>
        </clusterVisibleDirectories>
        <rsmWindowsDomain>MYDOMAIN</rsmWindowsDomain>
        <rsmLauncherURL>http://localhost:10182/LauncherService</rsmLauncherURL>
        <jobOutputFilename>ekm_job.out</jobOutputFilename>
        <dataManagementJreLocation>%AWP_ROOT182%\EKM\programs\jre1.8.0_121</dataManagementJreLocation>
        <dataManagementJarLocation>%AWP_ROOT182%\EKM\bin\ekm-servo-18.2.jar</dataManagementJarLocation>
        <!--
        Uncomment the following to integrate with EnginFrame for remote visualization.
        You will need to change the following:
        a) In serviceDefinitionFile, set the fully qualified host name of the server where
           enginframe is running
        b) Change the name of the adminUser if its different from efadmin
        c) Change the queue definitions. The template provides definition for two queues:
           a windows queue using NICE Neutro as the scheduler and NICE DCV as remote visualization solution;
           and a linux queue using Platform LSF (or openlava) as the scheduler and NICE DCV as remote
           visualization solution. You may need to modify, add or remove queue definitions as needed for
           your configuration.
         -->
        <!--
        <enginframe>
            <serviceDefinitionFile>
               https://<enginframe-server-name>:8443/enginframe/ekminteractive/ekminteractive.xml
            </serviceDefinitionFile>
            <adminUser>efadmin</adminUser>
            <queue>
                <name>Windows Remote Viz Queue</name>
                <os>windows</os>
                <scheduler>neutro</scheduler>
                <schedulerQueue></schedulerQueue>
                <remoteType>dcv</remoteType>
            </queue>
            <queue>
                <name>Linux Remote Viz Queue</name>
                <os>linux</os>
                <scheduler>lsf</scheduler>
                <schedulerQueue></schedulerQueue>
                <remoteType>dcv</remoteType>
            </queue>
        </enginframe>
        -->
        <workbenchServerPortRange>40000-40100</workbenchServerPortRange>
        <!-- Uncomment the following to show the CycleCloud cluster monitor under the
                 Cluster Monitors section under Jobs page of EKM UI -->
        <!--
        <clusterMonitors>
            <clusterMonitor>
                <type>CycleCloud</type>
                <param name="url" value="http://<cycle-cloud-server-name>/node_status"/>
                <param name="credentialInfoFilePath" value="{$EKM_HOME}/conf/cycleCloudCredentials.json"/>
                <param name="clusterName" value="kumo-hpc"/>
                <param name="hostPrefix" value="ip-"/>
                <param name="excludeNodeArrays" value="master,sgemaster,app,execute"/>
            </clusterMonitor>
        </clusterMonitors>
        -->
        <!--
            The following solver versions correspond to the installed versions of ANSYS solvers for submitting jobs using built-in templates.
            To add support for more versions add an extra <version> element with <value> and <labels>
            For example, to add version support for 16.1, add the following inside <solverVersions>
            <version>
                <value>161</value>
                <label>16.1</label>
            </version>
            The default value for the version can be specified as an attribute of the solverVersions element.
            -->
        <solverVersions default="182">
          <version>
            <value>182</value>
            <label>18.2</label>
          </version>
          <version>
            <value>180</value>
            <label>18.0</label>
          </version>
          <version>
            <value>172</value>
            <label>17.2</label>
          </version>
        </solverVersions>
      </remoteProcess>

`jobSourceRootPath`

  The path to the directory where EKM will stage the data files for batch jobs submitted to RSM, if users do not choose a working directory when setting up jobs. This directory is specified in the EKM job data directory field during installation, and is resolved on the cluster submit host, so it must be accessible from that machine. See The Creation and Structure of Job Directories for details.

  In Windows:

  If EKM and RSM are running on Windows and integrating with a Windows HPC cluster, this path must be a UNC path to a shared directory (for example, `\\HEADNODE\HPCTemp`). All cluster nodes should be able to access this share. In this case, EKM will create a `workspace` directory under the job data directory, and `username` directories will be created for each user under that directory (for example, `\\HEADNODE\HPCTemp\Default\jsmith`).

  In Linux:

  If EKM and RSM are running on Linux and integrating with a Linux cluster, this can be an absolute path to a shared directory, or a path that is relative to users’ home directories. The use of home directories (via a relative path) is strongly recommended. A user’s home directory is determined by the cluster submit host, and the user has read/write permission on this directory and any subdirectories that it contains. For example, specifying the value `jobRoot` would translate into `/path/to/user/home/jobRoot` for each user.

  In either Windows or Linux, if you specify an absolute path to a shared job data directory, you must make considerations regarding access and security, as described in Access and Permission Requirements of the Job Data Directory.

  Important:

  - You must create the job data directory specified in the `jobSourceRootPath` setting before job submission begins. EKM will not create it for you.

  - If you are using a shared directory in either Windows or Linux, it is recommended that you create the `workspace` directory up front, and ensure that all users have read/write permission on that directory, so that `username` directories can be created under it. Additional steps may also be required depending on your security requirements. For more information, see The Creation and Structure of Job Directories and Access and Permission Requirements of the Job Data Directory.

  - The EKM server, RSM launcher service and cluster software must all be running on the same O.S. For example, a Linux cluster will not work with an install of RSM and EKM on Windows.

  - If users will be submitting jobs to EKM from Workbench, and Workbench and RSM are on different machines that refer to the same physical job directory using different paths, then you must specify a `pathMapping` in the ekm.xml file. This ensures that EKM passes a job path to RSM that RSM can recognize. For more information see the `pathMappings` setting in this section.

`jobFileSystemHome`

  This setting is optional. It enables you to change the default starting directory on the Jobs > File System page.

  If included, there are two options:

  - Set the value to `UserHome` to set the default starting directory on the File System page to the user's home folder (for example, /nfs/testMachine/userData/user1 or C:\Users\user1).

        <jobFileSystemHome>UserHome</jobFileSystemHome>

  - Set the value to `JobRoot` to set the starting directory on the File System page to the EKM job data directory (in other words, the directory specified in the `jobSourceRootPath` setting).

        <jobFileSystemHome>JobRoot</jobFileSystemHome>

  For information about the File System page, see Accessing the File System.

`clusterVisibleDirectories`

  You only need to specify this setting if users will be choosing working directories for batch jobs (instead of using the auto-created directories), or if `jobSourceRootPath` is set to a relative path for a Linux installation.

  If `jobSourceRootPath` is a full/absolute path, EKM automatically considers the path to be visible, so you do not need to specify that path in the `clusterVisibleDirectories` setting.

  EKM assumes that it is submitting jobs to either an ANSYS RSM Cluster (ARC) or third-party cluster. Use the `clusterVisibleDirectories` setting to list directories that are visible to all execution nodes. This determines where the job data directory can reside, enables a job to run directly in its specified working directory, and prevents unnecessary file transfers to/from RSM.

  In the example below, users can run jobs in paths under `/net/userhomes`, `/spdm/wip`, and `/home`. These are directories that all cluster nodes can access. The `/net/userhomes` directory, for example, is a shared directory under which all users’ home directories are located. Specifying this directory as a visible cluster directory means that directories such as `/net/userhomes/jsmith` and `/net/userhomes/mjones` are also visible and valid. Job data for these users will be stored in `/net/userhomes/jsmith/jobdata` and `/net/userhomes/mjones/jobdata`.

  You can specify as many paths as needed in the `clusterVisibleDirectories` setting. When adding paths, make sure that you enclose each path in a `<dir>` tag, as shown below.

      <jobSourceRootPath>jobdata</jobSourceRootPath>
          <clusterVisibleDirectories>
      	        <dir>/net/userhomes</dir>
      	        <dir>/spdm/wip</dir>
      	        <dir>/home</dir>
          </clusterVisibleDirectories>

  If EKM and RSM are integrating with a Linux cluster, you can specify an absolute or relative path for `jobSourceRootPath`. You must always specify full paths for `clusterVisibleDirectories`.

`pathMappings`

  This is an optional setting that is used if users submit jobs to EKM from Workbench. You will need to add this setting if Workbench and RSM are installed on different machines, and use different paths to refer to the same physical job directory. The `pathMappings` setting enables you to map directory paths on the Workbench machine to paths used on the RSM machine or cluster node where jobs run. Each mapping consists of a pair of settings: the `clientPath` and `clusterPath`, as shown in the example below.

  1. A user submits a job from Workbench to EKM. Workbench refers to the job’s directory as follows:

     `\\clusterServer1\jobsShare\Job_15 Jun 2017 - 09.56.59 AM`

     EKM must be able to see this path.

  2. On the cluster node where RSM will eventually run the job, RSM refers to the same directory in a different way:

     `\\clusterServer1\jobs\Job_15 Jun 2017 - 09.56.59 AM`

  3. The `pathMapping` for this setup would consist of the following pair of settings:

             <pathMappings>
               <clientPath>\\clusterServer1\jobsShare</clientPath>
               <clusterPath>\\clusterServer1\jobs</clusterPath>
             </pathMappings>

  4. With this `pathMapping`, EKM will convert the Workbench path (`clientPath`) to the RSM version of the path (`clusterPath`) before it passes the job to RSM.

     In this case, this means that EKM will convert `\\clusterServer1\jobsShare\Job_15 Jun 2017 - 09.56.59 AM` to `\\clusterServer1\jobs\Job_15 Jun 2017 - 09.56.59 AM`, and pass the latter path to RSM.

  Important: Any `clusterPath` that you specify must be an allowed path specified in the `clusterVisibleDirectories` setting.

`rsmWindowsDomain` (Windows only)

  Use this setting to ensure successful job submission to RSM when RSM is running on Windows. This is the Windows domain name that will be prepended to the user name of all EKM users when batch jobs are submitted to RSM. All user jobs will be submitted to RSM as `rsmWindowsDomain value`\`OS account name`. For example, if `MYDOMAIN` is specified as the value for `rsmWindowsDomain`, and a user’s OS account name is `jsmith`, then jobs will be submitted to RSM as `MYDOMAIN\jsmith`.

  Note: It is recommended that you use a NetBIOS domain name rather than a Fully Qualified Domain Name (FQDN) for this setting.

`jobTemplate`

  Use this optional setting to change the default RSM job template file used to run EKM jobs to a customized one.

`rsmLauncherURL`

  If the cluster submit host is not the EKM server, you must change the value of this setting from `localhost` to the host name of the cluster submit host (where the ANSYS RSM Launcher service is running).

  You must also change the value of this setting if the default port of the RSM launcher service is changed (see Specifying a Port for the Launcher XmlRpc Listener (EKM-RSM) in the RSM User's Guide).

  Example:

  The RSM launcher service configuration is modified to use port `10099` instead of the default `10182`. The Ans.Rsm.AppSettings.config file in the ``install_root`\RSM\Config` directory is edited as follows:

      </appSettings>
        <appSettings name="LauncherService">
          <add key="LauncherXmlRpcEnabled" value="true" />
          <!-- Port for Launcher XmlRpc listener. http://+:port/Launcher -->
          <add key="LauncherXmlRpcPort" value="10099" />
          <add key="LauncherXmlRpcSecure" value="false" />
          <add key="XmlRpcMaxConcurrentRequests" value="10" />
          <!--
                Range of ports for user XmlRpc listeners. http://+:port/UserProxy
          -->
          <add key="ProxyXmlRpcPortRange" value="50000-50100" />
          <add key="ProxyXmlRpcLogMessagePrefix" value="[P] " />
        </appSettings>

  The `rsmLauncherURL` setting in ekm.xml is also modified to specify `10099` as the port in the URL:

      <rsmLauncherURL>http://localhost:10099/rsm/</rsmLauncherURL>

`rsmClientTimeout`

  Specifies how long in seconds EKM should wait for a response from the RSM launcher service (see the rsmLauncherURL setting) before giving up and reporting an error.

  This setting is optional. If included, the value must be positive. A value of `0` will cause EKM to wait for a response indefinitely. If this setting is not included, the timeout used will be 120 seconds.

  Example:

      <rsmClientTimeout>90</rsmClientTimeout>

`jobOutputFilename`

  The file name that will be used by all jobs to capture batch processing output.

`dataManagementJreLocation`

  The full path to the Java Runtime Environment (JRE) used to run the data management process. For details see The Data Management Process.

      <dataManagementJreLocation>%AWP_ROOT182%\EKM\programs\jre1.8.0_121</dataManagementJreLocation>

  By default this path is set to the full path of the JRE (JRE Home) included under the EKM folder under the ANSYS installation root folder. In general, you should not need to change this setting.

  The `AWP_ROOT182` variable in the path will be resolved on the cluster submit host (where the RSM launcher service is running).

  Example:

  `AWP_ROOT182` = C:\Program Files\ANSYS Inc\v182

  RSM will use a JRE located at C:\Program Files\ANSYS Inc\v182\EKM\programs\jre1.8.0_121.

  Note:

  - The `dataManagementJreLocation` should always be set to a valid local path on the cluster submit host, as the Data Management process is launched on that machine.

  - You do not need to change the path format of the `dataManagementJreLocation` for a Linux installation. RSM will convert the Windows path into a Linux path automatically.

`dataManagementJarLocation`

  The full path to the executable JAR file used to run the data management process.

      <dataManagementJarLocation>%AWP_ROOT182%\EKM\bin\ekm-servo-18.2.jar</dataManagementJarLocation>

  By default this path is set to the full path of the ekm-servo-18.2.jar file included under the EKM folder under the ANSYS installation root folder. In general, you should not need to change this setting.

  The `AWP_ROOT182` variable in the path will be resolved on the cluster submit host.

  Example:

  `AWP_ROOT182` = C:\Program Files\ANSYS Inc\v182

  RSM will use a JAR located at C:\Program Files\ANSYS Inc\v182\EKM\bin\ekm-servo-18.2.jar.

  Note:

  - The `dataManagementJarLocation` should always be set to a valid local path on the cluster submit host, as the Data Management process is launched on that machine.

  - You do not need to change the path format of the `dataManagementJreLocation` and `dataManagementJarLocation` for a Linux installation. RSM will convert the Windows path into a Linux path automatically.

`enginframe`

  Contains EnginFrame settings and interactive queue definitions. For more detailed information see Configuring EKM to Work with EnginFrame in the EKM Installation Guide.

  Figure 6.9: Sample Interactive Queue Definitions

      <enginframe>
        <serviceDefinitionFile>https://
          enginframe-server-name:8443/enginframe/ekminteractive/ekminteractive.xml
        </serviceDefinitionFile>
        <adminUser>efadmin</adminUser>
        <queue>
          <name>Windows Remote Viz Queue</name>
          <os>windows</os>
          <scheduler>neutro</scheduler>
          <schedulerQueue></schedulerQueue>
          <remoteType>dcv</remoteType>
        </queue>
        <queue>
          <name>Linux Remote Viz Queue</name>
          <os>linux</os>
          <scheduler>lsf</scheduler>
          <schedulerQueue></schedulerQueue>
          <remoteType>dcv</remoteType>
        </queue>
      </enginframe>

  The interactive queues defined in the ekm.xml file will be automatically created in the `/Administration/Servers/Master` folder when the EKM server is started. Every interactive queue that is created in EKM will automatically contain the predefined application `remoteDesktop.app.xml`, which launches an empty remote desktop session. Once interactive queues have been created in EKM you can define job submission settings for each queue, including the account names that will be used to launch remote sessions.

`workbenchServerPortRange`

  The reserved range of ports that the Workbench server will use for listening to command requests from EKM. This setting is used when Workbench server jobs are started from EKM. The range is defined using a min-max format, as shown in the example below:

      <workbenchServerPortRange>51215-51220</workbenchServerPortRange>

`clusterMonitors`

  When EKM is deployed on the Cloud, configuring CycleCloud in the ekm.xml file enables EKM users to monitor the HPC cluster. When configured correctly, a Cluster Monitor page is available in the Jobs section in EKM, and cluster monitor graphs are displayed on the HPC tab on that page. See Cluster Monitoring in the EKM User’s Guide for details.

      <clusterMonitors>
          <clusterMonitor>
              <type>CycleCloud</type>
              <param name="url" value="http://<cycle-cloud-server-name>/node_status"/>
              <param name="credentialInfoFilePath" value="{$EKM_HOME}/conf/cycleCloudCredentials.json"/>
              <param name="clusterName" value="kumo-hpc"/>
              <param name="hostPrefix" value="ip-"/>
              <param name="excludeNodeArrays" value="master,sgemaster,app,execute"/>
          </clusterMonitor>
      </clusterMonitors>

  The `<type>` should remain set to `CycleCloud`.

  Specify the parameters described below:

  - `url`: The URL of the REST API endpoint that will be queried for data

  - `credentialInfoFilePath`: The path to the .json file where encrypted credentials will be stored

  - `clusterName`: The name of the cluster to be monitored

  - `hostPrefix`: The prefix appended to host names

  - `excludeNodeArrays`: A comma-separated list of node arrays that you do not want to be included in the Cluster Monitor

  - (optional) `maxHttpClientConnections`: The maximum number of concurrent connections between the HttpClient and CycleCloud

    The HttpClient retrieves data from CycleCloud for the purpose of cluster monitoring. By default, the maximum number of concurrent connections is 10. If after some time you find that the number of user visits to the Cluster Monitor page is increasing, and 10 concurrent connections is not enough to handle the load, it is recommended that you add the `maxHttpClientConnections` setting and increase its value to allow more concurrent connections. Note that if several requests are made in quick succession, new connections will not be created for each one. Rather, connections will be reused when possible.

        <param name="maxHttpClientConnections" value="15"/>

`solverVersions`

  The solver versions specified here correspond to the installed versions of ANSYS solvers and applications that are used when jobs are submitted using EKM’s built-in CFX Batch, Electronics Batch, Fluent Batch, LS-DYNA Batch, MAPDL Batch, and Workbench Batch job templates.

          <solverVersions default="180">
            <version>
              <value>182</value>
              <label>18.2</label>
            </version>
            <version>
              <value>172</value>
              <label>17.2</label>
            </version>
          </solverVersions>

  Solver versions specified in `<version>` elements will appear in the Version drop-down list in the Start Job dialog box when a built-in job template is used to start a job. The `default` attribute determines which version will be selected by default in this list.

  To add support for more solver versions, create additional `<version>` elements with `<value>` and `<label>` attributes. For example, to add support for version 17.0 solvers, you would add the following `<version>` element:

            <version>
              <value>170</value>
              <label>17.0</label>
            </version>

  The `<value>` is what EKM uses to refer to the version internally, while the `<label>` is what is displayed in the Version drop-down list in the Start Job dialog box.

  Note:

  - Make sure that the versions specified correspond to the actual ANSYS application versions installed on your execution nodes.

  - The `<solverVersions>` element is intended for ANSYS products only. Non-ANSYS solvers are not supported.

  - For on-premise installations, versions within the past two major releases are supported (in other words, release 16 and 17). For Cloud installations, versions 16.1 and higher are supported.

  - The Workbench Batch template does not support job submission to versions of Workbench older than version 17.0. Pre-R17 versions will not be available in the Version drop box when using this template, even if such versions are specified in the `<solverVersions>` setting.

`enableClusterJobNameSpecification`

  Adding this setting to the `<remoteProcess>` settings allows a custom field to be displayed in the job submission wizard which ties the EKM job to a specified account name that can be used for tracking cluster usage.

      <enableClusterJobNameSpecification>true
      </enableClusterJobNameSpecification>

  For information on defining a cluster job name field and tracking cluster usage, see Tracking Cluster Usage Through a Cluster Job Name.

### Specifying Cache Service Settings (<cache>)

The `cache` setting specifies policies for storing files cached from remote EKM servers. The default value for this setting is shown below.

Figure 6.10: Default Value for cache Setting

    <cache>
          <size>20G</size>
    </cache>

`size`

  The maximum amount of data, in bytes, that can be cached. You can use suffixes k or K for kilobytes, m or M or megabytes and g or G for gigabytes. For example, 20G shown in the above example denotes 20 gigabytes.

Note: A cache size of `0` means that no files will be cached.

### Scheduling Automatic Tasks (<scheduledTasks>)

The `scheduledTasks` setting specifies the day and time when periodic tasks are executed by EKM. Below are the default values for this setting, followed by a description of each setting.

Figure 6.11: Default Values for scheduledTasks Setting

            <dataStoreGc>
                <day>Sunday</day>
                <hour>0</hour>
                <dayInterval>1</dayInterval>
            </dataStoreGc>
            <fileBackup>
                <day>Sunday</day>
                <hour>0</hour>
                <dayInterval>0</dayInterval>
            </fileBackup>
            <remoteSync>
                <day>Any</day>
                <hour>1</hour>
                <dayInterval>1</dayInterval>
            </remoteSync>
            <recycleBinCleanup>
                <day>Any</day>
                <hour>0</hour>
                <dayInterval>1</dayInterval>
            </recycleBinCleanup>
            <mail>
                <day>Any</day>
                <hour>20</hour>
                <dayInterval>1</dayInterval>
            </mail>
            <purge>
                <day>Saturday</day>
                <hour>22</hour>
                <dayInterval>7</dayInterval>
            </purge>
            <batchJobMonitor>
                <day>Any</day>
                <hour>0</hour>
                <dayInterval>0</dayInterval>
                <minInterval>1</minInterval>
            </batchJobMonitor>
            <serverMonitor>
                <day>Any</day>
                <hour>0</hour>
                <dayInterval>0</dayInterval>
                <minInterval>10</minInterval>
            </serverMonitor>
            <cacheMonitor>
                <day>Any</day>
                <hour>23</hour>
                <dayInterval>1</dayInterval>
            </cacheMonitor>
    </scheduledTasks>

You can specify the execution time for any task by providing the `day`, `hour`, and `min` values. `Any` value can be used for `day` if you want the task to be executed all days. Alternatively, you can specify a particular day of the week such as `Saturday`, `Sunday`, and so on. The `hour` values range from `0` (12 AM) to `23` (11 PM). The `min` (minute) value ranges from `0` to `59`. If `min` is unspecified, it is taken as `0`. You can specify the interval of the task by providing the `dayInterval` and `hourInterval` values. If you set both of these values to `0`, the task will never be executed.

`dataStoreGC`

  Used to periodically clean files from the datastore folder that are no longer being used within EKM. When a file is deleted from EKM it is not removed immediately but is marked for garbage collection. The file content is actually removed as part of this scheduled task. As shown in Figure 6.11: Default Values for scheduledTasks Setting, this task is executed every day at 2 AM.

  To ensure consistency during restore and preventing accidental deletion of files that have not yet been committed, this task will delete only those files that are no longer in use, and whose modification time is older than garbage collection start time minus a buffer time. The buffer time is equal to the specified interval of dataStoreGC scheduled task plus an additional buffer of 6 hours. For example, suppose default settings are used for dataStoreGC and a file was added on Monday at 3PM. The next garbage collection will start on Tuesday at 2AM, but this file will not be deleted because it is still in use. Now suppose this file is deleted on Tuesday at 10AM. The next garbage collection will start on Wednesday at 2AM, but because the file’s modification time is less than the buffer of 30 hours (24 hour dataStoreGC interval and 6 hour of additional buffer), it will not be deleted even then. The file will only be deleted in the next garbage collection on Thursday at 2AM. This ensures that if a complete backup was started before 10 AM on Thursday, the file will exist in both the database backup as well as the datastore backup, as long as the backup finishes before Thursday at 2AM.

  Important: The garbage collection interval should exceed the time it takes to complete a full backup of the datastore to avoid data inconsistency during restore. Thus if the backup time exceeds 24 hours, the dayInterval setting should be increased from the default value of 1.

`fileBackup`

  Used to create a backup of all files uploaded to EKM. This is desirable if you want to periodically write all files managed by EKM to a separate, backup folder. Because you may decide to use your own backup policy, by default, this task is specified to never execute because the `dayInterval` and `hourInterval` values are set to `0`.

`remoteSync`

  Used to periodically synchronize all files and folders in remote file servers. EKM allows users to create a reference to files/folders that reside in remote servers, in lieu of uploading them. This task is used to periodically poll the external servers and synchronize the information in EKM, to determine if any changes have occurred in the file server.

  Important: Do not schedule the `remoteSync` task to run at midnight. Doing so can interfere with the creation of the daily audit logs.

`recycleBinCleanup`

  Used to periodically purge objects from the Recycle Bin of all users in all workspaces, based on the recycle bin cleanup policy specified in the users' preference. Objects will be deleted only if the user has chosen to delete objects in the Recycle Bin that are older than X days, and more than X days have elapsed because the object was placed in the Recycle Bin.

`mail`

  Used to send an email to users that have subscribed to receive alerts for certain objects. By default, this task runs at 8 PM every day.

`purge`

  Used to remove objects from the repository that have expired. By default, this task runs every Saturday at 10 PM.

`batchJobMonitor`

  Used for monitoring the status of asynchronous batch jobs submitted to RSM. This task is run every minute to get real time feedback.

`serverMonitor`

  Used for monitoring the status of remote EKM servers. This task is run every 10 minutes. If a server cannot be reached, a warning is shown in the EKM user interface, alerting the system administrator to investigate the issue.

`cacheMonitor`

  Used to monitor the size of the cached data. It is run every night at 11 PM. It first removes any cached files that are no longer present in the master EKM workspace where the file came from. It then calculates the total size of the cache and if the size exceeds the maximum limit, it removes the oldest files one at a time until the size is below the limit. The “age” of the file is based on its last access time.

### Configuring Plug-ins (<pluginRegistry>)

The `pluginRegistry` setting is used to configure plug-ins that are loaded by EKM. The default values for this setting are shown below.

Figure 6.12: Default Values for pluginRegistry Setting

    <pluginRegistry>
            <pluginDirectory>
                {$EKM_HOME}/plugins-deploy
            </pluginDirectory>
            <loadAll>true</loadAll>
            <pluginSettings pluginName="cae">
               <param name="customResourcesPath" value=""/>
            </pluginSettings>
    </pluginRegistry>

`pluginDirectory`

  Specifies the full path of the directory containing the plug-in JAR files. By default, it is set to the `plugins-deploy` directory within the EKM installation directory. The `loadAll` setting determines whether all the plug-in JAR files in the `pluginDirectory` should be loaded or not. By default, this value is set to true. If you specify it as false, then you can explicitly list all the plug-ins you want to load by the following line. You will seldom need to change these two values.

      <plugin>PLUGIN-JAR-NAME</plugin>

`pluginSettings`

  Used to specify plug-in-specific settings that are given as `name` value pairs. Currently the only available setting is `customResourcesPath` for the `cae` plug-in. The `customResourcesPath` setting is used to specify a path where script files for metadata extraction and report generation can be placed if you want to override the default data extraction of built-in CAE types.

### Specifying the Superuser Name and Password (<superUser>)

The `superUser` setting is used to specify the user name and password of the Superuser. The Superuser has access to the EKM Administration interface, which allows workspace creation and migration.

Figure 6.13: Default Value for superUser Setting

    <superUser>
            <name>superuser</name>
            <password>9a85a0cc0a56febcf46690a6ab1a5803</password>
    </superUser>

`name`

  The name of the user who is the designated Superuser. This setting is optional. Only a password is required to sign in to the EKM Administration interface.

`password`

  Specifies the md5 hash of the superuser password. For security reasons clear text password is not stored in the file. The default value corresponds to the password: `superuser123`. It is recommended that you use the administration interface to change this default password after installation.

  For information on the EKM Administration interface, see Creating and Managing Workspaces.

### Configuring a Cluster (<cluster>)

The `cluster` setting is used to specify the configuration of a cluster.

Figure 6.14: Default Value for cluster Setting

    <cluster>
            <type>cluster</type>
            <cacheConfigFile>{$EKM_HOME}/conf/clusterCache.xml</cacheConfigFile>
    </cluster>

`type`

  Must be cluster.

`cacheConfigFile`

  Specifies the location of the configuration file for the infinispan cache, which is a cluster-wide in-memory cache.

### Specifying the Maximum Number of Search Results to Display (<memoryLimits>)

The `maxSearchResults` value in the `memoryLimits` setting is used to limit the number of objects that are returned by a search. This limits the amount of time and resources that are spent on search operations. If your server has a large amount of memory available and you want to allow users to search for more objects, you can increase the limit. The default value for this setting is shown below.

Figure 6.15: Default Value for maxSearchResults Setting

    <memoryLimits>
        	<maxSearchResults>500</maxSearchResults>
    </memoryLimits>

### Specifying the Email Domain (<email>)

The `email` setting enables you to specify a configured domain for all e-mails, alerts and messages that are sent by EKM. By default, the domain that you specify will be part of every e-mail address specified in EKM. The default value for this setting is shown below.

Figure 6.16: Default Value for email Setting

    <email>
        <mailFromDomain>nodomain.com</mailFromDomain>
      </email>

### Specifying the Custom User Interface Folder (<customResourcesPath>)

The `customResourcesPath` setting is used to specify the folder that contains user interface files for custom dialog boxes. Refer to the Defining Custom Dialogs, Wizards and Applications chapter in the EKM User’s Guide for details on how to create these files.

The default path shown is a suggested location for the custom resources folder. You can either create a folder in this location, or specify a path to a different folder on the EKM server.

Figure 6.17: Default Value for customResourcesPath Setting

    <customResourcesPath>{$EKM_HOME}/conf/resources</customResourcesPath>

### Specifying the Root Directory for File Transfers (<fileTransferService>)

The `fileTransferService` setting determines the root directory for the file transfer service when uploading a file to EKM using the File Transfer Client. This is the staging area in which files are temporarily held before being imported into EKM. The default value is the `TEMP` directory. In a clustered environment, the `rootDir` value will need to be changed on each node to a shared directory that all nodes can access.

Figure 6.18: Default Value for fileTransferService Setting

    <fileTransferService>
        <rootDir>{$EKM_TEMP}</rootDir>
      </fileTransferService>

Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

Prev | Up / Contents | Next

Release 18.2 - © ANSYS, Inc. All rights reserved.