40 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 installations, and stage or production environments.

This chapter includes the following topics:

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 Section 39.6, "Permissions Required to Perform WebCenter Portal Life Cycle Operations."

See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."

40.1 Deploying Portals

This section includes the following topics:

40.1.1 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 include all or some of the source portal's data.

Deploying a new portal on the target server and redeploying an existing portal are exactly the same. When you deploy a portal that already exists on the target, it is simply deleted and recreated as a new portal.

Note:

If you want to propagate metadata changes on the source portal to the target, rather than redeploying the whole portal, see Section 40.9.3, "Propagating Portal Changes in Staging to Production."

You can deploy online portals to a portal archive or directly deploy portals to another server:

  • Portal archive deployment - In most situations you will create an archive of the source portal (.par file) and then import the archived portal on the target server. You can use Portal Builder administration or WLST commands to export portals to an archive and then import portals from the file.

    For details, see Section 40.1.2.2, "Deploying Portal Archives to a Different Server."

  • Direct portal deployment - If you have a direct connection to your target server, you can use the deployWebCenterPortal WLST command to deploy portals to another target server. This method is useful if you want to propagate portal metadata changes.

    For details, see Section 40.9.2, "Directly Deploying Portals From Staging to Production."

Figure 40-1, "Deploying Portals to Another Target Server" illustrates the different ways you can move a portal (and its associated data) to another server.

Figure 40-1 Deploying Portals to Another Target Server

Description of Figure 40-1 follows
Description of "Figure 40-1 Deploying Portals to Another Target Server"

Information Deployed with a Portal

Internally stored data, that is, portal data stored in the WebCenter Portal database, WebCenter Content repository, and MDS can be deployed on the target at the same time as the portal. Depending on your requirements, you can include or exclude this information on deployment by setting options on deployment (or import):

Table 40-1 Portal Deployment Options

Information You Can Deploy with a Portal WLST Option importWebCenterPortals Portal Builder Import Option WLST Option deployWebCenterPortal

Portal pages

Always included

Always included

Always included

Assets

  • Page templates

  • Navigations

  • Resource catalogs

  • Skins

  • Page styles

  • Content presenter display templates

  • Task flow styles

  • Task flows

  • Data control

  • Pagelets

Always included

Always included

Always included

Portal content folder

importPortalContent

Include Portal Folder on Content Server

deployPortalContent

Portal activity/usage data:

  • activity streams

  • calendar events

  • feedback

  • lists

  • links

  • message boards

  • people connections

  • polls

  • profiles

  • surveys

importData

Include Services Data

deployData

Portal security data:

(Optional if portal exists on the target)

  • portal roles and permissions

  • member details and their role assignments

importSecurity

Include Security

deploySecurity

Portal customizations:

  • portal-level customizations (system pages, assets, task flows, and so on)

  • user-level customizations (sometimes referred to as user personalizations)

importCustomizations

Include Customizations

deployCustomizations

Information Not Migrated 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

  • portal discussions

  • portal mail

  • portal analytics

  • custom task flows / shared libraries

  • portal connections *

Other information not migrated includes:

  • shared assets

  • Home portal

Note:

* Connections are exported and imported separately. For more information, see Section 40.1.2.1.3, "Understanding Connection Property Files."

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. For details, see Section 40.8.1, "Migrating Back-end Components for Individual Portals."

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.

40.1.2 Deploying Portal Archives

Administrators can use Portal Builder or WLST commands to deploy portal archives (.par files) to any WebCenter Portal (11.1.1.8.x) installation. The target WebCenter Portal must be up and running when you deploy (or import) one or more portals from a file.

Figure 40-2 Deploying Portal Archives

Description of Figure 40-2 follows
Description of "Figure 40-2 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 Section 40.9, "Managing Portals in Production."

40.1.2.1 Understanding Portal Archives

You can use Portal Builder or the exportWebCenterPortals WLST command to create a portal archive (.par file) for a single portal, a complete portal hierarchy, or you can archive multiple portals and portal hierarchies in the same .par file.

Portal archives can contain:

  • One or more portal data archive files (.pdr)

  • An export log file (.log)

  • A WebCenter Portal connection properties file (connection.properties)

Note:

You can extract any portal archive (.par file) using the listWebCenterPortalArchive WLST command.

Figure 40-3 Portal Archive Deployment

Portal Archive Deployment
Description of "Figure 40-3 Portal Archive Deployment"

This section includes the following:

40.1.2.1.1 Understanding Portal Data Files (PDRs)

Portal archives include a portal data file (PDR) for each portal or portal hierarchy that you add to the archive, as illustrated in Figure 40-3, "Portal Archive Deployment".

The portal data file contains two files:

  • transport.mar - A metadata archive that captures metadata, data, and content for a single portal or portal hierarchy:

    • Metadata: Metadata stored in MDS for portal pages, assets, global customizations, user customizations, portlets, and so on.

    • Data: Data stored in WebCenter Portal database tables for portal activity, portal events, and so on.

    • Content: Content in the folder specifically created for any portal that offers document services.

      The folder is archived to a .zip file located at: oracle\webcenter\lifecycle\importexport\data\oracle-webcenter-doclib\docsexport.zip

      The archive does not include any web content that is referenced by the portal or content that is stored at any other location. Only the folder assigned to the portal on the back-end WebCenter Content Server is included with the portal.

  • policy-store.xml - Security policy for the portal or portal hierarchy.

