IvanJo's Blog

Speed up! Where we loose ticks...

Ivan — Sat, 27 Sep 2008 06:28:02 GMT

Bizzy (that's how I call it) can be very fast you can bet on it, and it can be as slow as a snail. It's You, yes YOU are the one that make it fly or make it crawl.

As you can see, numbers are very close one to another down to the "Start" of another orchestration. How come? What's going one within the engine so from 140 orchs/sec we drop to 90! Persistence point is the answer! What this means is that the engine persists it's state (state of a running orchestration instance - messages, variables etc.) to database. You can read more on MSDN by clicking here.

Let us proceed. Using a .NET serviced component within an atomic scope shape, BizTalk infrastructure forces using of MS DTC which adds fuel on the fire so we have another dramatic drop in executions from 90 to 54 ONLY!

To conclude, velocity of our system depends not only on project architectural design but also on shapes used within orchestrations. One thing is important to note: before you use any of shapes out there, try to find out how can those have an impact on our overall architecture and system in terms of performance, stability, (im)possibility to scale etc.
I understand that it's not that easy nor it's fast making all of those questions before putting some shape on orchestration designer but, believe on my word, after some experience gained you'll be solving orchestration puzzles quickly and with guaranteed success!

Come salvare un messaggio XML su SQL?

Ivan — Sun, 07 Sep 2008 14:39:24 GMT

Pensavo si trattasse di una cosa naturale e semplice da fare quando cliente me lo ha chiesto di implementare. Progetto che sto seguendo scrive i record su SAP. Nel caso i record sono già presenti, SAP restituisce una tabella dei record scartati. Cliente mi chiese: Senti, ma perché non scriviamo questo messaggio ritornato da SAP as-is su una tabella SQL per eventualmente esaminarli. A che io, con sorriso sulle labbra pensando tra me e me "bello non devo fare nulla con la risposta se non semplicemente salvarla, gli risposi: ma certamente che problema c'è ?!

Non avevo intuito che questa roba mi potesse prendere quasi 4 ore della mia vita

Ho cominciato a creare mio schema SQL come un Updategram. Scegliendo la tabella dove volevo scrivere mi sono beccato questa popup:

Cioè!! Ho detto.. Non posso scrivere in una tabella se questa ha una colonna di tipo XML. Pensa te! Mi sono calmato e pensato: vabbé mi faccio una stored procedure e risolvo così la faccenda.

Quando ho creato mio schema mi sono accorto che tutte le variabili che inviavo a SQL adapter sono, in realtà, gli attributi e non elementi a che ho cominciato a sudare freddo! Capite che non posso passare un XML per intero in un attributo! Per fortuna non ci ho messo molto a capire come risolvere questo problema.

Il problema lo ho approcciato creando una classe helper che, passandogli un XML document mi ritornava base64 encoded string che, a sua volta, finiva come il valore dell'attributo nel messaggio che chiamava la stored procedure (codice completo si vede sotto)

public static class LogXMLHelper    {        public static string EncodeXMLForAttribute(XmlDocument docToEscape)        {            return base64Encode(docToEscape.OuterXml);        }         private static string base64Encode(string data)        {            try            {                byte[] encData_byte = new byte[data.Length];                encData_byte = System.Text.Encoding.UTF8.GetBytes(data);                return Convert.ToBase64String(encData_byte);            }            catch (Exception e)            {                throw new Exception("Error in base64Encode" + e.Message);            }        }     }

A questo punto mia orchestrazione inviava correttamente a SQL quanto serviva ...

L'ultimo problema da risolvere rimasto era come faccio lato T-SQL tradurre questa stringa base64 encodata in XML di partenza?? Alla fine la soluzione riportata sotto ha risolto anche quest'ultimo pezzo della puzzle..

CREATE PROCEDURE [dbo].[LogXMLDocument] @SAPResponse as varchar(MAX)AS DECLARE @BinDecoded varbinary(max); DECLARE @SAPResponseDecoded xml; DECLARE @x xml; set @x = Cast('<row q="' + @SAPResponse + '" />' as xml) SET @BinDecoded = (SELECT @x.value('(/row/@q)[1]','varbinary(max)')) SET @SAPResponseDecoded = Convert(xml, @BinDecoded)  insert into LogTable (SAPResponse,LogTime)         values (@SAPResponseDecoded,getdate())

Chi lo avrebbe detto....

[OT] Finalmente arrivati VSEWss 1.2

Ivan — Sat, 05 Jul 2008 15:54:59 GMT

Finalmente Microsoft ha rilasciato la versione 1.2 di Visual Studio 2008 Extensions x Windows SharePoint Services 3.0. Potete scaricarlo da qui: http://www.microsoft.com/downloads/details.aspx?FamilyID=7BF65B28-06E2-4E87-9BAD-086E32185E68&displaylang=en

WCF net.tcp e compressione dei dati sul canale

Ivan — Fri, 27 Jun 2008 12:43:28 GMT

Mica roba da ridere...Speravo molto più facile..

Il problema di un cliente è stata questo: tramite un link satellitare bisogna scambiare i dati fra 15 point diversi dove un punto gioca ruolo del server e altri 14 sono i client. I client non comunicano tra loro, ma soltanto con server. Peccato che questo link va e viene a piacere, e potrebbe non esserci per delle giornate intere. Oltre a questo si tratta della banda paragonabile ai vecchi modem a 56KBps. Ve li ricordate ancora?

Quindi si è pensato un sistema di chunking dei messaggi da inviare (non in WCF) spezzettandoli nei piccoli frammenti. Si tratta di XML e nel caso dei chunk più grossi di 1K contenuto veniva GZippato ed encodato in base64 per essere fruibile dal WCF-NetTcp BizTalk Adapter.

Se a questo punto avete pensato: mi faccio un componente zip per la pipeline e la uso direttamente.. - non si può !! Questa non funziona perché adapter WCF si aspetta un messaggio XML per poterlo trasformare in SOAP ed inviarlo a destinatario. Una bella fregatura direi..

Dopo un po' di ricerche ho trovato degli articoli ed i post interessanti sul tema:

Microsoft lo farebbe così. Come l'idea è valida, ma non compila o così (ma non lo ho ancora provato - se qualcuno lo ha già provato e funziona bene fatemelo sapere!)
Un certo Pablo Cibraro usa WS-Compression per WCF per farlo, ma pare che abbia dei problemi. Vedete qui.
Progetto su CodeProject nominato CompactMessageEncoder cerca di risolvere questo problema.

Quindi, ho fatto un po' di prove qua e là e ho deciso di approcciare mio problema usando CompactMessageEncoder. Mediante un binding element extension si sceglie di aggiungere la compressione del canale.

Per come è stato strutturato il progetto, prevede la Send Port dinamica ed, ovviamente, la Receive Location definita da BizTalk Administration Console. Questa receive location viene configurata come WCF-Custom e nel tab Binding scegliere binding type customBinding e poi aggiungere compactMessageEncoding e tcpTransport (come da foto).

Per poterlo vedere, compactMessageEncoding, bisogna prima registrarlo nel machine.config (vedi questo link). Una volta configurato tutto la location è pronta.

La send port, se ricordate, era dinamica. Per farla funzionare ho usato questo link da Microsoft (parte specifica a WCF-Custom). Per quanto riguarda le impostazioni per WCF.BindingConfiguration ho usato quelli dai .config file trovato nello zip di CompactMessageEncoder.

Magicamente ha funzionato tutto...

NB. CompactMessageEncoder non funziona bene con WCF Configuration tool, quindi lo ho dovuto modificare un attimino...

Come eseguire procedure SQL 2005 che non hanno dbo?

Ivan — Tue, 17 Jun 2008 07:41:51 GMT

Ad un mio cliente piace tanto organizzare le tabelle, procedure le viste usando gli schima diversi da dbo (sto parlando dei schima usati da SQL - non BizTalk). Non è malvagio quest'approccio perché si va a finire un bel organizzato progetto su SQL. Peccato che a BizTalk non piace tanto questa cosa...

Ho avuto problema a generare i schema su BizTalk usando SQL Adapter wizard. Regolarmente non trovava la procedura stored che volevo eseguire. Il bello è che nella lista comparivano tutte le procedure definite (come vedete dallo screenshot)

Peccato che quando spingevo bottone "Generate" nello script non mi veniva fuori anche nome dello schema dove la procedura si trova, quindi sarebbe dovuto esserci: exec [spSync].[SetChunkedMessage] ...

Questo problema si potrebbe ovviare creando una procedura identica a quella che si vuole eseguire, ma sotto lo schema dbo e poi richiamarla ds VS2005. Una volta creato lo schema bisogna cambiare l'attributo value del nodo msbtssql:sqlScript, aprendo lo schema in XML puro, in da exec [SetChunkedMessage] a exec [spSync].[SetChunkedMessage] (come si vede sulla foto sotto)

Preparatevi per la doccia fredda: per la Send Port questo "trucco" non funziona

Custom adapters & proprietà promosse

Ivan — Tue, 10 Jun 2008 04:57:33 GMT

Toccato profondamente da uno dei ultimi post di, mio carissimo amico, Nino Crudele "File a ZERO byte in BizTalk e Creare un CUSTOM ADAPTER" dal fatto che a FILE adapter mancano le proprietà come LastWriteTime o FileCreationTime mi sono messo a pensare come aggiungerli facilmente. In realtà non è niente di trascendentale, ma un po' di lavoro c'è ne.

Da dove si parte? Bhe, partiamo dalla bozza di adapter che troverete nel suo post sopra cittato. In particolare pezzo di codice che bisogna aggiungere è subito dopo la chiamata alla funzione CreateMessage.

private const string DOT_NET_FILE_PROP_REMOTEFILENAME = "FileName";private const string DOT_NET_FILE_PROP_CREATIONTIME = "CreationTime";private const string DOT_NET_FILE_PROP_LASTWRITETIME = "LastWriteTime";private const string PROPERTYNAMESPACE = "http://schemas.microsoft.com/BizTalk/2003/dotnetfile-properties"; part.Data = fs;IBaseMessage message = this.messageFactory.CreateMessage();message.AddPart(MESSAGE_BODY, part, true); message.Context.Promote(DOT_NET_FILE_PROP_REMOTEFILENAME, PROPERTYNAMESPACE, (object)srcFilePath);message.Context.Promote(DOT_NET_FILE_PROP_CREATIONTIME, PROPERTYNAMESPACE, (object)fileCreationDate);message.Context.Promote(DOT_NET_FILE_PROP_LASTWRITETIME, PROPERTYNAMESPACE, (object)fileModificationDate);

Una volta che file è uscito dal adapter in BizTalk avrete messaggio (e le proprietà) come questi:

Quindi, siamo riusciti a valorizzare contesto del messaggio con delle proprietà nostre. Per arrivare a punto di leggerle dalla nostra orchestrazione dobbiamo fare altre 2-3 cosette.
Questo è facile: dobbiamo creare una "property schema" che contiene le nostre proprietà promosse. Dopo aver creato lo schema dovete cambiare la proprietà Target Namespace in "http://schemas.microsoft.com/BizTalk/2003/dotnetfile-properties" che è il valore della costante PROPERTYNAMESPACE nel codice sopra. Dopo questo aggiungete le proprietà che abbiamo deciso di promuovere: FileName, CreationTime e LastWriteTime. Alla fine avrete uno schema come seguente:

Siamo arrivati alla fase conclusiva: leggere le proprietà promosse tramite un "expression shape" dall'orchestrazione. Si fa così, ma questo probabilmente lo avrete già capito da soli:

filename=msg_input(MyProject.Schemas.Adapters.FileName);
createDate=msg_input(MyProject.Schemas.Adapters.CreationTime);

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

Questo è tutto.

Parallel shape (blocco) - demistificato

Ivan — Mon, 09 Jun 2008 01:03:00 GMT

Tutti sbagliano! Anch'io ho sbagliato diverse volte.

Ma, ho deciso di porre fine a questo! Non se ne po più ad usare blocco parallelo pensando che BizTalk tiri su 2 thread e faccia lavoro su 2 processori o addirittura 2 macchine diverse. Questa non la vedrete ragazzi - almeno non nelle versioni di BizTalk che vi sono sul mercato.

Guardate queste due immagini...

Ora vi spiego perche un bel' pezzo di "codice" come questo del immagine 1 è diverse volte più lento.

Persistenza

A mio parere questa è una delle più importanti "feature" di BizTalk. Si tratta di un meccanismo interno di BizTalk, completamente trasparente a noi, che sui diversi punti nella orchestrazaione (ben definiti !!!) salva lo stato ti tutte le variabili, i messaggi ecc. Si tratta di una specie di "recovery point" da usare nel caso succedesse qualcosa di imprevisto; nostra orchestrazione ripartirebbe dal ultimo punto conosciuto.

Nel caso di blocco "Parallel" questo avviene alla fine di ogni ramo. Nel caso sopraindicato si trattarebbe di 3 scritture su DB dello stato associato!

Come l'ultima cosa, vorrei sottolineare il fatto che i processi messi nei rami parallel non assolutamente creano diversi thread ma vengono eseguiti in seriale.

A questo punto probabilmente vi chiedete: ma per che cosa servono allora 'sti parallel shape??
La risposta è che sono stati pensati solamente per i processi che, prima di procedere, devono essere tutti arrivati alla fine - quindi solo per assicurare il fatto che non si va avanti con l'orchestrazione se tutti i rami non sono stati eseguiti.

Spero che questo lo troverete utile - per me lo sarebbe stato di certo qualche anno fa.

Spaccare i record SQL in n messaggi - SQL debatching

Ivan — Tue, 03 Jun 2008 17:37:25 GMT

Qualche giorno fa, per la n-esima volta mi sono trovato di fronte alla stessa domanda: "ma se io ho una stored procedure e tiro su diverse righe mi piacerebbe elaborarle come i messaggi singoli. Come faccio?"

Stranamente, ma non è proprio una cosa "supportata by design" come lo è usando Flat File Schema Wizard.

Quindi, l'idea generale è questa:

creo la stored procedure per tirarmi i dati da SQL
mi creo lo schema usando "Add Generated Items..." - SQL wizard
imposto le proprietà usate da debatching engine (XMLReceive pipeline)
creo nuovo schema che come nodo root ha quello del singola pizza e includo XSD precedentemente creato
imposto le proprietà che distinguono questo schima da quello già definito
deploy-o e creo la porta di ricezzione SQL ed, eventualmente, la porta Send, di tipo FILE, per salvare da qualche parte risultato di debatching

Per questo post ho creato 3 tabelle nel DB 'Pizze': Pizze, Ingredienti e Pizze_Ingredienti. (Nota: nel .ZIP che ho incluso si trova SQL script del DB)

Poi, ho creato una stored procedure ps_Menu come segue:

A questo punto siamo pronti per creare lo schema che rapresenta il nostro 'menu del giorno'. (Nota: ricordatevi, una volta creato lo schema, di togliere XMLDATA dalla stored perché così ritornerà i dati a posto della struttura!)

Per creare lo schema, vado su progetto (in VisualStudio), clicco sul tastro destro e scelgo Add Generated Items... Imposto SQL adapter configurando l'accesso al DB puntando quello delle pizze. La prossima schermata si presenta come quella sotto per definire un "Namespace" da usare per questi messaggi ed imposto Root element Name.

Sulla prossima schermata scelgo la "Stored Procedure" ed arrivo su quella che mi permette di scegliere la procedura da eseguire. Da menu a tendina seleziono "ps_Menu" e clicco bottone "Generate".

Oltre allo schema che vedete sotto viene anche generata una orchestrazione. Questa a noi non serve per cui la cancelliamo dal progetto.

Per puro piacere rinomino lo schema a: MenuPizze.xsd

Prima di proseguire, devo togliere tag XMLDATA dalla stored procedure per poter ricevere i dati da SQL.

Il fatto di processare ogni record ritornato da SQL come un messaggio si chiama debatching - quindi spaccare un unico messaggione in tanti messaggi piccoli. Per fare ciò BizTalk prevede l'utilizzo della pipeline XMLReceive (che imposteremo più tardi) e proclamando lo schema che abbiamo precedentemente creato di essere un Envelope. Quindi imposto la proprietà Envelope a true e Max Occurs del nodo Pizze a 1 e Body XPath del nodo MenuDelGiorno a MenuDelGiorno

Fin' qui è tutto regolare e lineare - come per fare debatching di qualuncue altro messaggio. Purtroppo, lo schema generata da SQL wizard include un tag di più di quanto noi ne abbiamo bisogno il MenuDelGiorno. Per risolvere questo dobbiamo applicare un trucco: creare un nuovo messaggio che abbia la stessa struttura per quanto riguarda il nodo Pizze però al livello root!
La via più breve, ed anche più corretta, è usare XSD Include dopo avere creato nuovo messaggio (come da immagine):

In questo modo abbiamo tutta la struttura presente nello schema creata da SQL wizard sotto quella nostra. Ora non rimane da fare altro che:

Creo lo schema Pizza.XSD
Cambio la proprietà Target Namespace a http://solnuke/test/Pizze/SQLDebatching
Clicco la proprietà Imports, scelgo XML Include dalla tendina e punto lo schema creato da wizard
Rinomino nodo 'Root' a Pizze e cambio sua proprietà Data Structure Type a PizzeType
L'ultima cosa da fare e cambiare la proprietà Root Reference a Pizze altrimenti avrete un messaggio nel event log come questo:

Error details: There was a failure executing the receive pipeline: .... Reason: Cannot locate document specification because multiple schemas matched the message type http://solnuke/test/Pizze/SQLDebatching#MenuDelGiorno

Ci sarebbe da impostare anche la pipeline sulla porta di Receive e configurarla come XMLReceive (raffigurata dall'immagine sottostante)

Ecco, questo è quanto. Vi allego anche un piccolo progetto per giocarci. Dentro lo ZIP troverete la cartella col progetto e un file .SQL per crearvi la struttura del database Pizze. Prima di testare aggiungete qualche pizza a menu :-)

Scarica qui: Pizza-SQLDebatching.zip

BizTalk add-in per Reflector

Ivan — Sun, 02 Mar 2008 07:56:00 GMT

Reflector lo conoscete tutti ormai (se no mi raccomando scaricatelo)

Questo add-in vi permette di vedere tutti gli "artifact" presenti nella .dll aperta (screenshot sotto).

Primo

Ivan — Sun, 02 Mar 2008 07:45:00 GMT

Ciao a tutti,
Intanto vorrei presentarmi. Sono Ivan Jocic (pronunciato come ivan iozici), e se non riuscite a pronunciarlo bene, allora non scrivetemi :) Scherzo.

Con BizTalk ci lavoro da quasi 4 anni. Ho iniziato con 2004 e ormai sono da un bel pezzo su 2006. Ho lavorato tanto sulla parte architetturale di alcuni progetti grossi e anche tanto come programmatore.
In questi anni ho potuto scoprire diversi bugs di Biz2004 e assieme ai team di Microsoft (UK, Francia, USA) li abbiamo risolti ed inpachettati nei relativi HotFix. Quei momenti mi hanno portato un know-how piu' sistemistico direi a gli sono molto grato.

Ovviamente io non sono soltanto un Biztalkiano; lavoro sul web e win32..

Credo che basti per iniziare, e voi?

ps. Scusatemi quando vedete le parole (specialmente le doppie) scritte male :) Nessuno e' perfetto...