Without going into too much detail, the Bundling facility allows "solutions" based upon Advanced Configuration Objects to be exported into an XML file so that they can be transported from site to site easily.

To sum it up, say you are a develoepr who develops a whole solution using the Advanced Configuuration Objects features and would like to share it with others (including a number of sites). You can attach the relevant Advanced Configuration Objects that make up your solution (Portals, Zones, Messages, Business Objects, Business Services, UI maps etc) and then export the definitions in XML format. That XML file can be then imported in the target environment and that installs the solution.

One of the things that is possible is to assess the status of a particular bundle that is being exported and imported using a query against the database (the online displays this information within the zones but you have to log online to see this information). I have compiled a query that will report basic status information.

Here is the SQL:

SELECT b.bndl_id AS "Bundle Id",
b.ext_reference_id AS "External Reference",
t.descr AS "Bundle Type",
s.descr AS "Status"
FROM F1_BNDL B,
F1_BUS_OBJ_STATUS_L S,
CI_LOOKUP_VAL_L T
WHERE t.field_name = 'BNDL_TYPE_FLG'
AND t.field_value = b.bndl_type_flg
AND t.language_cd = 'ENG'
AND s.language_cd = t.language_cd
AND s.bo_status_cd = b.bo_status_cd
AND TRIM(S.bus_obj_cd) = DECODE ( b.bus_obj_cd, 'F1IM', 'F1-BundleImport', 'F1-BundleExport')
ORDER BY 2;

You can add columns to make the query display more information as needed.

There are lots of articles about how statistics work and how to efficiently update them. Here is a short list from My Oracle Support that may assist in your understanding:

Note 236935.1 - Global statistics - An Explanation
Note 114671.1 - Gathering Statistics for the Cost Based Optimizer
Note 237537.1 - How to Move from ANALYZE to DBMS_STATS on Non-Partitioned Tables - Some Examples
Note 122009.1 - How to Retrieve Statistics Generated by ANALYZE SQL
Note 130688.1 - Script: Report Statistics for a Table, its Columns and Indexes with DBMS_STATS
Note 130911.1 - How to Determine if Dictionary Statistics are RDBMS- Generated or User-Defined
Note 1074354.6 - DBMS_STATS.CREATE_STAT_TABLE: What Do Table Columns Mean?
Note 117203.1 - How to Use DBMS_STATS to Move Statistics to a Different Database
Note 130899.1 - How to Set User-Defined Statistics Instead of RDBMS
Note 149560.1 - Collect and Display System Statistics (CPU and IO) for CBO usage
Note 153761.1 - Scaling the System to Improve CBO optimizer
Note 102334.1 - How to Automate Change Based Statistic Gathering - Monitoring Tables

Search for "Managing Optimizer Statistics" in your favorite search engine to get the product documentation.

The question I get from sites, is how often and how can I minimze the impact of the collection of statistics. Again there are guidelines available in the database documentation that suggest that you should update when a certain percentage of change in individual changes in table and how to minimze the impact of collacting the statistics.

The product itself does not have specific guidelines (except that it needs to be done on a regular basis) as we like to fit into the regime that you employ at your site for updating statistics and the growth factors experienced on individual objects due to the way you use the product.

There are three main tools that implementations use:

1. ConfigLab - A configurable copy facility is metadata aware and therefore understands the relationships between objects and by invoking the relevant maintenance objects validates the data copied. This utility uses the object validation to help ensure data integrity. Basically it is a set of configuration tables and a set of batch jobs to perform the mingration of data.


2. Bundling - A configrable release management ool that allows exporting of Advanced Configuration Environment based objects (business services, business objects, UI Maps etc) from one environment to another.


3. Blueprint - A Oracle Utilities Software Development Kit (SDK) based tool to import metadata from the development environment to your initial testing environment. The utility is command line based and basically uses a text based configuration file to drive the utility on the source and target sides.

I am asked which one I recommend for data migration. I believe each tool has a role in an implementation but you must be careful to use the right tool for the right job within an implementation. So here is my advice:

