Utveckling av demonstrationsmiljö för en plattform för hantering av informationsflöden D A N I E L S T A A F

Utveckling av demonstrationsmiljö för en plattform för hantering av informationsflöden D A N I E L S T A A F Examensarbete Stockholm, Sverige 2006

Utveckling av demonstrationsmiljö för en plattform för hantering av informationsflöden D A N I E L S T A A F Examensarbete i datalogi om 20 poäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2006 Handledare på CSC var Inge Frick Examinator var Stefan Arnborg TRITA-CSC-E 2006:034 ISRN-KTH/CSC/E--06/034--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.csc.kth.se

Utveckling av demonstrationsmiljö för en plattform för hantering av informationsflöden Sammanfattning Denna rapport beskriver bakgrunden till och implementationen av ett förenklat arbetsflöde för elektronisk handel. Moderna tekniker som XSL och Web Services används och fakturor skapas i två olika XML-format, e2b Invoice och UBL Invoice. Kommunikationsplattformen TOPCALL används för att leverera fakturor via fax och för att ge återkoppling via e-post, SMS, röstmeddelanden etc. Mellanprogrammet inubit Business Integration Server utvärderas också och används för att knyta ihop de olika komponenterna. Utvärderingen visar att inubit Business Integration Server är utmärkt för snabb utveckling av prototyper och samtidigt tillräckligt bra för att användas i produktion. Prestanda och skalbarhet är medelmåttiga men bör inte innebära något problem med tanke på dagens låga hårdvarupriser. Development of a Demonstration System for a Business Integration Platform Abstract This report describes the background and implementation of a simplified workflow for electronic commerce. Modern techniques like XSL and Web Services are used and invoices are created in two different XML formats, e2b Invoice and UBL Invoice. TOPCALL, a communication platform, is used for delivering invoices by fax and giving feedback by e-mail, SMS, IVR etc. The middleware inubit Business Integration Server is also evaluated by using it to connect the different components. The results of the evaluation show that inubit Business Integration Server is excellent for quick prototyping and still good enough for serious use. Performance and scalability are average but should be no problem with today's low hardware prices.

Innehållsförteckning 1 Inledning... 1 1.1 Bakgrund... 1 1.2 Problem... 1 1.3 Syfte... 1 1.4 Avgränsning... 1 2 Teori... 2 2.1 Mellanprogram... 2 2.1.1 Problem med mellanprogram... 4 2.2 Elektroniska fakturor... 5 2.2.1 Exempel på moderna standarder för elektroniska fakturor... 5 2.3 Simulering... 6 2.3.1 Fördelar... 6 2.3.2 Nackdelar... 7 2.4 XSL... 7 2.4.1 Extensible Stylesheet Language Transformations (XSLT)... 7 2.4.2 Extensible Stylesheet Language Path Language (XPath)... 7 2.4.3 Extensible Stylesheet Language Formatting Objects (XSL-FO)... 7 3 Analys... 8 4 Metodbeskrivning... 8 4.1 Agile Software Development... 8 4.2 Utvärdering av program... 9 5 Lösning... 9 6 Resultat... 10 6.1 TOPCALL... 10 6.1.1 TCOSS... 10 6.1.2 Line Server... 10 6.1.3 Klient-PC... 11 6.1.4 Arkivserver... 11 6.1.5 Talsvar... 11 6.1.6 Länkserver... 11 6.2 inubit Business Integration Server... 12 6.3 TOPCALLdemo... 14 6.3.1 Hårdvara... 14 6.3.2 Mjukvara... 14 6.3.3 Översikt... 14

6.3.4 Databaser... 15 6.3.5 Menyer... 16 7 Slutsatser... 17 7.1 TOPCALL... 17 7.2 inubit Business Integration Server... 17 7.3 Fakturastandarder... 18 7.4 Webblösning... 18 7.5 Konvertering av PDF-filer... 19 7.6 Alternativa lösningar... 19 7.6.1 All logik i PHP5 på webbservern... 19 7.6.2 All logik i Java på webbservern... 19 7.6.3 Databasdriven lösning... 19 7.7 Nackdelar med grafisk programmering... 20 Litteraturlista... 21 Bilagor... 22 Bilaga 1: inubit Business Integration Server 4.0... 22 Bilaga 2: Menyer i TOPCALLdemo... 24 Processmenyn... 24 Databasmenyn... 26 Webbshop... 27 Presentation... 28 Bilaga 3: Databaser... 29 Bilaga 4: Filstruktur... 30

Figurförteckning Figur 1 Stordator med terminaler... 2 Figur 2 Persondatorer kopplade till en server... 2 Figur 3 Servrar kopplade till persondatorer och tunna klienter... 3 Figur 4 Exempel på system utan mellanprogram... 3 Figur 5 Exempel på system med mellanprogram... 4 Figur 6 Systemöversikt för TOPCALL... 10 Figur 7 Arbetsflöde i inubit Business Integration Server... 12 Figur 8 Systemanslutningar... 12 Figur 9 Konfigureringsguide för databasanslutning... 13 Figur 10 Inbyggd XSLT-editor... 13 Figur 11 Översikt... 15 Figur 12 Huvudmeny... 16 Figur 13 Spårningsläge... 22 Figur 14 Simulering... 22 Figur 15 Loggning och köhantering... 23 Figur 16 Rapportgenerator... 23 Figur 17 Ny slumpvis order... 24 Figur 18 Godkänn order... 24 Figur 19 Attestera faktura... 25 Figur 20 Betalda fakturor... 25 Figur 21 Meddelanden till TOPCALL... 26 Figur 22 Ändra meddelande till TOPCALL... 26 Figur 23 Webbshop... 27 Figur 24 Val av fakturatyp... 27 Figur 25 Bekräfta order... 27 Figur 26 Order skickad... 28 Figur 27 Presentation styrd via talsvar... 28 Figur 28 Tabellstruktur för databasen Sim... 29 Figur 29 Tabellstruktur för databaserna Seller och Buyer... 29

