Optimisation des performances d’orchestration

Cette rubrique décrit les meilleures pratiques pour l’utilisation d’orchestrations dans les solutions BizTalk Server. Cela inclut des recommandations pour :

  • Réduction de la latence des solutions BizTalk Server qui utilisent des orchestrations

    • Élimination des orchestrations pour les modèles de messagerie uniquement

    • Utilisation des envois inline à partir d’orchestrations

    • Réduction des points de persistance d’orchestration

  • Imbrication d’orchestrations

  • Modèles de conception d’orchestration

  • Les blocs de gestion des exceptions d'orchestration

Recommandations pour optimiser les orchestrations pour les scénarios à faible latence

Les techniques suivantes peuvent être utilisées pour réduire la latence des solutions BizTalk Server qui utilisent des orchestrations.

Éliminer les orchestrations pour les modèles de messagerie uniquement

Si possible, réduisez l’utilisation des orchestrations pour augmenter le débit global et réduire la latence des processus métier. S’il n’est pas nécessaire d’exécuter des transactions longues et qu’il n’est pas nécessaire d’appeler plusieurs systèmes pour chaque requête, envisagez d’éliminer les orchestrations et de déplacer la logique métier vers les ports de réception et d’envoi afin de réduire la quantité totale d’allers-retours vers BizTalkMsgBoxDb et de réduire la latence en raison de l’accès à la base de données. Dans ce cas, implémentez des pipelines personnalisés et réutilisez des classes utilitaires qui ont été appelées auparavant à partir d’orchestrations. N'utilisez des orchestrations que si elles sont strictement nécessaires pour implémenter des modèles de conception tels que Scatter and Gather ou des convois. Pour plus d’informations sur les modèles de conception d’orchestration, consultez la rubrique Implémentation de modèles de conception dans les orchestrations (https://go.microsoft.com/fwlink/?LinkId=140042) dans la documentation BizTalk Server.

Utiliser les envois inline à partir d’orchestrations pour prendre en charge des scénarios à faible latence

Dans la mesure du possible, réduisez l’utilisation des orchestrations et privilégiez les modèles de messagerie uniquement pour augmenter le débit global et réduire la latence des processus métier. S'il n'est pas nécessaire d'avoir des transactions de longue durée et qu'il n'est pas nécessaire d'utiliser une logique métier pour invoquer plusieurs systèmes, envisagez de déplacer la logique métier vers les opérations de réception et d'envoi et d'éliminer l'utilisation des orchestrations. Cette approche peut être implémentée avec des pipelines personnalisés réutilisant les classes d’assistance précédemment appelées à partir d’orchestrations. Pour obtenir de meilleures performances dans les scénarios à faible latence, adoptez l’une des approches suivantes :

  • Éliminez les orchestrations inutiles et adoptez des modèles de messagerie uniquement pour réduire la quantité totale d’allers-retours vers la base de données BizTalk MessageBox. Cette approche permet une faible latence, car les envois en ligne contournent le moteur de messagerie BizTalk et la surcharge associée. La fonctionnalité d’envoi inline d’orchestration est fournie avec BizTalk Server 2006 et versions ultérieures.

  • Dans les orchestrations, éliminez les ports logiques liés aux ports physiques et utilisez les envois en ligne à leur place. Par exemple, un envoi inline peut être utilisé pour créer une instance d’une classe proxy WCF pour appeler un service Web en aval ou un composant ADO.NET pour accéder à une base de données SQL Server. Dans le diagramme suivant, un envoi inline est effectué lorsque l’orchestration instancie un composant métier, qui utilise en interne un objet proxy WCF pour appeler directement un service web en aval :

    Représentation de l’orchestration BizTalk envoi en ligne

Remarque

Bien que l’utilisation des envois inline à partir d’orchestrations réduise considérablement la latence, il existe des limitations à cette approche. Étant donné que les envois inline contournent le moteur de messagerie BizTalk, les fonctionnalités suivantes fournies avec le moteur de messagerie ne sont pas disponibles :

  • Pipelines transactionnels
    • Pipelines récupérables
    • Pipelines qui appellent l’API d’intercepteur BAM
    • Support de l'adaptateur BizTalk Server
    • Traitement par lots
    • Nouvelle tentatives
    • Initialisation de l'ensemble de corrélations
    • Configuration déclarative
    • Transports secondaires
    • Suivi
    • Utilisation déclarative de BAM

