Partager via

Recevoir des messages de modification des données basées sur l’interrogation dans l’adaptateur Oracle Database

  • Article

L’adaptateur Microsoft BizTalk pour Oracle Database prend en charge la réception de messages de modification des données basées sur l’interrogation en interrogeant la base de données Oracle. L’adaptateur remet les messages à votre application en :

  • Exécution d’une requête SQL SELECT pour déterminer si les données sont disponibles pour l’interrogation. Vous pouvez configurer l’adaptateur pour exécuter la requête SQL SELECT périodiquement ou en continu.

  • Exécution d’une requête SQL SELECT sur une table ou une vue Oracle ou exécution de procédures stockées, de fonctions ou de procédures et fonctions empaquetées.

  • Exécution d’un bloc de code PL/SQL facultatif post-interrogation sur la base de données Oracle. Ce bloc de code est souvent utilisé pour mettre à jour un champ sur les enregistrements interrogés dans la cible ou pour déplacer les enregistrements interrogés vers une autre table ou vue.

  • Le renvoi de la requête aboutit à un jeu de résultats en appelant l’opération POLLINGSTMT ou les procédures stockées, fonctions ou procédures et fonctions empaquetées qui sont exposées en tant qu’opérations d’interrogation.

    L’adaptateur exécute toutes ces opérations à l’intérieur d’une transaction Oracle.

    L’adaptateur vous permet également de recevoir des messages de modifications de données pour plusieurs artefacts Oracle dans la même application en exposant un PollingId paramètre dans l’URI de connexion. Ce paramètre modifie l’espace de noms cible de l’opération POLLINGSTMT.

Modifier l’espace de noms cible de POLLINGSTMT

Vous pouvez modifier l’espace de noms cible de l’opération POLLINGSTMT en définissant le PollingId paramètre de chaîne de requête dans l’URI de connexion. Si un PollingId est spécifié dans l’URI de connexion, l’adaptateur Oracle Database ajoute la chaîne spécifiée dans le PollingId paramètre à l’espace de noms cible par défaut pour l’opération POLLINGSTMT : http://microsoft.lobservices.oracledb/2007/03/POLLINGSTMT. L’action de message de l’opération POLLINGSTMT n’est pas modifiée.

Par exemple, si l’URI de connexion suivant est spécifié : OracleDb://User=SCOTT;Password=TIGER@Adapter?PollingId=AcctActivity, l’espace de noms cible sera http:/microsoft.lobservices.oracledb/2007/03/POLLINGSTMTAcctActivity.

En fournissant un espace de noms unique pour chaque opération POLLINGSTMT, vous pouvez recevoir des messages de modification des données pour plusieurs tables et vues Oracle dans votre application.

Pour plus d’informations sur l’URI de connexion de l’adaptateur Oracle Database, consultez Créer l’URI de connexion Oracle Database.

Recevoir des messages modifiés par des données à l’aide de propriétés de liaison

Vous configurez l’adaptateur Oracle Database pour recevoir des messages modifiés par les données en définissant tout ou partie des propriétés de liaison suivantes.

Binding, propriété Valeur Default Obligatoire ou facultatif
InboundOperationType Vérifiez que la valeur est définie sur Interrogation. Interrogation Obligatoire. Si elle n’est pas explicitement définie, la valeur par défaut s’applique.
PolledDataAvailableStatement Spécifiez l’instruction SELECT exécutée pour déterminer si des données sont disponibles pour l’interrogation d’une table spécifique. L’instruction spécifiée doit retourner un jeu de résultats composé de lignes et de colonnes. La valeur dans la première cellule du jeu de résultats indique si l’adaptateur exécute la valeur spécifiée pour la propriété de liaison PollingStatement . Si la première cellule du résultat contient une valeur positive, l’adaptateur exécute l’instruction d’interrogation. Par exemple, une instruction valide pour cette propriété de liaison sera :

Select * from <table_name>

