Pour déployer des modifications sur vos bases de données Analysis Services, vous devez préparer un script XMLA.

La syntaxe XML est une instruction Alter selon ce format :

<Command>
  <Alter AllowCreate="true" ObjectExpansion="enum">
    <!Object>...<!Object>
    <ObjectDefinition>...</ObjectDefinition>
  </Alter>
</Command>

L’attribut AllowCreate permet de créer l’objet s’il n’existe pas.

Le tag Object sert à pointer sur l’objet à modifier. Par exemple pour, modifier une dimension vous aurez ceci :

<!Object>
  <DatabaseID>ContosoUDM</DatabaseID>
  <DimensionID>Calendrier</DimensionID>
<!Object>

Le tag <ObjectDefinition/> contient quant à lui la définition de l’objet à créer ou à modifier.

Dans la vraie vie…

Dans les faits, on écrit jamais de zéro une instruction <Alter/>. On s’en remet à l’assistant de déploiement (Deployment Wizard), un outil fournit avec SSAS.
Cet assistant va générer le script XMLA et notamment la complexe définition de l’objet.
A noter qu’il est utilisable en ligne de commande : Microsoft.AnalysisServices.Deployment.exe

Le problème qu’on peut rencontrer, c’est quand on utilise un compte (compte de service ou un utilisateur Windows) pour l’impersonation des sources de données.
Dans ce cas, le script XMLA généré ne contient pas le mot de passe du compte or celui-ci doit être reprécisé.

On peut évidemment le rajouter le mot de passe dans le script avant de le lancer :

<ImpersonationInfo>
  <ImpersonationMode>ImpersonateAccount</ImpersonationMode>
  <Account>Domain\AS_Account</Account>
  <Password>***</Password>
</ImpersonationInfo>

Mais pourquoi doit ont repréciser le mot de passe à chaque déploiement ?

A cause de l’attribut ObjectExpansion de la commande Alter. Cet attribut est par défaut à ExpandFull, ce qui signifie que la définition de l’objet doit être complète.
Donc pour modifier le cube, il faut préciser tous les objets dépendants, ce qui inclut la data source et par conséquent le mot de passe du compte d’impersonation.

Peut-on faire autrement ?

ObjectExpansion peut prendre la valeur ObjectProperties, qui permet de n’indiquer que les éléments qui ont changé.
Il suffirait ainsi de ne pas préciser le bloc <ImpersonationInfo/> ou <DataSourceImpersonationInfo/>.

Sauf que ObjectProperties ne permet de modifier qu’objet par objet. Il faut donc toute une série de commandes Alter représentant toute la hiérarchie d’objets en pointant chacun avec le bloc <Object/>.

Alors finalement quelle solution ?

Il n’y en a pas vraiment . Les outils ne récupèrent pas le mot de passe et vous devez le renvoyer lors de la mise à jour quand on est en ExpandFull. Et utiliser l’option ObjectProperties rend le script XMLA trop compliqué.

Quelques pistes que j’utilise (en fonction du projet ou de la plate-forme) :

• utiliser le compte de service SSAS : vous n’aurez pas à manipuler de mot de passe dans les sources de données. L’inconvénient est que vous mutualisez l’accès aux données sources or on doit souvent cloisonner ces accès
• Passer un script XMLA que vous gardez précieusement qui rétablit les mots de passe en post-déploiement (avec l’option ObjectProperties). Ca marche aussi avec un script PowerShell et de l’AMO

Note : sachez que dans la cas de “gros” cubes (ie. ceux qui mettent un temps de process tel qu’on ne peut reprocesser tout à chaque fois), on est très vigilant sur les mises à jour. En effet, elles ne doivent en aucun cas mettre les partitions dans un état Unprocessed.

Bonnes mises à jour de cubes !