1 Inledning 1.1 Bakgrund Företaget LEKAB Communication Systems AB har under många år sålt kommunikationslösningar som baseras på produkten TOPCALL till större företag i Norden. TOPCALL, som utvecklas av det österrikiska företaget TOPCALL International AG (numera en del av brittiska DICOM Group plc), är en kommunikationsplattform som integrerar ett företags IT- och telefonisystem med publika kommunikationstjänster. Exempel på tillämpningar är en funktion för att skicka SMS direkt från MS Outlook och faxservern som kan översätta inkommande fax till text och leverera resultatet som ett e-postmeddelande till rätt mottagare, samtidigt som faxen arkiveras i ett format som gör att de kan plockas fram utan fördröjning 10 år senare. 1.2 Problem En del av LEKABs kunder känner inte till att TOPCALL är mer än en faxserver och detta examensarbete går ut på att ta fram en demonstrationsmiljö som på ett illustrativt sätt demonstrerar möjligheter och nytta med en kommunikationslösning från LEKAB. TOPCALL är klient-server-baserat och fungerar utmärkt i statiska system med fasta förbindelser mellan de ingående komponenterna men är mindre lämpat för system som ändrar sig mycket. För att möta kundernas behov av moderna, flexibla kommunikationslösningar och samtidigt dra nytta av TOPCALLs beprövade teknik behöver LEKAB utöka sitt produktutbud med någon form av mellanprogram (eng. middleware). TOPCALL International AG föreslog inubit Business Integration Server 4.0 från det tyska företaget inubit AG och demonstrationsmiljön är därför uppbyggd med hjälp av detta program. LEKAB var speciellt intresserat av hur mellanprogrammet kan användas för att skicka och ta emot elektroniska fakturor. 1.3 Syfte Syftet med examensarbetet var att: Utreda vilka möjligheter TOPCALL och inubit Business Integration Server 4.0 erbjuder. Implementera ett förenklat arbetsflöde för elektronisk handel med hjälp av inubit Business Integration Server 4.0. Elektroniska fakturor enligt någon modern standard skulle ingå och återkoppling i processen skulle ske via TOPCALL. Skapa en slagkraftig presentation av det hela som kan användas i LEKABs marknadsföring. Utvärdera hur väl inubit Business Integration Server 4.0 passade för uppgiften. 1.4 Avgränsning De komplexa interaktioner som finns i ett normalt order- och faktureringssystem simuleras på enklast möjliga sätt. Det viktiga är att visa det mervärde som går att få ut genom att kombinera de ingående komponenterna, inte en specifik e-handelslösning. Felhantering av undantagsfall som normalt utgör en stor del av arbetet med att ta fram denna typ av system begränsas till ett minimum. 1

2 Teori Detta kapitel ger en kort introduktion till några områden som berör examensarbetet. 2.1 Mellanprogram I dagens stora företag finns i allmänhet en mängd olika verksamhetskritiska datorsystem på olika plattformar. På 60- och 70-talet sköttes all datahantering i en stordator (Figur 1) men på 80-talet kom persondatorn och nyutvecklingen inriktades på en klient-server-modell där en samling applikationer körs lokalt på användarnas datorer och delar data via en server (Figur 2) [Stonebraker, 2002]. Figur 1 Stordator med terminaler Figur 2 Persondatorer kopplade till en server Den ökade tillgången på datorkraft gav upphov till många nya applikationer och gjorde att slutanvändarna kunde anpassa sin datormiljö i betydligt större utsträckning än tidigare. Med hjälp av makron i kontorsprogrammen kunde även vanliga användare skapa komplicerade lösningar utan att behöva anlita dataavdelningen för att göra dyra ändringar i stordatorn. 2

Tyvärr visade sig de administrativa kostnaderna vara stora med denna modell och när webben kom på 90-talet gick man tillbaka till en mer centraliserad modell. Moderna applikationer körs till stor del på servern och persondatorn fungerar närmast som en smart terminal (Figur 3). Figur 3 Servrar kopplade till persondatorer och tunna klienter Eftersom stora summor lagts ner på att skräddarsy de äldre systemen har de sällan kunnat ersättas helt utan kopplats ihop med de nya systemen med någon form av filöverföring. I början skapades dessa länkar helt för hand med egna protokoll från fall till fall men numera används ofta s.k. mellanprogram (eng. middleware). Ett mellanprogram hjälper till med översättning mellan olika filformat och erbjuder köhantering, loggning och stöd för dokumentation genom t.ex. automatiskt genererade flödesscheman. Mellanprogrammet minskar också kopplingen mellan olika system och gör det lättare att byta ut valda delar (Figur 4 och 5). Tanken är att ge företagen bättre kontroll över sina interna processer och skapa ett virtuellt enhetligt system, trots att de olika delsystemen skiljer sig mycket åt, genom att mellanprogrammet fungerar som spindeln i nätet. På engelska kallas detta för Enterprise Application Integration (EAI). Exempel på sådana här system är IBM WebSphere MQ (hette tidigare IBM MQSeries), Sun Java System Message Queue och TIBCO BusinessWorks [Medjahed, 2003]. Data Säljsystem Utskriftssystem Lagersystem Telefonisystem Data Ordersystem Faktureringssystem Betalningssystem Data Data Data Figur 4 Exempel på system utan mellanprogram 3

Säljsystem Utskriftssystem Telefonisystem Lagersystem Mellanprogram Data Ordersystem Faktureringssystem Betalningssystem Figur 5 Exempel på system med mellanprogram På senare år har EAI-leverantörerna fått konkurrens av företag som säljer lösningar som de kallar för Web Services. I marknadsföringen sägs de vara effektivare uppbyggda och allmänt bättre än de äldre EAI-systemen eftersom de använder öppna protokoll som Simple Object Access Protocol (SOAP), Web Service Definition Language (WSDL) och Universal Description, Discovery and Integration (UDDI) [Patil, 2003]. I praktiken är det bara ytterligare en form av abstraktion under ett nytt namn för att sälja bättre. Alla leverantörer säger sig numera stödja Web Services. Ett viktigt område för mellanprogram är automatiserad handel mellan företag, Business-to- Business Integration (B2B). Elektronisk handel mellan företag har funnits länge men tidigare användes komplicerade standarder som Electronic Data Interchange (EDI) som krävde dyra speciallösningar vilket utestängde mindre företag. Internet kombinerat med nya XML-baserade protokoll har sänkt ingångskostnaderna och det är tur eftersom storföretagen numera ofta kräver elektroniskt koppling mellan sitt och underleverantörernas order- och faktureringssystem. Tyvärr kan företagen fortfarande inte komma överens om att använda ett och samma format så en underleverantör med flera stora kunder kan ha stor nytta av ett mellanprogram. Exempel på produkter: IBM WebSphere Partner Gateway, Microsoft BizTalk Server, Oracle Fusion Middleware, TIBCO BusinessConnect. 2.1.1 Problem med mellanprogram Mellanprogrammet är ett extra system att underhålla. Kräver personal som är utbildad på systemet, om sådan saknas internt i organisationen kan det vara bättre att använda en enklare lösning än att anlita dyra konsulter för att skapa ett system som visserligen är mycket anpassningsbart men bara för konsulterna. Mycket tid kan gå åt till oväsentligheter eftersom mellanprogrammen har många funktioner och erbjuder flera alternativa sätt att bygga upp systemet på. En bra princip är att bygga så enkelt som möjligt. Ökade hårdvarukrav eftersom mellanprogram i sig drar en del resurser. Risk för långa svarstider eftersom data kanske kopieras och översätts onödigt mycket mellan de olika lagren. Om data mellanlagras för att snabba upp transaktionerna uppstår i stället synkroniseringsproblem där delar av systemet riskerar att använda gamla data. Kan vara besvärligt att hantera fel som uppstår eftersom det är svårt att förutse alla interaktioner som kan uppstå i ett distribuerat system [Kuo, 2003]. Om en felsituation inte hanteras rätt kan det leda till följdfel som är mycket svåra att rätta till eftersom systemets totala tillstånd är utspritt över så många komponenter. Många leverantörer att välja på och risk för inlåsningseffekter, viktigt att ha en klar plan för vad man vill åstadkomma för att kunna välja rätt. 4

