Configuring cHemTS¶

Install licenses

Configuring the system

Creating user for the database (ccDB is the default)

Default settings in application.properties

Authentication
Database connection settings
Connecting to a MongoDB cluster cloud
File check settings
Timeout settings

Other settings in application.properties

URL of config server and eureka service
Auto-check/auto-update the latest KB version
User roles in Compliance Checker and in cHemTS
Default regulation categories
Default report format
JSON reports' config
Image number in XSXL report
Scheduled removal of all File-check data
Salt/solvent dictionary for mixture handling
Selecting desired chemical editor

Advanced LDAP settings

Example config for two (LDAP and Active Directory) servers
Example for two Active Directory servers

Okta integration

Compound Registration integration

Merge specific rules into the Knowledge Base

Installing to Multiple Hosts

Config server
Eureka server
Configuring the war files

SSL

Install licences¶

Your license.cxl file(s) should be installed as described in the License Management section.

Configuring the system¶

Config Server is a service of Compliance Checker to populate your settings to other servers (cc-web, cc-api, cc-bigdata and cc-backend). On startup, all of these services require the Config server ** to load their settings from it. **Config server can update some settings runtime, but others need to be updated by restarting the servers.

To customize the application the configuration can be modified by editing the application.properties file.
Any property changed in the application.properties file will affect the appropriate services.
At the clean install, the settings in application.properties.default will be copied to the application.properties file.

At upgrading the software - i.e. installing the new software version - the application.properties file will never be overwritten. So your already customized configuration will not be changed.

Creating user for the database (ccDB is the default)¶

Creating user in MongoDB

# THE DEFAULT DATABASE IS "ccDB". (TO USE THIS, PLEASE UNCOMMENT THE NEXT LINE.)
# use ccDB

db.createUser(
 {
  user:"cxnMongo", 
  pwd:"ccMongoPass", 
  customData: 
   {
    data:"anydata"
   }, 
  roles : [ 
     { 
      role: "clusterAdmin", 
      db: "admin" 
     },
     { 
      role: "readAnyDatabase", 
      db: "admin" 
     },
     "readWrite"
    ] 
 }
)

Default settings in application properties¶

