Partager via

Problèmes connus pour Microsoft BizTalk Accelerator pour RosettaNet (BTARN)

  • Article

Cette section contient des informations utiles qui peuvent vous aider à éviter les erreurs avec Microsoft® BizTalk Accelerator pour RosettaNet (BTARN). Les problèmes connus sont regroupés dans les zones suivantes :

  • 0A1 Notification d’échec

  • BAM (Business Activity Monitoring)

  • Installation et configuration

  • Divers

0A1 Notification d’échec

BTARN n’effectue pas de validation inter-champs pour la propriété de configuration de processus CIDX et la propriété de contrat 0A1

BTARN ne vous empêche pas de définir la propriété « Standard » pour un profil de configuration de processus sur « CIDX », une fois que vous avez défini la propriété « 0A1 agreement » pour un contrat utilisant ce profil sur « 0A1 », même si un CIDX ne prend pas en charge les contrats 0A1.

Analyse BAM (Business Activity Monitoring)

Les données de colonne dupliquées apparaissent dans les rapports d’analyse de l’activité métier

Les colonnes ActivityID et PIPInstanceID dans les rapports web d’activités BAM contiennent le même contenu. Ces données reflètent avec précision l’identificateur de instance du processus d’interface partenaire (PIP). ActivityID utilise cette valeur pour la corrélation interne. Ignorez ce message.

Colonnes de données vides dans les rapports web de surveillance de l’activité métier

Les rapports web bam (Business Activity Monitoring) ne contiennent pas de données pour les processus de message 0A1. Les colonnes de message 0A1 dans les rapports Web sont codées en dur avec « Initial 0A1 ».

Installation et configuration

Les groupes et les utilisateurs du groupe Utilisateurs de l’application BizTalk et du groupe Administrateurs BizTalk Server doivent se trouver dans le même domaine

BTARN prend en charge l’ajout d’un groupe au groupe Utilisateurs de l’application BizTalk ou BizTalk Server groupe Administrateurs. Toutefois, les comptes d’utilisateurs individuels et les groupes qui appartiennent au groupe Utilisateurs de l’application BizTalk ou au groupe Administrateurs BizTalk Server doivent faire partie du même domaine.

La désinstallation de BTARN échoue si BizTalk Server est supprimé en premier

Si vous supprimez BizTalk Server avant de supprimer BTARN, le processus de suppression BTARN échoue sans erreur. Pour résoudre ce problème, réinstallez et reconfigurez BizTalk Server, puis supprimez BTARN.

Le déploiement distribué nécessite un contrôleur de domaine

Le déploiement de BTARN dans un environnement multiserveur nécessite un contrôleur de domaine, par exemple, lorsque vous avez installé BTARN sur un serveur et que les bases de données SQL Server utilisées pour la configuration sur un autre serveur.

Les configurations PIP personnalisées ne sont pas prises en charge

La version actuelle de BTARN ne prend pas en charge la configuration des piPs avec des éléments personnalisés ou d’autres informations standard non RosettaNet.

BTARN démarre automatiquement le service single Sign-On

BTARN démarre automatiquement l'Sign-On authentification unique (SSO) dans un événement où BTARN en a besoin et que le service d’authentification unique n’est pas en cours d’exécution.

Le programme de configuration ne supprime pas les répertoires virtuels BTARN de la liste des chemins exclus lorsque WebApps n’est pas configuré pour le site Web par défaut

Si vous annulez la configuration d’une installation BTARN dans laquelle le dossier virtuel de l’application web a été configuré pour être SharePoint Server, et non site web par défaut, après la configuration, vous devrez supprimer manuellement les répertoires virtuels btarnapp et btarnhttpreceive de la liste Chemins d’accès exclus dans le site Administration centrale de SharePoint. Cela se produit car lorsque vous configurez le dossier virtuel de l’application web sur SharePoint Server, vous devez ajouter manuellement btarnapp et btarnhttpreceive à la liste Chemins d’accès exclus. Le programme de configuration ne pourra pas les supprimer automatiquement de la liste Chemins exclus.

Divers

BTARN recevra des messages chiffrés dans l’un ou l’autre algorithme de chiffrement

Le pipeline de réception BTARN reçoit et déchiffre un message même si le protocole utilisé pour chiffrer le message et le paramètre Encodage dans ce champ ne correspondent pas. Par conséquent, BTARN reçoit les messages chiffrés dans RC2-40 ou 3DES.