Stora företag kan ha dålig samordning mellan olika delar av företaget och står då snart med en mängd olika mellanprogram. De blir då en del av det problem de var till för att lösa. 2.2 Elektroniska fakturor Ett företag står och faller med att få betalt för sina varor och tjänster och det finns stora pengar att spara på en effektiv hantering av fakturor. Med Internet och dagens datoriserade order- och faktureringssystem finns förutsättningar för att skapa en helt elektronisk hantering där fakturan aldrig behöver gå omvägen via papper. Detta har en rad fördelar: Kortare tid till betalning eftersom fakturan kommer fram direkt utan att riskera att komma bort i postgången. Inga brev- och portokostnader. Bättre säkerhet, enkelt att verifiera sändare och mottagare med digitala signaturer vilket minskar risken för bluffakturor. Systemet kan generera statistik och lätt upptäcka avvikelser och slå larm. Mindre tidsåtgång för attestering, lätt att hantera även komplicerade processer där många personer måste godkänna en faktura. Minskat beroende av administrativ personal, faktureringen kan fortsätta fungera även om administratören blir sjuk. 2.2.1 Exempel på moderna standarder för elektroniska fakturor cxml Invoice Commerce XML (cxml) är en proprietär standard för e-handel från det amerikanska företaget Ariba, Inc. som säljer olika plattformar för hantering av affärsprocesser. Se http://www.cxml.org/ för mer information. Visa XML Invoice XML-baserad proprietär fakturastandard från VISA som administrerar några av de vanligaste betal- och kreditkorten. Se http://international.visa.com/fb/downloads/commprod/visaxmlinvoice/ för mer information. RosettaNet PIP 3C3 RosettaNet är en ideell samarbetsorganisation för mer än 400 företag inom elektronikindustrin. Organisationen grundades 1998 och arbetar med att ta fram specifikationer för automatiserad handel mellan medlemsföretagen. Varje specifikation definieras i en s.k. PIP (Partner Interface Process) och grupperas tillsammans med andra liknande specifikationer i ett antal kluster och segment i RosettaNets klassificeringssystem [Damodaran, 2004]. Exempelvis är PIP 3C3 den tredje PIPen (sista trean) i segment C i kluster tre (första trean) och kallas även Notify of Invoice. Kluster tre är Order Management och segment C betyder Returns and Finance. Ursprungligen användes DTD (Document Type Definition) för att definiera en PIP men numera används XML Schema. Se http://www.rosettanet.org/ för mer information. UBL Invoice Universal Business Language (UBL) är en öppen XML-baserad standard skapad av OASIS för utbyte av alla sorters affärsdokument. Standarden är en implementation av en del av ramverket ebxml (Electronic Business XML, ISO 15000) och uppbyggd av en mängd delkomponenter kallade Business Information Entities (BIEs) som kan sättas ihop till specifika 5

dokumentmodeller. UBL Invoice är en dokumentmodell för fakturor. Version 1.0 av standarden finns på http://docs.oasis-open.org/ubl/cd-ubl-1.0/. e2b Invoice En norsk öppen XML-baserad standard skapad av e2b Forum som är ett samarbete mellan några av de största företagen i Norge. Se http://www.e2b.no/. e-faktura En elektronisk informations- och betalningstjänst för distribution och presentation av elektroniska fakturor till Internetbanker i Sverige. Anslutna banker är FöreningsSparbanken, Sparbanken Finn, Nordea, Svenska Handelsbanken, SEB, ÖEB, SkandiaBanken, ICA Bank och Länsförsäkringar Bank. Fakturamottagaren får fakturan presenterad i en lista hos sin Internetbank och behöver endast godkänna betalningen då all information redan är ifylld med automatik. Fakturautställaren kommunicerar inte direkt med banken utan via ett fakturahotell (drivs av exempelvis TietoEnator och WM-data) som håller reda på fakturan och återrapporterar till fakturautställaren när betalning erhållits. Fakturorna skickas till fakturahotellet i ett radorienterat filformat med klara anor från stordatorvärlden. För att använda tjänsten måste fakturautställaren skriva ett avtal med FöreningsSparbanken eller Nordea. Se http://www.e-faktura.com/ för mer information. 2.3 Simulering Vid uppbyggnad av komplexa system är simulering ett bra verktyg [Banks, 2003]. Genom att skapa en datormodell av det system man vill bygga upp blir det lättare att prova olika lösningar och få fram den som är bäst. Simuleringen kan vara mer eller mindre verklighetstrogen och det är viktigt att lägga sig på rätt nivå och bara ta med de saker som krävs för att få de svar man letar efter. En onödigt komplicerad modell tar både längre tid att bygga upp och köra vilket ökar kostnaderna. Om det exempelvis är ett datorsystem med ett par hundra datorer som ska byggas upp kan ett bra sätt vara att köpa in ett fåtal datorer och testa dem grundligt i en testmiljö. Utifrån detta kan sedan en modell av det stora systemet byggas upp för att se om det kan tänkas fungera som det var tänkt. Det finns simuleringsprodukter att köpa med färdiga modeller för de flesta tänkbara delar som kan ingå i ett system. 2.3.1 Fördelar Lätt att ändra olika indata och användningsmönster, systemets beteende vid extrem belastning kan studeras. Det går att experimentera med olika sätt att bygga systemet och snabbt se vad som skulle hända om t.ex. antalet servrar ökades. Förståelsen av systemet kan öka och simuleringen kan fungera som utbildningsresurs för det färdiga systemet. Användarna kan på ett säkert sätt själva få experimentera med simuleringssystemet innan de ger sig på det riktiga systemet. Möjlighet att komprimera och expandera tiden i systemet för att exempelvis se vad som skulle hända om en viss del av systemet gick långsammare än normalt. Systemet kan optimeras med avseende på kostnad och prestanda. Schouwenaar och Martin [2003] tar upp ett exempel där kostnaden för driften av ett faktureringssystem kunde minskas med över 10 % genom att simulera systemet och hitta flaskhalsarna. Osäkerheten över vilka marginaler som behövs minskar. 6

2.3.2 Nackdelar Det är svårt att göra simuleringar och det krävs stor kunskap av den som gör simuleringen. Minsta fel i modellbygget kan göra resultaten helt missvisande. Det kan vara svårt att tolka resultaten. Beroende på hur komplicerad modellen är kan simuleringen ta lång tid att köra och kräva dyra datorresurser. 2.4 XSL Extensible Stylesheet Language (XSL) är en familj bestående av tre olika rekommendationer (standarder) från World Wide Web Consortium (W3C) [Quin, 2005]. 2.4.1 Extensible Stylesheet Language Transformations (XSLT) XSLT är ett XML-baserat språk som används för att översätta mellan olika XML-vokabulärer. En XSLT-fil består av ett antal instruktioner och mallar som associerar ett visst mönster i infilen mot en viss utmatning i utfilen. 2.4.2 Extensible Stylesheet Language Path Language (XPath) XPath är ett uttrycksspråk som används i exempelvis XSLT för att välja ut delar av en XML-fil. 2.4.3 Extensible Stylesheet Language Formatting Objects (XSL-FO) XSL-FO är en XML-vokabulär med formateringsinstruktioner som exempelvis fontstorlek. Används som mellanformat när ett XML-dokument ska översättas till ett sidbeskrivningsspråk (t.ex. PostScript) för utskrift på papper. 7