Pour plus d’informations sur les types de pipelines qui ne peuvent pas être exécutés à partir d’une orchestration, consultez la section « Restrictions » de la rubrique Comment utiliser des expressions pour exécuter des pipelines (https://go.microsoft.com/fwlink/?LinkId=158008) dans la documentation BizTalk Server 2010.

Optimiser la latence de l’orchestration en réduisant le nombre de points de persistance, si possible

Une étendue d’orchestration doit uniquement être marquée comme « de longue durée transactionnelle » si vous souhaitez utiliser une compensation ou des délais d'expiration de l'étendue. Une étendue transactionnelle longue provoque un point de persistance supplémentaire à la fin de l’étendue, il faut donc les éviter à moins que vous n'ayez besoin d'utiliser une compensation ou des délais d’expiration d'étendue. Une étendue atomique provoque un point de persistance à la fin de l’étendue, mais garantit également qu’aucun point de persistance ne se produit à l’intérieur de l’étendue atomique. L'absence de persistance dans l'étendue peut parfois être utilisée à votre avantage pour regrouper les points de persistance (en cas de plusieurs envois, par exemple). En général, nous vous recommandons d’éviter les scopes atomiques si possible. Le moteur d’orchestration enregistre dans le stockage persistant l’état entier d’une instance d’orchestration en cours d’exécution à différents points, afin que l’instance puisse être restaurée ultérieurement en mémoire et exécutée à la fin. Le nombre de points de persistance dans une orchestration est l’un des facteurs clés qui influencent la latence des messages transitant par des orchestrations. Chaque fois que le moteur atteint un point de persistance, l’état interne d’une orchestration en cours d’exécution est sérialisé et enregistré dans MessageBox et cette opération entraîne un coût de latence. La sérialisation de l’état interne inclut tous les messages et variables instanciés et non encore libérés dans l’orchestration. Plus les messages et les variables sont importants et plus le nombre de ces messages est élevé, plus il faudra pour conserver l’état interne d’une orchestration. Un nombre excessif de points de persistance peut entraîner une dégradation significative des performances. Pour cette raison, nous vous recommandons d’éliminer les points de persistance inutiles des orchestrations en réduisant le nombre d’étendues transactionnelles et les formes d’envoi. Cette approche permet de diminuer la contention sur le MessageBox en raison de la déshydratation et de la réhydratation de l’orchestration, d’augmenter la scalabilité globale et de réduire la latence de l’orchestration. Une autre recommandation consiste à toujours conserver l’état interne d’une orchestration aussi petite que possible. Cette technique peut réduire considérablement le temps que le moteur XLANG passe à sérialiser, à rendre persistent et à rétablir l'état interne d'une orchestration lors d'un point de persistance. Une façon d’y parvenir consiste à créer des variables et des messages aussi tard que possible et à les libérer le plus tôt possible ; par exemple, introduisez des étendues non transactionnelles à l’intérieur de vos orchestrations et déclarez des variables et des messages dans ces étendues internes au lieu de les déclarer au niveau supérieur. Pour plus d’informations sur la réduction des points de persistance d’orchestration, consultez les rubriques suivantes dans la documentation BizTalk Server 2010 :

Instructions relatives à l’utilisation de propriétés promues pour accéder aux balises de message ou aux attributs d’une orchestration

Si vous avez besoin de promouvoir des propriétés, promouvez uniquement les propriétés utilisées pour le routage, les filtres et la corrélation des messages. La promotion de chaque propriété nécessite que le composant désassembleur (XML, Plat, personnalisé) reconnaisse le type de document et récupère les données du message à l’aide de l’expression XPath de l’annotation relative contenue dans le XSD qui définit le type de document. En outre, chaque promotion de propriété entraîne un appel distinct de la procédure stockée bts_InsertProperty lorsque l’Agent de message publie le message dans la base de données MessageBox. Si une orchestration doit accéder à un élément ou un attribut particulier contenu par un document XML, utilisez l’une des techniques suivantes :

  • Réduisez le nombre de propriétés écrites et promues et éliminez celles qui ne sont pas strictement nécessaires.

  • Éliminez les champs distingués inutiles. Les champs distingués sont des propriétés de contexte écrites et peuvent facilement occuper un espace significatif, car leur nom est égal à l’expression XPath utilisée pour récupérer des données. La propriété unique est définie en tant qu’annotations dans le XSD qui définit le type de document. Le composant désassembleur utilise la même approche adoptée pour les propriétés promues et utilise l’expression XPath qui définit un champ distingué pour le trouver dans le document entrant. Ensuite, le composant désassembleur écrit une propriété dans le contexte où :

    • Nom : expression XPath définie dans l’annotation.

    • Valeur : valeur de l’élément identifié par l’expression XPath dans un document entrant.

      Les expressions XPath peuvent être très longues, en particulier lorsque l’élément en question est très profond dans le schéma du document. Ainsi, plus les champs sont distingués, plus la taille du contexte est grande. Cela affecte à son tour les performances globales.

  • Utilisez la fonction intégrée XPath fournie par le runtime d’orchestration.

  • Si les messages sont assez petits (quelques kilo-octets) et au format XML, vous pouvez désérialiser le message dans une instance de classe .NET et utiliser des champs et des propriétés publics. Si le message a besoin d'une élaboration complexe (code personnalisé, politiques du moteur de règles métiers, etc.), l'accès aux données via les propriétés exposées par une instance d'une classe .NET est beaucoup plus rapide en utilisant des expressions XPath. Lorsque la logique métier appelée par l’orchestration est terminée, l’objet d’entité peut être re-sérialisé dans un message BizTalk. Vous pouvez créer des classes .NET à partir d’un schéma XML à l’aide de l’un des outils suivants : outil XSD (.NET Framework 2.0) ou SVCUTIL (.NET Framework 3.0).

  • Activez un composant d'aide dans une orchestration. Cette technique présente un avantage sur l’utilisation de champs distingués. En fait, une orchestration peut lire l’expression XPath à partir d’un magasin de configurations (fichier de configuration, magasin de configuration SSO, base de données personnalisée, et ainsi de suite) ainsi, lorsque vous devez modifier l’expression XPath, vous n’avez pas besoin de modifier et de redéployer un schéma, comme vous le devez faire pour les propriétés promues et les champs distingués. L’exemple de code suivant fournit un exemple de composant d’assistance. Le composant utilise la classe XPathReader fournie par le runtime BizTalk. Cela permet au code de lire le flux de documents jusqu’à ce que l’expression XPath soit trouvée.

#region Copyright
//===
//Microsoft Windows Server AppFabric Customer Advisory Team (CAT)
//
// This sample is supplemental to the technical guidance published on the community
// blog.
//
// Author: Paolo Salvatori.
//===
// Copyright © 2010 Microsoft Corporation. All rights reserved.
//
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOU BEAR THE RISK OF USING IT.
//===
#endregion
#region Using Directives
using System;
using System.Collections.Generic;
using System.IO;
using System.Xml;
using System.Linq;
using System.Text;
using System.Globalization;
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.Streaming;
using Microsoft.BizTalk.XPath;
#endregion
namespace Microsoft.AppFabric.CAT.Samples.DuplexMEP.Helpers
{
public class XPathHelper
{
#region Private Constants
private const string MessageCannotBeNull = "[XPathReader] The message cannot be null.";
#endregion
#region Public Static Methods
public static string GetValue(XLANGMessage message, int partIndex, string xpath)
{
try
{
if (message == null)
{
throw new ApplicationException(MessageCannotBeNull);
}
using (Stream stream = message[partIndex].RetrieveAs(typeof(Stream)) as Stream)
{
XmlTextReader xmlTextReader = new XmlTextReader(stream);
XPathCollection xPathCollection = new XPathCollection();
XPathReader xPathReader = new XPathReader(xmlTextReader, xPathCollection);
xPathCollection.Add(xpath);
while (xPathReader.Read())
{
if (xPathReader.HasAttributes)
{
for (int i = 0; i < xPathReader.AttributeCount; i++)
{
xPathReader.MoveToAttribute(i);
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.GetAttribute(i);
}
}
}
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.ReadString();
}
}
}
}
finally
{
message.Dispose();
}
return string.Empty;
}
#endregion
}
}

