Les nouvelles versions de nos applications favorites ne supportent plus XP depuis longtemps. Certaines comme SAP BI bloquent l’installation des logiciels sur cette plateforme. Cependant en bidouillant un peu on arrive à passer outre cette interdiction.

La version utilisée ici est la plateforme SAP BusinessObjects BI 4.1 SP3. Installation des clients sur Windows XP pour rappel, 5.1 Professionnel pour être précis.

On récupère les binaires et on lance l’installation. L’assistant vérifie les prérequis et comme on est en XP il râle. Et on arrête là, impossible de continuer en cliquant sur le bouton Suivant.

Pour déjouer cette vérification il faut modifier le fichier product.seed.xml qui se trouve dans l’arborescence du programme d’installation. Chez moi il se trouve dans le dossier (dossier_d’install)/SBOP_BI_PLAT_4.1_SP3_CLNT_WIN_32_64B_\DATA_UNITS\BusinessObjectsClient\dunit\product.businessobjectsclient-4.0-core-32.

Avec un bon éditeur de texte comme Notepad++ (car le fichier est au format UNIX) il faut modifier la section :

  <prerequisite id="getWindowsVersionPreReq" description="#prereq.WindowsVersionPreReqText#" reason="#prereq.WindowsVersionPreReqNotOkText#" type="error">
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="6.1"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="Windows7Above"/>
      <arg name="AllowedSuffix" value="WORKSTATION"/>
    </action>
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="6.2"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="Windows8Above"/>
      <arg name="AllowedSuffix" value="WORKSTATION"/>
    </action>
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="6.0"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="Windows2008Above"/>
      <arg name="AllowedSuffix" value="Server"/>
    </action>
    <condition>
      <or>
        <condition property="Windows2008Above" value="1"/>
        <condition property="Windows8Above" value="1"/>
        <condition>
          <and>
            <condition property="Windows7Above" value="1"/>
            <not>
              <condition property="$os.servicepack" value="0"/>
            </not>
          </and>
        </condition>
      </or>
    </condition>
  </prerequisite>  

Pour qu’elle ressemble à :

  <prerequisite id="getWindowsVersionPreReq" description="#prereq.WindowsVersionPreReqText#" reason="#prereq.WindowsVersionPreReqNotOkText#" type="error">
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="6.1"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="Windows7Above"/>
      <arg name="AllowedSuffix" value="WORKSTATION"/>
    </action>
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="6.2"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="Windows8Above"/>
      <arg name="AllowedSuffix" value="WORKSTATION"/>
    </action>
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="6.0"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="Windows2008Above"/>
      <arg name="AllowedSuffix" value="Server"/>
    </action>
    <action id="CompareVersion">
      <arg name="maxVersion" value=""/>
      <arg name="minVersion" value="5.1"/>
      <arg name="VersionNeedToCompare" value="[$os.version]"/>
      <arg name="Property" value="WindowsXPAbove"/>
      <arg name="AllowedSuffix" value="WORKSTATION"/>
    </action>
    <condition>
      <or>
        <condition property="Windows2008Above" value="1"/>
        <condition property="Windows8Above" value="1"/>
        <condition property="WindowsXPAbove" value="1"/>
        <condition>
          <and>
            <condition property="Windows7Above" value="1"/>
            <not>
              <condition property="$os.servicepack" value="0"/>
            </not>
          </and>
        </condition>
      </or>
    </condition>
  </prerequisite>

Après on relance l’installation et miracle ! Tous les prérequis sont vérifiés, même la version de Windows.

On peut alors passer à la suite…

Attention, cette installation n’est pas supportée par SAP. Mais ça peut dépanner

SAP fait son nettoyage de printemps dans son portefeuille BI.

On passe de 14 applications à 5 sur 4 thèmes différents ; on peut appeler ça le grand ménage !

Sans surprise il reste Business Objects et Crystal Reports. Et SAP va étoffer le petit nouveau Lumira pour qu’il puisse enfin être reconnu comme le Qlikview-Killer.

Il est vrai qu’on s’y perdait dans le portfolio. Certaines applications étaient très simples (comme Explorer) mais un peu limitées, d’autres étaient en doublon (Design Studio et Dashboards). Cette convergence des outils va simplifier la vision BI de SAP et le discours aux clients.

Source : SAP