Note: Vous ne devez pas spécifier de procédures stockées pour cette propriété de liaison. En outre, cette instruction ne doit pas modifier la base de données Oracle sous-jacente.		 SÉLECTIONNER 1 À PARTIR DE DUAL Obligatoire. Si elle n’est pas explicitement définie, la valeur par défaut s’applique, ce qui implique que l’adaptateur doit continuer l’interrogation, que la table interrogée possède ou non des données.
PollingAction Spécifie l’action de l’opération d’interrogation. Vous pouvez déterminer l’action d’interrogation d’une opération spécifique à partir des métadonnées que vous générez pour l’opération à l’aide du complément Consume Adapter Service. null Facultatif pour les opérations d’interrogation sur les tables et les vues à l’aide de l’instruction SELECT.
PollingInterval Définissez sur l’intervalle, en secondes, auquel vous souhaitez que l’adaptateur interroge la base de données Oracle. Cette propriété spécifie l’intervalle d’interrogation et le délai d’expiration de la transaction d’interrogation. La valeur doit être supérieure au temps nécessaire pour exécuter la requête et l’instruction post-interrogation (le cas échéant) sur la base de données Oracle, plus le temps nécessaire au client pour traiter les données de requête et retourner le message de réponse d’interrogation. 500 Obligatoire. Si elle n’est pas explicitement définie, la valeur par défaut s’applique.
PollingStatement Spécifiez l’une des options suivantes :

- Instruction SQL SELECT qui doit être exécutée sur la base de données Oracle. Cette instruction doit inclure une clause FOR UPDATE. Pour plus d’informations sur la clause FOR UPDATE, consultez Spécification d’une clause FOR UPDATE dans l’instruction d’interrogation plus loin dans cette rubrique.

- Message de demande d’une procédure stockée, d’une fonction, d’une procédure ou d’une fonction dans un package que vous souhaitez interroger.		 null Obligatoire. L’attribution d’une valeur non Null à PollingStatement active l’interrogation.
PollWhileDataFound Spécifie si l’adaptateur Oracle Database ignore l’intervalle d’interrogation et interroge continuellement la base de données Oracle, si les données sont disponibles dans la table interrogée. Si aucune donnée n’est disponible dans la table, l’adaptateur rétablit pour exécuter l’instruction SQL à l’intervalle d’interrogation spécifié False Obligatoire. Si elle n’est pas explicitement définie, la valeur par défaut s’applique.
PostPollStatement Définissez sur un bloc de code PL/SQL facultatif qui est exécuté par l’adaptateur après l’exécution de la requête, mais avant que les données de requête ne soient retournées au client. null facultatif. Si aucune valeur n’est spécifiée, une instruction post-interrogation n’est pas exécutée.

Notes

Si vous utilisez le modèle de service WCF ou le modèle de canal WCF, vous devez également définir la propriété de liaison AcceptCredentialsInUri .

Entrez une instruction FOR UPDATE dans l’instruction d’interrogation

Si vous utilisez une instruction SELECT comme instruction d’interrogation et que vous exécutez une instruction post-sondage qui affecte les lignes spécifiées dans l’instruction SELECT, vous devez utiliser la clause FOR UPDATE dans l’instruction d’interrogation. La spécification d’une clause FOR UPDATE garantit que les enregistrements sélectionnés par l’instruction d’interrogation sont verrouillés pendant la transaction et que l’instruction post-interrogation peut effectuer les mises à jour requises sur ceux-ci.

Attention

Vous pouvez avoir des scénarios dans lesquels, dans la fenêtre de temps entre l’interrogation et les instructions post-sondage, d’autres enregistrements sont ajoutés à la table qui répondent à la condition de l’instruction post-sondage. Dans de telles situations, l’instruction post-sondage met à jour tous les enregistrements qui satisfont à la condition, et pas seulement les enregistrements sélectionnés dans le cadre de l’instruction d’interrogation.