Réduire la complexité de l’orchestration pour améliorer les performances

La complexité des orchestrations a un impact significatif sur les performances. À mesure que la complexité de l’orchestration augmente, les performances globales diminuent. Les orchestrations peuvent être utilisées dans une variété presque infinie de scénarios, et chaque scénario peut impliquer des orchestrations de complexité variable. Évitez les orchestrations complexes lorsque cela est possible en faveur d’une approche modulaire. En d’autres termes, fractionnez votre logique métier en plusieurs orchestrations réutilisables.

Si vous avez besoin d’implémenter une orchestration complexe, définissez des messages et des variables dans des étendues internes dans la mesure du possible plutôt qu’au niveau racine. Cette technique conserve une empreinte plus faible en mémoire pour chaque orchestration, car les variables et les messages sont supprimés lorsque le flux quitte l’étendue où les variables et les messages ont été définis. Cette approche est particulièrement bénéfique lorsque les orchestrations sont enregistrées dans MessageBox aux points de persistance.

Utiliser la forme d’orchestration des appels par rapport à la forme d’orchestration de démarrage pour améliorer les performances

Évitez la forme Démarrer l’orchestration et utilisez la forme Orchestration des appels pour exécuter une orchestration imbriquée. En fait, la forme Call Orchestration peut être utilisée pour appeler de façon synchrone une orchestration référencée dans un autre projet. Cette approche permet de réutiliser les modèles de flux de travail d’orchestration courants dans les projets BizTalk. Lorsque vous invoquez une autre orchestration imbriquée de manière synchrone avec le composant Appel d'Orchestration, l’orchestration principale attend que l’orchestration imbriquée se termine avant de continuer. L’orchestration imbriquée est exécutée sur le même thread que l’orchestration appelante.

