Webservice sur la version Navision / Microsoft Dynamics 5 ... ou bien?

Question

Allez bounty!

Cette question m'a gagné un badge Tumbleweed (7 vues en 7 jours!), Qui est en quelque sorte une confirmation forte que Navision a une part de marché très limitée, ce qui - je pense - devrait être confirmation Navision est ni tout ce grand morceau de logiciel ...

Mais bon ... c'est ce que nous avons obtenu un back-end, donc je suis prêt à se battre avec cela. : -O

S'il y a un développeur NAVISION audacieux qui est capable de faire la lumière sur cette ... la prime est là pour vous! :)

---

Original Post

J'ai récemment mis en place un système de commerce électronique assez complexe qui interagit avec un héritage back-end basé sur Navision 5. Jusqu'à présent, l'échange de données entre les deux plate-forme est passé via des fichiers XML, mais cette méthode est assez maladroite et très sujettes à contretemps.

Nos besoins sont les suivants:

1. exposer certains éléments de la logique métier de chaque plate-forme à l'autre (par exemple: « quel est le montant total déjà acheté par ce client », « quels sont les produits actuellement offerts ? », "combien de nouveaux clients se sont inscrits sur le site?", etc ...).
2. ont des mécanismes de feed-back / validation pour les différentes opérations (par exemple: « Voici le nouvel ordre du client X » ... « Ok, il a obtenu, l'ordre va maintenant commencer à traiter » ... "Ok, copiez que, au revoir!").
3. Si possible, éviter de jouer avec des fichiers , mais en gardant tout cela se passe en termes d'appels / ports / services ...

La façon la plus naturelle que je pouvais penser serait d'intégrer les deux systèmes via webservice, mais Navision 5 ne supporte pas nativement. Donc, je l'ai fait mon « diligence raisonnable » et a trouvé un certain nombre de choses sur MSDN dont cet article et cette autre .

Selon ces articles il ne devrait pas être difficile de créer un webservice sur Navision 5 , mais quand je l'ai suggéré cette solution à l'équipe en charge du système d'héritage, ils nous ont dit qu'il est « théorie pure » et ils ne savent pas de personne qui ait jamais mis en œuvre il.

Je n'ai aucune raison de douter de leur parole, mais kilométrage peut varier ... et je pensais que peut-être dans la communauté SO il y a des professionnels d'autres pays qui ont effectivement mis en œuvre quelque chose de similaire et sont disponibles pour partager leur expérience.

Alors, ma question est double:

1. Est-ce qu'il ya quelqu'un qui a essayé à la maison et serait disponible pour partager un peu sur ce qui ont été les plus grandes difficultés, si le résultat final est fiable, s'ils pensent que le résultat en vaut la effort, etc ...?
2. Est-ce qu'il ya quelqu'un qui fait face à un problème similaire mais résolu avec une approche différente et qui serait disponible pour présenter leur solution ( «Je ne l'ai fait moi-même, mais si je devais le faire, je le ferais comme ça .. . » type de réponses sont également les bienvenus)?

Merci d'avance pour votre temps! :)

Answer 1

Moi aussi sonnera avec une réponse pas trop utile à propos de Nav 6:)

Je viens de terminer un projet en utilisant Nav 6. Etonnamment, les webservices sont très faciles à exposer et consommer. Il est vraiment une mince affaire d'aller chercher un objet dans l'interface webservices et cocher une case pour lui dire de s'exposer.

grouillant, les webservices ne fonctionnent pas comme vous attendez, vous devez utiliser souvent quelques essais et erreurs pour obtenir des objets et des propriétés à persister, car il est vraiment sensible à la séquence d'événements que vous utilisez pour enregistrer et objet. Et chaque objet semble fonctionner un peu différemment. par exemple: Pour créer un client, j'ai finalement découvert que vous devez créer et enregistrer un client vide, masser ce nouveau disque avec un codeunit, puis aller chercher le dossier et puis écrire les attributs du client et enregistrer à nouveau. I devrait de créer simplement un nouveau client (), définissez les attributs et enregistrer d'un seul rapide.

Je suppose que vous n'êtes pas trop envie de passer à Nav6, mais du haut de ma tête, voici comment vous pouvez simuler des services web:

peut déjà consommer Sharepoint et d'exposer webservices, de sorte que niveau n'est pas un problème. Nav 5 ne les a pas « naturellement », mais vous pouvez concocter votre propre programme qui agit comme un webservice « courtier » - vous êtes déjà obtenir des infos dans et hors de navigation, via la plupart XML. Vous pouvez construire ce courtier à prendre les fichiers d'entrée xml et massez à utiliser dans un appel webservice. Vous pouvez même renoncer à XML et écrire et lire directement à partir du Db, comme toutes les informations de navigation sont stockées là de toute façon. Voici donc ce que je pense:

NAV <-> Serveur SQL <-> Nouveau courtier 'webservice <-> Sharepoint

Ou si vous avez déjà l'API de NAV pat et que vous voulez vers le bas à resuse votre XML:

NAV <-> fichiers XML <-> Nouveau courtier 'webservice <-> Sharepoint

Si vous utilisez filewatchers XML et d'utilisation, le temps d'attente ne devrait pas être trop mauvais, filewatchers habituellement ramasser sur une chute ou un changement en millisecondes.

Hmm, mais je pense que vous êtes probablement censé utiliser BizTalk pour des choses comme ceci: NAV <-> BizTalk <-> Sharepoint

Mais je ne sais pas comment il serait facile de mettre en place BizTalk pour communiquer avec Nav. Je parie que c'est assez straighforward de faire fonctionner comms, mais c'est la spéculation.

Dans tous les cas, je ne sais pas comment ce poste est utile, mais peut-être cela vous donne quelques idées pour aller avec.

Cordialement, Lance

Answer 2

Là où je travaille, nous avons pu utiliser l'un des services Web de NAV 6 à intégrer avec SharePoint, afin que vous puissiez consulter un client ou d'enregistrer et de le montrer dans une partie Web dans SharePoint. Je sais que votre question concerne NAV 5 en particulier, mais je ne l'ai vu ce travail sur NAV 6. Et je n'étais pas le développeur qui a travaillé à ce sujet, donc je n'ai pas plus de détails que je crains.

Avez-vous essayé de demander sur mibuso.com? Ils sont beaucoup plus concentrés Navision.

Answer 3

Quand vous dites exposer la logique métier, cela inclut l'exécution ne le code AL (par exemple un CodeUnit)? Si vous avez seulement besoin d'effectuer des requêtes sur la base de données que vous pouvez utiliser NODBC & System.Data.Odbc ou l'API .NET cfront. Chacune de ces éléments peuvent facilement être compactés en utilisant un service Web .NET et à la fois soutenir la base de données native de NAV. Pour passer des messages que vous sauvegardez encore besoin d'utiliser COM, comme décrit dans le premier article que vous mentionnez.

Tous ci-dessus sont tout à fait possible, et relativement facile en fonction de vos compétences en .NET, COM et NAV.

Le deuxième article lié à vous décrit l'utilisation du NAS. Je ne suis pas expert en la matière, mais je pense que cela pourrait nécessiter un granulé de licence spéciale. Avant de passer du temps la mise en œuvre tout son bon de vérifier si votre licence inclut le NAS, cfront ou NODBC.

Answer 4

Vous pouvez réellement faire une « mise à niveau technique » de NAV 5 à NAV 2009, puis utiliser les webservices indigènes. Signification de remplacer les fichiers exe et l'ensemble de l'application (mais pas les objets, qui seront encore la version 5), et quelques autres trucs. Mais il fonctionne, et donc vous avez 2009-webservice fonctionnalité sur votre NAV 5: -)