Table 40-2, "Information Exported to Portal Archives (PDR Files)" describes the information included in .pdr file in more detail, shows you how to where information is located within the file, and highlights which information is optional on import.

Table 40-2 Information Exported to Portal Archives (PDR Files)

Information Exported to PDR Files Exported Imported Location in PDR
Always / Optional / Never

Portal pages

Always

Always

\transport.mar\oracle\webcenter\page\

Portlets

Always

Always

\oracle\adf\portlet

Portal Assets

  • Page templates

  • Navigations

  • Resource catalogs

  • Skins

  • Page styles

  • Content presenter display templates

  • Task flow styles

  • Task flows

  • Data controls

  • Pagelets

Always

Always

\transport.mar\oracle\webcenter\siteresources\

Portal content folder

Optional

Optional

\transport.mar\oracle\webcenter\lifecycle\importexport\data\oracle-webcenter-doclib\docsexport.zip

Portal activity/usage data:

  • activity streams

  • calendar events

  • feedback

  • lists

  • links

  • message boards

  • people connections

  • profiles

  • polls

  • surveys

  • tags

Always

Optional

\transport.mar\oracle\webcenter\lifecycle\importexport\data

Portal security data:

  • portal roles and permissions

  • member details and their role assignments

Always

Optional

(If portal exists on the target)

policy-store.xml

Portal customizations:

  • portal-level customizations (system pages, assets, task flows, and so on)

  • user-level customizations (sometimes referred to as user personalizations)

Always

Optional

\transport.mar\oracle\webcenter\

External content referenced by the portal through:

  • portal pages

  • portal assets

  • Content Presenter display templates

  • Site Studio

  • ...and so on

Never*

-

-

Data stored on external servers:

  • discussions

  • mail

  • announcements

  • analytics

  • custom task flows and shared libraries

Never*

-

-

Shared assets

Never*

-

-

Home portal

Never*

-

-

*Information Not Included in PDR Files

Portal data archives do not include shared assets or any information relating to the Home portal.

Portal data archives do not include content that is stored outside the portal's own content folder, such as content used by portal assets, portal pages, Content Presenter or Site Studio. Similarly, the archive does not contain other externally stored data such as discussions, announcements, and mail. To learn how to move this data, see Section 40.8.1, "Migrating Back-end Components for Individual Portals."

40.1.2.1.2 Understanding Export Log Files

When you export one or more portals, a log file (.log file) is provided inside the portal archive (.par file). The export log lists all the portals, MDS metadata files, and data (names of database tables that contain portal data) that are included in the archive.

Export logs are very useful for reference purposes and if you want to compare portal archives.

Example 40-1, "Portal Archive Export Log" shows the general format of an export log.

Example 40-1 Portal Archive Export Log

Exporting portal: MySalesPortal

Processing subportals : MySales, TeamSales

MDS Documents included for portal: MySalesPortal, MySales, TeamSales
/oracle/webcenter/lifecycle/importexport/data.xml
/oracle/webcenter/siteresources/... 
/oracle/webcenter/page/...
/pageDefs/oracle/webcenter/page/...
/oracle/webcenter/siteresources/...
/oracle/webcenter/space/metadata/spaces/...
/oracle/webcenter/translations/...
/oracle/webcenter/space/metadata/spaces/...
/oracle/webcenter/security/...
/oracle/webcenter/framework/scope/...

Exported database data for portal: MySalesPortal, MySales, TeamSales  at 2012-09-26-05:00:59

Database data included for portal: MySalesPortal, MySales, TeamSales
  WC_LIST_ROW$
  WC_RELATIONSHIP_RESOURCE
  WC_RELATIONSHIP_RESOURCE_ATT
  WC_RELATIONSHIP_INFO
  WC_RELATIONSHIP
  WC_RELATIONSHIP_INFO_ATT
  WC_PPL_COMMON_SETTING
  WC_SURVEY
  WC_SURVEY_PROPERTY
  WC_SURVEY_QUESTION
  WC_SURVEY_QUESTION_PROPERTY
  WC_CAL_CATEGORY
  WC_CAL_EVENT
  WC_CAL_ATTENDEE
  WC_AS_ACTIVITY_ELEMENT
  WC_AS_CUSTATTR
  WC_AS_OBJECT_DETAIL
  WC_AS_OBJECT
  WC_AS_ACTOR_DETAIL
  WC_AS_ACTOR
  WC_COMMENT
  WC_LIKE

Archive created for portal: MySalesPortal, MySales, TeamSales.

Portal data archive created: /tmp/expportal7553974727669501601/MySalesPortal-2012-09-26-05:00:59.pdr
40.1.2.1.3 Understanding Connection Property Files

When you export portals to an archive using the WLST command exportWebCenterPortals, connection information used in the source portal environment to connect to portlet producers, web services, external servers, and applications is saved to a file named connection.properties. The connection.properties file is included inside the portal archive and a copy is also placed in same directory as the portal archive.