La forme Orchestration de démarrage est similaire à la forme Appel d'orchestration, mais dans ce cas, l’orchestration imbriquée est appelée de manière asynchrone : le flux de contrôle dans l’orchestration qui invoque se poursuit au-delà de l'appel, sans attendre que l'orchestration invoquée termine son travail. Pour implémenter ce découplage entre l’appelant et les orchestrations appelées, l’orchestration de démarrage est implémentée via la publication d’un message dans la boîte de message BizTalk. Ce message est ensuite consommé par une instance hôte BizTalk en cours d'exécution qui exécute l'orchestration imbriquée. Lorsque cela est possible, utilisez Call Orchestration, surtout si l’orchestration appelante doit attendre un résultat de l’orchestration imbriquée pour continuer le traitement. Pour plus d’informations sur l’utilisation de la forme Orchestration des appels, consultez les rubriques suivantes dans la documentation BizTalk Server 2010 :

Utiliser XmlReader avec XLANGMessage par rapport à XmlReader avec XmlDocument pour améliorer les performances d’orchestration

Pour améliorer les performances d’orchestration pour les méthodes .NET appelées à partir d’une orchestration, utilisez XmlReader avec XLANGMessage, et non XmlDocument. L’exemple de code suivant illustre cette fonctionnalité.

// As a general rule, use XmlReader with XLANGMessage, not XmlDocument.
// This is illustrated in the parameter passed into the following code.
// The XLANG/s compiler doesn't allow a return value of XmlReader
// so documents must be initially constructed as XmlDocument()
public static XmlDocument FromMsg(XLANGMessage old)
{
    //get at the data
    XmlDocument ret = new XmlDocument();

    try{
        XmlReader reader = (XmlReader)old[0].RetrieveAs(typeof(XmlReader));
        //construct new message from old
        //read property
        object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
    }
    finally {
        // Call Dispose on the XLANGMessage object
        // because the message doesn't belong to the
        // .NET runtime - it belongs to the Messagebox database
        old.Dispose();
    }
    return ret;
}

