Christophe BRANDO

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 :

1. ré-écrire le mot de passe
2. remplacer la valeur vt=1 en vt=8

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.

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:

1. Clic droit sur les ressources de l’application BizTalk concernée
2. Choisir Add –> BizTalkAssemblies
3. Naviguer vers le répertoire \bin d’installation du BizTalk Adapter Pack et sélectionner l’assembly Microsoft.Adapters.SAP.BizTalkPropertySchema
4. 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
5. Redémarrer les services BizTalk afin de prendre en compte les modifications

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 !