Discussion :

[el_grom]

Bonjour à tous,

Je suis actuellement en train d'essayer de construire un outil pour automatiser le deployement de cubes SSAS d'un environnement de DEV à un environnement de PRO mais je suis coincé...

J'ai découvert l'option "Synchronize" de SSMS. Ca a l'air génial pour éviter de devoir faire manuellement le scriptage de la DB pour aller l'executer ailleurs. Mais je suis face à un probleme (dans les deux cas): Je dois changer ma connectionstring a chaque changement d'environnement (db qui change, user et mot de passe).
Pour le moment, c'est tres tres lourd car il faut le faire manuellement en farfouillant dans le xmla produit.

J'ai vu une option dans "Data Source Properties>Connection String>...>All>Named ConnectionString>File Name" mais je n'arrive pas à comprendre son fonctionnement..

Est-ce que cela remplace la configuration manuelle? Est-ce que cela pourrait m'aider dans mon projet? (il ne faudrait que changer le fichier pointé)

Est-ce qu'il existe une autre solution pour exporter et re-importer les metadata des cubes (dans une vision d'automatisation via scripts)?

Merci de votre aide/explications si vous faites autrement

[Jester]

Parles-tu de l’environnement source (pour remplir le DSV) ou le serveur SSAS à utiliser?

Je déploie à partir de Visual Studio (choix de l'env de source et cible via le getsionnaire de configuration) et j'ai un outils qui génère les scripts XMLA de refresh selon l'environnement pour l'ETL (en utilisant ascmd.exe comme je n'utilise pas SSIS).

[el_grom]

A priori, la connectionString sous forme de fichier serait liée au datasource particulier pour le ssas.

D'un point de vue global (et simplifié), j'ai deux environnements: DEV et PRO.
L'équipe de developpeur développe en DEV avec un DB relationnelle de DEV. Quand leur tâche est accomplie, ils me demandent de deployer le cube de DEV en PRO (la nouvelle structure contenant les nouvelles dimensions...).

Mon problème se situe à ce niveau la.. Car l'environnement de PRO depend d'une autre DB relationnelle, possède d'autres règles de sécurité... L'idéal serait de pouvoir exporter la structure seule et de l'importer dans le nouvel environnement de manière "automatique" (scripts...).

Pour le moment, je travaille avec le "script database as>Alter". Mais qui est très lourd à gerer car il faut modifier manuellement dans le code XML la connectionString (DB pointée, login, password) ainsi que les modifications de sécurités (changer les ids des roles, les memberships..) Ces modifications sont assez lourdes et presentent un gros risque d'erreurs.

J'ai donc cherché avec la synchronisation. Le soucis vient du fait que je dois quand meme modifier la ConnectionString. D'ou ma question d'appliquer un fichier de configuration pour la connectionstring (le fichier serait unique par environnement et ce "changement" serait transparent pour le ssas). Pas de problème de sécurité vu les options de la synchronisation. Juste une étape de unprocess/process en plus à effectuer.

Je ne suis pas le développeur, je n'ai donc ni accès à Visual Studio ni aux fichiers de projet.

J'espere avoir répondu à la question :$

[d.joubert]

Tu devrais générer une bonne fois pour toute le script XMLA en ALTER de la datasource de PROD.

Tu aurais juste à exécuter ce script après ton déploiement standard.

[el_grom]

Tu devrais générer une bonne fois pour toute le script XMLA en ALTER de la datasource de PROD.

Tu aurais juste à exécuter ce script après ton déploiement standard.

Donc, appliquer le XMLA de DEV, puis repasser avec celui qui configure les datasources en PRO afin de faire un écrasement? Pareil pour la sécurité j'imagine.

Ca devrait marcher mais ce n'est pas le plus propre surtout en cas d'ajout/modif/retrait d'un datasource non?

Je reconnais que ma situation n'est pas "évidente" mais je doute d'être le seul dans ce cas de figure :/

[d.joubert]

Sinon, si la structure de ton cube ne change pas (au niveau du nommage des dimensions et des partitions), tu peux créer un répertoire avec les 4 fichiers provenant du build : le .asdatabase, le .configsettings, le .deploymentoptions et le .deploymenttarget.

Tu modifies le .configsettings avec les valeurs propres à la prod, et tu utilises un script que tu crées grâce à l'utilitaire de déploiement d'Analysis Services pour qu'il utilise les fichiers de ce répertoire.

Quand tu voudras déployer un cube en prod, tu n'auras qu'à le builder et déplacer le .asdatabase généré dans ton répertoire, et lancer le script.

[el_grom]

Sinon, si la structure de ton cube ne change pas (au niveau du nommage des dimensions et des partitions), tu peux créer un répertoire avec les 4 fichiers provenant du build : le .asdatabase, le .configsettings, le .deploymentoptions et le .deploymenttarget.

Tu modifies le .configsettings avec les valeurs propres à la prod, et tu utilises un script que tu crées grâce à l'utilitaire de déploiement d'Analysis Services pour qu'il utilise les fichiers de ce répertoire.

Quand tu voudras déployer un cube en prod, tu n'auras qu'à le builder et déplacer le .asdatabase généré dans ton répertoire, et lancer le script.

Je l'avais mentionné plus haut mais dans mes tartines, c'est sans doute passé inapercu , je n'ai aucun accès à ces fichiers. Je ne suis pas du tout en charge du developpement (je n'ai d'ailleurs pas d'accès à un visual studio...).
Les seuls outils à ma disposition sont le management studio (SSMS pour les intimes ^^), ascmd/sqlcmd et ma bonne volonté

L'équipe qui développe n'a pas accès à la PROD (et ne peux donc pas déployer), quant à moi, je n'ai ni les connaissances ni le "temps" (au sens où ce n'est pas mon job) de tripoter dans le développement même des cubes mais je dois effectuer les deployement pour eux (et que cela soit transparent pour eux évidemment..)

