PL/SQL till Java Konvertering med verktyg PL/SQL to Java Conversion with tools

Transkript

1 PL/SQL till Java Konvertering med verktyg PL/SQL to Java Conversion with tools Fredrik Sköld Martini Philip Axell EXAMENSARBETE 2011 DATATEKNIK Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan (vx) Jönköping

2 Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom ämnesområdet Datateknik. Arbetet är ett led i den treåriga högskoleingenjörsutbildningen. Författarna svarar själva för framförda åsikter, slutsatser och resultat. Examinator: Inger Palmgren Handledare: Christer Thörn Omfattning: 15 hp (grundnivå) Datum: Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan (vx) Jönköping

3 Abstract Abstract This report is about an assignment gotten from the company Logica as a final thesis at the Computer Engineering education at Jönköping University. The assignment was supposed to investigate whether it is possible to convert a system written in the programming language PL/SQL to Java. The application in question was a sales ledger. The aim of the project was to make it possible for the company to at a low cost in time and money migrate the existing system. Some of the questions are examining whether it is possible to do this with the help of conversion tools and if so, are there any Bestpractices. We have investigated this through seeking information about different conversion tools and the different programming languages. To verify the functionality of the different tools we ran a number of different tests with actual conversion. These tests have shown that a conversion between PL/SQL and Java can work, however under strict standardized forms. The system we have been assigned to do not fall under these forms and it lost all of its functionality under the process of conversion in one case and the result code was close to useless. We came to the conclusion that a conversion with tools was not profitable in this case. 1

4 Sammanfattning Sammanfattning Den här rapporten hanterar ett uppdrag från företaget Logica gjort som ett examensarbete på utbildningen Högskoleingenjör inom Datateknik, programmet Webbutveckling/Programmering och datanät, på Tekniska Högskolan i Jönköping. Uppdraget gick ut på att kontrollera om ett system skrivet i programmeringsspråket PL/SQL går att konvertera till Java. Programmet i fråga var ett reskontrasystem. Syftet med projektet var att företaget skulle kunna konvertera deras system på ett så kostnadseffektivt och tidsbesparande sätt som möjligt. Frågor som rapporten har tagit upp är huruvida det finns konverteringsverktyg som kan göra detta och om i så fall det finns några Best-practises angående detta. Vi har undersökt detta genom informationssökning om olika verktyg samt om de båda språken. För att verifiera de olika verktygens funktionalitet har ett antal olika tester med konvertering utförts. De tester som har genomförts visar på att en konvertering mellan PL/SQL och Java kan fungera, men då under standardiserade former. Till denna kategori hörde dock inte Logicas applikation, som förlorade all sin funktionalitet under processen i ett av testen och genereringen av användbar kod var minimal. Vi kom fram till att i det här fallet var en konvertering ej möjlig att rättfärdiga i ett kostnadsperspektiv. Nyckelord Konvertering Undersökning PL/SQL Java Databas Applikations Server 2

5 Innehållsförteckning Innehållsförteckning 1 Inledning PROBLEMBESKRIVNING SYFTE MED PROJEKT FRÅGESTÄLLNINGAR AVGRÄNSNINGAR METOD DISPOSITION Teoretisk bakgrund SPRÅKTYPER Procedurbaserade Språk Objektorienterade språk DATABAS SQL Exempel på SQL-query Oracle Database PL/SQL Oracle Application Server JAVA Historia Grunderna Java Runtime Environment (JRE) Servlets Tomcat KONVERTERINGSVERKTYG SwisSQL sqlways Orindabuild Exodus - PL/SQL to Java conversion tool Utvärdering av konverteringsverktyg Genomförande TEORETISK FÖRSTUDIE Informationssökning PRAKTISKT FÖRBEREDANDE Installation av testmiljö Redigering av existerande kod Konstruering av testprojekt KONVERTERINGSVERKTYG SwisSQL - Oracle to Java Exodus - PL/SQL to Java conversion tool Resultat SWISSQL - ORACLE TO JAVA SwisSQL beslutar att lägga ner Oracle to Java-verktyget EXODUS - PL/SQL TO JAVA CONVERSION TOOL Diskussion och slutsatser RESULTATDISKUSSION SLUTSATSER OCH REKOMMENDATIONER

6 Innehållsförteckning 6 Referenser Bilagor

7 Innehållsförteckning Figurförteckning FIGUR 1 - ENKELT EXEMPEL PÅ PL/SQL-KOD 9 FIGUR 2 - ENKEL JAVA-KOD MED TVÅ KLASSER 10 FIGUR 3 - EXEMPEL PÅ HUR TABELLER I EN DATABAS KAN VARA RELATERADE. 11 FIGUR 4 - EXEMPEL PÅ EN SQL-QUERY 12 FIGUR 5 - ÖVERBLICK AV EN ORACLE DATABAS VISAD I SQLDEVELOPER 13 FIGUR 6 - ÖVERBLICK AV PL/SQL PLACERAD I OLIKA PAKET I EN ORACLE- DATABAS, SAMT VISS KOD. 14 FIGUR 7 - FIGUR ÖVER ORACLE APPLICATION SERVER KOPPLING TILL DATABASEN 15 FIGUR 8 - ENKEL FÖRKLARING TILL HUR EN SERVLET FUNGERAR MOT DATABAS 16 FIGUR 9 - EN APPLIKATIONSSERVER FÖR JAVA UPPKOPPLAD MOT DATABAS 17 FIGUR 10 - FIGUR ÖVER VAD KONVERTERINGSVERKTYGEN SKALL KLARA AV. 18 FIGUR 11 - TABELL ÖVER KONVERTERINGSVERKTYG OCH DESS TILLVERKARE 18 FIGUR 12 - EN SCREENSHOT ÖVER HUR SWISSQL SER UT [15] 19 FIGUR 13 - EN SCREENSHOT PÅ CIPHERSOFTS EXODUS UNDER ANVÄNDNING [20] 20 FIGUR 14 - ÖVERBLICK AV TESTMILJÖN, MED APPLIKATIONER. 24 FIGUR 15 - INLOGGNINGSVY I VÅRT TESTPROJEKT I JAVA. 25 FIGUR 16 - PROJEKTLEDARVISNING I VÅRT TESTPROJEKT I JAVA 26 FIGUR 17 - BILD FRÅN SWISSQLS HEMSIDA FÖR DERAS ORACLE TO JAVA TOOL. [23] 30 5

