Exécuter du SQL à l’installation d’un module DNN (v.5 et plus)

Les packages DNN sont des archive contenant les fichiers à déployer. Parmi ces fichiers, certains permettent l'exécution de script SQL à l'installation d'un module : les fichier "*.SqlDataProvider"

Nommage

Les fichiers avec l’extension *.SqlDataProvider seront
exécuté au moment de l’installation du module. 
Ces fichiers sont de simples fichiers de commande Transact SQL.

Ils doivent être nommés en se basant sur le format : [VERSION].[DATAPROVIDERTYPE]

  • [VERSION]: est le numéro de version séquentiel
    du script. Exemple : « 01.00.00 ». Il sera utilisé pour exécuter
    les scripts dans le bon ordre. Cenuméro de version a un rapport étroit au
    numéro de version du module (cf. partie Ordre d’exécution).
  • [DATAPROVIDERTYPE]: identifie le dataprovider
    qui sera utilisé. Par défaut, avec DNN, on utilise le DataProvider SQL Server
    (« SqlDataProvider »).

Il existe 3 noms spéciaux de scripts :

  • « install.dataprovidertype » : si le
    package est installé pour la première fois, ce script sera exécuté avant tous
    les autres ;
  • « upgrade.dataprovidertype » : si ce
    fichier existe, il sera exécuté juste après  l’exécution de tous les
    scripts « standards » et sera le dernier à être exécuter;
  • « uninstall.dataprovidertype » : ce
    script sera exécuté à la désinstallation du module.

Contenu du script

Le script doit contenir du Transact-SQL et prendre en compte
deux variables : « databaseOwner »
et « objectQualifier ». Ces
deux variable sont encadrées par des accolades et sont remplacées à
l’exécution.

  • {databaseOwner} : nom de l’objet  possédant
    le rôle « Owner » sur la base de données DNN. Habituellement
    « dbo » ; dans ce cas, « 
    {databaseOwner} » sera remplacé par « dbo. »
  • {objectQualifier} : préfixe utilisé par DNN
    pour tous les objets de la base de donnée liés à DNN. Habituellement
    « dnn » ; dans ce cas, « 
    { objectQualifier } »
    sera remplacé par « dnn_ ».

Exemple de script

if exists (select * from dbo.sysobjects where id =
object_id(N
'{databaseOwner}[{objectQualifier}DNNUOL_GetOnlineUsers]') and
OBJECTPROPERTY(id, N
'IsProcedure') = 1)

   
DROP PROCEDURE {databaseOwner}{objectQualifier}DNNUOL_GetOnlineUsers

GO

 

CREATE PROCEDURE
{databaseOwner}{objectQualifier}DNNUOL_GetOnlineUsers

@PortalIDint,

@IncludeHosts bit

AS

IF @IncludeHosts = 0

BEGIN

SELECT

   
UO.
UserID,

   
U.
UserName,

   
U.
DisplayName,

   
U.
FirstName,

   
U.
LastName,

   
U.
FirstName + ' ' + U.LastName AS FullName

FROM

   
{databaseOwner}{objectQualifier}
UsersOnline UO INNER JOIN {databaseOwner}{objectQualifier}Users U ON UO.UserID = U.UserID INNER JOIN {databaseOwner}{objectQualifier}UserPortals UP ON U.UserID = UP.UserID

WHERE

   
UO.
PortalID = @PortalID AND UO.UserID = U.UserID AND UP.Authorised = 1 AND U.IsSuperUser = 0 -- InnerJoin takes care of SU = 0, but for sanity.

END

ELSE

BEGIN

SELECT DISTINCT

   
UO.
UserID,

   
U.
UserName,

   
U.
DisplayName,

   
U.
FirstName,

   
U.
LastName,

   
U.
FirstName + ' ' + U.LastName AS FullName

