This chapter describes how to export and import partitions in WebLogic Server Multitenant (MT). You can use either Fusion Middleware Control (FMWC), the WLS Administration Console, or WLST to export and import partitions, as described in this chapter. The chapter refers to the Fusion Middleware and WebLogic Server documentation sets and online for additional information as appropriate.
This chapter includes the following sections:
Exporting and Importing Domain Partitions: Main Steps and WLST Examples
Exporting and Importing Domain Partitions: Related Tasks and Links
Using WLST (online or offline), a REST API (online only), or an administration console (online only), administrators can export a domain partition and then import a previously exported partition into a different domain.
Exporting and importing partitions lets you easily move partitions from one domain to another, including the applications that are deployed to the partition. This feature is useful for replicating partitions across domains and for moving domains from a development to a production environment.
When a partition is exported from the source domain it is packaged in a partition archive which includes:
The partition configuration.
Any resource groups contained in the partition.
Any resource group templates referred to by those resource groups.
The contents of the partition's file system, <partition-file-system>/config directory.
Optionally, application binaries and configurations for applications deployed to the partition.
No application runtime state, nor application-specific runtime configuration is included in the partition archive. Other examples of what would not be exported are JMS messages in queues and users in an embedded LDAP realm.
You can use the WLST exportPartition command to create a partition archive, <PartitionName>.zip. It copies a partition's configuration into the archive file as well as (optionally) the partition's applications and libraries. This command also creates the attributes.json file that you can use to modify the partition's configuration on import.
The command syntax is:
exportPartition(partitionName, expArchPath, [includeAppsNLibs], [keyFile])
Where partitionName is the name of the partition to export, expArchPath is the full path to the directory in which to save the partition archive, includeAppsNLibs, optionally, specifies whether to include application and library binaries in the partition archive, and keyFile, optionally, provides the full path to a file containing a string to use as the encryption key to encrypt attributes in the partition archive. See Exporting Domain Partitions: WLST Example.
A partition archive is a ZIP file containing these specific partition-related files:
| Files and Directories | Description |
|---|---|
partition-config.xml |
Contains the partition configuration and resource group templates configuration from config.xml. |
MANIFEST.MF |
Includes a time stamp and domain information for the archive. |
<PartitionName>-attributes.json |
Contains the MBean attributes and properties which can be changed by the administrator while importing the partition. In addition to being contained in the archive, a copy of this file is also located with the archive in the file system to make it easier to update. |
expPartSecret |
Contains the encrypted secret key used for encrypting and decrypting encrypted attributes. |
domain/config/resource-group-templates/<resource_template_name>/* |
If there is a resource group template associated with this partition, then the files related to the resource group template are copied to this location. |
domain/config/partitions/<partition-name>/* |
All the configuration files under domain/config/partitions/<partition-name>/config/*. |
pfs/config/* |
Contains the <partition-file-system>/config directory content. This would also include system resources (JMS, JDBC, and such) descriptor files. |
domain/upload/resource-group-templates/<resource_template_name>/<application_name>/ |
Contains resource group template-level binaries. |
pfs/upload/<application_name>/ |
Contains resource group-level application binaries. |
A prerequisite to importing a partition is that the server instance must already have a domain configured. When a partition is imported into a new domain some external systems may need to be configured to be aware of the newly imported partition. While importing a partition archive the system administrator may need to update the dependencies on the domain (like virtual targets, security realms, and resource group templates) and also optionally update other attributes in the partition configuration to make it valid, such as partition properties, JDBC, JMS, and other resources in resource groups. In addition, applications and system resources need to be deployed for the new partition.
During the import, the system administrator can override specific portions of the partition configuration by supplying a <PartitionName>-attributes.json file with modified attributes suitable for the target domain. However, changing the value of the name attribute is not supported; for example, "name" : "P1" in the following sample <PartitionName>-attributes.json cannot be changed.
{
"partition" : {
"name" : "P1",
"jdbc-system-resource-override" : {
"URL" : "url.com",
"Id" : "0",
"name" : "test123",
"CachingDisabled" : "false",
"Registered" : "false",
"User" : "test123",
"DynamicallyCreated" : "false",
"DataSourceName" : "test-source"
},
"resource-group-template" : {
"name" : "RGT1",
"jdbc-system-resource" : {
"name" : "jdbc1",
"descriptor-file-name" : "jdbc/P1DB1-8882-jdbc.xml"
}
"jms-server-resource" : {
"name" : "jms1",
"PagingDirectory" : ""
}
}
}
In the above example, all the JDBCSystemResourceOverrideMBean attributes are copied to the <PartitionName>-attributes.json file along with their current values.
If a resource group template already exists in the target domain, you must use the createNew option to overwrite the existing resource group template and create a new one using a new name. (See step 2 in Importing Domain Partitions: Main Steps.)
When a partition is exported, whether or not application binaries are included in the partition archive is determined by the value of the includeApps option on the export operation. If includeApps is true, the binaries are included. If false, they are excluded. The <PartitionName>-attributes.json file contains attributes for the application or library source path, deployment plan path, and staging mode. You can change these attributes in the <PartitionName>-attributes.json file.
The includeApps option also effects how the application is deployed upon being imported:
If true (default), the deployment files are copied over to <domain-dir>/<server>/upload or <partition-dir>/<server>/upload, depending on whether it's a resource group template-level application or resource group-level application, and deployed using the original staging mode. If the staging mode is NOSTAGE or EXTERNAL (on the targeted server), then the system administrator is responsible for making the application available from the correct location in the target domain.
If false, the system administrator is responsible for making the application available from the correct location in the target domain.
During the export operation, a new secret key is generated and stored in the expPartSecret file in the exported <PartitionName>.zip file. All the encrypted attributes in partition-config.xml and any system resource descriptors that are part of <PartitionName>.zip will be encrypted using the new secret key in the expPartSecret file. Alternatively, you can provide your own secret key by using the keyFile option.
During the import operation, after the entire partition is read and the attributes changed in accordance with the <PartitionName>-attributes.json file, the following steps are used to process encrypted attributes:
First, the secret key in the expPartSecret file in the exported ZIP is read.
Then the secret key is decrypted using a second key that is either the default key in the WLS source, or the key provided using the keyFile option to import. The user provided key must match the key used on import.
Then, all the encrypted attributes in the partition MBean (read and modified in the exporting operation) are decrypted using the key read from expPartSecret.
Then, all the encrypted attributes in the partition MBean are encrypted with the domain-specific key (SerializedSystemIni.dat) for the imported domain.
You can export a domain partition (the source domain) with its entire configuration and data, as a partition archive. With few configuration changes, you can then import the partition archive into another instance of multitenant WLS (the target domain). You might need to update domain dependencies, such as virtual targets and security realms, and optionally update other attributes in the partition configuration to make it valid.
Prior to exporting a domain partition, you must first have created or imported one.
The main steps for exporting domain partitions are as follows:
Select the domain partition you want to export.
Provide the full path to the directory in which to save the partition archive.
Each domain partition should be located in its own directory. The domain partition archive will be overwritten if it already exists in the specified location. Other files in the directory may be overwritten as well.
Optionally, select to include the installed application and library binaries in the exported partition archive.
Optionally, enter the full path to a file containing a string to use as the encryption key to encrypt attributes in the partition archive.
If you do not provide your own key, a new secret key will be generated and stored in the expPartSecret file in the exported <PartitionName>.zip file.
The following WLST command exports partition-1 to the /var/tmp directory. Application and library binaries are not included. /home/foo/mykeyfile is the path to the mykeyfile encryption key.
wls:/mydomain/serverConfig> exportPartition("partition-1", "/var/tmp/", false, "/home/foo/mykeyfile")
Prior to importing a domain partition:
You must have previously exported a domain partition (the source domain) to a partition archive file.
The server instance must already have a domain configured (the target domain).
The main steps for importing domain partitions are as follows:
Provide the full path to the partition archive file you want to import.
Optionally, select the overwrite existing resource group templates if the resource group template already exists in the target domain and you want to create a new one using a new name.
All resource group templates used by the source domain partition are contained in the partition archive and are imported along with the partition into the target domain. If the resource group template already exists in the target domain and you do not specify to overwrite the existing resource group template, the import operation will fail.
Optionally, specify a name to use for the partition when it is created in the target domain. This defaults to the original name of the partition.
Optionally, enter the full path to a file containing the key to decrypt attributes in the partition archive.
The following WLST command imports the partition-1 archive located in the /var/tmp directory. Application and library binaries are not included. The file /home/foo/mykeyfile is used as the encryption key.
wls:/mydomain/serverConfig> importPartition("/var/tmp/partition-1.zip", keyFile="/home/foo/mykeyfile")
For additional information, see the following:
"Export domain partitions" and "Import domain partitions" in Administering Oracle WebLogic Server with Fusion Middleware Control.
"Export partitions" and "Import partitions" in Oracle WebLogic Server Administration Console Online Help.