Connection information is included with the portal archive for backup purposes only, so you can easily see the connection configuration at the time the portal was backed up and if necessary, compare it with connection configuration at another point in time or perhaps on a restored WebCenter Portal instance.

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 Section 40.6.2, "Importing New WebCenter Portal Connections from a File."

Notes:

  • A connection.properties file is generated when you export a portal using the WLST command exportWebCenterPortals but this file is not included when you export portals from Portal Builder Administration.

  • A connection.properties file is also generated when you run the WLST command exportWebCenterPortalConnections. For details, see, Section 40.6.1, "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 40-3 shows examples where a different URL parameter is required on the target because the source and target do not use the same host.

Table 40-3 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 40-4 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 40-4 Using connection.properties to Create Connections on the Target

Description of Figure 40-4 follows
Description of "Figure 40-4 Using connection.properties to Create Connections on the Target"

Connection Types and Connection Properties

Table 40-4 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 Part V, "Managing Tools, Portlet Producers, and External Applications".

  • Oracle strongly recommends that you only edit properties in connection.properties that are marked Edit on Deployment?=Yes in Table 40-4. 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 40-4 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

  

Pagelet producers

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 Live Communications Server

url

poolName

adapter

timeout

appId

AdditionalProperty

defaultConnection

Yes

Yes

No

No

No

No

No

  

Presence server -

Microsoft Office Communications Server 2007 / 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

  

Oracle SES

url

appUser

defaultConnection

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

Oracle Portal

dataSource

extAppId

timeout

Yes

No

No

  

File System

path

Yes

  

Worklist connection

BPELConnection

No

  

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 Section 40.6, "Moving Connections Details from Staging to Production."

40.1.2.2 Deploying Portal Archives to a Different Server

First you deploy (or export) the portal to an archive (.par file) and then you import the archive on the target server. See also, Section 40.1.2.1, "Understanding Portal Archives."

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 Section 40.9, "Managing Portals in Production."

To export and then import a portal archive:

  1. Complete the portal archive prerequisites described in Section 40.1.2.3.1, "Portal Archiving Prerequisites."

  2. Export the source portal:

  3. (Optional) Migrate externally stored data and content to the target:

    For details, see Section 40.8.1, "Migrating Back-end Components for Individual Portals."

  4. Import the portal on the target:

40.1.2.3 Creating Portal Archives

Administrators can generate an archive (.par file) for any portal or portal hierarchy that is running on WebCenter Portal. You can use Portal Builder or the WLST command exportWebCenterPortals to create the archive and optionally include the portal's content folder.

To find out how to create portal archives, see:

40.1.2.3.1 Portal Archiving Prerequisites

Before exporting a portal to an archive (.par file), verify the following:

  • 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_Spaces',
 toLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

importMetadata(application='webcenter', server='WC_Spaces',
 fromLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')
40.1.2.3.2 Exporting Online Portals to an Archive Using Portal Builder Administration

WebCenter Portal administrators can export portals to an archive using Portal Builder administration as described here. You can save the portal archive to your 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. For details, see Section 40.2.1.1, "Exporting Portal Templates to an Archive Using WebCenter Portal."

To export one or more portals through Portal Builder administration:

  1. Click the Administration link.

  2. Click the Portals tab to display the Portals page.

    You can also enter the following URL in your browser to navigate directly to the Portals management page:

    http://host:port/webcenter/portal/builder/portals

    See Also:

    "WebCenter Portal Pretty URLs" appendix in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal

  3. Select the portal required by highlighting the row in the table.

    Ctrl-click rows to select more than one.

    Tip:

    to prevent data conflict during the export process, Oracle recommends that all the portals you select (including subportals) are offline during the export process, even if only temporarily. For details, see Section 46.11, "Taking Any Portal Offline."

    Members with the Portals-Manage All permission can still access a portal when it is offline, so ask them not make changes while you do the export.

  4. Click Export in the toolbar.

    The Export Portals pane opens (Figure 40-5). All the portals that you select are listed. If you chose a portal hierarchy, you must export the entire hierarchy; you cannot selectively remove child portals.

    If you want to exclude a portal, click the Delete icon next to the portal's name (a blue cross in Figure 40-5).

    Figure 40-5 Exporting Portals

    Description of Figure 40-5 follows
    Description of "Figure 40-5 Exporting Portals"

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

  6. Select Include Portal Folder on Content Server 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. See also, Section 40.1.2.1.1, "Understanding Portal Data Files (PDRs)."

    Notes:

    • Including content folders increases the size of the portal archive. If you are exporting a large number of portals or large content folders, take care that your archive does not exceed the maximum upload size for files (2 GB by default). If necessary, you can increase this setting, as described in Section 9.12, "Changing the Maximum File Upload Size."

    • 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_Spaces',
 toLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

importMetadata(application='webcenter', server='WC_Spaces',
 fromLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

  7. Click Export.

  8. Progress information is displayed during the export process (Figure 40-6).

    When the export process is complete, specify a location for the export archive (.par file).

    Figure 40-6 Portal Export In Progress

    Portal Export In Progess
    Description of "Figure 40-6 Portal Export In Progress"

    Select one of:

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

      When the Save to Server dialog displays (Figure 40-7), enter a suitable path in Archive Location, for example, /tmp, and then click Save. Ensure that the server directory you specify exists and you have write permissions.

      Figure 40-7 Saving Export Archives to a Server Location

      Description of Figure 40-7 follows
      Description of "Figure 40-7 Saving Export Archives to a Server Location"

  9. Click Close to dismiss the Export Portals pane.

The export archive (.par file) is saved to the specified location.

40.1.2.3.3 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, server, applicationVersion])