3 Analys För att ta fram en demonstrationsmiljö är det viktigt att ta reda på hur den ska användas. Ofta har kravställaren inte klart för sig exakt vad som önskas och därför är en iterativ metod där många prototyper tas fram i korta iterationer att föredra. Utvecklingen av prototyperna ger erfarenhet och insikt i hur tekniken fungerar, vilka begränsningar som finns och hur detta bör påverka utformningen. Denna typ av lösningsmetod kallas numera för Agile Software Development och är var vad som användes i detta examensarbete. Mer traditionella metoder som exempelvis Rational Unified Process (RUP) övervägdes men bedömdes vara mindre lämpligt för uppgiften. Efter några iterationer utarbetades följande riktlinjer: För att lätt kunna köra demonstrationsmiljön ute hos en kund ska en webblösning användas där alla program körs på servern och säljaren styr dessa via Internet med en vanlig webbläsare. Webb- och databasservrarna ska vara fria program med öppen källkod för maximal flexibilitet och prestanda. Demonstrationsmiljön måste visa vad produkterna kan men får samtidigt inte vara för komplicerad så att det tar för lång tid att visa de olika funktionerna. Det finns många olika tekniker för att skapa webblösningar men valet föll på webbservern Apache 2 kombinerat med skriptspråket PHP5 och databashanteraren PostgreSQL 8.1. I slutet av arbetet tillkom även databashanteraren MySQL 5. Utvärderingen av TOPCALL och inubit Business Integration Server 4.0 bestod i att läsa manualer och använda programmen med de utvärderingsområden som anges i metodbeskrivningen nedan i åtanke. 4 Metodbeskrivning 4.1 Agile Software Development Principerna bakom denna metod är följande: Högsta prioritet är att göra kunden nöjd genom att tidigt och kontinuerligt leverera värdefull mjukvara. Ändrade krav är välkomna, även sent i utvecklingsprocessen. Fungerande mjukvara ska levereras ofta. Affärsfolk och utvecklare ska jobba tillsammans dagligen under hela projektet. Projekt ska byggas runt motiverade individer som får det stöd de behöver. Det bästa sättet att förmedla information är samtal ansikte mot ansikte. Fungerande mjukvara är främsta måttet på framsteg. Hållbar utveckling, deltagarna ska inte behöva slita ut sig utan kunna arbeta i jämn takt under lång tid. Kontinuerligt beaktande av teknisk fulländning och god design. 8

Enkelhet, att maximera den mängd arbete som inte görs, är grundläggande. De bästa arkitekturerna, kraven och konstruktionerna skapas av självorganiserande arbetsgrupper. Arbetsgruppen reflekterar regelbundet över hur arbetet kan göras mer effektivt och gör nödvändiga förändringar. I jämförelse med exempelvis RUP prioriterar Agile Software Development individer och samarbete framför processer och verktyg. Fungerande mjukvara är viktigare än omfattande dokumentation och förmågan att svara på förändring viktigare än att följa en viss plan. För mer information se http://www.agilealliance.com/. 4.2 Utvärdering av program Vid utvärderingen av de ingående programmen var följande områden särskilt intressanta: Tidsåtgång för att skapa en viss funktion Möjligheter att koppla ihop med andra system Prestanda och skalbarhet 5 Lösning Arbetet började med att en relationsdatabasstruktur (Figur 29 i bilaga 2 på sidan 29) utformades med utgångspunkt från XML-formatet e2b Invoice. Därefter skapades PHP-skript som använde databasen så att det gick att lägga till och visa data med en webbläsare. Det visade sig snart att databasstrukturen var besvärlig att jobba med så den förenklades genom att ta bort allt som hade med kortbetalning och extrapriser att göra. Ett förenklat gränssnitt skapades också genom att lägga till vyer och användardefinierade funktioner i databasen. När databasen var färdig började arbetet med att skapa arbetsflöden (se avsnitt 6.2 på sidan 12) i inubit IS. Detta skedde till stor del experimentellt genom att pröva sig fram och läsa dokumentationen för TOPCALL och inubit IS i takt med att behov uppstod att använda de olika funktionerna. Ursprungligen var tanken att demonstrationsmiljön skulle ha ett helautomatiskt läge där slumpvisa beställningar skapades automatiskt men vid samtal med slutanvändarna framkom att de inte var intresserade av denna funktion. Demonstrationsmiljön kräver därför alltid interaktion med användaren men är förberedd för simuleringsfunktioner om behov skulle uppstå. Vid användningstesterna framkom att användarna ville ha ett mer konventionellt sätt att skapa beställningar på än den knapp för att skapa en slumpmässig som fanns. Valet föll på att använda Zen Cart (http://www.zen-cart.com/ ) som är en webbshop skriven i PHP med öppen källkod och baserad på oscommerce (http://www.oscommerce.com/ ). Zen Cart fungerar bara med MySQL så därför tillkom även denna databashanterare. Zen Cart s databas hade med fördel kunnat användas i stället för den befintliga databasen i PostgreSQL men eftersom detta hade inneburit en hel del förändringar i resten av systemet skapades i stället ett arbetsflöde i inubit IS för att automatiskt läsa över beställningar från Zen Cart s MySQL-databas till säljarens databas i PostgreSQL. Användningstesterna gav också önskemål om att kunna styra en PowerPoint-presentation via en mobiltelefon. Detta löstes genom att modifiera en befintlig talsvarslösning och spara presentationen som HTML med lite extra JavaScript (Figur 27 i bilaga 2 på sidan 28). 9

6 Resultat 6.1 TOPCALL Den senaste versionen av TOPCALL är uppbyggd enligt Figur 6. Klient-PC med Windows TOPCALL for Windows Arkivserver TC Foundation Classes Outlook-plugin TCP/IP Talsvar TCP/IP Huvudserver med Windows NT/2k/2003 TOPCALL Open Server Software (TCOSS) TCP/IP Länkserver med Windows NT/2k/2003 TOPCALL Link Package (TCLINK) TCLINK-FI TCLINK-GW TCMON TCLINK-MX TCLINK-LN TCSNMP TCLINK-SM TCLINK-MQ TCLINK-X4 TCP/IP TCP/IP Line Server ISDN TCSOAP TCIMG32... T E L E O P E R A T Ö R Figur 6 Systemöversikt för TOPCALL 6.1.1 TCOSS TOPCALL Open Server Software (TCOSS) är spindeln i nätet och sköter exempelvis routing, köhantering, omsändningar och kvittenser. Kommunikationen med övriga delar i systemet sker med ett eget protokoll över TCP/IP. För att få feltolerans finns möjlighet att sätta upp en extra TCOSS-server på annan plats som kan ta över om huvudservern går ner. 6.1.2 Line Server Tidigare satt telefonikorten i samma dator som kör TCOSS men nya installationer använder i stället separata rackmonterade datorer som kallas Line-servrar och är lättare att byta om de går sönder av exempelvis ett blixtnedslag. 10

