Restriktioner

Alla undantag i BizTalk ska hanteras internt av ESB Exception Management Framework, ESB ramverk för undantagshantering.

Alla undantag i tjänster utanför plattformen måste rapporteras genom webbtjänsten ESB Exception Management Framework.

Om ett fel skulle uppstå i webbtjänsten måste undantaget loggas och rapporteras när tjänsten är tillgänglig igen.

3.5 RESTRIKTIONER

SOA plattformen är uppbyggd på Microsoft .Net teknik, med stöd av Biztalk för transaktionskritiska och sammansatta tjänster.

4.1 UTVECKLINGSMILJÖ

Se dokumentet SOA SDK Installation av utvecklingsmiljö 1.0.

4.2 VISUAL STUDIO SOLUTION

Den Visual Studio-solution som används för utveckling består av flera projekt och referenser. Nedan följer en beskrivning av dessa referenser samt av varje projekt som ingår i solutionen.

4.2.1 REFERENSER TILL PLATTFORMEN

SOA-tjänster behöver ha referenser till ESB.ExceptionHandling.WCF Dessa referenser ligger med i projektets mapp

Stockholm.SOA.Template.WCF.TemplateService.WCFResources.

Användningen av ESB Exception Handling finns beskriven i ServiceImplementation.

4.2.2 PROJEKT SOM SKALL FINNAS I EN SOLUTION

STOCKHOLM.SOA.[MYSERVICE].WCF.SERVICECONTRACTS 4.2.2.1

Detta projekt skall innehålla de .Net klasser som krävs för att kunna skapa ett servicekontrakt för en tjänst.

Tjänstekontraktet definierar de funktioner och processer som publiceras.

Namngivning av metoderna måste ske med ett prefix som hänvisar till den applikationen tjänsten byggs för. Annars kan det uppstå namnkonflikter vid virtualisering av tjänster.

Om detta inte följs kommer tjänsten inte att godkännas för driftsättning i plattformen.

[ServiceOperation(Namespace=”http://stockholm.se/SOA/[Applikation]

/[Tjänst]/[Version]”,Name=”Tjänst”)]

Alla operationer skall följa konventionen

