Rittman Mead - Delivered Intelligence

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.

Posted in Oracle Discoverer |