8 Teoretisk bakgrund 1 Inledning Det här examensarbetet är gjort som slutlig uppgift på utbildningen Högskoleingenjör inom Datateknik, programmet Webbutveckling/Programmering och datanät, på Tekniska Högskolan i Jönköping. Examensarbetets uppgift har varit ett undersöka huruvida det är möjligt och om det är ekonomiskt fördelaktigt att med hjälp av olika verktyg konvertera koden i ett existerande system skrivet i programmeringsspråket PL/SQL och göra om funktionaliteten till att istället vara skriven i Java. Under utbildningens gång har vi läst omfattande kurser i objektorienterad programmering, så som C# och C++. Vi har även läst kurser i databashantering och SQL, projektledning och webbdesign. Alla dessa har hjälpt oss att genomföra projektet. Då vi inte tidigare har haft någon djupare kunskap om varken konvertering, PL/SQL eller JAVA var vi tvungna att skaffa oss detta på egen hand. Uppdragsgivaren är Logica Sverige AB, under kontoret i Jönköping. Logica är ett IT-tjänstföretag som erbjuder verksamhetsinriktade konsulttjänster, systemintegration och outsourcing till kunderna. De har ca anställda, varav 5200 finns i Sverige. [1] 1.1 Problembeskrivning Logica har hos flera stora kunder ett reskontrasystem vid namn EKO, som använder en Oracle-databas för lagring av bland annat information. De funktioner som systemet har är konstruerade med hjälp av PL/SQL som fungerar som ett logiskt programmeringsspråk, med procedurerna och funktionerna lagrade direkt i databasen. PL/SQLen ligger i olika så kallade paket i databasen och man kan sedan kalla på dessa i webbläsaren om man har installerat och konfigurerat en applikationsserver med webbserver-funktionalitet. Det grafiska gränssnittet är sedan genererat med hjälp av webbservern i HTML-kod, systemet använder även Java-script och CSS-mallar för presentationen. Logica har planer på att konvertera systemet till Java för att slippa använda Oracle som databas och applikationsserver, då dess licenser är dyra och man vill kunna leverera ett billigare och mer flexibelt system åt kunderna. De vill komma ifrån att lagra funktionaliteten i databasen och kan då istället med Java hämta information från i stort sett valfri databas och presentera den. Detta skulle kunna möjliggöra för kunden att i princip bestämma själv vilka produkter denne vill ha och kan därmed också reglera licenskostnaderna efter funktionalitet och antal användare. Man vill alltså komma ifrån PL/SQL, vilket är konstruerat av Oracle, för att på detta sätt undvika att man blir låst till deras produkter. 1.2 Syfte med projekt Vår uppgift i det här projektet har varit att leta upp och undersöka vilka vägar man kan gå och vilka som är mest effektiva i tid och kostnad för att konvertera det existerande systemet hos Logica till ett med samma funktionalitet fast istället byggt med hjälp av Java. Vår uppgift var att hitta en kostnads- och tidseffektiv lösning till konverteringsproblemet som de sedan kan använda till att utföra arbetet om det visar sig vara möjligt. 6

9 Teoretisk bakgrund Vi har koncentrerat oss på de delar av det existerande systemet som är mest fundamentala och de där det är störst chans att det uppstår problem. Tanken var att det skall gå åt så lite tid som möjligt till att faktiskt skriva Java-kod och istället i så stor utsträckning som möjligt använda de olika konverteringsverktyg som existerar för konvertering mellan PL/SQL och Java. Då dessa verktyg stödjer olika funktioner och datatyper sinsemellan har vi även sett över vilket som faktiskt passar bäst till just det här fallet. 1.3 Frågeställningar En del frågeställningar har påverkat projektets utgång, en av de viktigaste var vilka verktyg finns det för konvertering mellan PL/SQL och Java och vilka passar in på just det här systemet. En annan fråga var huruvida vilket konverteringsverktyg var bäst i aspekterna: Hur mycket funktionalitet som försvinner vid konverteringen. Vilket som kräver minst för och efterarbete. Hur kostnadseffektivt verktyget är. Ännu en frågeställning har varit huruvida liknande projekt har utförts tidigare och hur deras utfall blivit, vilka metoder som använts och vad som anses vara Best-practices i just konverteringen från PL/SQL till Java. 1.4 Avgränsningar Uppgiften innefattar att hitta olika Best-practices angående konvertering i större utsträckning än att utforska själva vilka vägar som är enklast att gå. Vi har tillsammans med företaget valt två delar av systemet, där en av dem behandlar inloggning och den andra en av de olika formulärsidorna, projektledarredigeringen. Vi valde dessa då de anses innehålla en stor del av den funktionalitet som återfinns även i andra delar av systemet och eventuella problem som skulle kunna dyka upp kommer förmodligen att visa sig här. 1.5 Metod För att lyckas med det här projektet har vi sökt en stor del information om olika tekniker, programmeringsspråk och verktyg. De programmeringsspråk som projektet vidrört hade vi inte någon tidigare erfarenhet av och vi behövde därför söka kunskapen på egen hand genom att hitta lämplig litteratur samt även praktisera ett antal mindre programmeringsprojekt. För att hitta den information vi behöver har vi till största del användt relevant litteratur och gjort informationssökning på internet via sökmotorer så som exempelvis Google. En stor del av informationen har vi även funnit med hjälp av Jönköping Högskolas biblioteksdatabas, där böcker och artiklar rörande ämnet finns. Vi har även haft regelbunden kontakt med Logica för att stämma av olika steg i projektets gång och vi har då även tagit hjälp av dem om det funnits hinder eller funderingar. 7

10 1.6 Disposition Teoretisk bakgrund Den här rapporten följer Tekniska högskolan i Jönköpings mall för examensarbeten och dess kapitel finns beskrivna nedan. I teoretisk bakgrund tar rapporten upp en del av den teori och uttryck som läsaren kan behöva för att förstå och följa med i resterande delar av rapporten, vi förklarar även hur olika verktyg och applikationer fungerar. I Genomförande tar vi upp hur projektet genomfördes och vad som gjordes för att komma fram till resultatet, vilka val vi gjort och varför. Resultatkapitlet tar upp det resultat som uppnåddes i projektet, även de eventuella problem som upptäcktes på vägen. Under kapitlet Diskussion och Slutsatser tar vi upp diskussion angående det resultat projektet har gett. Det kommer även ta upp personliga slutsatser om projektet och vilka förhållanden som kunde ha givit en annan utgång. 8

