mercoledì 12 novembre 2008
Sono quì al Teched a Barcellona, devo dire che sono molto soddisfatto e mi sto divertendo molto, oltre a lavorare
, ma devo dire che è molto più bello, la vivi in modo molto più intenso.
Gli amici quì presenti MVP e non, sono come sempre fantastici, sono insostituibili, non potrei più fare a meno di loro, perciò dovrete sopportarmi ancora per un bel pò.
Ho trascurato un pochino il blog, lavoro, e altro che scoprirete al mio ritorno dal Teched
A dire il vero avevo anche bisogno di carne fresca hehehehehe.
Torniamo a noi....
Le novità sono tante, poi post PDC...
Quello che mi interessava era inquadrare definitivamente il futuro di BizTalk / Services
A Redmond avevo visto in modo dettalgliato la prima ipotesi di OSLO, ora alcune cose sono cambiate ma l'idea di fondo è sempre la stessa, diciamo che ora è tutto molto più inquadrato, definito ed ordinato.
BizTalk come System Integrator e Dublin come Applcation Server, dico che era ora che alleggerissero BizTalk da cose che le competevano, notare il "le"
Per dirla tutta, questa è la slide che vuole rappresentare il rapporto tra BizTalk e Dublin, parla da sola 
Ho tantissime cose da dire, da approfondire, sono estremamente eccitato da tutto questo.
Stay Tuned!
mercoledì 22 ottobre 2008
A dire il vero l'inferno non è per colpa di Reporting Services ma di chi ha smanettato sulla security di IIS 7 ma visto che mi è costato un bel pò di sangue vale la pena annotarselo.
RS mi restituiva questo errore
w3wp!library!4!10/23/2008-18:51:47:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. See the report server log files for more information., Could not load Authorization extension;
Info: Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. See the report server log files for more information.
notato il w3wp e il "Could not load Authorization extension" ho provato a togliere tutti le estensioni di sicurezza a parte la Windows.
tutto ok, il fatto è che ho scoperto che RS non supporta le estensioni di sicurezza multiple.
Ho scritto questo solo come mio appunto, ma spero possa essere comunque una valida info.
giovedì 25 settembre 2008
Grande notizia, la versione 2 dell' adapter Pack offrirà la possibilità di eseguire query lato SAP.
Maggiori Info
mercoledì 24 settembre 2008
Quest'anno sarò al TechEd a Barcellona per l' HOL e ATE, spero di trovare tanti amici.
Grazie a Davide per l'immagine 

sabato 13 settembre 2008
Beh anche questa è ,per me, una cosa personale.
A parte che la MSC 2008 sia la più bella e completa conferenza intorno al mondo SharePoint e conta di speakers eccezionali come Igor , Paolo e tanti altri.
Il fatto è che tra loro trovo un caro amico, Claudio, è una persona che ragazzi sentirlo parlare...
Lui è SharePoint
, bravo Claudio!

Atro evento assolutamente unico e stellare nel campo della virtualizzazione, organizzato da Alessandro , persona veramente eccezionale.

Il TechDays – WPC 2008 sarà a mio parere un grandissimo evento, ho già sentito alcuni titoli delle sessioni e devo dire che non vedo l'ora che inizi.
La home page la dice tutta... fuoco e fiamme
E con un Early Bird molto interessante, beh ci vediamo lì.
Tutte le Info
venerdì 12 settembre 2008
Gironzolando, come faccio di solito, fra i milgiori blogs e usergroup, non ho potuto fare a meno di notare questa cosa.
In UGISS ho trovato questo evento che, secondo me, deve rappresentare il massimo per un appassionato di SQL Server.
Il PASS Community Summit 2008, PASS sta per Professional Association for SQL Server.
Mamma mia che evento, chissà se esisterà mai una PACS, Professional Association for Connected Systems
Comunque sia se fossi un Sqellaro non me la farei scappare neanche morto.

