esterday, we saw how to go about patching
repositories so that the entire process of migration from development to
production can be automated. That patching process was basically an
extension of the 3 way merge process. In 10g, 3 way merging was
supported in Web Catalogs as well. I had blogged about it here.
But the biggest downside was, it had to be done very carefully as there
were chances of losing a lot of objects. In 11g, web catalog
incremental migration is supported with more granular control on how the
3 way merge happens.
Applying the Patch:
So
the process more or less is the same as the Repository Patching
process. To start with lets assume we have a webcatalog called
SampleAppBaseline which will be our baseline web catalog that is already
in production (SampleAppProd). Due to a change request, lets assume
following are the changes that were made to the SampleAppBaseline
webcatalog.
Lets look at the diff file to see what the contents are.
As
you see all the changes that were made to the web catalog have now come
into this diff file. Remember we can now control whether we want to
migrate the permissions as well from one web catalog to the other. Now
the next step is to create a patch file out of this diff file by
comparing the changes in the diff file with the production web catalog.
By
modifying the PRODUCTION webcatalog name in the patch file we can apply
multiple patches simultaneously to different web catalogs (like UAT,
PROD etc). To apply the patch we just need to fire the following command
If we now open the production web catalog we should now be seeing all the changes applied automatically. Remember to test this out completely in development before finalizing the scripts in production. I have seen instances(on my test sand box) where the patch files seem to somehow not pick up the changes automatically (had to enforce it through timestamp differences).
The high level architecture of the patching process for web catalogs is given below
Creating the Patch:
Applying the Patch:So
the process more or less is the same as the Repository Patching
process. To start with lets assume we have a webcatalog called
SampleAppBaseline which will be our baseline web catalog that is already
in production (SampleAppProd). Due to a change request, lets assume
following are the changes that were made to the SampleAppBaseline
webcatalog.
1. One report was deleted – A report called ChartZoom has been deleted
2. One report was modified – A report called Filters has been modified
3. One new report was created – A report called SampleSales has been created
2. One report was modified – A report called Filters has been modified
3. One new report was created – A report called SampleSales has been created
The name of this new web catalog is
SampleAppChanged. Web Catalog patching is done through the Catalog
Manager command line options. In 10g this was not documented as shown here.
In 11g, we have much more comprehensive set of options that makes
scripting catalog manager related tasks a lot easier. So we start with
first creating the diff file using the following command
./runcat.sh -cmd diff -baseline /home/oracle/SampleAppBaseline -latest /home/oracle/SampleAppChanged -outputFile /home/oracle/SampleAppDiff.txt -folder /shared -verbosity detail
Lets look at the diff file to see what the contents are.
As
you see all the changes that were made to the web catalog have now come
into this diff file. Remember we can now control whether we want to
migrate the permissions as well from one web catalog to the other. Now
the next step is to create a patch file out of this diff file by
comparing the changes in the diff file with the production web catalog../runcat.sh -cmd createPatch -inputFile /home/oracle/SampleAppDiff.txt -outputFile /home/oracle/SampleAppPatch.txt -production /home/oracle/SampleAppProd
If we look at the patch file, it will look
similar to the diff file. Basically this provides us with an opportunity
to pick & choose the changes that we want to apply in to the
production web catalog (through command line options)
By
modifying the PRODUCTION webcatalog name in the patch file we can apply
multiple patches simultaneously to different web catalogs (like UAT,
PROD etc). To apply the patch we just need to fire the following command./runcat.sh -cmd applyPatch -inputFile /home/oracle/SampleAppPatch.txt -outputFile /home/oracle/SampleAppPatched.txt
If we now open the production web catalog we should now be seeing all the changes applied automatically. Remember to test this out completely in development before finalizing the scripts in production. I have seen instances(on my test sand box) where the patch files seem to somehow not pick up the changes automatically (had to enforce it through timestamp differences).
No comments:
Post a Comment