Dans tout projet d’intégration de données, les données partent d’une source, cette source pouvant par exemple être la base de données de votre ERP, un fichier Excel, ou bien un fichier XML, pour se retrouver éventuellement dans une base de destination, la plupart du temps, dans un projet de Business Intelligence, dans le datawarehouse.

A ce titre, SSIS intègre de nombreux outils de transformation du flux de données qui vont vous permettre de filtrer, d’enrichir, ou de façon plus générique, de traiter vos données. Parmi ces outils figurent celui de « fractionnement conditionnel ».

Pour illustrer les fonctionnalités de celui-ci, vous verrez comment il est aisé de réserver à des écritures comptables un traitement particulier selon qu’il s’agit d’une écriture de vente ou d’achat.

Les étapes suivantes décrivent un à un les composants qui illustrent cet exemple.

Cet exemple s’appuie sur une base de données ACCESS qui stocke les données du logiciel comptable, bien évidemment, il s’agit de connaître la structure des données pour savoir où collecter l’information.

Les propriétés du composant font état notamment de la requête SQL qui permet de ne sélectionner que les colonnes qui nous intéressent (Numéro de compte, Code Journal, Date d’écriture, Libellé, Débit et Crédit), et de ne prendre en compte que les écritures d’achat et de vente (seulement celui dont le premier chiffre du numéro de compte est 6 ou 7).

Cette étape est le cœur du sujet abordé dans ce billet, l’objectif de ce composant est de prendre en entrée un flux de lignes d’écritures, et de générer deux flux en sortie, le premier contenant les achats (écritures dont le numéro de compte commence par 6), le second contenant les ventes (numéro de compte qui commence par 7).

En sortie de cet élément, existent donc autant de flux de que conditions fixées dans la fenêtre de propriétés du fractionnement conditionnel. L’exemple montre ici que les flux d’enregistrements vont suivre des routes désormais totalement différentes, écriture dans un fichier texte.

Ceci étant, dans notre exemple, les flux des écritures d’achat et vente suivent des routes différentes mais il peut être concevable qu’après différents traitements spécifiques (par exemple  recherche dans une table annexe du nom du fournisseur pour les achats), ces flux aient besoin de se retrouver à nouveau dans un même flux pour bénéficier ainsi des mêmes opérations.

Cette fonctionnalité (Union) est intégrée à SSIS et fera l’objet d’un billet spécifique, avec bien sûr un exemple concret …

cet article se veut le premier d'une série consacrée à SQL Server 2005 et particulièrement la plateforme Integration Services. Ce billet est basé sur SQL Server 2005, mais bien évidemment, SQL Server 2008 reste au rendez-vous.

Juste pour mémoire, Integration Services inclus un outil graphique de construction de packages qui vont avoir pour vocation de mener des opérations d'intégration et de transformation de données. Le sujet du jour s'intéresse à un élément de transformation du flux de données qu'est "l'extraction de terme".

Si on travaille par exemple sur une application de gestion d'incidents, l'équipe support va saisir au fur et à mesure de ses interventions, des informations non structurées concernant les incidents. Le manager de cette équipe, va être intéressé dans ses attributions, par les éléments qui reviennent le plus souvent dans ces incidents (les produits, les modules, les personnes, etc ...). Pour aider notre manager dans son travail d'analyse, SSIS dispose d'un outil adapté, le fameux "extracteur de termes".

Sur différents critères, l'extracteur de terme va fournir une liste de termes, de phrases, avec pour chacun, un score d'occurence. Le manager pourra par exemple ainsi savoir que le terme "Microsoft Office" apparaît en tête de liste des termes les plus utilisés par les opérateurs du support.

alors comment ça marche ?

Pour l'exemple, utilisons simplement une table qui contient un champ "description" dans lequel les opérateurs ont saisi de manière non structurée les informations de support.

Notre package SSIS est très simple, il ressemble à ceci :

Le package est bien sûr composé d'une source de données, dont le flux va se déverser dans notre fameux "extracteur de termes". A noter au passage la conversion de données, due au fait que notre extracteur ne fonctionne qu'avec des types de données DT_WSTR ou DT_NTEXT.

Le paramétrage de l'extracteur de terme est relativement simple, il suffit de cocher le champ sur lequel va fonctionner l'extracteur. On peut par ailleurs enrichir notre extracteur en spécifiant dans l'onglet "exclusion" les termes qui devront être ignorés, ceux-ci étant positionné dans une autre source de données (base SQL, Excel, etc).

le flux est ensuite déversé dans notre exemple dans un fichier texte, mais on peut imaginer d'enchaîner des traitements beaucoup plus complexes de réaction par rapport à des niveaux n'occurence critique ou autre.

Pour plus de détails sur cet outil, n'oubliez pas MSDN : http://msdn.microsoft.com/en-us/library/ms141809(SQL.90).aspx

On envoie un mail tout simplement pour dire  que la tâche est terminée, et surtout lorsqu'elle s'est terminée par un échec...  Alors comment faire ?

Première étape : configurer la messagerie base de données   

Au préalable, l'utilisateur doit avoir le rôle SYSADMIN :

Ensuite, on peut lancer le wizard de configuration du database Mail :

Le wizard propose une série d'étapes, la première option permet de configurer la messagerie dans son ensemble.

et le finish …

Deuxième étape : configurer SQL Server Agent

L’étape suivante consiste à indiquer à SQL Server Agent, au niveau du système d’alerte, d’activer le profil de messagerie de base de données, et de sélectionner celui qui a été créé précédemment.

Ensuite sur la tâche SQL Server Agent, on va spécifier quelle est la personne à qui le profil de messagerie doit envoyer le mail. Le Database mail permet d’en envoyer à des opérateurs. S’il n’existe pas déjà, il faut donc créer un opérateur :

et enfin, indiquer ensuite au travail SQL Server Agent, l’envoyer une notification à l’opérateur lors de l’échec du travail.

Conclusion

Il s’agit d’une utilisation basique du database Mail à des fin d’administration ou de gestion, mais au-delà de cela, il s’agit d’une réelle solution d’entreprise permettant aux applications base de données d’envoyer des mails aux utilisateurs : résultats d’une requête, des fichiers, etc … On peut très bien imaginer tout un tas d’applications pratiques dans les solutions courante de gestion :

• envoi une alerte avec un résumé à un responsable commercial, lorsqu’un devis est édité avec un prix de vente en dessous des seuils autorisés,
• Un seuil de vente est atteint et génère une alerte particulière avec en pièce jointe un tableau de bord,
• ...