Je livre ici mes remarques sur l’utilisation des 2 outils ( liste non exhaustive ) :
Version XI r2

Premier choc … l’interface … Plus structurée, mais aussi plus lente. On s’y perd.
Deuxième choc … les fonctionnalités … On ne retrouve plus ses petits, on râle, et peu après on trouve d’autres possibilités plus intéressantes …

Idée reçue dont il faut tordre le cou : Webi n’est pas Deski !
Ce n’est pas juste une interface web de Deski, c’est un outil à part entière.
Il utilise bien les univers BO, il affiche bien des tableaux comme deski, mais c’est tout !
Un utilisateur expérimenté du client lourd mettra un certain temps à faire le tour de webi.
On retrouve bien la base de BO, mais un temps d’adaptation sera nécessaire.

Avantages de webi :

1. l’ajustement automatique des cellules en largeur et hauteur
2. la fusion de cellules
3. on peut afficher facilement les sections vides
   Propriétés / Affichage / Afficher si vide
4. on peut afficher facilement les cellules vides
   Propriétés / Affichage / Afficher les lignes avec des valeurs de dimension vides
   Propriétés / Affichage / Afficher les lignes avec des valeurs d’indicateur vides
5. la coloration des lignes 1 sur 2
6. éditeur de filtres + ergonomique
   Sous deski par défaut on a juste le filtre sur une ou plusieurs valeurs
   Sinon il faut passer par le filtre complexe, qui repose sur une formule
   Sous webi les filtres ressemblent aux conditions de l’éditeur de requête, c’est plus simple.
7. la synchronisation des objets
   Là y’a pas à dire, c’est quand même bien plus simple en webi !
   Sous deski il fallait sélectionner les objets 1 à 1 pour vérifier s’ils étaient liés.
   Dans webi les objets sont présentés correctement dans une grille.
8. le palmarès peut se faire directement dans l’éditeur sql
   Cela optimise les requêtes, les temps de réponse et la volumétrie ramenée
9. l’ajustement des correspondances quand on change d’univers
   Quand on change d’univers sous Deski, les objets non retrouvés ( obsolètes ) sont supprimés
   Sous webi on peut sélectionner d’autres objets en correspondance.
10. un poids plus faible des documents webi, même en export pdf ( 50% ) !!!
11. l’éditeur de requêtes : les filtres prédéfinis sont affichés sous les objets, comme ça on ne peut plus dire qu’on ne savait pas que ça existait !!!
12. de nouveaux types de graphiques
13. des sous-requêtes plus simples à afficher, sans onglet supplémentaire

Avantages pour deski :

1. Mise en page – impression à une échelle
   Sous webi il faut jouer sur la taille de la police …
2. VBA / macros
3. le travail en offline
4. Masquer une cellule
   Sous webi il faut jouer à l’homme invisible, passer en fond blanc, écriture blanche …
5. Regroupement de valeurs
   Ca correspond juste à un Si([var] DansListe ( );; ) , mais ça manque …
6. les données personnelles ( fichier excel par ex )
7. SQL à la carte
   Il faut passer par des tables dérivées pour webi, il faut des fois rajouter un univers.
8. Les invites
   sous deski on peut réutiliser une invite facilement, l’outil propose la liste des invites
   sous webi il faut copier/coller le texte de l’invite
9. les images sont incorporées dans le document
   Dans webi les images sont sur un serveur web et il faut connaître leurs urls.
10. On a l’historique des exécutions des requêtes, en temps et en nombre de lignes
11. le tri dans les requêtes
12. les modèles
13. la liste de valeurs ( LOV ) d’un objet est affichée en une seule fois

Les différences :

1. l’interface : moins de fenêtres pour webi, toutes les propriétés sont regroupées à gauche.
2. l’éditeur de requêtes : les filtres prédéfinis et les objets sont mélangés
3. on a des requêtes et non des fournisseurs de données
4. les formules …
   On n’a que des fonctions sous webi, comme SI() au lieu de l’expression « si … alors »
   Certains y verront un avantage, on retrouve la syntaxe d’Excel, l’outil bureautique le plus prisé en entreprise.
   Par contre certaines formules nécessitent des crochets pour l’écriture de certains paramètres, comme les noms des requêtes.
5. des expressions différentes – par exemple l’opérateur « Pas égal à » remplace « Différent de »