giovedì 11 settembre 2008
Ecco RFID all'opera al Teched 2008 in Australia, perchè non lo usiamo al WPC 2008 ?
martedì 9 settembre 2008
Jon Flanders ha appena pubblicato delle slides molto interessanti su una conferenza che ha tenuto da poco a Stoccolma per presentare il suo nuovo libro, tratta aspetti molto interessanti inerenti lo sviluppo WEB e WCF ed il loro futuro.
Ecco il link
lunedì 8 settembre 2008
Quanto mi piace immergermi negli abissi profondi di BizTalk, è una cosa a dir poco orgasmica.
Ho un Trace SQL, che mi sono preparato con pazienza e che permette di filtrare gli eventi più interessanti che BizTalk scatena durante il suo lavoro.
Vi garantisco che si scoprono cose estremamente interessanti, è possibile vedere la chiamata di host bts_DeQueueMessages_[HosTname] effettuata dall'Host Instance per eseguire lo spool dei messaggi.
L' inserimento delle property mediante la bts_InsertProperty e la fatidica bts_FindSubscriptions per la ricerca delle sottoscrizioni.
Penso che non esista niente di meglio per capire come esattamente funzioni ma soprattutto quali armi abbiamo a disposizione per poter intervenire e capire eventuali problemi.
Alcuni tipi di query possono esserci di grande aiuto a capire come un BizTalk Server sta funzionando e come è configurato.
In particolare mi sento sempre fare queste domande:
Come è possibile eseguire il resume di più messaggi?, Come faccio a capire quante istanze stanno lavorando bene e quali hanno problemi?
Chiaro che dalla Hub è possibile eseguire delle query ma non abbiamo a disposizione tantissimo.
Basta un pò di pazienza ed è BizTalk stesso a fornirci le risposte che cerchiamo.
Per provare queste queries non bisogna far altro che copiare il testo e eseguirlo in SQL 2005.
Configurazione delle messagebox:
declare @p2 nvarchar(128)
set @p2=N'NOMEMACCHINA'
declare @p3 nvarchar(128)
set @p3=N'BizTalkMsgBoxDb'
declare @p4 int
set @p4=1
declare @p5 int
set @p5=60
exec admsvr_LoadMsgBoxGroupProperties @nvcGroupName=N'BizTalk Group',@nvcMasterDBServer=@p2 output,@nvcMasterDBName=@p3 output,@nNumMsgboxServers=@p4 output,@nCacheRefreshInterval=@p5 output
select @p2, @p3, @p4, @p5
Per capire quale sia la master, disabilitare la pubblicazione dei messaggi ecc..
Ecco tutte le istance in sospeso
exec ops_OperateOnInstances @snOperation=0,@fMultiMessagebox=0,@uidInstanceID='00000000-0000-0000-0000-000000000000',@nvcApplication=N'',@snApplicationOperator=0,@nvcHost=N'',@snHostOperator=0,@nServiceClass=111,@snServiceClassOperator=0,@uidServiceType='00000000-0000-0000-0000-000000000000',@snServiceTypeOperator=0,@nStatus=36,@snStatusOperator=1,@nPendingOperation=1,@snPendingOperationOperator=0,@dtPendingOperationTimeFrom='Jan 1 1753 12:00:00:000AM',@dtPendingOperationTimeUntil='Dec 31 9999 10:59:59:997PM',@dtStartFrom='Jan 1 1753 12:00:00:000AM',@dtStartUntil='Dec 31 9999 10:59:59:997PM',@nvcErrorCode=N'',@snErrorCodeOperator=0,@nvcErrorDescription=N'',@snErrorDescriptionOperator=0,@nvcURI=N'',@snURIOperator=0,@dtStartSuspend='Jan 1 1753 12:00:00:000AM',@dtEndSuspend='Dec 31 9999 10:59:59:997PM',@nvcAdapter=N'',@snAdapterOperator=0,@nGroupingCriteria=0,@nGroupingMinCount=0,@nMaxMatches=51,@uidAccessorID='4386A978-682A-4F58-B32D-D9BA0D074F64',@nIsMasterMsgBox=0
Per eseguire un filter più rilassato è meglio filtrare in TexData su NotLike %bts_DeQueueMessages_NOMEHOST%
a meno che non vogliate vedere il cuore di BizTalk battere, è comunque carino.
La stored bts_DeQueueMessages_NOMEHOST viene chiamata continuamente dal relativo Host per eseguire lo spool dei messaggi.
Alla lunga risulta fastidiosa ma offre un buon punto di riferimento su alcune letture.
Per eseguire il resume di un messaggio BizTalk esegue questa chiamata:
set @p21=0
exec [dbo].[bts_UpdateMsgbox_NinoHost] @nArtifactType=1,@nAction=207,@uidObjectID=N'{6D12B877-ADFF-4B54-98B1-CB4A1A6B5E68}',@uidInstanceID=N'{6D12B877-ADFF-4B54-98B1-CB4A1A6B5E68}',@uidServiceID=N'{C97C4CB1-A853-413B-A3C6-C1CAECB74ABF}',@uidClassID=N'{59F295B0-3123-416E-966B-A2C6D65FF8E6}',@uidActivationID=N'{16B83A2B-CAAE-4581-B36F-675AA582CA6C}',@uidInstanceStateID=NULL,@uidWorkID=NULL,@uidPortID=NULL,@nvcErrorID=NULL,@nErrorCategory=0,@nvcAdditionalInfo=NULL,@nIsResumable=0,@dtResubmitTimeStamp='Dec 30 1899 12:00:00:000AM',@nvcLastAction=NULL,@nvcURL=NULL,@nvcAdapter=NULL,@fOptimize=1,@uidDBOwnerID=@p20 output,@nReturn=@p21 output
select @p20, @p21
Cchiaro che per lavorare al meglio sia necessario decodificare le varie informazioni, mi riferisco ai vari UID.
Per fare questo è necessario fare affidamento alle relative tabelle, quali la Applications, la famosa SPOOL dove abbiamo il messageType e il uidMessageID.
Ecco il Trace Template
Mick Breeze ha rilasciato pubblicamente le slide che utilizzerà per la sessione che terrà al Teched 08 insieme a Scott e altri, non ho ancora avuto occasione di vedere l'ntero programma del Teched, questa sessione è molto introduttiva, forse troppo, sono certo che nel programma saranno presenti sessioni su BizTalk più consistenti 
Ecco il link
http://blogs.breezetraining.com.au/mickb/2008/09/08/TOT334BuildingRFIDSolutionsWithBizTalk.aspx
domenica 7 settembre 2008
Per maggiori info inerenti i nuovi aggiornamenti su BizTalk server 2009 vi rimando a questa interessantissima Q&A con Oliver Sharp, General Manager della Connected System Division.
http://www.microsoft.com/presspass/features/2008/sep08/09-05BizTalk.mspx