The options that you set depends on your specific archive requirements. For command syntax, see the "exportWebCenterPortals" section in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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)

40.1.2.4 Importing One or More 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 Portal Builder 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 Section 46.11, "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 an Oracle Secure Enterprise Search crawl to index the newly imported data.

Portal Security (Optional on Import)

All portals need a security policy to work properly so you must include the portal's security policy when you import a brand new portal for the first time. Existing portals have a security policy in place so, in this case, it's up to you whether to overwrite the security information on import or maintain the existing security policy.

Take particular care when importing security on a production instance as you will overwrite the existing security model.

If you choose to import security for an existing portal, the security policy updates do not apply immediately. Any user that is logged in to WebCenter Portal must log out and log back in to adopt the latest security policies for the portal.

Take care when importing and overwriting security on a production instance.

Note:

The users in both the source and target environments must be identical. If a shared identity store is not used, your system administrator must migrate users to the target. Refer to Section 41.6.1.2, "Back Up (Export) WebCenter Portal Schema Data" and Section 41.6.1.3, "Restore (Import) WebCenter Portal Data."

Portal Archive Data (Optional on Import)

If data migration is important, you can elect to import data associated with the source portal such as activity streams, events, feedback, lists, links, message boards, people connections, profiles, polls, and surveys.

In some cases this data is not required on the target, for example, when importing portals between a stage and production environments.

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

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 Section 40.8.1, "Migrating Back-end Components for Individual Portals."

To find out how to import portal archives, see:

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

  • Portals exist on the target - Check whether any portals in the archive exist on the target. If required, take existing portals offline during the import process.

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

  • Shared assets - If any of the portals reference shared assets, ensure that you move the required shared assets to the target before (or after) the portal is imported to ensure the portal works properly.

  • 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 Section 40.6, "Moving Connections Details from Staging to Production."

  • Archive version - Verify that the portal archive or portal template archive that you want to import was exported from WebCenter Portal 11.1.1.8.0 or later. Archives from these releases have the .par file extension.

    While you can import archives from earlier versions (with the .ear file extension), any portal or portal template that you import this way will not fully function on an upgraded WebCenter Portal 11.1.1.8.x. instance. Oracle recommends that you upgrade your source environment to 11.1.1.8.x and then create export archives (.par files). For details, see the "Patching Oracle WebCenter Portal" chapter in Oracle Fusion Middleware Patching Guide.

40.1.2.4.2 Importing a Portal from an Archive Using Portal Builder Administration

WebCenter Portal administrators can import one more portals and portal hierarchies from a portal archive through Portal Builder administration.

To import one or more portals from a .par file:

  1. Click the Administration link.

  2. Click the Portals tab to display the Portals page.

    You can also enter the following URL in your browser to navigate directly to the Portals management page:

    http://host:port/webcenter/portal/builder/portals

    See Also:

    "WebCenter Portal Pretty URLs" appendix in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal

  3. Click Import in the toolbar.

    Tip:

    To import one or more portals as a subportal of an existing portal, select the target portal before clicking the Import button.

    The Import Portals dialog opens (Figure 40-8).

    Figure 40-8 Importing Portals

    Description of Figure 40-8 follows
    Description of "Figure 40-8 Importing Portals"

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

  5. Click Browse Archive to review the content available for import (Figure 40-9).

    Figure 40-9 Importing Portals

    Importing Portals
    Description of "Figure 40-9 Importing Portals"

    The names of all the portals in the specified archive display in the table. The Type column indicates when there is a conflict between the portals in the archive and those which 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.

  6. Set import options as required. For details, see Table 40-5:

    Table 40-5 Portal Import Options

    Field Description

    Include Customizations

    Select to import portal customizations.

    For information about which customizations are optional on import, refer to Table 40-1, "Portal Deployment Options" and Table 40-2, "Information Exported to Portal Archives (PDR Files)".

    Import does not completely overwrite existing portal customizations on the target (if any). Only customizations included in the portal archive are overwritten on import leaving any other customizations on the target unchanged.

    If you deselect this option:

    • New portals are imported without customizations, for example, default task flows are imported without any customizations, default portal settings are used, and all user customizations are excluded.

    • If you are importing a portal that already exists on the target, existing customizations on the target are preserved.

    Note: Portlet and page customizations are always imported.

    Include Portal Folder on Content Server

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

    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 Section 40.1.2.4.3, "Importing a Portal from an Archive Using WLST." If necessary, you can increase the upload setting, see Section 9.12, "Changing the Maximum File Upload Size."

    Include Security Policy

    Select to import security information with the. portal.

    When selected, the following security related information is imported:

    • Portal roles (and permissions assigned to each role).

    • Portal members (and member role assignments).

    Deselect this option if you do not want to import portal security information. This option is useful when importing portals between a stage and production environments, where:

    • Members used during testing are not required in the production environment.

    • The portal exists on the production instance and you do not want to overwrite the security information.

    Note: When importing a brand new portal, always select (check) this option as you cannot import a new portal without a security policy.

    Include Services Data

    Select to import portal-related data stored in the WebCenter Portal database for activity streams, events, feedback, lists, links, message boards, people connections, profiles, polls, and surveys.

    Deselect this option if you do not want to import any portal-related data. When you choose this option, data on the target (if any) is preserved. For example, when moving a portal from a test environment to a stage or production environment where test data is not required.

    Note: The import process does not move externally stored data such as mail, discussions, announcements, and so on.

  7. Click Import.

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

      To delete existing portals and replace them with imported versions, answer Yes. Answer 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 Section 40.1.2.4.3, "Importing a Portal from an Archive Using WLST." If necessary, you can increase the upload setting. For details, see Section 9.12, "Changing the Maximum File Upload Size."

    Notes:

    • 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_Spaces',
 toLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