The following default settings in application.properties.default can be modified in the application.properties file (in this format, # stands for comments):

Authentication¶

# Security provider chooses what settings to use for user authentication
## LDAP: uses LDAP server to log in users
## ACTIVE_DIRECTORY: Uses Microsoft's Active Directory service for authentication
## IN_MEMORY: small number of predefined users (recommended only for testing purposes)
## ANONYMOUS: no login required
    common.securityProviderName = IN_MEMORY

Database connection settings¶

The following default database connection settings can also be modified in the application.properties file:

# The MongoDB connection can be configured either by directly setting its Connection String defined by the option `spring.data.mongodb.uri` or setting the `databaseHost`,
# `databasePort`, `databaseName`, `mongoUser` and `mongoPassword` options below. If the `spring.data.mongodb.uri` is not set, the connection string starts with
# "mongodb://{databaseHost}:{databasePort}/{databaseName}" by substituting the corresponding options.
# In order to enable secure database transactions (which is usually default with databases in the cloud), use SRV Connection Format or the explicit TLS options as defined by
# the documentation of your database provider.
    #spring.data.mongodb.uri

# Host of the database
    databaseHost = 127.0.0.1

# The port where MongoDB listens for requests
    databasePort = 27017

# The name of database in MongoDB
    databaseName = test

# Username of database user.
    mongoUser = cxnMongo

# Password of database user.
    mongoPassword = ccMongoPass

Connecting to a MongoDB cluster cloud¶

Connection to a MongoDB cluster cloud (MongoDB Atlas, Amazon DocumentDB) can be configured by inserting the provided mongoDB URI to the application.properties file:

1	`#spring.data.mongodb.uri=<URI PROVIDED BY CLOUD SERVICE>`

For DocumentDB the PEM file should be downloaded, too. (See https://docs.aws.amazon.com/documentdb/latest/developerguide/getting-started.connect.html )

This PEM file should be added to the trusted store:

keytool -import -keystore cacerts -file

The new certificate should be added to the default trusted certificate.

File check settings¶

# These settings set the maximum size of upload for services. These properties also effect the maximum size of DB update as well.
spring.servlet.multipart.max-file-size=256MB
spring.servlet.multipart.max-request-size=256MB


# Search always runs on all available cores.
# If you use PARALLEL, then the system will distinct executors, one for all cores, that can boost the overall system performance and can cause a massive CPU load on server.
# If you use SEQUENTIAL execution strategy then only one executor will run on the server. (For search this executor will use all cores, but it creates a smaller CPU load.)
executionStrategy=PARALLEL


# The priority of Single check and Batch check can be configured by setting *.threadPriority key values between 1 (minimum) and 10 (maximum) priority.
# Default values are 5 for single 3 for batch.
check.single.threadPriority=5
check.batch.threadPriority=3


# This size determines how many molecules are checked in one run.
# If you upload a file with 1000 molecules, and set this property to 25 then the file will be cut to 40 pieces, and 40 executors can start working simultaneously.
chunkSize=10


# The maximum number of explicit atoms in a molecule that should be checked.
check.structure.maxAtomCount=200


# The comma-separated list of strings that are known to be invalid inputs and hence get rejected by CC and cHemTS checks even if they would be otherwise importable as a substance.
#check.structure.knownInvalidInputStrings=


# Speed up of checking Markush structures
searchEngine.enableMarkushAnalyzer=true

Timeout settings¶

# Session timeout settings in seconds or minutes (m)
server.servlet.session.timeout=120m


# If the servers know nothing about a job, then they mark it as dead, and reschedule to process. You can set this checking interval in milliseconds
# through this variable.
common.deadJobTreshold=120000


# Time limit in milliseconds for checking compliance of one target molecule against all selected rules.
# If check reaches this limit then search with the given target is stopped and it is added to the list of errors.
searchEngine.check.timeLimit=60000


# Time limit in milliseconds for checking compliance of one target molecule against one query substance.
# If the check against a substance reaches this limit then checking the given target is stopped and the given target molecule is added to the list of errors.
searchEngine.molSearch.timeLimit=10000

# Communication is load-balanced through Ribbon classes. 
# (https://github.com/Netflix/ribbon/wiki/Programmers-Guide/)
ribbon.ReadTimeout=16000

Other settings in application properties¶

You can configure other settings for Compliance Checker in the application.properties file.

URL of eureka service¶

1 2	`# The URL of eureka service eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/`

Auto-check/auto-update the latest KB version¶

# The URL of the latest Conpliance Checker knowledge base file: 
common.autoUpdateUrl=https://dl.chemaxon.com/cchecker/cc-database.jar 
#The URL of the latest cHemTS knowledge abase file
common.htsAutoUpdateUrl:https://dl.chemaxon.com/hts/hts-knowledge-base.jar

# The URL of the text file containing the version of the latest Compliance Checker knowledge base file.
common.autoUpdateVersionUrl=https://dl.chemaxon.com/cchecker/cc-version.txt 
#The URL of the text file containing the version of the latest cHemTS knowledge base file
common.htsAutoUpdateVersionUrl:https://dl.chemaxon.com/hts/hts-version.txt

common.autoUpdateEnabled=true

# Enables to schedule the knowledge base update automatically.
# The value should be a cron-like expression, which extends the usual UN*X definition to include triggers
# on the second as well as minute, hour, day of month, month and day of week.
# Example patterns:
# "0 0 * * * *" = the top of every hour of every day.
# "*/10 * * * * *" = every ten seconds.
# "0 0 8-10 * * *" = 8, 9 and 10 o'clock of every day.
# "0 * 6,19 * * *" = 6:00 AM and 7:00 PM every day.
# "0 0/30 8-10 * * *" = 8:00, 8:30, 9:00, 9:30 and 10 o'clock every day.
# "0 0 9-17 * * MON-FRI" = on the hour nine-to-five weekdays
# "0 0 0 25 12 ?" = every Christmas Day at midnight
#common.autoUpdateScheduler=0 0 0 * * MON-FRI
# Enables to schedule the cHemTS knowledge base update automatically.
common.htsAutoUpdateScheduler=0 0 1 * * MON-FRI

User roles in Compliance Checker and in cHemTS¶

Roles - with special privileges - can be assigned *to different user groups *:

Compliance Checker

USER : Can execute Single and File checks - against all Countries and those User-defined category groups which are not restricted for the USER by the CONTENT_MANAGER or by the ADMIN.
EXPERT_USER : Can execute Single and File checks - against all Countries and those User-defined category groups which are not restricted for the EXPERT_USER by the CONTENT_MANAGER or by the ADMIN.
CONTENT_MANAGER : Can execute Single and File checks and has limited access to the Administration functions:

-- User-defined category group editor: Select categories and make restrictions for the USER and/or EXPERT_USER roles\,
-- User-defined category editor
-- Database update history
-- Report template editor

ADMIN : Has access to all administration functions.
SYSTEM : A special group to run automatic system checks - with very limited privileges.

Category group access can be controlled according to ROLES.

CHemTS

HTS_USER : Can execute Single cHemTS and File checks
HTS_CONTENT_MANAGER : Can execute Single and File checks and has limited access to the Administration functions: -- Report template editor
HTS_ADMIN : Has access to all administration functions.

User role mapping in Chemaxon Cloud¶

In Chemaxon Cloud the users can be assigned to user groups. Each group translates directly to its corresponding Compliance Checker or cHemTS role according to the mapping below:

cc-user → USER
cc-expert-user → EXPERT_USER
cc-content-manager → CONTENT_MANAGER
cc-admin → ADMIN
hts-user → HTS_USER
hts-content-manager → HTS_CONTENT_MANAGER
hts-admin → HTS_ADMIN

Please find the available roles defined in the previous section: User roles in Compliance Checker and in cHemTS.

Configuring user roles¶

Roles can be assigned directly to special users by setting the value of the config key.
The value should be a comma separated list of ROLES.
(E.g.: roles.username=HTS_USER,HTS_CONTENT_MANAGER)

# You can map user groups to ROLEs in CC and cHemTS by this setting.
 # CC ROLES - We have 5 CC Roles
 # User groups can be mapped to the following Roles:
 # - USER: Can execute Single and File checks - against all Countries and those User-defined category groups
 # which are not restricted for the USER by the CONTENT_MANAGER or by the ADMIN.
 # - EXPERT_USER: Can execute Single and File checks - against all Countries and those User-defined category groups
 # which are not restricted for the EXPERT_USER by the CONTENT_MANAGER or by the ADMIN.
 # - CONTENT_MANAGER: Has limited access to the Administration functions:
 #   -- User-defined category group editor: Select categories and make restrictions for the USER and/or EXPERT_USER roles,
 #   -- User-defined category editor
 #   -- Database update history
 #   -- Report template editor
 # - ADMIN: Has access to all administration functions
 # cHemTS ROLES - We have 3 cHemTS Roles
 # - HTS_USER: Can execute cHemTS Single and File checks
 # - HTS_CONTENT_MANAGER : Can execute Single and File checks and has limited access to the Administration functions: -- Report template editor
 # - HTS_ADMIN : Has access to all administration functions.
 # COMMON ROLES
 # - SYSTEM: A special group to run automatic system checks
 # CC and cHemTS roles can be combined, so for example a user could have both USER and HTS_USER roles.
 # For automated system communication we need to have a SYSTEM user that can log in to the services.
 # The SYSTEM user - with very limited privileges - will use one of the authentication providers 
 # mentioned below, so you must register it in your LDAP / AD server.
     common.systemUser=system
     common.systemPassword=system

 # Roles - with special privileges - can be assigned to different user groups:
     common.rolesToGroupsMap={"userGroups":[],"userPattern":".*","adminGroups":["cc-admin"],"adminPattern":"","contentManagerGroups":["cc-content-manager"],"contentManagerPattern":"","expertUserGroups":["cc-expert-user"],"expertUserPattern":"","systemGroups":["cc-system"],"htsAdminGroups":["hts-admin"],"htsAdminPattern":"","htsContentManagerGroups":["hts-content-manager"],"htsContentManagerPattern":"","htsUserGroups":["hts-user"],"htsUserPattern":"","systemPattern":""}

 # Configuring ROLES
 # - FOR LDAP
 # If you use LDAP, then you can set it's configuration like this: 
 #   {"servers":[{"serverUrl":"ldap://ldap.server.com:389/dc=test,dc=tld","userDNPatterns":["uid={0},cn=users,cn=accounts"],"groupSearchBase":"","managerDN":"uid=cchecker,cn=sysaccounts","managerPassword":"<password>"}]}
 # This is a standard JSON but it has to be in one line. The "servers" property references an array. In this array you can set as many LDAP servers as you want. 
 # These servers will be checked in this specified order, and the first LDAP server that can authenticate the user will authenticate it.
 # The properties stands for the following:
 # "serverURL" -- The URL of the LDAP server
 # "userDNPatterns" -- The domain name of the users in the LDAP tree
 # "groupSearchBase" -- Domain name of groups in LDAP tree
 # "managerDN' -- The domain name of the manager user to query LDAP tree.
 # "managerPassword" -- The password of manager user.
     common.ldapConfig = {"servers":[{"serverUrl":"ldap://ldap.server.com:389/dc=test,dc=tld","userDNPatterns":["uid={0},cn=users,cn=accounts"],"groupSearchBase":"","managerDN":"uid=cchecker,cn=sysaccounts","managerPassword":"<password>"}]}

 # - FOR ACTIVE_DIRECTORY
 # If you use ACTIVE_DIRECTORY, then you can set you can set it's configuration like this: 
 #   {"servers":[{"domain":"your.domain","url":"ldap://server.domain.com"}]}
 # This is a standard JSON but it has to be in one line. The "servers" property references an array. 
 # In this array you can set as many Active Directory servers as you want. 
 # These servers will be checked in this specified order, and the first AD server that can authenticate the user will authenticate.
     common.activeDirectoryConfig={"servers":[{"domain":"your.domain","url":"ldap://server.domain.com"}]}

 # - FOR IN_MEMORY
 # If you are using IN_MEMORY authentication manager, you can configure it like this:
 #   {"users":[{"name":"<user>","password":"<userpwd>","roles":["USER"]}, {"name":"<admin>","password":"<adminpwd>","roles":["ADMIN"]}, {"name":"contentmanager", "<password>": "<contentmanagerpwd>", "roles":["CONTENT_MANAGER"]}, {"name":"expertuser", "<password>": "<expertuserpwd>", "roles":["EXPERT_USER"]}, {"name":"system","<password>":"system","roles":["SYSTEM"]}]}
 # This is a standard JSON but it has to be in one line. The "servers" property references an array. 
     common.inMemoryConfig = {"users":[{"name":"user","password":"password","roles":["USER"]},{"name":"admin","password":"adminPass","roles":["ADMIN"]},{"name":"contentmanager","password":"password","roles":["CONTENT_MANAGER"]},{"name":"expertuser","password":"password","roles":["EXPERT_USER"]},{"name":"system","password":"system","roles":["SYSTEM"]},{"name":"hts_user","password":"hts_password","roles":["HTS_USER"]},{"name":"hts_admin","password":"hts_adminPass","roles":["HTS_ADMIN"]},{"name":"hts_contentmanager","password":"hts_password","roles":["HTS_CONTENT_MANAGER"]}]}

 # - DIRECT ROLE ASSIGN
 # Roles can be assigned directly to special users by setting the value of the config key.
 # The value should be a comma separated list of ROLES. 
 # Currently available roles are: USER, EXPERT_USER, CONTENT_MANAGER, ADMIN, SYSTEM.
#   roles.<username>=<roles>

Default regulation categories¶

Admin can select Available countries or Selected check levels to be displayed in Regulation categories by setting check.default.regulationCategories key to COUNTRIES or CHECK_LEVELS in application.properties.

By adding/setting the check.hideCountries key value to true (default is false ) Available countries will not be displayed at all.

(On the System monitor page the Reload settings from config file button should be clicked after editing application.properties.)
Default regulation categories

# The default view for Regulation Categories. Valid values are: COUNTRIES, CHECK_LEVELS
#check.default.regulationCategories=CHECK_LEVELS


# Setting this to true will only display the check levels as selectable categories on the check pages
#check.hideCountries=true

Default report format¶

The default Report format can be set by the Admin by adding HTML , PDF , SDF , MRV or XLSX value to the batch.default.reportFormat key in application.properties.

(User's last selection is saved in the mongo DB and will not be modified.)
Default report format

1 2	`# The default report format for batch checks. Valid values are: HTML,PDF,SDF,MRV,XLSX #batch.default.reportFormat=HTML`

JSON reports' config¶

# Comma separated list of fields to be included in the JSON reports.

# Including only needed fields in JSON reports can greatly increase the speed of report generation

# To include child fields, parent fields also have to be listed

# If none of the listed fields are present in the result or the config key is not set
# then the full result will be added to the report

# Example: 
# [ 
#    [
#       { 
#          "segments":[ 
#             { 
#                "categoryName":"catName", 
#                "categoryCode":1234 
#             } 
#          ], 
#          "inputProperties":{ 
#             "ID":"123", 
#             "Name":"Name" 
#          } 
#       } 
#    ] 
# ] 

#
 To include only the categoryCode and ID in the JSON report from the above example result 
# the following configuration has to be made: 
#json.report.fields=segments,categoryCode,inputProperties,ID

Image number in XSXL report¶

The report.xlsx.max-image-count parameter sets the maximum number of images generated in .XSXL reports. The default number is 10000. Setting this parameter may prevent the service going down with out of memory error.

1	`report.xlsx.max-image-count=10000`

# Enables to schedule the removal of all check related data from the database.
# The value should be a cron-like expression, which extends the usual UN*X definition to include triggers
# on the second as well as minute, hour, day of month, month and day of week.

# Example patterns:
# "0 0 * * * *" = the top of every hour of every day.
# "*/10 * * * * *" = every ten seconds.
# "0 0 8-10 * * *" = 8, 9 and 10 o'clock of every day.
# "0 * 6,19 * * *" = 6:00 AM and 7:00 PM every day.
# "0 0/30 8-10 * * *" = 8:00, 8:30, 9:00, 9:30 and 10 o'clock every day.
# "0 0 9-17 * * MON-FRI" = on the hour nine-to-five weekdays
# "0 0 0 25 12 ?" = every Christmas Day at midnight
#batch.cleanup.scheduler=0 0 4 * * *

Salt/solvent dictionary for mixture handling¶

cHemTS leverages advanced mixture algorithm in order to be able to decide whether a particular multi-fragment input structure can be classified as a pure form, a salt or a mixture.

The algorithm can be fine-tuned by amending the list of known ignorable fragments. These fragments are either entirely discarded (in case of solvents or additives) or their salt characters are taken into consideration by the algorithm.

Ignorable fragments can be excluded or included on demand, the following configuration options need to be changed accordingly:

1 2	`hts.search.mixture.ignorablefragments.included=[...] hts.search.mixture.ignorablefragments.excluded=[...]`

Multiple structures can be listed separated by comma. E.g.

1	`hts.search.mixture.ignorablefragments.excluded=Br,CC(O)=O`

Each structure must be represented by SMILES format. In case of including new salts, their characters must be also set. Salt characters can be separated from the structure by semicolon. E.g.

1	`hts.search.mixture.ignorablefragments.included=SC#N;acidic`

Selecting desired chemical editor¶

The preferred chemical editor can be selected by setting this configuration key. It accepts two possible values: MARVIN_JS or MARVIN. The chosen editor requires the appropriate license as a prerequisite. The default value is MARVIN_JS.

1	`tools.chemical-editor=MARVIN_JS`

Advanced LDAP settings¶

Our LDAP configuration object is a list of configurations of LDAP servers.

Each server configuration can hold several attributes. Each of them can be left empty, left out from configuration string or can be set to null.

In this case, they will be used by their default values.

One server holds the following possible settings:

Attribute name	Attribute type	Default value	Example	Explanation
serverUrl	String	ldap://localhost:389	"ldaps://ldap.mycompany.com:621" or "ldap://ldap2.cmp.com/dc=cmp,dc=com"	The URL where the system can reach the LDAP server.
userDNPatterns	List of Strings	[ ]	[ "uid={0},dc=mycompany,dc=com", "uid={0},ou=internal,dc=mycompany,dc=com" ]	These patterns will be used to find the User by its distinguished name.The part between the curly brackets will be replaced by the username.If this setting is left empty, then user distinguished name won't be used in the user authentication.
groupSearchBase	String	""	"ou=InternalGroups,dc=mycompany,dc=com"	The base DN from which the search for group membership should be performed.
groupSearchFilter	String	""	"(member={0})"	The pattern to be used for the user search. {0} is the user's DN
userSearchBase	String	""	"ou=Users,dc=mycompany,dc=com"	This element of the LDAP tree will be used as the root element during user search. In case it is left empty, the root of the LDAP tree will be used. If you use userSearchFilter, than you must provide userSearchBase as well.
userSearchFilter	String	""	"sAMAccountName={0}"	In case the users are not found by their distinguished name, user search will happen. The part with the curly brackets will be replaced with the username that used to log in. In case of Active Directory, usually sAMAccountName is required to log in. You can not use userSearchFilter without userSearchBase.
managerDN	String	""	"dn=admin,dc=mycompany,dc=com" or "admin@mycompany.com"	This is the name of the manager user. This name will be used to bind to the LDAP server. The second format can be used to log in to Active Directory through LDAP.
managerPassword	String	""	"s3cr3tp455w0rd"	This is the password of the manager user.
root	String	""	"dc=mycompany,dc=com"	In case the serverURL does not contain the root of the LDAP search, then it can be set here. If it is left empty, then root from URL will be used. Active Directory usually requests root to be set separately for binding.

Example config for two (LDAP and Active Directory) servers¶

This configuration uses two servers (an LDAP and an Active Directory) and has all attributes:
LDAP config

{
    "servers" : [{
            "serverUrl" : "ldap://ldap1.mycompany.com/dc=mycompany,dc=com",
            "userDNPatterns" : ["uid={0},cn=users,dc=mycompany,dc=com", "uid={0},cn=external,dc=mycompany,dc=com"],
            "groupSearchBase" : "",
            "groupSearchFiler" : "",
            "userSearchBase" : "",
            "userSearchFilter" : "",
            "managerDN" : "uid=admin,cn=sysusers,dc=mycompany,dc=com",
            "managerPassword" : "PASSWORD!",
            "root" : ""
        }, {
            "serverUrl" : "ldaps://ad.mycompany.com/dc=cmp,dc=com",
            "userDNPatterns" : [],
            "groupSearchBase" : "",
            "groupSearchFiler" : "",
            "userSearchBase" : "dc=cmp,dc=com",
            "userSearchFilter" : "sAMAccountName={0}",
            "managerDN" : "Administrator@cmp.com",
            "managerPassword" : "other_PASSWORD!",
            "root" : "dc=cmp,dc=com"
        }
    ]
}

This means the same as the following:
Shorter Config

{
    "servers" : [{
            "serverUrl" : "ldap://ldap1.mycompany.com/dc=mycompany,dc=com",
            "userDNPatterns" : ["uid={0},cn=users,dc=mycompany,dc=com", "uid={0},cn=external,dc=mycompany,dc=com"],
            "managerDN" : "uid=admin,cn=sysusers,dc=mycompany,dc=com",
            "managerPassword" : "PASSWORD!"
        }, {
            "serverUrl" : "ldaps://ad.mycompany.com/dc=cmp,dc=com",
            "userSearchBase" : "dc=cmp,dc=com",
            "userSearchFilter" : "sAMAccountName={0}",
            "managerDN" : "Administrator@cmp.com",
            "managerPassword" : "other_PASSWORD!",
            "root" : "dc=cmp,dc=com"
        }
    ]
}

Consider using the shorter config format because in application.properties, the config must be in one single line , like this:
Config in one line

{"servers" : [{"serverUrl" : "ldap://ldap1.mycompany.com/dc=mycompany,dc=com", "userDNPatterns" : ["uid={0},cn=users,dc=mycompany,dc=com", "uid={0},cn=external,dc=mycompany,dc=com"], "managerDN" : "uid=admin,cn=sysusers,dc=mycompany,dc=com", "managerPassword" : "PASSWORD!"}, { "serverUrl" : "ldaps://ad.mycompany.com/dc=cmp,dc=com", "userSearchBase" : "dc=cmp,dc=com","userSearchFilter" : "sAMAccountName={0}", "managerDN" : "Administrator@cmp.com", "managerPassword" : "other_PASSWORD!", "root":"dc=cmp,dc=com"}]}

Example for two Active Directory servers¶

Example settings for 2 Active Directory servers

{
    "servers": [
        {
            "domain" : "first.domain",
            "url" : "ldap://first.com"
        } ,
        {
            "domain" : "second.domain",
            "url" : "ldap://second.com"
        } 
    ]
}

// Don't forget that you have to set it in the <code>application.properties</code> file in one line.
// Like this: { "servers": [    {"domain" : "first.domain", "url" : "ldap://first.com"} , {"domain" : "second.domain", "url" : "ldap://second.com"} ]}
// We only used multi line example for better readability.

Okta integration¶

Okta integration is supported for service 'cc-web' from version 23.8.0.

To integrate Compliance Checker UI (cc-web) with Okta the following configuration steps need to be made:

Create App Integration in Okta
- Log into Okta
- Select 'Applications'
- Click 'Create App Integration'
- Select 'OIDC - OpenID Connect'
- Select 'Web Application'
- Set 'App integration name' to a unique name.
- Set 'Sign-in redirect URIs' to 'https:///cc-web/authorization-code/callback'
- Set 'Sign-out redirect URIs' to 'https:///cc-web/logout'
- Set 'Assignments' the way you want to control access

Add the following lines to cc-web's configuration file (
/cc-web/application.properties)
- spring.profiles.active=production,okta
- okta.oauth2.issuer=
- okta.oauth2.client-id=
- okta.oauth2.client-secret=
- okta.oauth2.redirect-uri=/authorization-code/callback
- okta.oauth2.post-logout-redirect-uri=https:///cc-web/logout

Custom scopes and groups claim can also be configured if needed by adding the following configs:
- okta.oauth2.scopes=
- okta.oauth2.groups-claim=

If you are running cc-web behind a reverse proxy, be sure to add these configs too:
- server.use-forward-headers=true
- server.tomcat.remoteip.remote-ip-header=x-forwarded-for
- server.tomcat.remoteip.protocol-header=x-forwarded-proto

Map Okta groups to desired Compliance Checker roles by editing config 'common.rolesToGroupsMap' in main config file (/cc-config/config/application.properties)
Restart Compliance Checker services so configurations can take effect

Note: Okta integration only implemented for Compliance Checker UI (cc-web). To protect the integration endpoints (cc-api) you have to chose from one of the already existing authentication methods.

Compound Registration integration¶

Chemaxon Compound Registration integration has been available since Compliance Checker version 24.3.0. This version supports integration only with on-premise deployments.

Integrating the Compliance Checker with Chemaxon Compound Registration enables the direct use registration IDs as inputs in Compliance Checker for single and file checks, as well as API calls, without the need to manually or programmatically translate them into other known chemical formats such as SMILES. The supported ID types include: PCN (Parent Compound Number), CN (Compound Number), LN (Lot Number) and LnbRef (Laboratory NoteBook Reference). Please refer to the ID types defined on this Definition of Terms page.

To integrate, follow these configuration steps:

Register Compliance Checker as a trusted 3^rd party client in Compound Registration following the steps describend in Compound Registration - Authentication for trusted 3^rd party clients.

Add the following lines to the application.properties file of Compliance Checker:

  compound-registration.uri=https://<Compound Registration host>/RegistryCxn/rest
  compound-registration.api-client=<client name set in the previous step>
  compound-registration.api-secret=<symmetric authentication key set in the previous step>
  compound-registration.id-pattern=<regular expression matching possible IDs>

Restart the Compliance Checker
After restarting, single and file checks, as well as API endpoint checks, should be able to resolve compounds that were previously registered in Compound Registration.

Please note that the URI following the Compound Registration host may vary and depending on your specific deployment. Any change to the config options listed above will require a restart of Compliance Checker.

The id-pattern must be a valid Java Regular Expression. Since regular expressions might contain the backslash \ character, which is interpreted as a special-purpose character while the application is parsing the application.properties configuration file, escaping backlashes with double backslashes is necesary.
This pattern is intended to describe all possible registration IDs to be checked by the Compliance Checker application. If a pattern matches an input, but it is not found in Compound Registration, the check will fail.

Before proceeding with the integration of your systems, we strongly recommend scheduling a consultation to discuss the security aspects involved.

Merge specific rules into the Knowledge Base¶

Chemical substances can be checked against some special (e.g. company-specific) rules, too.

MRV files should be created from these rules - with the same data structure as the main Knowledge Base. An MRV file for the specific rules ( rule_structures.mrv ) and another MRV file for the specific exceptions ( exclusion_structures.mrv ).

These files should be copied to the Chemaxon_home/compliancechecker/user folder. (I.e. to the "user" subfolder of the "database" folder. The cc_backend startup process creates that folder with empty MRV files - but these files will never be overwritten automatically.)

Compliance Checker should be restarted to merge these specific rules into the main Knowledge Base.

Installing to Multiple Hosts¶

If you distribute the system you should set the following settings to the services:

Config server¶

Config server is the route of the hierarchy. It should register with Eureka service. If Eureka does not run in localhost:8761 (8761 is the default Eureka port) then you have to set the following property in the application.properties file:

eureka.client.serviceUrl.defaultZone=http\://<eureka-hostname>\:<eureka-port>/eureka/

If Eureka runs locally for the Config Server , but it is a remote service for the other services, then you should set the above property with an address that is available for all services, because this setting will be populated to all services.

Eureka server¶

Eureka server is used by all the services. It uses the Config Server to init itself. If the Config Server does not run in localhost:8888 (8888 is the default Config Server port), then you can have to set the following property in bootstrap.properties file:

spring.cloud.config.uri=http\://<config-server-host>\:<config-server-port>/

Configuring the war files¶

The main components of the application come in 4 war files: cc-backend.war, cc-bigdata.war, cc-web.war, cc-api.

Every war file uses the Config Server to init itself. If the Config Server does not run in localhost:8888, then you have to set for the components where to find the Config Server. One opportunity is to set the CONFIG_SERVER_URI environment variable, or to edit the bootstrap.properties file next to each war file. Or you can set in it in their .vmoptions file.
Setting environment variable in unix

export CONFIG_SERVER_URI = http://<config-server-host>:<config-server-port>/

Setting environment variable in windows command line

CONFIG_SERVER_URI = http://<config-server-host>:<config-server-port>/

Set environment variables in .vmoption file

-DCONFIG_SERVER_URI=http://<config-server-host>:<config-server-port>/

Editing bootstrap.properties file

spring.cloud.config.uri=http\://<config-server-host>\:<config-server-port>/

This property will be used in startup time to connect to the Config Server and receive all the properties to use in initialization.

SSL¶

While it is possible to configure the cc-web service to enable SSL so that the users can access the UI directly via HTTPS, we would first recommend to consider the option of using an application load balancer or reverse proxy (such as NGINX) with SSL termination.

In order to enable SSL for cc-web via its configuration, please follow the next steps:

Obtain your certificate file.
Import the certificate using the keytool command of your Java distribution. The exact way of doing this is out of the scope of this documentation as it depends on many factors such as the format of the certificate, which certificate store is supposed to be used, etc.
Add the following lines below to cc-web's configuration file (/cc-web/application.properties):

eureka.instance.non-secure-port-enabled=false
eureka.instance.secure-port-enabled=true
security.require-ssl=true
# The format used for the keystore
server.ssl.key-store-type=<format>
# The path to the keystore containing the certificate
server.ssl.key-store=<path to jks file>
# The password used to generate the certificate
server.ssl.key-store-password=<password>
# The alias mapped to the certificate
server.ssl.key-alias=<alias>

Configuring cHemTS¶

Install licences¶

Configuring the system¶

Creating user for the database (ccDB is the default)¶

Default settings in application properties¶

Authentication¶

Database connection settings¶

Connecting to a MongoDB cluster cloud¶

File check settings¶

Timeout settings¶

Other settings in application properties¶

URL of eureka service¶

Auto-check/auto-update the latest KB version¶

User roles in Compliance Checker and in cHemTS¶

User role mapping in Chemaxon Cloud¶

Configuring user roles¶

Default regulation categories¶

Default report format¶

JSON reports' config¶

Image number in XSXL report¶

Scheduled removal of all check related data¶

Salt/solvent dictionary for mixture handling¶

Selecting desired chemical editor¶

Advanced LDAP settings¶

Example config for two (LDAP and Active Directory) servers¶

Example for two Active Directory servers¶

Okta integration¶

Compound Registration integration¶

Merge specific rules into the Knowledge Base¶

Installing to Multiple Hosts¶

Config server¶

Eureka server¶

Configuring the war files¶

SSL¶