Régressions et bugs de webi / deski :

1. si on change l’univers d’une requête, toutes les requêtes changent d’univers !!!

Là ça dépend …

1. l’installation
   Le déploiement web est plus facile, les connexions SGBD ne sont à définir que sur les serveurs. La mise à jour de BO est instantanée sur tous les clients. Mais il reste le problème de la version de java ( JVM ). Il est fréquent d’avoir plusieurs applis web qui n’utilisent pas la même JVM. Et là ça bloque !!!

Il y a bien évidemment d’autres différences, et les nouvelles versions de BO comme la XI3 et le rich-client comblent de plus en plus les lacunes qui jouaient en l’avantage de deski.

et 2 indicateurs :

la requête suivante est bonne :

Ainsi que :

Mais si on prend les 2 indicateurs les résultats sont faux :

car on a en SQL

select  
  count(distinct VENTES.client),  
  VENTES.montant
from VENTES
group by VENTES.montant

Comme quoi il faut être vigilant sur les normes mises en oeuvre sur un univers, et garder les mêmes règles pour tout indicateur. Si on utilise les fonctions d’agrégation sur un indicateur ( et cela inclut le count() ), il faut faire de même sur les autres.

Problématique :
On a un indicateur annuel, on connait un certain historique et on aimerait estimer les valeurs de cet indicateur dans le futur.

Exemple :

select * from test_regr

Ici on ajoute 2 à Y chaque année, donc on peut prévoir qu’en 2011 on aurait Y=10, en 2012 Y=12 etc …
Evidemment ici on a une suite logique, c’est un exemple parfait.

Dans la vraie vie ce n’est pas si facile, par exemple on aurait :

On n’a pas ici la même différence entre 2 années successives, On ne peut déduire la valeur de 2011 ou 2012 simplement.

Oracle propose des fonctions permettant de calculer une droite de régression. En résumé il s’agit d’établir une droite qui représenterait la courbe d’évolution de l’indicateur.

Séquence Nostalgie des cours de stats : La méthode s’appuie sur le calcul des moindres carrés, je ne vais pas rentrer dans les détails, d’autres le faisant mieux que moi comme sur wikipedia.

L’équation de cette droite est du type y= p x + y0, p étant la pente et y0 l’ordonnée à l’origine.
Sous Oracle la fonction REGR_SLOPE donne la pente, et REGR_INTERCEPT y0.
Une fois qu’on les a déterminés on peut estimer une valeur dans le futur en remplaçant x dans l’équation.

— ce qui donne avec l’exemple

with v as
  (   select 2010 annee, 8 y from dual
union select 2009, 6 from dual
union select 2008, 4 from dual
union select 2007, 2 from dual )
SELECT regr_slope( y, annee ) p, regr_intercept( y, annee ) y0 from v;
 
-- p=2 et y0=-4012

estimation pour 2011 :

ou en sql :

with v as
  (   select 2010 annee, 8 y from dual
union select 2009, 6 from dual
union select 2008, 4 from dual
union select 2007, 2 from dual )
SELECT regr_slope( y, annee )*2011 + regr_intercept( y, annee ) from v;

et le tout en one-shot :

with a as
  ( select to_char(sysdate,'YYYY') annee from dual union
    select to_char(add_months(sysdate,-12),'YYYY') annee from dual union
    select to_char(add_months(sysdate,-24),'YYYY') annee from dual union
    select to_char(add_months(sysdate,-36),'YYYY') annee from dual union
    select to_char(add_months(sysdate,+12),'YYYY') annee from dual union
    select to_char(add_months(sysdate,+24),'YYYY') annee from dual union
    select to_char(add_months(sysdate,+36),'YYYY') annee from dual
  ), v as
  (   select 2010 annee, 8 y from dual
union select 2009, 6 from dual
union select 2008, 4 from dual
union select 2007, 2 from dual )
select
  a.annee,  
  v.y  volume,  
  s.p * a.annee + s.y0 estim
from
  v,
  ( select regr_slope( y, annee ) p, regr_intercept( y, annee ) y0 from v ) s,
  a
where v.annee(+)=a.annee
order by a.annee;

Remarques :

• intuitivement on a une progression linéaire,
  ce qui veut dire que si on sortait le graphe on pourrait tracer une ligne droite pour représenter l’évolution de l’indicateur.
  Sinon les estimations ne donnent pas les bons résultats