• Only use the Blueprint tool for migrating data from your development platform to your initial test environment. The blueprint tool is not designed to move large amounts of data and certainly is risky, if not used correctly, and can potentially break the integrity of your data. The SDK provides the configuration data that it is used for (mainly meta-data). This should not be extended as, while it can perform data migration on any data, it is not efficient and risky for certain types of configuration data.
• Only use Bundling on Maintenance Objects that are authorized for Bundling. There is an indicator on the Maintenance Object definition that decides whether it is "Eligible for Bundling". Bundling has been designed to migrate Advanced Configuration Environment based data and allow third parties to ship Advanced Configuration Environment based solutions to customers in a XML format.
• Use ConfigLab to migrate data from environment to environment. It has been designed with this in mind. It checks that any migration is valid before it applies the change to the target environment. This basically assists in maintaining data integrity. It also allows for Approval and Rejection of individual changes and even has an inbuilt audit trail for afurther analysis of changes. All important considerations for migrating complex data with complex relationships.

Interesting videos already there.

They also have setup a twitter channel.

• Concepts - General Concepts and Performance Troublehooting processes
• Client Troubleshooting - General troubleshooting of the browser client with common issues and resolutions.
• Network Troubleshooting - General troubleshooting of the network with common issues and resolutions.
• Web Application Server Troubleshooting - General troubleshooting of the Web Application Server with common issues and resolutions.
• Server Troubleshooting - General troubleshooting of the Operating system with common issues and resolutions.
• Database Troubleshooting - General troubleshooting of the database with common issues and resolutions.
• Batch Troubleshooting - General troubleshooting of the background processing component of the product with common issues and resolutions.

• Concepts - General concepts and introduction.
• Environment Management - Principles and techniques for creating and managing environments.
• Version Management - Integration of Version control and version management of configuration items.
• Release Management - Packaging configuration items into a release.
• Distribution - Distribution and installation of  releases across environments 
• Change Management - Generic change management processes for product implementations.
• Status Accounting -Status reporting techniques using product facilities. 
• Defect Management -Generic defect management processes for product implementations.

The Single Fixes infrastructure is used for far more than just fixes. It is reused for a number of key deliverables:

• Off New functionality is introduced off cycle using single fixes - Obviously, the new funtionality is not "enabled" by default for backward compatibility.
• Service Packs are delivered as single fixes - This represents a group of single fixes in one install package.
• Language Packs are delivered as single fixes - Products are multi-lingual so packs for individual langauges are available as single fixes.
• Fixes not related to the current release are delivered as single fixes - If a problem is registered in a past verison of a product and has been identifed as a potential problem in the current release, then a single fix for the "retrofit" may be released. You will usually see the words "Copy of..." in the single fix title and the number of the past fix number.

This can lead to a lot of fixes listed on the support site.

To minimize the impact of installing single fixes, I recommend the following:

• Only install the single fixes that apply to your site. Most cases you just want to install the single fixes that YOU register.
• Wait for Service Packs. The Service Packs are a cumulative collection of all the fixes available in one download and install. This is the easiest way to keep up.

There is a My Oracle Support KB ID (804612.1) on the important fixes. If you look at the list it is a list of individual single fixes to install. To install them all, the easiest way is to install the latest service pack.

The changes are to the process for implementation based upon feedback from customers as well as our own internal review process.

I will be attending the utilities tracks as well as some of the main sessions. If you are attending as well and want to catch up for a chat or discussion about the product, feel free to talk to me at the various events that are being held.

I will not be presenting this year but will be attending the sessions.

Like all of the best practices documents I published, there is no guarantee that the practices will provide the same level of benefit as the original contributer but they may provide some poisitive benefit for your implementation.

The document is available on My Oracle Support at KB Article 942074.1.

All the screens in the product are dynamically built using the screen definition and meta-data to deliver the screen to the Web Application Server. This allows implementations to customize the screen literals using meta-data (including multi-lingual tags) and also allow extensions to be added dynamically ( via client side user exits). This can delay the startup of the product as the preload dynamically all screens (within the configured scope).

This behavior can happen at application startup time (preloading) or when the screen is first accessed by the first user. The latter is a slight overhead (10-40ms) on the first call for the first user. After the screen is dynamically built, it is available to all users, just like the preload option.

