Configuring multi-partitions for Campaign

For Unica Campaign, you can configure the application within the partitions where you have configured an instance of Campaign.

Application users, within each partition, can access the Campaign functions, data, and customer tables that are configured for Campaign in the same partition.

Multiple partitions are useful for setting up a strong security between groups of users, because each partition has its own set of Campaign system tables.

You must not create multiple partitions if groups of users have to share data with each other.

Each partition has its own set of configuration settings. You can customize Campaign for each group of users. However, all partitions share the same installation binaries.

With the same binaries for all partitions, you can minimize the installation and upgrade efforts for multiple partitions.

The utility to create multi-partition is available in the $HOME_DIR/Platform/tools/bin location.

Provide values for the following paramters in the Campaign chart:

  • PARTITIONS - Name of the partition you want to configure. In case of multiple partitions specify partition name separated by a semi-colon. For example partition2;partition3.
  • SOURCE_PARTITION - The name of the source partition to be replicated.
  • DEST_PARTITION - The name of the destination partition to be created.
  • PARTITION_USER - Specifies the user name of the admin user for the replicated partition. The name must be unique within the instance of Unica Platform.
  • PARTITION_GROUP - Specifies the name of the Platform admin group that the utility creates. The name must be unique within the instance of Unica Platform.
  • CAMPAIGN_PARTITION2_DATABASE_HOST - Host system details of the system hosting the Campaign Partition2 database.
  • CAMPAIGN_PARTITION2_DATABASE_PORT - Port number of the Campaign Partition2 database.
  • CAMPAIGN_PARTITION2_DATABASE_NAME - Name of the Campaign Partition2 database.
  • CAMPAIGN_PARTITION2_DATABASE_USERNAME - Username to access the Campaign Partition2 database.
  • CAMPAIGN_PARTITION2_DATABASE_PASSWORD - Password to access the Campaign Partition2 database.
  • CAMPAIGN_PARTITION2_DS_INITIAL_SIZE - The initial size of the Campaign Partition2 datasource connection pool.
  • CAMPAIGN_PARTITION2_DS_MIN_IDLE - The minimum number of idle connections (not connected to a database) in the Campaign Partition2 datasource connection pool.
  • CAMPAIGN_PARTITION2_DS_MAX_IDLE - The maximum number of idle connections (not connected to a database) in the Campaign Partition2 datasource connection pool.
  • CAMPAIGN_PARTITION2_DS_MAX_TOTAL - The maximum number of connections that the Campaign Partition2 datasource can hold. If the number of connection requests exceed the configured value, the connection will be refused.
  • CAMPAIGN_PARTITION2_DS_STATEMENT_CACHE_SIZE - Maximum number of statements that can be cached in the Campaign Partition2 datasource. Statement caching improves performance by caching executable statements that are used repeatedly.
  • CAMPAIGN_PARTITION2_JNDI_NAME - JNDI name for Campaign Partition2.
  • CAMPAIGN_PARTITION2_POOL_NAME - Pool name for Campaign Partition2.
The syntax to generate a partition is:
./multiPartition.sh >> output.out

After running the utitilty, restart the Platform and Campaign pod. After restarting the pods, login with platform_admin.

You can login with PARTITION_USER and the partition name you specify is used as the password for the admin user