X

An Oracle blog about PeopleSoft Technology

Understanding the Customization Repository

David Bain
Sr. Director PeopleTools Product Management

I was on a call recently and the host asked me an interesting question.  She asked “What would you say is the most valuable feature in PeopleTools that you think the fewest customers are taking advantage of?”  The first thing that came to mind is the Customization Repository.  It’s a feature in PUM images that gives insight into conflicts between your customizations and changes delivered in PUM images.  Unfortunately, it hasn’t been widely adopted.  

I think one of the reasons people have been slow to adopt is because it’s a bit confusing to understand. People see the label ‘Customization Repository’ and think that it is a repository of their customizations.  That’s not the best way to think about it.  A better way to think about it is it’s one or more named groups of PeopleTools objects (keys only) that can be compared to changes delivered in PUM images.  The result of the compare will help you scope the size of the project and/or help you decide what and what not to include in your change package.  

What do I mean by a named group of PeopleTools objects?  Think about your customizations.  They are all made with PeopleTools objects, some in AppDesigner (Records, PeopleCode, Pages, etc.) and some online (Related Content, Pivot Grids, etc).   There are a lot of different ways to categorize customizations that might be meaningful to your maintenance projects.  You could group them by customization feature, localization, technology used, consultant that did the work, level of complexity and on and on.  In fact, you may want to group them in a way that a PeopleTools object might end up in more than one group, even for the same feature.

Once categorized, groups are compared to delivered objects.  It’s important to understand the only thing being compared are the keys, so the compare checks to see if an object from a group has been changed.  If the same object is in both, then it’s identified as a conflict and brought to your attention.

Let’s run though a quick example.  There is a set of customizations that you struggle with each time you apply maintenance.  They are not related to a single feature, but were actually part of a large customization project back in 2002.  You are gradually replacing those changes with Event Mapping and Drop Zones, but until that happens, you want to minimize the amount of changes to those objects.  You create a customization group you call ‘2002 Upgrade Miscl’ that includes the records, peoplecode, pages, and components and other tools objects that you want to track.  

Now it’s time for a maintenance project.  You want to take as much maintenance as you can but you don’t want to include any changes to any object in the ‘2002 Upgrade Miscl’ group.  Those are for another day.

Simply open the Customization Repository, find the group and set the ‘Include in Package’ flag to ‘No’. 

Now, when the system will automatically prevent any object in the ‘2002 Upgrade Miscl’ group from being included in a change package.  Of course if there are any dependencies that pull these objects in they will be prevented from being included as well.

There’s more to this customization repository that we’ll save for a later time.  But now you can start thinking about ways that you would group your customizations to give you insight and help your maintenance projects going forward.  

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.