Posts Tagged ‘Oracle Patches’

R12 Deployment using Captured Alien Technology from Roswell

December 26, 2010

On June 13th 1947, residents of Roswell reported seeing bright lights in the sky, moving at remarkable speed and then a huge explosion. 1947. The next day Mac Brazel found the crash site, and the biggest coverup in human history began. Today I am pleased to reveal a WORLD EXCLUSIVE of what really happened and how that technology worked it’s way into Oracle technology you use today. I promise with all the thousands of Oracle blogs on the internet, you will read this nowhere else……..

The crashed  UFO was taken to Area 51 (the photo above was smuggled out and is 100% genuine we believe)  and housed in a large top secret highly restricted warehouse. For over two decades scientists tried to break into the UFO’s computers with no success. From this 200 million dollar research program funded by the US Taxpayers, the only success was the discovery from the UFO of how to make non-stick frying pans. It was at this point during the famous alien autopsy that scientists also found out that the famous grey aliens keep their brains in their ass, explaining their relatively low intelligence compared with the sentinel aliens. Further there is strong evidence that a recent US President was indeed an alien, as many stated “he had his brains in his ass”.

At the same time, a bright but underachieving student named Larry Ellison, was flunking university with some style. In 1964 the government inadvertently invited Chicago students (including Larry) to the highly secure, non-existent area 51 for a field trip (Normally intruders are shot on sight but a clerical error led to 100 students, including those with far-left tendencies to be invited in). During this field trip, as the scientists were showing the non-stick frying pans Larry lost interest and wandered off, stumbling on the UFO (shown above in the 100% genuine photo). He started to mess around with the UFO computer and stumbled upon tape drives, which the 200 Million dollar research program scientists did not understand just what these were for almost twenty years. Luckily Larry had 20 large 10 inch tapes with him and he downloaded the entire UFO software. As he walked out Larry thought the game was up as security stopped him. “Do you need a hand with those tapes young man?” said the security guards. The kind guards got these dropped off at Larry’s house from the highly classified, non-existent area 51 site.

Larry spent the next ten years working out exactly how aliens were using advanced software technology using these tapes, before formally starting Oracle in 1977.

The truth is that Oracle software is based on alien technology

Now using alien technology was not all plain sailing (Larry can you stop spending so much on this sailing stuff – great pun and literally transition eh? – and start paying more in dividends….???). When Larry used alien technology to create Oracle Apps 10.7SC he did not realize that the aliens had tried this exact same strategy on their home planet of Ursula Minor Quadrant 5 with an ERP product called Grey Apps SC (note the naming similiarity) and everyone was laughing at how crap it was………The same thing happened here on earth to Larry’s home grown 10.7SC version. Larry eventually apologized for this ERP Release.

However the Oracle Database, ERP and now Fusion (even sounds alien) can now be revealed as being based on the software from the captured UFO in Roswell. And of course with such software, other vendors such as IBM and SAP (that 2 Billion dollar fine must sure have hurt), offering vastly inferior software are doomed….you may as well sell their shares now. It’s interesting to note it took a team of Oracle scientists a further 20 years to break the alien tapes for Fusion software. Oracle claims to have thousands of people working on this but this is just disinformation. Think about how little information is out there. Why is Oracle so secretive on Fusion Apps? When it does come out look for the alien code, that has not been taken out amongst the 50 million lines of source code.

Fusion Apps was delayed because Oracle couldn’t break the alien code. Fusion Apps is actually being developed not by a team of thousands as Oracle claim, but by a single programmer named Steve in his bedroom using the captured alien technology from Roswell.

And I feel a movie recommendation coming on. So captured alien technology that humans then re-engineer for their own ends? Well this one absolutely fits the bill. Terminator was a classic (as were all the Terminator movies) and they score a 10 out of 10. All are great movies to rent or buy.

Interestingly the new Exadata is similiary based on blueprints from those tapes. When you turn one of these Exadata servers on it uses less power than a lightbulb (it has alien fusion power sources and chips and a special plug from Home Depot). When you turn on the IBM servers with the same performance, all the lights in New York go out as it drains the power grid (allegedly according to a guy I talked to in a bar at 2:00AM. The lights of the bar went out and that’s when he stated someone turned on the IBM server again……..). It’s pretty conclusive proof of the use of captured alien technology from Roswell.

