Regarder sous le capot avec les packs de personnalisation - Partie 1

Introduction

Si vous utilisez Acumatica depuis un certain temps, ou si vous êtes sur le point de commencer à utiliser le meilleur ERP du marché, il est certain que vous avez rencontré - ou que vous rencontrerez bientôt - les packages de personnalisation d'Acumatica.

Les paquets de personnalisation sont une partie essentielle du système et de son extensibilité. C'est l'outil qui nous permet, à nous ISV, VAR et utilisateurs finaux, de modifier diverses fonctionnalités ou de les redéfinir complètement.

La plupart de ces informations sont très bien documentées dans les guides de développement proposés par Acumatica. Dans cet article, cependant, nous allons examiner les effets de la publication d'un paquet de personnalisation et identifier ce qui se passe dans le répertoire de l'instance et dans sa base de données. Allons-y et jetons un coup d'œil sous le capot !

Qu'est-ce qui est disponible dans un paquet de personnalisation ?

Un paquet de personnalisation est composé de plusieurs nœuds/domaines associés à différentes caractéristiques du système : développement du code, personnalisation des pages, extension/création des points de terminaison, etc.

Dans cet article, nous allons examiner les effets de deux de ces nœuds. Je me concentrerai sur ceux qui sont le plus souvent utilisés au quotidien dans mon travail.

Gardez à l'esprit que l'analyse des résultats qui sera présentée ensuite peut être facilement examinée/testée dans un environnement dans lequel l'accès au répertoire d'installation de l'instance est possible. Si vous travaillez sur une instance SaaS, il est préférable d'essayer d'abord sur un environnement local.

Nœud CODE

Il est bien documenté que cette fonctionnalité peut être utilisée pour étendre les fonctionnalités prêtes à l'emploi d'Acumatica. Elle peut également être utilisée pour le développement de nouvelles fonctionnalités - c'est-à-dire de nouveaux graphiques, de nouveaux DAC, ou même simplement du codage C# général.

Pour cet exemple, nous allons créer une nouvelle action/bouton dans la page Factures et ajustements(AP301000):

Nous le publions ensuite et obtenons la fonctionnalité attendue :

Voyons maintenant ce qui s'est passé sous le capot :

Si nous allons dans le répertoire [Instance]\App_RuntimeCode nous trouverons un fichier .CS avec le nom du nœud et la logique qui vient d'être publiée.

C'est le contenu de ce dossier - celui qui est utilisé par Acumatica pour identifier toute extensibilité - qui a été appliqué au système[1]

Ce qui est vraiment intéressant, c'est que nous pouvons ouvrir le fichier (ou en créer un nouveau) et y apporter des modifications directement à partir de notre IDE - en travaillant sur une interface plus conviviale pour le code. Si nous ouvrons l'instance et le fichier à partir de Visual Studio, par exemple, nous obtiendrons le contenu réel du fichier.

Nous pouvons alors ajouter des modifications et les enregistrer directement à partir du VS - et elles seront automatiquement disponibles sans qu'il soit nécessaire de les republier. Il suffit de rafraîchir le navigateur pour obtenir la nouvelle version.

Vous pouvez également ajouter de nouveaux fichiers et voir immédiatement les effets sur le système :

Achtung ! Cette méthode est idéale pour un développement rapide. Cependant, si vous publiez sans mettre à jour le paquet, vous risquez de perdre vos modifications. Le paquet de personnalisation dirige le contenu. Et les changements mis en œuvre directement sur l'IDE ne sont pas la version finale du paquet.

Alors, comment ramener ces changements dans le paquet ?

Comme il n'y a pas d'option directe pour "recharger à partir de l'instance", il s'agit d'un processus qui devra être réalisé en combinant les fonctionnalités disponibles dans l'interface utilisateur du paquet de personnalisation et des étapes manuelles :

• Si nous avons apporté des modifications à un fichier créé à l'origine à partir du paquet de personnalisation - dans notre exemple - cs - vous aurez la possibilité de recharger le contenu si vous essayez de le publier[2]:

UPDATE CUSTOMIZATION PROJECT ⇒ prend les changements effectués dans l'IDE et met à jour le paquet.

DISCARD ALL CHANGES ⇒ écrase les modifications effectuées dans l'IDE avec la dernière version disponible dans le paquet.

Si nous choisissons la première option, le contenu du paquet de personnalisation sera mis à jour avec les modifications apportées manuellement.