Answer 5

Pour le bénéfice de toute personne googler cela, si vous êtes toujours sur Navision 6 avec la base de données native, une bonne façon de se connecter, il est par la fenêtre file d'attente de messages.

Vous pouvez écrire votre propre service web qui met des requêtes XML dans la file d'attente, puis attendre la réponse à la pop-up. Du côté Navision, vous avez un client qui tire la file d'attente et met des réponses dans la file d'attente de réponse. Il y a un client spécial non-GUI appelé NAS pour cela.

Je me sers de cette approche depuis 15 ans pour relier les moteurs de réservation à la fin de retour sur Navision. Il fonctionne très bien et a l'avantage que vous pouvez jeter un regard à la demande avant d'atteindre Navision, de sorte que vous pouvez protéger votre arrière des demandes trop ou défectueux.

Le seul problème avec cette approche est que la commande COMMIT au sein de Navision est super cher. Il est difficile de servir d'importants volumes de demandes. Dès que l'arrière a besoin de commettre, vous êtes vers le bas juste quelques demandes par seconde. Cela peut être très bien pour un faible volume.

Pour un volume élevé dont vous avez besoin pour mettre en œuvre la mise en cache ou d'obtenir une partie de la logique métier sur. Pour moi, il a été d'être frappé par les sites de comparaison de prix, alors voici la solution est de servir les services web écrits en Python et seulement transmettre les demandes si quelqu'un achète quelque chose ...