Je me suis rarement retrouvé devant un produit aussi mal fait que celui-ci.
Lorsque j'ai recu le premier mail (NewsLetter) me prévenant de la sortie d'un ensemble de Reports permettant de remonter les données issues des Log IIS et de SharePoint dans une base SQL Server, puis d'exploiter ces données dans Reporting Services, j'ai trouvé ca élégant.
J'ai même été séduit par cette solution lorsque j'ai commencé à tester ces rapports depuis SSRS (SQL Server Reporting Services) avec la base de test fournie.
Je dois d'abord mettre un bémol pour ce qui est de ces rapports. En effet, ceux-ci ont été fournis en 2005 avec une base exemple contenant des données pour le début d'année 2005. Nous sommes actuellement Mi 2006 et devinez quoi :
- Un des paramètres de quasiment tous les rapports est la période avec un maximum : Les 12 derniers mois.
De ce fait, en prenant les rapports par défaut et la base exemple, on ne trouve jamais aucune valeur. Il a fallu donc ouvrir chaque fichier RDL pour ajouter simplement un choix (les 10 dernières années).
Bref, une fois ce petit détail modifié, les visuels sont assez intéressants pour continuer plus loin.
Il faut donc maintenant faire tout le process de chargement de la base de travail depuis une situation réelle. Je me mets donc sur un portail SharePoint de taille moyenne (plus 27 Go de document dans la base de contenu) et me lance dans la mise en place de la solution de chargement.
Un seul mot pour qualifier ceci : PATHETIQUE !!!!
En effet, pour mettre en place ce système :
- Il faut installer un tool de parsing (jusqu'à là pourquoi pas, mais bon on sent déjà le truc partir en vrille)
- Exécuter une série de scripts SQL pour la mise en place des bases de données
- Il faut modifier un script BAT pour la copie des fichiers de LOG
- Enfin paramétrer un fichier de config
Jusqu'à maintenant, on peut dire que cela n'a rien de dramatique, bien que pour moi ca commence fortement à ressembler à un développement de stagiaire, mais bon.
On lance le fichier batch (attention à respecter une arborescence spécifique pour les fichiers de log, sinon rien ne se charge) et voila la catastrophe :
4 Heures à attendre durant lesquelles on n'a quasiment aucun retour de ce qui se passe pour enfin avoir un message tel que celui-ci :
System.Data.SqlClient.SqlException
Null Values Exist in tblTempFileStorage_toFactStorage. Data not loaded
Error converting data type int to tinyint.
Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK TRANSACTION statement is missing. Previous count = 1, current count = 0.
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
Et ceci n'est qu'une des erreurs remontées, parce que bien sur on a ca à chaque fois avec une nouvelle erreur (donc à chaque fois 4 heures).
Je vous passe les corrections à rechercher à la main dans les scripts d'insertion, mais voila quand même un florilège de ce que j'ai du modifier (franchement même un stagiaire ne ferait pas ces erreurs) :
- Champs destinations faisant 50 ou 100 char alors que le champs d'origine en fait 500 : DONC FORCEMENT CA PLANTE !!!!
- Recherche du type de fichiers en prenant la position du premier "." dans le nom de fichier : DONC FORCEMENT CA PLANTE (sisi prenez le cas de toto.tata.titi.doc) !!!!
- Cast d'une valeur int dans un tinyint : FORCEMENT CA PLANTE !!!!
- ....
Donc ca fait plus de 4 jours que je me bas pour essayer de faire fonctionner ce système et franchement, je commence à avoir des doutes sur mon taux de réussite. Donc je dois signaler au créateur de cet ensemble de scripts que ceux-ci ne sont vraiment pas dignes d'être fournis par Microsoft.
Ainsi M. Dave Harper de Quilogy a signé tous ses scripts SQL en ne prenant même pas la peine de nettoyer ceux-ci (on a par exemple toutes les dates des exports des Procédures stockées).
En conclusion, ce produit est loin d'être fiable et utilisable telque. Il nécessite un gros travail de modification, mais je ne pensais vraiment pas que j'en arriverai là.
La suite au prochain épisode.
Romelard Fabrice
Commentaires
Enregistrer un commentaire