---

Mai 2016

Volume 31,numéro 5

Cet article a fait l'objet d'une traduction automatique.

Microsoft Azure : intégration des applications d'entreprise à l’aide d’Azure Logic Apps

Par Srikantan Sankaran | Mai 2016

Gestion des processus d'entreprise est un sujet chaud pour de nombreuses entreprises et intégration avec les systèmes hétérogènes constitue le cœur de l'automatisation des processus. Dans ce contexte, un cas d'usage critiques qui émerge est lié à la réception, de transformation et de routage des données entre l'entreprise et le cloud computing de Microsoft Azure. À l'aide de l'approche traditionnelle pour implémenter ces scénarios d'intégration d'application entreprise implique un investissement considérable de temps et le coût, d'identifier et d'investir dans un outil pour générer l'expertise technique et pour fournir une infrastructure pour prendre en charge le scénarios de bout en calcul. Gérée basée sur un cloud service, comme les applications logiques Azure résout ces problèmes.

La fonctionnalité d'applications logiques du Service applications Azure fournit une expérience d'édition visuelle où les développeurs peuvent composer échange de données complexes entre plusieurs sources de données ou des systèmes à l'aide d'une suite de connecteurs d'intégration standard et enterprise. Les scénarios tels que la gestion d'une défaillance temporaire, qui est unique pour les architectures en nuage et d'autres, comme le routage en fonction de condition de flux de processus et les transactions à long terme, peuvent être facilement implémentées via ce service.

Les fonctionnalités des applications logiques sont décrites dans cet article dans un scénario d'intégration d'entreprise où une organisation de vendeur a déployé une commande système sur Azure qui exploite les fonctionnalités fournies par les applications logiques de capture. Ce processus d'application logique, récupère les commandes à partir d'un point de terminaison public sécurisé exposées par une organisation acheteur, qui est ensuite transmise à travers les étapes nombreux constitué de capture de données, la transformation des données et routage avant l'inscription dans le système back-end. Un ID d'accusé de réception est généré et envoyé à l'organisation de l'acheteur pour chacune des commandes inscrits.

Flux de processus EAI

Figure 1 illustre un scénario EAI simple qui est implémenté à l'aide d'applications logiques.

Flux de processus de la figure 1 Enterprise Application Integration

Données de commande qui déclenche l'intégration sont téléchargées à partir de l'organisation de l'acheteur sous la forme de fichiers plats qui sont exposées en toute sécurité à l'aide d'un point de terminaison SSH protocole SFTP (File Transfer) via Internet. L'accès au point de terminaison est sécurisé avec informations d'identification qui sont partagées avec l'organisation du vendeur. Des dossiers distincts sont créés pour supprimer les données des commandes dans et pour recevoir des messages d'accusé de réception. Une machine virtuelle exécutant CentOS Linux est utilisée en tant que serveur SFTP qui héberge le point de terminaison pour la collecte de fichiers et drop.

Un connecteur Azure SFTP est utilisé pour se connecter au point de terminaison SFTP d'où les données de commande sont récupérées selon une fréquence de déclenchement temporel. Une instance de ce connecteur est créée dans le portail Azure, dans Azure Marketplace et déployée comme une application API. La même instance de l'application API sera également utilisée lorsque vous téléchargez les données d'accusé de réception de la commande au point de terminaison SFTP.

Voici les principaux paramètres à définir dans la configuration de l'instance du connecteur SFTP, lors de l'ajout au flux d'application logique :

• Fréquence de déclenchement : utilisé dans l'implémentation du scénario de 2 minutes
• Emplacement de collecte : Ajouter un chemin d'accès relatif du chemin d'accès racine (par exemple, < sftpusername > /home/) configuré dans l'instance du connecteur SFTP précédemment ; Dans ce cas : b2b/orders
• Sélectionnez le fichier à supprimer après l'option de lecture