Ebbene sì, come prevedevo Microsoft ha cambiato nome alla futura release BizTalk, la R3.
Il nuovo BizTalk si chiamerà BizTalk server 2009
, la trovo una decisione corretta, soprattutto per le pesanti modifiche effettuate alle principali componenti interne.
Chiaramente il cambiare il nome a una piattaforma come questa preclude ragioni di tutto rispetto, alcune delle quali molto interessanti.
L' interfaccia di sviluppo molto più solida e affidabile, chiaramente su piattaforma 2008, framework 3.5, l'architettura interna di interconnessione dei layer di comunicazione in WCF, quest' ultima è, secondo me la cosa migliore che potesse fare Microsoft.
Altrettanto interessante il supporto ad Hyper-V, e finalmente la possibilita di effettuare multi-deploy in ambienti cluster.
RFID rimane una piattaforma a parte ma che presenta interessati nuove possibilità verso il supporto di soluzioni mobile e protocolli industriali (LLRP, TDT, TDS, WS Discovery, EPCIS support)
Supporto su TFS di gran lunga migliorato, il messaging interno rivisto per la parte di interchange di tipo recoverable.
Negli anni a seguire Microsoft ha già annunciato che effettuerà altri interessanti rilasci, in questo ordine:
Supporto di sviluppo per complex mapping, per il B2B inserimento dela possibilità di gestire complex trading partners,
Nuova ESB Guidance e nuova carburazione sulla low latency.
Altri steroidi al BAM, grandissima feature di BizTalk.
Sapete cosa significa BizTalk Server 2009 e non R3?
Significa che a differenza di quello che sapevo, BizTalk non sarà più inglobato internamente a OSLO, come si pensava, ma sarà, giustamente, un una sua estensione.
Sono molto felice di tutto questo, OSLO è veramente interessante e credo rivoluzionerà tante cose ma penso che determinate problematiche architetturali debbano essere focalizzate alle relative piattaforme, ritengo che la "globalizzazione" tecnologica porti solo al caos.
...
martedì 2 settembre 2008
Malgrado abbia lavorato anche in Agosto, solo adesso , a Settembre, inizio a risentirmi nuovamente a pieno regime.
Il nuovo anno lavorativo inizia con un OT di tutto rispetto che farà felice Davide.
Ho cambiato moto, non sopportavo più il Varadero e dopo solo un anno, il divorzio, BASTA!!!!.
Inguidabile, sbilanciata all'inverosimile, pesantissima....
Sono andato in BMW ed è stato amore a prima prova
.
Ho fatto un giro con lei e mi sono detto questa è, in assoluto, la mia moto.
Ve la presento,

E' la F 800 GS, ragazzi è una moto fenomenale, capace di tutto, viaggiare, fuoristrada, gommata da strada ha la guida di un motard, 85 cavalli in solo 186 kg di peso.
Stupenda, non mi ci staccherò più.
mercoledì 27 agosto 2008
E' stata rilasciata la "BizTalk Server Performance Optimization Guide"
E' una guida per capire come e dove sia possibile intervenire su una infrastruttura di produzione BizTalk onde ottenere le migliori performance.
Il documento tratta vari aspetti quali, eliminazione di possibili Bottlenecks, eseguire test automatici e chiaramente ottimizzazione.
Veramente interessante.
Ecco i links:
MSDN http://msdn.microsoft.com/en-us/library/cc558617.aspx
TechNet http://technet.microsoft.com/en-us/library/cc558617.aspx
word document su Microsoft Download Center
lunedì 4 agosto 2008
BizTalk Hot Rod, è uscito il nuovo numero!
E' uscito il nuovo numero di BizTalk Hot Rod, è una rivista molto interessante e molto ben fatta che tratta tantissimi interessanti aspetti del mondo BizTalk.
Consiglio assolutamente la lettura.

