Une Bande Dessinée pour présenter le concept des SOA d'une façon caricaturale: "A la quête de SOA".

J'aime beaucoup ;)

<Jacques />

La communauté française des utilisateurs Biztalk est en ligne ! Vous trouverez sur ce site: actualité, articles, trucs et astuces. Un grand merci à Roch BADUEL.

Voici le lien : www.btug.fr

<Jacques/>

Lorsque l'on se frotte un peu aux events handler, on se pose à un moment ou à un autre la question du déploiement. Il est possible de passer par l'écriture de features, c'est quelque chose de parfaitement réalisable de façon unitaire.

Mais lorsqu'il s'agit de voir sur une liste ou un content type les event handlers attachés, et des les modifier c'est une autre paire de manche !

Yoyo (mon ex collègue expatrié en Floride le veinard !) m'a envoyé un lien vers un post de Brian Wilson : Event Handlers - Part 3: Register Event Handlers plus free Site Settings – Manage Event Handlers Add-on solution

Cette feature permet d'ajouter des events handler, d'éditer son numéro de séquence ou de supprimer son enregistrement et ce pour un site, une liste ou un content type.

A noter, ce code est aussi disponible sur CodePlex !

Merci YoYo ! <Laurent/>

update du 11/01/2008 Microsoft nous a confirmé que le concours est ouvert à tous, professionnels compris. Alors à vos clavier !

Comme le disait Philippe ici, Microsoft lance un concours de création de templates WSS. Toutes les infos sont ici : http://technet.microsoft.com/fr-fr/bb963863.aspx

Mais en regardant le règlement du concours d'un peu plus prêt on s'aperçoit en fait qu'il est réservé aux "développeurs indépendants". Par indépendant Microsoft entend les développeurs amateurs cf l'article 2 du règlement : "Ce concours s’adresse exclusivement aux développeurs indépendants domiciliés en France (y compris la Corse et les DOM TOM) (ci-après les « Participants »). Sont dits « indépendants », les développeurs amateurs c'est-à-dire toute personne dont l’activité professionnelle ne consiste pas à réaliser des développements informatiques que ce soit dans le cadre d’une agence multimédia, d’éditeur de logiciel, dans une SSII ou toute autre structure dont l’activité principale ou accessoire consiste dans le développements de logiciels informations."

Chez MCNext nous étions très motivés pour présenter quelques unes de nos créations, mais la je dois dire que nous sommes plutôt refroidis ! Voire déçus...

J'espère néanmoins que nous verrons de beaux templates pour compléter la liste des 40 fantastiques !

<Laurent/>

Dans certains cas de débug, il peut être intéressant de pouvoir accéder directement aux codes sources produits lors de la compilation d'un projet BizTalk et du coup pouvoir profiter du débugage en pas à pas de ces codes sources.

Cette manipulation n'est que peu recommandée mais peut s'avérer fortement utile pour comprendre des comportements lors de l'exécution de pipeline, orchestration ...

La suite sur le blog d'Arno : cliquer ici

<Jacques/>

Si comme moi, vous vous êtes demandés ce que l'on pouvait mettre à la place de %MessageID% ou %SourceFileName% lors de la configuration d'un send port de type FILE ou FTP, consultez le lien suivant : http://msdn2.microsoft.com/en-us/library/aa578022.aspx

BizTalk propose en effet les macros suivantes :

• %datetime%
• %datetime_bts2000%
• %datetime.tz%
• %DestinationParty%
• %DestinationPartyQualifier%
• %MessageID%
• %SourceFileName%
• %SourceParty%
• %SourcePartyQualifier%
• %time%
• %time.tz%

<Jacques/>

Une petite astuce pour les développeurs BizTalk 2004 et BizTalk 2006 : déployer vos assemblies via un simple glisser déposer de vos assemblies directement dans le GAC et un redémarrage des hosts.

Cette opération est à utiliser pendant la phase de développement pour le déploiement de petits correctifs tels que :

• modification d'une shape expression dans une orchestration ;
• modification d'une map ;

Si vous avez ajouté un nouveau port ou promu un nouvel élément ou attribut dans un schéma, passez votre chemin, suivez la procédure habituelle.

Pour plus de détails cliquez ici.

<Jacques/>

A l'occasion du lancement de BizTalk Server 2006 R2, participez à la conférence SOA Microsoft au Pavillon Kléber à Paris le jeudi 25 octobre 2007.

Pour vous inscrire : cliquez ici

Merci Stéphane pour le rappel ;)

<Jacques/>

J'ai eu l'opportunité de présenter aujourd'hui au club Moss France un sujet qui me tient à coeur : le projet Essilor eServices.

Vous trouverez le lien vers le club MOSS France http://clubmoss2007.org ou sera prochainement disponible la présentation et les démos.

En bref : ce projet a consisté à la refonte des sites B2C et B2B des filiales Européennes. Quelques démo seront prochainenement disponibles, notamment au niveau de l'intégration de google map ou de la technologie flex, ou encore de la personalisation de la home page via du positionnement de webparts.