Si une instruction post-sondage est spécifiée et que l’instruction d’interrogation ne contient pas de clause FOR UPDATE, vous rencontrerez l’une des deux conditions suivantes :

  • Si TransactionIsolationLevel est défini sur ReadCommitted, la requête post-interrogation ne met pas à jour les lignes sélectionnées.

  • Si TransactionIsolationLevel est défini sur Serializable, l’exception système cible suivante (Microsoft.ServiceModel.Channels.Common.TargetSystemException) se produit lorsque l’instruction post-sondage est exécutée : « ORA-08177 ne peut pas sérialiser l’accès pour cette transaction ». Dans ce cas, vous devez définir la propriété de liaison PollingRetryCount pour définir le nombre de fois où vous souhaitez que l’adaptateur réessaye la même transaction.

    Pour obtenir des instructions sur la définition du niveau d’isolation des transactions, consultez Configurer le niveau d’isolation des transactions et le délai d’expiration des transactions avec Oracle Database.

    Les instructions d’interrogation et de post-interrogation sont exécutées dans une transaction si les clients de l’adaptateur ont configuré pour utiliser des transactions et si la valeur de la propriété de liaison UseAmbientTransaction est définie sur True dans l’adaptateur.

    Voici un exemple de requête d’interrogation avec l’option FOR UPDATE :

SELECT * from EMP WHERE FLAG = 'Y' FOR UPDATE

Entrez une clause NOWAIT dans l’instruction d’interrogation

Vous pouvez avoir des scénarios où des threads simultanés accèdent à la table en cours d’interrogation, ce qui entraîne trop de conflits dans la table. Cela peut entraîner le blocage de la requête d’interrogation pour obtenir un verrou sur les lignes de table. Si vous utilisez une instruction SELECT comme instruction d’interrogation, vous pouvez spécifier un mot clé NOWAIT avec l’mot clé FOR UPDATE dans l’instruction SELECT. Cela entraîne le retour immédiat de l’exécution de la requête d’interrogation dans l’adaptateur s’il existe des verrous sur les lignes que la requête d’interrogation tente de sélectionner. Une exception est généralement levée par Oracle dans de telles conditions. Là encore, les clients d’adaptateur peuvent utiliser la propriété de liaison PollingInterval pour spécifier l’intervalle de temps après lequel les clients de l’adaptateur doivent réessayer d’interroger les données.

Voici un exemple de requête d’interrogation avec l’option NOWAIT :

SELECT * from EMP WHERE FLAG = 'Y' FOR UPDATE NOWAIT

Entrer une clause SKIP LOCKED dans l’instruction d’interrogation

Vous pouvez avoir des scénarios où, en raison de threads simultanés accédant à la table en cours d’interrogation, certaines lignes du jeu de résultats de la clause WHERE spécifiée dans la requête d’interrogation sont verrouillées. Par exemple, votre requête d’interrogation retourne 6 lignes à partir d’une table ; 4 de ces 6 lignes sont déjà verrouillées en raison d’une autre transaction. Dans ce cas, vous pouvez spécifier un mot clé SKIP LOCKED avec le mot clé FOR UPDATE qui indique à la base de données de tenter de verrouiller les lignes spécifiées par la clause WHERE et d’ignorer toutes les lignes déjà verrouillées. Les lignes déverrouillées dans la clause WHERE sont verrouillées pendant la transaction et l’instruction post-interrogation peut effectuer les mises à jour nécessaires afin que ces lignes ne soient pas interrogées à nouveau. Cela garantit que vous n’avez pas à attendre pour recevoir les messages d’interrogation jusqu’à ce que toutes les lignes spécifiées par la clause WHERE soient déverrouillées.

Le mot clé SKIP LOCKED est utile dans un scénario où vous avez des clients d’adaptateur sur plusieurs ordinateurs qui interrogent la même table dans une base de données. Vous pouvez équilibrer la charge entre les clients d’adaptateur en configurant l’opération d’interrogation de telle sorte que vous receviez des messages de modification des données basés sur l’interrogation pour les lignes spécifiées par la clause WHERE qui sont déverrouillées à ce moment-là, puis mettre à jour la ligne pour vous assurer que si un message de modification des données basées sur l’interrogation est reçu par un client d’adaptateur, les autres clients n’obtiennent pas le même message.

