Partager via

Optimisation des performances de l’orchestration

  • Article

Cette rubrique décrit les meilleures pratiques pour l’utilisation d’orchestrations dans BizTalk Server solutions. 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

  • Blocs de gestion des exceptions d’orchestration

Recommandations pour optimiser les orchestrations pour les scénarios de 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 de longue durée et s’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 pour réduire la quantité totale d’allers-retours vers BizTalkMsgBoxDb et réduire la latence due à l’accès à la base de données. Dans ce cas, implémentez des pipelines personnalisés et réutilisez des classes d’assistance précédemment appelées à partir d’orchestrations. Utilisez des orchestrations uniquement lorsque cela est strictement nécessaire pour implémenter des modèles de conception comme Scatter et Gather ou 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 les scénarios de 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’effectuer des transactions de longue durée et que la logique métier n’a pas besoin d’appeler plusieurs systèmes, envisagez de déplacer la logique métier pour recevoir et envoyer des ports et d’éliminer l’utilisation des orchestrations. Cette approche peut être implémentée avec des pipelines personnalisés qui réutilisent 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 prend en charge une faible latence, car les envois inline contournent le moteur de messagerie BizTalk et la surcharge associée. La fonctionnalité d’orchestration d’envoi inline 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 un instance d’une classe proxy WCF afin d’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’envoi inline d’orchestration BizTalk

Notes

Bien que l’utilisation d’envois inline à partir d’orchestrations réduise considérablement la latence, cette approche présente des limitations. É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
    • prise en charge de l’adaptateur BizTalk Server
    • Traitement par lot
    • Nouvelle tentatives
    • Initialisation d’un jeu 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 How to Use Expressions to Execute 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 « transactionnelle de longue durée » si vous souhaitez utiliser des délais de compensation ou d’étendue. Une étendue transactionnelle de longue durée entraîne un point de persistance supplémentaire à la fin de l’étendue. Elles doivent donc être évitées lorsque vous n’avez pas besoin d’utiliser des délais de compensation ou 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 produira à l’intérieur de l’étendue atomique. Cet effet secondaire de l’absence de persistance à l’intérieur de l’étendue peut parfois être utilisé à votre avantage pour les points de persistance par lot (lors de plusieurs envois, par exemple). En général, cependant, nous vous recommandons d’éviter les étendues atomiques si possible. Le moteur d’orchestration enregistre dans le stockage persistant tout l’état d’une orchestration en cours d’exécution instance à différents points, afin que la instance puisse être restaurée ultérieurement en mémoire et exécutée jusqu’à son achèvement. Le nombre de points de persistance dans une orchestration est l’un des facteurs clés qui influencent la latence des messages transitant par les 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, ce qui 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 publiés dans l’orchestration. Plus les messages et les variables sont volumineux et plus le nombre de messages et de variables sont importants, plus la conservation de l’état interne d’une orchestration est longue. 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 de formes d’envoi. Cette approche permet de réduire la contention sur 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 d’orchestration. Une autre recommandation consiste à toujours maintenir l’état interne d’une orchestration aussi petit que possible. Cette technique peut réduire considérablement le temps passé par le moteur XLANG à sérialiser, rendre persistant et restaurer l’état interne d’une orchestration en cas de point de persistance. Une façon d’y parvenir consiste à créer des variables et des messages le plus tard possible et à les publier 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 des propriétés promues pour accéder aux balises de message ou aux attributs à partir d’une orchestration

Si vous avez besoin de promouvoir des propriétés, promouvez uniquement les propriétés utilisées pour le routage des messages, 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é provoque 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 important, car leur nom est égal à l’expression XPath utilisée pour récupérer des données. La propriété distinguée 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 que celle adoptée pour les propriétés promues et utilise l’expression XPath qui définit un champ unique à 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 classe .NET instance et utiliser des propriétés et des champs publics. Si le message a besoin d’une élaboration complexe (code personnalisé, stratégies du moteur de règles d’entreprise, etc.) l’accès aux données à l’aide des propriétés exposées par un instance d’une classe .NET est beaucoup plus rapide à l’aide d’expressions XPath. Une fois la logique métier appelée par l’orchestration terminée, l’objet d’entité peut être 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).

  • Activer un composant d’assistance à partir d’une orchestration. Cette technique présente un avantage par rapport à 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, etc.). Par conséquent, lorsque vous devez modifier l’expression XPath, vous n’avez pas besoin de modifier et de redéployer un schéma, comme vous devez le 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 document 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, divisez votre logique métier en plusieurs orchestrations réutilisables.