FROM

   
{databaseOwner}{objectQualifier}
UsersOnline UO INNER JOIN {databaseOwner}{objectQualifier}Users U ON UO.UserID = U.UserID, {databaseOwner}{objectQualifier}UserPortals UP

WHERE

   
UO.
PortalID = @PortalID AND UO.UserID = U.UserID AND UP.Authorised = 1

END

GO

Intégration dans le package

Vous pouvez placer les fichiers *.SqlDataProvider où vous
le souhaitez dans le package à partir du moment où ils sont bien référencés
dans le manifest d’installation du package[1].

Référencer les fichiers *.SqlDataProvider dans le manifest
d’installation du package :

<dotnetnuke [...] >

   <packages>

     <package [...] >

        <components>

           [...]

           <componenttype="Script">

             <scripts>

                <basePath />

                <script [type="Install | UnInstall"] >

                   <path/>

                   <name/>

                   <version/>

                </script>

                [...]

             </scripts>

           </component>

           [...]

        </components>

     </package>

   </packages>

</dotnetnuke>

  • Type :
    Identifie si le script sera utilisé à l’installation ou la désinstallation du
    module. Seul le fichier « 
    uninstall.dataprovidertype » peut être
    référencé dans le type « uninstall ».
  • basePath :
    là où seront copiés les scripts après l’installation
  • path :
    répertoire cible où seront déposé les scripts (relatif à
    basePath)
  • name :
    nom du fichier de script
  • version :
    version séquentielle du fichier de script, utilisé pour exécuter les
    scripts dans le bon ordre (doit correspondre à la version du nom du fichier)

Exemple de manifest :

<dotnetnuke [...] >

   <packages>

     <package [...] version="05.01.01" >

        <components>

           [...]

           <componenttype="Script">

             <scripts>

                <basePath>DesktopModules\MyModule</basePath>

                <scripttype="Install"] >

                   <path>providers\dataproviders\sqldataprovider</path>

                   <name>02.09.04.sqldataprovider</name>

                   <version>02.09.04</version>

                </script>

                <scripttype="Install"] >

                   <path>providers\dataproviders\sqldataprovider</path>

                   <name>03.01.00.sqldataprovider</name>

                   <version>03.01.00</version>

                </script>

                <scripttype="Install"] >

                   <path>providers\dataproviders\sqldataprovider</path>

                   <name>05.01.01.sqldataprovider</name>

                   <version>05.01.01</version>

                </script>

                <scripttype="UnInstall"] >

                   <path>providers\dataproviders\sqldataprovider</path>

                   <name>UnInstall.sqldataprovider</name>

                   <version>05.01.01</version>

                </script>

             </scripts>

           </component>

           [...]

        </components>

     </package>

   </packages>

</dotnetnuke>

 

Ordre d’exécution (suite à l’exemple)

Comme on peut le voir au niveau de la balise <package/> la version du module dans lequel se trouve le
manifeste est : 05.01.01.

Cas de la 1ère installation

Ordre d’exécution :

  1. 02.09.04.sqldataprovider
  2. 03.01.00.sqldataprovider
  3.  05.01.01.sqldataprovider

DNN va exécuter les scripts en prenant les fichiers de
manière séquentielle sur leur numéro de version.

Cas de la mise à jour depuis la version 03.01.00

Ordre d’exécution :

  1. 05.01.01.sqldataprovider

Si le module est déjà installé, DNN va sauter les scripts
dont la version est inférieure ou égales au numéro de version du module déjà
installé (dans ce cas il saute 02.09.04 et 03.01.00). En effet, DNN présume
qu’ils ont déjà été exécutés.  Il est de
la responsabilité des développeurs de créer des scripts respectant ce
mécanisme.

________________________________________

[1] Manifest
d’installation du package : pour rappel, le manifest d’installation du
package est un fichier XML placé à la racine du package et dont l’extension est
« .dnn ». Il sert à décrire le contenue du package et à définir la
manière dont ce contenu doit être déployé au sein de DNN.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.