BTARN nécessite un signal dans un scénario synchrone à action unique

Dans un scénario synchrone à action unique, BTARN attend toujours et génère des signaux. Ce comportement est différent de la spécification RosettaNet selon laquelle un signal peut être requis ou non dans un scénario synchrone à action unique. Si BTARN est un répondeur, il génère toujours un signal en réponse à un message de l’initiateur. Si BTARN est un initiateur, il attend toujours un signal de retour de la part du répondeur. Si BTARN ne reçoit pas de signal, il expire après l’intervalle spécifié dans la Time To Perform propriété dans les paramètres de configuration du processus et génère un message 0A1.

BTARN prend en charge UTF-16 dans les messages reçus

BTARN reçoit et traite les messages qui ont un jeu de caractères UTF-16. BTARN envoie des messages avec un jeu de caractères UTF-8.

Les espaces de noms doivent être supprimés des messages de réponse mappés à partir des messages de demande

Si vous utilisez le mappeur BizTalk dans le processus privé d’un scénario de double action, le mappeur BizTalk ajoute des espaces de noms à certaines balises d’élément dans les instances de message de réponse mappées à partir de messages de requête. Ces espaces de noms provoquent un échec dans le pipeline d’envoi. Vous devez supprimer ces espaces de noms. Utilisez l’exemple HeaderHelper pour ce faire. Pour plus d’informations, consultez Double Action PIPAutomation Orchestration [RN3] et Step 4 : Creating the HeaderHelper Project [RN3].

La modification des paramètres d’URI nécessite IISRESET

Lors de l’exécution du programme d’installation, vous définissez les paramètres d’URI utilisés par les pages .aspx de réception et d’envoi, ainsi que les paramètres d’URI des adaptateurs de réception et d’envoi. Vous devez modifier ces paramètres si vous modifiez le nom de l’ordinateur sur lequel les pages .aspx ou les adaptateurs sont installés. Vous pouvez modifier ces paramètres en ré-exécutant le processus de configuration, mais cela nécessite une réinitialisation de tous les paramètres de configuration. Vous pouvez modifier les paramètres d’URI seuls en modifiant les clés de Registre associées (AsyncReceivePortURI, RNIFSenderURI, et SyncReceivePortURI). Après avoir modifié l’un de ces paramètres de Registre, vous devez exécuter IISRESET pour que les modifications prennent effet. En effet, BTARN met en cache les paramètres pour son utilisation. Après avoir exécuté IISRESET, vous devez également redémarrer les services BizTalk.

BTARN n’applique pas de restrictions sur les énumérations RNIF v1.1

La spécification RosettaNet Implementation Framework (RNIF) v1.1 spécifie des restrictions sur certaines énumérations de schéma RNIF. BTARN n’applique pas ces restrictions et ne valide pas par rapport à ces restrictions. Les restrictions ne s’appliquent pas à RNIF v2.01.

Cela est vrai pour les éléments d’en-tête de service suivants :

  • GlobalBusinessActionCode

  • GlobalPartnerClassificationCode

  • GlobalBusinessServiceCode

  • GlobalProcessCode

  • GlobalProcessIndicatorCode

  • VersionIdentifier

Les paramètres PerformanceControlRequest ne remplacent pas les paramètres de configuration de processus par défaut

Les messages entrants peuvent contenir des PerformanceControlRequest paramètres dans l’en-tête de service. Ces paramètres incluent des valeurs pour les paramètres de délai de délai de temps d’accusé de réception et de délai d’exécution, tels que définis dans les paramètres de configuration de processus définis dans la console de gestion BTARN. BTARN ne définit pas dynamiquement les délais en fonction des PerformanceControlRequest paramètres du message entrant. BTARN prend toujours les délais à partir des valeurs PIP par défaut définies dans les paramètres de configuration du processus. Cela suit la spécification RosettaNet Implementation Framework (RNIF) v1.1.

Le nom PIP et la version PIP des messages à double action respectent la casse

Si le nom PIP et la version PIP d’un message de réponse ont une casse différente des valeurs correspondantes du message de demande à double action d’origine, l’initiateur BTARN rejette le message de réponse comme non valide et retourne une exception au répondeur.

BTARN ne prend pas en charge la modification des paramètres d’accord lorsqu’il existe des processus actifs

