Discussion :

[CUCARACHA]

Salut,

Je travaille sur la refonte d'un SI d'une compagnie d'assurance qui stocke ses données dans une base DB2 sur un AS400.

Ma mission (que j'ai accepté avant que l'enregistrement ne se détruise 5 secondes plus tard) est de diminuer la dépendance de l'entreprise à AS400 car le responsable de cette machine n'est plus très loin de la retraite et donc, il faut virer l'AS400 d'ici 6 ou 7 ans.

Pour la partie IHM, j'ai choisi MVC3/Entity Framework car j'ai créé un Framework qui permet de générer un grand nombre de choses grace aux POCO T4 et à SQL Server.

Le hic, c'est qu'en attendant de virer l'AS400 je dois assurer le synchronisme temps réel entre l'ancienne base et la nouvelle en SQL Server 2008 R2.

Pour se faire, j'ai conçu un mécanisme qui consiste à vérifier la fraicheur des données à la consultation (car d'autres programmes écrivent dans l'AS400 et qu'il n'est pas possible de notifier le SQL Server de ses modifications à la volée).

Essai 1:
Création d'une procédure stockée CLR qui accède à l'AS400 via EasyCom, le connecteur ADO.net 2.0 que possède mon client.

Malheureusement, ce connecteur référence System.Design qui référence system.windows.form qui est incompatible avec SQL Server.

Essai 2:
Création d'une procédure stockée CLR qui accède à l'AS400 via un webservice WCF. Pour ce faire j'ai suivi les instructions : http://nielsb.wordpress.com/sqlclrwcf/

Malheureusement lorsque j'ai voulu référencer le service model, j'ai du référencer system.web, j'ai du référencer system.directoryservice, system.directoryservice.protocols puis System.EnterpriseServices qui m'a demandé System.Runtime.Remoting qui semble être incompatible.

Bref, pourriez-vous me suggérer un moyen (hors ODBC) pour executer des requêtes vers une autre base dans un autre système à partir d'une proc CLR ?

D'avance merci

laurent

[Bluedeep]

Je pense que les voies que tu as choisies font faire à Sql Server des tâches qui ne sont pas de son ressort.

Je verrais plutôt quelque chose basé sur Service Broker + WCF.

Sinon, je n'arrive pas à comprendre pourquoi ton appel via WCF ne peut pas être mise en place.

Je pense que, à la base, tu te compliques la vie en passant par un proxy auto généré (ce qui est totalement inutile dès qu'on est en ".Net cause à .Net dans un réseau local"), qui t'impose des dépendances pas forcément nécessaires.

[CUCARACHA]

Tu peux me donner un exemple de proxy non autogénéré ?

[mikedavem]

Etes vous obligé de passer par du CLR pour vérifier la fraicheur de vos données sur l'AS400 ?

++

[Bluedeep]

Pas sous la main (je ne fais pas de dév la où je suis), mais il suffit de mettre ton interface dans une assembly séparée qui sera commune à ton client et ton serveur.

[CUCARACHA]

Tu peux me donner un exemple de proxy non autogénéré ?

Bonjour, non, mais je ne vois.pas comment faire autrement pour que.ça.aille vite...

[CUCARACHA]

Bon j'ai réussi à me passer de toute dépendance en créant un webservice REST.

Maintenant mon exercice ce complique...

[CUCARACHA]

Bon, à priori, ça n'est pas possible d'intégrer ce que je veux à SQL Server sachant que je veux garder la compatibilité avec Entity Framework.

Pour moi le plus simple est d'opter pour Oracle (en plus, compte tenu de notre besoin, ça semble moins cher).

++

Laurent

[gork1970]

Bonjour,
Nous avons eu exactement le même problème pour un SI dans l'assurance, et pour le résoudre nous avons utilisé la technologie Convertigo pour intégrer les applications AS/400 avec le nouveau système SQL server. En fait on utilise les capacités du produit à se connecter aux différentes base et a pouvoir extraire et saisir dynamiquement des données dans l' ecrans existant AS/400.
Le projet initial était prévu pour plus de 6 mois de travail nous avons pu le réaliser en moins d'un mois. Le produit existe en version Gratuite Open source et en version entreprise

voir http://www.convertigo.com

[CUCARACHA]

Bonjour,

Je suis allé sur convertigo mais je ne vois pas de quel produit tu parles, tu peux préciser ?

D'avance merci

Laurent