5.3.2. Configuration Settings in WorkspaceConfig.xml

Engineering Knowledge Manager

Administration Guide | Chapter 5: Restricted and Unrestricted Configuration of Workspaces | 5.3. Configuring Workspace Settings |

5.3.1. Schema Definition for Workspace Configuration |  | Chapter 6: Configuring EKM Server Settings
Prev |  | Next

### 5.3.2. Configuration Settings in WorkspaceConfig.xml

Workspace configuration settings are specified in the WorkspaceConfig.xml file (see Steps for Changing WorkspaceConfig.xml Settings in EKM:). All of these settings are optional.

In this section:

- Specifying Default Data Types for File Extensions
- Specifying MIME Types for File Extensions
- Specifying Settings for Built-In or Custom Types
- Specifying Default Dashboard Settings
- Specifying Default Values for Preferences
- Specifying a Custom Download Message
- Scheduling EKM Tasks
- Creating User Accounts Automatically
- Specifying the Default Access Level for Auto-Created Users
- Designating a Root User for a Workspace
- Creating a Job-Only View
- Associating a Master Workspace with a Slave Workspace

Important: When specifying values for attributes in the WorkspaceConfig.xml file, avoid using characters that are used as identifiers in XML code, such as `“&”`, `“<”` and `“>”`. Otherwise, an error will be reported when you apply the workspace configuration.

For example, specifying the following value for the `downloadConfirmation` setting would cause an error because the “&” character is used.

    <downloadConfirmation>The files & folders on this system may be restricted.
    Please review restrictions on a file before distributing externally.</downloadConfirmation>

In this case, the following error would be reported when you apply the workspace configuration:

#### 5.3.2.1. Specifying Default Data Types for File Extensions

The `defaultExtensions` setting can be used to specify the data type that will be taken as the default for a particular extension. This is used in cases where the same extension is shared by multiple types. A sample listing is shown below.

Example 5.1: defaultExtensions Setting

    <defaultExtensions>
        	<extension>
        		<name>dat</name>
        		<type>PolyflowData</type>
        	</extension>
    </defaultExtensions>

In many cases, EKM can automatically infer the correct type if a file extension is used by multiple file types. Every user can also choose to specify the default type for a particular file extension in their preferences. This setting is used in cases where users have not specified a preference for an extension, and EKM cannot infer the type.

#### 5.3.2.2. Specifying MIME Types for File Extensions

The `mimeTable` setting can be used to specify the MIME type for a file extension. The MIME type for a built-in or custom type can also be specified in the `typeSettings` setting by using the `contentType` type attribute. The `mimeTable` setting is used to set the MIME type of those files that are represented as generic `File` types in EKM. The default MIME type of a file in EKM is `application/octet-stream`, which is used to represent binary files.

A sample listing for the `mimeTable` setting is shown below. In this example all files with an `out` extension will have a MIME type of `text/plain`.

Example 5.2: mimeTable Setting

    <mimeTable>
        	<mimeEntry>
        		<extension>out</extension>
        		<contentType>text/plain</contentType>
        	</mimeEntry>
    </mimeTable>

#### 5.3.2.3. Specifying Settings for Built-In or Custom Types

The `typeSettings` setting can be used to set or modify some settings of built-in or custom types. The following settings can be specified for any type:

- `hidden`: Used primarily to hide built-in types from which you do not want to extract metadata or reports. For example, by specifying `WorkBenchSimulation` as a hidden type, then whenever a `Workbench Simulation` file type (.dsdb) is added to EKM, it will be treated as an ordinary file and no metadata will be extracted from it.

- `modelObjectClass`: Used to specify the full name of a class that implements the back-end behavior of a data type. This is used for customization only.

- `typeAttribute`: Used to specify the value of some type attributes. See Defining Custom Types for a description of type attributes and acceptable names.