L'encodeur BizTalk FlatFile est utilisé pour lire le fichier plat à partir de l'application API du connecteur SFTP et de les convertir en document XML liées au schéma. L'encodeur FlatFile est disponible en tant que les connecteurs d'intégration d'entreprise pour les applications logiques. Une instance de ce connecteur est créée à partir d'Azure Marketplace et déployée comme une application API avant consommation dans le flux de l'application logique. L'encodeur FlatFile prend en charge base génération de schéma XSD à partir de fichiers plats et des Documents JSON, pour des besoins plus complexes impliquant plusieurs enregistrements enfants, tels que ceux utilisés dans ce scénario, le schéma sont générés à l'aide de Visual Studio 2012 et le SDK des Services BizTalk. Les documents de schéma XSD sont ensuite téléchargés vers l'application API du connecteur BizTalk FlatFile encodeur.

Le connecteur des Services de transformation BizTalk convertit le document XML contenant les données de commande dans une charge XML à insérer dans la base de données de Capture de commande. Elle utilise un mappage de Transformation qui est créé à l'aide de Visual Studio 2012 et le SDK des Services BizTalk. À l'instance de ce connecteur est déployé comme une application API, les fichiers de mappage pour l'inscription de l'ordre et le flux d'accusé de réception, sont téléchargées. Les fichiers de schéma utilisés dans le mappage n'ont pas à télécharger pour cette application API.

L'instance de l'application API du connecteur de base de données SQL consomme de la charge utile de document XML à partir de l'étape précédente et insère les données des commandes dans la base de données SQL Azure. Le schéma utilisé pour générer la charge utile XML pour l'opération d'insertion peut être généré dans Visual Studio 2012 avec les Services BizTalk, basé sur une instance de document XML, ou à l'aide des adaptateurs BizTalk WCF LOB pour SQL Server. Toutefois, l'application de API du connecteur de base de données de SQL Azure lui-même prend désormais en charge la génération du schéma pour toutes les opérations sur une base de données, directement à partir de la configuration de l'application API dans le portail Azure. Cela évite le besoin des outils supplémentaires tels que les adaptateurs BizTalk WCF LOB ou d'autres solutions de fournisseurs tiers, qui auraient été nécessaires pour les déploiements locaux.

Figure 2 présente certains paramètres de la clé à définir dans le connecteur de base de données SQL Azure.

Figure 2 Configuration de connecteur de base de données SQL Azure

Sur la réussite de l'insertion de données de commande, la réponse à partir du connecteur de base de données est transformée à l'aide du Service Connecteur application API transformation BizTalk configuré lors des étapes précédentes, à partir d'un tableau de n° commande à une liste séparée par des virgules.

L'Instance d'application API connecteur Azure Storage Blob est utilisé dans le flux de l'application logique pour stocker les messages d'erreur en cas d'échec de l'insertion de la base de données à l'étape précédente.

Les ID de commande générés dans la réponse sont téléchargés à l'aide du connecteur SFTP configuré précédemment au point de terminaison de l'organisation de l'acheteur SFTP.

Le flux de processus d'application logique, lorsque vous avez terminé, s'affiche comme illustré à la Figure 3.

Figure 3 terminer le flux d'application logique

À ce stade, la version du schéma par défaut qui est utilisé lors de la création d'une application logique est 2015-08-01-preview, qui ne fournit pas encore la possibilité d'ajouter des connecteurs d'entreprise. Par conséquent, pour implémenter le scénario EAI actuels, cette version du schéma doit être remplacée par 2014-12-01-preview. Cela est possible en mode Code de l'application logique en modifiant le code JSON directement.

Pensez à enregistrer les modifications, fermez l'éditeur de l'application logique et le recharger pour permettre les modifications prennent effet.

Lorsque vous ajoutez des ressources dans le flux de l'application logique, comme tous les connecteurs, base de données SQL Azure, les connexions de stockage et ainsi de suite, il est conseillé de regrouper toutes dans un seul groupe de ressources pour faciliter la gestion et facilité de déploiement. Il est également préférable que les ressources sont déployés dans la même région (centre de données Azure) afin de minimiser la latence pendant l'exécution du flux.

Gestion dans le flux d'erreurs temporaires

