1

To

ut

ce

qu

'il f

au

t sa

vo

ir a

va

nt

de

pa

sse

r à

SA

P B

I 4

.2 (

ou

à t

ou

te a

utr

e v

ers

ion

de

S

AP

Bu

sin

ess O

bje

cts

)

Tout ce qu'il faut savoir avant de passer à SAP BI4.2

(ou à toute autre version de SAP BusinessObjects)

Depuis 2001, mon mari et moi avons déménagé à 5 reprises. A chaque fois, nous avons rempli

une énorme malle d'à peu près 1,50m de long sur 60cm de haut. Celle-ci était évidemment très

lourde et difficile à refermer. J'ignorais totalement ce qu'elle contenait, mais d'après mon mari, il

s'agissait de "choses importantes" qu'il voulait garder. Nous avons donc payé 5 fois le

déménagement de cette malle pour ensuite la ranger et l'oublier. Elle finissait en effet à la cave

ou dans le garage de chaque maison que nous avons occupée. Je n'ai jamais posé de questions

jusqu'au dernier déménagement, lorsque la malle a fini dans le bureau. Elle traînait dans le

passage, et je ne voulais plus l'y voir ! De l'aveu même de mon mari, la clé avait été perdue et je

pense qu'il ne se souvenait plus non plus du contenu de cette malle. Après avoir insisté pendant

une semaine, j'ai réussi à lui faire cisailler le cadenas. C'est ainsi que nous avons retrouvé les livres

de cours datant de quand il était étudiant ... il y a 20 ans ... que de vieilleries !

Vous vous demandez peut-être pourquoi je vous raconte tout cela et quel rapport cette histoire

peut bien avoir avec les migrations Business Objects. Cette malle et les déménagements me

rappellent la manière dont j'ai été amenée à faire les mises à niveau Business Objects au fil des

ans. Nous avons migré le contenu d'une version de Business Objects à l'autre sans savoir si nous

étions en train de travailler sur du contenu inutilisé ou obsolète. Nous n'avions aucune vision

d'ensemble de ce qui était réellement utilisé et donc, nous ne voulions pas courir le risque de

supprimer des rapports ou des objets utilisés par les utilisateurs finaux. Résultat : nous avons tout

migré. C'est exactement ce qui se passait lorsque nous déménagions une malle pleine de vieux

livres de maison en maison. Si j'avais su ce qu'elle contenait, j'aurais envoyé les livres au recyclage

ou les aurais donnés avant même le premier déménagement !

J'ai été administratrice Business Objects chez un client pendant 10 ans. Et pendant tout ce temps,

j'ai effectué des migrations vers les nouvelles versions de Business Objects depuis la version 5. Les

migrations ont eu lieu de v5 à 6.5, 6.5 à XI, XI à XIR2, XIR2 à XI3.1 et enfin de XI3.1 à BI4.1.

L'environnement était fortement exploité (usage ad hoc), avec pour conséquence, au fil du

temps, un nombre toujours plus important de rapports dans les dossiers personnels des utilisateurs.

Bien entendu, ceci signifiait un référentiel toujours plus gourmand en stockage et ça allongeait

également le temps nécessaire aux migrations. A chaque mise à niveau vers une nouvelle version

de Business Objects, nous nous efforcions de trouver des moyens d'amener les utilisateurs à

nettoyer leurs dossiers personnels. Cette question a été soulevée dans un blog traitant de la

sauvegarde et de la restauration BO (cas 5)

Au cours de l'une des mises à niveau (de 6.5 à XI, il me semble), nous avons décidé de ne migrer

aucun dossier personnel. A la place, nous avons demandé aux utilisateurs d'envoyer les rapports

qu'ils souhaitaient conserver dans la boite de réception de l'administrateur. Chaque jour, le

nombre de documents reçus augmentait sensiblement. Et puis un jour, nous nous sommes

2

To

ut

ce

qu

'il f

au

t sa

vo

ir a

va

nt

de

pa

sse

r à

SA

P B

I 4

.2 (

ou

à t

ou

te a

utr

e v

ers

ion

de

S

AP

Bu

sin

ess O

bje

cts

)

aperçus que tous les rapports avaient disparu, comme si la boite de réception de l'administrateur

s'était vidée. Plusieurs heures de recherches et un ticket de support Business Objects plus tard,

nous avons compris ce qui s'était passé : le nombre de documents dans la boite de réception

dépassait le maximum de 1 000 défini dans la configuration BO. Par conséquent, ils ne

s'affichaient plus. En fin de compte, les documents étaient toujours bien là, mais ils ne s'affichaient

simplement plus. Nous avons réussi la migration, mais nous n'avons plus jamais procédé de cette

façon par la suite ! A chaque mise à niveau suivante, nous avons donc insisté pour que les

utilisateurs suppriment leurs documents inutilisés, sans savoir s'ils nous avaient écouté ou non. Nous