Les modifications apportées aux propriétés du contrat s’appliquent dès que vous cliquez sur Appliquer ou SUR OK pour les accepter. Une fois que vous avez modifié un contrat, toute nouvelle activité dans un processus déjà en cours d’exécution ou tout nouveau processus impliquant ce contrat utilise les propriétés modifiées de l’accord. Si un processus était en cours d’exécution lorsque vous avez modifié le contrat, il a peut-être déjà utilisé les propriétés du contrat précédent pour un message. Les nouveaux messages pour ce processus utilisent les nouveaux paramètres d’accord, ce qui peut générer des résultats imprévisibles. Il est recommandé de modifier les paramètres du contrat lorsqu’aucun processus n’est en cours d’exécution.

BTARN n’effectue pas de validation inter-champs après des modifications apportées à un profil de configuration de processus

Lorsque vous créez un profil de configuration de processus, puis créez un contrat, BTARN effectue une validation inter-champs pour s’assurer que les propriétés du contrat et du profil sont compatibles. Par exemple, il vérifie que pour un profil avec la propriété Standard définie sur « CIDX », la propriété de contrat 0A1 du contrat est définie sur « No 0A1 ». Toutefois, si vous modifiez un profil de configuration de processus après avoir créé un contrat, BTARN n’effectue pas de validation inter-champs. Si vous modifiez la propriété Standard de « RosettaNet » en « CIDX », BTARN ne vérifie pas que la propriété de contrat 0A1 du contrat est définie sur « No 0A1 ».

Des erreurs se produit si toutes les orchestrations ne sont pas démarrées

Le programme d’installation BTARN installe neuf orchestrations. Pour que BTARN traite correctement les messages, vous devez lier, inscrire et démarrer les neuf orchestrations avant de lancer le traitement. Pour plus d’informations, consultez les rubriques « Gestion de l’orchestration dans BizTalk Explorer » ou « Gestion des orchestrations » dans BizTalk Server aide.

RNIFReceive.aspx ne supprime pas la limite inférieure MIME d’un message

Lorsque la page RNIFReceive.aspx reçoit un message d’une page RNIFSend.aspx d’un partenaire, le message inclut un en-tête MIME et une limite MIME supérieure et inférieure, un nombre en base 64. RNIFSend.aspx ajoute l’en-tête et les limites au message pour la transmission RNIF. RNIFReceive.aspx doit supprimer l’en-tête MIME et les limites du message avant de soumettre le message au processus public. RNIFReceive.aspx supprime l’en-tête MIME et la limite supérieure, mais il ne supprime pas la limite inférieure. La présence de la limite inférieure n’affecte pas le traitement du message dans le processus public.

BTARN ne prend pas en charge une configuration respectant la casse des bases de données SQL Server

Si vous respectez la casse des bases de données et des objets de base de données BTARNSQL Server, la console de gestion BTARN ne trouve pas de ressources de base de données et lève une exception. Les bases de données et les objets de base de données BTARNSQL Server ne doivent pas respecter la casse.

Toutes les requêtes dans les scripts de maintenance de base de données doivent être écrites pour l’heure UTC

BTARN SQL Server bases de données utilisent l’heure UTC (Universal Time Coordinate), de sorte que toute requête que vous créez pour gérer l’une de ces bases de données doit être écrite pour l’heure UTC. Par exemple, si votre script de maintenance devait utiliser la GetDate() commande , vous devez le GetUTCDate()remplacer par .

Une orchestration PublicResponder rejette un message d’action de requête en double

Lorsqu’une PublicResponder orchestration (PublicResponderV11.odx) reçoit un message d’action de requête en double, elle enregistre un avertissement dans le journal des événements, puis rejette le message. Si un message en double est reçu une fois l’orchestration du répondeur terminée, BizTalk Server l’arrêtera, car il n’existe aucun abonnement.

Les erreurs de transmission ne s’affichent pas dans BAM si le processus public s’est arrêté

Si une erreur de transmission se produit lorsqu’une orchestration de processus publics traite son message final, le journal des événements et HAT affichent l’erreur, mais PAS BAM. BAM ne peut pas afficher le message, car l’orchestration s’est arrêtée.

L’outil pipeline.exe ne peut pas être utilisé pour déboguer un pipeline de réception BTARN

Si vous souhaitez déboguer un pipeline de réception, vous devez créer un port hébergeant le pipeline. Vous ne pouvez pas le déboguer à l’aide de l’outil pipeline.exe fourni par BizTalk Server.

Une erreur peut être générée pour un message retenté qui est correctement traité une fois l’orchestration terminée

