AcumatiCares
Introduction
D’un certain point de vue, un ERP est essentiellement un système pour stocker et manipuler les données saisies par les utilisateurs. C’est certainement un point de vue très général qui souligne l’importance de la gestion des données à l’intérieur du système.
Dans Acumatica, les données stockées dans la base de données sont traitées via une couche qui permet aux développeurs de manipuler les données sans interroger directement la base de données. Pour les développeurs Acumatica, il s’agit d’une couche d’abstraction bien connue - Business Query Language ou simplement BQL. Cette couche fournit plusieurs façons de manipuler des données et l’une d’entre elles est l’attribut PXProjection .
Dans cet article, nous allons plonger un peu dans cet attribut, nous allons examiner certaines de ses propriétés, comment il peut être utilisé, et montrer les scénarios courants où il s’applique.
Attribut PXProjection
Cet attribut est utilisé pour définir une nouvelle classe DAC dérivée de l’interface IBqlTable ou de toute autre DAC existante, avec des colonnes/champs/propriétés spécifiques provenant de DAC inclus dans une instruction select qui définit les données gérées par cette nouvelle classe. D’un certain point de vue, nous pouvons voir cette nouvelle classe DAC comme l’équivalent d’une vue SQL où les deux définissent un ensemble de données à partir d’une instruction et les deux sont une table virtuelle, c’est-à-dire qu’il n’y a pas de table réelle dans la base de données avec leurs noms.
Vous trouverez ci-dessous un exemple de cette DAC de projection utilisant INTranSplit comme DAC principal dans l’instruction select :
GIST : https://gist.github.com/Dioris/26e2bf16c5634fa550d6bd11482fd7fa
La DAC de projection ci-dessus sélectionne les derniers documents d’entrée publiés pour les éléments sérialisés dans le système et nous pouvons l’utiliser dans une déclaration de vue pour afficher les enregistrements résultants dans l’interface d’interface utilisateur d’un écran comme ci-dessous:
GIST : https://gist.github.com/Dioris/2ef5dde25d6e9c361637834a8b60284c
ou nous pouvons l’utiliser directement dans une autre déclaration BQL:
GIST : https://gist.github.com/Dioris/2149a44aab505a6c63c541423d6d85ba
Il ne fait aucun doute que l’exemple ci-dessus est un peu complexe, mais montre à quel point un DAC de projection pourrait être utile lorsqu’il s’agit de jeux de données compliqués, ce qui permet de réduire la complexité du BQL final et de rendre possibles les requêtes difficiles.
Commençons par le début:
Il existe essentiellement deux façons de déclarer une DAC de projection lorsqu’il s’agit de l’objet de base. Nous pouvons le définir à l’aide de l’interface IBqlTable comme exemple ci-dessus, ou nous pouvons dériver la nouvelle classe d’un DAC existant :
GIST : https://gist.github.com/Dioris/b3f322e3db560f8be6fac8caf7a62c36
Dans ce cas, les deux déclarations iront chercher toutes les commandes client approuvées. Cependant, la principale différence entre ces deux définitions est que la première vous oblige à déclarer les propriétés et les champs nécessaires, y compris au moins les champs clés. Pour la deuxième définition, la nouvelle DAC de projection hérite de tous les champs et propriétés de la classe de base (SOOrder).
Comme toute autre DAC, nous devons définir les champs clés pour définir les conditions d’unicité pour ses enregistrements en attribuant la propriété IsKey = true à l’attribut de base. En utilisant le même exemple ci-dessus, nous devons déclarer les champs OrderType et OrderNbr pour la première déclaration :
GIST : https://gist.github.com/Dioris/37ecc07072c32f73aa1f4a0d29a6cb71
Notez que les propriétés ajoutées sont explicitement mappées à une propriété existante de la DAC à partir de l’instruction select en affectant le type approprié à la propriété BqlField . Cependant, cela n’est pas nécessaire lors de la dérivation d’un DAC existant et ce DAC est le même que celui utilisé dans l’instruction select comme la deuxième définition.
Dans le cas où nous aurions besoin de modifier une propriété de base dérivée de la classe de base, nous devrions la remplacer comme suit:
GIST : https://gist.github.com/Dioris/dfdb49060df1f07a80e493864d0d91a4
Notez que la classe abstract orderNbr est définie avec le nouveau modificateur pour masquer la définition de la classe de base. Cette nouvelle classe abstraite est normalement utilisée si cette propriété est utilisée dans une autre instruction Bql. La propriété OrderNbr doit avoir le modificateur de priorité afin de définir les nouveaux attributs.
Comme mentionné initialement, l’instruction Select peut avoir plus d’une table impliquée, ce qui signifie que nous devrions mapper les champs nécessaires à partir des DAC supplémentaires au cas où un champ d’eux serait requis, sinon les DAC supplémentaires ne seront utilisés que pour filtrer les données que nous voulons.
Vous trouverez ci-dessous un exemple de DAC de projection pour récupérer des enregistrements de commandes client avec un comportement différent de RM :
GIST : https://gist.github.com/Dioris/d61f6b13ef068e3dd997d7be79a122e0
Dans ce cas, la DAC supplémentaire (SOOrderType) est utilisée à des fins de filtrage uniquement, car la nouvelle DAC de projection ne mappe aucun champ de cette DAC supplémentaire (SOOrderType). Cependant, nous pourrions avoir un besoin particulier de cartographier un champ à partir de cette table. Si tel est le cas, nous devrions le faire comme suit :
GIST: https://gist.github.com/Dioris/a0620755584c73fb8e00ac96aea97bfd
Propriété persistante
Par défaut, la DAC de projection est lisible, c’est-à-dire qu’elle ne permet pas de conserver les modifications apportées à la base de données. Cependant, il existe une propriété Persistent qui l’autorise en le définissant comme vrai que vous pouvez le voir ici:
GIST : https://gist.github.com/Dioris/403d482003d6b1f4979965ca0f1ea49f
Cette propriété vous permet de conserver les modifications apportées à la base de données, que ce soit si elles sont insérées, supprimées ou dans un état Mis à jour .
Bien sûr, les modifications peuvent être conservées dans toutes les tables / DAC impliquées dans l’instruction select. Si les modifications apportées à la table principale sont conservées et si plusieurs tables doivent être mises à jour dans la DAC de projection, la documentation indique que les champs mettant en œuvre la relation entre la table principale et la table jointe doivent avoir l’attribut PXExtraKey pour permettre la mise à jour appropriée appelée par la projection. Vous pouvez le voir clairement ci-dessous:
GIST : https://gist.github.com/Dioris/78c378c17ab91824bd0f38a6b0e986fc
Dans ce cas, la propriété OrderType est la seule impliquée dans la relation entre les deux tables et se trouve l’endroit où l’attribut doit être placé.
Cet attribut a également la possibilité de définir une liste des tables qui nécessitent persister. Dans ce cas, les tables qui n’en ont pas besoin peuvent être exclues :
GIST : https://gist.github.com/Dioris/9f41d1f189a129a3f789987a812298d9
Lorsque vous utilisez la propriété persistent (sans capital) pour définir la liste des DAC à persister, la propriété Persistante est définie sur true automatiquement.
Important!!
Lors de la mise à jour des modifications apportées à la base de données, tous les champs de toutes les DAC impliquées dans l’instruction select ne sont pas mis à jour : seuls les champs qui sont mappés sont ceux qui seront mis à jour.
J’espère que ces informations vous aideront à mieux comprendre cet attribut et à améliorer vos requêtes BQL.
Bon codage!