[d.joubert]

Oui, mais dans ce cas-là, tu peux demander à l'équipe de dev de te fournir ces fichiers nan ?

[el_grom]

Je vais essayer de regarder dans cette direction. S'il ne suffit que de modifier le fichier configSettings, cela pourrait eventuellement passer par un script... (aaaah, l'automatisation via scripts, du bonheur )

Merci des pistes, je reviens dès que j'ai plus d'infos

[Jester]

Je ne sais pas si tu as trouvé, mais garder les rôles de prod sur un fichier généré par la dev (donc avec des rôles de dev), je ne vois pas comment ça peut être facile (à part parser et modifier le XML). Les rôles sont définis dans le .asdatabase il me semble.

A la rigueur sous le workspace les rôles sont dans des fichiers à part. Via du SVN ou autre tu peux maintenir une version avec les roles de prod et sans les roles de dev en parallèle de la dev. Charge aux dev de compiler et à toi de push les nouveaux fichiers.

Mais c'est pas super propre. Ca me semble un problème organisationnel plus que technique.

[arnaudvoisin]

Bonjour el_grom,

Je ne sais pas si tu as résolu ton problème.

La solution proposée par David à base d'un ALTER en XMLA est une bonne idée, très efficace.

Après si tu souhaites rendre le truc un peu plus dynamique, tu peux regarder éventuellement du côté de l'AMO qui te permet d'administrer les cubes. Après tu as besoin d'un language pour manipuler la librairie. Moi je te conseille le scripting en PowerShell.

Pour créer ton script, voici quelque idées :

Tout d'abord, tu as besoin de charger l'assembly Analysis.Services

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices") >$NULL

Ensuite, tu te connectes à ta base AS avec un peu de variabilisation c'est mieux .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$srv = new-Object Microsoft.AnalysisServices.Server
$srv.Connect($ServerSSAS)
$db=$srv.Databases.FindByName($DatabaseName)

Tu peux éventuellement construire tes ConnectionString grâce à la classe System.Data.SqlClient.SqlConnectionStringBuilder

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$builder = New-Object System.Data.SqlClient.SqlConnectionStringBuilder
 
$builder["Data Source"] = $server 
$builder["Initial Catalog"] = $database
$builder["Encrypt"] = $true
$builder["TrustServerCertificate"] = $false
# etc ....

Puis tu peux boucler sur la collection de DataSources de ta bases :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
foreach($ds in $db.DataSources)
{
	$ds.set_ConnectionString($builder)
}

Mais tu peux la jouer moins dynamique en modifiant la ConnectionString en dure d'une DataSources

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ds=$db.DataSources.GetByName("MaDataSource")
$ds.set_ConnectionString("Provider=SQLNCLI11.1;Data Source=MonInstance;Integrated Security=SSPI;Initial Catalog=MaBase")

Je te conseille d'installer PowerGUI car il a la complétion, bien utile et aussi la possibilité d'explorer les objets instanciés, ce qui est vraiment très agréable.

Tu peux le télécharger à l'adresse suivante : http://powergui.org/index.jspa

Sinon pour parler plannification, ton script powershell peut très bien être appellé dans une step PowerShell à la suite de ta synchronisation.

J'espère que ca t'a donné des idées.

Arnaud VOISIN
Consultant BI chez WAISSO | MCITP - SQL SERVER 2008 BI
http://arnaudvoisin.blogspot.fr/
http://www.waisso.com/

[el_grom]

Merci de vos réponses!

Je ne sais pas si tu as trouvé, mais garder les rôles de prod sur un fichier généré par la dev (donc avec des rôles de dev), je ne vois pas comment ça peut être facile (à part parser et modifier le XML). Les rôles sont définis dans le .asdatabase il me semble.

A la rigueur sous le workspace les rôles sont dans des fichiers à part. Via du SVN ou autre tu peux maintenir une version avec les roles de prod et sans les roles de dev en parallèle de la dev. Charge aux dev de compiler et à toi de push les nouveaux fichiers.

Mais c'est pas super propre. Ca me semble un problème organisationnel plus que technique.

Pour l'instance, la solution "sale" imaginée consistait à generer un xmla des roles dans chaque environnement. Scripter le cube de DEV en xmla, l'appliquer en DEV et re-appliquer le xmla contenant les roles (l'étape 1). Ce n'est pas génial si un problème survient ou si une erreur a été commise dans les roles de DEV (changement d'un ID...).

Je ne travaille qu'avec trois roles dont les membres sont fixes. (les membres sont des groupes qui sont populés derriere). Pas de soucis donc pour le generer en "dur".

Niveau organisationnel, je suis d'accord, je suis dans une situation très délicate ... Le problème majeur étant de permettre aux équipes de développement de développer les améliorations (logique ) tout en les empechant d'accèder et/ou tester sur des données de production (confidentialité, accès differents...)... Voila pour la petite histoire

@Arnaudvoisin: Merci pour le détail, je vais y jeter un oeil! Je ne suis pas un grand grand fan d'AMO du fait qu'il me lie fortement à une librairie. J'ai déjà du ré-écrire pas mal de vieux scripts car DMO n'était plus supporté par SQL Server 2012...

Je trouve ca étonnant qu'il ne soit pas prévu une solution plus "user-friendly" prévue par le management studio pour ce cas de figure...
Je vais regarder plus en détail le contenu du .asdatabase alors, sait-on jamais Merci des infos!

[Jester]

Sinon une version de SQL Server Data Tools doit être peu chère et tu pourra facilement gérer ça (les fichiers de rôles sont séparés des autres). D'ailleurs les fichiers de source de données et cible aussi.