Cette section décrit les aspects suivants du traitement des instructions
d'un objet métier :
- La section Détermination des instructions explique comment le connecteur détermine l'instruction
à utiliser pour chaque objet métier source individuel.
- La section Images postérieures et deltas définit les termes et explique comment le connecteur gère
les images postérieures.
- La section Traitement des instructions explique les étapes réalisées par le connecteur lors de la
création, l'extraction, la mise à jour ou la suppression d'un objet
métier.
- La section Instructions SQL explique comment le connecteur utilise les instructions SQL
simples pour les opérations de sélection, de mise à jour, d'extraction ou
de suppression.
- La section Procédures stockées explique comment le connecteur utilise les procédures
stockées.
- La section Validation et annulation de transaction explique brièvement comment le connecteur utilise les blocs
de transaction.
Un objet métier de niveau supérieur et chacun de ses objets métier enfant
individuels peuvent contenir leurs propres instructions. Par
conséquent, un courtier d'intégration peut transmettre au connecteur un
objet métier doté d'instructions différentes pour les objets métier
parent et enfant. Lorsque cela se produit, le connecteur utilise
l'instruction de l'objet métier parent de niveau supérieur pour
déterminer le mode de traitement de l'ensemble de l'objet
métier. Pour plus d'informations, voir Traitement des instructions.
Une image postérieure représente l'état d'un objet
métier après que toutes les modifications ont été apportées. Un
delta est un objet métier utilisé dans une opération de mise à jour
qui contient uniquement les valeurs de clés et les données à modifier.
Dans la mesure où le connecteur prend uniquement en charge les images
postérieures, dès réception d'un objet métier pour sa mise à jour, le
connecteur suppose que l'objet métier représente l'état souhaité des
données après mise à jour.
Par conséquent, lorsqu'un courtier d'intégration envoie au
connecteur un objet métier avec l'instruction Update, le connecteur
modifie la représentation actuelle de l'objet métier dans la base de
données de sorte qu'elle corresponde exactement à l'objet métier
source. Pour ce faire, le connecteur modifie les valeurs
d'attribut simple et ajoute ou supprime des objets métier enfant.
Par exemple, supposons que l'état actuel de l'objet métier
Contract 2345 dans la base de données soit le suivant :

Supposons également que le courtier d'intégration transmette au
connecteur l'objet métier suivant :