At this point I’d just like to say I don’t believe in conspiracy theories, or alien abductions, etc. So if you’re some UFO nut that stumbled on this column and think this is all true, please don’t stalk me for photos and email me for further stories, as I’ve got good lawyers and I’ll take out a restraining order on you……..Now onto the serious business of the column – Teleportation. (Your thinking I’ve really lost the plot today right? Stay with me on this one for one more paragraph)

Look at the definition of teleportation. It breaks down physical structures and moves them from one place to another. I’d like to claim the Nobel Science prize for showing we already have this today and finally get to the point of today’s column (some are happy because they get hopefully useful information after reading like 10 pages of crap, others probably think here come the boring stuff and it was amazing Oracle based all their products on captured Alien Technology….we suggest those people get a life…….). Don’t worry, I’ll try to keep it interesting as I’ve absolutely got to do some sci-fi movie recommendations given the title of this column right?

So the topic for today is migration of all your R12 setup, customiztions, etc. (Well think about it. You take physical information, sitting on a disk, transfer it over a network which might even be some fibre optics channel, so actually converting physical info to light…..now that is super advanced ….. and then reconstruct on the other disk. Now that’s the very definition of teleportation).

Now there are two approaches. Either you manually do this (and risk all the screw ups) or you use teleportation. I’d love to see your bosses face as two weeks ago you were telling him of Zen Patching (See the article on the Art of Zen Patching) and today in your management meeting when you are asked how to solve deployment issues you suggest TELEPORTATION with a straight face, which you got from some guy called the Oracle Prophet on the web…….

When you do an Oracle implementation, or an Upgrade, or a new module or a single project or even a simple customization, there is potentially a lot of information that needs teleported. I wonder how many people have been fired as a result of my columns so far……

So today is a high level overview of the options you have to safely move the various components around your R12 instances with the minimum of fuss and the minimum risk. This is going to be a handy column for all those doing an R12 Upgrade in 2011 (given Premium Support has ended and R11 Support is dependent on some nasty small print of applying minimum patch levels…….)

FNDLOAD

Lets start with one which I hope just about everyone knows. FNDLOAD. Now this has been around since the first aliens came down and built the Pyramids……..So to quote Oracle Oracle Applications System Administrator’s Guide – Configuration Manual:

“The Generic Loader can download data from an application entity into a portable, editable text file”. How cool is that? You can download lots of your setup and edit it, giving you the ideal opportunity to screw things up bigtime.

But FNDLOAD is an amazing utility. With a single command line you can download an incredible array of setup including:

Applications

Attachment Setup

Concurrent Program Executables

Concurrent Program Definitions

Descriptive Flexfields

Folders

Forms

Functions

Key Flexfields

Lookup Types

Lookup Values

Menus

Messages

Printers

Printer Styles Definitions

Profile Options

Profile Values

Request Groups

Responsibilities

Values

Value Sets

(and a few more not documented………)

Using FNDLOAD is a breeze. Simply type in a one line command to download and a one line command to upload. Now if your doing 1,000 Menus across 12 Project Instances during Implementation, the time savings are vast….

FNDLOAD apps/apps_psswd 0 Y Mode configfile datafile entity [param]

It really is as simple as a single one line command.

A great blog entry on the details can be found at Anil Passi Blog. This gives a much more detailed overview than this column can and is a great blog with lots of other info too.

So which movie made teleportation famous? Well that has to be Star Trek, which started way back in 1966. Now I’m not a Star Trek fan, but the the 2009 Star Trek Movie was pretty good and I’d give that an 8 out of 10. Definitely worth a rental on DVD in 2011.

Generic File Manager Access Utility

Well here’s one I’ve never even heard off – Generic File Manager Access Utility. Now in a manner befitting Star Trek and during research for this article I came across this and we should boldly go where no man has gone before (Note Star Trek finally became gender aware and change this to a more acceptable politically correct sentence…..)

