Programmation

Personnalisation de Microsoft Dynamics GP – Dextérité par rapport à Extender, plus eConnect

Posted by admin

Microsoft Great Plains subit actuellement une refonte technologique substantielle. Pour vous rappeler l’histoire – Great Plains Dextérité a été conçu au début des années 1990 comme IDE et shell, écrits en langage de programmation C pour devenir tour à tour outil de développement et de scripting – langage sanscrit. Microsoft a par la suite acheté Great Plains Software à l’orée du 21e siècle. À cette époque, nous voyons deux produits émergents: eXtender, écrit par la société australienne eOne, et eConnect – instrument, conçu à l’origine pour les développeurs de commerce électronique Web. La question du choix du bon outil pour le développement de votre logiciel GP nécessite généralement des recherches supplémentaires, donc dans ce petit article, nous essaierons de vous orienter, en supposant que vous soyez un programmeur et un consultant, avec une certaine connaissance de la comptabilité et de l’architecture du système ERP d’entreprise.

o Dextérité. L’idée était claire au début des années 1990 de doter Great Plains Dynamics d’une certaine indépendance par rapport aux plates-formes de base de données et informatiques et de basculer rapidement en cas d’urgence. Le langage de programmation C a été introduit pour la plupart des plates-formes à l’ancienne: Unix, IBM PC / Microsoft Windows, Solaris, AIX, puis Linux. En raison de cette flexibilité, Dexterity a dû utiliser un moteur d’accès / personnalisation de données piloté par curseur pour être comparé aux instructions SQL SELEC et UPDATE agrégées. Les relevés agrégés offrent des performances beaucoup plus avancées

o Prolongateur. Parfois, vous pensez à des questions amusantes en matière de développement de logiciels. Supposons que nous fournissions un shell sur Dex lui-même et que nous formions l’utilisateur final ou le développeur à prototyper une nouvelle logique personnalisée dans des formulaires, des tables, des vues, et même fournissons le mécanisme pour inclure des scriptlets dex sanscript. Serait-ce un avantage par rapport à l’utilisation d’une dextérité approximative pour construire tout cela à partir de zéro? La réponse est plus probable – oui, c’est génial, et il est beaucoup plus facile et plus fiable d’implémenter un shell secondaire (extender), mais vous devez comprendre les inconvénients. Extender, étant une construction dex, devrait probablement partager le destin futur de la technologie dex. Et deuxièmement, si vous créez des modules complémentaires personnalisés pour Dynamics GP, vous devriez probablement utiliser le premier outil. Cependant, si vous êtes un client final et que vous avez juste besoin de faire le travail, Extender est une excellente option

o eConnect. Cet outil corrige la limitation de Dex en tant que langage de script natif et ouvre le pool d’objets GP pour les développeurs Microsoft Visual Studio. De plus, eConnect adopte une approche orientée objet, ce qui signifie qu’il est beaucoup plus facile de programmer en tant que «programmeur moderne» – il élimine le besoin de faire beaucoup de tests d’assurance qualité, en supposant que vous, en tant qu’encodeur logiciel, suivez précisément l’orientation objet des règles. Vous pouvez utiliser le langage de votre choix ou la philosophie choisie: C # (anciens développeurs Java) ou VB.Net – anciens programmeurs VB et tout le spectre des langages X.Net

o Une combinaison d’agilité et d’eConnect. À notre avis, c’est la manière la plus recommandée d’ajuster les généralistes pour les 5 à 10 prochaines années. Les formulaires Dextérité vous intègrent dans le monde de la sécurité client «épais» de Microsoft Dynamics GP et peuvent être ouverts intuitivement à partir du poste de travail GP. Vous transférez ensuite la logique métier vers une logique personnalisée développée par Visual Studio, en appelant eConnect via l’interface de service Web XML.

o Reporting. Nous voyons ici trois outils: MS SQL Server Reporting Services, GP Report Writer (ancien outil dex) et Crystal Reports. Vous devriez probablement considérer les tendances MS en premier lieu – SRS (en quittant pratiquement l’ancienne orientation Crystal Reports). La bonne nouvelle est que SRS est intuitivement compris par l’ancien concepteur de Crystal Reports, alors n’ayez crainte, installez SRS et portez vos rapports sur une nouvelle plateforme. En ce qui concerne ReportWriter, si vous disposez de formulaires SOP Invoice Long Form ou Field Services personnalisés, vous devez probablement continuer à mettre à niveau ces rapports personnalisés dans ReportWriter. Report Writer est intégré au poste de travail GP et ne nécessite pas de modules supplémentaires pour exécuter une commande d’appel de rapport

o Code source de programmation de dextérité. MBS a des partenaires de programmation de code source, qui à leur tour ont un programmeur de Dextérité, familier avec le code source sanscript de bas niveau (inclus dans DYNAMICS.DIC avec le code, la distribution régulière supprime le code sanscript de ce dictionnaire)

Leave A Comment