A sample listing for `typeSettings` is shown below. The name of a built-in type should be the non-localized name as described in Appendix B: Built-in Types - Reference. In this example, a `modelObjectClass` setting is provided for a custom type called `AcmeSimulationFile`. The `metaDataApplication` type attribute of the `FluentCase` built-in data type value is set to `fluentExtractionApp`, which is a custom application defined in the `applications.xml` file. The `hidden` setting of the `WorkBenchSimulation` type is set to `true`, which means that whenever a `Workbench Simulation` file type (.dsdb) is added to EKM, it will be treated as an ordinary object that is not eligible for data extraction. Finally, the `disableDataExtraction` setting is set to `true` for the `CfxDefinition` type, indicating that data will not be extracted from .def files when they are uploaded to EKM.

Example 5.3: typeSettings Setting

    <typeSettings>
        	<type name="AcmeSimulationFile">
        		<modelObjectClass>com.acme.AcmeSimulationFileObject</modelObjectClass>
        	</type>
        	<type name="FluentCase">
       			<typeAttribute name="metaDataApplication" value="fluentExtractionApp"/>
        	</type>
        	<type name="WorkBenchSimulation">
        		<hidden>true</hidden>
        	</type>
        	<type name="CfxDefinition">
       			<typeAttribute name="disableDataExtraction" value="true"/>
        	</type>
    </typeSettings>

#### 5.3.2.4. Specifying Default Dashboard Settings

The `dashboard` setting can be used to specify default gadgets for a user dashboard. This setting can have any number of child `gadget` elements. Each `gadget` element can have the following child elements:

- `name`: Used to specify the name of the gadget.

- `path`: Used to specify the path of the object that will be viewed by the gadget.

- `essential`: An optional element that can either be `true` or `false`. It specifies whether the `gadget` is essential, in which case it cannot be deleted by a user (an 'X' icon will not appear for essential gadgets). If this element is not specified, the `gadget` is treated as non-essential.

By default, all dashboards contain four gadgets: My Tasks, Job Monitor, Process Monitor, and Extraction Monitor. All of these gadgets are non-essential.

Example 5.4: dashboard Setting

    <dashboard>
    		<gadget>
    			<path>/Processes/My Tasks</path>
    		</gadget>
    		<gadget>
    			<path>/Jobs/Job Monitor</path>
    		</gadget>
    		<gadget>
    			<path>/Processes/Process Monitor</path>
    		</gadget>
    		<gadget>
    			<path>/Data/Extraction Monitor</path>
    		</gadget>
    	</dashboard>

Note: The `dashboard` setting in the WorkspaceConfig.xml file is applied when new user accounts are created. Changes to the `dashboard` setting will not affect existing users.

#### 5.3.2.5. Specifying Default Values for Preferences

The `preferences` setting is used to establish the default selections for preferences in the Settings dialog box. Changes made to the preferences defined in the WorkspaceConfig.xml file apply only to new users that are created. The preferences of existing users are not affected. The default values specified in the `preferences` setting are also the values that will be restored when a user (new or existing) clicks the Restore Defaults button in the Settings dialog box. The default values for the `preferences` setting are shown below.

Example 5.5: preferences Setting

    <preferences>
    		<initialUri>/My Home</initialUri>
    		<onSignInObject>lastAccessedObject</onSignInObject
    		<locale>en</locale>
    		<unitSystem>SI</unitSystem>
    		<disableDataExtraction>false</disableDataExtraction>
    		<theme>midnightblue</theme>
    		<typeColumnMap>
    			<typeColumnMapEntry>
    				<typeName>Model</typeName>
    				<columnList>type, length, modificationTime, modifiedBy</columnList>
    			</typeColumnMapEntry>
    		</typeColumnMap>
    		<recyclebinPolicy>cleanAfterSpecifiedTime</recyclebinPolicy>
    		<recyclebinCleanupInterval>30</recyclebinCleanupInterval>
    		<httpProxyServer/>
    		<httpProxyServerAuth>false</httpProxyServerAuth>
    		<compressArchives>true</compressArchives>
    	</preferences>

The sample above sets the following preferences:

- `initialUrl`: The location in the EKM workspace in which EKM will start.

- `onSignInObject`: The location that you want to be opened every time you sign in to EKM. The default value, `lastAccessedObject`, opens the location that was open when you last signed out of EKM. If you would prefer to open the same specific location every time, set the value to `specificObject`, then specify the desired location in the `initialUrl` setting.

