AcumatiCares
Introduction
Avez-vous voulu personnaliser l’écran Des commandes de processus SO? Notez que de nombreuses actions trouvées ici sont partagées dans l’écran de saisie de la commande client. Comment ces actions sont-elles liées entre les deux écrans ? Notre objectif aujourd’hui est d’explorer la relation entre ces écrans, et comment ces actions sont invoquées à partir de l’écran de traitement.
Traitement des commandes
Dans l’écran Traiter les commandes (SO501000), nous trouvons des sélections similaires dans la liste déroulante Action, comme on le trouve dans l’écran de saisie de la commande client (SO301000). Par exemple, les actions Créer un envoi et Annuler une commande se trouvent sur les deux écrans. À l’aide de l’outil de demande de code, nous pouvons ouvrir le fichier graphique qui alimente l’écran de saisie de la commande client - SOOrderEntry.cs. Lors de l’inspection, nous remarquons les membres tels que:
- putOnHold
- cancelOrder
- releaseFromCreditHold
- createShipment
Avant de continuer, il y a une histoire intéressante d’Acumatica pré-version 2017. Dans ces versions, les flux de travail des cycles de vie de documents standard tels que la commande client, la commande fournisseur, les factures, etc., ont été définis à l’aide de flux de travail d’automatisation. Chaque cycle de vie a été défini en interne avec un fichier XML laid, qui définissait les états de document et de champ, les actions de menu, les rapports et les valeurs. Acumatica a permis au développeur de modifier le fichier XML pour remplacer le flux de travail par défaut. En outre, un menu de flux de travail d’automatisation a aidé le développeur à créer ces modifications via un écran séparé (qui existe toujours). Cela a certainement facilité le travail, mais n’a pas été d’une grande aide pour en savoir plus sur le lien entre les actions de l’écran de traitement et l’écran de saisie du document.
Avec le navigateur de code, il est plus facile d’apprendre comment les actions sont partagées entre les écrans.
En regardant d’abord le graphique SOCreateShipment.cs, nous remarquons plusieurs membres de la classe
- Vue de données des commandes
- Filtre
- Événement RowSelected
- Événement RowUpdated
Mais remarquez qu’il n’y a pas de types nommés naturels pour notre liste déroulante d’actions? Devrions-nous nous attendre à voir des membres nommés pour chacune de ces actions dans le graphique?
Rappelons-nous l’un des piliers de la programmation orientée objet - l’encapsulation. Comme nous pouvons le déduire, ce n’est pas une bonne pratique de définir le contenu de chaque action, à plusieurs reprises, sur les deux écrans.
Alors que nous regardons le code du graphique, remarquez la vue de données Commandes. Cette vue de données est de type PXFilteredProcessing, qui hérite de PXProcessingBase. La classe PXProcessing définit le PXView, pour former les critères de sélection de nos enregistrements. L’avis dans le constructeur personnalisé pour la vue de données d’enregistrements passe le champ d’ID de Filter.Owner , afin d’ajouter les critères d’OuterView Where de la vue de données. Ceci est utilisé pour aider à sélectionner les enregistrements dans lesquels l’utilisateur actuel a la propriété de l’enregistrement de contact.
Un modèle de conception typique pour le traitement des écrans consiste à définir le délégué de traitement dans le constructeur de graphiques. Dans notre cas, nous ne voyons pas cela. Plus bas dans le code du graphique, notez l’événement RowSelected .
GIST : https://gist.github.com/tocohara/681c603dbe5f3aa059534373a5e66f14
Plusieurs écrans de traitement Acumatica utilisent l’événement Filter RowSelected pour appeler un délégué de processus de données. Par exemple, nous voyons cela dans l’écran Release Retainage (AR510000).
GIST: https://gist.github.com/tocohara/9c879a1e6670adeb921c6296c7fd1bc6
Dans ce cas, le SetProcessDelegate est plus évident. Mais qu’en est-il de notre écran de traitement des commandes client? Revenez à l’événement SOProcessFilter RowSelected . SetProcessWorkflowAction est membre de PXProcessingBase. Utilisons notre outil de réflecteur afin d’explorer ce membre.
GIST: https://gist.github.com/tocohara/3e92bb85c5cf5a62438b2bfaa19be5a5
Nous trouvons quelques déclarations intéressantes dans cette méthode. En particulier, certaines variables sont définies dans le corps de cette méthode pour les remarquer
- screenId
- actionName
Nous avons un moyen d’apprendre ce qu’est l’id d’écran et le nom de l’action, le graphique ProcessOrder , pendant l’événement RowSelected . Notez que le type d’action est S0301000$PrepareInvoice (dans ce cas, nous avons choisi l’action Préparer la facture dans l’écran de traitement).
Après une enquête plus approfondie sur les détails de la méthode SetProcessWorkflowAction, remarquez un appel à une méthode plus profonde nommée _SetProcessTargetInternal. Ce que nous découvrons, c’est le code qui crée des variables d’écran et de menu en divisant la variable Action avec le caractère $. Ceci est important car ils sont utilisés plus bas dans la méthode, pour appeler l’automatisation du flux de travail, en particulier par écran et ID d’action.
GIST: https://gist.github.com/tocohara/e74897a1c42ff9c630946f4eb9efb0e4
Le code va assez loin que cette méthode, mais finalement, le lien entre l’écran SO301000 et le graphique SOOrderEntry est établi dans le graphique. Plus tard, l’action est appelée dans un lot.
Si vous êtes curieux de connaître le stockage de cette relation, consultez la table AUDefinitionDetail:
Résumé
Dans cet article, nous avons exploré les graphiques de l’écran Ordres de traitement. Nous avons enquêté sur le membre actions. À l’aide d’un outil de réflecteur, nous avons découvert l’ID d’écran et le nom de l’action est intercepté profondément dans les membres de la classe PXProcessBase , afin d’appeler les actions dans l’écran de saisie de la commande client.
J’espère que vous avez trouvé cela utile - et toujours - Happy Coding!
