32 Deploying Portals, Templates, Assets, and Extensions

WebCenter Portal provides a set of utilities that enable administrators to deploy, back up, or move information between WebCenter Portal instances and stage or production environments.

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

When a portal is deployed, the following details are always included:
  • 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

When deploying a portal, you can optionally choose to include the following as part of portal deployment:
  • 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, suppose extend.spaces.webapp is dependent on CustomSharedLibrary1, and CustomSharedLibrary1 is dependent on CustomSharedLibrary2. If an updated version is available for both CustomSharedLibrary1 and CustomSharedLibrary2, only CustomSharedLibrary1 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 follows
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.

In some situations the source and target both use the same external server, for example, a portlet producer server or Oracle Internet Directory server might be shared across both environments.

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:

  1. Log on to WebCenter Portal, and navigate to portal administration.

  2. Click Tools and Services.

  3. Select Portal Server Connections from the list of tools and services.

  4. Click Create.

  5. In the Create Portal Server Connection page, specify the following details:

    1. Name: Specify the name of the connection. Note that only alphanumeric characters can be used.

    2. 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.

    3. Username: Type the user name used for connecting to the target server.

    4. Password: Type the password for the specified user name.

  6. Click Test to make sure the connection works.

  7. 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:

  1. In WebCenter Portal, access portal administration as described in Accessing Portal Administration in Building Portals with Oracle WebCenter Portal
  2. Click the Deploy icon.
  3. From the Server Name list under Target Portal Server, select the portal server connection you want to use to deploy your portal.
    You created this connection as described in Creating a Portal Server Connection.
  4. In the Comments box, specify comments, if any, about portal deployment.
  5. In the Options section, select the deployment options:
    • Include Portal Content: Select to specify that the portal content stored on Content Server must be included in portal deployment on the target server.

    • Include Shared Assets: Deploys the shared assets used by the portal. Clear the check box if you do not want to deploy shared assets.

    • Include Shared Libraries: Deploys the shared libraries used by the portal. Clear the check box if you do not want to deploy shared libraries. If you include shared libraries in portal deployment, you must restart the target server after deploying the portal for the shared library changes to be picked up.

    If this is the first time the portal is being deployed, the Redeploy instead of propagating changes check box appears disabled. Expanding the Change Details section displays a message that the portal is being deployed (for the first time) and hence all the data will be carried over to the target server. When you propagate a portal, this section displays the changes made to the portal since the last deployment.

  6. Click Deploy.

    The Deploy Portals dialog displays the progress and status of portal deployment. While the portal is being deployed, you can choose to close the dialog and continue to work on the portal if required.

    Figure 32-3 Portal Deployment Status

    Description of Figure 32-3 follows
    Description of "Figure 32-3 Portal Deployment Status"
  7. Click Close.

    Once a portal is deployed, you can view its deployment history and status.

    See Viewing Portal Deployment History.

  8. Restart the target server where the portal is deployed if you included shared libraries in portal deployment.
Viewing Portal Deployment History

To view portal deployment history using the WebCenter Portal Administration:

  1. On the Portals administration page, click Portal Deployments.
  2. On the Recent Deployments tab, click the Details link next to a portal to view deployment details.

    The Portal Deployment Details dialog displays the name of the target server and the date and time of deployment. It also shows the comments, if any, added while deploying the portal.

    Figure 32-4 Portal Deployment Details

    Description of Figure 32-4 follows
    Description of "Figure 32-4 Portal Deployment Details"
  3. Click Close.
  4. To view each portal's deployment status, click the Deployment History tab.
  5. Click the deployment status link for a portal to display its deployment operations.

    Figure 32-6 shows the two records for the portal named MyPortal, one for initial deployment and the other for propagation.

    Figure 32-6 Deployment Operations

    Description of Figure 32-6 follows
    Description of "Figure 32-6 Deployment Operations"
  6. Click Details next to a deployment operation to display more details.

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:

  1. Verify that the name of the managed server on which WebCenter Portal is deployed is the same in both the source and target environments. For example, WC_Portal.

    You can only run deployWebCenterPortal if the managed server names match. If the managed server name is different, use portal archive deployment instead. as described in Object Missing.

  2. Verify that you have at least the WebLogic Server Monitor role and the WebCenter Portal permission Portals: Manage Security and Configuration.
  3. Ensure a connection exists between the source and target WebCenter Portal. If a connection created using WebCenter Portal Administration already exists, you can use it to deploy portals or you can use the UI to create a new one.

    If a connection to the target from the source environment does not exist and you want to create one using WLST, use the WLST command adf_createHttpURLConnection.

    For example, in the source environment run:

    adf_createHttpURLConnection(appName='webcenter',name='MyWebCenterPortalTarget', 
     url='http://example.com:7777', user='myuser', password='mypassword',
     realm='ProductionRealm')
    

    See also Running Oracle WebLogic Scripting Tool (WLST) Commands.

