Configure xDI Designer

In most situations, Semarchy xDI Designer works without additional configuration. However, you can change its startup settings to meet your needs.

Overview

Major startup settings can be set in an INI file with a similar name to the Designer executable, and in the same directory. The Designer startup INI file is based on the Eclipse IDE startup file.

The file for Windows is semarchy-xdi-designer-windows.ini.
The file for Linux is semarchy-xdi-designer-linux.ini.
On macOS, the settings file is in the /Contents/Eclipse subdirectory of the application package. It is named semarchy-xdi-designer.ini.

When making edits to the INI file, you should follow these best practices:

Experiment with Designer launch parameters from your Command Prompt or Terminal before changing the files itself.
If a parameter would typically have a space between it and its argument, the argument must be on its own line.
Keep a backup of the original file in case of problems.

Some settings must be set in other configuration files. These are mentioned when relevant.

Settings

Memory management

By default, Designer allows the Java Virtual Machine to manage memory automatically. This is ideal in most cases.

You can use the -Xms and -Xmx Java parameters to configure the minimum and maximum amount of memory Designer uses.

# Minimum Heap size
-Xms512m
# Maximum Heap size.
-Xmx2048m

Built-in Runtime location

The Designer built-in Runtime is deployed by default in the Designer installation folder, in a subfolder named runtime.

To change this location, edit the following property:

# Runtime location
-Dxdi.designer.runtime.home=runtime

Module generation

Modules are files that xDI uses to communicate with external technologies. You can configure how xDI Designer modules with the following two properties:

# Location for generated modules
-Dxdi.designer.module.path.v1=runtime/modules
# Automatic module creation
-Dxdi.designer.module.automaticCreation=true

The property xdi.designer.module.path.v1 controls where xDI places modules when it creates them, and takes a relative or absolute path. Changing the module location only takes effect for Designer, and not its built-in runtime. Refer to the Runtime configuration guide to learn how to change where the runtime looks for modules.

The property xdi.designer.module.automaticCreation controls whether xDI creates modules automatically or not, and takes true or false.

License configuration

You can preconfigure license management for a xDI Designer instance by setting the following environement variables prior to starting the Designer.

XDI_DESIGNER_LICENSE_KEY: Set this variable to define your License Key string. When this variable is set, the Online mode is used by default. The Local Server mode is used instead if XDI_DESIGNER_LICENSE_SERVER_URL is set.
XDI_DESIGNER_LICENSE_SERVER_URL: Set this variable to define your local license server URL, and use the Local Server mode.
XDI_DESIGNER_LICENSE_KEY_FILE: Set this variable to define your License Key File location and use the Offline mode. This variable is taken into account only if XDI_DESIGNER_LICENSE_KEY is unset.

License Server certificates

Semarchy xDI Designer validates its license from a license server. This may be either the main Semarchy license server, or a local license server you install yourself. In both cases, xDI Designer communicates with the license server over an HTTP connection secured with SSL/TLS.

If you have a local license server, you need to configure it to use SSL/TLS, and specify a certificate.

If you use a certificate issued by a trusted certificate authority, Designer should connect without needing to make other changes.

Self-signed certificates

Using self-signed certificates requires you to disable a Java security setting. When possible, you should use a certificate issued by a trusted authority instead.

With a self-signed certificate, you must configure xDI Designer to recognize this certificate. Otherwise, Designer refuses the connection.

First, add the self-signed certificate to xDI Designer. You can do this in one of two ways:

Give Designer access to a custom keystore that holds your certificate.

Add your certificate to a Java Keystore, then add parameters to the Designer startup settings file to define the keystore information:

-Dxdi.designer.license.server.keystore.path=<Path to keystore file location>
-Dxdi.designer.license.server.keystore.type=<keystore type>
-Dxdi.designer.license.server.keystore.password=<security password>
-Dxdi.designer.license.server.keystore.key.alias=<keystore alias>

Add the certificate to the Java Virtual Machine (JVM) truststore directly, which allows any application using the JVM to access to the certificate.

If the JVM truststore is in a custom location, add the certificate to this location, then add parameters to the Designer startup settings file to define the certificate information:
```
-Djavax.net.ssl.trustStore=<Path to truststore location>
-Djavax.net.ssl.trustStoreType=<truststore type>
-Djavax.net.ssl.trustStoreProvider=<provider>
-Djavax.net.ssl.trustStorePassword=<truststore password>
```

Second, configure Designer to disable strict hostname verification in Java:

Navigate to the configuration subdirectory of the application package or installation directory.
Open the config.ini file in a text editor.
Find the line containing xdi.designer.license.server.certificate.hostname.verification=true.
Change true to false.
Save the file.

Your self-signed certificate should be recognized by Designer.

Configure Designer-to-Runtime file rewriting

When it starts, xDI Designer tries to find altered files in the built-in runtime, and replace them with the Designer’s own internal copies. This behavior serves to prevent conflicts or other unexpected behavior between Designer and the runtime. You can alter the behavior in the protection.rules files.

To protect the built-in runtime’s files from Designer’s rewrite mechanism, follow these steps:

From the xDI Designer install path, navigate to the runtime/properties subdirectory.
Open the protection.rules file in a text editor.
Add rules to protect files or directories, with one rule per line.

Protection rules work like this:

A leading / character represents a path relative to the runtime directory, here named runtime.
You can use a * wildcard character to represent multiple files or directories.
Type comments by using a leading # character on the line.

For examples, see the default protection.rules file.