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.