Step 2: Run deployWebCenterPortal in the Source Environment

In the source WebCenter Portal:

  1. Start the WLST tool from your source WebCenter Portal Oracle home directory, and connect to the Administration Server for WebCenter Portal.
  2. Run the WLST command deployWebCenterPortal to deploy the portal on the target server.
    deployWebCenterPortal(appName, portalName, targetConnectionName
     [deployCustomizations, deployPortalContent, deploySecurity, deployData,
     deployActivities, deploySharedAssets, deployConnections, overwrite, savePortal, deployLog, server,
     applicationVersion])
    

    For detailed command syntax and descriptions, see deployWebCenterPortal in WebCenter WLST Command Reference Reference. The options that you set depend on your specific deployment requirements.

    The following example deploys a new portal named myPortal for the first time on the target server. It also deploys all its associated content and specifies a name and location for the deploy log file:

    deployWebCenterPortal(appName='webcenter',portalName='myPortal',
    targetConnectionName='MyWebCenterPortalTarget', deployPortalContent=1,deployActivities=1,
    deployLog='/mydeploylogs/myPortal_deploy.log')

    Note:

    Always set deploySecurity=1 when importing a brand new portal as you cannot import a new portal without a security policy.

    Redeploying a portal that exists on the target

    If you want to redeploy a portal that already exists on the targer server, you use the deployWebCenterPortal command, with overwrite=1. The following example backs up a portal named myExistingPortal on the target and then overwrites the target portal (overwrite=1) with the source portal. The content associated with the target portal is preserved:

    deployWebCenterPortal(appName='webcenter',portalName='myExistingPortal',
    targetConnectionName='MyWebCenterPortalTarget', deployPortalContent=0,overwrite=1,savePortal=1)
    
  3. Examine the deployment log file.

    This file is either available at the location you specified (deployLog) or in a file named PortalDeploy_<timestamp>.log in your temporary directory.

Step 3: Verify Newly Deployed Portal in the Target Environment

In the target WebCenter Portal:

  1. Log in to the target WebCenter Portal.
  2. Navigate to the new portal deployment.
  3. Verify that the portal works as expected.

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.

Figure 32-7 Deploying Portal Archives

Description of Figure 32-7 follows
Description of "Figure 32-7 Deploying Portal Archives"

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.

Figure 32-8 Portal Archive Deployment

Description of Figure 32-8 follows
Description of "Figure 32-8 Portal Archive Deployment"
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 command exportWebCenterPortalConnections. 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 follows
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

url

proxyHost

proxyPort

timeout

externalApp

tokenType

defaultUser

issuerName

recipientAlias

Yes

Yes

Yes

No

No

No

No

No

No

Security configuration post deployment:

registrationProperties

keyStorePath

keyStorePswd

sigKeyAlias

sigKeyPswd

encKeyAlias

encKeyPswd

enforcePolicyURI

Foot 1

PDK-Java producer

url

proxyHost

proxyPort

subscriberId

serviceId

sharedKey

timeout

establishSession

externalApp

Yes

Yes

Yes

No

No

No

No

No

No

Security configuration post deployment:

mapUser

useProxy

Web service connection

url

proxyHost

proxyPort

mtom

addressing

wsrm

security

Yes

Yes

Yes

No

No

No

No

Web service connections are used by data controls

Footref 1

URL connections -

HTTP URL

url

authenticationType

connectionClassName

realm

Yes

No

No

No

Security configuration post deployment:

password

user

attributes

URL connections -

File URL

url

Yes

Analytics collector

collectorPort

host

isEnabled

timeout

isUnicast

defaultConnection

Yes

No

No

No

No

No

host: represents clusterName when isUnicast is set to 0 and collectorHost when isUnicast is set to 1

BPEL server

url

policy

recipientKeyAlias

linkURL

Yes

No

No

No

Discussions server

url

adminUser

application.root.category.id

