32 Deploying Portals, Templates, Assets, and Extensions
Note:
Oracle WebCenter Portal has deprecated the support for Jive features (announcements and discussions). If you have upgraded from a prior release to Release 12c (12.2.1.4.0), Jive features remain available in your upgraded instance but Oracle support is not provided for these features. In the next release, Jive features will not be available even in the upgraded instances
Permissions:
The content of this chapter is intended for system administrators.
For more information on which roles and permissions are required to deploy portals, templates, assets, connections, and extensions, see Permissions Required to Perform WebCenter Portal Lifecycle Operations.
See also Understanding Administrative Operations, Roles, and Tools.
Deploying Portals
This section includes the following topics:
About Portal Deployment
When you deploy a portal to another portal server, you make a copy of the source portal on the target server and you can choose to include all or some of the source portal's data.
After initial deployment of a portal, you can choose to redeploy the portal or propagate only portal changes to the target. When you redeploy a portal, it is simply deleted and re-created as a new portal. In portal propagation, only the incremental changes made to a portal on the source are pushed to the target server.
You can deploy a portal in the following ways:
-
Direct portal deployment - If a direct connection to the target server exists, you can deploy a portal to the target server by using WebCenter Portal Administration. You can also use the
deployWebCenterPortal
WLST command to deploy portals directly to the target server. For details, see Directly Deploying Portals Using WebCenter Portal and Directly Deploying Portals Using WLST. -
Portal archive deployment - You can export the archive (
.par
file) of the source portal and import the archived portal on the target server by using WebCenter Portal Administration. You can also use WLST commands to export portals to an archive and then import portals from the file.For details, see Exporting and Importing Portal Archives.
Information Always Deployed with a Portal
-
Portal pages
- Portal assets: Page templates, resource catalogs, skins, page styles, Content Presenter display templates, task flow styles, task flows, layouts, data controls, visualization templates, data visualizations (including dependant business objects and data sources), business objects, data sources (including their connections)
-
Portal activity/usage data: Activity streams, calendar events, feedback, lists, links, message boards, people connections, profiles, and surveys
-
Portal security data: Portal roles and permissions and member details and their role assignments
Information that can be Optionally Deployed with a Portal
-
Portal’s content: A portal’s documents and associated content are placed in the portal’s content folder on Content Server. If you choose not to move the content folder during portal deployment, you can manually move the folder to the target using WebCenter Content Server migration tools. For details, see System Migration and Archiving in Administering Oracle WebCenter Content.
Portal deployments do not include the content that is stored outside a portal's own content folder. If your portal contains portal assets, portal pages, Content Presenter display templates, or other components that reference content outside the portal’s content folder, you must either manually move such content to the target or ensure that the target can access the same content as the source. When you move a portal to a different target, Content Presenter data references are maintained only if Content Server connection names and root folder names are the same in both the source and the target.
-
Shared assets: While deploying your portal you can choose to deploy all shared assets used by the portal.
-
Shared library: While deploying your portal you can choose to deploy the shared libraries used by the portal. When you choose to deploy shared libraries, the main shared library that gets deployed is
extend.spaces.webapp
, which in turn may be dependent on other libraries. As part of deployment, all new versions (newly created or updated) of the dependent libraries of the main shared library are also included. However, this is done only for the first level of dependent libraries. For example, supposeextend.spaces.webapp
is dependent onCustomSharedLibrary1
, andCustomSharedLibrary1
is dependent onCustomSharedLibrary2
. If an updated version is available for bothCustomSharedLibrary1
andCustomSharedLibrary2
, onlyCustomSharedLibrary1
is included as part of shared library deployment.
Information Not Included During Portal Deployment
Some portal information is stored externally and cannot be deployed at the same time as the portal, for example:
-
content used by portal assets, Content Presenter or Site Studio stored outside of the portal’s content folder
-
portal discussions
-
portal mail
-
portal analytics
Note:
Connections are exported and imported separately. For more information, see Understanding Connection Property Files.
Figure 32-1 illustrates the different ways in which you can move a portal (and its associated data) to another server.
Figure 32-1 Deploying Portals to a Target Server