Une autre méthode consiste à créer une classe .NET basée sur le schéma. Cela prend moins de mémoire que le chargement du document dans un objet XmlDocument , ainsi que l’accès facile aux éléments de schéma pour les développeurs .NET. Pour générer une classe basée sur un schéma BizTalk, vous pouvez utiliser l’outil xsd.exe fourni avec Visual Studio. Par exemple, l’exécution dexsd.exe <schema.xsd> /classes par rapport à un schéma simple contenant des champs nommés ItemA, ItemB, ItemC, produit la classe suivante.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.1433
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System.Xml.Serialization;

//
// This source code was auto-generated by xsd, Version=2.0.50727.42.
//

/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="http://Schemas.MySchema")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="http://Schemas.MySchema", IsNullable=false)]
public partial class MySchemaRoot {

    private string itemAField;

    private string itemBField;

    private string itemCField;

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemA {
        get {
            return this.itemAField;
        }
        set {
            this.itemAField = value;
        }
    }

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemB {
        get {
            return this.itemBField;
        }
        set {
            this.itemBField = value;
        }
    }

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemC {
        get {
            return this.itemCField;
        }
        set {
            this.itemCField = value;
        }
    }
}

Cette classe peut ensuite être référencée dans votre assembly .NET afin d’accéder aux éléments de message, et l’objet retourné peut être directement affecté à un message. Voici un exemple d’utilisation de la classe générée ci-dessus.