venerdì 4 luglio 2008
Parlare di integrazione non è cosa semplice, è un argomento vastissimo e carico di sfaccettature, limitarlo ad una singola tecnologia sminuisce sicuramente la sua importanza.
Ad oggi è possibile utilizzare tantissime soluzioni diverse per integrare diversi sistemi, agnuno di loro ha i suoi vantaggi e svantaggi.
Microsoft presenta alternative quali Integration Service di SQL Server, Host Integration Server , BizTalk Adapter Pack, BizTalk, tutti molto diversi tra loro sia per architettura che per scopo.
Lo sappiamo tutti che è possibile fare qualsiasi cosa con ognuno di questi attori ma solo uno è migliore degli altri in una particolare soluzione.
Nell’ arco di quest’ anno parlerò tantissimo di integrazione e non mi limiterò solo a BizTalk, perchè ritengo che l’integrazione sia una filosofia e una scienza molto articolata.
L’altra sera stavo sul balcone e ho iniziato a ragionare su tutto questo iniziando a fare tantissime considerazioni e domande a me stesso, da lì ho deciso di iniziare a scrivere perchè voglio tenere traccia delle mie ricerche.
Chiaramente da buon MVP sono felice di condividerle con tutti le mie considerazioni sperando possano essere di aiuto.
Una cosa che mi fa sorridere è che ad oggi quando si parla di integrazione sembra si debba parlare obbligatoriamente di BizTalk.
Limitare BizTalk alla semplice integrazione tra sistemi è il segnale che identifica che non si è compreso esattamente cosa sia esattamente BizTalk.
Che dire..., partirei propio da questo.
Ma che cosa è BizTalk?
Direi che è la domanda principe, quella che solitamente mi sento fare per prima.
Credo che questa mancanza di vision non sia dovuta al fatto che manchi un sistema di informazione adeguato, ma alla natura stessa del prodotto, se di prodotto possiamo parlare.
BizTalk è un framework per l’integrazione e la gestione dei flussi tra diversi sistemi.
Si, quando parlo di flussi intendo workflow, ma attenzione ne esistono due principli diversi tipi, human e system workflow.
BizTalk è sicuramente la soluzione numero uno proposta da Microsoft per creare system workflow, non direi lo stesso per quello che riguarda l’aspetto human workflow.
A tal proposito esistono diverse soluzioni, quali Sharepoint e chiaramente Workflow Foundation (WF), è scontato che se dobbiamo arrivare ad ottenere architetture che necessitano di processi di tipo human piuttosto che system, la soluzione ottimale può essere utilizzare MOSS + WF + BizTalk, futura vision Microsoft di nome OSLO.
E gli adapter Pack?, ne parliamo un’ altra volta, ma sono certamente una validissima alternativa per integrare sistemi LOB.
Ok andiamo più sull’ amichevole e partiamo da zero, BizTalk è alla sua quinta versione, le versioni sono la 2000, 2002, 2004, 2006, 2006 R2, siamo in attesa della versione R3.
La versione 2004 rappresenta un vero salto epocale, infatti le architetture precedenti non hanno nulla a che vedere con essa, a tal proposito, infatti, non si può parlare nemmeno di migrazione dalla versione 2000 e 2002 ma di totale riscrittura e rivisitazione architetturale della soluzione.
A differenza di quello che si possa pensare BizTalk è molto diffuso ed utilizzato, chiaramente per correttezza non voglio fare nomi ma in Italia conta di oltre 180 installazioni delle quali 3 oltrepassano i 130 processori.
I diretti concorrenti coprono circa il 30% del mercato con tendenza a diminuire, quali sono i diretti concorrenti?, mmh ripeto non mi sembra corretto fare nomi.
La prima cosa che viene in mente pensando a BizTalk è ad un tool per integrare diversi flussi e che se serve ad eseguire trasformazioni, in sostanza viene paragonato ad un motore di ETL (Extract Transform Load), come Integration Service di SQL Server o T.... ops.
Ritengo che sia questo il più grave errore, un errore che porta solitamente ad una ingenua sottovalutazione della tecnologia in questione e, di conseguenza, ai relativi lasagne projects.
BizTalk non è stato creato per eseguire semplice ETL, anche se potrebbe farlo, ma ripeto non è stato progettato per questo, se dovessi decidere cosa utilizzare per replicare e trasformare i dati tra due tabelle SQL di un milione di records uilizzerei sicuramente Integration Service di SQL Server o altre tecnologie ma non certamente BizTalk.
A questo punto, di solito, la curiosità inizia a crescere e la domanda sorge spontanea.
Se non è un ETL, o perlomeno, non è tra i suoi targets primari, quali lo sono?
BizTalk è fondamentalmente un HUB Messaging Router, questa sua particolarità lo rende unico nel suo genere.
Sostanzialmente BizTalk riceve messaggi, questi messaggi possono arrivare da sistemi diversi ma al suo interno sono sempre e comunque messaggi.
A cosa è dovuta questa particolarità, è dovuta a un layer esterno chiamato adapter che lui stesso espone.
BizTalk ha tantissimi adapters a disposizione, ognuno di loro è specializzato a parlare con un diverso tipo di sistema, la cosa importante è che a prescindere da quale sia il tipo di sistema o il tipo di protocollo, quando l’adapter riceve qualcosa lo deserializza in una forma BizTalk standard, che corrisponde al famoso messaggio, tecnicamente farlando è un XML Document contenente puro XML.
BizTalk utilizza un pattern architetturale interno molto conosciuto che si chiama Publish/Subscriber.
Un volta entrato in BizTalk questo messaggio può essere sottoscritto a diversi Subscribers, questi possono essere processi molto complessi o semplicemente porte di invio su altri sistemi.
A differenza di quando si lavora su un classico ETL, nel quale esiste uno stretto legame tra un processo e l’altro, in BizTalk esiste solo la sottoscrizione e su questo si basa l’intero funzionamento.
Un messaggio può essere sottoscritto con tantissime regole, basandosi sul valore di uno o più campi, sul fatto che arrivi da un determinato partner, dal fatto che sia un determinato tipo di messaggio e tanto altro ancora.
Sostanzialmente il messaggio viene pubblicato al suo interno ed uno o più Subscriber possono riceverlo, questi Subscribers possono essere processi, porte e altro.
In BizTalk non si può parlare di soluzioni chiuse perchè una soluzione è composta da vari tipi di messaggi e processi che possono essere estesi in qualsiasi momento.
Per capire meglio prendiamo in esame alcune tipiche architetture nelle quali BizTalk può essere utilizzato.
Esistono vari tipi di possibili patterns sia architetturali che di sviluppo, è un discorso molto lungo, complicato e interessantissimo, a dire il vero è l’ argomento di un prossimo articolo.
Dovendo anticipare qualcosa e senza scendere nei particolari prendiamo le due più semplici e diffuse, HUB & Spoke e ESB.
HUB & Spoke Fig 1
FIG 1
In questo caso abbiamo i vari BizTalk dislocati sulle varie agenzie o reparti aziendali (SPOKES) e uno centralizzato (HUB)
I vari BizTalk decentralizzati si occupano di integrare le varie tecnologie in periferia e quello centrale “orchestra” i vari messaggi che arrivano dalle sedi.
In questo tipo di soluzione gli stessi BizTalk decentralizzati fungono da Subscribers, internamente all’ HUB centrale è possibile rappresentare i vari attori come “Partners” e creare politiche di smistamento dei messaggi e di comunicazione assolutamente uniche nel suo genere ma anche questo sarà argomento a parte di un futuro articolo.
La natura stessa di BizTalk porta a creare queste architetture in modo naturale.
ESB Fig 2
FIG 2
Enterprise Service BUS, questa è tra le più frequenti, a differenza della precedente sono le varie tecnologie ad essere interfacciate direttamente a BizTalk, ad essere sincero il concetto di ESB è molto più complicato e include concetti molto profondi , standard di interfaccia, di comunicazione, ma adesso quello che desidero è essere semplicemente chiaro.
Nell’ esempio in figura abbiamo un database SQL Server un SAP, un sistema AS/400 e un database Oracle.
Il compito di BizTalk può essere molteplice, dal permettere ai vari sistemi di interscambiarsi le informazioni al gestire un processo di workflow o di business prelevando o ricevendo le informazioni necessarie dai vari attori e nel caso utilizzarle congiuntamente per poi smistarle (Sottoscriverle).
Solitamente è una soluzione interna all’ azienda ed il focus è ottenere un layer assolutamente standard per comunicare con tutte le diverse tecnologie, certo, un layer assolutamente standard quali dei servizi Web come Web Services o WCF (Fig 3)
FIG 3
Questo discorso / percorso intrapreso mi porta a fare tantissime considerazioni, saranno sicuramente stimoli per prossimi articoli...
Vi prego di contattarmi e scrivere per eventuali considerazioni, che potranno sicuramente arricchire e stimolare a nuove discussioni.
Quanto mi diverte l' integrazione! 
giovedì 3 luglio 2008
Ebbene sì, dovrete sopportarvi questo matto che parla di integrazione,BPM, EAI e DDT
per un altro anno ancora.
Mi è arrivata la mail che mi riassegna l' MVP Award, che dire, non ho fatto il post immediatamente, ho voluto prima ripensare a quest' anno di lavoro.
E' stato il mio primo anno da MVP, una esperienza molto intensa e piena di tantissime soddisfazioni, a volte piena di sacrifici ma sacrifici sempre gratificanti grazie alle persone che mi hanno sempre seguito e che ringrazio.
Chi mi conosce sa che fondamentalmente sono una persona semplice e istintiva, per me è stato un anno nel quale ho imparato tantissimo cercando di seguire attentamente i colleghi ormai veterani, ho perso amici e poi ritrovati.
Non sono più la persona di un anno fa, questa esperienza mi ha cambiato molto, in meglio, e questo lo devo soprattutto agli amici MVP che mi sono stati più vicini e mi hanno aiutato a capire tante cose.
Di Lorenzo addirittura pensavo fosse un androide, perchè non gli scappava un mio post e se scrivevo una inesattezza di qualsiasi tipo mi bacchettava immediatamente
, sono certo stia leggendo anche questo
, da lui ho imparato veramente tanto, è una persona assolutamente eccezionale.
Di RAF ho cercato di carpire da dove derivasse quella immensa fonte di energia che sprigiona di continuo , ci sto ancora lavorando
Ho avuto occasione di conoscere nuovi amici veramente speciali come Alessandro , Davide, è un elenco molto lungo.
Ringrazio Alead, un amico sincero e leale, sempre presente nelle necessità e nei momenti difficili.
Quest' anno sarà un anno fantastico e pieno di nuovi propositi, rimbocchiamoci le maniche e mettiamoci al lavoro.
giovedì 26 giugno 2008
Questa che vado a descrivervi è una guida completa per iniziare a comprendere BizTalk, è una guida che vuole fornire tutte le risorse più importanti ed aiutare le principali figure professionali che sono normalmente coinvolte nel normale lifecycle aziendale.
BizTalk è un sistema piuttosto complesso e suddiviso da diversi aspetti architetturali e di infrastruttura.
Direi di dividere in tre sezioni:
Sezione VISION, indicata per persone assolutamente decisionali, alle quali interessa capire gli aspetti più di alto livello del prodotto e di conseguenza delle eventuali soluzioni e scopi.
Sezione ARCHITECT, per persone che lavorano in ambito operativo e decisionale, più vicino all'aspetto tecnico/architetturale
Sezione DEVELOPER, per chi intende lavorare operativamente con BizTalk.
Per le sezioni ARCHITECT e DEVELOPER metterò una sezione FirstAID dove inserirò quella che io definisco, "la borsa degli atrezzi"
Questa guida sarà costantemente aggiornata dal sottoscritto
VISION
Che cos'è BizTalk Server 2006?
Panoramica di prodotto
Funzionalità
Requisiti di sistema
Prerequisite Skills and Knowledge
Webcast
BizTalk 2006 R2: licensing e novità di prodotto
Scenari:
Scenarios for Business Solutions
Casi di successo:
Caso 1
Caso 2
ARCHITECT
Per esperienza credo che queste risorse che vi ho selezionato offrano le risposte alle domande più frequenti:
Requisiti di sistema per BizTalk Server 2006
Planning and Architecture
Planning for High Availability
Designing the System Architectures for BizTalk Server
Runtime Architecture
Management and Tracking Architecture
Performance and Capacity Planning
ESB
Decidere di seguire un pattern architetturale come la ESB Guidance non è semplicissimo, consiglio una letta a questo articolo di Di Paolo De Nictolis, molto ben fatto
SOA, BizTalk ha il suo ESB
Direi che se l' architect necessita di una formazione base BizTalk per poter parlare con gli sviluppatori, la strada migliore è leggersi questo testo:
Foundations of BizTalk Server 2006 (Foundations)
Webcast
Introduzione a Biztalk Server 2006 (Livello 200)
Biztalk Server, amministrazione e troubleshooting (Livello 300)
FirstAID
Versione di valutazione
Planning for Security
Macchina virtuale con Microsoft BizTalk 2006 a bordo, installato e configurato, pronta all'uso
DEVELOPER
Per uno sviluppatore consiglio di inziare per passi e in particolare da una introduzione di massima per poi passare ai dettagli.
La chiave sta nel capire prima cosa sia BizTalk e cosa metta a disposizione, ci sono alcuni libri in commercio, direi che per la parte introduttiva il migliore è:
First Steps: Developing BizTalk Applications
Fornisce una prima panoramica completa mantenedo un livello assolutamente introduttivo
Successivamente passerei a questo testo:
BizTalk 2006 Recipes: A Problem-Solution Approach
E' un percorso che parte dalle basi e tocca tutti gli aspetti proponendo esercizi pratici e spiegando successivamente i relativi aspetti tecnici di BizTalk.
Una volta fatto questi due testi si aprono due strade, una per chi vuole interessarsi maggiormente agli aspetti di gestione, monitoring e amministrazione di BizTalk e l'altro per gli aspetti di personalizzazione e programmazione di basso livello.
Nel primo caso consiglio:
Professional BizTalk Server 2006
E' un testo fatto veramente bene, cura tantissimo gli aspetti di gestione e amminitrazione, non solo, anche la parte monitoring, che in questo libro vede la presenza di un bel centinaio di pagine molto ben fatte inerenti il BAM di BizTalk.
Nel secondo caso:
Pro BizTalk 2006 (Pro)
E' un testo che segue la strada del fratellino Recipes ma proponendo soluizioni che portano a dover utilizzare aspetti di programmazione piuttoto spinti in BizTalk.
Ci sono vari articoli, sicuramente dovendo consigliare un percorso direi:
Articoli:
Biztalk Server 2006 Quick Start
Questi articoli li consiglio dopo aver letto almeno il First Steps: Developing BizTalk Applications
Biztalk Pipelines e dintorni
Biztalk Correlations
E questi per interessanti approfondimenti
Throttling e tecniche di monitoring in Biztalk Server 2006 (Parte I)
Throttling e tecniche di monitoring in Biztalk Server 2006 (Parte II)
Webcast:
Seguendo anche quì un persorso partendo dall' alto verso il basso direi:
Introduzione a Biztalk Server 2006 (Livello 200) Biztalk Server 2006, utilizzo degli schema e delle mappe (Livello 200) BizTalk Server mapping (Livello 300) Biztalk Server 2006, le orchestrations (Livello 200) BizTalk Advanced Orchestration (Livello 300) Biztalk 2006 Adapters Foundations (Livello 200) BizTalk Server Messaging routing (Livello 300) BizTalk Server Business Rules Engine (BRE) e Business Activity Monitoring (BAM) (Livello 300) Biztalk Server, amministrazione e troubleshooting (Livello 300)
Questi webcast per interessanti approfondimenti:
BizTalk Server R2 Accelerator for HL7 2.0 (Livello 300) Biztalk Server, RFID Adapter (Livello 300)
FirstAID
Developing Custom Components Application Deployment Command-Line Reference Developers Reference General AID
Ecco cosa avere sempre con se per sopravvivere a qualsiasi cosa.
Macchina virtuale con Microsoft BizTalk 2006 a bordo, installato e configurato, pronta all'uso
BizTalk Server 2006 R2 Technical Documentation Library
Performance Counters
Application Deployment Command-Line Reference
BAM Command-Line Tools
Developers Reference
UserGroup italiani
http://BizTalkia.com
mercoledì 18 giugno 2008
Sono molto eccitato al pensiero della nuova release, la R3, di BizTalk.
Questa eccitazione deriva dal fatto che le nuove features presentate sono molto interessanti, anche se non del tutto ancora chiare.
Direi che uno dei punti focali risiede nella parte RFID e l'altro sugli adapter.
Il primo è dettato da una attuale esigenza nel dover gestire dispositivi mobile RFID la seconda per la naturale evoluzione che Microsoft sta attuando nel model drive disegn (OSLO).
Devo dire che mi viene da sorridere quando penso al famoso annuncio che venne fatto nel lontano 2005, al PDC, .... "BizTalk è finito!" ,WWF è il futuro!, ai tempi avevamo la versione 2004 e adesso parliamo di R3, di VNext, MDD e della necessità di mantenere la limpida e sempre solida coerenza di BizTalk quale System Workflow.
Ormai credo che siamo ad un punto di svolta decisivo che influirà su tutti noi e che ha già cambiato la mia persona.
Non esistono più prodotti ma framework, non esistono più soluzioni ma model drive, e come tale anche io sto evolvendo verso visioni molto più alte e indubbiamente interessanti.
Inizio ad avere tutte le conferme di quel disegno già intrapreso a suo tempo e che allora potevo solo intuire e intravedevo, l'uscita della Microsoft ESB Guidance for BizTalk Server 2006 R2 su codeplex, che ha iniziato a proporre un interessante pattern di sviluppo verso le service-oriented applications.
Il WCF LOB (Line of Business Adapter) SDK, il preludio verso la possibilità di offrire servizi di integrazione, e quando parlo di servizi non parlo a caso, avere un layer service oriented, in grado di portare una tecnologia ad offrire pattern di integrazione sempre più specializzati.
Si perchè il fine è giustamente questo, fino a ieri si parlava di SAP .Net Connector per integrare un sistema SAP, oggi si parla di utlizzare un servizio WCF integrato o meno nel nostro applicativo e che risulta totalmente astratto al client.
Un servizio fruibile e riutilizzabile da chiunque lo desideri, quello che oggi si chiama BizTalk Adapter Pack.
Il BizTalk Adapter Pack, che al momento si trova alla versione 1.0 ma che conta di una versione 2 in Microsoft Connect, credo sia un ulteriore punto di svolta verso la possibilità di usufruire di soluzioni architetturali sempre più distribuite dove parallelamente ad esso evolve OBA, per fornire soluzioni client su un client che è sicuramente il più conosciuto al mondo.
L' integrazione tra i due mondi era talmente palese da sfociare in un BizTalk Adapter Pack – Office Developer Program
La Connection Systems Division di Microsoft sta lavorando alacremente su OSLO e la sua uscita non è poi così distante, BizTalk per come lo conosciamo andrà avanti ancora per un bel pò di tempo, qualche anno, quanto è difficile stabilirlo.
Anche BizTalk subirà una naturale evoluzione in quello che risulterà in una componente fondamentale di un sistema più grande ed orientato totalmente ai servizi.
Credo comunque che la strada intrappresa sia assolutamente naturale e coerente alle esigenze del business futuro, non resta che attendere i prossimi eventi. 
martedì 27 maggio 2008
Questa volta ho voluto prendere il toro per le corna.
Mi sono ritrovato ad affrontare per l'ennesima volta il problema di passare un file a zero byte in BizTalk.
BizTalk non supporta l'acquisizione di file a zero byte, questo non lo dico io ma Microsoft, è by design.
Il mio cliente mi guarda stranito ed io gli spiego per quale ragione la cosa non sia attuabile.
Le soluzioni proposte in rete sono delle più disparate, la più simpatica che ho trovato consiste....
...prima di andare avanti a leggere sedetevi comodi 
nel monitorare l'event viewer ed intercettare l' errore che restituisce BizTalk, successivamente....
basta così non sono andato avanti a leggere.
Altra e credo unica soluzione degna di considerazione è utilizzare un server FTP, l'adapter FTP legge i file a zero byte, ma chiaramente si è obbligati a usare un server FTP.
Per essere precisi, e devo esserlo, l'adapter file supporta file a zero byte ma solo in send, si tratterebbe quindi di avere un server FTP per la sola ricezione.
Bisogna anche aggiungere che avere un server FTP in ricezione porta a dover gestire problematiche di concorrenza e di lettura che sono facilmente risolvibili su file system.
A questo punto mi sono detto basta, vediamo di mettere fine a questa storia.
A tal scopo ho deciso di fare un adapter file custom in grado di ricevere zero byte, a dire il vero non ero sicuro che funzionasse.
Nell' SDK di BizTalk, precisamente sotto ROOT:\Program Files\Microsoft BizTalk Server 2006\SDK\Samples\AdaptersDevelopment, è possibile trovare un paio di esempi e quello che serve per la relativa compilazione.
Prendiamo appunto ,come esempio, l'adapter file.
Non voglio entrare nel merito di alcune scelte architetturali dell' esempio ma entrare nel merito del problema.
Il punto chiave dell' adapter è chiaramente la funzione CreateMessage che crea il fatidico IBaseMessage, il messaggio.
L'adapter originale altro non fa che leggere un file metterlo in un System.IO.Stream e passare lo stream al Body del messaggio
part.Data = fs;
IBaseMessage message = this.messageFactory.CreateMessage();
message.AddPart(MESSAGE_BODY, part, true);
Il problema che anche in questo caso si incorre nell' errore tanto temuto
The adapter "SticAdapter" raised an error message. Details "SubmitFiles was called with an empty list of Files".
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Originale il nome dell' apadper
, ma la situazione lo richiedeva.
mmmhhhh...
Idea risolutiva!
Passare un Byte a zero direttamete nel body del messaggio 
byte[] bytes = new byte[1];
fs.Write(bytes, 0, 1);
Trace.WriteLine("[BizTalkia.com] Passa il byte");
part.Data = fs;
IBaseMessage message = this.messageFactory.CreateMessage();
message.AddPart(MESSAGE_BODY, part, true);
Chiaramente fs è lo stream dopo la lettura dal file.
Se Il file è a zero byte entra correttamente in BizTalk e quello risultante in uscita è assolutamente di zero byte.
Se è un file pieno rimane integro all'originale, ma è fantastica questa trovata hehehehe
Una volta modificato il codice si tratta di compilare il tutto e eseguire il deploy.
Il deploy è semplicissimo, bisogna creare le chiavi di registry per la registrazione dell' adapter, è possibile trovare in due file che vengono forniti con l' SDK:
DynamicAdapterManagement.reg
StaticAdapterManagement.reg
che trovate sotto ROOT:\Program Files\Microsoft BizTalk Server 2006\SDK\Samples\AdaptersDevelopment\File Adapter
Le modifiche riguardano essenzialmente le directory di riferimento dei vari componenti in gioco.
Nel caso di un adapter sono solitamente tre:
Quello di RunTime, nel caso del nostor adapter è Microsoft.BizTalk.SDKSamples.Adapters.DotNetFile.Runtime.dll
Quello di gestione, cioè la famosa finestra di impostazioni: Microsoft.BizTalk.SDKSamples.Adapters.DotNetFile.Designtime.dll
Quello delle librerie di base, Microsoft.Samples.BizTalk.Adapter.Common.dll, che va rigorosamente messo in GAC.
Infine dalla console di amministrazione di BizTalk, sul nodo Adapters, tasto destro del mouse, new, mettete il nome preferito e selezionate Static DotNetFile.
Avete il codice sorgente a disposizione perciò potete effettuare tutte le modifiche del caso, una molto simpatica sarebbe quella di portare la data e ora del file in una context property, cosa che non è reperibile
utilizzando un file adapter standard, che propone al massimo il CreationTime che si riferisce alla data e ora di creazione del messaggio e non a quello del file.
Beh credo di aver detto tutto e spero che questo possa esser di aiuto a tanti.
giovedì 22 maggio 2008
Mentre lavoravo su una orchestration mi sono reso conto che a volte, nel nostro mestiere, la parte artistica può prendere il sopravvento.
Ecco una delle mie ultime creazioni, è intitolata
Rinascita di una orchestration
Questa è l'orchestration prima della metamorfosi,
stavo davanti al monitor è la osservavo, ad un certo punto ho collassato il gruppo centrale ed ecco il risultato
Una bellissima farfalla :-)
ok ok, adesso , adesso non iniziate, come al solito, a chiedere informazioni sul mio pusher :-)
devo ricordarmi di dirgli di smetterla di usare la varecchina :-D
lunedì 19 maggio 2008
Due persone mi hanno fatto un paio di domande che ritengo possano essere di comune interesse e per questo voglio proporre sul blog con relativa risposta.
La prima riguarda BizTalk ed EDIFACT ed è possibile trovarla sul forum di BizTalkia a questo indirizzo
La seconda via email ecco il testo, ho chiaramente eliminato riferimenti a persone e altro:
Ciao Nino
Il mio obiettivo è quello di scrivere del codice che mi permetta di leggere e scrivere degli RFID in C# Il reader è di marca Work Tag Tecnologies della softwork Id CPR-PR50 USB Gli strumenti che sto usando sono Visula Studio 2005 con linguaggio C#.
Che librerie devo usare?
devo installare qualche driver specifico per far comunicare?
Ora ho cercato diverse strade:
1)Ho cercato di usare del codice Phidget e non ho ben capito se Phidget è una tecnologia applicabile a tutti gli RFID oppure è una marca e quindi il codice è valido solo per quel tipo di RFID.
Ho usato delle librerie denominate MPR e niente.
Ora sono su Intel Mobile Platform ma è un gran casino :) e prima di avventurarmi ulteriormente volevo saper quale sia la strada corretta.
Grazie mille per la tua risposta
Ciao xxxxxx,
Solitamente i fornitori rilasciano il layer di librerie per interfacciare il proprio reader.
Il DSPI della Phidget è indicato per quel reader ma può aiutarti a capire come funziona l'architettura di un DSPI e come implementarlo.
Altro cosiglio, su BizTalkia in area download puoi trovare degli esempi molto ben fatti sviluppati da Claudio.
Altra documentazione molto utile e codice sorgente lo trovi nell' SDK della piattaforma RFID di Microsoft.
Per accordi presi con Microsoft Intel dovrebbe essere in grado di fornire il DSPI per tutti quei reader che riescono a funzionare in emulazione Intel appunto, ma per questo dovresti contattare Intel.
La stada migliore è accertarsi che il fornitore abbia le librerie di interfacciamento con il reader, questo ti solleva da tanto lavoro, esempio la CAEN fornisce tutte le librerie e sono ben disponibili.
Successivamente guardarti la documentazione che trovi sull' help del Microsoft RFID Platform e con quella di fianco ti esegui il debug del sorgente del device della Phidget.
Questo secondo me ti aiuterebbe molto a capire come sia l'architettura di un DSPI e come funziona.
Spero di essere stato abbastanza chiaro, contattami pure se hai bisogno.
Ciao
Nino
Ultima condiderazione aggiuntiva che mi sono dimenticato di mettere nella risposta.
La nuova piattaforma R3 di BizTalk fornirà un altissimo supporto aggiuntivo a tutte le soluzione RFID soprattutto riferito alla nuova piattaforma BizTalk di RFID Mobile.
venerdì 9 maggio 2008
Steve ha pubblicato nuovi aggiornamenti riguardo le nuove features della futura R3.
direi che in generale si allinea a quello che mi aspettavo, anche se non ci si sbilancia molto sulla parte mobile.
Direi che la features più interessante riguarda la parte RFID Mobile.
Aggiornamento alla parte LOB e chiaramente i tanto attesi templates per VS2008.
Comunque ne parleremo meglio Lunedì al BizTalkia Day.
A proposito, l'evento ha avuto il successo che immaginavo i posti disponibili sono ormai molto esigui.