...
Öppna därefter ett kommandofönster och gå till installations-mappen, för att bygga och testa källkoden med hjälp av Maven:
...
Dessa Route:s kan i sin tur ha olika in och utgångar eller vara sammankopplade. Detta gör att det är enkelt att skriva kod där varje steg i processen kan skrivas utföras av en enskild klass med en specifik uppgift. Dessa steg kan sedan relativt enkelt kopplas samman i flöden som är enkla att överblicka och följa. Det gör det även enkelt att lägga till eller dra ifrån steg i processen, skapa undantag och vägval efter behov och/eller återanvända flera steg i en process genom att skapa en specifik Route för dessa.
Det finns många positiva superlativ att orda säga om Camel. Men det är värt att notera, att som ny användare av ramverket, är det lätt att förväxla en Route-konfigurering med kod som exekveras (passerar anktestet).
Men egentligen är det API:et till ramverket som utformats så att det “liknar” programmering. Det här behöver inte vara ett problem, men är värt att ha i bakhuvudet.
De Routes/Flöden som styr data-flödet i VP skapas upp i klassen VPRouter. Den klassen är en väldigt bra ingång , för att få en överblick över VP. Man kan mycket väl hävda att den bättre beskriver flödet än t.ex. ett flödesdiagram.
För att flytta data mellan stegen processen/Routen processerna i routen används ett Exchange objekt. Detta är en realisering av konceptet Message exchange pattern vilket vi känner igen från t.ex. Rest SOAP etc. Som nämnts kan en Route börja i lite av varje men i VP:s fall kommer Exchange objektet att emanera från
I VP emanerar Exchange objektet från en web-socket, och den använder Exchange objektet som placeholder för data som kommer in den vägen. Egentligen: payloaden (Payloaden, SOAP meddelandet) , hamnar i attributet In.Body , headrar Headrar placeras i In.Headers etc. o.s.v.
I princip kan/bör varje steg i flödet genom VP motsvaras av en implementation av det enkla interfacet Processor vilken , vilket har en metod process, som tar just en Exchange.
Exchange In vs Out.: En egenhet är att om man exempelvis vill göra ändringar i In.Body innan den skickas vidare till nästa steg så görs detta enklast genom att stoppa tillbaka ändringen i In.Body. Det kan verka lite ointuitivt först, men under förutsättning att vi inte försökt sätta Out “manuellt” så används In som Out till nästa steg. På det viset följer övriga attribut som headers, attachments etc. med automatiskt.
I praktiken jobbar de olika stegen i VP i huvudsak med attributen: In.Body (Soap meddelandet), In.Headers för att läsa headers som kommit in och lägga till headers som behöver läggas till åt Producenten, samt Propertys vilka ligger direkt på Exchangen och används för att överföra data mellan de olika stegen i flödet.
En annan egenhet är att strömmad data kan realiseras lite olika. I VP:s fall så är bodyn, direkt ur lådan, ett läs-en-gång attribut. Vi har kringgått detta genom att slå på streamCaching.