Pour procéder à la mise à jour, le connecteur applique les modifications
suivantes à la base de données :
- mise à jour des attributs simples dans les objets métier Contract et
Address de niveau supérieur ;
- création de l'objet métier Phone ;
- mise à jour des attributs simples dans les objets métier enfant A, B, F et
G ;
- suppression des objets métier enfant C, D et E ;
- création des objets métier enfant H, I et J.
Dans la mesure où le connecteur suppose que chaque objet métier provenant
du courtier d'intégration représente une image postérieure, il est
important de veiller à ce que chaque objet métier envoyé à ce connecteur pour
la mise à jour contienne des objets métier enfant existants et valides.
Même si aucun des attributs simples d'un objet métier n'a été
modifié, l'objet métier enfant doit être inclus dans l'objet métier
source.
Vous avez toutefois la possibilité d'empêcher certains connecteurs de
supprimer les objets métier enfant manquants au cours d'une opération de
mise à jour. Vous pouvez utiliser les informations d'application
relatives à l'attribut représentant l'enfant ou le tableau
d'enfants pour demander au connecteur de conserver les objets métier
enfant qui ne sont pas inclus dans l'objet métier source. Pour ce
faire, attribuez au paramètre KEEP_RELATIONSHIP la valeur
true. Pour plus d'informations, voir Spécification de la clé étrangère d'un attribut.
Cette section présente les étapes réalisées par le connecteur lors de la
création, l'extraction, la mise à jour ou de la suppression d'un
objet métier envoyé par un courtier d'intégration. Le connecteur
traite les objets métier hiérarchiques de manière récursive. En
d'autres termes, il procède aux mêmes étapes pour chaque objet métier
enfant jusqu'à ce qu'il ait traité tous les objets métier
individuels.
- Remarque :
- Un objet métier de niveau supérieur correspondant à un encapsuleur prend en
charge les instructions de création, d'extraction, de mise à jour et de
suppression. La seule différence avec le traitement d'un objet
encapsuleur réside dans le fait que seuls les objets contenus dans
l'objet encapsuleur sont traités et non l'objet lui-même.
A différents points du traitement décrit ci-après, le connecteur compare
deux objets métier pour voir s'ils sont identiques. Par exemple,
au cours d'une opération de mise à jour, le connecteur détermine si un
objet métier spécifique existe dans un tableau d'objets métier.
Pour effectuer cette vérification, le connecteur compare l'objet métier
concerné avec chaque objet métier du tableau. Pour que deux objets
métier soient considérés comme identiques, les deux conditions suivantes
doivent être remplies :
- Les objets métier comparés doivent être de type identique. Par
exemple, un objet métier Customer n'est jamais considéré comme identique
à un objet métier Contact même s'ils ont exactement les mêmes
attributs.
- Tous les attributs de clé correspondants dans les deux objets métier
doivent contenir des valeurs identiques. Si un attribut de clé a la
valeur CxIgnore dans les deux objets métier, le connecteur les
considère comme identiques. Toutefois, si un attribut de clé a la
valeur CxIgnore dans l'un des objets métier et non dans
l'autre, les objets métier ne sont pas identiques.
Lors de la création d'un objet métier, le connecteur renvoie
l'état VALCHANGE si l'opération a réussi (que
l'opération ait entraîné ou non des modifications à l'objet métier)
ou FAIL si l'opération a échoué.
Lors de la création d'un objet métier hiérarchique, le connecteur
procède aux étapes suivantes :
- Il insère de manière récursive chaque objet métier enfant de type
cardinalité simple contenu avec des droits de propriété dans la base de
données. En d'autres termes, le connecteur crée l'enfant et
tous les objets métier enfant que l'enfant et ses enfants
contiennent.
Si la définition d'objet métier spécifie qu'un attribut
représente un objet métier enfant de type cardinalité simple et que cet
attribut est vide, le connecteur ignore l'attribut. Toutefois, si
la définition d'objet métier requiert que l'attribut représente un
enfant et que ce n'est pas le cas, le connecteur renvoie un message
d'erreur et met fin au traitement.
- Il traite chaque objet métier enfant de type cardinalité simple contenu
avec des droits de propriété comme suit :
- Il tente de manière récursive d'extraire l'enfant de la base de
données à l'aide des valeurs de clé transmises par le courtier
d'intégration.
- Si l'extraction échoue, indiquant ainsi que l'enfant
n'existe pas actuellement dans la base de données, le connecteur renvoie
un message d'erreur et met fin au traitement. Si l'extraction
réussit, le connecteur met à jour l'objet métier enfant de manière
récursive.
- Remarque :
- Pour permettre à cette approche de fonctionner correctement lorsque
l'objet métier enfant existe déjà dans la base de données de
l'application, veillez à ce que les renvois aux attributs de clé primaire
contenus dans les objets métier enfant soient corrects dans les opérations de
création. Si l'objet métier enfant n'existe pas déjà dans la
base de données de l'application, affectez aux attributs de clé primaire
la valeur CxBlank.
- Il insère l'objet métier de niveau supérieur dans la base de données
comme suit :
- Il affecte à chaque valeur de clé étrangère les valeurs de clé primaire de
l'objet métier enfant correspondant représenté avec le type cardinalité
simple. Dans la mesure où les valeurs des objets métier enfant peuvent
être définies par des compteurs ou des séquences de base de données ou par la
base de données elle-même lors de la création de l'enfant, cette étape
garantit la validité des valeurs de clé étrangère dans le parent avant que ce
dernier ne soit inséré dans la base de données par le connecteur.
- Il génère une nouvelle valeur d'ID unique pour chaque attribut défini
automatiquement par la base de données. Le nom du compteur ou de la
séquence de base de données est stocké dans les informations spécifiques à
l'application de l'attribut. Si un attribut possède un
compteur ou une séquence de base de données qui lui est associé, la valeur
générée par le connecteur remplace toute valeur transmise par le courtier
d'intégration. Pour plus d'informations sur la spécification
d'un compteur ou d'une séquence de base de données, voir UID=AUTO dans Informations spécifiques à l'application pour les attributs simples.
- Il copie la valeur d'un attribut sur la valeur d'un autre
attribut comme indiqué par le paramètre CA (CopyAttribute) des
informations d'application de l'attribut. Pour plus
d'informations sur l'utilisation du paramètre CA, voir
CA=set_attr_name dans Informations spécifiques à l'application pour les attributs simples.
- Il insère l'objet métier de niveau supérieur dans la base de
données.
- Remarque :
- Un objet métier de niveau supérieur correspondant à un encapsuleur ne sera
pas inséré dans la base de données.
- Il traite chaque objet métier enfant de type cardinalité simple qui stocke
la relation parent-enfant dans l'enfant, comme suit :
- Il définit les valeurs de clé étrangère dans l'enfant pour faire
référence à la valeur contenue dans les attributs de clé primaire
correspondants dans le parent. Dans la mesure où les valeurs de clé
primaire du parent ont été générées au cours de la création du parent, la
validité des valeurs de clé étrangère dans chaque enfant est ainsi garantie
avant que l'enfant ne soit inséré dans la base de données.
- Il insère l'enfant dans la base de données.
- Il traite chaque objet métier enfant de type cardinalité multiple comme
suit :
- Il définit les valeurs de clé étrangère dans chaque enfant pour faire
référence à la valeur contenue dans les attributs de clé primaire
correspondant dans le parent. Dans la mesure où les valeurs de clé
primaire du parent ont été générées au cours de la création du parent, la
validité des valeurs de clé étrangère dans chaque enfant est ainsi garantie
avant que l'enfant ne soit inséré dans la base de données.
- Il insère chaque objet métier enfant de type cardinalité multiple dans la
base de données.
Lors de l'extraction d'un objet métier hiérarchique, le
connecteur procède aux étapes suivantes :
- Il supprime tous les objets métier enfant de l'objet métier de niveau
supérieur reçu du courtier d'intégration.
- Il extrait l'objet métier de niveau supérieur de la base de
données.
- Si l'extraction renvoie une ligne, le connecteur poursuit le
traitement.
- Si l'extraction ne renvoie aucune ligne, indiquant que l'objet
métier de niveau supérieur n'existe pas dans la base de données, le
connecteur renvoie la valeur BO_DOES_NOT_EXIST.
- Si l'extraction renvoie plusieurs lignes, le connecteur renvoie la
valeur FAIL.
Remarques :
- Un objet métier peut avoir des attributs qui ne correspondent à aucune
colonne de la base de données, tels que les attributs d'espace
réservé. Lors de l'extraction, le connecteur ne modifie pas ces
attributs dans l'objet métier de niveau supérieur : ils conservent
les valeurs reçues du courtier d'intégration. Dans les objets
métier enfant, le connecteur affecte à ces attributs leurs valeurs par défaut
lors de l'extraction.
- Un objet métier de niveau supérieur correspondant à un encapsuleur doit
contenir toutes les valeurs d'attribut des objets situés au niveau
inférieur immédiat de l'objet encapsuleur car ces valeurs seront
nécessaires pour extraire les objets, notamment les clés et les attributs
d'espace réservé. L'ensemble des clés et attributs
d'espace réservé doit être renseigné dans l'objet
encapsuleur. Les attributs simples de l'objet encapsuleur qui
seront utilisés en tant que clés étrangères dans les objets d'un niveau
inférieur à l'encapsuleur devront être signalés en tant que clés dans
l'objet encapsuleur.
- Il extrait de manière récursive tous les objets métier enfant de type
cardinalité multiple.
- Remarque :
- Le connecteur n'impose pas le caractère unique des valeurs lors du
remplissage d'un tableau d'objets métier. Il en va de la
responsabilité de la base de données d'assurer cette unicité. Si la
base de données renvoie des objets métier enfant en double, le connecteur
renvoie à son tour des enfants en double.
- Il extrait de manière récursive chaque enfant de type cardinalité simple,
que l'objet métier enfant soit contenu avec ou sans droits de
propriété.
- Remarque :
- Tous les objets métier enfant de type cardinalité simple sont traités en
fonction des occurrences dans l'objet métier et avant le traitement de
l'objet métier parent. La propriété ou la non-propriété des objets
enfant ne détermine pas la séquence de traitement mais en détermine le
type.
Une instruction RetrieveByContent est applicable uniquement pour
l'objet métier de niveau supérieur car le connecteur réalise une
extraction en fonction des attributs contenus uniquement dans l'objet
métier de niveau supérieur.
Si un objet métier de niveau supérieur utilise l'instruction
RetrieveByContent, tous les attributs (y compris les attributs non clés) dont
la valeur n'est pas null sont utilisés comme critères
d'extraction.
Si plusieurs lignes sont renvoyées, le connecteur utilise la première ligne
en tant que ligne de résultat et renvoie la valeur
MULTIPLE_HITS.
- Remarque :
- Une instruction RetrieveByContent n'est pas applicable pour un objet
métier de niveau supérieur correspondant à un encapsuleur.
Lors de la mise à jour d'un objet métier, le connecteur renvoie
l'état VALCHANGE si l'opération a réussi (que
l'opération ait entraîné ou non des modifications à l'objet métier)
ou FAIL si l'opération a échoué. Lors de
l'utilisation d'une base de données Oracle, le connecteur verrouille
les données lors de leur extraction afin de garantir leur intégrité.
Lors de la mise à jour d'un objet métier hiérarchique, le connecteur
procède aux étapes suivantes :
- Il utilise les valeurs de clé primaire de l'objet métier source pour
extraire l'entité correspondante de la base de données.
L'objet métier extrait est une représentation exacte de l'état en
cours des données dans la base de données.
- Si l'extraction échoue, indiquant que l'objet métier de niveau
supérieur n'existe pas dans la base de données, le connecteur renvoie la
valeur BO_DOES_NOT_EXIST et la mise à jour échoue.
- Remarque :
- Un objet métier de niveau supérieur correspondant à un encapsuleur ne doit
pas exister dans la base de données. Toutefois, il doit contenir toutes
les valeurs d'attribut des objets situés au niveau inférieur immédiat de
l'objet encapsuleur car ces valeurs seront nécessaires pour extraire les
objets, notamment les clés et les attributs d'espace réservé.
L'ensemble des clés et attributs d'espace réservé doit être
renseigné dans l'objet encapsuleur. Les attributs simples de
l'objet encapsuleur qui seront utilisés en tant que clés étrangères dans
les objets d'un niveau inférieur à l'encapsuleur devront être
signalés en tant que clés dans l'objet encapsuleur.
- Si l'extraction réussit, le connecteur compare l'objet métier
extrait avec l'objet métier source pour déterminer les objets métier
enfant qui requièrent des modifications dans la base de données. Le
connecteur ne doit pas, toutefois, comparer les valeurs contenues dans les
attributs simples de l'objet métier source avec celles contenues dans
l'objet métier extrait. Le connecteur met à jour la valeur de tous
les attributs simples non clés.
Si tous les attributs simples contenus dans l'objet métier de niveau
supérieur représentent des clés, le connecteur ne peut générer aucune requête
de mise à jour pour l'objet métier de niveau supérieur. Dans ce
cas, le connecteur consigne un message d'avertissement et procède à
l'étape 2.
- Il met à jour de manière récursive tous les enfants de type cardinalité
simple de l'objet métier de niveau supérieur.
Si la définition d'objet métier nécessite qu'un attribut
représente un objet métier enfant, l'enfant doit exister à la fois dans
l'objet métier source et dans l'objet métier extrait. Dans le
cas contraire, la mise à jour échoue et le connecteur renvoie un message
d'erreur.
Le connecteur gère les enfants de type cardinalité simple contenus avec des
droits de propriété de l'une des manières suivantes :
- Si l'enfant est présent dans les objets métier source et extrait, le
connecteur supprime l'enfant existant dans la base de données et en crée
un nouveau au lieu de le mettre à jour.
- Si l'enfant est présent dans l'objet métier source et non dans
l'objet métier extrait, le connecteur le crée de manière récursive dans
la base de données.
- Si l'enfant est présent dans l'objet métier extrait et non dans
l'objet métier source, le connecteur le supprime de manière récursive de
la base de données. Le type de suppression, physique ou logique, dépend
de la valeur de la propriété ChildUpdatePhyDelete de l'enfant.
Pour les enfants de type cardinalité simple contenus sans droits de
propriété, le connecteur tente d'extraire chaque enfant de la base de
données présent dans l'objet métier source. S'il parvient à
le faire, le connecteur alimente l'objet métier enfant sans le mettre à
jour dans la mesure où les enfants de type cardinalité simple contenus sans
droits de propriété ne peuvent être modifiés par le connecteur.
- Pour les objets métier enfant de type cardinalité simple qui stockent la
relation dans le parent, le connecteur affecte à chaque valeur de clé
étrangère dans le parent la valeur de la clé primaire contenue dans
l'objet métier enfant de type cardinalité simple correspondant.
Cette étape est nécessaire dans la mesure où des enfants de type cardinalité
simple peuvent avoir été ajoutés à la base de données au cours des étapes
précédentes, entraînant ainsi la création d'ID uniques
supplémentaires.
- Il met à jour tous les attributs simples de l'objet métier extrait à
l'exception de ceux dont l'attribut correspondant dans l'objet
métier source contient la valeur CxIgnore.
Dans la mesure où l'objet métier mis à jour doit être unique, le
connecteur vérifie qu'une seule ligne est traitée en retour. Il
renvoie un message d'erreur si plusieurs lignes sont traitées.
- Il affecte à toutes les valeurs de clé étrangère dans chaque enfant qui
stocke la relation parent-enfant dans l'enfant (de type cardinalité
multiple et simple) la valeur de clé primaire de l'objet métier parent
correspondant. Lorsqu'InterChange Server est utilisé en tant que
courtier d'intégration, ces valeurs sont généralement mises en référence
croisée au cours du mappage des données. Toutefois, cette étape est
importante pour garantir la validité des valeurs de clé étrangère des nouveaux
enfants qui stockent la relation dans l'enfant avant que le connecteur
mette à jour ces enfants.
- Il traite chaque enfant de type cardinalité multiple de l'objet
métier extrait de l'une des manières suivantes :
- Si l'enfant existe dans les tableaux des objets métier source et
extrait, le connecteur le met à jour de manière récursive dans la base de
données.
- Si l'enfant existe dans le tableau de l'objet métier source et
non dans le tableau de l'objet métier extrait, le connecteur le crée de
manière récursive dans la base de données.
- Si l'enfant existe dans le tableau de l'objet métier extrait et
non dans le tableau de l'objet métier source, le connecteur le supprime
de manière récursive de la base de données à moins que la valeur
KEEP_RELATIONSHIP des informations d'application de
l'attribut représentant l'enfant dans le parent soit
true. Dans ce cas, le connecteur ne supprime pas
l'enfant de la base de données. Pour plus d'informations,
voir Spécification de la clé étrangère d'un attribut. Le type de suppression, physique ou logique, dépend
de la valeur de la propriété ChildUpdatePhyDelete de l'enfant.
- Remarque :
- Le courtier d'intégration doit veiller à ce que les objets métier
contenus avec une cardinalité multiple dans l'objet métier source soient
uniques (en d'autres termes, un tableau ne doit pas contenir plusieurs
copies d'un même objet métier). Si le connecteur extrait un objet
métier en double dans un tableau source, il traite l'objet métier deux
fois, ce qui peut entraîner des résultats incertains.
Le traitement de l'instruction DeltaUpdate est différent du traitement
de l'instruction Update sur les points suivants :
- Avec une instruction DeltaUpdate, aucune extraction n'est réalisée
avant la mise à jour, contrairement au traitement de l'instruction
Update.
- Aucune comparaison n'est effectuée entre l'objet métier entrant
et l'objet métier contenu dans la base de données.
- Tous les enfants sont traités en fonction de l'instruction définie
dans chaque objet enfant. Si aucune instruction n'est définie pour
l'un des enfants, le connecteur renvoie un message d'erreur.
Lors de la mise à jour delta d'un objet métier, le connecteur renvoie
l'état VALCHANGE si l'opération a réussi (que
l'opération ait entraîné ou non des modifications à l'objet métier)
ou FAIL si l'opération a échoué.
Lors de la mise à jour delta d'un objet métier hiérarchique, le
connecteur procède aux étapes suivantes :
- Il traite de manière récursive tous les enfants de type cardinalité simple
de l'objet parent. Si un enfant est signalé par la valeur
IsRequired dans la spécification de l'objet métier, il doit être présent
dans l'objet des communications entrantes. Dans le cas contraire,
la mise à jour delta échoue et le connecteur renvoie un message
d'erreur.
- Il affecte à toutes les valeurs de clé étrangère dans le parent qui fait
référence aux attributs contenus dans les enfants de type cardinalité simple
les valeurs des enfants correspondants. Cette étape est nécessaire dans
la mesure où des enfants de type cardinalité simple peuvent avoir été ajoutés
à la base de données au cours des étapes précédentes, entraînant ainsi la
création de valeurs de séquence supplémentaires.
- Il met à jour l'objet courant en cours de traitement via une
instruction SQL UPDATE ou une procédure stockée. Tous les
attributs simples de l'objet métier individuel sont mis à jour, à
l'exception des attributs ayant la valeur IsIgnore dans l'objet
métier des communications entrantes. Le connecteur ne compare pas
l'objet des communications entrantes avec l'objet courant en
fonction des attributs pour déterminer les attributs devant être ajoutés à
l'instruction de mise à jour : ils sont tous mis à jour.
Dans la mesure où l'objet mis à jour doit être unique, le connecteur
vérifie qu'une seule ligne est traitée en retour. Un message
d'erreur est renvoyé si plusieurs lignes sont traitées.
- Il affecte à toutes les valeurs de clé étrangère dans tous les enfants de
cardinalité N de l'objet courant qui fait référence aux attributs parent
les valeurs parent correspondantes. En règle générale, ces valeurs ont
déjà été renvoyées au cours du mappage des données. Cela peut toutefois
ne pas être le cas pour les nouveaux enfants dans les conteneurs de
cardinalité N. La validité de toutes les valeurs de clé étrangère dans
tous les enfants de cardinalité N est ainsi garantie avant la mise à jour de
ces enfants.
- Il met à jour tous les conteneurs de cardinalité N de l'objet
courant.
Lors du traitement des objets enfant, chaque instruction d'enfant est
prise en compte et l'opération appropriée est réalisée. Les
instructions autorisées sur un enfant dans une instruction DeltaUpdate sont
les suivantes : Create, Delete et DeltaUpdate.
- Si une instruction Create est trouvée dans l'enfant, ce dernier est
créé dans la base de données s'il s'agit d'un enfant avec
droits de propriété. Les enfants sans droits de propriétés sont
extraits pour que leur présence soit validée dans la base de données.
- Si une instruction Delete est trouvée dans l'enfant, ce dernier est
supprimé.
- Si une instruction DeltaUpdate est trouvée dans l'enfant, ce dernier
est mis à jour dans la base de données.
Lors de la suppression d'un objet métier, le connecteur renvoie
l'état SUCCESS si l'opération a réussi ou FAIL
si l'opération a échoué. L'objet métier parent est tout
d'abord extrait. Ensuite, l'adaptateur supprime de manière
récursive tous les enfants de type cardinalité simple ayant une relation avec
droits de propriété avec le parent, puis l'objet métier parent lui-même
et enfin tous les enfants de cardinalité N. Les enfants de type
cardinalité simple sans droits de propriété ne sont jamais supprimés.
Si aucun objet métier n'existe, le connecteur renvoie le message
FAIL.
Le connecteur prend en charge la suppression logique et physique, selon la
valeur SCN (Status Column Name) dans les informations spécifiques à
l'application de l'objet. Si la valeur SCN est définie, le
connecteur procède à une suppression logique. Si la valeur SCN
n'est pas définie, le connecteur procède à une suppression
physique.
Lors de la suppression physique d'un objet métier hiérarchique, le
connecteur procède aux étapes suivantes :
- Il supprime de manière récursive tous les objets métier enfant de type
cardinalité simple contenus avec droits de propriétés.
- Il supprime l'objet métier de niveau supérieur.
- Il supprime de manière récursive tous les objets métier enfant de type
cardinalité multiple.
- Remarque :
- Un objet métier de niveau supérieur correspondant à un encapsuleur ne dispose
d'aucune table de base de données correspondante : il ne sera, par
conséquent, pas supprimé de la base de données. Toutes les valeurs
d'attributs simples d'un encapsuleur seront ignorées.
Lors de la suppression logique d'un objet métier, le connecteur
procède aux étapes suivantes :
- Il émet une instruction UPDATE qui affecte à l'attribut
d'état de l'objet métier la valeur spécifiée par les informations
d'application de l'objet métier. Le connecteur vérifie que la
mise à jour concerne une seule ligne de la base de données puis renvoie un
message d'erreur dans le cas contraire.
- Il supprime logiquement tous les enfants de type cardinalité simple
contenus avec droits de propriété et tous les enfants de type cardinalité
multiple de manière récursive. Le connecteur ne supprime pas les
enfants de type cardinalité simple contenus sans droits de propriété.
Le connecteur peut utiliser des instructions SQL simples pour les
opérations de sélection, de mise à jour, d'extraction ou de
suppression. Les noms des colonnes relatives aux instructions SQL
proviennent de la propriété AppSpecificInfo d'un
attribut. Chaque requête couvre une seule table, à moins qu'elle
ne désigne une vue.
Une procédure stockée est un groupe d'instructions SQL formant une
unité logique et réalisant une tâche spécifique. Une procédure stockée
rassemble un ensemble d'opérations ou de requêtes que le connecteur doit
exécuter sur un objet dans un serveur de base de données.
Le connecteur fait appel aux procédures stockées dans les cas suivants
:
- avant le traitement d'un objet métier pour réaliser les processus
opérationnels préparatoires ;
- après le traitement d'un objet métier pour réaliser les processus
post-opérationnels ;
- pour réaliser un ensemble d'opérations sur un objet métier, au lieu
d'utiliser une simple instruction INSERT, RETRIEVE,
UPDATE ou DELETE.
Lors du traitement d'un objet métier hiérarchique, le connecteur peut
utiliser une procédure stockée pour traiter l'objet métier de niveau
supérieur ou l'un de ses objets métier enfant. Toutefois, chaque
objet métier ou tableau d'objets métier doit avoir sa propre procédure
stockée.
Cette section décrit les étapes à entreprendre pour obliger le connecteur à
utiliser une procédure stockée pour un objet métier. Elle contient les
sections suivantes :
Vous devez ajouter une catégorie spécifique d'attributs à l'objet
métier pour chaque type de procédure stockée traitée par le connecteur.
Ces attributs représentent uniquement le type de procédure stockée et les
informations spécifiques à l'application qui la définissent. Ces
attributs n'utilisent pas les paramètres des informations spécifiques à
l'application disponibles pour un attribut simple standard.
Nommez l'attribut en fonction du type de procédure stockée à
utiliser. Par exemple, pour obliger le connecteur à utiliser les
procédures stockées AfterUpdate et BeforeRetrieve, ajoutez les attributs
AfterUpdateSP et BeforeRetrieveSP.
Le connecteur reconnaît les noms d'attributs d'objets métier
suivants :
BeforeCreateSP
AfterCreateSP
CreateSP
BeforeUpdateSP
AfterUpdateSP
UpdateSP
BeforeDeleteSP
AfterDeleteSP
DeleteSP
BeforeRetrieveSP
AfterRetrieveSP
RetrieveSP
BeforeRetrieveByContentSP
AfterRetrieveByContentSP
RetrieveByContentSP
BeforeRetrieveUpdateSP
AfterRetrieveUpdateSP
RetrieveUpdateSP
BeforeDeltaUpdateSP
AfterDeltaUpdateSP
DeltaUpdateSP
- Remarque :
- Créez un attribut uniquement pour les procédures stockées que vous souhaitez
que le connecteur exécute. Utilisez les informations spécifiques à
l'application ou le mappage (uniquement si InterChange Server est utilisé
en tant que courtier d'intégration) pour spécifier les valeurs de ces
attributs avant que l'objet métier ne soit envoyé au connecteur.
Le connecteur doit être redémarré pour prendre en compte les modifications
apportées à ces valeurs pour les appels ultérieurs sur un objet métier.
La syntaxe utilisée pour spécifier une procédure stockée est la suivante
:
SPN=StoredProcedureName;RS=true|false[;IP=Attribute_Name1[:Attribute_Name2[:...]]]
[;OP=Attribute_Name1| RS[:Attribute_Name2| RS[:...]]]
[;IO=Attribute_Name1[:Attribute_Name2[:...]]]
où :
- StoredProcedureName
- Nom de la procédure stockée.
- RS
- A la valeur true si la procédure stockée renvoie un ensemble de
résultats, ou false dans le cas contraire. La valeur par
défaut est false. Si la valeur est true, la
propriété ColumnName contenue dans les informations
d'application d'un attribut désigne la colonne appropriée dans
l'ensemble de résultats. Si le paramètre RS fait partie de la
liste des paramètres de sortie, ce paramètre spécifique renvoie un ensemble de
résultats. Un seul paramètre OUT pour l'ensemble de
résultats est pris en charge. Si plusieurs ensembles de résultats sont
renvoyés sous la forme d'un paramètre OUT, seul le premier
ensemble de résultats est renvoyé et les autres sont ignorés.
Actuellement, cette fonction est prise en charge pour Oracle 8i et versions
ultérieures et pour les procédures stockées qui utilisent le pilote JDBC
Oracle. Pour la procédure stockée dans la base de données, le paramètre
correspondant doit renvoyer un type REFCURSOR.
- IP
- Input Parameters (paramètres d'entrée) : liste des attributs
d'objets métier dont le connecteur doit utiliser les valeurs en tant que
valeurs d'entrée lors de l'exécution de la procédure stockée.
- OP
- Output Parameters (paramètre de sortie) : liste des attributs
d'objets métier auxquels le connecteur doit renvoyer les valeurs après
l'exécution de la procédure stockée. Voir le paramètre RS pour
obtenir une description de l'ensemble de résultats.
- IO
- InputOutput Parameters (paramètres d'entrée-sortie) : liste des
attributs d'objets métier dont le connecteur doit utiliser les valeurs en
tant que valeurs d'entrée et auxquels le connecteur doit renvoyer les
valeurs après l'exécution de la procédure stockée.
L'ordre des valeurs StoredProcedureName, RS et
des paramètres est important, alors que l'ordre des paramètres entre eux
ne l'est pas. En d'autres termes, cela ne fait aucune
différence pour le connecteur si la procédure stockée regroupe tous les
paramètres de chaque type ou qu'elle disperse les types de
paramètre. Lorsque plusieurs paramètres de même type sont regroupés
ensemble, séparez les valeurs par deux-points (:). Il n'est
pas nécessaire de répéter le type de paramètre pour chaque valeur.
Séparez les paramètres de types différents par un point virgule.
Lorsque vous indiquez des valeurs de paramètre, n'insérez aucun espace de
chaque côté du signe égal (=).
Les exemples suivants utilisent les procédures stockées nommées
CustomerAddressRetrieve et
CustomerAddressRetrieveForOracleDB pour renvoyer un ensemble de
résultats qui contient plusieurs adresses et qui est utilisé pour créer un
objet métier enfant de cardinalité N.
- Remarque :
- Les ensembles de résultats sont traités pour l'attribut RetrieveSP
uniquement et sont utilisés pour créer un objet métier enfant de cardinalité
N.
Pour les bases de données Oracle, l'ensemble de résultats est renvoyé
en tant que paramètre de sortie et est traité en conséquence par
l'adaptateur. Pour les autres bases de données, l'ensemble de
résultats est une valeur de retour provenant de la procédure stockée.
- CustomerAddressRetrieve (pour les bases de données autres que Oracle)
Attribute : RetrieveSP
ASI : SPN=CustomerAddressRetrieve;RS=true;IP=CustomerName:IP=Customerld;
OP=ErrorStatus;OP=ErrorMsg
- CustomerAddressRetrieveForOracleDB (pour les bases de données Oracle)
Attribute : RetrieveSP
ASI : SPN=CustomerAddressRetrieveForOracleDB;RS=true;IP=CustomerName:
IP=Customerld;OP=RS;OP=ErrorStatus;OP=ErrorMsg
(OP=RS signifie que le premier paramètre de sortie est un
ensemble de résultats)
Les exemples suivants utilisent les procédures stockées nommées
CustomerInsert et VendorInsert qui obtiennent des
valeurs auprès de deux attributs d'entrée et renvoient ces valeurs à
quatre attributs de sortie. Ces exemples illustrent différentes
structures de procédures stockées.
- Les paramètres de même type sont regroupés ensemble (IP, IP, OP, OP, OP,
OP, IO) :
SPN=CustomerInsert;RS=false;IP=LastName:FirstName;OP=CustomerName:
CustomerID:ErrorStatus:ErrorMessage;IO=VendorID
- Les paramètres de même type sont dispersés (IP, OP, OP, OP, IP, IO, OP)
:
SPN=VendorInsert;RS=false;IP=LastName;OP=CustomerName:
CustomerID:ErrorStatus;IP=FirstName;IO=VendorID;OP=ErrorMessage
Le connecteur prend en charge uniquement les types de données simples pris
en charge par le pilote JDBC.
Il existe deux méthodes pour spécifier le nom de la procédure stockée et
ses valeurs de paramètre :
- Propriété AppSpecificInfo de l'attribut
Si la longueur du texte qui spécifie la procédure stockée est inférieure ou
égale à 4000 octets, vous pouvez spécifier la valeur dans la propriété
AppSpecificInfo de l'attribut. Vous pouvez utiliser
cette propriété pour spécifier la procédure stockée, que le connecteur ait
lancé une requête pour rechercher l'objet métier (en d'autres
termes, l'objet métier représente un événement d'application) ou
qu'il ait reçu l'objet métier en tant que requête du courtier
d'intégration.
L'exemple suivant illustre la spécification de la procédure stockée
dans les informations spécifiques à l'application. Dans ce cas, la
valeur spécifiée pour la propriété MaxLength n'a aucune
importance pour la procédure stockée.
[Attribute]
Name = BeforeCreateSP
Type = String
MaxLength = 15
IsKey = false
IsRequired = false
AppSpecificInfo = SPN=ContactInsert;IP=LastName:FirstName;OP=CustomerName:
CustomerID:ErrorStatus:ErrorMessage
[End]
- Valeur d'attribut (pertinente uniquement si InterChange Server est
utilisé en tant que courtier d'intégration)
Si la longueur du texte qui spécifie la procédure stockée est supérieure à
4000 octets, vous devez utiliser le mappage pour spécifier la procédure
stockée. Vous pouvez utiliser le mappage pour spécifier la procédure
stockée uniquement si l'objet métier représente une requête du courtier
d'intégration. En d'autres termes, vous ne pouvez pas
utiliser la valeur d'un attribut pour spécifier une procédure stockée
lorsque le connecteur recherche des événements.
Si la longueur du texte de la procédure stockée est supérieure à 4000
octets et que vous utilisez le mappage pour la spécifier, n'oubliez pas
d'augmenter la valeur de la propriété MaxLength pour
l'adapter au texte intégral.
- Remarque :
- Si une procédure stockée qui gère une opération de création, de mise à jour
ou de suppression est exécutée sur un objet métier hiérarchique contenant un
tableau d'objets métier enfant, le connecteur traite chaque objet métier
enfant individuellement. Par exemple, si le connecteur exécute une
procédure stockée BeforeCreate, il ne traite pas le tableau en tant
qu'unité mais traite chaque membre de ce tableau. Lorsqu'il
traite une procédure stockée BeforeRetrieve, le connecteur agit sur
un seul objet métier. Lorsqu'il traite une procédure stockée
AfterRetrieve, le connecteur agit sur tous les objets métier
renvoyés par l'extraction.
Les sections suivantes expliquent comment le connecteur traite les
procédures stockées :
Une procédure stockée de création renvoie généralement les valeurs
utilisées par le connecteur pour renseigner les attributs simples dans
l'objet métier de niveau supérieur. Le connecteur procède comme
suit lors du traitement des procédures stockées de création
(BeforeCreate, Create, AfterCreate) :
- Il vérifie que l'objet métier contient un attribut
BeforeCreateSP. Le cas échéant, il appelle la procédure
stockée BeforeCreate.
- Si la procédure stockée renvoie des valeurs via les paramètres de sortie,
il utilise ces valeurs pour définir la valeur des attributs simples dans
l'objet métier.
- Il crée les objets métier enfant de type cardinalité simple.
- Il affecte à chacune des valeurs de clé étrangère de l'objet métier de
niveau supérieur la valeur de clé primaire de chaque objet métier enfant de
type cardinalité simple.
- Il vérifie que l'objet métier contient un attribut
CreateSP. Le cas échéant, il appelle la procédure stockée
Create pour créer l'objet métier de niveau supérieur.
Dans le cas contraire, il génère et exécute une instruction INSERT
pour créer l'objet métier de niveau supérieur.
- Si la procédure stockée Create renvoie des valeurs via les
paramètres de sortie, il utilise ces valeurs pour définir la valeur des
attributs simples dans l'objet métier.
- Il affecte à la valeur de clé étrangère de chaque enfant de type
cardinalité multiple la valeur de l'attribut de clé primaire de leur
parent.
- Il crée les objets métier enfant de type cardinalité multiple.
- Il vérifie que l'objet métier contient un attribut
AfterCreateSP. Le cas échéant, il appelle la procédure
stockée AfterCreate.
- Si la procédure stockée renvoie des valeurs via les paramètres de sortie,
il utilise ces valeurs pour définir les valeurs des attributs simples dans
l'objet métier.
Le connecteur peut utiliser les valeurs renvoyées à l'étape 10 pour
modifier les valeurs d'un objet métier créé au cours des étapes 3 ou
5.
Une procédure stockée de mise à jour renvoie généralement les valeurs
utilisées par le connecteur pour renseigner les attributs simples dans
l'objet métier de niveau supérieur. Le connecteur procède comme
suit lors du traitement des procédures stockées de mise à jour
(BeforeUpdate, Update, AfterUpdate) :
- Il vérifie que l'objet métier contient un attribut
BeforeUpdateSP. Le cas échéant, il appelle la procédure
stockée BeforeUpdate.
- Si la procédure stockée BeforeUpdate renvoie des valeurs via
les paramètres de sortie, il utilise ces valeurs pour définir la valeur des
attributs simples dans l'objet métier.
- Il met à jour les objets métier enfant de type cardinalité simple.
- Il affecte à chacune des valeurs de clé étrangère de l'objet métier de
niveau supérieur la valeur de clé primaire de chaque objet métier enfant
contenu de type cardinalité simple.
- Il vérifie que l'objet métier contient un attribut
UpdateSP. Le cas échéant, il appelle la procédure stockée
Update pour mettre à jour l'objet métier de niveau
supérieur. Dans le cas contraire, il génère et exécute une instruction
UPDATE pour mettre à jour l'objet métier de niveau
supérieur.
- Si la procédure stockée Update renvoie des valeurs via les
paramètres de sortie, il utilise ces valeurs pour définir la valeur des
attributs simples dans l'objet métier.
- Il définit les valeurs de clé étrangère dans les enfants de type
cardinalité multiple pour faire référence à la valeur contenue dans les
attributs de clé primaire correspondants dans le parent.
- Il met à jour les objets métier enfant de type cardinalité
multiple.
- Il vérifie que l'objet métier contient un attribut
AfterUpdateSP. Le cas échéant, il appelle la procédure
stockée AfterUpdate.
- Si la procédure stockée renvoie des valeurs via les paramètres de sortie,
il utilise ces valeurs pour définir la valeur des attributs simples dans
l'objet métier.
Une procédure stockée de suppression ne renvoie pas les valeurs au
connecteur. Le connecteur procède comme suit lors du traitement des
procédures stockées de suppression (BeforeDelete,
Delete, AfterDelete) :
- Il vérifie que l'objet métier contient un attribut
BeforeDeleteSP. Le cas échéant, il appelle la procédure
stockée BeforeDelete.
- Il supprime les objets métier enfant de type cardinalité simple.
- Il supprime les objets métier enfant de type cardinalité multiple.
- Il vérifie que l'objet métier contient un attribut
DeleteSP. Le cas échéant, il appelle la procédure stockée
Delete pour supprimer l'objet métier de niveau supérieur. Dans le
cas contraire, il génère et exécute une instruction DELETE.
- Il vérifie que l'objet métier contient un attribut
AfterDeleteSP. Le cas échéant, il appelle la procédure
stockée AfterDelete.
Pour les opérations d'extraction simples, les procédures stockées
peuvent être utilisées pour l'objet métier de niveau supérieur, pour les
enfants de type cardinalité simple ainsi que pour les enfants de type
cardinalité multiple. L'ordre des procédures est le suivant
:
- BeforeRetrieve
- Retrieve
- AfterRetrieve
Le connecteur crée un objet temporaire pour extraire un objet métier enfant
de type cardinalité simple ou multiple. Le connecteur applique ensuite
la procédure stockée BeforeRetrieve à l'objet métier
temporaire. La procédure stockée AfterRetrieve est alors
appliquée à chaque objet enfant extrait pour le conteneur.
Le connecteur exécute la procédure stockée AfterRetrieve après
avoir exécuté une requête Retrieve générée dynamiquement à partir
des métadonnées de l'objet métier ou de la procédure stockée sur
l'objet métier.
Selon la spécification JDBC, il existe trois types d'appel
StoredProcedure comme suit :
- {call <spName>(?,?,?)}
- {call <spName>}
- {?= call <spName>(?,?,?)}
où spName désigne le nom de la procédure stockée.
Le connecteur prend en charge les deux premiers types. Il traitera
le paramètre ResultSet renvoyé par l'appel
StoredProcedure.
Si RS=true dans la syntaxe de la procédure stockée,
l'ensemble de résultats provenant de la procédure stockée est
traité. Si RS=false, l'ensemble de résultats n'est
pas traité. La valeur par défaut du paramètre RS est
false. Une fois les valeurs de l'ensemble de résultats
traitées, les variables de sortie de la procédure stockée sont
traitées. Si RS=true, les enfants de type cardinalité
multiple ne peuvent pas spécifier les variables de sortie dans la procédure
stockée associée.
- Remarque :
- Le traitement de l'ensemble de résultats est pris en charge uniquement
pour les opérations de l'instruction Retrieve et de l'attribut
RetrieveSP.
Le paramètre ResultSetMetaData est obtenu pour l'ensemble
de résultats renvoyé par la procédure stockée. Les valeurs de toutes
les colonnes contenues dans l'ensemble de résultats sont obtenues et
définies sur l'attribut correspondant de l'objet métier. La
propriété ColumnName des informations d'application d'un attribut
doit contenir le nom de la colonne ResultSet pour faire correspondre
l'attribut et la colonne.
Pour les objets de type cardinalité simple, l'ensemble de résultats
correspondant ne doit contenir qu'une seule ligne. Si plusieurs
lignes sont renvoyées dans l'ensemble de résultats, un message
d'erreur est signalé.
Pour les enfants de type cardinalité multiple, plusieurs lignes peuvent
être renvoyées via l'ensemble de résultats. Pour chaque ligne
renvoyée, un objet est créé et ajouté au conteneur. Le conteneur est
ensuite ajouté à l'objet parent à l'index d'attribut
obligatoire.
L'enfant de cardinalité N d'un objet métier encapsuleur possède
les attributs de la procédure stockée qui représentent les paramètres
d'entrée et les colonnes de l'ensemble de résultats. Le
paramètre WRAPPER=true est défini au niveau des informations
spécifiques à l'application de l'objet métier. Les
informations d'application de l'objet métier enfant ont la valeur
TN=dummy.
Pour les opérations RetrieveByContent simples, les procédures
stockées peuvent uniquement être utilisées pour l'objet métier de niveau
supérieur et ses enfants de type cardinalité simple. En d'autres
termes, elles ne peuvent pas être utilisées pour renvoyer un ensemble de
résultats ou plusieurs lignes. L'ordre des procédures est le
suivant :
- BeforeRetrieveByContent
- RetrieveByContent
- AfterRetrieveByContent
Le connecteur crée un objet temporaire pour extraire un objet métier enfant
de type cardinalité simple ou multiple. Pour les objets métier de type
cardinalité multiple, le connecteur applique ensuite la procédure stockée
BeforeRetrieveByContent à l'objet métier temporaire. La
procédure stockée AfterRetrieveByContent est alors appliquée à
chaque objet enfant extrait pour le conteneur.
Le connecteur exécute la procédure stockée
AfterRetrieveByContent après avoir exécuté une requête
RetrieveByContent générée dynamiquement à partir des métadonnées de
l'objet métier ou de la procédure stockée sur l'objet métier.
Dans ce cas, bien que l'extraction d'un objet métier hiérarchique
entraîne également l'extraction de ses objets métier enfant, le
connecteur exécute la procédure stockée AfterRetrieveByContent sur
chaque objet métier présent dans le tableau.
Les procédures stockées suivantes sont appelées sur l'objet métier de
niveau supérieur et extraient tous les objets métier enfant de la même manière
que lorsqu'il s'agit de l'instruction simple
Retrieve.
L'ordre des procédures est le suivant :
- BeforeRetrieveUpdate
- RetrieveUpdate
- AfterRetrieveUpdate
Ces procédures stockées procèdent aux mêmes opérations que les procédures
BeforeRetrieve et AfterRetrieve. Elles portent un
nom distinctif pour que vous puissiez créer des attributs distincts afin
d'obliger le connecteur à exécuter les opérations
BeforeRetrieve et BeforeRetrieveUpdate, ainsi que les
opérations AfterRetrieve et AfterRetrieveUpdate.
Le connecteur crée un objet temporaire pour extraire un objet métier enfant
de type cardinalité simple ou multiple. Pour les objets métier de type
cardinalité multiple, le connecteur applique ensuite la procédure stockée
BeforeRetrieveUpdate à l'objet métier temporaire. La
procédure stockée AfterRetrieveUpdate est alors appliquée à chaque
objet enfant extrait pour le conteneur.
Le connecteur exécute la procédure stockée AfterRetrieveUpdate
après avoir exécuté une requête RETRIEVE générée dynamiquement à
partir des métadonnées de l'objet métier ou de la procédure stockée sur
l'objet métier. Dans ce cas, bien que l'extraction d'un
objet métier hiérarchique entraîne également l'extraction de ses objets
métier enfant, le connecteur exécute la procédure stockée
AfterRetrieveUpdate sur chaque objet métier présent dans le
tableau.
Chaque fois que le connecteur reçoit un objet métier à traiter, il commence
un bloc de transactions. Toutes les instructions SQL que le
connecteur exécute lors du traitement de cet objet métier sont regroupées dans
le bloc de transactions. Une fois le traitement de l'objet métier
terminé, le connecteur valide le bloc de transactions si le traitement est une
réussite ou l'annule s'il rencontre une erreur.