Si vous avez besoin d’implémenter une orchestration complexe, définissez les messages et les variables dans des étendues internes dans la mesure du possible plutôt qu’au niveau racine. Cette technique conserve un encombrement 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 utile lorsque les orchestrations sont enregistrées dans MessageBox à des points de persistance.

Utiliser la forme d’orchestration des appels et la forme Démarrer l’orchestration 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 d’orchestration des appels peut être utilisée pour appeler de manière synchrone une orchestration référencée dans un autre projet. Cette approche permet de réutiliser des modèles de flux de travail d’orchestration courants dans les projets BizTalk. Lorsque vous appelez une autre orchestration imbriquée de façon synchrone avec la forme d’orchestration des appels, l’orchestration englobante attend que l’orchestration imbriquée se termine avant de continuer. L’orchestration imbriquée est exécutée sur le même thread qui exécute l’orchestration appelante.

La forme Démarrer l’orchestration est similaire à la forme Orchestration des appels, mais dans ce cas, l’orchestration imbriquée est appelée de manière asynchrone : le flux de contrôle dans l’orchestration d’appel se poursuit au-delà de l’appel, sans attendre que l’orchestration appelé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 un hôte BizTalk in-process instance qui exécute l’orchestration imbriquée. Si possible, utilisez l’orchestration des appels, en particulier 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 et XmlReader avec XmlDocument pour améliorer les performances de l’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 nécessite 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 sur un schéma simple contenant des champs nommés ItemA, ItemB, ItemC, génère 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. En effet, même si cette technique utilise beaucoup moins de mémoire que lors du chargement du message dans un objet XmlDocument , l’intégralité du message est toujours chargée 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 messages volumineux (octets) qui est exposé sur la page de configuration des propriétés du groupe BizTalk, le message est écrit dans le système de fichiers. Cela réduit les performances globales, mais évite les exceptions de mémoire insuffisante.

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

Vous pouvez augmenter les performances en réduisant l’utilisation de 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 appelés directement à partir d’une orchestration à l’aide de la classe XLANGPipelineManager contenue dans le Microsoft.XLANGs.Pipeline.dll. Ainsi, le traitement des pipelines peut être déplacé des ports vers les 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é de tirer parti de 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 Designer 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 Aggregator, Gestion et compensation des exceptions, Message Broker, Nuage de points et Collecte, et Convoi séquentiel et parallèle. Ces modèles peuvent être utilisés pour développer des solutions complexes d’intégration d’applications d’entreprise (IAE), d’architecture Service-Oriented (SOA) et de gestion des processus métier (BPM) avec BizTalk Server. 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 et Modèles et meilleures pratiques pour l’intégration d’entreprise (https://go.microsoft.com/fwlink/?LinkId=140043).

Utiliser de manière appropriée les classes .NET dans les orchestrations pour optimiser les performances

En général, les classes .NET utilisées dans une orchestration peuvent être divisées en deux catégories distinctes :

  • Assistances et services - Ces classes fournissent des services communs 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 éléments 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 permettant de 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 des classes XmlSerializer ou 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 le plus tard 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 réduit la taille globale de l’état interne sérialisé et conservé dans la base de données MessageBox lorsqu’une orchestration est déshydratée. Pour plus d’informations sur l’utilisation des orchestrations dans BizTalk Server, consultez l’article FAQ sur les orchestrations BizTalk Server (https://go.microsoft.com/fwlink/?LinkID=116886).

    Notes

    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 gestionnaire d’exceptions d’orchestration

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

Considérations relatives à l’utilisation de mappages dans les orchestrations

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

  • Si vous utilisez une carte pour extraire ou définir les propriétés utilisées avec la 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 un mappage, le document est chargé en mémoire, mais lorsque vous utilisez des champs distingués ou des 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 un mappage pour regrouper plusieurs champs en un seul, utilisez des champs distinctifs ou des propriétés promues avec une variable d'orchestration pour obtenir le jeu de résultats.

Voir aussi

Optimisation des performances