Le 02 décembre 2012, Microsoft a publié la mise à jour CU4 pour AX Dynamics 2012.
Cette Cumulative Update 4 reprend les CU3, CU2 et CU1.
La mise à jour contient une partie binaire et une partie fonctionnelle (à tester avec vos customisations).
La partie binaire est applicable sur le client riche AX et sur le serveur.
A priori, la sortie de la R2 en décembre et celle du CU4 ne serait pas liées. La R2 apporte des évolutions plus fonctionnelles, sur l'internationalisation de l'application notamment.
La CU4 est basée sur les retours clients/partenaires des releases RTM et Feautre Pack (fonctionnels et applicatifs).
Lien vers la CU4 : KB2765124
Integration, development of Dynamics AX
Thursday, December 20, 2012
Wednesday, December 19, 2012
Conflit d'ID à l'import d'un modelStore
J'ai rencontré recemment un problème d'import de ModelStore sur un environnement cible, sur lequel j'ai trouvé peu d'information claire.
Le message d'erreur à l'import est de la forme :
Import-AXModelStore : The pipeline has been stopped.
At line:1 char:20
+ Import-AXModelStore <<<< -file "C:\monmodel.axmodelstore" -Sch
emaName "MONSCHEMA" -Database MADATABASE -Server MONSERVER -D
etails
+ CategoryInfo : OperationStopped: (:) [Import-AXModelStore], Pip
elineStoppedException
+ FullyQualifiedErrorId : Invalid object name 'MONSCHEMA.ModelSecurityComm
on'.,Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.PowerShell.Impo
rtStoreCommand
Il s'agit d'un conflit d'ID lié à des developpements identiques (projet, objet de l'AOT) sur des couches différentes du model AX (ex en couche CUS, ISV, USR...).
Vérifier que vos dev soit bien tous importés dans la bonne couche sur votre serveur de compilation et que vous n'auriez pas importé un XPO en CUS puis une mise à jour de ce XPO en USR par exemple (c'était mon cas).
J'ai résolu en forçant l'écrasement des ID (j'imagine par la couche la plus elevée) en ajoutant un attribut sur la commande powershell Import-AXModelStore :
Import-AXModelStore -file "C:\monmodel.axmodelstore" -SchemaName "monschemas" -Database madatabase -Server monserver -IdConflict "overwrite" -Details
L'Attribut IDconflict peut prendre la valeur reject ou overwirte (comme l'attribut de la commande AXUtil permettant de faire la même opération).
Corriger ensuite votre environnement de compilation :
1) En important dans la bonne couche les XPO en conflit.
2) En supprimant la customisation dans la couche du dessus
3) compiler l'application
4) Extraire le modelstore
5) Réimporter le modelstore sans l'attribut -IDConflict
Attention, veiller à importer le XPO (étape 1) avant de supprimer la modification en couche supérieure, sinon, une perte de données peut être effectuée par la suppression (en cas de création de table ou de champs)
Quelques liens utiles :
Lien sur les méthodes de déploiements
Une discussion qui m'a permit de comprendre
Un white paper microsoft sur le sujet
Le message d'erreur à l'import est de la forme :
Import-AXModelStore : The pipeline has been stopped.
At line:1 char:20
+ Import-AXModelStore <<<< -file "C:\monmodel.axmodelstore" -Sch
emaName "MONSCHEMA" -Database MADATABASE -Server MONSERVER -D
etails
+ CategoryInfo : OperationStopped: (:) [Import-AXModelStore], Pip
elineStoppedException
+ FullyQualifiedErrorId : Invalid object name 'MONSCHEMA.ModelSecurityComm
on'.,Microsoft.Dynamics.AX.Framework.Tools.ModelManagement.PowerShell.Impo
rtStoreCommand
Vérifier que vos dev soit bien tous importés dans la bonne couche sur votre serveur de compilation et que vous n'auriez pas importé un XPO en CUS puis une mise à jour de ce XPO en USR par exemple (c'était mon cas).
J'ai résolu en forçant l'écrasement des ID (j'imagine par la couche la plus elevée) en ajoutant un attribut sur la commande powershell Import-AXModelStore :
Import-AXModelStore -file "C:\monmodel.axmodelstore" -SchemaName "monschemas" -Database madatabase -Server monserver -IdConflict "overwrite" -Details
L'Attribut IDconflict peut prendre la valeur reject ou overwirte (comme l'attribut de la commande AXUtil permettant de faire la même opération).
Corriger ensuite votre environnement de compilation :
1) En important dans la bonne couche les XPO en conflit.
2) En supprimant la customisation dans la couche du dessus
3) compiler l'application
4) Extraire le modelstore
5) Réimporter le modelstore sans l'attribut -IDConflict
Attention, veiller à importer le XPO (étape 1) avant de supprimer la modification en couche supérieure, sinon, une perte de données peut être effectuée par la suppression (en cas de création de table ou de champs)
Quelques liens utiles :
Lien sur les méthodes de déploiements
Une discussion qui m'a permit de comprendre
Un white paper microsoft sur le sujet
Thursday, December 13, 2012
Copier un Report SSRS sous DAX 2012
Voici un outil XPO AX 2012 qui permet de dupliquer les reports SSRS (projet) : Cliquer ici
Il vous suffit d'envoyer un mail à Sreenath via son Blog pour qu'il vous envoi son projet.
La question de savoir si l'on doit effectuer des personnalisations de report sur les originaux AX ou sur des copies reste entière. En effet la copie de report nécessite de reconfigurer tous les lanceurs présents sous AX.
Subscribe to:
Posts (Atom)