As said can’t say much on the Generic File Manager Access Utility as never used it, but its covered again in the Oracle Applications System Administrator’s Guide – Configuration Manual. From what I can see it’s used to transfer Help Files between Systems, but as with everything in an Oracle manual, a lot is left unstated………

Oracle Alerts

Now Oracle has the ability to define Alerts across pretty much any business area. These are very useful and used by a lot of companies. But they can take a fair chunk of time to define and migrate. Not many people know this, but alerts can also be transferred between databases. Having a quick look at Oracle Alert User’s Guide it’s a pretty straightforward procedure:

Firstly go to the Alert Screen.

Simply choose from the Tools Menu the Transfer Alert option and fill out the screen above. Very straightforward and saves a lot of time.

Now apparently there is also an option to transfer alerts using FNDLOAD

FNDLOAD apps_user_name/apps_password O Y DOWNLOAD $ALR_TOP/patch/115/import/alr.lct my_file.ldt ALR_ALERTS APPLICATION_SHORT_NAME=”INV” ALERT_NAME=”Alert_to_download”

See Meta Link Note: 400295.1 for more details.

Now the interesting point is that you can download all your configuration files and once your happy, store them in a Source Control System such as Subversion or PVCS. Once you are ready to deploy to a new instance all the files can be automatically loaded using a Shell script (or some other newer options I’ll discuss) in a matter of minutes. Interestingly if you combine using a database flashback option and an automated shell script you can practise deployments many times in quick succession until you get it right. That keeps your Production very safe, as you will have removed all the bugs from deployment by repeateded practise runs. The Database Flashback option lets you go back to a previous version of the database very quickly indeed.

So time for another movie recommendation. Back in the 80’s, when I was a kid, I saw one of the most magical and memorable movies of my life. E.T. This movie is timeless and one your kids will definitely love. It’s funny how ET used a Texas Instruments Speak and Spell and a few bits of wire to make an intergalactic telephone to call across the Universe for help. Ironically putting a bunch of very simple tools together (FNDLOAD, ISetup, etc) can equally help you in either your R12 Upgrades or R12 Implementations………..

Data Load

So how do you spot a Functional Consultant? One way is that generally Functional Consultants have weird hairstyles. That’s a sure give-away. The other give-away is that they are sitting trying to write SQL badly so that they can get the data for their beloved Data Load Tool.

So what is Data Load? Data Load is a tool that basically takes all your data and plays it back into an Oracle ERP screen. It’s uses are endless from typing in Account Combinations, Suppliers, Inventory Setup, etc. It can work on both Core/Professional and Self Service screens. Sure there are others ways to do some of the stuff listed, but that requires heavy technical ability, and sometimes on projects that just ain’t there, so that’s when Functional guys turn to this tool, plus all the stuff that technically cannot be done without violating your support license.

Now you imagine. Even with all the “alien technology” I doubt Oracle has everything covered in terms of setup, etc. So you imagine having a tool that can pretty much load into a very large number of screens, where no API, FNDLOAD or Interface can go……….and then be able to source control everything and when you get a new environment during implementation you can simply run Data Load to create a lot of what would take you days to setup. And it’s so easy even a Functional guy can use it………

I’ve seen a lot of people rave about this product and use it during implementations. It’s definitely worth a look and you can find it at the Data Load Site.

FSG Export/Import

Apart from the funny hairstyle and dataload, another way to spot a Functional guy is that they generally are writing FSG Reports. For those that don’t know, FSG Reporting provides the ability for end users to write various accounting reports with no programming in Oracle General Ledger. Now if you’ve ever written one of these, you’ll know they can involve zillions of rowsets, column sets, etc. They take a long time to define and setup.

An excellent blog on the details of FSG Transfer can be found here.

Oracle ISetup

iSetup has been targetted to deploy a lot of the functional setup. Now I looked at this product quite a few years back and found it disappointing to be honest.

However it does seem to have moved on and it does now support more in terms of setup.

iSetup now supports:

Application Object Library

Oracle Financials

Oracle Human Resources Management System

