Utilisation de CA Service Virtualization › Utilisation de la Workstation (Station de travail) et de la console avec CA Service Virtualization › Création d'images de service › Utilisation de protocoles de données › Copybook › Logique de correspondance

Logique de correspondance

Vous pouvez reconstituer le fonctionnement de la logique de correspondance en fonction des descriptions des éléments XML et des arguments. Toutefois, pour plus de clarté, cette section décrira la procédure de correspondance dans son intégralité.

Lorsque le VSE reçoit une charge utile, la mise en correspondance se produit dans les phases suivantes :

• Charge utile
• Section
• Copybook
• Finalisation

Charge utile

La charge utile est la première phase de correspondance qui a lieu lorsque le VSE reçoit une nouvelle charge utile. Cette phase détermine l'élément <payload> dans le fichier de mappage de charge utile correspondant à la charge utile reçue. VSE tente de mettre en correspondance un élément <payload> en traitant les éléments dans le fichier de mappage de charge utile dans l'ordre, à savoir de haut en bas. La première correspondance détectée sera sélectionnée.

Remarque : Si aucun élément de charge utile ne correspond à la charge utile, elle sera traitée comme charge utile inconnue. Le contenu sera hexadécimal et encapsulé dans une structure XML générique. Si nécessaire, les charges utiles inconnues seront automatiquement reconverties en octets lors de la lecture.

Pour les charges utiles de demande :

1. Si l'attribut type de cet élément est request (demande), continuez. Dans le cas contraire, cet élément ne correspond pas.
2. Si matchType est défini sur argument, recherchez un argument de demande dont la clé correspond à l'attribut key et la valeur correspond à l'attribut value dans cet élément. En cas de détection, cet élément de charge utile correspondra.
3. Si matchType est défini sur attribute, recherchez un attribut de demande dont la clé correspond à l'attribut key et la valeur correspond à la valeur attribute dans cet élément. En cas de détection, cet élément de charge utile correspondra.
4. Si matchType est défini sur metaData (Métadonnées), recherchez une entrée de métadonnées de demande dont la clé correspond à l'attribut key et la valeur correspond à l'attribut value dans cet élément. En cas de détection, cet élément de charge utile correspondra.
5. Si matchType est défini sur operation, vérifiez si le nom d'opération de la demande correspond à l'attribut key dans cet élément. Si c'est le cas, cet élément de charge utile correspondra.
6. Si matchType est défini sur payload, recherchez dans les limites spécifiées par cet élément les attributs keyStart et keyEnd pour la valeur dans l'attribut key. Si la clé est détectée dans ces limites, l'élément de charge utile correspondra.
7. Si matchType est défini sur all, les étapes 2 à 6 seront traitées dans l'ordre et le traitement s'arrêtera lorsqu'une correspondance sera détectée. La seule différence repose sur le fait que dans les étapes 5 et 6, l'attribut value est utilisé à la place de l'attribut key.