Description of "Figure 32-1 Deploying Portals to a Target Server"
If your source and target WebCenter Portal installations are connected to different external servers and information associated with the source portal is required on the target, the external portal data must be moved separately.
Note:
While exporting or deploying a portal if the server goes down and fails over to another server in the cluster, the operation will fail. You need to refresh the page and perform the export or deployment operation again.If you want to deploy a portal larger than 50 MB, ensure that you modify the maximum file upload size on the target server as per your requirements. For information, see Modifying the File Upload Size in Content Manager.
For information about troubleshooting portal deployment issues, see Troubleshooting WebCenter Portal.
Directly Deploying Portals Using WebCenter Portal
Using WebCenter Portal administration, you first create a connection to the target server and then directly deploy your portals to the target server. After a portal is deployed, you can view its deployment status and deployment history.
This section includes the following topics:
Creating a Portal Server Connection
Before you can deploy a portal, you need to set up a connection to the target portal server.
To create a portal server connection:
-
Log on to WebCenter Portal, and navigate to portal administration.
-
Click Tools and Services.
-
Select Portal Server Connections from the list of tools and services.
-
Click Create.
-
In the Create Portal Server Connection page, specify the following details:
-
Name: Specify the name of the connection. Note that only alphanumeric characters can be used.
-
URL: Specify the URL of the target portal server in the following format:
http://
targetserverhost:port
where
targetserverhost:port
refer to the host name and port number of the portal server where you want to deploy your portals. -
Username: Type the user name used for connecting to the target server.
-
Password: Type the password for the specified user name.
-
-
Click Test to make sure the connection works.
-
Click Create.
Note that if the connection test fails due to the portal server being offline, the connection will still be set up, and can be used once the server is available.
Deploying a Portal Using WebCenter Portal
Note:
Deploying a portal is primarily a system administrator task; however, you can assign the Portal Server: Deploy
permission to another custom role. It is recommended that you create a custom role and assign this permission to the custom role in order to restrict the user roles that can deploy portals.
Only the Portal Manager (or Delegated Manager) of the portal can deploy the portal, and in addition, must be in a role that has the Portal Server: Deploy
permission.
For more information about creating a custom application role and adding users to the role, see Defining Application Roles. and Assigning Users (and Groups) to Application Roles.
To deploy a portal using WebCenter Portal:
Directly Deploying Portals Using WLST
You can use the WLST command deployWebCenterPortal
to deploy a single, online portal directly to another target server. If you want to propagate portal changes in the source to the target using WLST, then you must use deployWebCenterPortal
to deploy your portal.
Before deploying a portal you must complete a few prerequisite tasks. The overall process is as follows:
Step 1: Complete Prerequisites for Direct Portal Deployment
Before running the WLST command deployWebCenterPortal
, complete the following:
Deploying Portal Archives
Administrators can use WebCenter Portal or WLST commands to deploy portal archives (.par
files) to any WebCenter Portal installation. The target portal server must be up and running when you deploy (or import) one or more portals from a file.
This section includes the following topics:
Note:
When you deploy a portal to another server from an archive you cannot use portal propagation to make incremental updates to the portal later on. The portal propagation feature is only possible when used in conjunction with direct portal deployment. See Propagating and Redeploying Portals in Production.
Understanding Portal Archives
You can create a portal archive (.par
file) for a single portal or you can archive multiple portals in the same .par
file.
Portal archives can contain:
-
One or more portal data archive
(.pdr
) files: Portal archives include a PDR for each portal that you add to the archive. A PDR includes the security policy for the portal and a metadata archive that captures metadata, data, and content for the portal. -
An export log file (
.log
): An export log file lists all the portals, MDS metadata files, and data (names of database tables that contain portal data) included in the archive. -
The connections.xml file For more information, see Understanding Connection Property Files.
-
A WebCenter Portal connection properties file (
connection.properties
)
Note:
You can extract any portal archive (.par
file) using the listWebCenterPortalArchive
WLST command.
Understanding Connection Property Files
If you plan to import, deploy, propagate, or restore a portal on a WebCenter Portal target where all or some connections do not exist, Oracle recommends that you use the WLST command exportWebCenterPortalConnections
to generate the connection.properties
file from the source environment, and then use the WLST command importWebCenterPortalConnections
to import missing connections configured in that file on the target environment. For detailed steps, see Importing New WebCenter Portal Connections from a File.
Note:
-
A
connection.properties
file is also generated when you run the WLST commandexportWebCenterPortalConnections
. For details, see, Exporting WebCenter Portal Connections Details to a File. -
All connections configured in the source WebCenter Portal environment are exported to
connection.properties
. The connection information in this file is not specific to the portals in the archive. -
Only new connections are imported on the target. Connections that exist on the target are ignored.
Modifying Connection Details
If some connection information, such as server names, ports, and so on, varies between the source and target environments, you can isolate and modify connection details in the file before importing, deploying, propagating, or restoring the portal.
Table 32-1 shows examples where a different URL parameter is required on the target because the source and target do not use the same host.
Table 32-1 Example: Connection URLs Different in Source and Target Environments
Connection Type | Source Connection: URL parameter | Target Connection: URL parameter |
---|---|---|
WSRP Portlet Producer |
http://mysource.com:8899/MyWSRPPortletProducer/portlets/wsrp2?WSDL |
http://mytarget.com:8899/MyWSRPPortletProducer/portlets/wsrp2?WSDL |
PDK-Java Producer |
http://source.host.com:7778/myJPDKPortletProducer/providers |
http://target.host.com:7778/myJPDKPortletProducer/providers |
Web Service |
http://source.example.com/getEmployee?empId=20+deptId=10 |
http://target.example.com/getEmployee?empId=20+deptId=10 |
Figure 32-9 illustrates how you can edit connection details in connection.properties
when source and target parameters vary before new connections are created on the target.
Figure 32-9 Using connection.properties to Create Connections on the Target

