Recevoir des messages basés sur l’interrogation modifiés des données à partir d’Oracle E-Business Suite

L’adaptateur Microsoft BizTalk pour Oracle E-Business Suite prend en charge la réception de messages basés sur l’interrogation de données modifiées en interrogeant les tables d’interface, les vues d’interface, les tables et les vues. 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 Oracle E-Business Suite. 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 POLL ou les procédures stockées, les fonctions ou les 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.

Comment configurer l’adaptateur Oracle E-Business pour la réception de messages modifiés par des données à l’aide de propriétés de liaison ?

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

Spécification d’une clause FOR UPDATE dans l’instruction 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 eux.

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

• Si TransactionIsolationLevel a la valeur 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-interrogation 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 E-Business Suite.

  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 a la valeur 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  

Spécification d’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 un trop grand nombre 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 une 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 d’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  

Spécification d’une clause SKIP LOCKED dans l’instruction Interrogation

Vous pouvez avoir des scénarios où, en raison de l’interrogation de threads simultanés accédant à la table, 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 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 ordonnée (FIFO)

Dans un environnement de production, l’interrogation peut être utilisée pour surveiller les modifications de données dans Oracle E-Business Suite. Ces messages modifiés par les données sont reçus par le client de l’adaptateur à l’aide de l’adaptateur Oracle E-Business. 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 E-Business prend en charge la livraison ordonnée ou le premier entré, premier sorti (FIFO) pour maintenir l’ordre dans lequel les messages sont reçus d’Oracle E-Business Suite. Voici quelques considérations relatives à la prise en charge de FIFO dans les scénarios entrants pour l’adaptateur Oracle E-Business.

• 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 E-Business.

• 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 une remise ordonnée définie pour les messages provenant du port de réception de l’adaptateur Oracle E-Business.

  L’adaptateur WCF-Custom ou WCF-OracleEBS 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 au traitement entrant. Cette propriété peut être définie sous l’onglet Messages du WCF-Custom ou WCF-OracleEBS port de réception 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).

Voir aussi

Activités de développement
Interroger Oracle E-Business Suite à l’aide de BizTalk Server