Biztalk vs API pour couche de databroker

Question

Mon entreprise est sur le point de subir un grand projet dans lequel notre client veut un grand portail client avec un cms, implémentation de crm. Cela nécessitera une interaction avec des données provenant de sources multiples provenant de nos clients, ces sources incluent les systèmes backend de bureau XML, les bases de données sql, les services web, etc ...

Notre solution proposée serait d'écrire une API dans C# pour fournir une interface commune avec tous ces systèmes. Cela serait évolutif pour des projets futurs et simultanés au sein de l'entreprise. Notre client a exprimé son intérêt pour l'utilisation de Biztalk plutôt que d'une API personnalisée pour cette intégration, car il pense que c'est une solution d'entreprise que n'importe lequel de ses fournisseurs pourrait prendre en charge et qui sera mieux supportée. Nous pensons que le travail de configuration en utilisant Biztalk serait plutôt lourd pour toutes leurs règles métier personnalisées qui sont requises et qu'une interface pour la nouvelle application pour obtenir des données depuis et vers Biztalk devrait encore être écrite.

Avons-nous raison de préférer une solution API personnalisée au-dessus de Biztalk? Biztalk conviendrait-il comme couche de databroker pour fournir une interface au nouveau portail client que nous sommes en train d'écrire? Nous n'avons pas l'habitude d'utiliser Biztalk auparavant, donc toute contribution serait appréciée.

Answer 1

En lisant vos exigences, je dirais que vous voudriez vous concentrer sur les parties de base de l'entreprise. C'est à dire. comment utiliser les services mentionnés ci-dessus ensemble. Le sujet où vous voulez dépenser le moins possible est "la plomberie" de ceci.

Le serveur BizTalk enlèvera une grande partie de cette plomberie pour vous. Au lieu de traiter de «comment garantir la cohérence si la normalisation se passe mal», vous devrez traiter de «comment normaliser les données». BizTalk est également très "futur" dans le sens où vous pouvez toujours ajouter/supprimer/modifier des systèmes dans un environnement BizTalk sans avoir besoin de "l'enlever pour un changement". (dans les limites bien sûr et si mis en œuvre correctement).

Je vous conseillerais de réévaluer le "faites-le vous-même" aprroach et de voir combien d'effort est nécessaire si vous voulez faire le "do it yourself" façon. Jetez un coup d'œil à la quantité de «code de plomberie» par rapport à «code de compétence de base». Rappelez-vous, après l'avoir écrit, vous devez le maintenir/corriger. BizTalk est une technologie éprouvée pour héberger ce genre d'exigences.

De la description ci-dessus je dirais; "BizTalk est probablement la meilleure option à choisir".

Hope this helps,

Answer 2

Lorsque l'on regarde à l'interface de BizTalk il y a une grande vérité à réaliser;

'Il n'y a pas d'interface'

BizTalk ne spécifie pas des interfaces spécifiques. Il vous permet de configurer un "modèle d'échange de message nommé" (comme Request-Response, OneWay, etc.). Le message entrant est "Publié" dans BizTalk (par ce que nous appelons une combinaison "Receive Port" + "Receive location"). Vous pouvez avoir une Orchestration (logique métier) ou un SendPort (connexion à un système externe-> out) 'subscribe' aux messages. Cet abonnement peut être basé sur des informations de contexte ou des informations de contenu (bien que le dernier nécessite que les informations soient levées du contenu du message dans le contexte du message).BizTalk vous permet donc de connecter n'importe quel système à un moment donné en devenant un «éditeur» ou un «abonné» aux messages. Cela peut même être fait lorsque le système est pleinement opérationnel en production.

Tout projet BizTalk peut toujours utiliser l'API .Net complète sur plusieurs sites, ce qui vous permet d'écrire «tout ce que vous pouvez en .Net» dans BizTalk.

Je voudrais dire une chose cependant; "Veuillez vous assurer qu'au moins une ou deux personnes de votre équipe de projet obtiendront une montée en charge/un cours BizTalk". BizTalk est comme un pistolet dissimulé; Extrêmement puissant mais dangereux entre de mauvaises mains.