6.1.3 Klient-PC Slutanvändarna kommer normalt åt funktionerna i TOPCALL via en tilläggsmodul i den grupprogramvara som används, t.ex. Outlook. För administrativa användare finns program som visar allt som händer i systemet och där administratören kan gå in och se vilka meddelanden som skickats m.m. Klientprogrammen kan antingen prata direkt med TCOSS-servern över TCP/IP eller använda TOPCALL Foundation Classes som är ett antal COM-objekt i en ActiveX-dll och erbjuder ett mer lättanvänt gränssnitt. 6.1.4 Arkivserver En arkivserver används för att långtidslagra sända och mottagna meddelanden på ett säkert sätt. Arkivservern indexerar informationen så att den snabbt kan plockas fram senare vilket är ett myndighetskrav inom vissa branscher. 6.1.5 Talsvar TOPCALL kan kopplas ihop med talsvar från andra tillverkare och har även en enklare egen lösning som bygger på MS Speech API (SAPI) och Windows Script Host. 6.1.6 Länkserver Länkservern fungerar som länk mellan TOPCALL och andra system. De flesta länkmodulerna arbetar i batch-läge där inkommande och utgående meddelanden mellanlagras i kataloger för att sedan plockas upp av en annan modul med jämna mellanrum. Några exempel på länkmoduler: File Interface (TC/Link-FI) Skickar vidare meddelanden som placeras i en viss katalog till TCOSS och levererar inkommande meddelanden från TCOSS i en annan katalog. MS Exchange (TC/Link-MX) Utbyter meddelanden med MS Exchange. Novell GroupWise (TC/Link-GW) Utbyter meddelanden med Novell GroupWise. Lotus Notes (TC/Link-LN) Utbyter meddelanden med Lotus Notes. X.400 (TC/Link-X4) Utbyter meddelanden med antika system som fortfarande använder X.400. SMTP (TC/Link-SM) Utbyter meddelanden med de flesta e-postsystem. MQ (TC/Link-MQ) Utbyter meddelanden med IBMs kösystem MQ som används för kommunikation med stordatorer. SOAP (TC/Link-SOAP) Utbyter meddelanden med program som pratar SOAP, t.ex. inubit Business Integration Server. 11