Another link I checked is stating that the coverage is much wider across General Ledger, Accounts Payable, Accounts Receivable, Fixed Assets, Cash Management, Purchasing, Inventory, Bill of Material Engineering, WIP, Costing, Order Management, Shipping, HRMS and Payroll. Its worth checking Metalink for the latest list of objects that iSetup supports, together with re-use of API’s.

From an Application Object Library perspective, iSetup supports a similar list to FNDLOAD.

From a Financials perspective, as of 12.1 iSetup supports various General Ledger setup including Chart of Accounts, Currencies, Accounting Calendars, Budgets, Ledger Sets, etc.

iSetup has some support for Cash Management including System Parameters and Transaction Codes.

From an HRMS perspective, as of 12.1 iSetup supports various HRMS Setups including Locations, Business Groups, Organizations, Organization Structures, Job Groups, Jobs, Grades, Position Structures, Position Hierarchies and Positions. It also supports Employee Migration.

From a Payroll perspective, as of 12.1 iSetup supports various Payroll Setups including Balance Types, Defined Balances, Balance Attributes, Element Classifications, Fast Formula, Element Types, Input Values, Balance Feeds, etc.

One interesting option is the possibility to download and then modify and change. Allowing for instance setting up once and then changing for a different country and reloading. Has a lot of time-saving potential.

iSetup can also migrate XML Publisher data, Personalizations and Workflow Definitions, so it is well worth investigating as an additional tool to your deployment strategy.

Another nice feature of iSetup is the ability to compare various objects across databases. Handy when somethings stops working and you are looking for a needle in the proverbial haystack with a small piece of missing/mistyped setup.

Further details can be found on the websites below:

Steven Chan – Ten Ways of Using iSetup

iSetup Data Sheet

Frontier Consulting – iSetup

Frontier Consulting – iSetup Best Kept Secrets

Solution Beacon – Some new Thoughts for an Old Friend – iSetup

Trutek – Migating your Customs with iSetup

And with that it’s definitely time for another movie review. So a column all about aliens and their technology…..well if this column is all about Aliens and Sci-fi movies then one of the best Alien movies of all time has to be Aliens 2. I give this an absolute 10 out of 10. And you can probably pick it up on DVD pretty cheap given it’s a real old movie now, but still incredibly good.

OA Framework Personalizations

A lot of sites are using OA Framework Personalizations to modify OA Framework Pages, with a view to limiting impact of future upgrades/patches. Some of these personalizations can be quite involved and re-applying these involves a huge amount of work. Luckily again Oracle provides a handy method of exporting and importing these personalizations across databases.

More details can be found in the excellent blogs below:

Anil Passi – OA Framework Personalization Migrations

R12 Form Personalizations
 
 A little known feature of R12 is Form Personalizations. This allows you to replace quite a chunk of CUSTOM.PLL (or other Library code) with code that you define directly in R12. A great article covering this can be found at

R12 Form Personalizations

Now this not only allows you to remove custom code from CUSTOM.PLL or attached libraries (which is great), it also allows you to extract and import these Personalizations.

Simply using FNDLOAD again does the trick:

FNDLOAD user/pass 0 Y DOWNLOAD affrmcus.lct output_file FND_FORM_CUSTOM_RULES form_name 

Using R12 Form Personalizations is a more flexible and more visible way of approaching some forms based customizations. It’s also much more supportable.

Putting all the Alien Technology Together

There are a couple of interesting options with all the tools listed above that could radically improve your processes, make your ERP Instance(s) a lot safer and save you piles of time.

Firstly most of them produce files. Files can be put into Source Control such as Subversion (it’s free and great). If you Source Control your files, you can implement proper Release Control, guaranteeing that what you deploy is what you really want to deploy.

With all your files for setup in source control you can write automated deployment scripts, that will deploy all your setup in a matter of minutes (or if you have huge amounts of setup, a couple of hours). This will allow you to practise deployment in a repeatable manner until it works with ZERO failures. (Use the database flashback allows you to run deployment and then restore to a previous state in a few minutes, allowing multiple deployment runs/adjustments). Once you have that deployment release perfect, your Production deployment will be vastly safer than 99% of other companies on the planet.