recipientKeyAlias

policyURIForAuthAccess

policyURIForPublicAccess

timeout

defaultConnection

Yes

Yes

Yes

No

No

No

No

No

External applications

url

authMethod

userFieldName

pwdFieldName

displayName

publicCredentialEnabled

sharedCredentialEnabled

AdditionalFields

Yes

No

No

No

No

No

No

No

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

url

poolName

userDomain

adapter

timeout

appId

AdditionalProperty

defaultConnection

Yes

Yes

Yes

No

No

No

No

No

Mail server

imapHost

smtpHost

imapPort

smtpPort

smtpSecured

imapSecured

appId

timeOut

AdditionalProperties

defaultConnection

Yes

Yes

Yes

Yes

Yes

Yes

No

No

No

No

LDAP configuration post deployment:

LdapDomain

LdapDefaultUser

LdapHost

LdapBaseDn

LdapAdminUsername

LdapPort

LdapSecured

Personal events server

webServiceUrl

adapterName

appId

defaultConnection

Yes

No

No

No

Search

url

appUser

defaultConnection

indexAliasName

Yes

No

No

Users will be prompted for appPassword if promptForPassword is set to 1

WebCenter Content Server (socket)

serverHost

serverPort

extAppId

timeout

socketType

webContextRoot

cacheInvalidationInterval

binaryCacheMaxEntrySize

defaultConnection

Yes

Yes

No

No

No

No

No

No

No

Security configuration post deployment:

adminUsername

adminPassword

keystorePassword

privateKeyPassword

WebCenter Content Server (socketssl)

serverHost

serverPort

extAppId

timeout

socketType

webContextRoot

cacheInvalidationInterval

binaryCacheMaxEntrySize

defaultConnection

keystoreLocation

privateKeyAlias

Yes

Yes

No

No

No

No

No

No

No

No

No

Security configuration post deployment:

adminUsername

adminPassword

keystorePassword

privateKeyPassword

WebCenter Content Server (jaxws)

url

extAppId

timeout

socketType

webContextRoot

cacheInvalidationInterval

binaryCacheMaxEntrySize

defaultConnection

clientSecurityPolicy

Yes

No

No

No

No

No

No

No

No

Security configuration post deployment:

adminUsername

adminPassword

keystorePassword

privateKeyPassword

WebCenter Content Server (web)

url

extAppId

timeout

socketType

webContextRoot

cacheInvalidationInterval

binaryCacheMaxEntrySize

defaultConnection

Yes

No

No

No

No

No

No

No

Security configuration post deployment:

adminUsername

adminPassword

keystorePassword

privateKeyPassword

File System

path

Yes

Worklist connection

BPELConnection

No

Rest Connection

url

Yes

 

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 value enable. If the value is not set to enable or left blank, lifecycle operations will run in the default, non-secure mode. If the value is set to enable, lifecycle operations are secured, and checksum acts as the credentials for the encrypt or decrypt process.

  • Non-secure mode: By default, lifecycle operations run without any security restriction on archives.

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 thelifecycle.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.

Securing Archive Files
To secure application, portal, and asset archives, you can choose to set either the high-security mode or the moderate-security mode for lifecycle operations.
To secure your application, portal, and asset archives:
  1. Log on to WebCenter Portal.
  2. Configure the desired security mode to secure your archives:
    Option Procedure
    To enable the high-security mode
    1. Create a custom global attribute named ExternallySecureLifecycleOperations.

    2. Set the value of the custom attribute to enable. For information about creating a custom global attribute, see Adding a Global Attribute.

    To enable the moderate-security mode

    1. Register an external application and specify shared credentials. For information, see Registering External Applications.

    2. Create a custom global attribute named SecureLifecycleOperations. Specify the name of the external application as the value. For information about creating a custom attribute, see Adding a Global Attribute.

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:

  1. Complete the portal archive prerequisites described in Portal Export Prerequisites.
  2. Export the source portal:
  3. (Optional) Migrate externally stored data and content to the target:
  4. Import the portal on the target:
Object Missing

