Le mot de passe, d’accès à un proxy par exemple, n’est pas écrit dans le fichier de binding lorsque celui-ci est généré via l’assistant d’export, ce qui génère une erreur au déploiement.
Pour corriger cela, il faut éditer le fichier de binding :
- ré-écrire le mot de passe
- remplacer la valeur vt=1 en vt=8
Le Pipeline XML Receive vérifie que :
- le message est bien formé d’un point de vue XML (i.e, « XML well-formed »)
- un schéma XSD définissant le même espace de nom XML (XML-namespace) que le message en cours de traitement est déployé dans BizTalk
En aucun cas, le pipeline de réception vérifie la conformité du XML par rapport au XSD ! Pour cela, il faut l’indiquer explicitement…
Lorsqu’un vocabulaire est publié et/ou qu’une stratégie est publiée ou déployée dans le Business Rules Engine (BRE), il devient impossible de les modifier depuis le Business Rules Composer (BRC) ! En effet, si une évolution s’impose, nous sommes censés créer une nouvelle version du vocabulaire ou de la stratégie…
D’après moi, cela est une bonne pratique dans un cycle de production, mais guère pratique dans un cycle de développement, cycle pendant lequel un vocabulaire ou une stratégie est publié(e) (ou déployée pour une stratégie) maintes fois pour tests.
Heureusement, il existe une solution – peu élégante certes, mais très efficace – permettant de s’affranchir de la création d’une nouvelle version.
Le principe est de modifier en base de données le statut du vocabulaire ou de la stratégie afin d’annuler la publication ou le déploiement.
Pour rappel,
- Un vocabulaire posséde 2 statuts : Enregistré (valeur 0) et Publié (valeur 1)
- Une stratégie posséde 3 statuts : Enregistrée (valeur 0), Publiée (valeur 1) et Déployée (valeur 1 !)
- Le statut Publié se distingue du statut Déployé par la présence d’une entrée dans la table re_deployment_config vérifiant la condition re_deployment_config.nRuleSetID = re_ruleset.nRuleSetID
- Dans ces 2 états, une entrée est également présente dans la table re_tracking_id
Où exactement en base de données ?
- base de données BizTalkRuleEngineDb (c’est le nom de la base de données par défaut)
- table re_vocabulary pour un vocabulaire
- table re_ruleset pour une stratégie
- colonne nStatus, valeur 0 pour le statut Enregistré et valeur 1 pour le statut Publié ou Déployé
Comment procéder ?
Simplement en passant la valeur de la colonne nStatus de 1 à 0, et inversement après modification et le tour est joué !
Attention, si l’on souhaite publier ou déployer une stratégie à l’aide du BRC (après modification manuellement du statut en base de données), il est également nécessaire de supprimer la ligne associée (identifiant nRuleSetID) à la stratégie dans les tables re_tracking_id et re_deployment_config.
Et puis d’abord pour quoi faire ?
Cela peut sembler nécessaire lorsque les développements BizTalk Server 2004 se réalisent dans des environnements virtuels avec BizTalk et SQL Server 2000 déjà installés. Dans ce cas, il devient impératif de changer le nom du serveur virtuel, ainsi que le nom du serveur SQL Server.
Comment ?
De la manière suivante :
- Déconfigurer le serveur BizTalk – s’il est déjà configuré, bien entendu – à l’aide de la commande
configframework /u
- Supprimer les jobs SQL Server pour BizTalk
- Renommer le serveur SQL en exécutant les instructions suivantes :
sp_helpserver -- afin de connaitre la valeur {ancien_nom}
GO
sp_dropserver {ancien_nom}
GO
sp_addserver {nouveau_nom}, local
GO
- Redémarrer les services SQL Server (voire la machine si nécessaire…)
- Reconfigurer le serveur BizTalk à l’aide de la commande
Configframework
- S’il devient nécessaire de supprimer des jobs SQL Server après avoir réalisé l’étape 3, exécuter la requête SQL Server suivante
UPDATE msdb.dbo.sysjobs SET originating_server = @@SERVERNAME WHERE
originating_server <> @@SERVERNAME;
afin d’éviter le message d’erreur erreur 14274: impossible d’ajouter, de mettre à jour ou de supprimer un travail provenant d’un serveur MSX (ni l’une des étapes ou l’un de ses plannings).
Et voila.
Lorsque l’on cherche à récupérer des messages IDOC à l’aide d’un port de réception BizTalk présentant l’adapter WCF-SAP, le journal d’évènement Windows peut présenter l’exception Loading property information list by namespace failed or property not found in the list.
Cause:
A la réception d’un message IDOC, l’adapter WCF-SAP essaie de promouvoir des champs dans le context du message. Pour réaliser cela, l’adapter s’appuie sur un property schema défini dans l’assembly Microsoft.Adapters.SAP.BizTalkPropertySchema.
Solution:
Il suffit d’ajouter l’assembly Microsoft.Adapters.SAP.BizTalkPropertySchema dans les ressources de l’application BizTalk présentant le port de réception SAP à l’aide de la manipulation suivante:
- Clic droit sur les ressources de l’application BizTalk concernée
- Choisir Add –> BizTalkAssemblies
- Naviguer vers le répertoire \bin d’installation du BizTalk Adapter Pack et sélectionner l’assembly Microsoft.Adapters.SAP.BizTalkPropertySchema
- Dans les propriétés de l’adapter WCF, vérifier que le champ EnableBizTalkCompatibilityMode (anciennement connu sous le nom EnableBizTalkLayeredChannel) présente la valeur True
- Redémarrer les services BizTalk afin de prendre en compte les modifications
Sous un environnement 64 bits (Windows Server 2008 Standard Edition), le message Explorer OM not supported in 64 bits process peut apparaître dans le journal d’évènement lors de l’installation de l’ESB Portal de l’ESB Toolkit 2.0.
Pour corriger cela, il m’a été nécessaire de passer à True la propriété Enable 32-bit Applications dans les propriétés avancées du pool d’application associé à l’application web (déployée sous IIS) ESB.BizTalkOperationsService.
Pourquoi écrire un post alors qu’il en existe déjà un (avec des images svp)
Ok, le risque c’est que le lien ne fonctionne plus, mais bon…
Merci à jesaispasqui pour son post.
Il est généralement écrit que le type d’un message XML BizTalk est toujours composé de son namespace suivi de l’élèment root de la manière suivante : <namespace>#<root>.
Richard Seroter, MVP Microsoft, démontre sur ce billet que cela n’est pas forcément le cas !
L’objectif est de s’assurer que les messages publiés dans un ordre donné dans la MessageBox soient transmis à chacun des abonnés dans le même ordre.
Cette option se configure :
- dans un port d’envoi
- ou, dans une shape Receive d’une orchestration
et, n’est pas supportée par les ports dynamiques ni les transports de backup.
Un flux end-to-end pour lequel l’on souhaite traiter les messages dans un ordre donné doit respecter les conditions suivantes :
- Les messages doivent être recus par un adapter permettant de respecter cet ordre dans la transmission à la MessageBox.
- La souscription à ces messages doit être réalisé par un port d’envoi présentant l’option Ordered Delivery activée.
- Si une orchestration a souscrit à ces messages, celle-ci doit être unique en instance et doit implémenter le pattern sequential convoy (corrélation). Enfin, la shape de réception doit présenter la propriété Ordered Delivery à True.
Attention, l’option Ordered Delivery se comporte différemment pour un port d’envoi si :
- l’option de transport - du même port – Stop sending subsequent message on current message failure est activée ou non :
- Si True, alors le port est suspendu et tous les messages ne sont plus traités; ainsi l’ordre des messages est fortement respecté.
- Si False, alors seul le message en erreur est suspendu (état not resumable). Tous les autres messages continuent d’être traités. L’ordre des messages suspendu est conservé, mais un saut de séquence peut alors se produire
- Si un port d’envoi de type solicit-response présente la propriété Stop sending subsequent message on current message failure à True, et si l’option recoverable interchange est configuré à l’étape de désassemblage du pipeline de réception de la réponse, alors le port d’envoi continue de transmettre les messages s’il existe une erreur dans le désassemblage de la réponse.
Mise en pratique par Richard SEROTER dans ce billet.
Par défaut, le fichier de binding généré par l’adapter WCF-SAP définit un mode de communication de type resquest-response (port de réception) ou solicit-response (port d’envoi). Aussi, à l’import du fichier dans une application BizTalk, un port de réception ou d’envoi de type two-way est créé !
Pour utiliser le fichier de binding avec un port one-way les modifications suivantes sont à réaliser :
- Editer le fichier de binding
- Modifier la valeur de la propriété isTwoWay de true à false
- Commenter les balises ReceivePipeline (resp. SendPipeline) et ReceivePipelineData (resp. SendPipelineData) si le port à créer est un port d’envoi (resp. de réception)