Now Oracle’s heading in a very interesting direction with all this using the Application Change Management Pack. This, as Oracle puts it “provides a centralized view to monitor and orchestrate changes (both functional and technical) across multiple Oracle E-Business Suite systems.”

Read this for some more details on the Application Change Management Pack.

Now I don’t know just how good this is, but imagine being able to put large parts of your Functional and Technical Setup and your code into a Release Patch, just like Oracle Corporation. Imagine being able to clone Production, apply your patch and get to the point of repeating this until you had zero failures on your very complex R12 Upgrade Customization Release Patch.

This is certainly a very interesting development and the Change Management Pack is certainly worth looking at.

So time for a final movie review and a wrap-up. A word of warning. Not all alien technology is entirely friendly. In War of the Worlds, Alien technology proved to be extremely deadly. So my final movie pick is War of the Worlds. On reflection I’ll give this a 9 out of 10. It’s a superb remake. And a word of advice, when using the FNDLOAD Alien Technology, just be careful with your parameters or you may download and then upload into Production a whole lot more than you want………

The point of these tools isn’t primarily to save you time, although they will definitely save huge amounts of time on any project. Imagine having to setup say 100 custom programs in 12 instances during a project implementation. Or 200 messages. Or thousands of menus and entries. Or module setup. A large chunk of project time is wasted by very expensive consultants doing very menial setup, rather than delivering the end solution. And it doesn’t need to be that way with the tools that Oracle provides.

The primary reason everyone should be using these tools (either in implementation or Post-Production Support or R12 Upgrades) are because these tools introduce a repeatable, testable and verifiable process. These tools vastly reduce the mistakes you make.

For all those doing R12 Upgrade, these tools allow you to be successful on cutover weekend even when the timescales look utterly impossible. (Have a look at my R12 columns, with thousands of custom objects, 600 functional setups, all to be done in a matter of a day, with everyone under serious stress. Impossible? Not if you plan ahead and fully utilize all the tools that Oracle provides to make your life easier………

Till next time when I hope to publish the Secrets of the Holy Grail and the connection to R12. Just don’t tell the Feds where Oracle technology really came from. The secret is out there.

So I guess as Arnie would say from Terminator,  Hasta La Vista Baby………

Further secret blogs and prophecies can be found at:

https://oracleprophet.wordpress.com


Advertisements

R12 Patching and the Art of Zen

September 18, 2010

Reading through Wikipedia, I found an interesting article on the concepts of Zen. Now I’m not really into that type of stuff myself (each to their own), but I thought it would make an original way to present this article 🙂

“One practice of Zen Buddhist’s is Koan Inquiry. A koan is a question, or statement, the meaning of which cannot be understood by rational thinking but may be accessible through intuition. The answer can occur during meditation or during your typical daily life with all the mundane tasks you do.

To Zen Buddhist’s the Koan is “the place and the time and the event where truth reveals itself”. It is a way to induce an experience of enlightenment or realization, not through rational reasoning, but through intuition.

Answering a Koan requires a student to let go of conceptual thinking and of the logical way we order the world, so that like creativity in art, the appropriate insight and response arises naturally and spontaneously in the mind.”

Or to quote from a very non-Zen perspective, you think about a problem very hard all day. You fail to make any breakthrough. During the next morning, in the shower, without even thinking of the problem, you suddenly think of the idea. Ironically perhaps we are all practicing Koan Inquiry as a natural state of mind to solve difficult problems, without even having to think about the problem at hand.

Now let’s look at ERP Patching in relation to Zen 🙂 We need to be clear from the outset that this form of Zen Patching applies only to the following patches below. This is extremely important to keep in mind.

Security Patches

ATG Patches

Database Patches

This form of Zen does not apply to other ERP Patches

Applying this form of Zen Patching to any other types of patches will cause you some serious grief in your career when you report to your boss that your ERP for your entire organization worldwide is trashed because you read some amazing article by some “new age ERP guy called the Oracle Prophet” on a radical new method using the Art of Zen for ERP Patching and thought it was worth a try on your Production System……….

Do note that this form of Zen Patching does work on both R11 and R12, but not on R10. It also works on 9i, 10G and 11G databases. Please check Oracle Certification matrices and raise the question to Oracle Support if in doubt.

Oracle Support – Good morning. Can I help you?

Reader – Yes could you tell me if the Art of Zen patching is certified against R12 Apps please?

If the phone goes dead at this point, we suggest you assume Oracle Support is not aware of the Art of Zen patching and you should not pursue your question with them……….We also suggest you give your colleagues name during any telephone calls with Oracle,  in case Oracle raises a complaint for nuisance phone calls to your company…..:-)