Cela n'aurait pas pu se faire sans la volonté, l'aide et le soutien de Guillaume Pranal que je tiens à remercier chaleureusement.

<Laurent/>

Wrox a mis en ligne un chapitre du livre "Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs" qui explique comment écrire sa première webpart.

"Developing SharePoint 2007 Web Parts" est écrit par Jan Tielens (qui n'est autre que le créateur de la SmartPart). Du coup vous n'avez plus d'excuse pour ne pas commencer a coder votre première webpart !

<Laurent/>

Télécharger une machine virtuelle avec BizTalk 2006 préconfigurée ici. <Jacques/>

Je me présente : Jacques NHOUYVANISVONG, j'ai intégré depuis peu la société MCNEXT, en tant que responsable du pôle BizTalk :).

Je vais essayer de vous montrer ce qui ce qui se cache derrière les mots EAI, BPM, BAM, orchestration, adapter, pipeline, policy, ....

Mon objectif principal est de "vulgariser" et promouvoir l'utilisation de BizTalk.

Cette rubrique va me permettre de vous apporter mon regard et mon retour d'expérience sur les projets d'implémentation de BizTalk Server.

Un petit cadeau pour fêter l'ouverture de cette rubrique : un poster pour tapisser votre bureau.

A votre service, n'hésiter pas à me contacter !

<Jacques/>

Voici une analogie intéressante qui m'a été exposée il y a peu :

Si on considère une équipe projet comme une usine de transformation des besoins d'un client en un produit final, on peut lui appliquer la théorie des contraintes comme dans une usine traditionnelle.
Dans ce cas, on tente de réduire le volume des encours, c'est à dire les produits intermédiaires déjà réalisés mais qui n'ont pas encore été intégré dans le produit final : spécifications écrites, modèle de conception, et même morceaux de code... Ils représentent de l'argent investi stocké dans l'entrepôt du logiciel. Qui plus est ce stock est une denrée périssable, car les besoins évoluent souvent très vite.
Les méthodes agiles essaient donc de minimiser ce stock et permettre au client de changer d'idée facilement sans impacter la réussite du projet.

A quand la mise en oeuvre d'un kanban de Use Cases ?

Je ne saurais trop vous conseiller l'article de Martin Fowler qui détaille les grands principes de l'intégration continue :

• Maintenir un référentiel unique de source
• Automatiser la construction du projet
• Inclure les tests dans la construction du projet
• Tout le monde doit committer ses changements au moins une fois par jour
• Chaque commit lance la reconstruction du projet sur le serveur d'intégration
• La construction (avec les tests) du projet doit rester rapide
• Jouer les tests dans un environnement identique à celui de production
• N'importe qui doit pouvoir récupérer le dernier exécutable facilement
• Tout le monde doit savoir ce qui se passe
• Automatiser le déploiement du projet

Les avantages de l'intégration continue ne sont pas seulement techniques, mais aussi organisationnels. Et en plus vous avez là un nouveau canal de communication. Voici quelques points dans le désordre.

D'abord, vous devez concevoir un script pour construire votre projet en un clic, ce qui veut dire que tout le monde construit son projet de la même façon. Et comme le projet est construit uniquement à partir des données du référentiel sur une machine séparée, vous êtes sûr d'avoir tous les éléments du projet dans votre référentiel.

Les problèmes d'intégration sont minimes car tout le monde doit committer régulièrement.

Comme les tests sont joués après chaque commit, il est plus facile d'identifier un bug dans le code qui a été modifié.

Le test et le déploiement dans un environnement identique à celui de production minimisent les risques et le temps d'installation du projet dans son environnement final.

Le fait de construire le projet après chaque commit responsabilise les membres de l'équipe, car en cas d'échec on le voit tout de suite et on connait également les dernières personnes à avoir modifier le code... De plus, lorsque l'intégration est en échec, chacun sait qu'il est inutile de mettre à jour son projet en local au risque de se retrouver bloqué.

Autre avantage et non des moindres, vous disposez ainsi d'un version opérationnelle en permanence. Cette version peut servir à des démonstrations, et donc montrer l'avancement du projet directement au travers de l'application.

Enfin, on peut inclure dans la construction du projet des outils d'analyse du code. Ces métriques viennent compléter les rapports de builds et de tests, et peuvent être utilisées pour améliorer la qualité du code.


Toutes ces pratiques peuvent être adoptées progressivement. Elles améliorent incontestablement la productivité et la qualité d'un projet. Vous n'avez donc aucune excuse pour ne pas vous y mettre !

Suite à une pression incessante, je me suis enfin résolu à ouvrir cette nouvelle catégorie : le développement AGILE en .Net !

Vous devriez y trouver :

• des explications sur les outils qu'on utilise
• des retours d'expérience
• des liens vers d'autres articles intéressants
• ...

Et surtout, partagez avec nous vos découvertes, vos expériences et vos commentaires.

Enfin, si vous souhaitez vous lancer dans l'aventure, MCNEXT peut vous aider dans votre démarche.