Description of "Figure 32-9 Using connection.properties to Create Connections on the Target"
Connection Types and Connection Properties
Table 32-2 lists all the connections captured in the connection.properties
file together with the properties that are exported for the various connection types. The table also shows which properties you can edit before deployment, and which properties you must set on the target.
Note:
-
For detailed information about individual connection properties, including which ones are mandatory or optional for a particular connection type, refer to the chapter for that connection type. For a list of chapters, see Administering Tools and Services.
-
Oracle strongly recommends that you only edit properties in
connection.properties
that are marked Edit on Deployment?=Yes in Table 32-2. If for some reason you want to edit any of the properties marked Edit on Deployment?=No, you may do so after migrating the connection on the target using either Fusion Middleware Control or WLST commands.
Table 32-2 Connection Properties Exported to connection.properties
Connection Type | Properties Exported | Edit on Deployment? | Notes and Post Deployment Configuration Requirements |
---|---|---|---|
WSRP portlet producer |
|
|
Security configuration post deployment:
|
PDK-Java producer |
|
|
Security configuration post deployment:
|
Web service connection |
|
|
Web service connections are used by data controls |
URL connections - HTTP URL |
|
|
Security configuration post deployment:
|
URL connections - File URL |
|
|
|
Analytics collector |
|
|
|
BPEL server |
|
|
|
Discussions server |
|
|
|
External applications |
|
|
If public or shared credentials are configured on the source, they are not exported for security reasons. You must configure these credentials on the target post deployment, if required. |
Presence server - Microsoft Lync 2010 |
|
|
|
Mail server |
|
|
LDAP configuration post deployment:
|
Personal events server |
|
|
|
Search |
|
|
Users will be prompted for |
WebCenter Content Server (socket) |
|
|
Security configuration post deployment:
|
WebCenter Content Server (socketssl) |
|
|
Security configuration post deployment:
|
WebCenter Content Server (jaxws) |
|
|
Security configuration post deployment:
|
WebCenter Content Server (web) |
|
|
Security configuration post deployment:
|
File System |
|
|
|
Worklist connection |
|
|
|
Rest Connection |
|
|
Footnote 1
Security related configuration: Only policy information is included with the connection. The Override set for the security policy is not included so you must configure these parameters post deployment.
To find out how to deploy connection information in to another server, see Moving Connections Details from Staging to Production.
Securing Archives
This section includes the following topics:
About Securing Archive Files
WebCenter Portal supports validation checks to be performed when portal archives are exported or imported. This secures portal archives by preventing corrupt or arbitrary files from being included on Portal Server.
You can choose to set any of the following security levels for lifecycle operations:
-
High-security mode: Set the
ExternallySecureLifecycleOperations
custom attribute, mapped against an external application that stores the credentials to encrypt or decrypt the file storing the checksum value. -
Moderate-security mode: Set the
SecureLifecycleOperations
custom attribute, mapped against the valueenable
. If the value is set toenable
, lifecycle operations are secured, and checksum acts as the credentials for the encrypt or decrypt process.
During the export operations, a checksum is calculated and added to all the lifecycle archives - portal archives, application archives, and asset archives. The checksum is stored in a file named lifecycle.chk
inside the .par
or .aar
files and the file is encrypted. During archive import, the file is decrypted to fetch the checksum value. In moderate security mode, the checksum (calculated internally) acts as the password to encrypt or decrypt the file. In high-security mode, the external application with shared credentials is used as the password, and the ExternallySecureLifecycleOperations
custom attribute is used to fetch the password.
Consider the following while configuring a secure mode for lifecycle operations:
-
If an archive is exported in a secured source environment, and the target environment is not secured, security validations are not performed on the archive.
-
If lifecycle operations are secured, and during archive import if the
lifecycle.chk
file is missing from the archive, it is a security violation and the import operation is not allowed. -
If lifecycle operations need to be secured, the same level of security must be set on the target and the source instances. Different levels of security modes are not supported.
-
If the high-security mode is set, both the source and the target instances must use the same password for the encryption and decryption to work.
Exporting and Importing Portal Archives
If a direct connection to the target server does not exist, you can first export a portal to an archive (.par
file) and then import the archive on the target server to deploy the portal. You can also create a portal archive if you want to create a backup of the portal and restore it on the same instance later.
Note:
When you deploy a portal to another server from an archive you cannot use portal propagation to make incremental updates to the portal later on. The portal propagation feature is only possible when used in conjunction with direct portal deployment. See Propagating and Redeploying Portals in Production.
To export and then import a portal archive:
Exporting Portals to an Archive
You can generate an archive (.par
file) for any portal that is running on WebCenter Portal. You can create a portal archive by using WebCenter Portal, the exportWebCenterPortals
WLST command, or REST APIs.
To find out how to create portal archives, see:
Portal Export Prerequisites
Before exporting a portal to an archive (.par
file), verify the following:
-
Portal content stored on Content Server - If you want to include the portal content stored on Content Server in the portal archive, ensure Content Server is up and running. The portal archive does not include any security settings. On import, the security group of the target portal server is applied.
-
Web service data controls - If any of the portals you want to export contain web service data controls, all the associated web services must be up and accessible for the export to succeed.
-
Portlet producers - If any of the portals you want to export contain portlets, all associated portlet producers must be up and accessible for all portlet metadata to be included in the archive.
-
Content outside portal folder - Content stored outside the portal folder (such as files, images and icons) that is used by portal assets, portal pages, Content Presenter, and Site Studio are not automatically included in the archive. You must copy all dependent files to appropriate locations on the target content server.
Note:
If you are managing legacy portals with assets that store artifacts in MDS, Oracle recommends that you relocate all dependent artifacts from MDS to your content server. If you choose not to move artifacts stored in MDS, you can use MDS WLST commands
exportMetadata
/importMetadata
to move the MDS content to another target. For example:exportMetadata(application='webcenter', server='
WC_Portal
', toLocation='/tmp/content', docs='/oracle/webcenter/siteresources/scopedMD/shared/**') importMetadata(application='webcenter', server='WC_Portal
', fromLocation='/tmp/content', docs='/oracle/webcenter/siteresources/scopedMD/shared/**')
Exporting Online Portals to an Archive Using WebCenter Portal Administration
With Portal Server-Manage All
or Manage Configuration
permission, you can export portals to an archive using WebCenter Portal Administration, saving the portal archive to a local file system or to a remote server file system.
Note:
You can export portal templates too, but this is a separate process. You cannot export portals and portal templates into a single archive.
See Exporting Portal Templates to an Archive Using WebCenter Portal.
To export one or more portals:
Exporting Online Portals to an Archive Using WLST
Use the WLST command exportWebCenterPortals
to export one or more portals to a portal archive (.par
file). When you create a portal archive using WLST you can choose whether or not to include the portal's content folder and connection information in the archive:
exportWebCenterPortals(appName, fileName, [names, offlineDuringExport, exportPortalContent, exportConnections, exportSharedAssets, server, applicationVersion])
The options that you set depends on your specific archive requirements. For command syntax, seeexportWebCenterPortals
in WebCenter WLST Command Reference
Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Exporting two portals
This example exports two portals named Sales
and Finance
, plus all content, data, security, customizations, and connection information:
exportWebCenterPortals(appName='webcenter', fileName='MyPortalExport.par', names='Sales,Finance', exportPortalContent=1, exportConnections=1)
Example 2 - Exporting a single, offline portal without its content folder or connection details
This example takes MySales
offline and exports the portal to MyPortalExport.par
:
exportWebCenterPortals(appName='webcenter', fileName='MyPortalExport.par', names='Sales', offlineDuringExport=1)
Exporting a Portal Using REST APIs
You can generate a portal archive (.par
file) for your portals using the REST API support.
To export a portal using REST API, use the following URL format:
http://host:port
/rest/api/v1/portal/portals/portal_shortId
/archive?utoken=utoken_value
Where host
: port
are the hostname and port number for the server where the portal is running, and portal_shortId
is the short ID of the portal to be exported.
If you want to export the portal content as well, include the includePortalContentValue
parameter in the URL as follows:
http://host:port/rest/api/v1/portal/portals/portal_shortId/archive?includePortalContent=includePortalContentValue&utoken=utoken_value
The default value for includePortalContent
is 0. Any value greater than 0 will be treated as true, and the portal content will be included in the portal archive.
To export the portal, in wpfas/modules/rest-service/servlet/src/java/oracle/webcenter/jaxrs/services/portal/controller/PortalsResource.java
, add a GET operation in the following format:
@GET @Path("{portalId}/archive") public Response exportPortal(@PathParam("portalId") String portalId, @DefaultValue(START_INDEX_DEFAULT) @QueryParam("includePortalContent") int includePortalContent);
The GET operation will call the API to perform the portal export. You can then download the PAR file to the local client. Response code 200 represents the successful export of a portal.
Importing Portals from an Archive
Administrators can deploy archived portals (.par
files) to any WebCenter Portal Server. You can use the WLST command importWebCenterPortals
to import portal archives or you can use WebCenter Portal Administration.
On import, all portals included in the archive are created or re-created on the target server. Existing portals are deleted then replaced, and new portals are created. If you intend to import portals with names identical to those available on the target server, ensure that those portals are offline in the target application as it is not possible to overwrite portals that are online. For details, see Taking Any Portal Offline.
Note:
When importing portals using WLST, you can set the option forceOffline=1
to automatically take any online portals offline. Any portals taken offline in this way, remain offline at the end of the import process.
Portals are locked during an import operation to prevent simultaneous imports/exports of the same portal. If someone else is importing a particular portal, all subsequent attempts to import (or export) the same portal are blocked.
After importing one or more portals, consider initiating Elasticsearch crawl to index the newly imported data.
Portal Archive Content (Optional on Import)
Portal archives sometimes contain the portal's content folder. If included, you can choose whether or not to import this information too. On import, the content folder in the archive overwrites the folder on the target (if one exists), and the security group of the target portal server is applied.
Note:
Portal archives do not include web content/pages displayed through Content Presenter since this information is not stored in the portal's content folder.
External Portal Data (Import Separately)
Externally stored data, such as discussions can be migrated for individual portals but this is a separate process. See Migrating Discussions Resources for a Portal.
To find out how to import portal archives, see:
Portal Import Prerequisites
Before importing a portal archive (.par
file), verify the following:
-
Shared identity store - Verify that the users in the source and target environments are the same. If a shared identity store is not used, your system administrator must migrate users to the target. Refer to Back Up (Export) WebCenter Portal Schema Data and Restore (Import) WebCenter Portal Data.
-
Portals exist on the target - Check whether any portals in the archive already exist on the target. If required, take existing portals offline during the import process, as described in Taking Any Portal Offline.
-
Web service data controls - If any of the portals you want to import contain web service data controls, all the associated web services must be up and accessible for the import to succeed.
-
Portlet producers - Any portlet producers used by the portal must be up and running when you import the portal.
-
Connections to external servers, applications, web services, and portlet producers - Portals that rely on certain external connections to be configured will not work if a similar connection does not exist in the target. Before importing the portal, ensure that all the required connections exist on the target. If you create or reconfigure connections on the target you may need to restart the target managed server. For details, see Moving Connections Details from Staging to Production.
-
Archive version - If you want to import portal archives from a WebCenter Portal 11g release, you must first upgrade to the current WebCenter Portal 12c release, re-create the portal export archive (.par file), and then import it.
For upgrade, see Understanding the Oracle WebCenter Upgrade Procedures Flow in Upgrading Oracle WebCenter.
Importing a Portal from an Archive Using WebCenter Portal Administration
With Portal Server-Manage All
or Manage Configuration
permission, you can import portals from a portal archive through WebCenter Portal Administration.
To import one or more portals from a .par
file:
Typically, some additional work is required before new portals are ready for general use so initially, all newly imported portals are offline. For example, you may want to:
-
Migrate data associated with back-end components.
For details, see Migrating Discussions Resources for a Portal.
-
Add or invite members.
-
Enable or disable tools and services.
Once portal content and membership details are finalized you can bring the portal online. See Bringing Any Portal Back Online.
Importing a Portal from an Archive Using WLST
Use the WLST command importWebCenterPortals
to import one or more archived portals into WebCenter Portal:
importWebCenterPortals(appName, fileName, [names, parentPortal, importCustomizations, importPortalContent, importSecurity, importData, importActivities, overwrite, savePortals, forceOffline, importLog, importConnections, connPropertiesFile, importSharedAssets, server, applicationVersion])
When you import portals using WLST, you do not have to import everything inside the archive. If the archive contains multiple portals you can specify only those portals that you want to import. You can also specify how much information is imported along with the portals. For example you can choose whether or not to import the portal's content folder or shared assets. These options are useful as in some circumstances, such as moving a portal from a test environment to a stage or production environment, test-related data/content is not always required.
The options that you set depend on your specific requirements. For command syntax, see importWebCenterPortals
in WebCenter WLST Command Reference
Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Importing two portals on the target for the first time
This example imports two portals named Sales
and Finance
, plus all content, and security, and also specifies a name and location for the import log file:
importWebCenterPortals(appName='webcenter', fileName='MyPortalExport.par', names='Sales,Finance', importLog='/myimportlogs/myPortal_import.log')
Example 2 - Importing a portal that exists on the target
This example backs up a portal named myExistingPortal
on the target and then overwrites the target portal with the archived version (excluding all possible data):
importWebCenterPortals(appName='webcenter', fileName='MyPortalExport.par', names='myExistingPortal', importPortalContent=0, importActivities=0, overwrite=1, savePortals=1)
Importing a Portal Using REST APIs
You can import portals into WebCenter Portal using REST API.
To import a portal using REST API, use the following URL format:
http://host:port
/rest/api/v1/portal/portals?utoken=<utoken_value>
where host
:port
are the hostname and port number of the server into which you want to import the portal.
To import the portal, add the POST operation in the following format in the wpfas/modules/rest-service/servlet/src/java/oracle/webcenter/jaxrs/services/portal/controller/PortalsResource.java
:
@POST @Consumes({MediaType.MULTIPART_FORM_DATA, MediaType.APPLICATION_OCTET_STREAM}) @ResourceType("urn:oracle:webcenter:portal:portals") public Response importPortal(MultiPart multiPartData, @DefaultValue(START_INDEX_DEFAULT) @QueryParam("includePortalContent") int includePortalContent);
For performing portal imports using the POST operation the content type must be specified as multipart/form-data
. In a multipart format, each part is a contiguous portion of the object's data. You can upload each object part independently and in any order. If transmission of any part fails, you can retransmit that part without affecting other parts. The POST operation also requires the filename of the portal archive to be mapped to the fileName
key.
Viewing and Extracting Portal Archives
Use the WLST command listWebCenterPortalArchive
to view the content of a portal archive (.par
file). You can also extract the portal archive content to a location of your choice, if required. For command syntax, see listWebCenterPortalArchive
in WLST Command Reference for WebLogic Server.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Deploying Portal Templates
Administrators can export portal templates from WebCenter Portal and deploy them on another portal server. Out-of-the-box templates cannot be exported.
While export and import utilities are primarily used to move information between WebCenter Portal instances, the portal template export feature is also useful as a backup service, and for sharing and exchanging templates with others.
Portal templates can contain pages, documents, portal assets, and security information such as custom roles and member details. As all the template data is included in the portal template archive, you do not need to manually migrate any template data to the target when you deploy a portal template to another WebCenter Portal Server.
Portal templates that use document services (files, folders, wikis, blogs) automatically own a content folder on WebCenter Portal's back-end content repository. When you use WebCenter Portal Administration to export portal templates, the content stored in this folder is automatically included in the portal template archive for easy deployment to another target server.
If you export the portal template using the WLST command exportWebCenterPortalTemplates
the content folder is optional.
Note:
Portal template archives do not include web content/pages referenced by the portal template that is stored at any other location, for example, information displayed through Content Presenter that is not stored in the portal template's content folder. Only the folder assigned to the portal template on WebCenter Portal's back-end content repository is included with the portal template archive.
This section includes the following topics:
Exporting Portal Templates
Administrators can use the WLST command exportWebCenterPortalTemplates
to export one or more portal templates to an archive. Alternatively, administrators and application specialists can use WebCenter Portal Administration to export portal templates to an archive.
This section includes the following topics:
Exporting Portal Templates to an Archive Using WebCenter Portal
Application specialists (and other users with the Portal Templates: Manage All
permission) can export portal templates from WebCenter Portal. For information, see Exporting Portal Templates in Building Portals with Oracle
WebCenter Portal.
Note:
You cannot export portals and portal templates into a single archive. Exporting portals is a separate process. For more information, see Exporting Online Portals to an Archive Using WebCenter Portal Administration.
Exporting Portal Templates to an Archive Using WLST
Use the WLST command exportWebCenterPortalTemplates
to export one or more portal templates to an archive (.par
file). When you create a portal template archive using WLST you can choose whether or not to include the portal's content folder in the archive:
exportWebCenterPortalTemplates(appName, fileName, [names, exportPortalTemplateContent, exportConnections, server, applicationVersion])
The options that you set depends on your specific archive requirements. For command syntax, see exportWebCenterPortalTemplates
in WebCenter WLST Command Reference
Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Exporting two portal templates
This example exports two templates named SalesTargetTemplate
and NewProjectTemplate
, plus their associated content folders:
exportWebCenterPortalTemplates(appName='webcenter', fileName='MyTemplateExport.par', names='SalesTargetTemplate,NewProjectTemplate', exportPortalTemplateContent=1)
Example 2 - Exporting a single portal template without its content folder
This example exports the New Hire
template. Documents are not enabled in this template so the template does not have a content folder:
exportWebCenterPortals(appName='webcenter', fileName='MyTemplateExport.par', names='NewHire')
Importing Portal Templates
Administrators can use the WLST command importWebCenterPortals
to deploy one or more portal templates on a WebCenter Portal Server. Alternatively, administrators and application specialists can use WebCenter Portal Administration to import portal templates from an archive.
On import, all portal templates included in the archive are re-created on the target application. If a portal template exists on the target, then it is deleted and replaced. If a portal template does not exist, then it is created.
Newly imported portal templates are not immediately available for general use. You must publish newly imported templates to make them available to everyone. See Publishing or Hiding Portal Templates in Building Portals with Oracle WebCenter Portal.
This section includes the following topics:
Importing Portal Templates from an Archive Using WebCenter Portal
Application specialists (and other users with Portal Templates: Manage All
permission) can import portal templates into WebCenter Portal. For more information, see Importing Portal Templates in Building Portals with Oracle
WebCenter Portal.
Importing Portal Templates from an Archive Using WLST
Use the WLST command importWebCenterPortals
to import one or more portal templates from an archive (.par
file). When you import a portal template archive using WLST you can choose whether or not to import template content folders:
importWebCenterPortals(appName, fileName, [names], [parentPortal], [importCustomizations], [importPortalContent], [importSecurity], [importData], [importActivities], [overwrite], [savePortals], [forceOffline], [importLog], ]importConnections], [connPropertiesFile], [importSharedAssets], [server], [applicationVersion])
The options that you set depend on your specific archive requirements. For command syntax, see importWebCenterPortals in WebCenter WLST Command Reference Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Importing a new portal template without content
The following example imports the New Hire
portal template archived in myPortalTemplateExport.par
and specifies a name and location for the import log file. Documents are not enabled in this template so the template does not have a content folder.
importWebCenterPortals(appName='webcenter', fileName='myPortalTemplateExport.par', names='NewHire', importLog='newHireTemplate_import.log')
Example 2 - Imports two existing portal template with content:
This example backs up portal templates named SalesTargetTemplate
and NewProjectTemplate
on the target, and then overwrites the existing templates and their content folders with information in myPortalTemplateExport.par
:
importWebCenterPortals(appName='webcenter', fileName='myPortalTemplateExport.par', names='SalesTargetTemplate,NewProjectTemplate', importPortalContent=1, overwrite=1, savePortals=1, importLog='myPortalTemplate_import.log')
Deploying Assets
Authorized users can download assets, such as skins and page templates, while WebCenter Portal is running, edit and extend them in tools such as Oracle JDeveloper, and then deploy them back to WebCenter Portal. Users who want to share assets or migrate assets to other WebCenter Portal instances can use the download/upload feature too.
WebCenter Portal users can download and upload the following assets through WebCenter Portal and administrators can perform the same tasks using WLST commands:
-
Page templates
-
Resource catalogs
-
Skins
-
Page styles
-
Content Presenter display templates
-
Visualizations
-
Business objects
-
Task flow styles
-
Task flows
-
Layout
-
Data controls
-
Data sources
When you download (or export) a WebCenter Portal asset, the asset details are saved to an export archive (.aar
file). You can save the export archive to your local file system or a remote server file system using a filename of your choice. Artifacts, such as icons and images, used or referenced by assets are not included in the export or import archive unless they are stored in the portal’s content folder on Content Server and the contents folder is in sync on the source and the target servers.
Devices and Device Groups
.aar
file), and then import (deploy) them to another WebCenter Portal instance. For example, if you want to move devices or device groups developed on stage to a production server or share your devices and device groups with another WebCenter Portal installation.
Note:
You cannot export or import out-of-the-box device groups or devices. You can only export and import device groups or devices that you and other administrators create or copy.
This section includes the following topics:
Exporting Assets, Devices, and Device Groups to an Archive
This section describes the various ways you can create an asset, device, and device group archive. It includes the following topics:
See also, About Permissions Required to Import (or Export) Assets.
Exporting Assets to an Archive from WebCenter Portal
Administrators, application specialists, and portal managers can export assets from WebCenter Portal. For details, see Downloading an Asset in Building Portals with Oracle WebCenter Portal.
Exporting Devices and Device Groups to an Archive
This section includes the following topics:
Exporting Devices and Device Groups Using WebCenter Portal
Administrators can export one or more devices and device groups to a file (.par
file) from WebCenter Portal Administration. For details, see Managing Device and Device Group Lifecycles.
Exporting Devices and Device Groups Using WLST
Administrators can use the WLST command exportWebCenterResource
to export a single device or device group from WebCenter Portal to an export archive (.aar
file):
exportWebCenterResource(appName, fileName, resourceType, [resourceGUID, resourceName, spaceName, exportContentDirectory, server, applicationVersion])
For command syntax, see exportWebCenterResource in WebCenter WLST Command Reference Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Exporting a device group
The following example exports a device group named "MyMobileDeviceGroup" from WebCenter Portal:
exportWebCenterResource(appName='webcenter', fileName='myDeviceGroupExport.aar', resourceType='deviceGroup', resourceName='MyMobileDeviceGroup)
Example 2 - Exporting a device
The following example exports a device named "MyMobileDevice" from WebCenter Portal:
exportWebCenterResource(appName='webcenter', fileName='myDeviceExport.aar', resourceType='device', resourceName='MyMobileDevice)
Exporting an Asset, Device, or Device Group to an Archive Using WLST
Administrators can use the WLST command exportWebCenterResource
to export a single asset, device, or device group from WebCenter Portal:
exportWebCenterResource(appName, fileName, resourceType, [resourceGUID, resourceName, spaceName, exportContentDirectory, server, applicationVersion])
The options that you set depends on the asset, device, or device group you want to export. For command syntax, see exportWebCenterResource in WebCenter WLST Command Reference Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Exporting a page template belonging to the "Sales" portal
The following example exports a page template from the Sales
portal to a file named mySalesPageTemplateExport.aar
:
exportWebCenterResource(appName='webcenter', fileName='mySalesPageTemplateExport.aar', resourceType='pageTemplate', resourceGUID='gsr47d9a5ac_7398_439a_97d2_8b54ce905f7e, spaceName='SalesPortal')
Example 2 - Exporting a shared portal skin identified by GUID
The following example exports a shared portal skin to a file named mySharedSkinExport.aar
:
exportWebCenterResource(appName='webcenter', fileName='mySharedSkinExport.aar', resourceType='skin', resourceGUID='gsr5a8c2fcc_bc7f_4cba_9254_36df58d66e60)
Example 3 - Exporting a shared portal skin identified by name
The following example exports the same shared portal skin but specifies the skin's display name rather than the GUID:
exportWebCenterResource(appName='webcenter', fileName='mySharedSkinExport.aar', resourceType='skin', resourceName='MyCompanySkin)
Example 4- Exporting a device group
The following example exports a device group named "MyMobileDeviceGroup" from WebCenter Portal:
exportWebCenterResource(appName='webcenter', fileName='myDeviceGroupExport.aar', resourceType='deviceGroup', resourceName='MyMobileDeviceGroup)
Example 5- Exporting a device
The following example exports a device named "MyMobileDevice" from WebCenter Portal:
exportWebCenterResource(appName='webcenter', fileName='myDeviceExport.aar', resourceType='device', resourceName='MyMobileDevice)
Exporting Assets Using REST API
Oracle WebCenter Portal provides REST APIs to download a specific asset to an archive (.aar) from a portal or the shared assets area.
To export an asset using REST API, use the following URL format:
http://host:port/rest/api/v1/portal/typeOfAsset/assetId/archive?utoken=utokenvalue
Where typeOfAsset
refers to the asset you want to export, such as page templates, skins, visualization templates, or resource catalogs.
To export an asset, add the GET operation in the following format in wpfas/modules/rest-service/servlet/src/java/oracle/webcenter/jaxrs/services/portal/controller/
AssetTypeResource
.java
@GET
@Path("{id}/archive")
public Response exportPortal(@PathParam("id
") String id);
Where, PathParam's id
is the short ID of the asset to be exported.
Importing Assets from an Archive
You can only import an asset previously saved to a WebCenter Portal asset export archive (.aar
file). For details, see Exporting Assets, Devices, and Device Groups to an Archive.
On import:
-
Existing assets are overwritten, that is, assets with the same internal ID.
-
Portal assets are always imported back into the same portal. You cannot import a resource into a different portal.
This section describes the various ways you can import an asset to WebCenter Portal from an archive. It includes the following topics:
About Permissions Required to Import (or Export) Assets
Table 32-3 describes the roles/permission required to import (or export) assets using the WebCenter Portal Administration.
Note:
If you want to import (or export) assets using WLST, you must also have the WebLogic Server Monitor
role (or higher).
Table 32-3 Permissions Required to Import (or Export) Assets Using WebCenter Portal
Asset | Required WebCenter Portal Role or Permission | Description |
---|---|---|
Shared asset |
OR |
|
Shared asset |
|
|
|
|
|
Portal asset |
OR |
|
Portal asset |
|
|
|
|
Importing Assets from an Archive using WebCenter Portal
Administrators, application specialists, and portal managers can import assets from WebCenter Portal. For details, see Uploading an Asset in Building Portals with Oracle WebCenter Portal
Importing Devices and Device Groups Using WebCenter Portal
Administrators can import one or more devices and device groups from a file (.par
file) using WebCenter Portal Administration. For details, see Managing Device and Device Group Lifecycles.
Importing Assets from an Archive using WLST
Administrators can use the WLST command importWebCenterResource
to deploy a single asset, device, or device group to WebCenter Portal.
importWebCenterResource(appName, fileName, [resourceType, spaceName, overwriteContentDirectory, server, applicationVersion])
The options that you set depends on the asset, device, or device group you want to deploy. For command syntax, see importWebCenterResource in WebCenter WLST Command Reference Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Deploying a page template to the "Sales" portal
The following example imports a page template archived in mySalesPageTemplateExport.aar
in to the Sales
portal:
importWebCenterResource(appName='webcenter', fileName='mySalesPageTemplateExport.aar', resourceType='pageTemplate', spaceName='SalesPortal')
Example 2 - Deploying a shared portal skin
The following example imports a shared portal skin archived in mySharedSkinExport.aar
:
importWebCenterResource(appName='webcenter', fileName='mySharedSkinExport.aar', resourceType='skin')
Example 3 - Deploying a device group
The following example imports a device group exported to myDeviceGroupExport.aar
:
importWebCenterResource(appName='webcenter', fileName='myDeviceGroupExport.aar', resourceType='deviceGroup')
Example 4 - Deploying a device
The following example imports a device archived in myDeviceExport.aar
:
importWebCenterResource(appName='webcenter', fileName='myDeviceExport.aar', resourceType='device')
Importing Assets Using REST API
Oracle WebCenter Portal provides REST APIs to download a specific asset to an archive (.aar
file) from a portal or the shared assets area.
To export an asset using REST API, use the following URL format:
http://host:port
/rest/api/v1/portal/portals/portalShortId/typeOfAsset
?utoken=utokenvalue
Where typeOfAsset
is the asset you want to export, such as page templates, skins, visualization templates, or resource catalogs, and portalShortId
refers to the short ID of the portal into which the asset will be imported.
To import an asset into a portal or the shared assets area, add the POST operation in the following format in wpfas/modules/rest-service/servlet/src/java/oracle/webcenter/jaxrs/services/portal/controller/PortalsReosurce.java
:
@POST @Consumes({MediaType.MULTIPART_FORM_DATA, MediaType.APPLICATION_OCTET_STREAM}) @Path("{portalId}/<typeOfAsset>") @ResourceType("urn:oracle:webcenter:portal:<assetType>") public Response importPortal(@PathParam("portalId") String portalId, MultiPart multiPartData);
Where, PathParam's portalId
is the short ID of the portal into which asset will be imported, multipartData
is the multipart data with the file to be consumed for upload.
For importing assets using the POST operation, the content type must be specified as multipart/form-data
. In a multipart format, each part is a contiguous portion of the object's data. You can upload each object part independently and in any order. If transmission of any part fails, you can retransmit that part without affecting other parts. The POST operation also requires the filename of the asset archive to be mapped to the fileName
key.
For importing a shared asset, you can also use the following URL format:
http://host:port/rest/api/v1/portal/typeOfAsset?utoken=utokenvalue
To import a shared asset, add the POST operation in the following format in wpfas/modules/rest-service/servlet/src/java/oracle/webcenter/jaxrs/services/portal/controller/AssetTypeResource.java
:
POST @Consumes({MediaType.MULTIPART_FORM_DATA, MediaType.APPLICATION_OCTET_STREAM}) @ResourceType("urn:oracle:webcenter:portal:<assetType>") public Response importPortal(MultiPart multiPartData)
Deploying Custom Shared Library Extensions
Developers can use JDeveloper to build custom ADF library components for portals, such as managed beans, task flows, and data controls, and deploy them as shared library extensions to the portal server.
See also, the Developing Shared Libraries in Developing for Oracle WebCenter Portal.
If shared libraries are used by a portal, you can choose to push them to another instance while deploying or propagating the portal.
Moving Connections Details from Staging to Production
Administrators can use the WLST commands exportWebCenterPortalConnections
and importWebCenterPortalConnections
to migrate connections details from one WebCenter Portal installation to another. These commands are useful if you import or restore a portal and connections used in the source server, such as portlet producer connections and web service connections, do not exist on the target server.
For more information on the types of connections you can migrate, see Understanding Connection Property Files.
This section includes the following topics:
Exporting WebCenter Portal Connections Details to a File
If you have WebLogic Server Operator
role (or higher) you can use the WLST command exportWebCenterPortalConnections
to export connection information currently configured for a particular WebCenter Portal installation to a file:
exportWebCenterPortalConnections(appName, fileName, [connectionType, connectionName, logFile, server, applicationVersion])
Note:
You cannot export connections for a specific portal. Connections are shared across all the portals.
The options that you set depends on the connection information you want to export. For command syntax, see exportWebCenterPortalConnections
in WebCenter WLST Command Reference
Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Here are a few examples:
Example 1 - Deploying all WSRP producer and external application connections to a file
The following example only exports WSRP producer and external application connections to a file named myconnection.properties
:
exportWebCenterPortalConnections(appName='webcenter', fileName='/myConnections/myconnection.properties', connectionType='wsrpProducerConnection,externalAppConnection')
Example 2 - Deploying specific WSRP producer connections to a file
The following example exports connection configuration information for two WSRP producer connections named MyWSRP1
and MyWRSP2
:
exportWebCenterPortalConnections(appName='webcenter', fileName='/myConnections/connection.properties', connectionType='wsrpProducerConnection', connectionName='MyWSRP1,MyWSRP2')
Importing New WebCenter Portal Connections from a File
If you have WebLogic Server Operator
role (or higher) you can use the WLST command importWebCenterPortalConnections
to deploy connection information exported from one WebCenter Portal installation to another.
importWebCenterPortalConnections(appName, fileName, [promptForPassword, logFile, server, applicationVersion])
Only new connections are imported on the target. Connections that already exist on the target are ignored. The source connection information must be exported using the the WLST command exportWebCenterPortalConnections
. To find out how, see Exporting WebCenter Portal Connections Details to a File.
If required, you can edit the file that contains the connection information before you deploy the connection information on the target. See also Understanding Connection Property Files.
Example 1 - Importing connections from a file
The following example imports connections defined in a file named myconnection.properties
located in /myConnections
. Detailed information about the import connection operation is also logged to importConnection.log
:
importWebCenterPortalConnections(appName='webcenter', fileName='/myConnections/myconnection.properties',logFile='importConnection.log')
Example 2 - Importing connections that require credentials
The following example imports connections defined in a file named myconnection.properties
located in /myConnections
and prompts you for credentials if required:
importWebCenterPortalConnections(appName='webcenter', fileName='/myConnections/myconnection.properties', promptForPassword=1)
For command syntax, see importWebCenterPortalConnections
in WebCenter WLST Command Reference
Reference.
For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.
Migrating Discussions Resources for a Portal
After you move/migrate one or more portals to another server, you can (optionally) migrate portal data that is stored by various back-end components. This includes migrating discussions resources if they are used in the portal.
Discussions:
After importing one or more portals, consider initiating an search crawl to index the newly imported data.
Exporting Portal Discussions to an Archive
Use the discussions server's Admin Console to export discussions associated with a particular portal.
Portal discussions are exported to an .xml
file, and saved to a .zip
file in the DOMAIN_HOME/config/fmwconfig/servers/<target_server_name>/owc_discussions/data/
directory.
Where DOMAIN_HOME
is the path to the Oracle WebLogic Server domain. For example, MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/WC_Collaboration/owc_discussions/data/
.
To export discussions for a portal:
-
Login to the Admin Console for the discussions server.
You can login directly if you know the console's URL. For example:
http://example.com:8890/owc_discussions/admin
Alternatively, log in through WebCenter Portal as follows:
-
Open WebCenter Portal administration.
For details, see Exploring the Settings Pages in WebCenter Portal Administration.
-
Click Portals.
-
Select the portal whose discussions you want to export, then select Administer.
-
Click Tools and Services, then Discussions.
-
Note down the Forum Name/Forum ID or Category Name/Category ID associated with the portal.
WebCenter Portal's discussions server generates discussion category and forum IDs sequentially. If this ID exists on the target system, the imported forum (or category) will be assigned a new, unique ID, and therefore you must reconfigure the imported portal, to point to the new ID. For details, see Step 11 below.
-
Click Administer Forums, and login to the Discussions Server Admin Console.
-
-
In the Admin Console, select the System menu and select XML Import & Export in the sidebar.
-
Select Data Export.
-
Set the following options (Figure 32-15):
-
Export Options - Select Custom Options, and select all the check boxes.
-
Export Content - Select Export Specific Content, and select the name of the forum or category required.
Note: Portals that support multiple forums use a category to store discussions. Other portal use a single forum.
-
Export location, Export filename, Export file encoding - Keep the default values.
Figure 32-15 Exporting Discussions for an Individual Portal
Description of "Figure 32-15 Exporting Discussions for an Individual Portal" -
-
Click Start Export.
-
Once complete, copy the
.zip
file (that contains the export.xml
file) from theMW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/<server_name>/owc_discussions/data
directory to same location on the target discussions server.For example:
MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/WC_Collaboration/owc_discussions/data
Before importing discussions on the target system, the portal you are migrating must exist on the target. See Importing a Portal from an Archive Using WebCenter Portal Administration.
Importing Portal Discussions from an Archive
Use the discussions server's Admin Console to import discussions exported from another WebCenter Portal environment.
Ensure that the associated portal exists on the target before you import the discussion data. See Exporting and Importing Portal Archives or Directly Deploying Portals Using WLST.
Note:
WebCenter Portal's discussions server generates discussion category and forum IDs sequentially. Therefore, when importing discussion data between two targets (or source to target), there is a chance that the same IDs exist on both systems. When ID clashes occur, the imported forum (or category) is assigned a new, unique ID and therefore you must reconfigure the portal to point to the new ID. See Step 11 below for details.
To import discussions for a particular portal:
-
Log into the Admin Console for the target discussions server.
You can login directly if you know the console's URL. For example:
http://example.com:8890/owc_discussions/admin
Alternatively, log in through WebCenter Portal as follows:
-
Open WebCenter Portal administration.
For details, see Exploring the Settings Pages in WebCenter Portal Administration.
-
Click Portals.
-
Select the portal for which you want to import data, and then select Administer.
-
Click Tools and Services, then Discussions.
-
Click Administer Forums (on the far right), and log into the Admin Console.
-
-
In the Admin Console, select the System menu and then select XML Import & Export in the sidebar.
-
Select Data Import.
-
Select the appropriate import file from the list available (Figure 32-16).
If the file you want is not listed, copy the export
.zip
file from the source directoryDOMAIN_HOME/config/fmwconfig/servers/<target_server_name>/owc_discussions/data/
to same location on this target. See also, Exporting Portal Discussions to an Archive.Where
DOMAIN_HOME
is the path to the Oracle WebLogic Server domain. For example:MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/WC_Collaboration/owc_discussions/data/
Figure 32-16 Importing Discussions for a Portal
Description of "Figure 32-16 Importing Discussions for a Portal" -
Click Start Import.
On import, the discussions data is copied to the discussions server. In the next step you reassociate the portal you migrated earlier with this newly imported data.
-
Select the Content menu, and then select Content Summary in the sidebar.
All the categories and forums in the system are listed here.
-
Select WebCenter, and then click the Move button for the newly imported forum or category.
-
Select the root category for the target WebCenter Portal, and click Move Categories.
The Category Summary page shows the new location.
-
Click Permissions in the sidebar.
-
Deselect all the permissions for the User Types: Anyone and Registered Users, and click Save Changes (Figure 32-17).
-
In WebCenter Portal, navigate to Discussions Forum Settings for the portal to reassociate the portal with the discussion data that you just imported:
-
Open WebCenter Portal administration.
For details, see Exploring the Settings Pages in WebCenter Portal Administration.
-
Click Portals.
-
Select the portal for which you want to import data, and then select Administer.
-
Click Tools and Services, then Discussions.
-
Click the Search icon besides Category ID or Forum ID, select the imported category (or forum) from the list, and click
Select
. -
Click Save.
-
Propagating and Redeploying Portals in Production
This section includes the following topics:
Understanding Portal Propagation
Administrators can propagate portal changes made in staging to production if the stage and production environments are connected and kept "in sync". For example, you can propagate portal changes such as new pages and assets added or modified. Oracle strongly recommends that you always make changes in stage first and then push your portal changes to production using deployment or propagation. Propagation does not require the production server to be restarted or incur any downtime.
For lists of changes propagated from staging to production, see Table 32-4
Table 32-4 Portal Changes Propagated to Production
Portal Changes Propagated | Yes / No |
---|---|
Portal pages |
Yes |
Assets |
Yes |
Portlets |
Yes |
Portal folder content changes |
Yes |
Portal activity/usage data (activity streams, calendar events, feedback, list, links, message boards, people connections, profiles, surveys) |
No |
Portal security data excluding custom page security (portal roles and permissions, member details and their role assignments) |
No |
External content referenced by the portal (through portal pages, portal assets, Content Presenter display templates, Site Studio, and so on...) |
No |
Data stored on external servers (discussions, mail, announcements, analytics, custom task flows and shared libraries) |
No |
Any structural changes to a portal require redeployment.
-
Custom security can be set for portal pages. During portal propagation, custom page security changes are propagated. However, only portal-level security changes for existing roles (roles that are present on both the source and target servers) are propagated. If you created a new role and added new page permissions or added or removed members, changes are not propagated as the new role is not present on the target server. To migrate such changes, you must redeploy the portal.
- After deploying a portal if you enable a new tool, such as documents, or disable it on the source server and then propagate portal changes, tool-related changes are not reflected on the target server. You must redeploy your portal for the changes to take effect.
Propagating Portal Changes Using WebCenter Portal
To propagate changes made to a portal to the target server:
Propagating Portal Changes Using WLST
Direct portal propagation is only possible if a connection exists between the source and target environments and the portal was previously deployed directly to the target using deployWebCenterPortals
WLST command. See Directly Deploying Portals Using WLST.
To propagate metadata changes from staging to production:
Here are some examples:
Example 1 - Propagating portal metadata changes
The following commands create a connection to the production server (MyProductionConnection
) and then propagates changes for a portal named myPortal
to the target server:
adf_createHttpURLConnection(appName='webcenter', name='MyProductionConnection', url='http://example.com:7777', user='myuser', password='mypassword', realm='ProductionRealm') propagateWebCenterPortal(appName='webcenter', portalName='myPortal', targetConnectionName='MyProductionConnection')
Example 2 - Backing up the target portal before propagating portal metadata changes
The following example backs up myPortal
on the target, propagates portal changes, including any changes to the portal content and shared assets used in the portal, and also specifies a name and location for the propagation log file:
propagateWebCenterPortal(appName='webcenter', portalName='myPortal', targetConnectionName='MyProductionConnection', savePortal=1 propagateLog='/mypropagationlogs/myPortal_propagation.log', propagateSharedAssets=1, propagatePortalContent=1,)