So where does the Art of Zen fit into Oracle ERP patching?

 Let’s use a typical a koan to provide an illustration.

“We will test the patch by not testing the patch. Only then will we know that the patch has worked.”

Now at this point in time, you are probably thinking I’ve been hitting some fairly strong stuff to get to this state of mind, or I’ve completely lost the plot.

I can hear everyone thinking “So let me get this straight. You are going to test the patch by not testing the patch, so that you know the patch is working”. To which I’d reply, great you’ve got it. You are certainly a quick learner on this Zen Patching stuff!!! 🙂

Our R12 Patching Philosophy actually made our auditors jaws drop, not in terms of the Zen stuff (trust me, keep this stuff between yourself and myself please and maybe better not mention to your management or auditors……), but on the thoroughness of approach.

We always have five databases for our patching (at a minimum). This is probably a lot more than most have but let me explain why and you’ll probably want to then copy this model.

Our DBA Environment. This is where the patches are applied to make sure, well they actually apply. Believe it or not some patches from Oracle don’t even apply cleanly.

Our Patch Environment. This is where they are applied with a little bit of testing. OK we deviate a little from the Zen stuff, but give me a break……This makes sure they at least do what they say on the box without major functional failure.

Our development environment, which is always busy with daily activity by our development team , functional team and testers.

Our test environment which is always busy with daily activity by our users.

Our Production environment.  I’ve been pushing our company to drop this as it uses a lot of space and we hear most of our complaints from this database, but management insist it is important and needed. 🙂

We should also state our databases are pretty heavily used so application flows naturally are being used throughout development and test databases. We also apply any patches onto any other instances we have at that point in time, so that the patch is naturally tested by the simple day to day activity in as many places as possible, with a careful rollout to each environment.

 

The Art of Zen Patching

The point is simple on these types of patches. Oracle does release patches that should be applied at some point.

The Security Patches typically come quarterly and we try to apply 3-6 months after they come out. Security patches represent a serious risk to apply, although generally apply well. However security patches also represent a risk if you do not apply. You need to find the balance, but you SHOULD apply these regularly.

The ATG Patches are less frequent but provide critical updates to Browsers (especially if you have DMZ applications) and other technology components, including diagnostics.

The Database patches (and we’re talking 10G to 11G for instance) do come out periodically and at some point you need to decide to keep at least supported, although we’re very picky on applying these, but are in the process of an 11G Upgrade. (Various 10G database versions are losing or have lost premier support). This activity is every couple of years or so.

We’re not talking about applying every patch. No company in their right mind can achieve this. We’re talking about keeping your head above water and staying supportable.

The point is this. To test every time on these types of patches across every last item is impossible. The conventional way is to get the patch, apply, test everything and then move to Production in a few weeks. That’s a very logical way to order the world of Oracle ERP. But unfortunately this is not a very practical or safe way. These patches are by their very nature too broad and silently hit too many areas to be open to a logical, standardized testing process. The conventional approach actually increases risk with these types of patches because it is by no means obvious what could be impacted.

There must be a better way where you find that balance. This is the Art of R12 Zen Patching.

Our philosophy is simple. We plan carefully on all these types of patches well ahead of applying.

We do not apply these patches immediately they come out. We are kind enough to give others the opportunity to be the heroes or unenlightened who find the bugs, log them in My Oracle Support and make our life so much simpler because we heavily research each patch to find the problems the unenlightened logged. This way we avoid the bulk of the problems. Are you one of the unenlightened? If so we appreciate you finding the bugs for us, causing issues for your users on Production systems and generally making our life so much easier and less stressful.

