The Shorten Spot

I am currently updating the Software Configuration Management series of documents for the latest practices and facilities in the product. One of the features getting attention is the Bundling facility provided for the Advanced Configuration Objects.

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.

One of the most important pieces of advice I like to give customers is the fact that their database statistics should be kept to date. The Cost Based Optimizer (CBO) uses statistics in the database to decide the most efficient path to get the data for individual SQL queries. If the statistics are stale or incorrect then the CBO may pick a less optimal path. It may make the wrong decision with the wrong statistics.

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.

One of the most common questions I get asked by implementations is around the utilities available for moving data from environment to environment. This confusion is that with the Oracle Utilities Application Framework based products there are a number of tools provided that can be used to transfer data from one environment to another.

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.

Oracle Utilities has a Youtube channel for customers and strategy people to outline their views and their implementations of Oracle Utilities products.

Interesting videos already there.

They also have setup a twitter channel.

One of the features of the Oracle Utilities Application Framework based products is the ability to implement single fixes. A single fix, as the name applies, is a software based fix for a particular bug or problem register by a customer, partner or even internally.
The idea is that if a specific problem is found then we can ship a specific fix for that problem. Sounds simple enough. Well, it all sounds simple but it can get more complex due its power. With great power, comes complexity.

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 LDAP Import whitepaper has been updated and reposted to My Oracle Support at Knowledge Base article id 774783.1.

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

It is fast approaching October and that means it is Oracle OpenWorld time again. The event is held annually in San Francisco every year and is on between October 11-15 this year.

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.

The latest whitepaper to hit My Oracle Support is XAI Best Practices. This document took a long while to compile but contains workflows for common configuration tasks for XAI as well as a set of Best Practices obtained from customers around the world.

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.

One of the features of the Oracle Utilities Application Framework is the ability to preload the screens for performance reasons. Let me explain about this facility.

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 ships a number of editions of the database. See Note 465460.1 for details of the differences between the editions.

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.

The following Oracle Utilities Customer Care And Billing technical documentation has been updated for Service Pack 4:

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

This the updated list of whitepapers available for the Oracle Utilities Application Framework:

The Best Practices for IT Operations for Oracle Utilities Application Framework Based Products whitepaper has been updated for the latest information and has been renamed to "Technical Best Practices for Oracle Utilities Application Framework Based Products".

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.

With the implementation of Single Fix 8218568 there is a misconception that all the environmental based settings are now externalized. This is not the case there are two more locations where there are some additional environmental settings:

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

One of the issues some customers face is that the configuration settings are bundled within the application itself. This meant if you made a configuration change you needed to rebuild the deployments files and under certain conditions this can cause administration delays.

With Single Fix 8218568 all the configuration files previously included in the deployment can be overridden if the configuration files are placed outside the deployment files in the correct location. This affects the following configuration files:

• spl.properties
• hibernate.properties
• log4j.properties

This change only affects online (root app, XAI App and Service EJB) as background process component already has this functionality. It also does not affect the J2EE Web Application descriptors (web.xml and weblogic.xml). This means that if you setup the configuration settings as per the PFD (shipped with the fix) then you do not have to run the deployment utilities to build and redeploy the product in the J2EE Server.

If the files are in the following locations they will override the one bundled with the deployment file:

Root App - $SPLEBASE/etc/conf/root/WEB-INF/classes
XAI - $SPLEBASE/etc/conf/XAIApp/WEB-INF/classes
Service EJB - $SPLEBASE/etc/conf/service

Note: For this fix to work the SPLEBASE environment variable MUST be set to the appropriate location and available to the J2EE Web Application Server prior to starting the J2EE Web Application Server. If it is not set, the product will use the settings contained in the EAR file.

Of course, when the files in these locations are changed it requires a restart of the product to reflect the change.

To install this fix you must install the following additional fixes (in order) prior to installing this fix:

• 8436955
• 8519398
• 8498736
• 8473778

Note: This assumes you have already installed Oracle Utilities Application Framework V2.2 Service Pack 4 prior to installing any fixes.

This enhancement will help customers who deploy clusters or who make changes to certain parameters, such as passwords, on a regular basis.

This the updated list of whitepapers available for the Oracle Utilities Application Framework:

A batch best practices whitepaper has been released on "My Oracle Support" covering the common and best practices for the batch component of the Oracle Utilities Application Framework.

It covers configuration, execution and scheduling advice for the batch component used by products using the Oracle Utilities Application Framework.

The Knowledge base article id is 836362.1.

You may of noticed that my blog has been silent the last few weeks. Well, I had a minor accident and fractured my arm so my productivity is somewhat reduced. Whilst I recover I will bo slowly posting new entries and publishing new whitepapers.

Thanks for your patience.

It has been a while, between customer visits and my vacation I have not posted for a while but expect a flurry of posts over the next month or so to catch up.

The latest service pack for V2.2 of Oracle Utilities Application Framework and Oracle Utilities Customer Care And Billing is available for download.

This service pack contains the latest fixes as well fixes that were part of Service Pack 2 and Service Pack 3. Service Pack 1 fixes are not included as the service pack format was changed between SP1 and SP2.

The readme with the service pack contains the detailed instruction of what is included and also what is required to install the Service Pack.

The Support numbers on My Oracle Support for the Service Pack are:

8520899 - Oracle Utilities Customer Care And Billing V2.2 Service Pack 4
8520890 - Oracle Utilities Application Framework V2.2 Service Pack 4

Do not forget to follow me on twitter (theshortenspot) for all the latest announcements and pointers to advice.