Introduction
Les performances des échanges ALE peuvent être optimisées dans les différentes étapes du processus ALE :
A : Création des IDocs dans le système émetteur
B : Transfert des IDocs à la couche de communication
C : Communication entre le système émetteur et le système récepteur
D : Intégration des IDocs dans le système récepteur
Pour chaque étapes, l’optimisation peut porter sur :
Le contrôle des événements déclencheurs
Le traitement en parallèle des IDocs
Le regroupement des IDocs en paquets
L’administration de la communication entre système émetteur et récepteur
Créer et transférer les IDocs à la couche de communication en deux étapes séparées améliore les performance globales du processus ALE.
Création des IDocs dans le système émetteur
Privilégier le mode de création avec pointeurs de modification en arrière plan.
Cette étape peut être exécutée en parallèle par plusieurs processus dialogue uniquement dans le cas où les IDocs sont créés en mode message par plusieurs utilisateurs ou dans le cas d’un envoi en masse (par une BD10 par exemple).
Dans le cas d’une création à partir des pointeurs de modification, le programme RBDMIDOC ne prend qu’un seul processus batch.
Il n’y a pas de réel avantage à créer les IDocs en parallèle en mode transactionnel, au contraire cela peut même se révéler dangereux dans la mesure où tous les processus dialogue peuvent être monopolisés.
Avant de créer des IDocs en transactionnel et en mode parallèle, il est conseillé de définir un groupe de serveurs (RZ12).
Le groupe de serveur définit la liste de serveurs d’application dont les processus dialogue peuvent être utilisés pour la création d’IDocs.
Deux processus dialogue restent inutilisés sur chaque serveur d’application dans le groupe de serveur pour éviter la saturation.
Pour créer les IDocs sur un serveur précis, le groupe de serveurs ne doit contenir qu’une seule entrée correspondant au serveur en question.
Transfert des IDocs à la couche ALE du système émetteur
Privilégier le transfert en mode collecté par batch (RSEOUT00).
Plusieurs jobs du RSEOUT00 peuvent être planifiés pour plusieurs destinataires ou types de message afin de transférer les IDocs en parallèle à la couche de communication.
En mode collecté, le RSEOUT00 regroupe les IDocs d’un même partenaire en paquets dont la taille est paramétrée dans les accord d’interchange.
L’écran de sélection du RSEOUT00 permet également de renseigner le nombre d’IDocs à transférer avant le COMMIT WORK soit exécuté et les IDocs débloquées (Attention à ne pas mettre une valeur trop grande pour ne saturer la mémoire et/ou la table de blocage).
SAP recommande entre 10 et 2500 IDocs par paquet selon le nombre de segments dans l’IDoc.
Pour les IDocs volumineux (exemple GLROLL or ALEAUD), le paquet doit contenir entre 1 et 10 IDocs.
Si les IDocs sont intégrés en mode collecté dans le système récepteur, un paquet d’IDocs peut contenir jusqu’à 10 000 enregistrements de données.
Par exemple, pour un IDoc contenant 10 enregistrements, le paquet peur contenir jusqu’à 1000 IDocs.
ATTENTION : Le transfert des IDocs à la couche de communication utilise TOUS les processus dialogue disponibles sur le serveur d’application indépendamment du mode de transfert (immédiat ou regroupé).
S’assurer que le système récepteur dispose d’un nombre suffisant de processus dialogue : le nombre de processus doit être supérieur ou égal au nombre de processus du système émetteur.
Chaque processus dialogue du système émetteur établie une connexion RFCt avec le système récepteur.
Intégration des IDocs dans le système récepteur
Privilégier l’intégration en mode collecté par batch (RBDAPP01)
Mode immédiat :
Attention si les paquets d’IDocs sont intégrés en immédiat dans le système récepteur, TOUS les processus dialogue du serveur récepteur sont utilisés.
Le mode immédiat peut bloquer le serveur récepteur. Les paquets d’IDocs ne peuvent être distribués à travers un groupe de serveur.
Si le paquet comporte plusieurs IDocs et si le module fonction d’intégration ne supporte pas la mise en jour en masse, la couche ALE appelle le module fonction de façon séquentielle dans le même processus pour chaque IDoc du paquet.
Lorsque la table TEDEF est renseignée, (entrée TRFC-IDOC, BATCHJOB), le système utilise les processus batch pour intégrer les IDocs si les dialogue sont saturées en planifiant des jobs avec le programme RBDAPP01 pour chaque IDocs. ATTENTION : ceci peut également saturer les processus batch. (Note 555229)
Mode collecté :
Un serveur d’application appartenant à un groupe de serveur peut être utilisé lors de l’intégration des IDocs en mode batch.
Si aucun groupe de serveurs n’est spécifié, TOUS les processus dialogue du serveur local sont utilisés en parallèle. Ceci peut bloquer le serveur.
Si le groupe de serveur est utilisé, 2 processus dialogue resteront inutilisés
Le RBDAPP01 est capable d’appeler le module fonction d’intégration en masse pour un paquet d’IDocs (si le module fonction supporte le mode de mise à jour collecté)
Traitement en paquets :
Le traitement en paquet réduit le nombre de processus dialogue utilisés et améliore les performance du système
Les paquets peuvent être utilisés lors de la création, du transfert et de l’intégration des IDocs.
Création :
Cf § Création des IDocs dans le système émetteur
Transfert :
Plusieurs IDocs peuvent être regroupés dans un même paquet pour être envoyés dans un même appel RFCt.
Ce procédé comporte plusieurs avantages :
Réduction des taches d’administration liés aux performances de l’ALE
RFCt utilise moins de processus dialogue sur le système émetteur
RFCt utilise moins de processus dialogue sur le système récepteur
Intégration :
Deux types de module fonctions sont utilisés pour intégrer les IDocs :
Modules supportant la mise à jour collectée qui intègrent le paquet d’IDocs dans la même LUW
Modules traitant un seul IDoc par appel
Si les IDocs sont intégrés en immédiat, le système émetteur détermine la taille du paquet. En entrée du système récepteur, la couche ALE détermine si le module fonction d’intégration supporte ou non le mode collecté. S’il le supporte, le paquet est transmis tel quel sinon il est divisé en IDocs individuels.
L’intégration en mode collecté réduit la charge DB.
Pour le RBDAPP01, SAP recommande d’utiliser des paquets de 20 à 100 IDocs.
Source : BC619- ALE Technology