importMetadata(application='webcenter', server='WC_Spaces',
 fromLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

    An information message displays.

  8. Click Yes to confirm that you want to import the portals.

    An information message displays when all portals import successfully (Figure 40-10).

    Figure 40-10 Portal Import Successful

    Description of Figure 40-10 follows
    Description of "Figure 40-10 Portal Import Successful"

  9. Click Close to dismiss the Import Portals window.

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 Section 46.12, "Bringing Any Portal Back Online."

40.1.2.4.3 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])

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, customizations, security information, or data. 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 depends on your specific requirements. For command syntax, see the "importWebCenterPortals" section in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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, data, security, and customizations, 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', importCustomizations=0, importPortalContent=0,
 importSecurity=0,importData=0, importActivities=0, overwrite=1, savePortals=1)

40.1.2.5 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 the "listWebCenterPortalArchive" section in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

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

40.1.3 Deploying Portal Hierarchies

In WebCenter Portal, a portal hierarchy comprises a parent portal with one or more subportals (as shown in Figure 40-11). The deployment process for portal hierarchies is the same as for a single portal but there are a few guidelines and restrictions due to the dependency between portals in a hierarchy. For details see:

Guidelines for Exporting Portal Hierarchies

When you export a portal hierarchy, for deployment to another server or for backup purposes, only specify that you want to export the parent portal and the whole hierarchy is exported to a single portal data file (PDR) named (<parentportalname>-<datetimestamp>.pdr).

Important:

Due to various dependencies between portals in a hierarchy, Oracle recommends that you always export and import the complete portal hierarchy.

For example, to export portals in the hierarchies shown in Figure 40-11, specify the following:

exportWebCenterPortals(appName='webcenter', fileName='myPortalHierarchies.par',
 names='Sales,MyProject')

While "Tasks" is a parent portal for "Task X" and "Task Y", it is not the highest portal in the hierarchy. If you try to export only the "Tasks" hierarchy, information inherited from "My Project" will be missing from the export archive.

Figure 40-11 Deploying Portal Hierarchies

Description of Figure 40-11 follows
Description of "Figure 40-11 Deploying Portal Hierarchies"

Guidelines for Importing Portal Hierarchies

  • Selective import or restoration of child portals in an archive is not allowed. Always export the whole hierarchy and import the whole hierarchy on the target.

  • Do not change the parent when you import a hierarchical portal on the target.

For example, to import all portals in the hierarchies shown in Figure 40-11, specify:

importWebCenterPortals(appName='webcenter', fileName='myPortalHierarchies.par',
 names='Sales,MyProject', forceOffline=1)

40.2 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, discussions, lists, and security information such as custom roles and member details. When you export a portal template all this information is packaged in a portal data file (PDR). The PDR file contains a metadata archive (MAR file) and a single XML file containing security policy information for the template.

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 Portal Builder administration to export portal templates, the content stored in this folder is automatically included in the portal template archive (.pdr) for easy deployment to another target server. The folder is added to a .zip file located at: transport.mar\oracle\webcenter\lifecycle\importexport\data\oracle-webcenter-doclib\docsexport.zip.

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:

40.2.1 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 Portal Builder administration to export portal templates to an archive.

This section includes the following topics:

40.2.1.1 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 more information, see the "Exporting Portal Templates" section in Oracle Fusion Middleware 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 details see Section 40.1.2.3.2, "Exporting Online Portals to an Archive Using Portal Builder Administration."

40.2.1.2 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, server, applicationVersion])

The options that you set depends on your specific archive requirements. For command syntax, see the "exportWebCenterPortalTemplates" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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')

40.2.2 Importing Portal Templates

Administrators can use the WLST command importWebCenterPortals to deploy one or more portal templates on another WebCenter Portal Server. Alternatively, administrators and application specialists can use Portal Builder 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 the "Publishing or Hiding Portal Templates" section in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal.

This section includes the following topics:

40.2.2.1 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 the "Importing Portal Templates" in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal.

40.2.2.2 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, [importPortalContent], [overwrite], [savePortals], [importLog])

The options that you set depends on your specific archive requirements. For command syntax, see the "importWebCenterPortals" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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')