This object is not available in the repository.

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:

  1. On the Portals administration page (see Accessing the Portals Page in WebCenter Portal Administration), select the portal you want to export by highlighting the row in the table.

    Press Ctrl+click to select more than row.

    Note:

    To prevent data conflict during the export process, Oracle recommends that all the portals you select are offline during the export process, even if only temporarily.

    See Taking Any Portal Offline.

    Members with the Portals: Manage Security and Configuration permission can still access a portal when it is offline, so notify them to not make changes while you complete the export.

  2. Click Export in the toolbar.

    The Export Portals pane opens. All the portals that you select are listed.

    If you want to exclude a portal, click the Delete icon next to the portal's name.

  3. Enter a name for the Portal Archive with the file extension .par or accept the default name.

    The default filename for the portal archive includes a random number to ensure uniqueness: webcenter_random_number.par

  4. Select Include Portal Content to export each portal's content folder.

    A folder is automatically created in WebCenter Portal's content repository for portals that use document services to create, manage, and store portal documents (files, folders, wikis, blogs). Only content that is stored in this folder can be exported with the portal. The export does not, for example, include web content/pages displayed through Content Presenter since this information is not stored in the portal's content folder.

    Note:

    • The portal archive does not include any security settings. On import, the security group of the target portal server is applied.

    • Including content folders increases the size of the portal archive. If you are exporting a large number of portals or large content folders, make sure that your portal archive size does not exceed the maximum upload limit of 2 GB.

    • 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 and do not include MDS content within the asset archive, you can use MDS WLST commands exportMetadata/importMetadata to move the MDS content another time. 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/**')
  5. Select Include Shared Assets to export the shared assets used in the portal.
  6. Click Export.
    Progress information displays during the export process.

    Figure 32-11 Portal Export In Progress

    Description of Figure 32-11 follows
    Description of "Figure 32-11 Portal Export In Progress"
  7. Specify a location for the export archive (.par file) when the export process is complete.

    Select either of the following:

    • Download - Saves the export .par file to your local file system.

      Your browser downloads and saves the archive locally. The actual download location depends on your browser settings.

      Some browsers have settings that restrict the size of downloads. If your export archive is large and does not download, check your browser settings.

    • Save to Server - Saves the export .par file to a server location. The .par file is saved to the default path DOMAIN_HOME/WC_Archives, where DOMAIN_HOME refers to the domain location where WebCenter Portal is installed.

      When the file is saved, click OK to close the Information dialog.

  8. Click Close.
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:

  1. Ensure that you meet the portal import prerequisites listed in Portal Import Prerequisites.
  2. On the Portals administration page (see Accessing the Portals Page in WebCenter Portal Administration), click Import in the toolbar.

    The Import Portals dialog opens.

  3. Specify the location of your portal archive (.par file). Select one of:
    • Look on My Computer - Enter the location in the text box. Alternatively, click Browse to locate the directory on your local file system where the .par file is stored.

    • Look on WebCenter Portal Server - Enter the path on the server where WebCenter Portal is deployed, including the archive filename, in the text box. For example, /tmp/MyPortalExport.par. You can specify any shared location accessible from WebCenter Portal.

  4. Click Browse Archive to review the content available for import.

    The names of all the portals in the specified archive display in the table. The Type column indicates when there is a difference between the portals in the archive and those that exist on the target:

    • New - A portal with this name does not exist on the target. On import, a new portal is created.

    • Replace - A portal with this name and the same GUID exists on the target. The existing portal is deleted on import and replaced with the version in the portal archive.

    • Conflict - A portal with this name exists on the target but the portal on the target has a different GUID to the portal you are trying to import. Or similarly, this portal has the same GUID as one of the portals in the target but the portal names do not match.

      If the import process detects a conflict between the portals you are trying to import and those which exist on the target, you must resolve the issue. For example, if the conflict is due to matching names but different GUIDs you could either change the name of the source portal and create a new export archive, or rename the conflicting portal in the target application and import the same archive.

  5. Set import options as required.
    Field Description

    Include Portal Content

    (Only displays if the archive specified includes a content folder for one or more portal.)

    Select to import all content folders included in the archive. Folders that exist on the target are overwritten on import, and the security group of the target portal server is applied.

    Deselect this option to exclude portal content folders (if any). This option is useful when migrating between stage and production environments where test content is no longer required.

    Note: Portal archives that contain large content folders may exceed the maximum upload size for files (2 GB by default). Oracle recommends that you use the importWebCenterPortals WLST command to import any portal archive that exceeds the current upload size.

    See Importing a Portal from an Archive Using WLST. If necessary, you can increase the upload setting, see Changing the Maximum File Upload Size.

    Include Shared Assets

    Select to import shared assets, like skin and page templates, used in the portal.

  6. Click Import.
    • If you try to import portals that exist in the target WebCenter Portal application, the Confirm Replace Portal dialog displays. You must confirm whether you want to overwrite the existing portals.

      To delete existing portals and replace them with imported versions, click Yes. Click No to cancel the import process.

    • If the import process detects a conflict between the portals you are trying to import and those which exist on the target, a message displays to help you resolve the issue. For example, conflict messages display if a portal on the target application has the same name but a different GUID to a portal you are trying to import. In this instance you could change the name of the source portal and create a new export archive, or rename the conflicting portal in the target application and import the same archive.

    • If the portal archive exceeds the maximum upload size for files (2 GB by default) you cannot import the portals. Oracle recommends that you use the importWebCenterPortals WLST command to import any portal archive that exceeds the current upload size.

      For details, see Importing a Portal from an Archive Using WLST. If necessary, you can increase the upload setting. For details, see Changing the Maximum File Upload Size.

    Note:

    • If you are working with 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 and do not include MDS content within the asset archive, you can use MDS WLST commands exportMetadata/importMetadata to move the MDS content another time. 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/**')
  7. In the information message, click Yes to confirm that you want to import the portals.

    An information message displays when all portals import successfully.

    Figure 32-14 Portal Import Successful

    Description of Figure 32-14 follows
    Description of "Figure 32-14 Portal Import Successful"
  8. Click Close.

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:

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

Administrators can export device groups and devices to a file (.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
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

  • Administrator

OR

Shared asset

  • Create, Edit, Delete <resourcetype>

  • This permission enables you to create and manage shared assets for WebCenter Portal.

  • Manage Configuration

  • This application-level permission (Manage Configuration) gives you access to WebCenter Portal Administration pages.

Portal asset

  • Portal Manager

OR

Portal asset

  • Create, Edit, Delete Resources (standard)

    OR

    Create, Edit, Delete <resourcetype> (advanced)

  • These permissions enable you to create and manage assets for a particular portal. Either standard or advanced permissions will apply, depending on the portal.

  • Manage Configuration

  • This portal-level permission (Manage Configuration) gives you access to the asset administration page for a particular portal.

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:

  1. 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:

    1. Open WebCenter Portal administration.

      For details, see Exploring the Settings Pages in WebCenter Portal Administration.

    2. Click Portals.

    3. Select the portal whose discussions you want to export, then select Administer.

    4. Click Tools and Services, then Discussions.

    5. 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.

    6. Click Administer Forums, and login to the Discussions Server Admin Console.

  2. In the Admin Console, select the System menu and select XML Import & Export in the sidebar.

  3. Select Data Export.

  4. Set the following options (Figure 32-15):

    1. Export Options - Select Custom Options, and select all the check boxes.

    2. 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.

    3. 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 follows
    Description of "Figure 32-15 Exporting Discussions for an Individual Portal"
  5. Click Start Export.

  6. Once complete, copy the .zip file (that contains the export .xml file) from the MW_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:

  1. 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:

    1. Open WebCenter Portal administration.

      For details, see Exploring the Settings Pages in WebCenter Portal Administration.

    2. Click Portals.

    3. Select the portal for which you want to import data, and then select Administer.

    4. Click Tools and Services, then Discussions.

    5. Click Administer Forums (on the far right), and log into the Admin Console.

  2. In the Admin Console, select the System menu and then select XML Import & Export in the sidebar.

  3. Select Data Import.

  4. 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 directory DOMAIN_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 follows
    Description of "Figure 32-16 Importing Discussions for a Portal"
  5. 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.

  6. Select the Content menu, and then select Content Summary in the sidebar.

    All the categories and forums in the system are listed here.

  7. Select WebCenter, and then click the Move button for the newly imported forum or category.

  8. Select the root category for the target WebCenter Portal, and click Move Categories.

    The Category Summary page shows the new location.

  9. Click Permissions in the sidebar.

  10. Deselect all the permissions for the User Types: Anyone and Registered Users, and click Save Changes (Figure 32-17).

    Figure 32-17 Editing Forum Permissions

    Description of Figure 32-17 follows
    Description of "Figure 32-17 Editing Forum Permissions"
  11. In WebCenter Portal, navigate to Discussions Forum Settings for the portal to reassociate the portal with the discussion data that you just imported:

    1. Open WebCenter Portal administration.

      For details, see Exploring the Settings Pages in WebCenter Portal Administration.

    2. Click Portals.

    3. Select the portal for which you want to import data, and then select Administer.

    4. Click Tools and Services, then Discussions.

    5. Click the Search icon besides Category ID or Forum ID, select the imported category (or forum) from the list, and click Select.

    6. 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:

  1. In WebCenter Portal, access portal administration as described in Accessing Portal Administration in Building Portals with Oracle WebCenter Portal.
  2. Click the Deploy icon.

    Note:

    You will see the Deploy icon only if you are granted the application-level permission Portal Server: Deploy.
  3. Under Target Portal Server, from the Server Name list, select the connection to be used for propagating portal changes. It must be the same connection that was used to deploy the portal.
  4. In the Comments box, specify any comments related to portal propagation.
  5. In the Options section, select the propagation options:
    • Include Portal Content: Select to specify that the portal content stored on Content Server must be propagated to the target server.

    • Include Shared Assets: Propagates the shared assets used by the portal. Clear the check box if you do not want to propagate shared assets.

    • Include Shared Libraries: Propagates the shared libraries used by the portal. Clear the check box if you do not want to propagate shared libraries. If you choose to propagate shared libraries, you must restart the target server after propagating portal changes for the shared library changes to be picked up.

  6. Expand the Changed Details section to view the artifacts or settings that will be propagated.
    • Portal Assets: Lists the portal assets that have been added or updated since the last propagation. For example, Figure 32-18 the Pages category shows that three pages were added since the last propagation.

    • Shared Assets: Lists the shared assets used by the portal that were added or updated since the last propagation.

    • Shared Libraries: Lists the shared libraries used by the portal that were added or updated since the last propagation.

    Figure 32-18 Propagating Portal Changes

    Description of Figure 32-18 follows
    Description of "Figure 32-18 Propagating Portal Changes"
  7. Click Propagate.

    The Deploy Portals dialog displays the progress and status of portal propagation. While the portal is being propagated, you can choose to work on the portal if required.

  8. Click Close.
  9. If you propagated shared libraries, restart the target server for the shared libraries changes to take effect. For information, see Starting and Stopping Managed Servers for WebCenter Portal Application Deployments.

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:

  1. Run the WLST command propagateWebCenterPortal to propagate metadata for the portal.
    propagateWebCenterPortal(appName, portalName, targetConnectionName,
     [savePortal, propagateLog, propagateSharedAssets, propagatePortalContent, server, applicationVersion])
    

    The options that you set depends on your specific requirements. For command syntax, see propagateWebCenterPortal in WebCenter WLST Command Reference Reference.

    For information on how to run WLST commands, see Running Oracle WebLogic Scripting Tool (WLST) Commands.

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,)

Redeploying a Portal Using WebCenter Portal

In WebCenter Portal, when you redeploy a portal, all information about the existing portal is deleted from the target server and a new portal is created.

To redeploy a portal using WebCenter Portal:

  1. In WebCenter Portal, access portal administration as described in Accessing Portal Administration in Building Portals with Oracle WebCenter Portal.
  2. Click the Deploy icon.

    Note:

    You will see the Deploy icon only if you are granted the application-level permission Portal Server: Deploy.
  3. In the Comments box, specify any comments related to portal redeployment.
  4. Under Target Portal Server, from the Server Name list, select the connection that was used for deploying deploy the portal.
  5. In the Options section, select the options:
    • Redeploy instead of propagating changes: Select to specify that the portal needs to be redeployed.

    • Include Portal Content: Select to specify that the portal content stored on Content Server must be included in portal redeployment.

    • Include Shared Assets: Deploys shared assets used by the portal. Clear the check box if you do not want to deploy shared assets.

    • Include Shared Libraries: Deploys the shared libraries used by the portal. Clear the check box if you do not want to deploy shared libraries. If you include shared libraries in portal deployment, you must restart the target server after redeploying the portal for shared library changes to be picked up.

    Figure 32-19 Redeploying a Portal

    Description of Figure 32-19 follows
    Description of "Figure 32-19 Redeploying a Portal"
  6. Click Deploy.

    The Deploy Portals dialog displays the progress and status of portal deployment. While the portal is being redeployed, you can choose to work on the portal if required.

  7. Click Close.
  8. If you chose to redeploy shared libraries, restart the target server for the shared libraries changes to take effect. For information, see Starting and Stopping Managed Servers for WebCenter Portal Application Deployments.