Parallel BOXI3.1 and BI4.1 environments

[Former Member]

We are planning an upgrade from BOXI3.1 to BI4.1 and have a few thousand objects to migrate.  So a big bang migration is out the question and we'll migrate in "chunks", running parallel 3.1 and 4.1 environments.

I guess there is a danger (albeit a small one) that we'll create a new object in the 3.1 system that will be given a UID that is identical to one of the UIDs created in the 4.1 system.  This would cause a problem when we come to migrate that new object across to 4.1.

Is there any way of preventing this happening?

Does the migration tool look out for this issue and fix it (perhaps by reassigning the UID at point of migration)?

[former_member185603 · Accepted solution]

UID is unique. So there is no way both will match when you create new content in either environment. Only when you promote, source and destination CUIDs will be same.

[Former Member · Accepted solution]

Hi Jawahar,

Thanks for your answer.

Will the UID still be unique if we are talking about two sets of UIDs on two entirely separate servers?

If so, then how does it manage to do achieve that?

Thanks

Tristan

[denis_konovalov · Accepted solution]

first of all - there is no such thing as UID in BOE (Xi3.1 or BI4.x).

All objects have 2 id's - CUID and SI_ID.

SI_ID unique in any given cluster and CUID just simply unique.

When you migrate/promote objects from 3.1 to 4.x or within different BI4.x systems that object maintains its CUID, but will have new SI_ID in each new system.

chances that you have same CUID created in 2 different systems are non-existent.

[Former Member · Accepted solution]

Thanks Denis - extremely helpful. 

May I just ask for an elaboration on your term "non-existent"

So I'm guessing that the CUID is randomly/pseudo-randomly generated and of sufficient length that, whilst theoretically possible that two identical ones could be created, it's statistically not worth worrying about.  Is that correct?

Sorry to be so precise - I'm a good consultant and want to highlight all risks (albeit practically non-existent ones) to my customer.  Sure you understand

[denis_konovalov · Accepted solution]

Yes to your guess. Exact nature of the mechanism on how CUID is created is not available.
Since the time CUID's were introduced SAP is not aware of instances where 2 same strings were created in 2 different systems.

[Former Member]

Hi Tristan,

Back to your original question "planning an upgrade from BOXI3.1 to BI4.1 and have a few thousand objects to migrate.  So a big bang migration is out the question and we'll migrate in "chunks" "

How many objects you are talking about here?

If you have good configured systems for 4.x then migrating all together is definitely not an issue. I've migrated 50k plus objects in one go (it failed in between due to some common UMT issues but then VOILA!)

I've migrated from 3.1 SP5 to 4.1 SP2 with roughly 8k users, 200 folders, 50 universes, 10k plus reports, etc etc...

We also had both systems running in parallel back then, but some or the other day you need think of planning a freeze on development on 3.1 till then you can migrate/ promote 5 - 10 odd reports weekly or monthly from 3.1 to 4.x.

But, in my experience, one shot migration is wise than putting in multiple phases.

See if this helps.

Reg,

NK

[János_at_SAP]

Hello,

If you change/develop new reports on XI 3.1 you can still do an incrementation uprgade BOXI3.1 to BI4.1. The Incremental upgrades allow you to migrate individual objects to a destination deployment, since are identified as a problematic objects during the migration.

Useful links :

How to Upgrade to BI4.0 - Business Intelligence (BusinessObjects) - SCN Wiki

also a good KBA about promotion.

1969259 - LCM CLI Master Note - How to promote thousands of objects
across BI4 environments ?

I hope it is directs you into a good direction.

Regards

János

[Former Member]

Thanks Janos,

So I understand that the incremental upgrade allows me to migrate object by object if I wish.  That's good, but here's my exact scenario:

1. In my XI 3.1 system I create a Webi called "Sales Order Report" that the system assigns the UID ABC1234
2. In my BI 4.1 system I create a Webi called "Profit and Loss" that the systems assigns the same UID - ABC1234
3. I run the migration program to bring across "Sales Order Report" from XI 3.1 to BI 4.1

What will happen out of the following three?

1. Will the migration program error because the UID already exists? 
2. Will "Sales Order Report" overwrite "Profit and Loss"?
3. Will the migration program realise what's happening and give "Sales Order Report" a new UID (say DEF5678) to resolve the issue?

Hope the issue makes sense.  Thanks for your help.

[Matthew_Shaw]

Hello Tristan

The BI Platform (any version) will never assign a CUID that is used in any other system, even if the object is created at the same time, has the same type and has the same name.

Why? Because the CUID is a very large number and is made up of many aspects including: machine name, cluster name, date, time and a random number too.  In other words the CUID for an object is completely unique to that system. (well unless you promote it to other systems of course).

It is important you create the object only in 1 place and then promote it to the other locations. This is particularly important for 'parent' objects such as: folders, universes, connections, publications etc. It is important for these 'parent' objects as their child will be associated to them by their CUID. If the CUID does not match (but the name does match) the object will not promote.

I hope this helps, regards, Matthew

[Former Member]

Thanks Matthew.  One last question - does the migration program carry across the CUID of the object from the originating system into the target or does it assign a new CUID (in order to include the correct system name, creation time/ date etc)?

[Matthew_Shaw]

With BI4:

When you promote any object (using the Upgrade Management Tool, or Promotion Management, including the LCM Command Line) the CUID (Cluster Unique Identifier) will remain the same.

When the object is promoted the object it is going to 'update' is identified by the CUID. It is not identified by its name (this is why you can not, create two folders of the same name in two different systems and expect objects held within them to be promoted from one to the other).

The system will compare the CUID in the source with the CUID in the target. NOT the name.

If the CUID in the target already exists then it will attempt to update the object (overwriting it) and it will attempt to update its content. This may also include updating the objects' name. However if updating the objects' name will cause a name clash, then the object will not be updated (it will fail to be promoted).  A name clash is possible if another object, of the same type and held in the same container (folder, group) has the same name as the source object.

The system will NEVER re-assign a CUID as you mention, the CUID always remains the same.

(I hope this last bit doesn't confuse: An object has a number of properties, a name and a CUID are two, But it also has an 'ID'. The 'ID' is used by the system for 'day-to-day' operations. You can see this in HTTP logs, for example when you open a document, it will refer to the documents ID and not its CUID.  Why? ID's are shorter and so perform so much better. The IDs, unlike CUIDs, do change from one system to another and the product will re-assign IDs as required. If you refer to an objects ID in one system it will almost certainly have a different ID if it is promoted into another. Both IDs and CUIDs can not be manually assigned, they are both system assigned properties.)