• les fonctions regr sont des fonctions analytiques, on peut les utiliser comme telles avec la clause over( … )
  cela réduit le nombre de passages sur la table d’historique et peut jouer sur les performances

SOUS Business Objects :

On trouve bien les fonctions REGR_% dans l’éditeur des objets BO du designer

Mais les contraintes réduisent le champ d’action :

• on peut avoir des sum() en paramètre ( ex : regr_slope( sum( montant ), annee) ), mais la gestion est assez complexe, on mélange 2 fonctions d’agrégation et souvent cela pose problème car il manque une colonne dans le GROUP BY du select généré par BO.
  On oublie donc cela, et on a déjà des tables agrégées dans l’univers.
• quand on rajoute des dimensions ( dans l’éditeur SQL du rapport ) il faudrait les mettre dans la clause over(partition by (dimensions)) de la formule de l’objet dans Designer.
  Il faut donc être synchro entre l’éditeur de rapport et l’univers.
• il faut avoir des tables agrégées au grain de la dimension en x. Cela signifie qu’on doit avoir une seule valeur dans la table pour un x donné.

Par exemple si on a 10 opérations pour une année, on n’aura pas d’erreur mais les fonctions se feront sur une sorte de moyenne des indicateurs ( au lieu de la somme ).

Cela implique :

• il faut des tables agrégées au grain de la dimension en x. On peut s’en arranger avec des vues ou des tables dérivées qui font les sommes.
• il faut exactement les mêmes dimensions dans le fournisseur de données que celles utilisées pour les objets de régression.
• si on utilise d’autres objets la requête tombera en erreur
  Cela peut donc multiplier le nombre de tables et d’objets dans l’univers.
  Il est donc important de bien connaître les besoins au départ, de se limiter à ce périmètre et d’expliquer les contraintes aux utilisateurs finaux.

En conclusion l’implémentation des fonctions Oracle de régression dans BO pour établir un modèle prévisionnel est assez limitée.
Il faut définir l’état final et à partir de là définir les objets de l’univers en utilisant les fonctions regr_slope() et regr_intercept().
L’univers utilisé est un univers technique, on ne pourra créer facilement d’autres états prévisionnels à partir de celui-ci. Il faudra généralement à chaque fois créer de nouveaux objets.

La solution made in DBA consiste généralement à rajouter un hint, c’est à dire une petite ligne de code pour forcer le plan d’exécution.

Exemple :

SELECT /*+ FULL(SALES) */
  ...
FROM  
  SALES,  
  ....
-- ici on ne passe par les index, on lit la table complètement

Pour coder ce hint dans Business Objects, on peut :

• modifier le sql généré
  C’est dommage, on perd la fonctionnalité de sql dynamique de BO, avec tous les inconvénients que cela engendre : maintenance difficile, désynchronisation de la requête avec l’univers.
• modifier la propriété hint de la connexion.
  Mais toutes les requêtes seront impactées, ou il faut créer une nouvelle connexion.
• créer un nouvel objet

Cette dernière solution est à privilégier.
Il suffit de créer un objet technique pointant sur une constante ( 0, 1 ou NULL ), à mettre en 1ère position dans l’éditeur de requête.

La formule de l’objet est

/*+ FULL(SALES) */ 0

Et on le définit sur la table SALES ( bouton Tables … ) pour éviter les alertes lors de la vérification de l’intégrité de l’univers.

/* exemple **
with operations
as (  
select 1 idclient, sysdate dat, 4 val from dual union all
select 1 idclient, sysdate+1 dat, 8 val from dual union all
select 1 idclient, sysdate+2 dat, 7 val from dual union all
select 2 idclient, sysdate dat, 2 val from dual ) */
select idclient, max(dat) from operations group by idclient

Par contre si on veut récupérer d’autres informations de cet enregistrement, il faut passer par une sous-requête :

select idclient,  dat,  val
from operations a
where a.dat=(select max(b.dat) from operations b where b.idclient=a.idclient )

Le problème est ( entre autres ) qu’on passe 2 fois sur la table operations, ce qui dégrade les performances.

Oracle propose depuis la 9i les fonctions analytiques, ce qui est bien pratique pour gérer ce type de problème.
On utilisera par exemple la fonction row_number(), mais on aura toujours une sous-requête :

