Le 1er Cumulative Update Package (kb2429050) pour BizTalk 2009 est maintenant disponible pour les versions x86 et x64.
Egalement disponible, le 1er Cumulative Update Package pour l’Adapter Pack V2.0 (kb2444952) pour BizTalk 2009 (seulement en version x86).
BizTalk Server 2010 devrait être disponible à l’achat, selon l’équipe produit, à partir du 1er Octobre 2010 !
Le billet de l’équipe BizTalk qui annonce cette nouvelle et présente également les nouvelles fonctionnalités.
L’article Microsoft suivant http://support.microsoft.com/kb/318785/ explique comment trouver les versions des frameworks .NET installés.
Il s’agit simplement d’aller “jeter un oeil” au bon endroit dans la base de registre Windows…
Certes ce n’est pas du BizTalk, mais cela ne fait pas de mal….
JOINTURE NATURELLE :
la jointure s’effectue sur les colonnes communes, c’est à dire celles de même nom et type :
SELECT colonnes FROM table1 NATURALJOIN table2 [USING col1, col2 ... ] [WHERE prédicat]
Le mot clef USING permet de restreindre les colonnes communes à prendre en considération.
JOINTURE INTERNE :
la jointure s’effectue entre les tables sur les colonnes précisées dans la condition de jointure :
SELECT colonnes FROM table1 t1 [INNER ] JOIN table2 t2 ON condition [WHERE prédicat]
JOINTURE EXTERNE :
récupère les lignes des tables correspondant au critère de jointure, mais aussi celle pour lesquelles il n’existe pas de correspondances.
SELECT colonnes FROM table1 t1 [RIGHT OUTER | LEFT OUTER | FULL OUTER ] JOIN table2 t2 ON condition [WHERE prédicat] ...
- RIGHT OUTER : la table à droite de l’expression clef “RIGHT OUTER” renvoie des lignes sans correspondance avec la table à gauche.
- LEFT OUTER : la table à gauche de l’expression clef “LEFT OUTER” renvoie des lignes sans correspondance avec la table à droite.
- FULL OUTER : les deux tables renvoient des lignes sans correspondance entre elles.
JOINTURE CROISÉE :
réalise le produit cartésien (la “multiplication”) des deux tables. Il n’y a pas de condition.
SELECT colonnes FROM table1 t1 CROSS JOIN table2 t2 [WHERE prédicat] ...
JOINTURE D’UNION :
concatène les tables sans aucune correspondances de colonnes
SELECT colonnes FROM table1 UNION JOIN table2
Il n’y a pas de critère de jointure.
Pour faire communiquer 2 ports en binding direct, toutes les conditions suivantes doivent être réunies:
- le port d’envoi pointe sur le port de réception
- le port de réception pointe sur lui même
- les 2 ports doivent être de même type
- l’orchestration qui contient le port de réception est publique (i.e, propriété de l’orchestration, champ Modificateur de type=public)
Le numéro de produit d’un serveur BizTalk est présent dans la base de registre sous la clé ProductVersion présente dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0
Ci-dessous, les correspondances entre le numéro de produit et la version du serveur BizTalk :
- BizTalk Server 2004 –> 3.0.4902.0
- BizTalk Server 2004 SP1 –> 3.0.6070.0
- BizTalk Server 2004 SP2 –> 3.0.7405.0
- BizTalk Server 2006 –> 3.5.1602.0
- BizTalk Server 2006 R2 –> 3.6.1404.0
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…
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.