Multi-tenant creation process

Follow this roadmap to create Counter Fraud tenants. On average, new tenant creation takes approximately 50 minutes to complete. Due to differences in hardware performance and the variance in DB2 import options, this time can vary.

The multi-tenant creation process includes the following steps:

Prepare your ICFM environment. See Preparing to create Counter Fraud tenants for details.
Copy the newTenant.properties.template file, located in the icfminstall/cf20_install/installs/production/cfm20/application/CFM/multitenancy/properties directory. For example, copy and rename this file to /icfmmulti/properties/NewTenant.properties. See Creating Counter Fraud tenants for details.
Create a database instance with a database in the existing database management system.
The tenant creation program populates the existing database management system on the Data server with a new instance and corresponding database. The program copies all <SCHEMA>.<TABLE> entries from the original installation to the new tenant database. The database is then created, configured, and customized, based on properties that are specified in one of the main scripts (see create-db2-tenant-linux.sh) and any additional tables that are defined in the tableFile.lst file. The following properties within the new tenant properties file (for example, NewTenant.properties) are of particular importance for DB2:
- cfm_tenant.db2.user – Specifies a user that is created as the new DB2 instance owner.
- cfm_tenant.db2.userpass – Specifies the password for the new DB2 instance owner.
- cfm_tenant.db2.port – Specifies a TCP/IP port that is reserved for use with DB2. A free port must be specified.
- cfm_tenant.db2.ssl.port – Specifies a TCP/IP secure port that is reserved for use with DB2. A free port must be specified.
- cfm_tenant.db2.dbname – Specifies the name of the DB2 database that is created for the new tenant.
- cfm_tenant.db2.ssl.dn – Specifies the DN string that is used for DB2 certificates in the new tenant.
The new tenant properties file contains a property that is named cfm_tenant.db2.validate.tables. Property values can be true or false. Each <SCHEMA>.<TABLE> within the tableFile.lst file is checked to ensure that it is valid, and if the named table has any related tables, that these tables are also specified on the list. If cfm_tenant.db2.validate.tables=false and an invalid table is detected (or any required tables are missing), the process fails. If cfm_tenant.db2.validate.tables=true, invalid tables are removed and required tables added. The process then continues with the updated list.
Create a queue manager and required queues in the existing IBM WebSphere MQ installation.
The existing IBM WebSphere MQ installation, which is on the Core server, is populated with a new queue manager with all queues that are copied from the base installation queue manager. You can specify the queue manager name and configuration options by editing the main properties file (properties starting with cfm_tenant.mq.*). The following properties within the new tenant properties file are of particular importance to MQ:
- cfm_tenant.mq.admin – Specifies a user that is created as the MQ user for the new tenant.
- cfm_tenant.mq.admin.password – Specifies the password for the new MQ user.
- cfm_tenant.mq.qm – Specifies a name for the new MQ Queue Manager.
- cfm_tenant.mq.port – Specifies a TCP/IP port reserved for use with MQ. A free port must be specified.
- cfm_tenant.mq.sslport – Specifies a TCP/IP secure port reserved for use with MQ. A free port must be specified.
- cfm_tenant.mqtt.port – Specifies a TCP/IP port reserved for use with MQTT. A free port must be specified.
Create a WebSphere cluster and server in the existing WebSphere Application Server ICFM node and profile.
The tenant creation program uses the existing WebSphere Application Server deployment manager to create a new tenant cluster and server under the existing ICFM node and profile. The configuration requires DB2 and MQ data sources (created in previous installation steps). Similar to the base installation, SSL communication is configured for the DB2 data source. You can specify the name and configuration of the new cluster (and associated resources) by editing the main properties file (properties starting with cfm_tenant.was.*). The following properties within the new tenant properties file are applicable to WebSphere Application Server:
- cfm_tenant.was.admin.password – Specifies the WebSphere Applicable Server administrator password (if changed from the default).
- cfm_tenant.was.engine.userPass – Specifies the ICFM engine user password (if changed from the default).
- cfm_tenant.was.new.clustername – Specifies the name of the new ICFM cluster that is created for the new tenant.
- cfm_tenant.was.new.servername – Specifies the name of the new ICFM server that is created for the new tenant.
You can also edit the cfm_tenant.was.batch.jobs property to transfer batch jobs that exist on the base installation system to the new tenant.
Note: There is only one job manager for the WebSphere Application Server instance; therefore, all jobs for all provisioned tenants are visible within the single job manager. However, keep in mind that jobs run on the tenant system for which they are configured.
Create an integration node and integration server.
The tenant creation program creates a new integration node with a companion integration server, which is associated with the queue manager that was created in Step 4. You can specify the name of this new integration node and server by editing the main properties file (properties starting with cfm_tenant.iib.*). The following properties within the new tenant properties file are of particular importance for IIB:
- cfm_tenant.iib.user – Specifies a user that is created as the IIB user for the new tenant.
- cfm_tenant.iib.userpass– Specifies the password for the new IIB user.
- cfm_tenant.iib.server – Specifies the name of the new IIB execution group for the new tenant.
- cfm_tenant.iib.node – Specifies the name of the new IIB node for the new tenant.
Review and complete post mulit-tenant creation tasks that are relevant to your deployment. For example, after you create a WebSphere MQ queue manager and integration node, you must copy any existing message flows.

Instructions are included in the following topics:

Preparing to create Counter Fraud tenants
Before running the installation script to create new Counter Fraud tenants, you must prepare your environment by verifying server-to-server connectivity and updating your Linux packages.
Creating Counter Fraud tenants
To create one or more Counter Fraud tenants, you must customize the tenant creation property file and then run the tenant creation program.
Post multi-tenant creation considerations
Depending on your particular deployment needs, here are some items to consider after multi-tenant creation.
Verifying tenant creation
When a tenant is created, the data from the base CFCONFIG.SYSTEM_PROPS table is copied over to the new tenant. It is a good idea to verify that this new directory structure exists. You can also conduct a system check to ensure that your system is configured correctly, has valid connections, and that system properties include the correct values.

Parent topic: Supporting multiple tenants on an ICFM instance (optional)

Related concepts:

Planning considerations for multi-tenancy support

Uninstalling multi-tenancy support