Les applications logiques Azure offrent la possibilité d'incorporer une logique de nouvelle tentative pour prendre en charge des erreurs temporaires qui sont uniques à des architectures de nuage. Cela implique l'ajout d'un fragment de code JSON, comme vous pouvez le voir par le code en surbrillance Figure 4.

Figure 4 les erreurs temporaires de gestion

"b2bmicrosoftsqlconnector": {
  "type": "ApiApp",
  "inputs": {
    "apiVersion": "2015-01-14",
    "host": {
      },
    "operation": "XMLInsertOnordersax",
    "parameters": {
      "requestMessage": {
        "InputXml": "@{body('transformservice').OutputXml}"
      }
    },
    "retryPolicy" : {
      "type": "fixed",
      "interval": "PT30S",
      "count": 2
    },
  },

Lorsqu'il existe des échecs intermittents ou des exceptions de connectivité lors de l'exécution de l'ordre de l'opération d'insertion dans la base de données SQL Azure, l'application API du connecteur réessaiera la demande deux fois jusqu'à ce qu'il renvoie une erreur.

Applications logiques prennent également en charge la possibilité d'ajouter des fonctionnalités telles que la répétition de l'appel de l'exécution jusqu'à ce qu'une condition prédéfinie est satisfaite, implémenter des Actions d'attente, appeler les autres flux de travail et ainsi de suite.

Exécution du flux de l'application logique conditionnelle

Dans un flux de l'application logique, il est possible de définir des actions en fonction du résultat de l'opération précédente. L'option pour définir une condition peut être définie dans le volet de Configuration dans le concepteur ou dans le mode Code de l'application logique.

Par exemple, dans le flux actuel, si le résultat de l'insertion de commande dans la base de données SQL Azure est réussi, puis la Message de réponse est transformée avant le téléchargement vers le point de terminaison SFTP à l'organisation de l'acheteur.

En cas de défaillance, un message d'erreur est téléchargé vers le stockage Azure à l'aide du connecteur de stockage d'objets Blob Azure. L'interface utilisateur d'application logique représente visuellement le flux ainsi configurés. Reportez-vous à Figure 6 qui décrit comment les opérations conditionnelles peuvent être définies et comment l'application logique représente visuellement le flux qui implique les.

Représentation visuelle de la figure 6 des opérations conditionnelles

Utilisation de Documents de schéma XSD

Outils de développement que les développeurs utilisent pour leurs artefacts de build pour des Solutions d'intégration d'entreprise basé sur BizTalk Server peuvent être étendues pour une utilisation pour les applications logiques, également. Le SDK des Services BizTalk, conjointement avec Visual Studio 2012, fournit des modèles de projet supplémentaires afin de permettre au développeur de générer ou de créer une transformation et schémas XSD est mappé. Il existe des Assistants intégrés qui peuvent être utilisés pour générer ces de fichiers plats et des instances de document XML. Les documents de schéma XSD sortie générées dans Visual Studio 2012 peuvent être téléchargés directement à l'Instance d'encodeur FlatFile utilisé dans l'application logique.

Un exemple de fichier XML qui a été utilisé pour générer le schéma XSD pour l'insertion de données de base de données SQL Azure ordre, à l'aide de l'Assistant génération de schéma dans Visual Studio 2012, qui est indiqué dans Figure 5.

Fichier XML de la figure 5 permet de générer un schéma XSD pour l'insertion de données de commande de base de données SQL Azure

<Insert xmlns="https://schemas.microsoft.com/Sql/2008/05/TableOp/dbo/ordersax ">
  <Rows>
  <ordersax xmlns="https://schemas.microsoft.com/Sql/2008/05/Types/Tables/dbo">
    <orderidsap>sap0101</orderidsap>
    <orderdate>2016-02-03</orderdate>
    <supplierid>sail001</supplierid>
    <orderamount>25000</orderamount>
    <currency>INR</currency>
    <discount>12</discount>
    <delvydate>2016-06-03</delvydate>
    <contract>C001</contract>
    <contact>Mr</contact>
  </ordersax>
  <ordersax xmlns="https://schemas.microsoft.com/Sql/2008/05/Types/Tables/dbo">
    <...>
  </ordersax>
... and more records ...
  </Rows>
</Insert>

La réutilisation de ces artefacts qui sont utilisés pour le déploiement local de Solutions EAI à l'aide de BizTalk Server fournit des valeurs étendus aux entreprises sur leurs investissements pour Explorer Azure comme une option permettant de déployer leurs solutions. En outre, il existe des avantages supplémentaires comme l'heure rapide pour le déploiement, la facilité de mise en service d'infrastructure, de facilité de gestion et de surveillance de la solution.

Utiliser des cartes

Le connecteur de service de transformation Azure BizTalk utilise les mappages de transformation de BizTalk pour transformer des documents XML. Toutefois, pour créer ces mappages, Visual Studio 2012 avec le Kit de développement BizTalk Services est requis. Comme avec les schémas XSD, les fichiers de transformation de mappage une fois générés ici peuvent être importées directement dans les applications logiques Azure.

Dans le flux de processus prises en considération, pour mapper l'entrée XML pour le schéma XML insérer et pour parcourir tous les enregistrements dans le document entrant, le fonctoid boucle MapEach est utilisé, comme illustré dans Figure 7.

Figure 7 mise en correspondance de l'accusé de réception de commande Insert

Pour mapper le message de réponse de la création de commande pour le message sortant, le tableau d'ID de commande généré à partir de la base de données SQL Server doit être convertie dans les valeurs séparées par des virgules à l'intérieur d'un seul élément. Pour ce faire, le fonctoid concaténation cumulée est utilisé.

L'exécution du scénario

Pour tester le scénario décrit ici, déposer le fichier orderssap.csv dans le /home/ < sftpusername >/b2b/commandes dossier à l'aide de l'outil WinSCP/équivalent.

Surveiller l'état des journaux pour vous assurer que le déclencheur est activé en effet déclencheur connecteur d'application logique.

S'il y a pas d'erreurs, un fichier, la gestion XML, est déposé dans le /home/ < sftpusername >/b2b/resp dossier qui contiendrait les valeurs d'ID de commande séparées par des virgules générés à partir du système de traitement de commande dans Azure.

Maintenant, supprimez le fichier orderssap.csv à nouveau dans le même dossier, sans aucune modification. Le connecteur de base de données lève une exception en raison d'une erreur de Violation de contrainte Unique à partir de la base de données. Un message d'erreur sera téléchargé dans le stockage Blob Azure, dans le conteneur « orders ».

Exécution d'application logique, suivi et la surveillance

La vignette opérations permet de surveiller l'exécution de l'application logique de flux. Il existe également un journal séparé pour déclencher des événements de l'application logique. Explorez chacun d'entre eux et affichez une décomposition de l'exécution de chaque connecteur dans le flux, le résultat de l'exécution et la durée.

Étendre le scénario pour l'intégration entre différents locaux

Bien que la base de données SQL utilisée dans ce scénario est déployé dans Azure, il serait tout aussi facile à intégrer à une base de données SQL server est en cours d'exécution à l'intérieur d'un réseau d'entreprise. L'infrastructure de Services d'application Azure, dont les applications logiques fait partie, fournit une fonctionnalité appelée connexions hybrides. Implémentation de cette fonctionnalité implique l'installation d'un gestionnaire de connexions hybrides sur un serveur derrière le pare-feu du réseau d'entreprise, par le biais duquel l'application logique s'intègre à cette base de données. En dehors de SQL Server, les autres bases de données qui sont accessibles à l'aide de connexions hybrides sont Oracle, DB2 et Informix.

À l'aide de connexions hybrides, l'utilisation des connecteurs d'entreprise de BizTalk peut être étendue pour les systèmes de métier (LOB) tels que SAP et SharePoint déploiement à l'intérieur des réseaux d'entreprise. Ils peuvent également être étendus aux Services REST et de services Web déployés en local.

Configuration logicielle requise pour implémenter ce scénario

En dehors d'un abonnement Azure qui est requis pour implémenter le scénario décrit ici, les outils de développement suivants et les autres logiciels sont également requis :

• Visual Studio 2012, ainsi que le SDK des Services BizTalk s'exécutant sur Windows 8/8.1/10 ou Windows Server 2012 R2 est requis.
• SQL Management Studio pour SQL Server 2014 ou version ultérieure pour la création et connexion à la base de données SQL Azure. Vous pouvez également utiliser Visual Studio 2012 / ou des outils plus élevées pour SQL Server.
• WinSCP ou un outil équivalent pour se connecter au serveur SFTP, créez les dossiers « envoi » et « réception » et pour supprimer des messages.

Artefacts disponibles au téléchargement

Les artefacts suivants permettent d'implémenter ce scénario sont disponibles pour téléchargement à partir du référentiel GitHub à bit.ly/1poJPgs:

• Script–ordersax.sql de création de base de données SQL Azure
• Exemple de commande données file–orderssap.csv
• Schémas XSD :
  • dbinsert_sampledata.xsd : Schéma SQL Insert
  • dbinsert_sampledata1.xsd : dans le cadre du et référencé dans le schéma ci-dessus
  • orderssap.xsd : le schéma pour le Document entrant d'ordre
  • orderresponse.xsd : Réponse SQL Insert
  • orderresponse1.xsd : dans le cadre du et référencé dans le schéma de réponse SQL Insert
  • ordersaxresp.xsd : schéma de message de réponse XML sortant
• Mappages :
  • Orders.trfm : Message entrant de mappage au schéma SQL Insert
  • ordersaxtosap.trfm : Schéma de réponse SQL Insert mappage au schéma de Message sortant

Les références suivantes peut être utiles lors de l'implémentation de la solution couverts dans ce scénario :

• Configuration logicielle requise pour développer des schémas et mappages utilisés dans la solution : bit.ly/1R3RzvH
• À l'aide de Visual Studio 2012 pour générer des schémas à partir de fichiers plats : bit.ly/1nP6qBy
• Configuration d'un connecteur SFTP dans Azure : bit.ly/254QfC2

Synthèse

Les applications logiques Azure fournit une plate-forme pour implémenter des scénarios de bout en bout EAI. L'ensemble complet de connecteurs standards et enterprise permet d'intégrer de nombreux systèmes métier d'entreprise et les applications Software-as-a-Service dans le cloud. Il peut consommer de façon transparente les artefacts générés pour les déploiements de solution EAI locaux à l'aide de BizTalk Server 2013, tels que des schémas et des mappages. Cela offre aux entreprises une option pour adapter leurs investissements actuels et déverrouiller leur potentiel pour implémenter les scénarios dans le cloud, en exploitant les atouts de haute disponibilité, fiabilité et facilité de configuration de l'infrastructure Azure fournit. Prise en charge des connexions hybrides dans les applications logiques, une valeur supplémentaire peut être dérivée d'actuels investissements LoB systèmes déployés en local, en ouvrant des opportunités pour qu'ils participent à des scénarios d'intégration en cours d'exécution dans le cloud.

Conseil !

Un moyen rapide pour commencer à développer des artefacts de la solution consiste à utiliser l'image de machine virtuelle de la galerie dans le portail de gestion qui exécute BizTalk Server 2013, Édition Standard. Installation de Visual Studio 2012 et le SDK des Services BizTalk dans la machine virtuelle m'a pris plus de 30 minutes.

---

Srikantan Sankaranest un spécialiste technique de l'équipe DX en Inde, basé à Bangalore. Il travaille avec nombreux éditeurs de logiciels en Inde et leur permet de concevoir et déployer leurs solutions sur Microsoft Azure. Contactez-le à sansri@microsoft.com.

Merci à l'experte technique Microsoft suivante d'avoir relu cet article : Sandeep Alur
Sandeep Alur – est le développeur de conduire pour l'Inde DX et est basé à Bangalore.