• D'autre part, si nous avons ajouté un nouveau fichier directement dans l'IDE - dans notre exemple cs, il n'y a pas d'option directe pour "Mettre à jour le projet de personnalisation". C'est un processus qui devra être effectué manuellement. Heureusement, il s'agit d'un copier/coller direct de nos modifications !

Enfin, il est important de garder à l'esprit qu'en l'absence de compilation ou de publication, les erreurs de syntaxe ne seront pas détectées tant que la fonctionnalité n'aura pas été testée.

En conclusion, il s'agit d'un excellent moyen de tester rapidement de petites modifications sans avoir à publier ou à compiler, ce qui est souvent pratique pour vérifier les résultats et les alternatives.

Nœud d'écrans

Examinons maintenant un autre nœud qui est très souvent utilisé dans les personnalisations : le nœud Screens.

Grâce à cette fonctionnalité, nous pouvons personnaliser des pages existantes ou en créer de nouvelles. Comme nous l'avons fait avec le nœud CODE, voyons ce qui se passe sous le capot lorsque l'une de ces modifications est publiée.

Pour les besoins de ce billet, nous allons procéder à un ajustement radical - pas très esthétique - et placer le champ Description sur la troisième ligne de l'en-tête de la page Factures et ajustements. Pour ce faire, nous utiliserons le contrôle Arbre du paquet de personnalisation :

Alors, comment Acumatica sait-il que la page doit avoir cet aspect maintenant si le fichier ASPX original n'a pas changé ? La réponse se trouve dans le fichier [Instance]\CstPublished dans le répertoire [Instance]\CstPublished.

Toute personnalisation apportée aux pages prêtes à l'emploi sera affichée sous la forme d'un nouvel ensemble de fichiers ASPX et ASPX.CS dans ce dossier :

Ces fichiers ne contiendront pas uniquement les modifications spécifiques. Ils contiendront le résultat de la fusion de la page d'origine et des nouvelles modifications. Il s'agit d'une redéfinition complète de la page.

De la même manière que pour le nœud de code, vous pourrez apporter des modifications directes à ces fichiers et en voir l'effet immédiat dans l'interface utilisateur. Continuons et échangeons les champs Statut et Description:

Il suffit d'enregistrer le fichier, d'actualiser le navigateur et la modification sera visible :

Une fois encore, comme pour le nœud Code, c'est le contenu réel du paquet de personnalisation qui est à l'origine de l'information. Si la version précédente du paquet est publiée, ce changement de swap sera perdu. Ainsi, avant que le paquet ne soit republié, nous devons nous assurer de le mettre à jour avec la dernière version de nos modifications manuelles.

Dans ce cas, nous n'aurons pas la possibilité de "recharger" comme nous l'avons fait pour le nœud Code. Vous pouvez donc utiliser la commande Actions > Modifier ASPX pour apporter les modifications :

Recherchez la zone que vous souhaitez modifier, mettez en œuvre les changements et appuyez sur le bouton GENERER LE SCRIPT DE PERSONNALISATION :

Cette option d'édition directe de l'APSX est une bonne alternative à l'utilisation du contrôle de l'arbre. Elle est cependant parfois un peu lourde, car il ne s'agit pas d'un contrôle de texte simple. Lorsque de nouvelles modifications sont apportées, il faut quelques secondes pour qu'il réponde. Je recommanderais personnellement de l'utiliser pour de petites modifications spécifiques, plutôt que pour un remplacement complet des conteneurs.

Petite astuce: vous avez déjà apporté des modifications à une page dans le paquet de personnalisation, mais elles ne sont pas reflétées dans l'interface utilisateur ? Il vous suffit de supprimer le contenu du dossier CstPublished et de republier votre paquet[3].

Résumé

Les nœuds du Customization Package qui ont été couverts dans ce billet s'appliquent à tous les locataires. En d'autres termes, il n'est pas possible d'appliquer la logique personnalisée ou la page personnalisée à un locataire, mais pas à un autre.

Cependant, vous avez peut-être vu l'option "Publier plusieurs locataires". Cette fonctionnalité s'applique à d'autres domaines disponibles dans le paquet de personnalisation, qui seront couverts dans les articles suivants de cette série.

Bon codage !

[1] Il existe d'autres façons de procéder via le répertoire Bin/, mais nous n'en parlerons pas dans ce billet.

[2] Cette fonctionnalité sera disponible si vous essayez de publier à partir du paquet de personnalisation lui-même. Pas à partir de la page Projets de personnalisation (SM204505)

[3] Vous pouvez simuler la suppression des fichiers en dépubliant tous les paquets.