11 Teoretisk bakgrund 2 Teoretisk bakgrund Det här kapitlet går igenom olika tekniker och dess grunder som behövs för att förstå hur det existerande systemet fungerar samt varför företaget vill gå ifrån den nuvarande uppbyggnaden. Vi behandlar här olika typer av programmeringsspråk, hur dessa är uppbyggda och fungerar, och kopplar dessa till de språk som det här projektet vidrör. Kapitlet går även igenom information som kan behövas för att få förståelse om varför vi har utfört vissa moment och dess resutlat. Det här kapitlet kommer även att förklara hur en databas är uppbyggd och hur PL/SQL fungerar tillsammans med en sådan. Kapitlet hanterar även grundläggande information om de konverteringsverktyg som senare används i genomförandet. Vi har under skrivandet av det här kapitlet utgått från att läsaren har en grundläggande kunskap om datorer, servrar och programmering och kommer därför inte gå in på djupet exempelvis i hur en dator hanterar programkod. 2.1 Språktyper Procedurbaserade språk Dessa språk låter programmeraren definiera olika procedurer och funktioner som körs i ordning. Ordningen är oftast uppifrån och ner och programmet avslutar när pekaren har gått till slutet av en fil. Exempel på sådana språk är: PL/SQL, C, Visual Basic, Perl, Ada. Procedurer och funktioner måste deklareras för att koden skall kunna kalla på dessa från andra delar av programmet. När man sedan kallar på en funktion eller procedur flyttas pekaren till denna för att sedan genomföra dess funktion. Efter det att funktionen är genomförd så flyttas pekaren tillbaka där den var innan proceduren eller funktionen kallades på för att sedan fortsätta nedåt. [2] Exemplet i Figur 1 visar hur man enkelt skriver ut ett meddelande med hjälp av PL/SQL. Man börjar med att deklarera variablerna för att sedan starta själva funktionen. Pekaren går nedåt tills dess att den pekar på END då den är klar med funktionen. DECLARE meddelande varchar(100); --Deklarerar en textsträng som heter meddelande BEGIN meddelande := Hejsan Världen, Detta är PL/SQL! ; --meddelande får värde dbms_output.put_line(meddelande); --Skriver ut meddelandet END; Objektorienterade språk Figur 1 Enkelt exempel på PL/SQL-kod Objektorienterade språk är baserade på objekt som är strukturer som har olika attribut och rutiner som kallas metoder. Dessa metoder bestämmer vad objektet kan göra och hur det beter sig, detta gör att det enkelt går att programmera ett objekt som kan återanvändas. Exempel på sådana språk är: C++, Objective-C och Java. 9

