If the only requirement is to transfer the
FULL catalog from development to production, then a straight copy would be enough. Once requirements are more sophisiticated then 'runcat' gets it done efficiently.
Partial catalog change is the more likely situation with the catalog. A typical scenario:
1. Developers build requests and dashboards with final versions stored in the '/shared' subfolder, so for deployment purposes the '/users' subfolder on development might be ignored. Tag the <SOURCE> catalog, so newly created objects get a unique id.
- tag - gives each new object a unique id
- -appVersion - useful for tagging the new objects with the release number for which they're developed
- -patchSet - useful for tagging objects created for the specific instance of the release, after a round of defect fixing for example. This is less important.
- -skipFolder - allows you to ignore any objects created under the '/users' subfolder.
Tagging is an important activity, without it 'runcat' can only compare objects in different catalogs based on name (since no unique ID is present). 'Duplicate' objects appear after applying a patch, where objects have been renamed.
2. You've copied the newly tagged <SOURCE> version of the catalog to the <TARGET> and backed up the current <TARGET> catalog. Now you want to apply the differences between the two catalogs as a patch on the <CURRENT_TARGET>.
./runcat.sh -cmd diff -baseline <CURRENT_TARGET> -latest <SOURCE> -outputFile <DIFF_FILE> -skipFolder /users -verbosity detail
- diff - determines the differences between two catalog files
- -baseline - the currently deployed catalog, before the new changes are applied
- -latest - the new catalog with the latest changes from step 1
- -outputFile - file created with all the differences between the catalogs (except for explicit -skipFolder items)
- -skipFolder - again, no need to compare '/users' subfolder
- -verbosity - the detail is important here, especially if developers have made significant changes to compound objects, dashboard pages for example.
./runcat.sh -cmd createPatch -inputFile <DIFF_FILE> -outputFile <PATCH_FILE> -production <CURRENT_TARGET>
- createPatch - creates a patch to be applied
- -inputFile - uses the previously created <DIFF_FILE> as input
- -outputFile - creates an output file of patch 'instructions'
- -production - determines the catalog against which the patch will be applied
./runcat.sh -cmd applyPatch -inputFile <PATCH_FILE> -outputFile <PATCH_LOG> -persistNewApplicationRoles
- applyPatch - applies the patch to the <CURRENT_TARGET> catalog
- -inputFile - uses the previously created <PATCH_FILE> as input
- -outputFile - creates a log file output
- -persistNewApplicationRoles - forces newly created application roles to be persisted from the <SOURCE>. An optional tag, but important when development is used to build application security, 'Manage Privileges' for example.
3. Script all of these steps and you're 'automatically' patching the catalog with all the changes from development in under a minute (dependent on catalog size).
Finally, a couple of other points worth mentioning:
- archive / unarchive switches from 'runcat' are not used since they currently rely on permissions (therefore application roles) being the same between catalogs. It is also not possible to specifically archive the '/system' subfolder where privileges are stored (see previous post)*
- Oracle provided OBIA web catalogs will have tags in place. Think about tagging objects once you start creating your own. Tag objects from the outset if you're creating a catalog from scratch
- Working with Linux (OEL) just now, but these commands of course work with the windows version of the utility.
Hope this helps.
DR. OBI
*Functionality of these utilities may be subject to change in future releases.