So should I preload or not?

• If your site is sensitive to availability then a faster product startup is required so disabling preloading is suggested.
• If your site does not use a majority of the main menu then disabling preloading is suggested. Preloading at a minimum will process all of the potential main menu items whether they are used at your site or not.
• If your site is not sensitive to availability and uses a majority of the main menu then preloading should be scoped to only preload the main menu. The administration meny is not used by the majority of your end users so it is not efficient to preload.

Preloading is controlled by two product paramaters: disablePreload and preloadAllPages. The "Technical Best Practices" whitepaper on Metalink (KB Id 560367.1) outlines the valid values for these parameters.

As an aside, one of the big reasons preloading was included was for demonstrations. Typically the products are demonstrated on laptops by sales personnel so preloading screens for all functions them is ideal. They are not startup time sensitive and wish to minimize ANY delay when displaying screens on a laptop.

If you are undecided, remember this, the overhead on preloading can be minimal if it is not enabled at startup time as it only affects the first user on an individual screen. Over 99% of the time whether the screen is preloaded or not, the users will not see the difference. The differentiator is whether you want a quicker startup time or do not want that first user to have a slight delay when they first hit the screen, in that case preloading is for you.

We have sites who preload and sites that don't preload in production.

Oracle Utilities Customer Care And Billing can use the Standard and Enterprise Editions within the limitations of those editions.

Please refer to Note 861306.1 for clarification of the support of the Standard Edition.

• 753301.1 - Oracle Utilities Customer Care And Billing Batch Operations And Configuration Guide
• 753303.1 - Oracle Utilities Customer Care And Billing Operations And Configuration Guide

The documentation includes references to single fixes that have been release up to and including late June 2009.

There are quite a few updates to the document:

• The advice is now centered around V2.x of the Oracle Utilities Application Framework.
• Background of the Oracle Utilities Application Framework - History of the Oracle Utilities Application Framework including a summary of its facilties.
• Updated list of whitepapers for the product set.
• Data Management Best Practices - Originally some internal advice but some advice around data types, archiving, data retention, partitioning, compression and clustering.
• Network Bandwidth guidelines.
• Clustered server advice.
• New section on Business Server Best Practices including JVM optimization advice and cache controls.
• New Database Parameter settings.

All V1.x advice has been placed in a seperate document now for V1.x customers.

The relevant document numbers in My Oracle Support are:

• 560367.1 - Technical Best Practices for Oracle Utilities Application Framework Based Products
• 856854.1 - V1 Addendum for Technical Best Practices for Oracle Utilities Application Framework Based Products

This document will be updated every 6 months or so and reposted. Hope the documentation helps you all out. I quite enjoyed doing the updates to this document in particular as it was the first whitepaper I wrote ages ago. I decided it was LONG overdue for an update. Interestingly I updated this document while recovering from a fractured arm over the last few weeks so this update willbe remembered by me for a while.

• web.xml - The J2EE Application Descriptor
• XAI Options - MPL and other XAI components use this as a registry

The product can (and does) support clustering if you set these settings correctly. Let me explain.

There are four types of environmental setting that are left in these files and here some advice on how to set them in a clustered environment:

• Hostnames - Hosts for URL are used. In a clustered environment, this value should be set to the cluster host or the proxy host/load balancer.
• URL Patterns - It is possible to change the URL pattern (i.e. SPLApp/cis.jsp) to allow flexibility in the URL. In most clusters this value is common across the cluster, therefore any value you specify should apply to all nodes in a cluster.
• Port Numbers - The port number is specified as part of the URL. Most sites tend to use 80 in production as that is the default port. Again, in most clusters this value is common across the cluster, therefore any value you specify should apply to all nodes in a cluster. Most vendors require a cluster to use a common port number across the cluster. If the port number changes per node, that is typically called "managed" servers not "clustering".
• File Locations - Some of our components need to orientate where key files are stored. In a cluster it is assumed that the underlying software has been installed on each of the nodes. If this is not the case this value can be set to a shared resource on the cluster that holds that information. If the software is installed then to support clustering the software should be installed in the same location across the cluster.

Setting these values appropriate can assist in supporting clustering with environmental settings.