- `locale`: The language in which you want EKM to display text. Once you have logged into EKM, text will be displayed in the language you choose. The language for the EKM login page will depend on the language preference of your web browser. This is because EKM preferences are available only after you have logged into EKM.

- `unitSystem`: The unit system in which you want EKM to display property values in drop-down lists.

  Choose one of the following values:

  - `SI` (the default)

  - `CGS`

  - `US`

  - `Metric`

  - `British`

  Units will be shown only for custom properties of type `Double` that have been associated with a quantity. All the other values are shown without any units. See Defining Properties for a Custom Type for details on how to define a quantity with a custom property.

- `disableDataExtraction`: Setting this to `true` prevents the automatic extraction of metadata from CAE files when such files are uploaded or imported into the EKM repository. Files will be identified in the repository with a warning icon next to them, and hovering over this icon will display the message Extracted data is not set. You can subsequently extract metadata manually. By default this preference is set to `false` to allow the automatic extraction of metadata.

- `theme`: The theme that is used to display the EKM interface. Themes are defined in CSS files that are included in the EKM installation. The default value for this setting is `midnightblue`. If you prefer a lighter theme, change the value to `sunrise`.

- `typeColumnMap`: Determines what columns are displayed in the file list window for an object type. The `typeColumnMapEntry` element is an entry in the column map. Each entry has a `typeName` and `columnList` attribute. The `typeName` attribute is the name of the object type, and the `columnList` attribute determines the columns that are to appear for that type in the file list window. You can define a `typeColumnMapEntry` for each object type in EKM.

  The sample `typeColumnMap` element below contains a `typeColumnMapEntry` for the `Model` type, which is the base type of all object types in EKM.

  Example 5.6: typeColumnMap Element

      		<typeColumnMap>
      			<typeColumnMapEntry>
      				<typeName>Model</typeName>
      				<columnList>type, length, modificationTime, modifiedBy</columnList>
      			</typeColumnMapEntry>
      		</typeColumnMap>

- `recyclebinPolicy`: Determines how and when items are permanently removed from the recycle bin. Use one of the values described below.

  - `cleanAfterSpecifiedTime` will delete objects from the recycle bin after a specified number of days. This is the default setting.

  - `cleanOnExit` will permanently delete all objects on exit or logout.

  - `cleanNever` will not permanently delete objects from the recycle bin unless the user initiates it.

- `recyclebinCleanupInterval`: The number of days after which an object will be permanently removed from the recycle bin if the `recyclebinPolicy` is set to `cleanAfterSpecifiedTime`.

- `httpProxyServer`: If you use a proxy server to access a shared EKM server, this is the host name and port (for example, `www.ekmserver.com:3128`) of the default proxy server that the File Transfer Client will use to connect to EKM.

- `httpProxyServerAuth`: The default value for this property is `false`. Set to `true` if the proxy server requires authentication for access.

- `compressArchives`: When this property is set to `true` (the default value), archive files (for example, .wbpz files) are compressed before they are transferred to or from the EKM server. An archive file is a collection of files and folders stored in one file. The archive file is not compressed — it uses the same amount of disk space as all of the individual files and folders combined. A compressed file is a collection of files and folders stored in one file and stored in a way that uses less disk space than the files and folders that it contains. The choice to compress archive files will depend largely on your location. Compression is most beneficial if you are transferring files from a remote location across a Wide Area Network (WAN). Even though time is needed by the system to compress and decompress the archive file, the reduced file size compensates for this and allows files to be transferred much more quickly when connection speeds are slower. On the other hand, if you are on the same Local Area Network (LAN) as the EKM server, it is recommended that you disable compression. To disable compression, set the `compressArchives` property to `false`.

  The compression preference applies to archives (.wbpz files) that are created by EKM when you upload Workbench projects to the EKM repository, and when folders are archived on the server for download.

  Note that compression will not be used on archives that are used primarily on the server (in other words, archives that are not specifically destined for transfer). This includes archives created for jobs.

