Migrating Discoverer EULs From Development To Production

I was with a client this week who had an issue with migrating Discoverer End User Layers from one environment to another. He would make some changes in the development EUL, then import the changed business areas into the test EUL, but often he'd get multiple copies of folders, items and hierarchies, and every once in a while a worksheet would refuse to run as a certain join could not be found.

From speaking to the client, the process he went through to migrate an EUL was as follows:

1. Firstly, he'd use the Discoverer Administrator Export feature to export an ".eex" file containing one or more business areas
2. Next, he'd log on to his target EUL, and then use the Import Wizard to select the .eex file he'd created.
3. Then, he'd import in the .eex file using the default settings :

and proceed with the import.

What happened then is that the Import Wizard would create an additional folder for each imported one that already existing in the EUL, giving it the name "Customers1" if for example the original folder name was "Customers". In addition, the Import Wizard would create additional copies of any hierarchies that were imported but already existed in the EUL, which after a while led to a situation where multiple copies of folders, items and hierarchies existed for each import that had taken place.

The next step the client took was to do the export as before, but this time manually delete any business areas from the target EUL before importing in the .eex file. Whilst this got round the problem of creating multiple incarnations of folders and hierarchies, the problem now was that certain worksheets, when opened, complained that joins could not be found and had to be recreated before they could be used.

I'd heard of this problem before but also knew that there was a recommended way to migrate EULs from one environment to another without these problems occurring. The first step therefore was to take a look on metalink, and I quickly came across note 62513.1 entitled "Migrating a Discoverer Environment Between Two Databases" which looks at both migrating whole EUL and in our instance migrating individual business areas. I also had a word with Michael Armstrong-Smith, who's a regular contributor to the OTN Discoverer Forum and is the author behind the forthcoming Oracle Press Discoverer Handbook, Second Edition. Michael's advice on this process was:

"When importing data into the Admin edition, a user will be presented with a dialog box called Import Wizard Step 2. Step 1 is where the user names the EEX file to be imported. In step 2 of the wizard the use has to answer certain questions. These are:

• if two object match what action should occur?
  
  I would normally select the fourth option - Refresh the object and then check the sub-box called Preserve display related properties
   
• How should two objects be matched up?
  If I am confident that my EULs were in sync before I changed one of them, I would always go by Identifier. However, if I have manually changed any of my identifiers then I would have no choice but to select By Display Name. There is an issue here in that if the user has changed the display name and inadvertently changed the identifier as well, Discoverer will be unable to confirm that this import does in fact contain a change and it will create a new business area. It is very important therefore that users do not change both identifiers and display names at the same time!
   
• Should the current user take ownership of imported workbooks?
  I would normally set this to Only take ownership if original owner cannot be found."

What this does then is use the contents of the .eex file to refresh existing folders (and their items) if they exist already, and create new folders if they don't currently exist in the target EUL. It matches the folders by identifier, which in most cases should match up, and only changes ownership of the workbooks if the the original owner doesn't have an account on the target database. The only change I'd make to Michael's approach is to uncheck the "Preserve display related properties" checkbox as otherwise any changes you've made to object names (folders, items etc) won't be brought through when you refresh the business areas.

Thanks to Michael for his help with this topic.