public static Root SetValues(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)
{
   try
   {
   MySchemaRoot rootObj=(MySchemaRoot)msg[0].RetrieveAs(typeof(MySchemaRoot);
   rootObj.ItemA="value a";
   rootObj.ItemB="value b";
   rootObj.ItemC="value c";
   }
    finally {
        msg.Dispose();
            }

   return rootObj;
}

Cette technique vous permet d’utiliser une approche orientée objet lors du traitement des messages. Cette technique doit être utilisée principalement avec des messages relativement petits. Cela est dû au fait que même si cette technique utilise beaucoup moins de mémoire que lors du chargement du message dans un objet XmlDocument , le message entier est toujours chargé en mémoire. Lors du traitement de messages plus volumineux, utilisez la classe XmlReader pour lire les messages et la classe XmlWriter pour écrire des messages. Lorsque vous utilisez XmlReader et XmlWriter, le message est contenu dans un objet VirtualStream . Si la taille du message dépasse la valeur spécifiée pour le seuil de message volumineux (octets) exposé sur la page de configuration des propriétés du groupe BizTalk, le message est écrit dans le système de fichiers. Cela diminue les performances globales, mais évite les exceptions de mémoire insuffisante.

Améliorer les performances en réduisant l’utilisation des ports logiques liés aux ports physiques

Vous pouvez augmenter les performances en réduisant l’utilisation des ports logiques liés aux ports physiques qui utilisent les adaptateurs suivants :

  • SQL Server, Oracle

  • WSE, HTTP, WCF

  • MSMQ, MQSeries

    Dans BizTalk Server 2010, les pipelines d’envoi et de réception peuvent être directement appelés à partir d’une orchestration à l’aide de la classe XLANGPipelineManager contenue dans le Microsoft.XLANGs.Pipeline.dll. Par conséquent, le traitement des pipelines peut être déplacé de ports vers des orchestrations ; Les ports logiques d’une orchestration peuvent être remplacés par une forme Expression, qui appelle une instance d’une classe .NET donnée (par exemple, un composant d’accès aux données à l’aide de ADO.NET). Avant d’adopter cette technique, vous devez savoir que si vous n’utilisez pas d’adaptateurs et de ports physiques, vous perdez la possibilité d’exploiter leurs fonctions, telles que le traitement par lots, les nouvelles tentatives, la configuration déclarative et les transports secondaires.

Modèles de conception d’orchestration

Le Concepteur d’orchestration permet aux développeurs d’implémenter un large éventail de modèles d’intégration d’entreprise. Certains modèles courants incluent l'Agrégateur, la Gestion des exceptions et la Compensation, le Courtier de messages, Dispersion et Rassemblement, ainsi que le Convoi séquentiel et parallèle. Ces modèles peuvent être utilisés pour développer des solutions EAI (Enterprise Application Integration), Service-Oriented Architecture (SOA) et BPM (Business Process Management) complexes avec BizTalk Server. Pour plus d’informations sur les modèles de conception d’orchestration, consultez les rubriques Implémentation de modèles de conception dans les orchestrations (https://go.microsoft.com/fwlink/?LinkId=140042) dans la documentation de BizTalk Server et Modèles et meilleures pratiques pour l’intégration d’entreprise (https://go.microsoft.com/fwlink/?LinkId=140043).

Utiliser les classes .NET appropriées dans les orchestrations pour optimiser les performances

En général, les classes .NET utilisées à l’intérieur d’une orchestration peuvent être divisées en deux catégories distinctes :

  • Assistances et services - Ces classes fournissent des services courants aux orchestrations telles que le suivi, la gestion des erreurs, la mise en cache et la sérialisation/désérialisation. La plupart de ces classes peuvent être implémentées en tant que classes statiques sans état interne et plusieurs méthodes statiques publiques. Cette approche évite de créer plusieurs objets de la même classe dans différentes orchestrations exécutées en même temps, ce qui permet de réduire l’espace de travail des processus hôtes et d’économiser de la mémoire. Une classe sans état permet de réduire la taille globale de l’état interne qui doit être sérialisé et conservé dans bizTalk MessageBox lorsqu’une orchestration est déshydratée.

  • Entités et objets métier - Vous pouvez utiliser ces classes pour gérer des entités, telles que les commandes, les articles de commande et les clients. Une orchestration unique peut créer et gérer en interne plusieurs instances du même type. Ces classes sont généralement avec état et exposent des champs publics et/ou des propriétés ainsi que des méthodes pour modifier l’état interne de l’objet. Les instances de ces classes peuvent être créées dynamiquement en désérialisant une partie XLANGMessage dans un objet .NET à l’aide du XmlSerializer ou des classes DataContractSerializer ou à l’aide de la méthode XLANGPart.RetrieveAs . Vous devez structurer une orchestration à l’aide d’étendues non transactionnelles de telle sorte que les instances de classes avec état soient créées aussi tard que possible et libérées dès qu’elles ne sont plus nécessaires. Cette approche réduit l’espace de travail des processus hôtes et minimise la taille globale de l’état interne qui est sérialisé et stocké dans la base de données MessageBox lorsqu’une orchestration est déshydratée. Pour plus d’informations sur l’utilisation d’orchestrations dans BizTalk Server, consultez l’article FAQ sur les orchestrations BizTalk Server (https://go.microsoft.com/fwlink/?LinkID=116886).

    Remarque

    Bien que cet article soit écrit pour BizTalk Server 2004 et BizTalk Server 2006, les concepts présentés s’appliquent également aux orchestrations BizTalk Server 2010.

Blocs de gestion des exceptions d'orchestration

Lorsque vous utilisez des blocs de gestionnaire d’exceptions d’orchestration, incluez toutes les formes d’orchestration dans une ou plusieurs étendues (étendues non transactionnelles chaque fois que possible) et créez au moins les blocs de gestionnaire d’exceptions suivants :

Considérations relatives à l’utilisation de cartes dans des orchestrations

Les considérations suivantes s’appliquent lors de l’utilisation de cartes dans les orchestrations :

  • Si vous utilisez une carte pour extraire ou définir des propriétés utilisées avec une logique métier dans une orchestration, utilisez des champs distingués ou des propriétés promues. Cette pratique doit être suivie, car lors de l’extraction ou de la définition de valeurs avec une carte, le document est chargé en mémoire. Toutefois, lors de l’utilisation de champs distingués ou de propriétés promues, le moteur d’orchestration accède au contexte du message et ne charge pas le document en mémoire.

  • Si vous utilisez une carte pour agréger plusieurs champs en un seul champ, utilisez des champs distingués ou des propriétés promues avec une variable d’orchestration pour accumuler le jeu de résultats.

Voir aussi

Optimisation des performances

  • Last updated on