2015-03-17 1 views
-1

Nous venons d'installer l'environnement en direct BizTalk 2013 R2. Le système live dispose de 2 serveurs BizTalk de cluster actifs-actifs et de 2 serveurs de cluster SQL actifs-passifs. Dans notre système live précédent, nous avons un serveur BizTalk 2010 et un serveur SQL (pas de cluster). Dans le système Live BizTalk 2010 précédent, nous avions un bloc de code pour obtenir le nom de la forme actuelle et tout était OK.Microsoft.XLANGs.Core.Context.RootService.ExceptionLocation renvoie null

Context.RootService.FriendlyNameFromShapeId(Context.RootService.ExceptionLocation.ShapeID) 

Mais quand nous migrons ce code nouvel environnement de cluster BizTalk 2013, ExceptionLocation renvoie NULL et nous obtenons exception de référence d'objet.

Des idées? Est-ce lié au bogue BizTalk 2013 R2 ou lié au clustering?

+0

Avez-vous essayé dans un serveur de développement BizTalk 2013 R2 non clusterisé pour voir si cela fonctionne comme prévu? – Dijkgraaf

+0

Oui, je l'ai essayé dans BizTalk 2013 R2 standalone (Biztalk unique et SQL Server sur les deux machines) dev machine. Les résultats sont les mêmes. La situation n'est pas liée au regroupement. Tout est lié à la valeur GlobalTrackingOption dans Biztalk DB. –

Répondre

2

Nous avons trouvé la solution après une analyse approfondie. Le problème est que, dans BiztalkMgmtDb dans la table adm_Group, la valeur de la colonne GlobalTrackingOption est 0. C'est la raison pour laquelle l'objet ExceptionLocation a une valeur nulle. Lorsque nous avons mis cette valeur à 1 (Dans la configuration de biztalk, la valeur par défaut de cette colonne est 1), tout est OK. D'autre part, nous allons analyser les problèmes de performance de la transformation de cette colonne à 1.