Discussion :

[seeryx]

Salut à tous,

Ceci est mon premier post.

Je viens vers vous car j'aimerais développer une application web qui me permette d’interagir avec l'ERP Microsoft Dynamics Nav à l'aide de Visual Studio 2010, C# et ASP.NET.

En ce qui concerne C#, j'ai commencé avec une simple application qui me permet de lire, modifier et supprimer des enregistrements dans une BDD SQL (SQL server 2008 R2). L'application marche parfaitement. Mais bien entendu ne tient pas compte des règles de gestion de l'ERP( ce qui est très important !)

Le but final est quant à lui de pouvoir afficher et modifier les infos de la table Clients présents dans la base SQL de notre ERP Microsoft Dynamics NAV à partir de notre site web et ce en respectant les règles de gestion de l'ERP.

Questions :
-----------
1) Quels sont les moyens d'accéder à Microsoft Dynamics Nav 2009R2 ?
2) J'ai entendu parler des webservices mais y-a-t'il d'autres méthodes ?
3) Pourriez-vous me mettre sur la voie ou m'indiquer des tutos faisant tout le chemin (création page web, création connection à la BDD, utilisation des règles de gestion de l'ERP) ?

[Immobilis]

Salut,

Pourquoi ne pas utiliser directement l'ERP?

A+

[seeryx]

Salut,

Car le but est d'expérimenter les pont qui existent entre l'ERP et les technologies web afin de pouvoir par exemple faire un extranet,...

[frecil]

Salut,

Car le but est d'expérimenter les pont qui existent entre l'ERP et les technologies web afin de pouvoir par exemple faire un extranet,...

Ah mon avis, la difficulté dans ce que tu veux faire, porte davantage dans la connaissance du fonctionnement de l'ERP, et en particulier des ponts qu'il propose avec d'autres technologies, que dans le développement ASP.NET proprement dit.

D'après leur documentation, il semble qu'il y ait au moins des webservices :
http://msdn.microsoft.com/en-us/library/dd355036.aspx

[tortuegenie]

Les webservices restent encore la meilleure des solutions, on peut faire plein de chose interessantes avec en se greffant sur ce que tu souhaites

[hajer_baccouch]

Bonjour tout le monde,
j'ai lu ce post et c'est similaire à mon projet, mon probléme c'est comment connecter C# à un ERP pour l'extracation des données
es ce qu'il y a des bibliothéques de fonctions pour ceci.
MERCI pour votre collaboration

[calagan99]

Je n'avais pas vu ce post, ma réponse est donc tardive mais je crois que cet article pourrait être utile.

Si j'avais eu accès à des webservices il y a encore quelques mois, je n'aurais peut-être pas une poussée d'urticaire à l'évocation des anciennes versions de Dynamics Nav...

[StringBuilder]

Bonjour,

J'apporte mon expérience personnelle, car j'ai longuement travaillé dans une équipe "interfaces" qui, comme son nom l'indique, était dédiée à l'interfaçage entre un ERP et d'autres outils.

A l'époque, les WebServices n'existaient pas encore (snif).

Aujourd'hui, ils sont, je pense, à privilégier.

Ensuite, d'un point de vue sécurité :
- Si l'application est à usage interne, avec un risque faible d'intrusion, tu peux travailler "directement" avec l'ERP
- Si l'application est à usage public (site e-Commerce par exemple), alors il faut absolument utiliser ta propre base (qui peut reprendre la structure de la base de l'ERP pour plus de simplicité) et ne jamais faire d'accès direct au serveur, sauf éventuellement en lecture, via procédure stockée, et jamais sur les tables directement. C'est ensuite le serveur de l'ERP qui va mettre à jour ta base et lire dedans, jamais dans l'autre sens !

Les moyens d'accéder aux données d'un ERP sont généralement, par ordre de préférence (ma préférence) :
- WebServices (quand ils sont bien faits et qu'ils ne se contentent pas de faire du CRUD sans se soucier du paramétrage...)
- Edition/Intégration : la plupart des ERP permettent de générer des fichiers plats, formattés, facilement interprétable. De la même façon, ils supportent en entrée des fichiers formattés : ce type de fichiers est très intéssant dans la mesure où tu peux travailler avec uniquement les données dont tu as besoin, contrairement aux webservices, qui te ramènent souvent (et on besoin) d'une foultitudes de données dont tu n'as absolument pas besoin. Les éditions/intégration jouent les règles de l'ERP comme en inter-actif, et sont donc sécurisées.
- EDI : C'est un peu comme les éditions/intégration, mais avec un format de fichier normalisé. C'est plus lourd à utiliser, dans la mesure où on doit traduire les formats natifs de l'ERP en fichier EDI en entrée comme en sortie. L'avantage, c'est qu'on peut ensuite s'interfacer de façon standard avec n'importe quoi.
- Lecture directe dans les tables : pour la lecture, à condition de bien contrôler les requêtes, utiliser des requêtes paramétrées, si possible, au maximum des vues ou procédures stockées, la lecture directe des tables est ce qu'il y a de plus rapide, et permet d'avoir des données à jour immédiatement.

Eviter au maximum les accès en écriture dans la base. Pour certaines tables très simples, aux règles de gestions claires, restreintes et figées, on pourra s'amuser à attaquer directement la base. Mais c'est à éviter, avec un ERP on n'est jamais à l'abri :
- d'une modification du modèle des données, rendant caduque toutes les requêtes SQL qu'on utilise
- de l'apparition d'une nouvelle contrainte ou règle de gestion qu'on n'aurait jamais pu imaginer
- de l'apparition de données filles, qu'on ne saura pas alimenter

Donc pour résumer, si les WebServices sont bien fait, abuse-en. Sinon, édition/intégration. Le reste, évite. Les requêtes directes, c'est bien par exemple pour avoir un contrôle en temps réel des stocks, mais faut pas chercher à en faire plus.