40.3 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 Portal Builder and administrators can perform the same tasks using WLST commands:

  • Page templates

  • Navigations

  • Resource catalogs

  • Skins

  • Page styles

  • Content presenter display templates

  • Task flow styles

  • Task flows

  • Data controls

Note:

While you cannot upload or download individual pagelets, all assets (including pagelets) are included when you migrate individual portals or an entire WebCenter Portal instance.

When you download (or export) a WebCenter Portal asset, the asset details are saved to an export archive (.ear file). You can save the export archive to your local file system or a remote server file system using a filename of your choice.

External Asset Dependencies

No artifacts used or referenced by assets, such as icons, images, and data controls, are included in the archive. When you upload an asset to another WebCenter Portal instance you are must manage and move dependent asset artifacts manually. Oracle recommends that you use a folder structure on your content server specifically for asset artifacts so that content is easy to identify and move, if required.

Note:

If you are managing legacy assets that store artifacts in MDS, Oracle recommends that you relocate dependent artifacts to your content server. However, if you do need to move artifacts stored in MDS, you can use the MDS WLST commands exportMetadata/importMetadata. For example:

exportMetadata(application='webcenter', server='WC_Spaces',
 toLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

importMetadata(application='webcenter', server='WC_Spaces',
 fromLocation='/tmp/content',
 docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

This section includes the following topics:

40.3.1 Exporting Assets to an Archive

This section describes the various ways you can create an asset archive. It includes the following topics:

See also, Section 40.3.2.1, "About Permissions Required to Import (or Export) Assets."

40.3.1.1 Exporting Assets to an Archive from Portal Builder

Administrators, application specialists, and portal moderators can export assets from Portal Builder. For details, see the "Downloading an Asset" section in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal.

40.3.1.2 Exporting Assets to an Archive using WLST

Administrators can use the WLST command exportWebCenterResource to export a single asset from WebCenter Portal:

exportWebCenterResource(appName, fileName, resourceType, [resourceGUID,
 resourceName, spaceName, exportContentDirectory,server, applicationVersion])

The options that you set depends on the asset you want to export. For command syntax, see the "exportWebCenterResource" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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.ear:

exportWebCenterResource(appName='webcenter',
 fileName='mySalesPageTemplateExport.ear', 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.ear:

exportWebCenterResource(appName='webcenter', fileName='mySharedSkinExport.ear',
 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.ear',
 resourceType='skin', resourceName='MyCompanySkin)

40.3.1.3 Exporting Assets to an Archive from JDeveloper

Developers can export assets that they create or extend in JDeveloper to an archive (.ear file) for others to deploy. For more information, see the "Exporting WebCenter Portal Assets to an Archive" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

40.3.2 Importing Assets from an Archive

You can only import an asset previously saved to a WebCenter Portal export archive (.ear file). For details, see Section 40.3.1, "Exporting Assets 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:

40.3.2.1 About Permissions Required to Import (or Export) Assets

Table 40-6 describes the roles/permission required to import (or export) assets using the Portal Builder administration.

Note:

If you want to import (or export) assets using WLST, you must also have the WebLogic Server Monitor role (or higher).

Table 40-6 Permissions Required to Import (or Export) Assets Using Portal Builder

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 Portal Builder administration pages.
     

Portal asset

  • Moderator
 

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.

40.3.2.2 Importing Assets from an Archive using Portal Builder

Administrators, application specialists, and portal moderators can import assets from Portal Builder. For details, see the "Uploading an Asset" section in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal

40.3.2.3 Importing Assets from an Archive using WLST

Administrators can use the WLST command importWebCenterResource to deploy a single asset to WebCenter Portal.

importWebCenterResource(appName, fileName, [resourceType, spaceName,
 overwriteContentDirectory, server, applicationVersion])

The options that you set depends on the asset you want to deploy. For command syntax, see the "importWebCenterResource" section in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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.ear in to the Sales portal:

importWebCenterResource(appName='webcenter',
 fileName='mySalesPageTemplateExport.ear', resourceType='pageTemplate',
 spaceName='SalesPortal')

Example 2 - Deploying a shared portal skin

The following example imports a shared portal skin archived in mySharedSkinExport.ear:

importWebCenterResource(appName='webcenter', fileName='mySharedSkinExport.ear',
 resourceType='skin')

40.4 Deploying Devices and Device Groups

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

40.4.1 Exporting Devices and Device Groups to an Archive

This section includes the following topics:

40.4.1.1 Exporting Devices and Device Groups Using Portal Builder

Administrators can export one or more devices and device groups to a file (.ear file) from Portal Builder Administration. For details, see Section 53.4, "Managing Device and Device Group Life Cycles."

40.4.1.2 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 a file (.ear file):

exportWebCenterResource(appName, fileName, resourceType, [resourceName, server,
 applicationVersion])

For command syntax, see the "exportWebCenterResource" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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.ear',
 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.ear',
 resourceType='device', resourceName='MyMobileDevice)

40.4.2 Importing Devices and Device Groups from an Archive

This section includes the following topics:

40.4.2.1 Importing Devices and Device Groups Using Portal Builder

Administrators can import one or more devices and device groups from a file (.ear file) using Portal Builder Administration. For details, see Section 53.4, "Managing Device and Device Group Life Cycles."

40.4.2.2 Importing Devices and Device Groups Using WLST

Administrators can use the WLST command importWebCenterResource to deploy one or more devices or device groups to WebCenter Portal from a file (.ear file).

importWebCenterResource(appName, fileName, [resourceType, server,
 applicationVersion])

For command syntax, see the "importWebCenterResource" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

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

Here are a few examples:

Example 1 - Deploying a device group

The following example imports a device group exported to myDeviceGroupExport.ear:

importWebCenterResource(appName='webcenter', fileName='myDeviceGroupExport.ear',
 resourceType='deviceGroup')

Example 2 - Deploying a device

The following example imports a device archived in myDeviceExport.ear:

importWebCenterResource(appName='webcenter', fileName='myDeviceExport.ear',
 resourceType='device')

40.5 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 Components for WebCenter Portal Using JDeveloper" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

40.6 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 Section 40.1.2.1.3, "Understanding Connection Property Files."

This section includes the following topics:

40.6.1 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 the "exportWebCenterPortalConnections" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "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')

40.6.2 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 WLST command exportWebCenterPortalConnections. To find out how, see Section 40.6.1, "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 Section 40.1.2.1.3, "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 the "importWebCenterPortalConnections" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

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

40.7 Moving Portals from Staging to Production

If you are using a staging environment to develop and test your portals before moving them to your production server, Oracle recommends that you always make changes in stage first and move changes to production to keep both environments in sync. The steps for moving the portals are exactly the same as those described in, Section 40.9, "Managing Portals in Production."

40.8 Moving External Portal Data from Staging to Production

This section includes the following:

40.8.1 Migrating Back-end Components for Individual Portals

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.

Discussions:

Content:

Pagelets:

After importing one or more portals, consider initiating an Oracle Secure Enterprise Search crawl to index the newly imported data.

40.8.1.1 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 Chapter 47, "Exploring the Administration Page in Portal Builder 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 40-12):

    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 40-12 Exporting Discussions for an Individual Portal

    Description of Figure 40-12 follows
    Description of "Figure 40-12 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 Section 40.1.2.4.2, "Importing a Portal from an Archive Using Portal Builder Administration."

40.8.1.2 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 Section 40.1.2.2, "Deploying Portal Archives to a Different Server" or Section 40.9.2, "Directly Deploying Portals From Staging to Production."

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 Chapter 47, "Exploring the Administration Page in Portal Builder 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 40-13).

    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, Section 40.8.1.1, "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 40-13 Importing Discussions for a Portal

    Description of Figure 40-13 follows
    Description of "Figure 40-13 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 40-14).

    Figure 40-14 Editing Forum Permissions

    Editing Forum Permissions
    Description of "Figure 40-14 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 Chapter 47, "Exploring the Administration Page in Portal Builder 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.

40.8.1.3 Exporting Content for a Portal

Oracle recommends that documents and content associated with your portal are placed in the portal folder. When you export a portal to an archive, there is an option to include this portal folder in the portal archive (see Section 40.1.2.3, "Creating Portal Archives") and there is a similar option when you deploy a portal directly to another portal server (see Section 40.9.2, "Directly Deploying Portals From Staging to Production").

Note:

If you choose not to migrate the portal folder with the portal you can manually move the portal folder to the target using WebCenter Content Server migration tools. For details, see the "System Migration and Archiving" section in Oracle Fusion Middleware Administering Oracle WebCenter Content.

In addition to the portal folder, your portal may reference content in other locations, for example:

  • Other folders on Content Server

  • External content repositories or web locations

You cannot export content in any other folder or location along with the portal so you must ensure the target system can access the same content as the source. See also, Section 40.8.1.4, "Importing Content for a Portal."

In all cases, documents and content remain in the source content repository so if required, you can migrate any content that you require after migrating the portal to the target.

40.8.1.4 Importing Content for a Portal

When you import a portal from Portal Builder Administration, you can select "Include Portal Folder on Content Server" in the import dialog if you want to import documents with the portal. If you are using the importWebCenterPortals WLST command to do the import, set importPortalContent=1.

Note:

Portal archives do not always contain the portal folder. To include the portal folder you must select the "Include Portal Folder on Content Server" option on export as well. For details, see Section 40.1.2.3, "Creating Portal Archives."

Content Not Stored in the Portal Folder

Portal archives never include content that is stored outside the 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 folder, you must either:

  • Manually move such content to the target.

  • Ensure that the target can access the same content as the source.

Note:

When you move a portal to a different target, Content Presenter data references are only maintained if Content Server connection names and root folder names are the same in both the source and the target.

For information about Oracle WebCenter Content Server migration tools, see the "System Migration and Archiving" section in Oracle Fusion Middleware Administering Oracle WebCenter Content. For other content repositories, refer to the manufacturer's product documentation.

40.8.2 Migrating Back-end Components for an Entire Portal Server

Before you move/migrate an entire portal server, you must migrate all the back-end components that are used by the application, see Section 41.5, "Migrating Entire WebCenter Portal to Another Target."

40.9 Managing Portals in Production

This section includes the following topics:

40.9.1 Understanding Portal Propagation

Administrators can propagate metadata changes in staging to production providing that your stage and production environments are connected and kept "in sync". Oracle strongly recommends that you always make changes in stage first and then push your metadata changes to production using deployment or propagation.

The propagation feature is useful for migrating changes to portal metadata (pages, assets, portlets dropped on to pages, and so on). Propagation does not require the production server to be restarted or incur any downtime because propagation only transfers changes to portal metadata. For details, see Table 40-7.

Table 40-7 Portal Changes Propagated to Production

Portal Changes Propagated Yes / No

Portal-level customizations (metadata)

  

Portal pages and system pages

Yes

Portlets

Yes

Assets

Yes

Task flows

Yes
   

User-level customizations (metadata)

  

Portal pages

Yes

Portlets

No

Task flow instances

Yes
   

Portal folder content

No

Subportals

No

Portal activity/usage data

(activity streams, calendar events, feedback, list, links, message boards, people connections, profiles, polls, surveys)

No

Portal security data

(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

Labeling During Propagation

For propagation to work, you must move deploy the portal to production using the WLST command deployWebCenterPortal—this command re-creates the entire stage portal on the production instance and creates a matching label on the stage portal and the production portal, for example LABEL_1. Subsequently, whenever you propagate changes from stage to production using the WLST command propagateWebCenterPortal command, the portal's label increments by 1 in both the stage and production environment, as summarized in this table:

Portal Change in Stage Action WLST Command Label

First time only

Deploy the stage portal to production

deployWebCenterPortal

LABEL_1

Subsequent change

Propagate metadata changes in the stage portal to production

propagateWebCenterPortal

LABEL_2

Subsequent change

Propagate more metadata changes

"

LABEL_3

Subsequent change...

"

"

LABLE_n+1

See also, Appendix E, "Labeling During WebCenter Portal Lifecycle."

40.9.2 Directly Deploying Portals From Staging to Production

Administrators can use the WLST command deployWebCenterPortal to deploy a single, online portal directly to another target server. If the portal you specify has one or more subportals, the dependent portals are deployed too. You must use this method to deploy your portal if you want to propagate portal metadata changes in the source, such as page or asset updates, to the target.

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

    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 Section 40.1.2.3, "Creating Portal Archives."

  2. Verify that you have at least the WebLogic Server Monitor role and the WebCenter Portal permission Portals - Manage All.

  3. Ensure a connection exists between the source and target WebCenter Portal.

    If a connection does not exist yet, use the WLST command adf_createHttpURLConnection to create a connection to the target from the source environment.

    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,Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

  4. (Optional) Move externally stored portal data to the target environment.

    For details, see Section 40.8.1, "Migrating Back-end Components for Individual Portals."

  5. (Optional) Ensure that all the connections used by the portal (and portal components) are configured on target.

    The deployWebCenterPortal command does not, for example, carry connections configured for web service data controls. Connections that do not exist on the target must be migrated separately. For details, see Section 40.6, "Moving Connections Details from Staging to Production."

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.

    For details, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

  2. Run the WLST command deployWebCenterPortal to deploy the portal on the target server.

    deployWebCenterPortal(appName, portalName, targetConnectionName
 [deployCustomizations, deployContent, deploySecurity, deployData,
 deployActivities, overwrite, savePortal, deployLog, server,
 applicationVersion])

    For detailed command syntax and descriptions, see the "deployWebCenterPortal" section in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

    The options that you set depends on your specific deployment requirements. Here are two common examples:

    Example 1 - Deploying a portal on the target for the first time

    This example deploys a new portal named myPortal, plus all its associated content, data, security, and customizations, and also specifies a name and location for the deploy log file:

    deployWebCenterPortal(appName='webcenter',portalName='myPortal',
targetConnectionName='MyWebCenterPortalTarget',deployCustomizations=1,
deployPortalContent=1,deploySecurity=1,deployData=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.

    Example 2 - Redeploying a portal that exists on the target

    This example backs up a portal named myExistingPortal on the target and then overwrites the target portal (overwrite=1) with the source portal. The content, data, security, and customizations associated with the target portal is preserved:

    deployWebCenterPortal(appName='webcenter',portalName='myExistingPortal',
targetConnectionName='MyWebCenterPortalTarget',deployCustomizations=0,
deployPortalContent=0,deploySecurity=0,deployData=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.

40.9.3 Propagating Portal Changes in Staging to Production

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 Section 40.9.2, "Directly Deploying Portals From Staging to Production."

To propagate metadata changes from staging to production:

  1. Run the WLST command adf_createHttpURLConnection to create a connection to the production server:

    adf_createHttpURLConnection(appName, name, url, user, password, realm)

  2. Run the WLST command propagateWebCenterPortal to propagate metadata for the portal.

    propagateWebCenterPortal(appName, portalName, targetConnectionName,
 [savePortal, propagateLog, server, applicationVersion])

    The options that you set depends on your specific requirements. For command syntax, see the "propagateWebCenterPortal" section in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

    For information on how to run WLST commands, see Section 1.13.3.1, "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 metadata 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 metadata changes for a portal named myPortal, 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')

40.10 Restrictions

Portal deployment and portal propagation operations are only supported across two WebLogic Server instances or two IBM WebSphere instance. You cannot deploy or propagate portals from IBM WebSphere to Oracle WebLogic Server or vice versa.