BTARN utilise des orchestrations pour représenter le flux de processus. Dans certains cas, lorsque plusieurs messages retentés sont retentés, l’orchestration peut se terminer correctement avant qu’un message retenté n’arrive dans bizTalk MessageBox. Lorsque ce comportement se produit, BizTalk Server génère un message d’erreur « terminé mais ignoré » correspondant. Vous devez examiner votre application métier pour déterminer si le processus est terminé ou non. Si l’application métier indique la réussite de l’exécution, vous pouvez ignorer le message « terminé mais ignoré ».

Un fichier XML exporté à partir de tracking.xls peut avoir des champs incorrects

Lorsque vous définissez de nouvelles vues de suivi dans un fichier XLS de suivi et exportez un fichier XML à partir du fichier XLS de suivi, certains noms de champs sont légèrement modifiés. Pour corriger ce problème, vérifiez les champs de votre fichier XML de suivi personnalisé par rapport au champ standard tracking.xml installé par l’installation de BTARN.

Le schéma d’en-tête de service RNIF 1.1 pour les signaux et les réponses peut nécessiter une modification

BTARN expédie tous les schémas d’en-tête RosettaNet. Certaines implémentations utilisent les nœuds Contrôle de signal et Contrôle d’action différemment d’autres, comme décrit ci-dessous.

BTARN out of the box expédie l’élément Signal Control comme ci-dessous. Notez qu’il peut en être de même pour l’élément Contrôle d’action.

<!ELEMENT SignalControl (  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity,  
          inResponseTo)>

Si votre solution nécessite cette séquence, vous n’avez pas besoin de faire quoi que ce soit.

D’autre part, d’autres implémentations utilisent le code suivant :

<!ELEMENT SignalControl (  
          inResponseTo,  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity)>

Si votre solution nécessite cette séquence, reportez-vous à kb 889523. Cette mise à jour logicielle modifie le schéma XML correspondant. Notez que cette mise à jour affecte uniquement les processus RNIF 1.1.

La procédure stockée SQL PipAutomationGetAction doit être mise à jour

Vous devez mettre à jour la procédure stockée PIPAutomationGetAction SQL pour verrouiller les enregistrements uniques. Supprimez les lignes suivantes :

IF @@ERROR <> 0  
    UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID

La procédure stockée PipAutomationGetAction correcte est la suivante :

CREATE PROCEDURE PipAutomationGetAction  
AS  
 SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
BEGIN TRANSACTION  
DECLARE @tempGUID nvarchar(36)  
SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB WITH (READPAST,UPDLOCK,ROWLOCK)  
   WHERE Delivered = 0 AND MessageCategory = 10  
  ORDER BY TimeCreated  
  SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion, ServiceContent FROM MessagesToLOB  
   WHERE MessageID = @tempGUID  
For xml auto  
UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID  
 COMMIT TRANSACTION  
GO

Vous pouvez personnaliser le code aspx pour retourner la description de l’erreur

Si vous devez journaliser ou envoyer une description d’erreur, vous pouvez personnaliser le code aspx pour que le texte réel soit retourné dans la réponse. Pour ce faire, utilisez HttpResponse.Status (qui est l’objet de réponse de la requête asp intrinsèque) ou HttpWebResponse.StatusDescription (qui est retourné par l’appel .NET à la méthode GetResponse de l’objet HttpWebRequest). Pour retourner les valeurs de retour de l’un des objets de réponse applicables, définissez la valeur Response.Status de la même façon que la définition de Response.StatusCode dans le code aspx fourni avec BTARN.

Les messages RNIF 1.1 ne peuvent pas être lus en texte brut à partir de tables de non-répudiation si la méthode d’encodage est définie sur Base64

Cela se produit uniquement si la méthode d’encodage est définie sur Base64. Les messages peuvent être lus en texte clair à partir de tables de non-répudiation si la méthode d’encodage est définie sur quoted-printable ou 8 bits. Vous devez enregistrer le fichier de message avec l’extension *.eml, puis l’ouvrir à l’aide d’Outlook Express pour lire le message et Outlook Express décodera le message pour vous. Vous pouvez également utiliser le code ci-dessous pour lire les messages encodés en Base64 à partir de tables de non-répudiation.

byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);  
string plainText = Encoding.UTF8.GetString(textBytes);  
txtOutput.Text = plainText;

Voir aussi

Problèmes connus et dépannage