For more information about user preferences, see Setting Your Preferences in the User’s Guide.

#### 5.3.2.6. Specifying a Custom Download Message

The `downloadConfirmation` setting can be used to specify a customizable message that will be displayed whenever a user tries to download a file or folder from EKM. This can be used if the data contained within EKM is confidential, and for legal reasons, you want to inform the user about restrictions on the data before it is downloaded. An example of this setting is shown below.

Example 5.7: downloadConfirmation Setting

    <downloadConfirmation>The files and folders on this system may be restricted.
    Make sure to read the restriction property associated with the file before
    distributing the content to people outside the company.</downloadConfirmation>

#### 5.3.2.7. Scheduling EKM Tasks

The `scheduledTasks` setting can be used to schedule tasks that EKM will execute on a particular day and time. The tasks correspond to scripts that have been uploaded to EKM. Scripts can be developed in either Python or BeanShell languages with `.py` and `.bsh` extensions, respectively.

For each `scheduledTask`, the `scriptPath` setting specifies the path of the script file in the workspace. You can specify the execution time for any script by providing the `day`, `hour`, and `min` values. Any value can be used for `day` if you want the task to be executed on 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.

Scripts are always executed on behalf of the Root User. Therefore, any action executed by the script will have all privileges given to the Root User.

In the following example there are four scheduled tasks defined. `script1.py` is executed every Saturday at 10PM, `script2.py` is executed every day at 12AM, `script3.py` is executed every hour and `script4.py` is executed after every 10 minutes.

Example 5.8: scheduledTasks Setting

    <scheduledTasks>
          <scheduledTask>
              <scriptPath>/Data/Shared Data/scripts/script1.py</scriptPath>
              <day>Saturday</day>
              <hour>22</hour>
              <dayInterval>7</dayInterval>
         </scheduledTask>
        <scheduledTask>
              <scriptPath>/Data/Shared Data/scripts/script2.py</scriptPath>
              <day>Any</day>
              <hour>0</hour>
              <dayInterval>1</dayInterval>
          </scheduledTask>
          <scheduledTask>
              <scriptPath>/Data/Shared Data/scripts/script3.py</scriptPath>
              <day>Any</day>
              <hour>0</hour>
              <dayInterval>0</dayInterval>
              <hourInterval>1</hourInterval>
          </scheduledTask>
          <scheduledTask>
              <scriptPath>/Data/Shared Data/scripts/script4.py</scriptPath>
              <day>Any</day>
              <hour>0</hour>
              <dayInterval>0</dayInterval>
              <minInterval>10</minInterval>
          </scheduledTask>
    </scheduledTasks>

#### 5.3.2.8. Creating User Accounts Automatically

The `createUsersAutomatically` setting specifies whether or not user accounts will be created automatically when users successfully sign in to the workspace for the first time.

The default behavior for workspaces is as follows:

- The Default workspace that is created during the EKM installation has automatic account creation enabled.

- If the workspace is one that has been migrated from version 15 or earlier, automatic account creation is disabled.

- For new workspaces, automatic account creation is enabled if the Create new users automatically check box was enabled when the workspace was created.

Example 5.9: createUsersAutomatically Setting

    <ekm:workspace>

    	...
    	<createUsersAutomatically>true</createUsersAutomatically>

    </ekm:workspace>

If the setting has a value of `true`, any user with valid credentials for the active login module will be able to sign in to the workspace, and EKM will create a user account for that user automatically. For information about configuring user logins, see Configuring Login Authentication in the Installation Guide. If the setting has a value of `false`, a user will only be able to sign in to the workspace if an administrator has created a user account for that user. See Adding and Modifying Users for details.

Note: The default access level of auto-created users is `Analyst`. If you would like to change the default access level, see Specifying the Default Access Level for Auto-Created Users.

#### 5.3.2.9. Specifying the Default Access Level for Auto-Created Users

By default, if the `createUsersAutomatically` setting is set to true (see Creating User Accounts Automatically), auto-created users will have their access level set to `Analyst` when their account is created. For information about access levels, see Licensing and Access in the Installation Guide.