6.2 inubit Business Integration Server I förutsättningarna ingick att använda det Java- och XSL-baserade arbetsflödesprogrammet inubit Business Integration Server 4.0. I detta mellanprogram sker programmeringen delvis grafiskt genom att dra och släppa symboler för olika komponenter i ett flödesschema, kopplingar mellan olika komponenter visas med pilar (Figur 7). Arbetsmetoden blir med nödvändighet iterativ genom att utvecklaren skapar en del av arbetsflödet, testkör det och sedan använder utmatningen från hela eller delar av det i den fortsatta utvecklingen. De arbetsflöden som visas i de följande bilderna är en del av TOPCALLdemo (se avsnitt 6.3 på sidan 14). Figur 7 Arbetsflöde i inubit Business Integration Server Kommunikation med omvärlden sker med hjälp av s.k. systemanslutningar System Connectors. I Figur 7 finns två sådana, en HTTP Connector (symbol med texten HTTP://) och en Database Connector (symbol med ett stiliserat skivminne). Vilka systemanslutningar som kan användas bestäms av programmets licensnyckel, i det här fallet ingick följande systemanslutningar (Figur 8). Systemanslutning för TOPCALL (variant av Web Service-anslutning dvs använder SOAP) Figur 8 Systemanslutningar 12

Systemanslutningarna konfigureras med guider (Figur 9) och XML-styrfiler på ingången. Exempelvis används en XSLTkonverterare (symbol med tre kugghjul) överst i Figur 7 för att skapa en styrfil som sedan matas in i en databasanslutning. XSLT-konverteraren programmeras i XSLT som skrivs in antingen i den inbyggda editorn (Figur 10) eller i ett externt program. Den inbyggda editorn har tre ramar där den övre visar XSLT-filen, den nedre vänstra ett källfilsexempel och den högra ett exempel på hur utfilen ska se ut. Exempelramarna erbjuder en genväg till att skriva in XSLT-instruktionerna för hand genom att pekdonet kan användas för att dra och släppa delar av trädstrukturen från exempelramarna till det övre fönstret. För att testa att XSLT-filen fungerar finns det en knapp i verktygsfältet med tre kugghjul på. Ett tryck på den och en resultatfil visas i fliken Mapping results (samma ram som exempelutfilen). Resultatfilerna kan också ses med hjälp av spårningsläget, se bilaga 1. Figur 9 Konfigureringsguide för databasanslutning Figur 10 Inbyggd XSLT-editor 13

6.3 TOPCALLdemo Arbetet resulterade i en demonstrationsmiljö kallad TOPCALLdemo. Här följer en kort systembeskrivning. 6.3.1 Hårdvara Modern PC med tillräckligt med arbetsminne, t.ex. en 3GHz P4 med 1GB RAM och 120GB hårddisk. En PC med Windows och TOPCALL Open Server Software (TCOSS) med tillhörande Line Server som kopplar den till telenätet. 6.3.2 Mjukvara MS Virtual PC 2004 http://www.microsoft.com/windows/virtualpc/ MS Windows Server 2003 Std http://www.microsoft.com/windowsserver2003/ TOPCALL Link Package 2.14.03 (TCLINK) inubit Business Integration Server 4.0 (Java- och XSL-baserat arbetsflödesprogram) http://www.inubit.com/inubit.php?id=3&sub=&lang=en Apache HTTP Server 2.0.55 (webbserver, Öppen källkod) http://www.apache.org/ PHP 5.1 (skripttolk, Öppen källkod) http://www.php.net/ PostgreSQL 8.1 (relationsdatabashanterare, Öppen källkod) http://www.postgresql.org/ MySQL 5.0.17 (relationsdatabashanterare, Öppen källkod) http://www.mysql.com/ Xpdf 3.01 (program som bl.a. kan konvertera pdf-filer till bilder, Öppen källkod) http://www.foolabs.com/xpdf/ ImageMagick-6.2.5 (bildkonverteringsprogram, Öppen källkod) http://www.imagemagick.org/ Zen Cart 1.2.6d (webbshop skriven i PHP, Öppen källkod) http://www.zen-cart.com/ 6.3.3 Översikt TOPCALLdemo består av ett antal PHP-skript, fyra databaser och en mängd arbetsflöden i inubit Business Integration Server (Figur 11). TCLINK kräver Windows men resten av programmen kan köras på någon variant av Linux eller UNIX. Vid utvecklingen användes MS Virtual PC med två virtuella maskiner med MS Windows Server 2003, en för TCLINK och en för resten av programmen. Ursprungligen var tanken att säljare och köpare skulle ha var sin virtuella maskin men testmaskinens minne räckte inte till så säljare och köpare delar på Apache, PostgreSQL och inubit Business Integration Server. 14

Apache HTTP Server med PHP PHP-skript PostgreSQL Säljare Köpare Sim JDBC3 MySQL Zencart JDBC3 inubit IS Arbetsflöden SOAP TCLINK Fil in/ut pdftoimage.cmd TCOSS pdftoppm (Xpdf) convert (ImageMagick) Talsvarsskript Figur 11 Översikt 6.3.4 Databaser TOPCALLdemo använder följande fyra databaser: Zencart Används av webbshopen Zen Cart 1.2.6d. Sim Lagrar de meddelanden som TOPCALL ska skicka vid en viss statusövergång (se Figur 22 i bilaga 2). Tabellstrukturen visas i Figur 28 i bilaga 3. Seller Säljarens databas med tabellstrukturen (Figur 29 i bilaga 3) modellerad efter de fält som finns i XML-formatet e2b Invoice. Buyer Köparens databas med samma tabellstruktur som säljarens. 15

6.3.5 Menyer TOPCALLdemo är webbaserat och använder strikt XHTML 1.0 vilket alla moderna webbläsare har stöd för (testad med Firefox, Konqueror, Opera och IE 6). De olika menyerna nås genom att klicka på menyraden högst upp i fönstret (Figur 12). Figur 12 Huvudmeny Menyraden innehåller följande alternativ: Process Visar processmenyn, se Figur 17 till Figur 20 i bilaga 2. Databas Visar databasmenyn, se Figur 21 i bilaga 2. Utfiler Visar ett index över de utfiler systemet skapat, exempelvis fakturor. Webbshop Visar en enkel handelsplats för fiktiva varor, se Figur 23 i bilaga 2. Presentation Visar ett bildspel som styrs via ett talsvar, se Figur 27 i bilaga 2. 16

7 Slutsatser 7.1 TOPCALL TOPCALL är lätt att koppla ihop med alla program som har någon form av programmeringsstöd och det går snabbt att ta fram lösningar med systemet. Prestanda är bra och när systemet väl är uppsatt är det stabilt. I likhet med en del andra komplicerade system kräver TOPCALL stora kunskaper av den som installerar serverdelarna och installationsprogrammen är definitivt inte gjorda för att användas av någon som inte vet exakt hur systemet fungerar. Installationsprogrammet för TOPCALL Link Package visar t.ex. en mängd inställningar i alldeles för många dialogrutor efter varandra utan hjälptexter och utan möjlighet att backa om något av valen blir fel. Dessa dialogrutor hade med fördel kunnat utelämnas eftersom det är lättare att göra inställningarna i efterhand i Windows registereditor eller genom att läsa in en registerfil sparad som text. Ett nytt installationsprogram är på gång för nästa version av TOPCALL och det blir förhoppningsvis bättre. Den SOAP-modul på länkservern som användes för TOPCALLdemo hade relativt begränsad funktionalitet men när detta skrivs har det kommit en ny produkt, TCOSS Web Services (TWS), som ger tillgång till betydligt fler funktioner i TOPCALL. Med TWS går det att använda SOAP för att t.ex. läsa meddelanden i realtid från TCOSS och arkivservrar. Klientprogrammen fungerar bra men ser något omoderna ut eftersom de inte har uppdaterats utseendemässigt de senaste åren. Fördelen med detta är att de är resurssnåla och fungerar bra även med äldre versioner av Windows. 7.2 inubit Business Integration Server inubit Business Integration Server (inubit IS) har en modern och överskådlig arkitektur och baseras på flera välkända komponenter som utvecklas som öppen källkod vilket borde bidra till bra stabilitet. Eftersom programmet är Java-baserat kan det köras på alla operativsystem med Java-stöd vilket är en klar fördel jämfört med konkurrenter som MS BizTalk. Utvecklingsgränssnittet är långt ifrån så förfinat som i exempelvis BizTalk men fyller sin funktion och det självuppackande installationsprogrammet på 128MB (vilket inkluderar dokumentation och Sun JRE 1.4) visar att programmet är betydligt snålare med diskutrymme än många konkurrenter. Det första intrycket av det grafiska arbetssättet var att det var ineffektivt men efter lite träning gick det snabbt att ta fram lösningar med programmet. Att översätta från ett XML-format till ett annat var lätt gjort och det är nog denna typ av uppgifter programmet passar bäst för. Databasfunktionerna fungerade bra för enklare operationer men att t.ex. läsa från flera kopplade tabeller krävde separata steg med flera XSLT-konverterare efter varandra. Att läsa in hela tabellerna och koppla ihop dem med XSL är långsamt eller omöjligt om tabellerna är stora. Några lämpliga vyer i databasen löser naturligtvis detta problem men det är inte alltid det går att ändra i databasen. Programdokumentation var fullt läslig men något kortfattad vilket inte gjorde så mycket då programmet är logiskt uppbyggt, oftast gick det att pröva sig fram till en lösning utan att läsa dokumentationen. Den höga abstraktionsnivån underlättar förändringar men innebär också att vissa operationer blir onödigt krångliga. De grafiska arbetsflödena inbjuder till att involvera beställaren i hela utvecklingsprocessen men värdet av detta kan diskuteras, alla kan inte läsa ett flödesschema hur logiskt det än är, speciellt inte om det består av hundratals komponenter vilket kan krävas i ett stort system. 17

Det finns några irriterande småfel som att å, ä och ö inte går att använda i namn på arbetsflöden och en bild av ett arbetsflöde går bara att få ut ur programmet via rapportgeneratorn som då sparar den i jpeg-format (en skärmdump ger bättre bildkvalité). Möjligheterna att koppla ihop inubit IS med andra system är goda. Om det är någon anslutning som saknas går det lätt att skapa egna tilläggsmoduler i Java. När det gäller prestanda är det svårt att dra några säkra slutsatser. De arbetsflöden som skapades var inte speciellt utformade för att mäta prestanda men visade på att exekveringstiden varierar mycket beroende på hur arbetsflödena utformas. Svagheten i programmet verkar vara Javas minneshantering för det längsta arbetsflödet i TOPCALLdemo som tog runt en sekund att köra på testdatorn kunde ta uppåt 15 sekunder att köra under Virtual PC. En installation av inubit IS bör därför planeras noggrant så att tillräckligt med minne allokeras till Java och processorn bör ha så stort cache-minne som möjligt. Som standard använder inubit IS den Java-baserade databashanteraren HSQL för alla loggfunktioner men den går att byta ut mot t.ex. MySQL eller Oracle. HSQL är förmodligen ett bra val, tester med MySQL visade sig ge något lägre prestanda. Att byta ut den medföljande Sun JRE 1.4 mot senaste versionen av Sun JRE 1.5 gav också lägre prestanda. Skalbarheten bör vara acceptabel eftersom det finns möjlighet till lastbalansering genom att sprida ut hela eller delar av arbetsflöden på flera datorer med var sin installation av inubit IS. Någon sådan avancerad installation testades dock inte. Sammantaget kan sägas att affärsprocesser som ändras ofta och inte är extremt tidskritiska med fördel kan implementeras med inubit IS. Programmets styrka ligger i visualisering av affärsprocesser men är fullt användbart även i produktion, särskilt med tanke på de sjunkande hårdvarupriserna. inubit IS har däremot inga avgörande fördelar i jämförelse med konkurrenterna och i de fall en kund redan använder ett annat mellanprogram är det naturligtvis det som ska användas för att skapa kopplingen till TOPCALL. 7.3 Fakturastandarder Efter att ha gått igenom en mängd standarder för elektronisk handel är det bestående intrycket att de olika aktörerna på marknaden har svårt att komma överens. Även om det skett en viss konsolidering de senaste åren så finns det fortfarande alldeles för många snarlika standarder. Med XML-baserade standarder är det visserligen någorlunda enkelt att översätta mellan olika format men det är onödigt arbete som borde kunna undvikas. En del av problemet kan bero på att många företag i branschen fortfarande tycks basera sin affärsmodell på att försöka införa en standard de själva hittat på och samtidigt låsa in den bakom krångliga licensavtal och patent. Detta främjar definitivt inte utvecklingen av elektronisk handel. Framtiden för konsulter som kan området ser i alla fall ljus ut. 7.4 Webblösning Apache 2 och PHP 5 gav bra prestanda och var lätt att jobba med. Om systemet hade varit större hade någon form av Java-lösning kunnat vara aktuell men PHP5 är överlägset enkelt att snabbt skapa prototyper i. Alternativ som Python hade kanske passat ännu bättre men PHP5 har fördelen av att vara enklare att förstå för den som brukar jobba med C, C++, C#, Visual Basic och Java. En lösning med MS Internet Information Services (IIS) och ASP.NET hade varit ett krångligt, icke-portabelt alternativ utan några egentliga fördelar. PostgreSQL 8.1 fungerar utmärkt och har blivit bra mycket bättre i de senaste versionerna och står sig nu väl i konkurrensen med t.ex. MS SQL Server. Prestanda är utmärkta och programmet har stöd för alla funktioner som krävs i en databashanterare. MySQL 5 är däremot en besvikelse, bl.a. fanns en bugg i version 5.0.15 (som deklarerats som stabil av MySQL AB) som 18

gjorde att vissa av frågorna i Zen Cart inte fungerade. Även om buggen fixades i version 5.0.16 så är det inte så förtroendeingivande att träffa på sådana fel i stabila versioner. Stödet för stored procedures och triggers är heller inte lika beprövat som i PostgreSQL och med tanke på att det tillkommer en licenskostnad för att använda MySQL i program som distribueras utan källkod är PostgreSQL ett bättre val. Webbshopen Zen Cart är mycket bra med tanke på att det är gratis men har också en del brister. Den har bara stöd för MySQL och även om det framgår av koden att PostgreSQL-stöd är på gång kommer det nog ta lite tid att lägga till på rätt sätt. Koden använder MySQL-specifika funktioner som t.ex. mysql_insert_id() (PostgreSQL 8.1 har dock fått en ny funktion lastval() som gör ungefär samma sak). Koden är lite väl ostrukturerad på sina ställen och det märks att det är många olika personer som har skrivit den. 7.5 Konvertering av PDF-filer TOPCALL har stöd för att konvertera PDF-filer till sitt interna bildformat men lösningen som används innebär en extra licenskostnad. För TOPCALLdemo användes i stället de fria kommandoradsprogrammen pdftoppm (ingår i Xpdf) och convert (ingår i ImageMagick). pdftoppm kan konvertera varje sida i en PDF-fil till en bildfil i PPM-format (Portabel Pixmap Format) och med hjälp av convert kan sedan dessa bilder slås ihop till en enda bild i TIFFformat. Tagged Image File Format (TIFF) har stöd för flera sidor och är enkelt att läsa för TOPCALL. convert är ett utmärkt program och kan spara mycket tid för den som behöver konvertera några hundra bildfiler till ett annat format och kanske ändra storleken samtidigt. 7.6 Alternativa lösningar Demonstrationsmiljön hade mycket väl kunnat utvecklas utan inubit IS. Här följer en kort genomgång av några möjliga alternativ: 7.6.1 All logik i PHP5 på webbservern PHP5 är ett fullt utvecklat programmeringsspråk med bra stöd för abstraktioner som exempelvis klasser och det finns en mängd färdiga moduler att använda. Att skicka meddelanden via TOPCALL hade antingen kunnat göras som i inubit IS med hjälp av SOAP eller (med webbservern under Windows) genom att installera TOPCALLs klientpaket och använda COManrop mot TOPCALL Foundation Classes. Ett annat alternativ hade varit att installera webbservern på samma maskin som TOPCALLs länkpaket och spara filer med utgående meddelanden i en speciell katalog som läses med jämna mellanrum av TC/Link-FI (se avsnitt 6.1.6). 7.6.2 All logik i Java på webbservern Någonting liknande arbetsflödena i inubit IS hade kunnat byggas upp i Java med vanlig kod. Komponenterna i inubit IS hade då motsvarats av Java-klasser och med en lämplig klasshierarki kunde programmeringen ha gjorts i någon av de avancerade UML-editorer som både kan skapa och läsa in Java-kod. En mer dynamisk lösning är också tänkbar med dynamiskt skapade klasser som serialiseras och sparas i en databas. 7.6.3 Databasdriven lösning Att lägga all kod i webbservern är den enklaste lösningen men en databasdriven lösning där en del av logiken ligger i databasen har en mängd fördelar: Minskad mängd kod som körs på webbservern. 19

Naturlig separation av affärslogiken från presentationen, inget behov av att bygga upp extra abstraktioner i webbkoden för att dela på logiken om olika webbgränssnitt för olika användare ska byggas upp. Data behöver inte flyttas fram och tillbaka lika mycket vilket kan ge bättre prestanda. Möjlighet till säkrare hantering av data där webbservern inte har direkt tillgång till tabellerna utan måste gå via databasfunktioner som validerar indata. Ett intrång på webbservern behöver därför inte betyda att angriparen automatiskt kan ladda ner hela databasen. PostgreSQL stödjer s.k. stored procedures och triggers vilket innebär att databasadministratören kan lägga in programkod som körs när en viss händelse inträffar, t.ex. när en ny post läggs till i en tabell. Programkoden lagras antingen som källkod direkt i databasen eller kompilerad i externa bibliotek med en stubbe i databasen som talar om hur koden ska anropas. Det finns en mängd programspråk att välja på men för Java finns PL/Java som kör en virtuell Java-maskin i samma process som databasen (se http://gborg.postgresql.org/project/pljava/). Java har bra stöd för XML, t.ex. i form av de fria komponenterna Saxon och Xalan som inubit IS använder sig av internt. Det finns även färdiga klasser som exempelvis dbsql2xml (se http://dbsql2xml.sourceforge.net/) som hade passat perfekt till att exportera informationen i databasen till olika XML-format. Kopplingen till TOPCALL hade kunnat göras med SOAP som i inubit IS. De loggningsfunktioner som finns i inubit IS hade varit lätt att ordna med triggers i PostgreSQL men att skapa en visualisering av dataflödet i databasen hade varit mer tidskrävande. Databasvisualisering är ett område det forskats mycket kring men det finns inga färdiga lösningar som automatiskt skulle kunna skapa något som motsvarar ett arbetsflöde i inubit IS. Med ett bra ritprogram och hårt arbete går det dock att göra minst lika bra diagram för hand. 7.7 Nackdelar med grafisk programmering Utvecklingen av TOPCALLdemo visade på några generella nackdelar med mellanprogram som programmeras grafiskt: Det är oftast långsammare att rita än att skriva kod eftersom det flesta datorer saknar lämpliga inmatningsenheter som digitaliseringsbord. Mycket tid kan gå åt till att placera figurerna snyggt om programmet saknar funktioner för att ordna figurerna automatiskt. Ökad risk för arbetsskador p.g.a. flitigt användande av pekdonet. En erfaren programmerare kan översätta sina tankar till programkod med automatik och måste använda extra kognitiva resurser för att rita i stället. De ord som används i ett programmeringsspråk kan också ses som bilder och fördelarna med att använda en snedställd fyrkant i stället för if (...) är inte självklar. Grafisk programmering kan störa de bilder programmeraren har i huvudet över systemet som helhet, särskilt om det inte går att få bilderna i programmet att bli lika uttrycksfulla som i huvudet. Lätt att bli låst i de abstraktioner som erbjuds, mycket svårare att t.ex. skapa ett eget minispråk för en viss tillämpning inuti det vanliga programmeringsspråket om det är grafiskt. Grafisk programmering passar därför bäst för den som programmerar sällan och saknar längre utbildning i programmering. 20

Litteraturlista BANKS, J., J. CARSON, B. L. NELSON, D. NICOL. (2004). Discrete-Event System Simulation, Fourth Edition. Prentice Hall. ISBN 0131446797. DAMODARAN, S. (2004). B2B integration over the Internet with XML: RosettaNet successes and challenges. Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters, 188 195. KUO, D., A. FEKETE, P. GREENFIELD, J. JANG, D. PALMER. (2003). Just What Could Possibly Go Wrong In B2B Integration? Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC 03), 544. MEDJAHED, B., B. BENATALLAH, A. BOUGUETTAYA, A. H. H. NGU, A. K. ELMAGARMID. (2003). Business-to-business interactions: issues and enabling technologies. The VLDB Journal, Vol. 12, 59 85. PATIL, S., E. NEWCOMER. (2003). ebxml and Web Services. IEEE Internet Computing, Vol. 7, 74 82. SCHOUWENAAR, M., E. MARTIN. (2003). OPTIMIZATION OF A TELECOMMUNICATIONS BILLING SYSTEM. Proceedings of the 35th conference on Winter simulation: driving innovation, 1843 1847. STONEBRAKER, M. (2002). Too Much Middleware. SIGMOD Record, Vol. 31, No. 1, 97. QUIN, L., (2005), The Extensible Stylesheet Language Family (XSL), http://www.w3.org/style/xsl/ 21

Bilagor Bilaga 1: inubit Business Integration Server 4.0 Arbetsflödena i inubit IS erbjuder ett utmärkt sätt att visualisera systemet. Genom att aktivera ett speciellt spårningsläge går det att följa ett visst meddelande grafiskt på skärmen (Figur 13). Delresultaten sparas och kan visas i ett fönster genom att högerklicka på respektive övergång och välja ett alternativ på den popup-meny som då visas. Figur 13 Spårningsläge Grön punkt som rör sig (symboliserar meddelandet) Det går också att köra en slags simulering som t.ex. kan beräkna tidsåtgång för ett flöde genom att sätta tider för varje delprocess (Figur 14). Figur 14 Simulering 22

Alla händelser lagras i en databas och med hjälp av den går det att se exakt vad som hänt när något inte fungerar (Figur 15). Figur 15 Loggning och köhantering Databasen är också utmärkt för att generera statistik, en inbyggd rapportgenerator ger några exempel (Figur 16, exekveringstiderna är vid körning i MS Virtual PC). Figur 16 Rapportgenerator 23

Bilaga 2: Menyer i TOPCALLdemo Processmenyn Processmenyn är ett förenklat sätt att beskriva en automatiserad betalningsprocess där det finns en leverantör, en beställare och en chef som godkänner beställningarna (systemet fungerar som administratör). Nya order skapas genom att klicka på Fyll i order, antingen i menyn till vänster eller i figuren (se pilarna i Figur 17). Figur 17 Ny slumpvis order Vid val av Fyll i order skapas en ny slumpvis order i databasen Seller och beställaren får välja vilken typ av faktura som ska skickas. När beställaren klickar på Skicka order får chefen en meddelande via TOPCALL om att gå in i menyn Godkänn order (Figur 18) och godkänna ordern. Figur 18 Godkänn order 24

När chefen har godkänt ordern skapas en faktura i det format beställaren valde. De resulterande filerna går att nå genom att välja Utfiler i menyraden, fax skickas till det nummer som angetts i statusövergång nr 50 i databasmenyn (Figur 21) men sparas också som PDF. Fakturor i formatet XML (e2b Invoice) läses tillbaka av systemet och skrivs till databasen Buyer så att beställaren och chefen kan attestera fakturan (Figur 19). När både beställare och chef attesterat fakturan anses den betald och detta registreras i databasen Seller. Betalda fakturor går att se genom att välja Betalda fakturor i menyn till vänster eller klicka var som helst i rutan Leverantör (se pilarna i Figur 20). Figur 19 Attestera faktura Figur 20 Betalda fakturor 25

Databasmenyn I databasmenyn går det att se de data som finns i databaserna Seller, Buyer och Sim. Alternativet Meddelanden till Topcall (Figur 21) visar de meddelanden som skickas till TOPCALL vid en viss statusövergång. Figur 21 Meddelanden till TOPCALL Numren längst till vänster i listan motsvarar de numrerade statusövergångarna i figuren. Statusövergång nr 50 är inte utsatt i figuren men innebär att en faktura ska skickas som fax (om service ändras till SMTP får mottagaren ett e-postmeddelande med fakturan bifogad som tiffbild). Varje statusövergång kan ha flera olika meddelanden och enskilda poster i listan kan ändras genom att klicka på dem (Figur 22). Statusövergång Figur 22 Ändra meddelande till TOPCALL 26