select idclient, dat, val from (
  select idclient, dat, val,
    row_number() over(partition by idclient order by dat desc) num
  from operations
)
where num=1

Cette solution n’est pas forcément simple à implémenter du fait de la sous-requête. Un ETL comme Sunopsis/ODI ne gère pas les sous-requêtes, il faut passer par des vues et du coup on perdra le lien dans l’analyse d’impact de l’outil.
Solution miracle, on a une requête en one-shot avec la clause keep :

select idclient,
  max(dat),
  max(val) keep (dense_rank last  order by dat) val
from operations
group by idclient

Cerise sur le gâteau, on peut aussi utiliser ce type de clause dans un univers Business Objects, cela évite de passer par une table dérivée ou du sql en dur.

Que du bonheur.

En cherchant les infos sur la version 4 de BO je suis tombé sur ce document : https://websmp210.sap-ag.de/…/bobj_deski_eol.pdf qui annonce l’abandon de Deski dans la prochaine version de BO.
Bon, la date du 1er avril peut me faire douter, mais j’ai du mal à voir un grand éditeur comme SAP laisser traîner un troll sur son site.

BO nous avait déjà fait le coup avec la 1ère version de XI, ils ne vont quand même pas remettre ça ? Je sais qu’aux US Webi domine, mais sur le vieux continent c’est différent …

Je vois dans ma boule de crystal une XI 4 R2 sortir peu de temps après … mais avec deski

C’est bluffant, les résultats de la recherche apparaissent au fur et à mesure de la saisie et cela sans ralentissement

On se prend à rêver à de possibles adaptations à la BI …
A la sauce Business Objects par exemple, pourquoi pas le résultat des données rafraîchi et affiché en temps réel au fur et à mesure de l’édition de la requête en ad-hoc ?
Cela pourrait représenter un gain de temps non négligeable pour les utilisateurs.

Evidemment la technologie derrière devrait suivre, et être performante ( mais si on a déjà un cube OLAP ? )

Mr Google, si vous nous écoutez …

Tout d’abord, voyons comment insérer une invite dans un document.

Par exemple nous avons un état ( très simple ) qui donne le nombre de dossier créés un certain jour. Au lieu de devoir le modifier à chaque fois pour changer la journée dans les conditions de la requête, nous allons mettre une invite qui va demander quelle journée prendre à chaque exécution.

Sous Deski ( client lourd, anciennement reporter ) :
Dans les conditions sur l’objet ( ici Date création ) on sélectionne comme opérateur « Egal à » et comme opérande « Saisir une nouvelle invite ». Il faut ensuite saisir le libellé de l’invite, qui servira aussi de message lors de l’exécution. Les caractères spéciaux comme le ? et les espaces sont autorisés dans le libellé.

Quand on exécute la requête une popup s’affiche proposant à l’utilisateur de rentrer une valeur pour la date :

La valeur saisie est alors prise en condition dans la requête et les données ressorties ne concerneront que la journée saisie.

Sous WebIntelligence ( client léger ), dans les conditions sur un objet il faut sélectionner « Invite » en cliquant sur le bouton le plus à droite.

En cliquant sur le bouton juste à gauche ( entre la saisie de texte et le bouton le plus à droite ), on accède aux propriétés de l’invite, pour changer son nom, garder la dernière valeur sélectionnée lors de la prochaine exécution ou définir la
valeur par défaut.

On peut aussi taper le libellé de l’invite directement dans le cadre de saisie après l’opérateur.
Lors de l’exécution une popup apparait invitant l‘utilisateur à saisir une valeur :

Le fonctionnement est le même lors du rafraichissement du document dans Infoview :

On peut aussi saisir les valeurs des invites directement dans le volet à gauche du document :

Quelques remarques :

• On peut réutiliser une invite dans la même requête ou dans un autre fournisseur de données en reprenant le même libellé – ainsi l’invite ne sera posée qu’une seule fois à l’exécution.
  Sous Deski on peut utiliser l’opérande « Afficher la liste des invites » pour ne pas avoir à retaper le nom, sous Webi il faut effectuer un copier/coller.
• On peut utiliser les invites avec tous les opérateurs.

La suite ( dans quelques jours ) : Part II, Affichage dans le rapport