See Understanding Scope for more information. Manual changes are reported to you in the following places:. Table provides a comprehensive list of the categories and types of data that comprise a portal and whether or not the propagation tools move them.
Any type of data that is not propagated by the propagation tools is noted in the Notes column. Data that is not propagated might require a manual change to be made on the destination server. For more information on manual changes, see Make Required Manual Changes. Note: Definitions that you create using public entitlement APIs are not propagated. Note: Definitions that you create using your own custom code APIs are not propagated. Note: Only the roles that are required that a given asset depends upon are propagated.
Note: Roles that you create using your own custom code APIs are not propagated. Note: Users and groups are not propagated, but user and group identification is preserved; you must manually create users and groups that correspond with propagated roles. Note: Workflows are not propagated. Security information consists generally of authentication data and authorization data. As Table shows, authorization data consists of roles and policies, while authentication consists of users and groups.
Users and groups are never propagated by the propagation tools. In addition to user and group information, the propagation tools do not propagate the following:. Because roles contain user and group information, you need to consider how user and group information is stored for your staging and production system; these two systems may or may not share the same authentication repositories. If your systems do not share the same authentication repositories for managing users and groups, then after propagating a portal, you must manually edit each role to add the appropriate users and groups on the destination system.
If the systems do share the same authentication repositories, then no manual changes to roles need to be made after a propagation. For more information on manual propagation changes, see Make Required Manual Changes. You can think of a WebLogic Portal inventory as a large tree structure, with multiple levels of parent and child nodes.
Each node in the tree represents the inventory for a part of the portal application. If a node is declared to be in scope, then that node and all of its descendents are in scope. That is, they will be included in the exported inventory file. If you do not want to propagate an entire portal application, you can use scoping to limit the propagated assets. The most common use cases for scoping include:. The Workshop for WebLogic based propagation tools and the propagation Ant tasks both support scoping.
The Workshop for WebLogic propagation tools let you manually make scoping decisions by selecting and unselecting nodes in the merged inventory tree. The Ant tasks let you control scoping with a scope.
Performance is the primary use case for scoping. Because a scoped inventory reduces the overall size of an exported WebLogic Portal inventory, propagation tasks typically run faster. If you have a large content repository, you might not want to export it when you propagate a portal. In this case, you can move the content repository, and all of its content, out of scope. Another reason to scope is security-related. You may want to exclude certain sensitive content from an inventory if you plan to transport that inventory through insecure channels.
The primary risk associated with scoping is that a scoped inventory file can include assets with dependencies that cannot be resolved. When an inventory is scoped, entire nodes and descendants of the nodes are excluded from the inventory. As a result, if included artifacts depend on excluded artifacts, those dependencies cannot be resolved.
Typically out of scope dependencies are reported as manual elections. By default the propagation servlet will fail on manual add elections.
The following are best practices if you intend to consider scoping an inventory:. You can set the scope of a propagation in the Workshop for WebLogic based propagation tools and in the Ant tasks. This section explains how to set scope using the New Propagation Session Wizard. When you create a new Propagation Session, you select a source and a destination inventory to merge. Before the merge, however, you are given the chance to make scoping decisions in the Select Global Scope dialog, shown in Figure To make selections in the Select Global Scope dialog, you must first select the Limit the scope to the specified nodes checkbox.
You can use the OnlineDownloadTask to scope an inventory file. This task takes a scope. You can edit this file to include the items you want to include in the inventory file. If you do not specify a scope. WebLogic Portal gives you a great deal of freedom to scope your portal inventories. When you select an inventory node to be in or out of scope, that choice usually affects other nodes that are either dependent on or a dependent of the selected node. WebLogic Portal automatically determines these dependencies.
In Workshop for WebLogic, you can see the dependencies visually: when you select a node, other related nodes are automatically selected. This section helps you to understand the effects of four kinds of scoping decisions:. By default, all propagations are scoped to the Enterprise application level. This means that all of the artifacts that make up the portal that can be propagated are propagated. By default, the entire Enterprise application is in scope , as Figure illustrates.
There are no preset scoping levels. Both the propagation tools and Ant tasks let you specify scoping however you want. The Ant tasks let you specify a scope.
See also Understanding a Scope Property File. There are four major categories of portal artifacts that you can scope to:. Using this dialog, you can drill into one of the top-level categories to refine the level of scoping. However, as previously noted, the best practice is to scope only to one of the top-level categories, such as the Content Service. One of the most common scoping use cases is scoping to the desktop level. This means that you identify one or more specific desktops to be in scope.
The rest of the enterprise application is then considered to be out of scope and is not propagated. Any other desktops and the rest of the Enterprise application are then out of scope. See What are the Risks of Scoping? Another common use case it scoping to a repository. When you scope to a repository, the entire repository is propagated, including all types, folders, and content, as illustrated in Figure Any other repositories are not propagated, and no other part of the Enterprise application is propagated.
Note that the contents of parent folders are not propagated, only the parent folders themselves, as illustrated in Figure When you propagate portal assets, such as desktops containing pages and books, new pages and books are added to the Portal Library if they do not already exist there.
The WebLogic Portal Administration Console organizes portal resources in a tree that consists of Library resources and desktop resources. Understanding the relationship between Library and desktop resources helps you to understand the effects and consequences of propagation. The following text describes the relationships between the following instances of portal assets:.
When you create a new desktop using the WebLogic Portal Administration Console, you can use an existing portal template. Using a template means that you will be taking the portal resources for your desktop directly from a. When you create a desktop, the portal assets are removed from the. Taking the assets from a new desktop instance and placing them in the Library is called disassembling.
At this point, the assets books, pages, and so on in the Library Library instances are hierarchically related to their corresponding desktop instances. A change to a Library resource, such as a name change, is automatically inherited by the corresponding desktop instance. On the other hand, a change to the desktop instance is not reflected back up the hierarchy. New books and pages that you create in a desktop are not disassembled—they are considered to be private to that desktop.
If an administrator or a visitor using Visitor Tools changes the Book Properties of a book or the Page Properties of a page in a desktop, those property settings become decoupled from the settings in the parent book or page in the Library.
Page properties include layout and theme, while Book Properties include menus and layout. When a portal is propagated, any assets that are decoupled in the source application will remain decoupled in the destination. For more details on the specific data propagated, see Propagation Reference Table.
Policies let you control how source and destination inventories are merged into a final inventory file. This section describes policies and presents examples to help you understand how to apply them. Policies let you specify how to handle the following three merge cases:. Through the propagation tools, you can set two kinds of policies:.
Figure illustrates a simple, but common, example. In this case, the default global policies define how two inventories are merged. Portlet 5 from Desktop B is also added. However, Portlet 6 on the destination is deleted, because it did not exist in Desktop B on source system. Figure shows the same source and destination system; however, in this case the global policy specifies that adds are ignored.
In this case, Portlet 6 is removed from the destination desktop because it did not exist in the source desktop. None of the additional portlets from the source are added, because the global policy specifies that adds are to be ignored. Figure shows how a local policy overrides a global policy. Merge source and destination inventories. Set scopes and policies on merged inventories. Upload a portal inventory to a destination system. Commit a final inventory on the destination system.
Use the import feature to download portal inventory files from the source and destination systems. Use the Propagation Session wizard to create a propagation project, import source and destination inventory files, and create a merged inventory file. Use the Propagation Perspective to view and tune the merged inventory file.
This perspective provides a graphical view of your merged inventory, highlighting additions, deletions, and updates, and allowing you to make changes before generating the final merged inventory. Create a final merged inventory file. Upload and commit the final merged inventory file to the destination server. Figure Example Propagation Perspective. Figure Import — Select Dialog. Start Workshop for WebLogic. In the New Project dialog, enter a name for the project and click Finish.
The project appears in the Package Explorer, as shown in Figure Figure New Simple Project Folder. In the New Propagation Session dialog, select a parent folder, and enter a name for the session.
The parent folder can be any project folder, such as the Simple Project folder you created previously. Click Next. The New Propagation Session — Choose source inventory files dialog appears.
In the The New Propagation Session — Choose source inventory files dialog, select the link Click to import files , as shown in Figure The Import — Select dialog appears.
Figure Import — File System Dialog. Global policies Global scope Local policy overrides. In the Choose Source Inventory File dialog, select the source inventory file, as shown in Figure , and click Next. Figure Choose Source Inventory Dialog. In the Choose Source Inventory File dialog, select the destination inventory file, as shown in Figure Figure Destination Inventory File Selected.
The artifact exists in the source, but not the destination. It will be added to the destination. The artifact exists in the destination, but not the source. It will be deleted from the destination. The artifact exists in the source and destination. It has changed in the source and it will be updated in the destination. Indicates that the change is impossible to make, possibly because of a conflicting dependency.
In addition, a message is displayed in the Problems view. Indicates a manual change is required. The Export — Select dialog appears. Are you deploying your application for the first time, or are you redeploying it? For details, see General Propagation Scenarios. If you are redeploying an existing application, what kinds of changes were made to it, and how were they made? Did developers use Workshop for WebLogic to modify, create, or remove portal resources such as adding a new book and pages to a portal, and adding portlets to the pages?
Was your application modified in a staging environment by administrators using the Administration Console? What is the scope of your propagation? Do you wish to propagate the entire Enterprise application, a single web application, or a desktop? For details on scope, see Understanding Scope. Do you want to push a portal from a staging or production environment back to a Workshop for WebLogic environment?
Do you want to push a portal from a production environment back to a staging environment? This can be accomplished with the propagation tools or the propagation Ant tasks. Have you defined entitlements for portal assets, such as portlets? If so, you need to be aware that users and groups are, by design never propagated by the propagation tools, and you may need to manually recreate specific user and group definitions on the production server.
For information on how security elements are handled during propagation, see Security Information and Propagation. Any changes made to the EAR file, including datasync data, are automatically detected and deployed to the target server. New portlets are automatically detected and moved into the Library of the Administration Console. New books and pages added to a portal are not automatically added to the Library.
They are added only if you use the Administration Console to create a new Desktop that uses the new books and pages. This includes. Datasync data is ignored if the EAR is redeployed to a server in production mode.
In this case, you must propagate the datasync data using one of the propagation tools. See the following section, Moving the Datasync Data , for information on moving the datasync data. New Books and Pages added to a portal are not automatically added to the Library.
Not recommended because application files are not editable Datasync data is read from the filesystem read-only Not recommended for cluster deployment. Generally, EAR files are preferred for production mode. Thereafter, datasync data is always in the database. Datasync data is stored in the database. You must propagate datasync assets to the target database as a separate operation, as explained in this section.
Deploy the EAR file. Use the propagation tools to propagate the database assets from the staging server to the production server. Figure Definition Label in the Properties View. The following delegated administration policies: portal resources Library and Desktop level content management user group management content selectors campaigns visitor roles placeholders segments security providers. If you make a change to EAR data in Workshop for WebLogic for instance, modifying a theme , the only way to move those changes to another environment is to redeploy the EAR file.
For instance, an administrator can assign a specific theme to a page using the WebLogic Portal Administration Console, and a reference to the actual theme file is maintained in the database. When you propagate a desktop to another environment using the propagation tools, those references are propagated, but the actual file the reference points to for example, a.
EAR deployment and the propagation tools are described in the following sections. Propagation tools. Propagation tools Note: The same EAR file that was deployed to the staging system must also be deployed at least once to the production system.
Whenever the Administration Console is used, the output is stored in a database, not in a file. Therefore, if you are in development and use the Administration Console to create desktops, users, groups, entitlements, or other administrative features, that information is stored in a database.
Assets in the database are not included in the EAR file, and will not be transferred when you move and deploy the EAR. If you use the Administration Console in a development environment, then you must use the propagation tools to move the database assets to the staging environment. To move portal assets to a production environment database to database , the best practice is to use the Workshop for WebLogic propagation tools or Ant tasks. At this point, you can view the differences between the source and destination inventories the merged view and decide whether or not to go ahead with the propagation.
Differences can include portal assets that have been added, deleted, or updated. For example, if a page was added to a desktop in staging the propagation tools will report that a page was added if it does not exist in the production environment. Similarly, if a page was deleted from the production environment, the propagation tools will report that it was deleted and give you the option of adding it back or not if it still exists on the staging server. At this point, all subsequent modifications to the portal made using the WLP Administration Console occur in the database only.
Changes are not reflected back into the EAR file. Mode of Target Server. Deploy an Exploded EAR. Deploy an EAR File. Development Mode. Production Mode. On Redeployment Datasync data is stored in the database. For detailed information on scoping an inventory, see Scoping an Inventory.
Typically, the two environments will be out of sync. You can save the Ant script that is used by Workshop for WebLogic. By saving the script, you can examine it and begin to understand how it works. For information on saving propagation Ant scripts, refer to Workshop for WebLogic online help. The URL specified for these commands indicate how the servlet is addressed. For WebLogic Portal applications deployed in a cluster, a proxy server or load balancer sits in front of the cluster to marshal traffic to the cluster nodes.
While it is possible to target a propagation to the proxy, a better approach is to identify a single cluster managed node and to address it directly. This approach has these advantages:. Portal desktops, portlet preferences, content, and most other artifacts are persisted into the database.
However, some security information such as entitlements and delegated administration policies are persisted into the embedded LDAP server intrinsic to every WebLogic Server instance. In a cluster, the Administration Server is responsible for distributing updates to the embedded LDAP server to all nodes in the cluster.
If the Administration Server is down, the nodes in the cluster can get out of sync if updates are made to entitlements or delegated administration. Therefore, it is strongly recommended to have the Administration Server running when the Propagation Tool is updating an application. Unlike any other activity in a WebLogic Portal application, the propagation tools iterate through the configuration of the entire WebLogic Portal application.
Therefore, if there is a latent problem in the application configuration, the propagation tools are apt to encounter it. While these problems adversely affect the propagation, the true source of the error is usually at a deeper level. To troubleshoot such a problem, attempt test the area in question using another means such as the WebLogic Portal Administration Console. This process can help you to discover and fix the actual problem or provide a simpler, reproducible test case.
Some cases have arisen where an unsupported database driver or corrupt security repository have negatively impacted the propagation tools.
While these problems affect the propagation, the solution lies in addressing the root cause. Note that during an Export Propagation Inventory to Server operation Workshop for WebLogic or OnlineCommit Ant operation, the propagation tools processes a list of changes to make on the destination system. At times, this list can be enormous, with thousands of necessary changes.
This operation can take a significant amount of time. The propagation tools do not create an encompassing transaction for all changes for several reasons:. During propagation, each change to the destination system is executed in its own transaction. If the propagation operation is interrupted in the middle, the configuration will be left in an incomplete state.
For example, this situation can occur if the managed server hardware fails during the operation. In such a case, you can simply rerun the propagation tools. The tools will detect the new, shorter, list of remaining changes that need to be applied and will start again where the previous propagation failed. These operations read and write large amounts of database records while working with the WebLogic Portal application configuration.
These operations are notable in that they tend to take the longest amounts of time to execute. An effective way to improve the speed of these operations is to improve the performance of the database. Allocating more powerful hardware is an effective but expensive solution. Often, having a database administrator tune the database is effective. The Microsoft Windows file system is more restrictive than those of other operating systems.
Specifically, there are file path length limitations that are problematic when working with deeply nested folder structures. The propagation tools make use of the file system extensively when doing certain operations.
0コメント