If you would like auto-created users to have a different access level in a workspace when their accounts are created, you must manually add a `defaultAccessTypeForAutoCreatedUsers` setting after the `createUsersAutomatically` setting in the workspace's WorkspaceConfig.xml file, and for its value specify either `basic`, `analyst` or `shared`. If an invalid value is specified, or a value is not specified at all, the `Analyst` access level will be used.

An example of this setting is shown in bold below:

Example 5.10: defaultAccessTypeForAutoCreatedUsers Setting

    <ekm:workspace>

    	...
    	<defaultAccessTypeForAutoCreatedUsers>shared</defaultAccessTypeForAutoCreatedUsers>

    </ekm:workspace>

#### 5.3.2.10. Designating a Root User for a Workspace

The Root User is the primary administrator for an EKM workspace, and the only user who can make restricted configuration changes in that workspace. By default, the Root User for a workspace is the user specified in the `<defaultRootUser>` setting in the ekm.xml file (see Specifying the Default Root User (<defaultRootUser>)).

If you want to specify a different Root User for a specific workspace, you must manually add a `designatedRootUser` setting to that workspace’s WorkspaceConfig.xml file, and for its value specify the EKM user name of the user you want to designate as the Root User for that workspace. This effectively overrides the `<defaultRootUser>` setting.

An example of this setting is shown in bold below.

Example 5.11: designatedRootUser Setting

    <ekm:workspace>

    	...
    	<designatedRootUser>jsmith</designatedRootUser>

    </ekm:workspace>

Note:

- This setting must be added after the `<createUsersAutomatically>` setting.

- EKM user names are case-sensitive. See How User Logins Work in the EKM Installation Guide to see how EKM user names are defined.

- Once you have added this setting and designated a Root User for the workspace, you can apply and/or accept the configuration change. If you choose to apply the configuration, you will lose your root privileges at that time. You must then sign out of the workspace and let the new `designatedRootUser` sign in so that he or she can accept the workspace configuration changes.

#### 5.3.2.11. Creating a Job-Only View

The `ekm:workspace` setting is used to control the overall appearance and functionality of an EKM workspace. Adding a `jobOnlyView` setting with a value of `true` results in a simplified view in which only the Jobs section is displayed.

Example 5.12: jobOnlyView Setting

    <ekm:workspace>

    	...
    	<jobOnlyView>true</jobOnlyView>

    </ekm:workspace>

For details about the appearance and functionality of the job-only view, see Working in a Job-Only View in the EKM User's Guide.

Note:

- This setting must be placed last unless you also have `defaultAccessTypeForAutoCreatedUsers` defined. In that case, it should come second last.

- `Admin` users will still have access to the Administration section in a job-only view.

#### 5.3.2.12. Associating a Master Workspace with a Slave Workspace

If you are setting up a distributed Master-Slave configuration, as described in Running Jobs in a Distributed Environment, you must configure workspaces on Slave servers to point to workspaces on a Master EKM server which contain the central data to be used for running jobs.

To associate a Master workspace with a Slave workspace, sign in to the Slave workspace and add `masterServerUrl` and `masterServerWorkspace` settings to the Slave server's WorkspaceConfig.xml file, as shown in the example below. For the `masterServerUrl` enter the URL of the Master EKM server, and for the `masterServerWorkspace` enter the name of the Master workspace that you want to associate with the Slave workspace.

Example 5.13: masterServerUrl and masterServerWorkspace Settings

    <ekm:workspace>

    	...
    	<masterServerUrl>http://masterMachineName:8080</masterServerUrl>
    	<masterServerWorkspace>Default</masterServerWorkspace>

    </ekm:workspace>

Note:

- These settings must be placed last unless you also have `defaultAccessTypeForAutoCreatedUsers` defined. In that case, they should come second last.

- Associating a workspace with a Master workspace is what makes a workspace a Slave workspace. Although a Slave workspace is similar to a workspace with a job-only view, you do not need to configure a Slave workspace to have a job-only view. That will happen automatically when you associate a Master workspace with it.

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.