[OperationContract(Action=”http://stockholm.se/SOA/[Application]/WCF/[FEATURE]/[

ResponseMessageType TemplateMyOperation(RequestMessageType request)

ServiceImplementationen måste ange

ServiceBehavior(Namespace=”http://stockholm.se/SOA/[Applikation]/WCF/[Tjänst]/[Ve rsion”,Name=”TemplatedService”)]

STOCKHOLM.SOA.[MYSERVICE].WCF.DATACONTRACTS 4.2.2.3

Detta projekt skall innehålla de datakontrakt som används i lösningen. Alla attribut skall vara ordnade.

[DataContract(Namespace=” http://stockholm.se/SOA/[Applikation]/

[Tjänst]/[Version]”name=”MyDataContract”)]

Public class MyDataContract {

[DataMember(Order=0,IsRequired=true,Name=”MyDataMember1”)]

public string MyDataMember1{get;set;}

[DataMember(Order=1,IsReqired=false,Name=”MyDataMember2”)]

public string MyDataMember2{get;set;}

}

STOCKHOLM.SOA.[MYSERVICE].WCF.MESSAGECONTRACTS 4.2.2.4

Meddelande kontrakt skall också inta ett ordnat förhållande.

[MessageContrac]

public class MyMessageContract {

[MessageHeader]

Public string MessageIdentifier{get;set;}

[MessageHeader]

public string MyMessageHeader{get;set;}

[MessageBodyMember(Order=0)]

public string MyMessageBodyMember1{get;set;}

[MessageBodyMember(Order=1)]

public MyDataContract MyMessageBodyMember2{get;set;}

För spårbarhetens skull kan det vara bra att ange ett meddelande-id i headern.

Felkontrakt

[DataContract(Namespace=” http://stockholm.se/SOA/[Applikation]

/[Tjänst]/[Version]”,Name=”MyFault”)]

public class MyFault {

[DataMember(Order=0)]

public string Fault{get;set;}

[DataMember(Order=1)]

public string FaultMessage{get;set;}

}

STOCKHOLM.SOA.[MYSERVICE].WCF.SERVICEIMPLEMENTATION 4.2.2.6

Er implementationen skall läggas in i detta projekt.

I SDK medföljer ett mallprojekt som är ett tomt skal för hur en solution för en SOA-tjänst ska se ut.

För att skapa en e-tjänste-lösning, utgå från mallprojektet Stockholm.SOA.Template.WCF.Template

4.3.1 ANPASSNING AV SOASERVICETEMPLATE

2. Öppna Stockholm.SOA.Template.WCF.Template.sln

3. Ändra namespaces i alla projekt enligt kapitel 2, exempelvis från Stockholm.SOA.Template.WCF.TemplateService.DataContracts till

Stockholm.SOA.MyApplication.WCF.MyService, genom att högerklicka på projekten och välja Properties > Application.

OBS: Se till att inte använda ett för långt namn på servicen, då det kan göra att sökvägarna i projektet blir för långa. Detta kanske inte upptäcks förrän vid kompilering. En max längd på 60 tecken rekommenderas för

Stockholm.SOA.MyApplication.WCF.MyService. Detta kan variera något beroende på strukturen för den katalog där projektet placeras.

4. Ändra namn på samtliga projekt så att de följer alla namespaces, genom att högerklicka på projektet och välja Rename

5. Ta bort samtliga projekt från lösningen, genom att högerklicka på projekten och välja Remove

7. När man ändrat alla mappnamn, lägg tillbaks samtliga projekt i lösningen, genom att högerklicka på Solution och välj Add > Existing Project. Lägg till samtliga projekt i katalogen.

ersätt Stockholm.SOA.Template.WCF.TemplateService med namnet på din etjänst, exempelvis Stockholm.SOA.[MyApplication].WCF.[MyService]

9. Ändra tjänstens namespace genom att göra en global sökning och ersätt http://stockholm.se/SOA/Template/TemplateService/

med

http://stockholm.se/SOA/[MyApplication].MyService/

Project Reference

MessageContracts

Stockholm.SOA.[MyApplication].WCF.[MyService].F

4.3.2 DEPLOYMENT UNDER UTVECKLING ANVÄND EN CONSOLEHOST

4.3.2.1

Under utvecklingsprojektet använder du ett consolehost-projekt för att kunna felsöka koden. I template-projektet finns kod både för att skapa en körbar consolehost samt en IIS-tjänst som kan användas för att bygga ett deploymentpaket.

KLIENT 4.3.2.2

Under utvecklingsarbetet kan det vara bra att skapa en testklient som kan hämta och

Skall sättas upp i enlighet med dokumentation avseende informationsklassning från Stockholm Stad.

I övrigt används WCF security guidelines vid granskning av SOA-projekten.

4.3.4 BINDNINGAR

Se till att rätt bindingar används mellan klient och service. Använd inte endast default, utan testa den bindning som verkligen kommer att användas vid ett produktionsläge.

5 EXEMPEL PÅ EN SOA-TJÄNST – CASTLE TOUR BOOKINGSERVICE

Projektet Stockholm.SOA.CastleTour.WCF.Booking är exempel på en SOA-tjänst som är utvecklad på plattformen.

Den innehåller exempel på mycket av det som beskrivs i nästa kapitel och kan med fördel användas som hjälpmedel vid utveckling av e-tjänster.

Öppna solutionfilen i Visual Studio för att titta på koden och bygga en consolehost för att stega igenom den.

CastleTour har två befintliga Web-tjänster för att hantera dels bokning av turer, dels för bokning av hotellrum. Dessa används ifrån varsin användarimplementation. Dessa tjänster är utvecklade innan framtageandet av denna SOA SDK, och har därför litet olika namnrymder(namespace) och namn.

Uppdraget är att utforma en SOA-lösning för att generellt hantera bokningar för CastleTours. Lösningen kräver att det är löst kopplade tjänster som kan utföra ett sammankopplat arbetsflöde. De befintliga verksamhetssystemen är byggda som web-tjänster och kan var för sig sköta en bokning.

Men hanteringen kräver en manuell kontroll av betalning i en betalningslista som kommer ifrån fakturaavdelningen. När kontrollen är gjord skickas manuellt en bokningsbekräftelse via e-post till den person som har initierat bokningen.

För bokning av turer med lunch finns en E-tjänst uppsatt där gäster kan boka in sig till guidade turer på de olika slotten. Bokningen skickas i nuläget med e-post till personal som manuellt lägger till en bokning i verksamhetssystemet.

Tjänsten lägger upp ett signerat dokument som innehåller information om gästerna i sällskapet i E-tjänstens mapp FormDataAttachmentTransfer med de metadata som används för filetransfertjänsten. Denna plockar upp filen och lämnar den på en filarea där personalen kan hämta upp den.

5.2 KRAVSPECIFIKATIONEN

Efter en förstudie kommer ni gemensamt fram till att de befintliga tjänsterna

CastleTours.TourService och CastleTours.HotelMgmt går att använda för bokningar.

Dock innehåller bägge varsin lista med gäster och med slott/hotell, men detta är inget som ni kommer att ta hänsyn till i det första genomförandet.

E-tjänsteutvecklarna vill kunna få upp en lista på slott med bilder på slotten för att gäster skall kunna välja slott i en lista. Den informationen finns tillgänglig i

CastleTours.TourService och kommer att användas därifrån. Eftersom listorna på slott och gäster har olika id för respektive slott kommer ni bara att använda text när ni letar upp slotten/gästen.

För att hantera bokningarnas relationer, skapas en ny databas, där relationerna läggs till med pekare mot det bokningsnummer som fås från vardera tjänst. Den tjänsten kommer att ha två metoder. En för att spara bokningsrelationen, och en för att hämta upp

relationen.

Dessutom skall en ny tjänst utvecklas, som kontrollerar om reservationen är betald i

Bokningsnummer => Fakturanummer i demoexemplet. När en fil som innehåller ett aktuellt bokningsnummer kommer in, startar BizTalk en ny orkestrering som skickar ett betalningsmeddelande till respektive bokningtjänst.

När betalningen är slutförd kommer användaren att få ett notifierings-mail med bokningsbekräftelsen, dessutom skall bekräftelsen läggas upp på användarens sida i E-tjänsten.

5.3 DESIGN PÅ IMPLEMENTERADE WCF-TJÄNSTER

5.3.1 HOTELMANAGEMENT

5.4 DESIGN AV BOKNINGSHANTERINGEN