Voici un exemple de requête d’interrogation avec l’option SKIP LOCKED :

SELECT * from EMP WHERE FLAG = 'Y' FOR UPDATE SKIP LOCKED

Prise en charge de la livraison commandée (FIFO)

Dans un environnement de production, l’interrogation peut être utilisée pour surveiller les modifications de données dans la base de données Oracle. Ces messages modifiés par les données sont reçus par le client d’adaptateur à l’aide de l’adaptateur Oracle Database. Selon les scénarios métier, il peut être essentiel que les messages modifiés par les données soient reçus par le client de l’adaptateur dans le bon ordre.

L’adaptateur Oracle Database prend en charge la remise ordonnée ou le premier entré en premier sorti (FIFO) pour maintenir l’ordre dans lequel les messages sont reçus de la base de données Oracle. Voici quelques considérations relatives à la prise en charge de FIFO dans les scénarios entrants pour l’adaptateur Oracle Database.

  • Si le message est consommé par une orchestration, la remise ordonnée doit être définie pour les messages provenant du port de réception de l’adaptateur Oracle Database.

  • Si le message est consommé par un port d’envoi (dans un scénario de routage basé sur le contenu), le port d’envoi doit avoir ordonné la remise définie pour les messages provenant du port de réception de l’adaptateur Oracle Database.

    L’adaptateur WCF-Custom ou WCF-OracleDB a une propriété Suspendre le message de demande en cas d’échec qui spécifie s’il faut suspendre le message de demande qui échoue dans le traitement entrant. Cette propriété peut être définie sous l’onglet Messages du port de réception WCF-Custom ou WCF-OracleDB sous la section Gestion des erreurs . Le tableau suivant répertorie les scénarios décrivant comment les messages entrants sont traités selon que cette propriété est définie ou non et l’état de l’abonné au message (orchestration ou port).

Port, propriété Abonné à l’état non listé Abonné dans l’état Inscrit mais Arrêté
Suspendre le message de demande en cas d’échec , propriété NOT set - Le rapport d’échec de routage est généré en tant que message suspendu (message non repris)

- Le message réel n’est pas suspendu

- La requête post-interrogation n’est pas exécutée car la transaction est abandonnée. Par conséquent, l’interrogation se répète et extrait à nouveau les lignes.

- Erreurs signalées dans le journal des événements pour décrire ce qui s’est passé.		 - Non considéré comme un « échec ». Il n’y a aucun message d’erreur dans le journal des événements.

- Le message réel est placé dans la file d’attente suspendue (pouvant être reprise).

- Lorsque le port d’abonnement ou l’orchestration démarre, les messages sont automatiquement repris. Si la livraison commandée est définie sur l’abonné, elle sera honorée.

- Les messages peuvent également être repris manuellement.
Suspend request message on failure property IS set - Le rapport d’échec de routage est généré en tant que message suspendu (message non repris)

- Le message réel est également suspendu

- La requête post-interrogation n’est pas exécutée car la transaction est abandonnée. Par conséquent, l’interrogation se répète et extrait à nouveau les lignes.

- Erreurs signalées dans le journal des événements pour décrire ce qui s’est passé.		 - Non considéré comme un « échec ». Il n’y a aucun message d’erreur dans le journal des événements.

- Le message réel est placé dans la file d’attente suspendue (pouvant être reprise).

- Lorsque le port d’abonnement ou l’orchestration démarre, les messages sont automatiquement repris. Si la livraison commandée est définie sur l’abonné, elle sera honorée.

- Les messages peuvent également être repris manuellement.

Voir aussi

Développer votre application Oracle Database
Interroger Oracle Database à l’aide de BizTalk Server
Recevoir des messages de modification des données basées sur l’interrogation dans Oracle Database à l’aide du modèle de service WCF
Recevoir des messages basés sur des interrogations modifiées de données dans Oracle Database à l’aide du modèle de canal WCF