I paketeringen av boendekalkylen ingår en datalager-implementation som använder JDBC för att spara och hämta information i en databas. Denna plugin fungerar enbart i java-versionen av boendekalkylen.

JDBC datalagret är testat mot följande databaser: 

  • PostgreSQL (testas regelbundet)

  • MS SQL Server

  • DB2

Plugin'et kan antingen själv skapa en anslutning direkt till databasen eller erhålla en anslutning via JNDI. Används JNDI så konfigureras drivrutinen, databasens url, användarnamn och lösenord i applikationsservern.

Aktivera JDBC-plugin'et

Med nedanstående inställningar aktiveras jdbc-plugin'et.

<Impcapitex_integration_dataadaptrar_IListaEnHandlaeggaresKalkyler>capitex.boendekalkyl.datalager.jdbc.ListaEnHandlaeggaresKalkyler</Impcapitex_integration_dataadaptrar_IListaEnHandlaeggaresKalkyler>
 
<Impcapitex_integration_dataadaptrar_IHaemtaKalkyl>capitex.boendekalkyl.datalager.jdbc.HaemtaKalkyl</Impcapitex_integration_dataadaptrar_IHaemtaKalkyl>
 
<Impcapitex_integration_dataadaptrar_IListaAllaKalkylerFoerEnPerson>capitex.boendekalkyl.datalager.jdbc.ListaAllaKalkylerFoerEnPerson</Impcapitex_integration_dataadaptrar_IListaAllaKalkylerFoerEnPerson>
 
<Impcapitex_integration_dataadaptrar_IRaderaKalkyl>capitex.boendekalkyl.datalager.jdbc.RaderaKalkyl</Impcapitex_integration_dataadaptrar_IRaderaKalkyl>
 
<Impcapitex_integration_dataadaptrar_ISparaKalkyl>capitex.boendekalkyl.datalager.jdbc.SparaKalkyl</Impcapitex_integration_dataadaptrar_ISparaKalkyl>

Drivrutin anges med inställningen
Impcapitex_integration_boendekalkyl_JDBCDrivrutin  

Anslutningssträng anges med inställningen
Impcapitex_integration_boendekalkyl_DatabasURL

Användarnamn anges med inställningen
Impcapitex_integration_boendekalkyl_Annvaendarnamn

Lösenord anges med inställningen
Impcapitex_integration_boendekalkyl_Loesenord

Om JNDI används så ska inga av ovanstående anslutningsinställningar används och sätt följande inställning till true:
Impcapitex_integration_boendekalkyl_AnvaendJNDI

Om JNDI används så ska datasource-namnet anges med inställningen
Impcapitex_integration_boendekalkyl_DataSourceName

Vilken teckenkodning som ska användas för att spara och hämta binär data
capitex_boendekalkyl_jdbc_binary_data_encoding

Exempel, databas-anslutning med JNDI

Nedanstående konfiguration ansluter till en databas som konfigurerats i applikationsservern med DataSource-namnet myDataSource.

<Impcapitex_integration_boendekalkyl_AnvaendJNDI>true</Impcapitex_integration_boendekalkyl_AnvaendJNDI>
 
<Impcapitex_integration_boendekalkyl_DataSourceName>myDataSource</Impcapitex_integration_boendekalkyl_DataSourceName>

I de flesta applikationsservrar anger man två olika namn på en datakälla, det ena namnet kallas ofta JNDI-name och representerar "sökvägen" i JDNI-trädet tex "datasources.jdbc.mydatasource" och så kan man ange ett unikt namn som fofta kallas "name", "datasourcename" eller "uniqe name/id". Här verkar det dock finnas en liten förvirrning för vilket namn som ska användas vid "lookup". I tex weblogic version 8 så kunde man använda det unika namnet, men i version 10 verkar det som om man måste använda JNDI-namnet (det med punkter i).

Exempel, databas-anslutning med JNDI i WebSphere

Om JNDI-miljövariablerna INITIAL_CONTEXT_FACTORY och PROVIDER_URL inte är satta så kan dess också sättas via inställningar. Följande exempel visar hur dessa kan sättas i WebSphere. Detta ska normalt sett inte behöva göras.

<Impcapitex_integration_boendekalkyl_AnvaendJNDI>true</Impcapitex_integration_boendekalkyl_AnvaendJNDI>
 
<Impcapitex_integration_boendekalkyl_INITIAL_CONTEXT_FACTORY>com.ibm.websphere.naming.WsnInitialContextFactory</Impcapitex_integration_boendekalkyl_INITIAL_CONTEXT_FACTORY>
 
<Impcapitex_integration_boendekalkyl_PROVIDER_URL>corbaloc:iiop:localhost:2809</Impcapitex_integration_boendekalkyl_PROVIDER_URL>
 