Pour les charges utiles de réponse (lors de l'enregistrement) :

1. Si l'élément de charge utile de demande précédemment décrit a défini l'attribut definesResponse sur true, renvoyez immédiatement l'élément de charge utile avec le même nom que l'élément de demande, mais avec le type de response. Si aucun élément de ce type n'est détecté, il n'y aura aucune correspondance.
2. Si l'élément de charge utile de demande précédemment décrit n'a pas défini l'attribut definesResponse sur true :
   1. Si l'attribut type de cet élément est response (réponse), continuez. Dans le cas contraire, cet élément ne correspond pas.
   2. Si matchType est défini sur metaData (Métadonnées), recherchez une entrée de métadonnées de réponse dont la clé correspond à l'attribut key et la valeur correspond à l'attribut value dans cet élément. En cas de détection, cet élément de charge utile correspondra.
   3. Si matchType est défini sur payload, recherchez dans les limites spécifiées par cet élément les attributs keyStart et keyEnd pour la valeur dans l'attribut key. Si la clé est détectée dans ces limites, l'élément de charge utile correspondra.
   4. Si matchType est défini sur all, effectuez les étapes b et c dans l'ordre et arrêtez le processus lorsqu'une correspondance est détectée. La seule différence repose sur le fait que dans l'étape c, l'attribut value est utilisé à la place de l'attribut key.

Pour les charges utiles de réponse (lors de la lecture) :

Lors de la lecture, aucune correspondance n'est effectuée pour les réponses. En revanche, lors de l'enregistrement, toute correspondance déterminée est enregistrée dans les métadonnées de l'objet de réponse. Puis, pendant la lecture, lorsque cet objet de réponse est renvoyé, le processeur récupère la valeur à partir des métadonnées de la réponse, recherche l'élément de charge utile avec ce nom (et le type response) et l'utilise. Si aucun élément de ce type n'existe, cela est considéré comme une erreur irrécupérable.

Section

Une fois l'élément de charge utile identifié, le processeur examine chaque élément de section dans l'ordre, c'est-à-dire de haut en bas. Aucune correspondance n'est établie à ce niveau. A l'issue du traitement complet d'une section par le processeur (en d'autres termes, aucun des copybooks de la section ne correspond), il passe à la section suivante sans réexaminer les sections précédentes.

Copybook

La dernière phase de correspondance consiste à déterminer le copybook dans cette section qui s'applique en premier, en deuxième, etc., jusqu'à ce que tous les enregistrements dans la charge utile soient traités. Cette phase de correspondance est la plus complexe. Le processus est le suivant :

1. Le processeur examine tous les éléments copybook dans la section et les trie dans l'ordre des numéros spécifiés dans leurs attributs d'ordre.
2. La liste d'éléments copybook avec le numéro d'ordre le plus bas est d'abord vérifiée (dans l'ordre spécifié dans le fichier). La valeur de l'attribut key dans cet élément copybook est recherchée dans la charge utile restante et l'index dans lequel elle a été détectée (le cas échéant) est enregistré. La valeur de l'attribut clé dans cet élément copybook est recherchée dans la charge utile restante et l'index où elle a été détectée (le cas échéant) est enregistré.
3. Une fois que tous les copybooks dans la liste d'ordre le plus bas ont été vérifiés, en cas de correspondance, le plus ancien de la charge utile sera utilisé.
4. En cas de correspondance d'un copybook :
   1. Si une correspondance a déjà été établie pour ce copybook dans cette charge utile (un enregistrement antérieur dans la charge utile), le processeur vérifiera si l'attribut max peut être à nouveau appliqué. Si l'attribut max a été atteint, la correspondance ne sera pas traitée comme telle et la copybook correspondant suivant sera utilisé.
   2. Si l'attribut max n'a pas été atteint, ce copybook sera appliqué à la charge utile et le nombre d'octets spécifiés par le copybook sera consommé. Si un attribut length-field est présent dans le copybook, la valeur de ce champ dans l'enregistrement sera utilisée pour déterminer le nombre d'octets à consommer et le processeur reviendra à l'étape 2.
5. Si aucune correspondance avec un copybook n'est établie, la liste de copybooks avec le numéro d'ordre le plus bas suivant sera vérifiée à l'aide des mêmes règles que celles des étapes 2, 3 et 4. Une fois que le processeur détermine qu'aucun copybook dans une liste de numéros d'ordre donnée ne correspond, il n'effectue aucune nouvelle tentative de traitement de cette liste de numéros d'ordre (pour cette section) pour cette charge utile.
6. Après la vérification de toutes les listes et si aucune correspondance n'est détectée (ou que la charge utile ne contient plus d'octets), le processeur passe à la section suivante.

Finalisation

S'il reste des octets dans la charge utile après le traitement de toutes les sections d'une charge utile, ils seront tronqués.