Project Server 2016 pour les administrateurs ep. 1 (les bases de données)

Intéressons-nous dans cet article à l’architecture de Project Server 2016 et plus précisément à l’organisation des bases de données.

Un peu d’histoire pour voir qu’à l’origine, Project Server 2003 ou EPM 2003 couplé à Windows SharePoint Services 2.0 comportait 2 bases.

L’intégration entre les 2 produits n’était qu’une simple option car il n’y avait pas d’interdépendances entre Project et SharePoint :

Vient ensuite la version Project Server 2007 ou EPM 2007 et ses 4 bases Project Server + 1 base de contenu Windows SharePoint Services 3.0 :

Même principe reconduit dans la version Project Server 2010 mais nous passons de Windows SharePoint Services 3.0 (version gratuite) à SharePoint 2010 Enterprise (version payante) :

Avec l’apparition de Project Online et le besoin de limiter le nombre de bases de données, Microsoft revient en arrière dans la version Project Server 2013 avec à nouveau une seule base dans laquelle nous retrouvons 4 schémas :

• draft : tables et objets Project Server de travail
• pub : tables et objets Project Server publiés
• dbo : tables et objets Project Server de rapports
• ver : tables et objets Project Server archivés

Dans la version qui nous intéresse, Project Server 2016, Microsoft décide d’aller encore plus loin dans la limitation du nombre de bases de données avec une fusion de la base de contenu SharePoint et de la base Project Server.
Cela va même encore plus loin car vous pouvez désormais stocker plusieurs instances Project dans une seule et même base de contenu.
Vous retrouvez ainsi 5 schémas :

• dbo : tables et objets SharePoint
• pjdraft : tables et objets Project Server de travail
• pjpub : tables et objets Project Server publiés
• pjrep : tables et objets Project Server de rapports
• pjver : tables et objets Project Server archivés

Toutes les bases de données de contenu SharePoint disposeront systématiquement des 5 schémas ci-dessus même s’il n’y a pas d’instance Project à l’intérieur.

Dans le cas où 2 instances cohabitent dans la même base de contenu, on pourra distinguer les données grâce à une nouvelle colonne « SiteId  » dans les tables SQL.
Ex : dans une table du schéma « draft »…

Le projet PWA01_NMI01 appartient à l’instance /PWA01 et PWA02_NMI01 appartient à l’instance /PWA02.

Microsoft indique cependant que l’accès aux tables Reporting (via une requête SQL) ne sera supporté que si la base de contenu ne contient qu’une seule instance.

Il sera de toute façon conseillé de séparer votre contenu (comme c’était déjà le cas en 2013) dans 2 bases de données.
L’objectif étant de séparer les données Project et les données de vos sites projet dans 2 bases bien distinctes afin de faciliter les opérations de maintenance et de mises à jour.