<Impcapitex_integration_boendekalkyl_DataSourceName>myDataSource</Impcapitex_integration_boendekalkyl_DataSourceName>

Exempel, databas-anslutning med JNDI i WebLogic

Om JNDI-miljövariablerna INITIAL_CONTEXT_FACTORY och PROVIDER_URL inte är satta så kan dess också sättas via inställningar. Följande exempel visar hur dessa kan sättas i WebLogic. Detta ska normalt sett inte behöva göras.

<Impcapitex_integration_boendekalkyl_AnvaendJNDI>true</Impcapitex_integration_boendekalkyl_AnvaendJNDI>
 
<Impcapitex_integration_boendekalkyl_INITIAL_CONTEXT_FACTORY>weblogic.jndi.WLInitialContextFactory</Impcapitex_integration_boendekalkyl_INITIAL_CONTEXT_FACTORY>
 
<Impcapitex_integration_boendekalkyl_PROVIDER_URL>t3://localhost:7001</Impcapitex_integration_boendekalkyl_PROVIDER_URL>
 
<Impcapitex_integration_boendekalkyl_DataSourceName>myDataSource</Impcapitex_integration_boendekalkyl_DataSourceName>

Måste man sätta dessa så är ofta provder-url precis samma som applikationens host-namn, dvs kör man applikationen på http://myserver.test.se:7501/Boendekalkyl/BoKalkGraenssnitt så bör provider_url bli t3://myserver.test.se:7501. Har man ett kluster med servrar så verkar det som om man ska lista alla serverinstanser enligt följande exempel:

<Impcapitex_integration_boendekalkyl_PROVIDER_URL>t3://server1.test.se:7501,server2.test.se:7501</Impcapitex_integration_boendekalkyl_PROVIDER_URL>

Detta är dock så dåligt dokumenterat att vi inte är helt säkra, för en del verkar det funka att ange enbart samlingsnamnet för klustret, men hur detta eller hur ovanstående fungerar när en server kopplas bort från klustret har vi inte testat. För att konfigurera detta rätt i ett kluster behövs helt klart expertkunskaper... I WebLogic kan man gå in i admin-verktyget under en serverinstans och bläddra fram dataanslutningen i JNDI-trädet, där finns det en "toString()" för dataanslutningen, ur den kan man luska fram hur man ska skriva provider_url'en.

Exempel, DB2-anslutning utan JNDI 

Nedanstående konfiguration ansluter till en DB2-databas med namnet bokalk med användare ad\user och lösenord password. I detta fall används inte JNDI för att hämta databasanslutningen. Detta sätt är inte J2EE-compliant.

<Impcapitex_integration_boendekalkyl_JDBCDrivrutin>COM.ibm.db2.jdbc.app.DB2Driver</Impcapitex_integration_boendekalkyl_JDBCDrivrutin>
 
<Impcapitex_integration_boendekalkyl_DatabasURL>jdbc:db2:bokalk</Impcapitex_integration_boendekalkyl_DatabasURL>
 
<Impcapitex_integration_boendekalkyl_Annvaendarnamn>ad\user</Impcapitex_integration_boendekalkyl_Annvaendarnamn>
 
<Impcapitex_integration_boendekalkyl_Loesenord>password</Impcapitex_integration_boendekalkyl_Loesenord>

Exempel, MS SQL-anslutning

Nedanstående konfiguration ansluter till en SQL-databas på den lokala datorn med användare user och lösenord password. Databasen för boendekalkylen är satt som default-databas för användaren ifråga. Det finns troligtvis bättre drivrutiner för att ansluta till MS SQL-sevrer än att gå omvägen via Suns ODBC-drivrutin som i exemplet.

<Impcapitex_integration_boendekalkyl_JDBCDrivrutin>sun.jdbc.odbc.JdbcOdbcDriver</Impcapitex_integration_boendekalkyl_JDBCDrivrutin>
 
<Impcapitex_integration_boendekalkyl_DatabasURL>jdbc:odbc:Driver={SQL Server};Server=localhost;Uid=user;Pwd=password;</Impcapitex_integration_boendekalkyl_DatabasURL>
 
<Impcapitex_integration_boendekalkyl_Annvaendarnamn>user</Impcapitex_integration_boendekalkyl_Annvaendarnamn>
 
<Impcapitex_integration_boendekalkyl_Loesenord>password</Impcapitex_integration_boendekalkyl_Loesenord>

Tabeller 

Datastrukturen är mycket enkel och består av två tabeller. Kalkyl och Person. En sparad boendekalkyl blir en post i tabellen Kalkyl och en eller flera poster i Person. Om samma person finns med i flera kalkyler så finns personen med flera gånger i person-tabellen. Dvs två olika kalkyler delar alltså ingen information med varandra.