avons donc tout migré en bloc.

Lorsque vous déménagez, vous mettez en général de côté les choses que vous ne souhaitez pas

garder. J'avais donc l'habitude de séparer d'un côté ce que je voulais donner, et de l'autre, tout

ce qui devait être jeté. Il y a toujours quelque chose que l'on ne veut pas emporter. Ainsi,

déménager offre une occasion parfaite de faire le tri ! Il en va de même lorsque l'on migre d'une

version de Business Objects à l'autre ; c'est le moment idéal pour faire un grand nettoyage !

Les 10 étapes que nous vous recommandons de suivre pour simplifier la migration vers BI4.2 sont

présentées ici :

Ce document détaille la procédure de nettoyage avant migration.

Migrez-vous l'intégralité de votre contenu d'une version de Business Objects à l'autre ? Les

migrations monopolisent-elles du temps et des ressources pour le traitement de contenu inutilisé,

obsolète ou redondant ? Avez-vous constamment besoin d'étendre l'espace de stockage sur

vos serveurs au fur et à mesure de l'évolution de vos environnements ? Savez-vous vraiment ce

qui se passe sur votre plateforme ?

3

To

ut

ce

qu

'il f

au

t sa

vo

ir a

va

nt

de

pa

sse

r à

SA

P B

I 4

.2 (

ou

à t

ou

te a

utr

e v

ers

ion

de

S

AP

Bu

sin

ess O

bje

cts

)

Avez-vous les réponses à toutes ces questions ?

• Au cours de l'année passée, voire des 2 dernières années, quels sont les rapports n'ayant

jamais été utilisés ?

• Quels sont les objets d'univers inutilisés dans aucun rapport existant dans votre

environnement ?

• Quel type de contenu consomme le plus d'espace dans le CMS ? Les boites de

réception ? Les instances ? Les dossiers publics ? Ou les dossiers personnels ?

Ne voudriez-vous pas cartographier votre environnement afin de déterminer exactement ce

qu’il faut conserver ? La suppression du contenu inutilisé et obsolète avant migration réduirait

donc considérablement la durée du processus et la quantité d'espace de stockage nécessaire

sur le serveur BO. Les audits Business Objects fournissent certaines informations, mais celles-ci sont

limitées aux détails concernant le contenu auquel les utilisateurs ont accédé. Par exemple, si un

rapport donné n'a jamais été généré, ou qu'un objet existant n'a jamais été utilisé, celui-ci

n'apparaîtra dans aucun rapport d'audit.

360Suite permet d'obtenir les informations manquantes pour une gestion optimale des

environnements SAP BusinessObjects. 360Eyes, l'un des composants de 360Suite, fournit un très

grand nombre de détails apportant toutes les réponses aux questions que vous pourriez avoir

concernant vos environnements. Concernant les limitations d'audit évoquées ci-dessus, 360Eyes

résout ce problème en récupérant les données depuis le CMS et Auditor. Les données sont

rassemblées dans une base de données unique, créant ainsi le lien auparavant manquant.

360Eyes est fourni avec 4 univers et 40 rapports Webi directement utilisables. Vous pouvez

immédiatement procéder à l'analyse de votre environnement et générer des rapports

personnalisés. A l'avenir, vous allez vous demander comment il était même possible de procéder

à une migration sans ces informations !

4

To

ut

ce

qu

'il f

au

t sa

vo

ir a

va

nt

de

pa

sse

r à

SA

P B

I 4

.2 (

ou

à t

ou

te a

utr

e v

ers

ion

de

S

AP

Bu

sin

ess O

bje

cts

)

Grâce à 360Eyes :

• Déterminez le contenu inutilisé (objets d'univers, rapports, utilisateurs, etc.).

• Comparez plusieurs environnements et versions en cours de migration.

• Analysez et nettoyez les univers UNV avant conversion au format UNX.

• Optimisez les structures des rapports avant conversion en déterminant les objets et

variables inutilisés.

• Effectuez des analyses d’impact : Déterminez quels sont les rapports contenant des objets

d’univers données, une table ou un champ d’une table, ou même une fonction Business

Objects (par exemple Somme).

• Détectez les doublons et identifiez les mêmes documents présents dans plusieurs dossiers

de l'environnement.

• Comparez les paramètres de sécurité entre versions et repérez les changements survenus

en cours de migration.

• Documentez le contenu des environnements (documents, univers et sécurité).

• Et bien plus encore !

Le manque de visibilité entraine pertes de temps et d'argent, ainsi que des coûts de stockage

plus élevés. N'avancez plus à l'aveuglette lors des migrations Business Objects : 360Eyes vous

apporte toutes les informations dont vous avez besoin pour exécuter sereinement ces opérations

de maintenance.

Pour davantage d’informations :

http://www.gbandsmith.com/fr/solutions-sap-businessobjects/auditez-et-analysez/