Our philosophy then rests correctly on a peace of mind that these patches are largely stable, largely trusted and tested by others around the world. This isn’t just a philosophy, it’s backed up by hard facts based on an incredibly low failure rate of patches we have applied. The patch types listed are generally very mature, very stable and very reliable. The quality of these types of patches is far higher than the Oracle ERP patches for the application modules.

Our key philosophy can be defined by the koan below. (As you raise a smile, remember this is used in leadership teaching by guys that make more in a month than you make in 5 years and sell books by the truckload at Amazon 🙂

“Once upon a time in ancient Japan, a young man was studying martial arts under a famous teacher. Every day the young man would practice in a courtyard along with the other students. One day, as the master watched, he could see that the other students were consistently interfering with the young man’s technique. Sensing the student’s frustration, the master approached the student and tapped him on the shoulder. “What is wrong?” inquired the teacher. “I cannot execute my technique and I do not understand why,” replied the student. “This is because you do not understand harmony. Please follow me,” said the master. Leaving the practice hall, the master and student walked a short distance into the woods until they came upon a stream. After standing silently beside the streambed for a few minutes, the master spoke. “Look at the water,” he instructed. “It does not slam into the rocks and stop out of frustration, but instead flows around them and continues down the stream. Become like the water and you will understand harmony.” Soon, the student learned to move and flow like the stream, and none of the other students could keep him from executing his techniques” – Timothy H. Warneka

Now I’m not into all this stuff and I’m as skeptical as anyone else, but maybe they have a point. Too many companies are simply slamming into the rocks with patches, rather than working with the flow of Oracle Corporation. Working with Oracle, you often feel that you are not talking of a stream but more a raging torrent of patches. The problem is you are always fighting against the flood of patches, rather than finding what these guys would refer to as “harmony”.

The very essence of our philosophy and the koan itself can now be answered 🙂

“We will test the patch by not testing the patch. Only then will we know that the patch has worked.”

After rolling the patch through DBA and Patch environments very carefully over many weeks, we are ready to proceed to our main development and testing environments.

We typically roll patches into our development environment for a minimum of 4 weeks. We observe the behavior of the environment and record any bugs. We carefully investigate all bug occurrences.

Once we are comfortable at that point, we do run testing. OK so we broke our mantra, but nowhere near the testing that would normally be required. Why? Because we have seen the bugs naturally arise through our normal daily activity (as a Project Manager you’ll know typically what is going on and where the gaps may be I would hope). So to quote the Art of Zen,” the appropriate insight and response arises naturally.” This is the beauty of the Art of Zen Patching 🙂 You do your daily stuff to get to the answer of whether the patch causes major grief.

At this point we normally release the patches to our Test Instance, again allowing patches to settle for 4-8 weeks. Again using normal user activity, we gain further appropriate insight and responses, in terms of stability of the patch and subsequent bugs, arising from the natural process of user activity.

We do ask our users to test and hit the key functionality, but again, with the insight given from normal daily use, we have achieved ” the appropriate insight and response which arises naturally” as a Zen Master or Leadership or Lifestyle coach would tell you for quite a lot of cash 🙂

Even our DBA Team reaches a relaxed Zen like state and if you know your average DBA guys……… With planning comes time for our DBA Team to work and document carefully the steps needed for each patch. The timeframes create space for many, many practice runs, so that on the day of application to Production, they know exactly what to do and what to expect. It also creates the space and time for good old fashioned research on My Oracle Support. (A tip is that as we’re doing this approach over a number of months, the DBA’s always get copies of Production on a regular basis to run through the patching process, so any production specific issues are always encountered early).

In addition, we carefully plan for releases. So if you take our last security patches, these were rolled into an ATG RUP6 and a minor database point release (to stay supported). This reduces a constant patch cycle to a more manageable ITIL Release concept, reducing your workload overall. The raging torrent of patches becomes a much more manageable stream.

Most companies have huge stress over these types of patches. Most companies don’t even bother applying, much to the detriment in terms of support, future upgrades and security.

We are like every other company in many respects. We are highly conservative on applying patches. We like to stick on what we know.

But we do pay attention and plan for security, de-support of databases, new browser support in ATG RUP’s, etc in a very careful manner well ahead of time, allowing us to practice the Art of Zen Patching 🙂

Companies stress out, rush patches and therefore make mistakes. That is not the Art of Zen Patching. Zen Patching stresses the very opposite approach. Put the patch into your environments, slowly observe and watch over many months, then test and finally you will see the appropriate insight and responses that it has worked. Now looking at Wiki again, Monks meditate over many months or even years to answer a Koan. There is no difference in the approach of Zen Patching 🙂 The time the patches spend in your environments can be thought of as your meditation period over many months (typically 3-6 months depending on risk assessment) to find the answer to the koan of “how to test the patch without testing the patch to know the patch has worked”.

But with our R12 Zen Patching, we’ve reached an almost Zen like state 🙂 Patches are simply a natural part of the lifecycle of ERP. We have accepted that. They are planned and are allowed to settle for several months, to give insight into their nature and risk. Patches still require testing, but to a far lesser extent than a fully focused, high risk “lets test this patch and apply this patch in two weeks time”, which is similar to slamming into the rocks in the stream.

So where are we today with such an approach?

R12.0.4 RUP5 (yes this was a nightmare of testing the old fashioned way, definitely slamming into the rocks in the stream, but our go-live was incredibly smooth. Zen Patching doesn’t work here I’m afraid for those embarking on an R12 Upgrade. It’s the good old fashioned conventional testing approach that is needed here).

Security Patches to April 2010

ATG RUP6

11G and July Security Patches are currently under the Zen method as is a SUSE Linux Upgrade

We have never had a failure or serious outage as a result of Zen Patching (should I trademark this perhaps and make a lot of cash like those leadership guys??????), although as with all Oracle patches, it is a very serious business, with serious risks, so there is no place for complacency.

So what about the opinions of others on our ERP and how up to date we are overall with patches?  To quote one Senior Consultant DBA recently, we are way ahead of most companies in terms of patching, and have an “aggressive patching policy”.

I would say that the Art of Zen Patching can never be described with words like “aggressive” 🙂 . In fact it is quite the opposite. It is a very slow and considered process, stressing great patience, over many months, waiting for insight as a part of a natural process to reduce the risks we face, as the real Zen guys would put it 🙂

We simply achieve a lot more than most companies, with a lot less effort and a lot less risk. I think the Zen guys and leadership/lifestyle gurus would term it as “simply learning to move and flow with the Oracle stream creating harmony and peace of mind”. Obviously they’d be charging a thousand US Bucks an hour for this type of advice. (I remember we had one such IT Guru in our company. Cost us 6 figures for six weeks of work – we ended up using his laminated b*llshit as coffee mats……that was about the only value we got……). Now maybe the Consultant our company hired wasn’t too hot except for the coffee mats, but with some of these leadership and other philosophies, well maybe there’s something in it after all……

Call it Zen. Call it Lifestyle (or is it Patch) Management :-), but to have a safe, low risk and stress free approach to this type of patching which works with reduced effort (rather than increased effort) is  not a bad place to be, as an ERP Manager…….

Health Warning

This article was designed to present a very serious subject in a hopefully entertaining and educational manner utilizing both conventional approaches of testing, in conjunction with a more unconventional approach. However applying any patches on a Production Database is a very serious business. Patches do need testing and this should never be underestimated. However the point of this article is that by allowing patches to settle into various instances over time, you vastly increase the chances of spotting serious issues and vastly reduce the risk of issues in production that conventional testing can never address. This is the safest way to apply such patches that I have found, using a conventional testing approach, together with a far less conventional approach. 21st Century Testing meets 5th Century Zen Philosophy.

Disclaimer

(By the way, I haven’t been smoking anything….the intention of this article is to present a very serious subject – Oracle Patching – in hopefully what some will find a very funny and original manner, that can then be remembered and applied to help all of us that face the very serious risks of patching global ERP Systems, so don’ take all the Zen references for Patching too seriously………otherwise someone may think you’ve been smoking something………). Think Monty Python British humour as you read it……..

If you remember the article, change patching from a rush to a planned perspective and patch carefully over a period of months, then the article did it’s job 🙂

I hope you find it as funny to read as I did writing it 🙂