Kalkylens inmatade data sparas som en BLOB i databasen. Denna BLOB ska inte försöka läsas av utomstående system. För att läsa data så kan medföljande webservices användas. Önskas en annan databasmodell så kan egna funktioner för hämta och spara enkelt implementeras.

Schema

De sql-frågor som boendekalkylen ställer mot tabellerna innehåller inget schema-namn, databasen måste alltså konfigureras så att databas-användarens default-schema är samma schema som tabellerna.

Exempel på typisk SQL-fråga som ställs:

SELECT KalkylDataXML, Arkiverad, Kalkylnamn, Handlaeggare, Kontor, SenastAendrad, Skapad FROM Kalkyl WHERE KalkylID = ?

Används derby så skapas databas och tabeller automatiskt

Sätt följande inställning för att tabellerna ska skapas automatsitk i Derby, med dessa inställningar så skapas databasen i katalogen c:\boendekalkyl

<Impcapitex_integration_boendekalkyl_SkapaDBOmDenSaknas>true</Impcapitex_integration_boendekalkyl_SkapaDBOmDenSaknas>
 
<Impcapitex_integration_boendekalkyl_JDBCDrivrutin>org.apache.derby.jdbc.EmbeddedDriver</Impcapitex_integration_boendekalkyl_JDBCDrivrutin>
 
<Impcapitex_integration_boendekalkyl_DatabasURL>jdbc:derby:C:\\Boendekalkyl</Impcapitex_integration_boendekalkyl_DatabasURL>
 
<Impcapitex_integration_boendekalkyl_Annvaendarnamn>-</Impcapitex_integration_boendekalkyl_Annvaendarnamn>
 
<Impcapitex_integration_boendekalkyl_Loesenord>-</Impcapitex_integration_boendekalkyl_Loesenord>

Exempel Tabellscript - DB2

CREATE TABLE KALKYL (
KALKYLID VARCHAR(40) NOT NULL,
KALKYLNAMN VARCHAR(30),
SENASTAENDRAD TIMESTAMP,
SKAPAD TIMESTAMP,
HANDLAEGGARE VARCHAR(80),
ARKIVERAD SMALLINT,
KONTOR VARCHAR(80),
KALKYLDATAXML BLOB(1 M) LOGGED NOT COMPACT,
CONSTRAINT CC1228215669195 PRIMARY KEY (KALKYLID)
);
 
CREATE TABLE PERSON (
PERSONID VARCHAR(40) NOT NULL,
KALKYLID VARCHAR(40) NOT NULL,
FOERNAMN VARCHAR(30),
EFTERNAMN VARCHAR(80),
PERSONNUMMER VARCHAR(12),
CONSTRAINT CC1228215958062 PRIMARY KEY (PERSONID),
CONSTRAINT CC1228215964046 FOREIGN KEY (KALKYLID)
REFERENCES KALKYL (KALKYLID)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT ENFORCED
ENABLE QUERY OPTIMIZATION
);

Exempel Tabellscript - MS SQL

CREATE TABLE KALKYL (
KALKYLID VARCHAR(40),
KALKYLNAMN VARCHAR(30),
SENASTAENDRAD DATETIME,
SKAPAD DATETIME,
HANDLAEGGARE VARCHAR(80),
ARKIVERAD SMALLINT,
KONTOR VARCHAR(80),
KALKYLDATAXML IMAGE
);
 
CREATE TABLE PERSON (
PERSONID VARCHAR(40),
KALKYLID VARCHAR(40),
FOERNAMN VARCHAR(30),
EFTERNAMN VARCHAR(80),
PERSONNUMMER VARCHAR(12)
);

Tabellen OEvrigt behövs enbart om inställningar mm ska ligga i databasen  

CREATE TABLE OEVRIGT (
  OEVRIGTID varchar(40),
  XMLDATA image
);

Tabellen KreditProdukt behövs enbart om modulen kreditprodukter används.

CREATE TABLE KREDITPRODUKT (
  KREDITPRODUKTNAMN varchar(40),
  KREDITPRODUKTXML image
);

Index och nycklar

Kalkyl.kalkylid (primärnyckel, unikt, klustrat)
Kalkyl.handlaeggare (index, ej unikt)

Person.personid (primärnyckel, unikt, klustrat)
Person.kalkylid (foreign key, ej unikt, inga triggers eller constraints)
Person.personummer (index, ej unikt)

OEvrigt.oevrigtid (primärnyckel, unikt, klustrat)

KreditProdukt.kreditproduktnamn (primärnyckel, unikt, klustrat)