Thursday, 13 April 2017

5 things about PeopleSoft Update Manager Change Packages



PeopleSoft 9.2 applications have been following a continuous delivery model since March 2013. Selective Adoption is the term used to describe this model and is characterised by the ability for customers to choose what updates they apply and when they apply them (a key differentiator between PeopleSoft and cloud SaaS applications).

PeopleSoft Update Images (often referred to as PIs (PeopleSoft Images), PUM Images or just Images) are the delivery mechanism for all PeopleSoft application updates (fixes, regulatory updates and new features).  

PeopleSoft Update Manager is a tool within the PUM Image which is used to select updates and define Change Packages for deployment.

Change Assistant tool is then used to take these package definitions and build the physical Change Package.

I'm presenting at the UKOUG PeopleSoft Roadshow in London on 26 April on Selective Adoption and the Oracle Cloud so come along to join in the discussion.

Until then... here's 5 things about Update Manager Change Packages:

1. PeopleSoft Update Manager Change Packages are used to deploy application updates to a target PeopleSoft system.  The package itself is a single ZIP file containing all* files necessary to apply one or more application Updates to a target PeopleSoft system (*see thing 4 below for exception to this).
2. You create a PUM Package using the Define Appliction Package menu option in the PUM Dashboard.  This can be found in the PUM Image: PeopleTools > Lifecycle Management > Update Manager
3. You apply a PUM Package to your target PeopleSoft system using Change Assistant (a Windows based tool which orchestrates the execution of predefined actions such as SQL and DataMover scripts, App Designer Projects, etc).
4. The first time you apply a package you apply it in "Initial Pass" mode.  This will add to the Package ZIP file any additional files necessary to apply the package in "Move to Production" (MTP) mode - additional files such as Datamover DAT files for loading messages and other meta data along with customised Application Designer objects if any customisations had to be re-applied.  In Initial Pass mode Change Assistant must have access to the same PUM Image as was used to create the Package and must have access to the target PeopleSoft system.  Change Assistant is expecting to not only reference the PUM Image for application data but also is expecting to find the defined Change Package in the PUM Image.
5. After Initial Pass you end up with a new ZIP file that contains everything you need to deploy the Updates to your target PeopleSoft systems.  Once you have this final ZIP file Change Assistant does not need access to the PUM Image again.


4 comments:

Bart22 said...

Graham,

Thank you for the overview - I have two questions:

1. the 'initial' pass - it doesn't only create the zip file, it also actually moves the changes to the target database, correct?
2. Is it wise to create a demo change package and apply to an existing demo database (we don't want to use the PUM Image as demo database), and create separate change package(s) for the other databases? What is best practice?

Many thanks,
Bart

Graham said...

@Bart22:

1. the 'initial' pass - it doesn't only create the zip file, it also actually moves the changes to the target database, correct?
GS: Yes. That's correct. Your initial target is normally going to be Development (or somewhere that has your customisations and closely matches production).

2. Is it wise to create a demo change package and apply to an existing demo database (we don't want to use the PUM Image as demo database), and create separate change package(s) for the other databases? What is best practice?
GS: It is the aim to keep Demo in step with Production. Any update you apply to production you should also apply to demo and equally don't apply an update to demo that you will not also apply to Production. It's vital you have a demo system which reflects production (less customisations) in which you can recreate issues. So, best practice is to
1) load target (dev) into PUM Image,
2) create change package and
3) run IP against target (dev),
4) this IP process will create a new "updated" change package which then can be applied to UAT/QA, production but NOT demo.
5) You need to apply to demo the original Change Package used in the Dev IP (this CP is renamed at the end of IP so you don't lose it).


Hope this is helpful.
Graham

RK said...

I know this is an older post, but can you clarify 5)in the above comment? Apply the orig change package to DEMO environment. Can you elaborate on that, do you move that CP as a Move to production or how is CA assistant configured to do so? Traditionally before PUM, I'd apply the update to DEMO first and then migrate it to my dev environments and if I understand this, we now do DEV first then DEMO and I just want to make sure how I apply the update to DEMO. Thanks

Graham said...

@RK> Sorry for delay in getting back to you.

Firstly, you can continue your original practice of applying update to Demo first. The only reason oracle recommend applying it to demo after you've updated production is because it help achieve the desired state of Demo. That is "demo should contain only updates that have been applied to production". If you apply to demo first then that's still ok as long you back it out of demo if the update never makes it to production.

The very first time you apply a Change Package (CP) it runs in initial pass mode. In this mode you get a chance to manage (i.e. compare and reapply customisations) customised objects and then at the end of the job it creates a NEW CP which contains your recustomised objects . It is this NEW CP that you then apply to UAT and Production. However, as this CP contains customised objects it's NOT the CP you then want to apply to Demo. So you need to go back to the original CP (ie the one that gets renamed during the initial pass). Hope that makes sense.

Graham