12 Teoretisk bakgrund Man skapar klasser som är en definition av vad ett objekt innehåller och kan göra, dessa klasser kan sedan inkluderas i ett valfritt projekt, så länge man har tillgång till filerna. Att använda klasser förenklar programmeringen exempelvis genom att man slipper programmera samma funktion varje gång man skall använda denna, man placerar då funktionen i klassen. Man kan då istället med objektets hjälp kalla på dess medlemsfunktioner och använda dem utan att behöva skriva om dem. Det som gör objektorientering starkt är arv och polyformism, detta betyder att man exempelvis kan skapa en hierarki med klasser där subklasserna ärver funktioner och attribut av basklassen, man kan sedan skriva över dessa längre ner i hierarkin vilket gör att de fungerar annorlunda för objekt som tillhör de lägre klasserna. I Figur 2 finns ett exempel på enkel klassuppbyggnad i Java. [2] class Hejsan{ private String _meddelande; //Deklareraren text sträng //skapar en konstruktor som skapar objektet, denna sätter även värdet på //_meddelande public Hejsan(String meddelande){ _meddelande = meddelande; } //skapar en funktion i klassen som skriver ut _meddelande public void domeddelande(){ System.out.println(_meddelande); } } class HejsanProgram{ public static void main(){ //skapar objectet med en text som input, kallar sedan på domeddelande //funktionen Hejsan hej = Hejsan( Hejsan, detta är ett Java objekt ); hej.domeddelande(); } } Figur 2 Enkel Java-kod med två klasser 10

13 Teoretisk bakgrund 2.2 Databaser Det system som företaget har för nuvarande är uppbyggt på en Oracle-databas. En enkel förklaring av en databas är att den kan samla och organiserar en stor mängd information. Det som är speciellt med den är att all information är uppdelad över olika tabeller, de data som hör ihop finns i samma tabell. En tabell kan ses som ett vanligt Excel-ark fast det har ett bestämt antal kolumner. Exempelvis kan det finnas en tabell som kallas Användare, då finns det ofta en första kolumn som heter Användar-ID och minst en kolumn till som innehåller information om den användare som har detta ID, exempelvis namnet på personen. Det finns rader (rows, tuples) med kolumner där alla kolumner som finns på denna rad hör ihop, detta är vad som definierar en relationsdatabas. Den riktiga översättningen av tabell, och även synonymen på engelska, är Relation, därav namnet. Innan den första definitionen av en relationsdatabasen kom (1970) var de databaser som fanns uppbyggda på ett sådant sätt att man endast kunde svara på ett litet antal frågor, så som exempelvis endast vilka butiker en leverantör skulle skicka varor till.[3] Det finns alltid en kolumn som skall vara unik, alltså innehålla ett unikt värde som ingen annan rad har i den specifika kolumnen. Denna kolumn kallas för nyckel, key, och kan även kombineras med andra kolumner för att få fram en ännu starkare nyckel. Alla kolumner kan man även specificera vilken typ av data den skall innehålla, alltså om det skall vara exempelvis ett tal, datum eller en text. [3] Databasens tabeller kan ofta, beroende på tillverkare, kopplas ihop med varandra, de tidigaste databaserna som utvecklades hade inte den här möjligheten. I exemplet i Figur 3 finns det en tabell med användare och en tabell med olika bilar, man då med hjälp av en relation definiera vilka användare som äger vilka bilar och vise versa vilka bilar som ägs av vilka användare. [3] Anvandare Bilar PK Anvandare_ID 0- PK Bil_ID Anvandare_Namn FK1 Bil_Modell Anvandare_ID SQL Figur 3 -- Exempel på hur tabeller i en databas kan vara relaterade. SQL, Simple Query Language, används för att kommunicera och integrera med en databas genom att skriva så kallade querys till databasen. SQL började med en rapport publicerad av E.F.Codd, vilken han skrev medan han arbetade på IBM s forskningslaboratorium i San José Några år senare 1974 definierade D.Vhamberlin ett språk som kallades Structured English Query Language (SEQUEL), som senare skulle bli SQL. [6] En query (fråga) är uppdelad i olika kommandon som beskriver vad som skall göras eller hämtas. Man kan till exempel välja att hämta all information från en viss tabell med en 11

14 Teoretisk bakgrund SQL-fråga där en viss kolumn stämmer överens med ett krav i frågan. Med hjälp av SQL kan man bland annat uppdatera information och även ta bort rader i olika tabeller. Det går också att skapa, ta bort och uppdatera tabeller med hjälp av en SQL-fråga. SQLfrågorna kan spara som stored procedures i databasen för att kallas på direkt från ett anrop, istället för att man skriver frågan exempelvis i programkoden. Stored procedure innebär att frågan sparas som ett script placerat i databasen. Nuförtiden går det att med hjälp av exempelvis PL/SQL att utveckla hela program uppbyggda på SQL. [6] Exempel på SQL-query SELECT kolumn_for_namn, kolumn_efter_namn FROM tabell_anstallda WHERE kolumn_for_namn = David Figur 4 - Exempel på en SQL-query Queryn i Figur 4 kommer att hämta information från tabellen tabell_anstallda och visa kolumnerna kolumn_for_namn och kolumn_efter_namn och dess värden. De rader som kommer att visas är de som stämmer överens med WHERE -kommandot, som i det här fallet skall kontrollera ifall det finns något värde i kolumnen kolumn_for_namn som stämmer överens med David. Den text som i figuren står i början av varje rad är några av de standardkommandon som finns definierade i SQL, några fler av dessa är: UPDATE, DELETE FROM, INSERT, GROUP BY och HAVING. Alla dessa har olika innebörd och man använder dem på olika sätt för att exempelvis göra uträkningar, uppdatera information eller gruppera rader med liknande information. [6] Oracle Database Oracles databas är uppbyggd som en objektorienterad relationsdatabas. Den första versionen började utvecklas år 1977, då av skaparen Larry Ellison tillsammans med sina vänner Bob Miner och Ed Oates. De hade insett att behovet av en databas med möjligheten att ha relationer mellan olika tabeller var stort. Oracles databas är konstruerad som sådan att allt innehåll i databasen delas upp i olika filer på hårddisken och alla tabeller får varsitt table-space, alltså ett förutbestämt utrymme där tabellerna kan växa på servern. [3][4] Hierarkin i en Oracle-databas är uppbyggd på olika användare, som vardera kan ha exempelvis tabeller, PL/SQL-paket och procedurer. Man kan sedan tilldela de olika databasanvändarna rättigheter och restriktioner, vilket bidrar till att man kan dela administrationen mellan ett stort antal personer. Beroende på hur administratören konfigurerar databasservern kan man exempelvis koppla upp sig mot denna så länge man har en klient installerad på den aktuella datorn. Klienten installerar en listener på datorn som används för att koppla upp sig mot databasen. Man kan således med hjälp av detta komma åt databasen från i stort sett vilken dator som helst vilket underlättar interaktion på distans. I Figur 5 finns en vy över databasens uppbyggnad för Oracle visad i SQLDeveloper. [3][4] 12

15 Teoretisk bakgrund PL/SQL Figur 5 - Överblick av en Oracle databas visad i SQLDeveloper I den här rapporten hanteras en stor del PL/SQL (Procedural Language /SQL) som är det programmeringsspråk Oracle har tagit fram för att bygga ut SQL och som Logica använder i deras reskontrasystem. Tidigare har SQL enbart varit ett simpelt sätt att kommunicera mot en databas. Det har dock sedan SQL lanserades utvecklats olika språk för att kunna inkludera logik i den kod som representerar SQL:en. PL/SQL är ett sådant. Språket är ett blockbaserat programmeringsspråk som innehåller funktioner och procedurer. Blockbaserat innebär att det finns olika stora kodstycken, men att blocken alltid kompileras separat, som ett procedurbaserat språk. Tidigare i det här kapitlet finns en förklaring av procedurbaserade språk.[6][7][8] PL/SQL kan skrivas direkt i en kompilator som kalla SQL*Plus och då kör man dess funktioner direkt på datorn, men man kan även skriva och köra koden i så kallade scriptfiler som har filändelsen.sql. Dessa kan köras från SQL*Plus men kan även placeras i databasen som stored procedures, det är på detta sätt som Logica använder sin PL/SQLkod. Detta underlättar för applikationsservern, som är uppkopplad mot databasen, att lätt komma åt dem och bearbeta deras information. Man kan lägga dessa under ett antal kategorier i databasen vid namn Procedures, Functions och även i större sammanhang som olika Packages. I Figur 6 finns en överblick på hur dessa kan vara placerade i en databas. [6][7][8] 13

16 Teoretisk bakgrund Figur 6 -- Överblick av PL/SQL placerad i olika paket i en Oracle-databas, samt viss kod. Varje Package, från och med nu omnämnt som paket, fungerar som en header-fil där alla procedurer och funktioner deklareras och sedan finns det möjlighet till en body där man implementerar funktionaliteten. Dessa funktioner och procedurer liknar högnivåspråk där man kan implementera dessa till att exempelvis hämta, bearbeta eller radera data, men man också skapa funktioner och procedurer som utför beräkningar och liknande. Det finns tillgång till olika standardklasser som hanterar kopplingen till systemet och man kan med hjälp av dessa exempelvis hämta datum och liknande information. Skillnaden mellan procedur och funktion är att en funktion alltid returnerar ett värde medans en procedur inte måste göra detta. Man använder därför procedurer när det inte krävs ett returnerat värde. [6][7][8] Oracle Application Server En applikationsserver används för att bidra med en miljö där ett program oberoende av funktion skall kunna köras. PL/SQL delen av det här projektet utnyttjar Oracle Application Server för att hantera den PL/SQL kod som databasen innerhåller. Oracle Application Server, som då stödjer PL/SQL efter viss konfiguration, användes för att kalla på och ta emot data från PL/SQL funktioner i Oracle Databasen. För att projektets sida skall kunna visas så skickas först en förfrågan från användaren till applikationsservern, därefter kallar denna på en PL/SQL procedur i databasen som i sin tur returnerar den data som proceduren genererar. Efter det att applikationsservern mottagit informationen så bearbetar denna det och skickar vidare till användaren. I Figur 7 visas en enkel överblick av kopplingen mellan applikationsserver och databas.[5] 14

17 Teoretisk bakgrund arbetare.hittaarbetare Kallar procedur Oracle AppServer Oracle Database Go Använder hemsida Arbetare: David Svensson Klicka Förfrågar sida Skickar Sida Returnerar HTML data Arbetare: David Svensson Figur 7 - Figur över Oracle Application server koppling till databasen 2.3 JAVA Historia Java är baserat på språket C++ och skapades av Sun Microsystems med ett projekt lett av James Gosling år James kallade först språket för Oak men då detta redan var upptaget så föreslogs namnet Java hos en lokal kaffeförsäljare, som en referens till kaffesorten. Företaget hade planerat att konsumentmarknaden inom datorer skulle växa mer än vad den gjorde under den här tidsperioden och projektet hotades snart att läggas ner. Men tack vare den kraftiga utvecklingen av internet (World Wide Web) 1993, lyckades Javas interaktiva hemsidor att få upp projektet på fötter igen. Sun tillkännagav Java på en presskonferens 1995 som tack vare den utvecklade interaktionen med internet blev en succé. [9][10] Java används numera för att programmera allt ifrån storskalade applikationer till program för mobiltelefoner. Java utvecklas kontinuerligt med hjälp av JCP ( Java Community Process ), en styrelse som i samarbete med Java-communityn väljer vilka steg och i vilken riktning språket skall gå. Den samling som styr JCP består av flera stora och ledande företag inom branschen, men även mindre aktörer och även ner på användarnivå. Sun Microsystems har nu blivit uppköpta av Oracle, men Java står fortfarande kvar som opensource och JCP finns ännu kvar.[9][10] Grunderna Java är som tidigare nämnt baserat på C++ och är därmed ett objektorienterat programmeringsspråk, självklart med vissa skillnader mot C++ och det skall ha en enklare modell av objektorienteringen. Tanken med Java är att allting skall skapas i klasser, dessa ska vara så enkla som möjligt för andra utvecklare att använda till sena egna projekt, alltså dess funktioner skall vara anpassningsbara för andra tillämpningar än de egna. Dessa klasser innehåller olika metoder som returnerar och behandlar olika värden och objekt. Många av dessa klasser laddas upp till Java class library där det ska vara enkelt för utvecklare att komma åt dem. [9] 15

18 Teoretisk bakgrund En stor del med att lära sig Java innebär att kunna hantera dessa klasser och implementera dem till sina egna projekt, samtidigt som man måste ha god kunskap om hur syntaxen är upplagd för att kunna göra just detta och även konstruera egna klasser. Java är också konstruerat så att det ska kunna köras på så många olika sorters system som möjligt genom att installera en säker körmiljö på de maskiner som skall kunna exekvera Java-program, en så kallad Java Runtime Environment (JRE). [9] Java Runtime Environment (JRE) Det är JRE:n som används för vanliga användare som vill kunna köra olika Javaapplikationer och applets på sin dator. Denna miljö innehåller bland annat en JVM (Java Virtual Machine) som då är en virtuell miljö vilket gör att språket blir möjligt att köra på alla system. Den innehåller även grundläggande klasserna samt bibliotek. En Java Virtual Machine är som det låter en virtuell maskin som installeras på systemet i fråga och agerar då som en fullt fungerande dator med operativsystem inuti ditt egna system. [9][11] Ett vanligt programmeringsspråk fungerar oftast så att man programmerar för ett speciellt system, med dess specifikationer och egenskaper. Den kod som då skrivs översetts sedan till maskinkod och sedan exekverar kompilatorn denne gentemot systemet. Java använder istället så kallad bytecode. Programmering med Java innebär att man sparar sin kod i ett dokument med ändelsen.java, när man sedan kör kompilatorn hämtar den sedan dessa och sparar dem som bytecode i en.class-fil. JVM:en hämtar sedan in denna bytecode och kör den då gentemot operativsystemet på som maskinkod. Det är alltså JVM:en som gör det möjligt för Java-kod att fungera på flera olika system utan att man behöver programmera för just dessa. För att kunna utveckla Java-applikationer behöver man däremot Java Developement Kit (JDK) installerat på systemet som innehåller bland annat en kompilator, för att kunna köra koden. JRE:n och JDK:n innehåller dock till viss del samma komponenter. [9][11] Servlets Servlets kan beskrivas som en server applikation utan något interface. Dessa är till för att hantera den data som en webbapplikation skickar in och begär ut. Dessa kan vara mycket viktiga då de ger många smidiga möjligheter för webb-applikationer. Figur 8 nedan visar en enkel inloggnings applikation. I den här skriver du in användare och lösenord för att sedan skicka vidare detta till en servlet som jämför detta mot en databas. [13] Användare Lösenord Logga In Java Webb-App Login Servlet Databas Figur 8 - Enkel förklaring till hur en servlet fungerar mot databas 16

19 Teoretisk bakgrund Tomcat Apache Tomcat är en applikationsserver för Java servlets och Java server pages (.jsp). Tomcat är en opensourceprodukt, vilket betyder att all källkod är öppen för allmänheten och man kan på så sätt bygga en egen produkt för att sedan lansera. Dock krävs det att man har tillstånd av Apache Software Foundation (ASF) för att kunna lansera denne med en referens om att den innehåller kod från Tomcat. I och med att den är opensource är den också licensfri för användning, även i produktionsmiljö. [14] Tomcat utvecklades från början från Apaches Webserver, just för att kunna hantera Java, som då inte hade någon riktig representant i stabila webbservrar. En applikationsserver behövs för att kunna implementera Java funktionalitet på en webbplats, utan en server som hanterar olika funktioner och kod kan man inte generera en sida som är interaktiv. I Figur 9 nedan visas hur Tomcat hanterar en applikations SQL-sats för att hämta information. Applikationsservern hanterar de olika momenten som användaren på webbplatsen gör och kopplar dessa samman med rätt funktion och navigering. I Tomcat går det med hjälp av olika.xml-filer att bestämma vilka url:er som skall leda vart (till vilka servelts, jsp osv.), det går att ha flera olika applikationer i samma server, vilket kräver att man skall kunna navigera mellan dessa. [14] SELECT kolumn_for_namn, kolumn_efter_namn FROM tabell_anstallda WHERE kolumn_for_namn = David Skickar In SQL Sats Go TomCat Server Oracle Database Använder hemsida Arbetare: David Svensson Klicka Förfrågar sida Skickar Sida Returnerar Data David Svensson Figur 9 - En applikationsserver för Java uppkopplad mot databas 2.4 KONVERTERINGSVERKTYG Det här projektet är utfört efter inställningen att en ny version av det existerande systemet inte skall behövas programmeras från grunden i Java, utan att man med hjälp av konverteringsverktyg skall kunna spendera så lite tid som möjligt åt att överföra funktionaliteten till Java istället. Ett konverteringsverktyg används för att på ett så smidigt och enkelt sätt som möjligt omvandla från en typ till en annan. Det finns konverteringverktyg för exempelvis datatyper i olika databaser, det finns konverteringsverktyg för att flytta faktisk data mellan databaser av olika tillverkare och arkitektur. Det finns även konverteringverktyg som gör om kod och syntax i ett programmeringsspråk till ett annat. 17

20 Teoretisk bakgrund Tanken med den här typen av verktyg är att man skall slippa bygga om ett system från början när man exempelvis vill byta det programmeringsspråk applikationen är byggt på. Eller om man endast vill flytta existerande tabeller och data mellan två olika databaser. Skäl för att göra detta kan till exempel vara att man vill kunna implementera nya funktioner i systemet som det aktuella programmeringsspråket inte stöder, eller att man vill kunna komma ifrån licenser och kostnader för både kund och egen vinning. För att godkännas som ett gångbart konverteringsverktyg i det här specifika projektet bör det klara av de steg som finns i Figur 10 nedan. Oracle Java Gränssnittet Gränssnitt (HTML) Funktionalliteten Automatisk Migration Funktionalliteten (Servlets/Beens) Dataåtkomst Dataåtkomst Databas Databas (Oracle eller annat) Figur 10 - Figur över vad konverteringsverktygen skall klara av. De verktyg som omnämns i den här rapporten har rapportskrivarna med hjälp av företaget letat fram genom att göra sökningar på webben, samt genom att leta efter artiklar berörande liknande projekt. De som initialt hittades beskrivs i kommande stycke, men på grund av djupare efterforskning har några av dem uteslutits som kandidater för just det här projektet. I det här specifika projektet har vi använt konverteringsverktyg för att konvertera kod mellan PL/SQL och Java. Namn Tillverkare Exodus - PL/SQL to Java conversion tool Ciphersoft SwisSQL - Oracle to Java Orindabuild sqlways SwisSQL Orindasoft Ispirer Figur 11 - Tabell över konverteringsverktyg och dess tillverkare 18

21 Teoretisk bakgrund SwisSQL SwisSQL är en produkt som levererar flera olika konverteringsmöjligheter, bland dessa: migrering av data och stored procedures från SQL Server till en Oracle databas med PL/SQL procedures istället. SwisSQLs konverteringsverktyg för PL/SQL till Java är en applikation som skall ta existerande PL/SQL kod, som finns sparad i en Oracle databas, och konvertera denna till Java-kod, uppbyggd med servlets, klasser och beans. På så sätt skall den ersätta funktionaliteten i PL/SQLen men undvika att spara de nya filerna i databasen och då komma till ett mer standardiserat sätt att erbjuda en webbtjänst eller applikation. [16][17] Produkten skall göra om den existerande koden från att vara placerad i databasen som stored procedures till att i Javan använda JDBC för att koppla upp mot databasen och köras som en fristående applikation. Verktyget skall enligt produktbeskrivningen stödja flera olika sorters programmeringsuppbyggnader i PL/SQL, samt även stödja funktionalitet som erhålls från olika standard paket i den existerande koden.[16][17] En bild på SwisSQLs interface finns i Figur 12. Figur 12 - En screenshot över hur SwisSQL ser ut [15] En lista över olika funktioner som SwisSQL säger sig inneha: Migrera PL/SQL-stored procedures till Java-kod. Stödjer nästan alla PL/SQL-strukturer. Stödjer PL/SQL- paket, procedures och funktioner. Den kompletta listan med SwisSQL:s funktionalitet hämtad från deras hemsida finns i bilaga 1 till den här rapporten.[16][17] 19

22 Teoretisk bakgrund sqlways SqlWays är ett verktyg utvecklat av Ispirer för att migrera data och procedurer mellan olika databaser. Om det finns SQL-statements i Java kod kan detta verktyg även konvertera dessa till ett passande format för destinationsdatabasen. sqlways används alltså för att flytta data mellan databaser av olika slag och fabrikat. Det gör i själva verket alltså ingen konvertering av funktionell kod, vilket gör verktyget ej användbart för det här projektet. [18] Orindabuild Ett verktyg som faktiskt inte konverterar varken data eller kod som vi först trodde, men är ett plug-in för exempelvis Eclipse. Det är utvecklat av Orindasoft. Det här verktyget är till för att integrera Java-kod med PL/SQL, för att exempelvis skapa en funktion som skall koppla till en viss databas istället för att använda den enda databas som PL/SQL stödjer, vilken är Oracles. Det här verktyget faller alltså också bort från listan av gångbara alternativ för konverteringen.[19] Exodus - PL/SQL to Java conversion tool Ciphersoft är ett företag som har en produkt kallad Exodus, Exodus har i sin tur ett verktyg som skall konvertera PL/SQL-kod till Java och även kunna anpassa denna till att fungera med en webbtjänst, en bild av programmet finns i Figur 13. Verktyget skall plocka ut PL/SQLens paket och procedurer konvertera dessa till Java, och om man så väljer spara dem återigen i databasen för användning på samma sätt. [21][22] Figur 13 - En screenshot på Ciphersofts Exodus under användning [20] 20

23 Teoretisk bakgrund Verktyget skall stödja funktioner som Oracle Menus, triggers och stored procedures. Ciphersoft har en lista med kriterier som anvisar hur det existerande systemet måste se ut för att kunna konverteras med full funktionalitet, denna lista bifogas som bilaga 2. Exodus är ett alternativ som passar in på det här projektets behov. En del av de saker som Exodus skall klara av att omvandla är följande: [21][22] Oracle Forms Detta används som interface mot en Oracle databas och kan modifieras efter de krav man vill ha. Triggers Triggers används för att genomföra någon typ utav funktion då kraven för triggern blir uppfylt. Tillexempel lägga till en ny rad i en tabell. Stored Procedures Detta är procedurer som är lagrade i databasen istället för tillexempel separata filer Utvärdering av konverteringsverktyg Efter en närmare undersökning som nämnts tidigare visade det sig att inte alla verktyg lämpade sig för det här specifika projektet. De som bör klara av att konvertera PL/SQL-kod till Java är: Ciphersofts Exodus SwisSQLs Oracle to Java I det kommande avsnittet har vi testat de olika verktygen och utvärderat deras funktionalitet. 21

24 3 Genomförande Genomförande Det första som ägde rum i projektets gång var ett möte mellan oss och Logica där vi gick igenom vad examensarbetet skulle behandla och på vilket sätt de ville att vi skulle arbeta. Efter det initiala mötet hos företaget påbörjades en lång period med installation och konfigurering av en fungerande testmiljö som skulle kunna både hantera deras existerande system, men även kunna presentera det som skall bli resultatet av konverteringen. Under projektets gång har flertalet möten ägt rum hos Logica, för att kunna diskutera projektets gång och deras synpunkter på de olika etapperna. Dessa möten har skett mer eller mindre regelbundet, oftast veckovis, beroende på vad som har hänt i projektets väg och huruvida det varit några framsteg de har velat inspektera. 3.1 Teoretisk förstudie Projektet hanterade språken PL/SQL och Java, PL/SQL i det existerande systemet och Java i det format som slutprodukten skulle vara i. Erfarenheten av dessa var minimal och var tvungen att förbättras, detta gjordes genom att först söka information och teori om de båda språken. Det viktigaste i det här steget var att förstå hur språken fungerade, syntax, logik och uppbyggnad, på vilka olika sätt man kan använda dem samt vilka skillnader som fanns mellan dem. Efter en kort genomgång av de olika språken gjordes även ett par mindre projekt i dessa, för att skaffa den elementära kunskapen om hur språken används och vad som krävs för att kunna sätta upp en fungerande miljö. För att kunna förstå PL/SQL gjordes även en testsida med olika funktioner som förbättrade kunskaperna om språket. Genom att skapa ett projekt i Java som hade samma funktionalitet som den PL/SQLkod vi fått av företaget, kunde vi därmed se hur en fungerande konverteringen skulle kunna se ut. En beskrivning av det projektet kommer under avsnittet Konstruering av testprojekt. Med hjälp av detta projekt såg vi hur en konverterad kod skulle kunna se ut och hur den bör vara uppbyggd för att vara användbar och vilka olika delar en fungerande konvertering skall innehålla Informationssökning Projektet var tänkt att kontrollera olika konverteringsverktygs förmåga att konvertera PL/SQL till Java och behålla dess funktionalitet under processen. Detta för att en faktisk konvertering av Logicas nuvarande system bör ta så lite tid som möjligt och att konfiguration av resultatkoden skall vara liten. I början av projektet var kunskapen om olika konverteringsverktyg låg, förutom de som företaget hade gett oss tips om. Det första steget var således att försöka hitta olika verktyg som skulle kunna utföra den uppgift vi önskade. Initialt hittades fem olika verktyg som såg ut att vara passande för projektet, detta var dock mestadels en snabb överblick för att få en uppfattning angående vilka möjligheter som fanns. Vi undersökte även om det fanns några existerande liknande projekt som utförts tidigare och huruvida dessa varit lyckade eller ej. 22

25 Genomförande För att hitta relevanta artiklar och rapporter berörande ämnet och de olika programmeringsspråken användes sökmotorn på Högskolans bibliotek, dock användes mestadels en sökmotor för den resterande webben för att hitta de användbara verktygen. Informationssökning har även gjorts på olika bibliotek för att hitta relevanta böcker rörande ämnet och omkringliggande information. De böcker som använts har mestadels berört programmeringsbiten då det projekt vi sysslat med inte är något som är så vanligt förekommande att böcker skrivs om det. För att kunna sätta upp en fungerande testmiljö var vi även tvungna att hitta information om vilka versioner av Oracles databas samt applikationsserver som skulle användas tillsammans samt med vilket operativsystem. Det fanns dock inga direkta krav från applikationen vilka versioner som skulle användas. För att kunna sätta upp en applikationsserver för Javan var det även där tvunget att söka information om vilka skillnader det fanns mellan olika serverleverantörerna, samt vilka restriktioner de olika hade och eventuella licenskostnader. När det gäller applikationsservern för Java finns dock inte samma krav som PL/SQL ställer på databasen, då PL/SQL är utvecklat för Oracle krävs det att man har just en Oracledatabas. 3.2 Praktiskt förberedande Installation av testmiljö För att kunna undersöka huruvida de olika verktygen verkligen fungerade var vi tvungna att ha en arbetsmiljö som kunde hantera de olika momenten. Miljön var tvungen att kunna hantera en version av Logicas gamla system samt kunna presentera en webbapplikation baserad på Java. Testmiljön skulle vara enkel att spara samt återställa om något skulle gå fel. Efter en del testande insågs att en virtuell miljö (en virtuell dator installerad på testmaskinen) där det var lätt att spara och återställa skulle underlätta för att motverka eventuella snedsteg i projektets gång. I den virtuella miljön så krävdes det en arbetsmiljö för Oracles databas samt att Applikationsservern skulle kunna installeras och fungera felfritt. För att hitta ett operativsystem som detta stöddes av så krävdes det ett antal olika tester där ett flertal inte fungerade eller fyllde de krav som krävdes. Vad som kunde utgöra dessa problem var bland annat arkitekturen på operativsystemet, exempelvis om os:et var baserat på 32-bitars eller 64-bitars. Olika versioner av Oracles databas och applikationsserver krävde olika operativsystem och då företagets existerande system inte hade några direkta krav på vilken exakt version dessa skulle vara i, var det upp till oss att sätta upp en testmiljö som var smidig att installera samt fungerade som det existerande systemet. Varje test krävde att den virtuella plattformen raderades för att sedan byggas upp igen. Slutligen valdes en virtuell maskin med operativsystemet Windows XP (32-bitars) för att bli den arbetsplattform som projektet skulle använda sig av. Windows XP valdes för att det var det mest kompatibla systemet för Oracles produkter under testernas gång då många av de andra stötte på flera problem med kompabilitet och att använda en faktisk server-version visade sig kräva en stor del konfiguration vid varje steg i implementationen och valdes därför bort för att spara tid. 23

26 Genomförande Ytterligare en aspekt av installationen var att få en så kallad listener att fungera för databasen, denna krävs bland annat för att kunna använda webbgränssnittet med databasen och behövs även för applikationsservern, så att denna kan komma åt de olika PL/SQL procedurer och liknande man vill kalla på. När väl testmiljön för oracle-systemet var uppsatt och fungerande var nästa steg att installera ännu en applikationsserver, fast då istället för Java. Då vi använde samma databas som i det ursprungliga systemet behövdes alltså inte någon installation eller konfiguration av ännu en sådan. Tanken med Javan var att all information fortfarande skulle finnas i databasen, nödvändigtvis inte samma fabrikat som nu, men att man har.jsp filer och servlets sparade på hårddisk på en server för att generera webbservicen, med hjälp av en applikationsserver anpassad för Java, och att genom denna hämta informationen från databasen. Den applikationsserver vi valde att arbeta med var Apache Tomcat 7, då den är opensource, skall vara stabil och även lätt att konfigurera. Tomcat var kompatibelt med Windows XP, som vi nu valt som testmiljöns plattform, och var därför inte lika krävande att installera som Oracles olika produkter. I Figur 14 visas en grundläggande överblick på hur serverdatorn var installerad med olika applikationer samt hur vi kopplade upp oss mot den. Efter det att dessa applikationer var installerade krävdes det att den virtuella arbetsstationen skulle anpassas så att det gick att arbeta flera simultant på den från en remote desktop. Detta uppnåddes genom att ändra ett antal värden i registret då funktionen är inbyggd men ej aktiv i Windows XP. Efter att detta var gjort installerades den kod som vi erhållits utav företaget. All kontakt med oracles databas har gjorts med hjälp av SQLDeveloper som även det är en oracle-produkt. Det administrativa med databasen sköts via webbgränssnittet, alltså konfigurering av användare och rättigheter, samt portar och liknande funktionella inställningar. SQLdeveloper användes dock bland annat för redigering av tabeller i databasen, samt för att konfigurera de olika paketen i PL/SQL:en. Application Servers (TomCat/Oracle App Server) Internet Virtual Machine (Windows XP) Database (Oracle Database) Utvecklings applikationer (TextHanterare/SQLDeveloper) Figur 14 - Överblick av testmiljön, med applikationer. 24

27 Genomförande Redigering av existerande kod Efter att testmiljön var installerad och att allt fungerade felfritt var det dags att importera den kod vi fått av Logica som representerade deras ursprungliga system, alltså olika PL/SQL-paket. För att få koden att fungera utan problem i testmiljön krävdes viss redigering då denna bara var en liten del av det hela systemet och vissa delar var beroende av delar som ej var tillgängliga för oss i nuläget. Den kod vi fick av företaget hade stora delar av funktionaliteten bortkommenterad för att kunna använda endast de viktigaste delarna utan att faktiskt behöva implementera hela systemet, men det var delar av koden som ändå inte fungerade fullt ut, då vissa procedurer etc. krävde att rätt port och liknande angavs som argument. De funktioner som användes i de elementära paketen men exempelvis inte returnerade rätt värde redigerade vi till att fungera i vår testmiljö. Vi tog alltså bort all den kod som var bortkommenterad och de procedurer och funktioner i andra paket som inte användes för den funktionalitet vi behövde. Detta gjordes för att få så lättöverskådlig kod som möjligt och även för underlätta eventuell felsökning Konstruering av testprojekt Som tidigare nämnt utvecklade vi nu två projekt, ett i vardera språk. Det projekt som gällde PL/SQL, gjordes mestadels för att få kunskap om syntax och för att kontrollera att Oracles applikationsserver fungerade som tänkt. Projektet som vi gjorde i Java var dock tänkt att visa hur en fungerande Javakonverteringen skulle kunna fungera, vilket var nödvändigt för att kunna avgöra huruvida konverteringsverktygen fullföljde uppgiften vi gett dem. Vår Java-applikation var i slutändan uppbyggd med olika.jsp sidor, där vi använde servlets och klasser för att hantera in och utdata. Applikationen var uppbyggd efter den uppfattning vi fått av företagets inloggningstjänst och projektledarvisning. Vi byggde alltså en inloggning, visas i Figur 15, med koppling till oracledatabasen för att kontrollera huruvida användaren har tillgång eller ej. Vår lösning var baserad på htmlforms och POST-variabler för att skicka informationen och validera direkt på sidan, detta var dock enligt företaget inte det sätt man borde ha byggt tjänsten på och vi tog till oss informationen då vi inte tidigare arbetat med Java och därmed inte var helt säkra på arbetssättet. Figur 15 Inloggningsvy i vårt testprojekt i Java. 25

28 Genomförande Projektledarvisningen byggde vi på liknande sätt, visas i Figur 16, genom att fylla upp en html-form med information hämtad från databasen med hjälp av en variabel skickad med GET eller POST. Figur 16 Projektledarvisning i vårt testprojekt i Java 3.3 Konverteringsverktyg Initialt gick vi igenom de olika verktygen vi funnit för att se vilka som skulle kunna producera bäst resultat samt för att kunna utesluta eventuella kandidater som inte hade rätt funktionalitet. Som tidigare nämnt i kapitlet teoretisk bakgrund så kunde vi tidigt utesluta två av kandidaterna, vilka var Orindabuild och sqlways då dessa inte besatt rätt egenskaper för att kunna fullfölja våra tester. Vi testade sqlways på några av de paket vi fått av företaget och märkte då att det som sqlways faktiskt gjorde var att flytta innehållet i en databas av en tillverkare till en databas av en annan tillverkare och formaterade datan där efter. Några tester med Orindabuild blev aldrig av då detta verktyg skall användas vid utveckling av Java och man behöver koppla applikationen till en databas innehållandes PL/SQL kod och liknande, den skapar alltså en JDBC-koppling till databasen utan att man själv behöver skriva den. De verktyg som till slut har testats fullt ut är då SwisSQL och Exodus. Dessa verktyg var de som skulle kunna utföra de uppgifter vi behövde. 26