Instruktioner för utvecklare
...
Initial uppsättning av utvecklingsmiljön
...
...
...
...
Instruktioner för använda lokal Ping konsument vid tester mot VP och dess interna VP producent
...
Ytterligare information om koden m.m. hittas i SAD:en, på sidan SKLTP VP SAD - Implementationsvy
Innehållsförteckning |
---|
Initial uppsättning av utvecklingsmiljön
Sätt upp utvecklingsmiljö enligt följande: Generella instruktioner för utvecklare.
...
Exempel på checkout kommando för virtualiseringsplatformen
|
Öppna därefter ett kommandofönster och gå till installations-mappen, för att bygga och testa källkoden med hjälp av Maven:
|
Hur köra automatiska tester
Alla automatiserade enhetstester och integrationstester går att köra via Maven utan att någon infrastruktur behöver vara uppsatt.
|
Hur ser det ut i utvecklingsmiljön?
Efter att koden importerats i en lämplig utvecklingsmiljö (IntelliJ eller Eclipse t.ex.) så kan applikationen startas i run/debug som VpServicesApplication:
...
Applikations-strukturen ska i IntelliJ se ut som detta:
...
Hur commita kod
För att committa källkod på GitHub följer vi standardproceduren beskriven på: Generella instruktioner för utvecklare.
Hur göra en release
För att bygga en release följer vi standardproceduren beskriven på: Generella instruktioner för utvecklare.
Lokal verifiering
För att verifiera att VP Camel är installerat och igång på ett normalt sätt, så kan man anropa statustjänsten med t.ex. Curl, se punkt 4 på denna sida: SKLTP VP Camel - Installation
För att anropa VP Camel med Soap-requests så behöver man sätta upp en testmiljö med t.ex. SoapUI.
Övrigt
Expandera | ||
---|---|---|
| ||
Camel implementerar ett så kallat domän-specifikt språk (E)DSL. Detta används för att styra data flödet mellan olika processer. Vilket görs genom att man skapar upp ett eller flera flöden kallade Routes i en Routebilder. 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 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. De Routes/Flöden som styr data-flödet i VP skapas upp i klassen För att flytta data mellan 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. I princip kan/bör varje steg i flödet genom VP motsvaras av en implementation av interfacet Processor, 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å |