http://www.obieefans.com/create-environment-patch-environmentalization/
Create Environment Patch (Environmentalization)
Posted by root on 27 March, 2012No comments yetThis item was filled under [ OBIEE MISC ]
During RPD migrations we constantly need to change metadata for the target environment such as physical connection pool(s) and LDAP source(s). To do this manually is time consuming and open for error. Thus, there needs to be a way to script or automate this process. This document will address the automated solution using what is termed in OBI as the patching process.
The first migration from Dev->Test, Dev->Prod, or source->target will need to be done manually. Meaning, the RPD that is ready to be migrated to the target environment will need to have its physical connections and LDAP source(s) manually changed for that target environment. That would be done using the BI Admin Tool in offline mode. After which, we can test our changes to ensure that the connections and information we entered is correct. Then we can create the patch that will be used for later migrations of the RPD.
The following steps will be done after any manual changes needed for the target version of the RPD (this includes the first migration to the target environment), so that we can capture the patch XML to be used for later migrations. We will need to follow these steps after any and all manual environment changes that are needed for the target environment, such as the initial migration or password or server changes.
1.Open up the target version of the RPD in offline mode. (In my example, I open up the Production version of the RPD after I made the manual environmental changes).
2.Select File->Compare…
3.Browse and locate the development RPD that was used to create the production version, prior to the manual changes. (This RPD should be exactly the same as the opened RPD except that the conn pools, LDAP sources are changed for the target environment)
4.Enter the selected RPD’s password
5.Click Create Patch…
6.Browse to folder and name patch xml file. Click Save. ( I try to use a patch folder within a migration folder. Also I try to use a standard naming convention for the patch file. For my example, I put in patch folder and named the xml bipatch_env_to_prod.xml.
Now you have your patch for just the changes needed for environmentalizing an RPD to the target environment. Looking at the patch xml I created you will see and should see just the following:
As you can see I have changed 2 connection pools and I highlighted the changes I did in the admin tool for the target prod env. You should only see those RPD objects for which you made environmental changes, as the rest of the RPD should be the same as the dev (or source) RPD which you based the target RPD for migration.
Now the next steps detail using this patch xml in subsequent migrations. This patch xml will be used in a script that will automate the environmentalization of the rpd. I like to make a folder structure like the following:
/migration – This folder holds everything related to migrations including the .bat script used to environmentalize stage RPDs to target_ready
/stage – This will hold the RPD(s) ready for migration
/patch – This holds the patch files
/target_ready
/test – Folder for test ready RPDs to be uploaded to test
/prod – Folder for prod ready RPDs to be uploaded to prod
To script the environmentalization, I use the xml API biserverxmlexec. This API executes the XML in offline mode to create or modify a repository file. It can be found in MIDDLEWARE_HOME\Oracle_BI1\bifoundation\server\bin. The following example modifies the rp_dev.rpd and writes to rp_prod.rpd:
biserverxmlexec -I bipatch_env_to_prod.xml -B .\rp_dev.rpd -O c:\…\target_ready\prod\rp_prod.rpd. You will be prompted for the password of the rp_dev.rpd. Give password: my_rpd_password
The newly created RPD is now ready to be migrated. We now just need to upload the repository into the target (production in my example) environment using the FMC (aka Enterprise manager) upload process.
Now I would make a .bat (or .sh for UNIX/LINUX) file, which would call this biserverxmlexec API command and maybe include the base repository password so that I would not be prompted. This is up to the individual. If done so, this process is just a quick execution of the script and the new environmentalized RPD would be sitting and ready in the target_ready folder. Now I always double check the created RPD just to make sure the script did what it was supposed to. But there really should not be a need as it does the same thing every time.
Create Environment Patch (Environmentalization)
Posted by root on 27 March, 2012No comments yetThis item was filled under [ OBIEE MISC ]
During RPD migrations we constantly need to change metadata for the target environment such as physical connection pool(s) and LDAP source(s). To do this manually is time consuming and open for error. Thus, there needs to be a way to script or automate this process. This document will address the automated solution using what is termed in OBI as the patching process.
The first migration from Dev->Test, Dev->Prod, or source->target will need to be done manually. Meaning, the RPD that is ready to be migrated to the target environment will need to have its physical connections and LDAP source(s) manually changed for that target environment. That would be done using the BI Admin Tool in offline mode. After which, we can test our changes to ensure that the connections and information we entered is correct. Then we can create the patch that will be used for later migrations of the RPD.
The following steps will be done after any manual changes needed for the target version of the RPD (this includes the first migration to the target environment), so that we can capture the patch XML to be used for later migrations. We will need to follow these steps after any and all manual environment changes that are needed for the target environment, such as the initial migration or password or server changes.
1.Open up the target version of the RPD in offline mode. (In my example, I open up the Production version of the RPD after I made the manual environmental changes).
2.Select File->Compare…
3.Browse and locate the development RPD that was used to create the production version, prior to the manual changes. (This RPD should be exactly the same as the opened RPD except that the conn pools, LDAP sources are changed for the target environment)
4.Enter the selected RPD’s password
5.Click Create Patch…
6.Browse to folder and name patch xml file. Click Save. ( I try to use a patch folder within a migration folder. Also I try to use a standard naming convention for the patch file. For my example, I put in patch folder and named the xml bipatch_env_to_prod.xml.
Now you have your patch for just the changes needed for environmentalizing an RPD to the target environment. Looking at the patch xml I created you will see and should see just the following:
As you can see I have changed 2 connection pools and I highlighted the changes I did in the admin tool for the target prod env. You should only see those RPD objects for which you made environmental changes, as the rest of the RPD should be the same as the dev (or source) RPD which you based the target RPD for migration.
Now the next steps detail using this patch xml in subsequent migrations. This patch xml will be used in a script that will automate the environmentalization of the rpd. I like to make a folder structure like the following:
/migration – This folder holds everything related to migrations including the .bat script used to environmentalize stage RPDs to target_ready
/stage – This will hold the RPD(s) ready for migration
/patch – This holds the patch files
/target_ready
/test – Folder for test ready RPDs to be uploaded to test
/prod – Folder for prod ready RPDs to be uploaded to prod
To script the environmentalization, I use the xml API biserverxmlexec. This API executes the XML in offline mode to create or modify a repository file. It can be found in MIDDLEWARE_HOME\Oracle_BI1\bifoundation\server\bin. The following example modifies the rp_dev.rpd and writes to rp_prod.rpd:
biserverxmlexec -I bipatch_env_to_prod.xml -B .\rp_dev.rpd -O c:\…\target_ready\prod\rp_prod.rpd. You will be prompted for the password of the rp_dev.rpd. Give password: my_rpd_password
The newly created RPD is now ready to be migrated. We now just need to upload the repository into the target (production in my example) environment using the FMC (aka Enterprise manager) upload process.
Now I would make a .bat (or .sh for UNIX/LINUX) file, which would call this biserverxmlexec API command and maybe include the base repository password so that I would not be prompted. This is up to the individual. If done so, this process is just a quick execution of the script and the new environmentalized RPD would be sitting and ready in the target_ready folder. Now I always double check the created RPD just to make sure the script did what it was supposed to. But there really should not be a need as it does the same thing every time.
Comments
Post a Comment