---

Jeg har et program, som skal leveres til en masse firmaer, først i norden,
derefter internationalt. Data fra dette program skal kunne integreres i
kundernes økonomisystemer, således at man i økonomisystemerne kan se
økonomidata og data fra mit program sammen.

Er der nogen af jer, der har erfaringer med dette? Hvordan bør jeg gøre det,
så kunderne får det, de forventer, når de ser, at programmet "kan
integreres med deres økonomisystemer"? Umiddelbart havde jeg tænkt mig at
levere COM interfaces eller SOAP interfaces, men jeg ved ikke rigtig, hvad
kunderne forventer...

Alle inputs er velkommen.

Hilsen,

Lars B. Dybdahl.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e20c043$0$11021$edfadb0f@dread12.news.tele.dk...

> Jeg har et program, som skal leveres til en masse
> firmaer, først i norden, derefter internationalt. Data
> fra dette program skal kunne integreres i kundernes
> økonomisystemer, således at man i økonomisystemerne
> kan se økonomidata og data fra mit program sammen.

Det kommer jo ret meget an på hvilke typer økonomisystemer vi taler om
og hvad slags data du skal levere til dem.

Har du ikke aftalt dette på forhånd med kunderne eller hvad? For mig
lyder det som om du begiver dig ud på dybt vand hvis du ikke på forhånd
har sat dig ind i hvad der skal leveres.

Hvor meget ved du om økonomi og regnskab?

--
M.v.h.
Olav
http://www.experit.dk
Fjern intet for at skrive til mig

---

Det tal på antal besøgende i forretninger, antal biler i parkeringskældre,
og tal på, hvordan folk går rundt i et center. Disse tal kan leveres på
mange måder af den eksisterende kode, men det er så op til den person, der
foretager den endelige integration, hvilke data der vælges, og hvordan det
puttes ind.

Systemet skal leveres til tusindvis af kunder, som kører alt ligefra
Navision, SAP, Oracle, Great Plains software, og forhåbentligt skulle det
også kunne integreres med mindre systemer.

Der er med andre ord ikke tale om at levere til en bestemt kunde eller et
bestemt økonomisystem, og det bliver ikke os, der skal foretage selve
integrationen. Det er derfor jeg spørger her, om der er nogen der kender
lidt til markedet og ved, hvad slags api der forventes ude i markedet? Jeg
spørger jo netop fordi jeg vil sætte mig ind i, hvad der skal leveres...

Hilsen,

Lars Dybdahl.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e213e5e$0$11012$edfadb0f@dread12.news.tele.dk...

> Systemet skal leveres til tusindvis af kunder, som kører
> alt ligefra Navision, SAP, Oracle, Great Plains software,
> og forhåbentligt skulle det også kunne integreres med
> mindre systemer.

Ok.

Den person der foretager den endelige integration, er det en udvikler
eller hvad?

Jeg har været med til forskellige typer af denne slags integration, og
det er meget forskelligt hvordan det er lavet.

En idé kunne være at lave et separat modul hvor I har indbygget hele
udtrækningsdelen (integrationsmodulet). Så kan en superbruger (eller
systemejer) så på en skærm sætte op hvordan data skal integreres fra det
ene system til det andet. Der vil sikkert altid skulle laves kodearbejde
bagefter - specielt for de mere avancerede kunder - men du kan da
ihvertfald give mulighed for at de kan løse en hel del af integrationen
selv. Eller satser du på at score ekstra timer på at lave integration
hos hver kunde?

Jeg kender ikke alle de nævnte økonomisystemer i detaljer, men start
f.eks. med at lave mulighed for at trække data ud i form af flade filer
(faste records eller kommasepararede). Så kan du bygge ovenpå med SOAP,
COM, CORBA osv. bagefter.

--
M.v.h.
Olav
http://www.experit.dk
Fjern intet for at skrive til mig

---

Olav M.J. Christiansen wrote:
> Den person der foretager den endelige integration, er det en udvikler
> eller hvad?

Det er jo det, jeg spørger om... Vi ønsker at levere et færdigt system i
æsker, der kan sælges til f.eks. et brasiliansk firma jeg ikke kan
kommunikere med. Dette firma skal så kunne tage vores produkt og sit
økonomi system og få disse integreret uden at spørge os.

> Jeg har været med til forskellige typer af denne slags integration, og
> det er meget forskelligt hvordan det er lavet.

Fortæl...

> En idé kunne være at lave et separat modul hvor I har indbygget hele
> udtrækningsdelen (integrationsmodulet).

Er sådan set allerede lavet som Delphi klasser - jeg mangler bare at pakke
det ind på den måde, der er mest hensigtsmæssig.

> Der vil sikkert altid skulle laves kodearbejde
> bagefter - specielt for de mere avancerede kunder - men du kan da
> ihvertfald give mulighed for at de kan løse en hel del af integrationen
> selv. Eller satser du på at score ekstra timer på at lave integration
> hos hver kunde?

Det vil vi ikke - men vi vil meget gerne lade forhandlerne score de
konsulenttimer, idet det vil øge motivationen for at sælge produktet.

> Jeg kender ikke alle de nævnte økonomisystemer i detaljer, men start
> f.eks. med at lave mulighed for at trække data ud i form af flade filer
> (faste records eller kommasepararede).

Erm... vil man anse det for at være et seriøst bud på et api til
integration? Husk, at vi vil skrive det på vores feature liste...

Hilsen,

Lars.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e2153d3$0$10996$edfadb0f@dread12.news.tele.dk...

[klip]
> Vi ønsker at levere et færdigt system i
> æsker, der kan sælges til f.eks. et
> brasiliansk firma jeg ikke kan kommunikere med.
[klip]

Ok - det stiller jo nogle andre krav til systemet.

Iøvrigt tror jeg vi er ved at bevæge os off-topic i forhold til en
Pascal-gruppe. Når vi taler økonomisystemer er der en helt masse andre
aspekter der kan være vigtigere end de tekniske (og jeg kan se at Uffe
har kommenteret på den rent tekniske side af sagen).

[klip]
> Fortæl...
[klip]

Min egen erfaring stammer fra så forskellige firmaer som Philips,
Maersk, Nordea, BAX Global samt andre mindre firmaer. Men det er en lang
historie som vil fylde for meget her i gruppen.

[klip]
> Erm... vil man anse det for at være et seriøst
> bud på et api til integration? Husk, at vi vil skrive
> det på vores feature liste...
[klip]

Ja, absolut. Hvis det er den eneste mulighed man har, er det jo bedre
end slet ingenting.

Inden vi bevæger os mere off-topic end vi allerede er, så lad mig slutte
af med nogle gode råd. Hvis du så vil have det uddybet, kan du evt.
kontakte mig direkte:

Postulat: Det kan *ikke* lade sig gøre at lave en universel løsning der
kan integreres fuldt ud med alle mulige (og umulige) økonomisystemer.

Derfor vil et udtræk til en flad fil, kommasepareret fil, eller f.eks. i
en database med ODBC-adgang ell. lign. være en 'generisk' løsning som en
kunde kan anvende, hvis der ikke findes andre løsninger.

Kort fortalt vil jeg råde dig til følgende:

1. Brug lidt tid på at sætte dig ind i lidt bogføring (få en bogholder
eller revisor til at give dig en introduktion eller lån en bog på
biblioteket). Det er ikke noget jeg kan lære dig på 5 min. på usenet.

2. Lav en generisk løsning som beskrevet tidligere, der kan anvendes
hvis alt andet ikke duer.

3. Design en integrationsløsning som gør det enkelt at lave nye
interfaces (som f.eks. de klasser du allerede har lavet - med lidt
overbygning på).

4. Sæt dig ind i nogle af de væsentligste systemer som du forventer
kunderne anvender (f.eks. Navision, SAP, Oracle, Great Plains software
som du jo selv beskriver). Det kan enten være ved at kontakte en
leverandør af den software eller ved at bruge en kunde som 'pilot'.

5. Lav så nogle standardløsninger der passer til de vigtigste løsninger.
Afhængig af om tid er en faktor kan du så lave resten af løsningerne
efterhånden som kunderne efterspørger dem. Hvis du skal implementere
alle disse løsninger inden produktet bliver udsendt, skal du forvente en
ret stor arbejdsopgave.

Du bør også være opmærksom på ting som f.eks. bogføringsloven der
bestemt ikke er den samme i f.eks. Danmark og Brasilien. Endvidere er
det ikke alle økonomisystemer der 'kan lide' at indlæse tredjeparts
data. Slutteligt vil der også være kunder der har udviklet deres egne
økonomisystemer (jo - de findes). Med andre ord er der ret mange ting at
tænke over, som jeg ikke kan beskrive på få linier i dette forum.

Kontakt mig direkte hvis du vil have yderligere information.

--
M.v.h.
Olav
http://www.experit.dk
Fjern intet for at skrive til mig

---

Jeg ved skam stort set alt, hvad der skal vides om bogføring, men det har
ikke så meget med sagen at gøre. Kunden vil gerne kunne sammenholde
økonomiske nøgletal med vores besøgstal. F.eks. er det jo meget rart at
vide, at gennemsnitsbesøgstiden i butikkerne er øget efter den sidste
reklamekampagne, selv om omsætningen ikke steg.

Jeg har Delphi API'er til at levere data (som virker under både Linux og
Windows), og Uffe's løsninger kender jeg allerede og har stort set haft dem
alle sammen i mine tanker inden jeg skrev det første indlæg her. Så det
hele drejer sig i virkeligheden om at vælge, hvilke teknologier jeg skal
pakke mine Delphi API'er ind i...

Hvis jeg skal lave flade filer, så ville jeg gøre det ved at lave et GUI
windows program i Delphi, som gør det nemt at hælde flade filer ud. Evt.
gøre det muligt at gemme opsætningen, så man kan aktivere det fra en Win32
text mode kommando linie.

Hvis jeg skal lave COM objekter, så ville jeg kaste mig over Delphi's
dejlige COM faciliteter og så lave en stor dokumentation bagefter med
eksempler i .vbs.

Hvis jeg skal lave SOAP, vil jeg nok undersøge, om det kan laves med Apache
serveren på Linux serverne (som vi leverer som "black box" til kunderne),
fordi vi så helt kan undgå at skulle installere noget på kundernes
computere.

Delphi API'et ligger ret fast, idet det bygger på store beregningsalgoritmer
og stort set udtømmer alle de måder, man kan få data ud på.

Dermed burde punkt 1), 2), 3) og 5) være dækket i dit indlæg - jeg mangler
kun punkt 4). Og her tænkte jeg netop så genialt, at det kunne jo være at
en eller anden her på listen havde nogle erfaringer, som de kunne dele ud
af... som kunne fortælle mig, om integration med økonomisystemer er et
stort kaos, eller om der er nogle teknologier, der er at foretrække.

Vi vil sandsynligvis køre lidt test på nogle kunder i norden, men af
forskellige årsager, så næsten uanset hvad vi leverer til dem vil de blive
glade og ikke komme med konstruktiv kritik. Og det kan jeg jo ikke bruge
til noget... jeg har brug for, at nogen med overblik fortæller mig, at "De
fleste integrationer sker med flade filer, men integrationsprogrammørerne
sukker efter COM komponenter eller lignende", eller "COM komponenter kan
ikke bruges i de fleste systemer nutildags fordi..." eller "SOAP er det,
som alle bruger i dag, hvis du leverer andet vil de grine af dig" eller
"Dine kunder vil være bedøvende ligeglade".

Umiddelbart synes jeg at dk.edb.programmering.pascal er det helt rette
forum, idet valget af teknologi skal ses i lyset af de anvendte
programmeringsværktøjer, som her er Borland Delphi 7 Data Architect og
Kylix 3 for Delphi.

Hilsen,

Lars Dybdahl.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e2175b2$0$11010

(...)
> Hvis jeg skal lave SOAP, vil jeg nok undersøge, om det kan laves med
Apache
> serveren på Linux serverne (som vi leverer som "black box" til kunderne),

Hvis du med "laves med" mener kan køre under, så er svaret ja. Det gælder
også windows-versionen af Apache.

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e2153d3$0$10996

> > Jeg kender ikke alle de nævnte økonomisystemer i detaljer, men start
> > f.eks. med at lave mulighed for at trække data ud i form af flade filer
> > (faste records eller kommasepararede).
>
> Erm... vil man anse det for at være et seriøst bud på et api til
> integration? Husk, at vi vil skrive det på vores feature liste...

Forslaget er godt, for XML kan mange større systemer jo håndtere i dag.

---

David A. D. Konrad wrote:
> Forslaget er godt, for XML kan mange større systemer jo håndtere i dag.

Har du eksempler? Som jeg har skrevet, skal vi tage systemer, som kunderne
bruger - ikke de sidste nye versioner der bliver solgt.

Lars Dybdahl.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e213e5e$0$11012$edfadb0f@dread12.news.tele.dk...
> Det tal på antal besøgende i forretninger, antal biler i parkeringskældre,
> og tal på, hvordan folk går rundt i et center. Disse tal kan leveres på
> mange måder af den eksisterende kode, men det er så op til den person, der
> foretager den endelige integration, hvilke data der vælges, og hvordan det
> puttes ind.
>
> Systemet skal leveres til tusindvis af kunder, som kører alt ligefra
> Navision, SAP, Oracle, Great Plains software, og forhåbentligt skulle det
> også kunne integreres med mindre systemer.

Med andre ord : Du skal integrere på vidt forskellig måde, til forskellige
koncepter og vidt forskellige platforme.

> Der er med andre ord ikke tale om at levere til en bestemt kunde eller et
> bestemt økonomisystem, og det bliver ikke os, der skal foretage selve
> integrationen. Det er derfor jeg spørger her, om der er nogen der kender
> lidt til markedet og ved, hvad slags api der forventes ude i markedet? Jeg
> spørger jo netop fordi jeg vil sætte mig ind i, hvad der skal leveres...

Jeg har en del gange arbejdet med integration til eksisterende systemer,
også systemer der ikke var hyldevarer, ala Oracle, SAP, Novell mv. Det er
som oftest det mest problemetiske.

Integration kan, som jeg ser det, forståes og foregå på tre måder

* Integration der kobler sig til kundens system. Mange større systemer, SAP,
navision mv, har muligheder for at man kan tilføje tredjeparts komponenter,
skærmbilleder mv - eller i udvikle addons eller hooks der bliver leveret som
f.eks en DLL/EXE. I dit tilfælde kunne nogle kunder måske forvente, at
"integration" betød en udvidelse af standardprogrammet, f.eks en "se
dybdahl-data"-knap, der fik et skærmbillede til at poppe op, og viser de
data du nævner ovenover.

* Integration til legacysystemet. Det er måske det, der i systembeskrivelsen
menes med "integration". Din løsning skal indeholde en administrativ del,
hvor man definerer hvad, hvor og hvordan de data du leverer gemmes ned i det
eksisterende systems registre/database(R), og det er så op til
legacysystemet at behandle og vise disse udefrakommende data korrekt. Det er
nok den mest fleksible løsning, da du dermed kan gøre spændvidden af
integrationsmuligheder temmelig bred. F.eks kan "besøgende" blive lagt i
tabel i en eksisterende database, medens oplysninger om kundernes bevægelser
kan lægges i et mere valgfrit brancheorienteret layout i XML, der kan vises
på 17 forskellige måder.

* Applikationintegration. Det er den løsning, du umiddelbart taler om, men
som virker en smule ugennemførlig, ummiddelbart. Der er tale om, at man
binder sig til det eksisterende systems teknologi, og udvider systemets
funktionalitet på dets egne præmisser - som du skriver via COM eller SOAP.
Det er en risikabel vej at gå - det er jo ikke dit system, der skal
integrere med kernesystemet, men kernesystemet der skal integreres med det
du leverer. Heldigvis er der nu kommet Web Services, og hvis systemet
understøtter Web Services, og man kan registrere en Web Service og få vist
data fra de XML-pakker man sender til systemet via den leverede Web Service,
må det helt klart være vejen frem.

---

Det er jo helt klart en kombination af "integration der kobler sig til
kundens system" og "applikationsintegration" der skal opnås - nu beskrevet
med dine ord.

Kunden skal selvflg. selv vide, hvordan de laver en knap, der viser data fra
vores system og programmere de skærmbilleder, der skal laves. Men eftersom
det på grund af dataernes art ikke giver mening at kigge direkte ned i
vores database, skal data hentes via et interface (api). Her forstår jeg
ikke, hvorfor du på den ene side siger "risikabel" og på den anden side
siger "helt klart være vejen frem" om det samme.

Men din anbefaling om at gå webservices vejen vil jeg tage til efterretning.
Kan webservices også integreres i kundens økonomisystem, hvis de f.eks.
kører Concorde C5, bare for at tage et eksempel? Vi skulle jo nødigt ud i,
at kunden skal opgradere sit økonomisystem til sidste nye version bare på
grund af vores produkt - det ville jo være urealistisk.

Hilsen,

Lars Dybdahl.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

Hvis dine data kan gemmes i en database, så skal du bare sørge for, at
basen kan tilgåes med ODBC eller lign. Med en DBISAM database er dette
f.eks. nemt.

Alternativt kan du lave et COM/DCOM interface til din applikation.

Hvis brugerne ikke er på windows platformen, kan du overveje CORBA, som
er mere universelt end COM, men stadig med "State".

Hvis data skal leveres over nettet, så er SOAP nok mere relevant, men
dette kan selvfølgelig også anvendes lokalt. SOAP er "stateless" og nok
generelt langsommere, men det betyder muligvis ikke noget for din
anvendelse.

Jeg anvender DCOM i et system, som skal kunne tilgåes generelt fra mange
applikationer og overvejer at udvide med CORBA (har nok lidt lange
udsigter p.t.).

Hilsen
Uffe

"Lars B. Dybdahl" <Lars@dybdahl.dk> wrote in message
news:3e20c043$0$11021$edfadb0f@dread12.news.tele.dk...
> Jeg har et program, som skal leveres til en masse firmaer, først i
norden,
> derefter internationalt. Data fra dette program skal kunne integreres
i
> kundernes økonomisystemer, således at man i økonomisystemerne kan se
> økonomidata og data fra mit program sammen.
>
> Er der nogen af jer, der har erfaringer med dette? Hvordan bør jeg
gøre det,
> så kunderne får det, de forventer, når de ser, at programmet "kan
> integreres med deres økonomisystemer"? Umiddelbart havde jeg tænkt mig
at
> levere COM interfaces eller SOAP interfaces, men jeg ved ikke rigtig,
hvad
> kunderne forventer...
>
> Alle inputs er velkommen.
>
> Hilsen,
>
> Lars B. Dybdahl.
>
> --
> Freelance programmør
> Dybdahl Engineering: http://dybdahl.dk/
> Delphi brugergruppen DAPUG: http://dapug.dk/
>

---

Har du konkrete erfaringer med anvendelse af SOAP i forb. med integration
til større systemer? Jeg overvejer lidt SOAP, da serveren er Linux baseret,
men det vil koste mindre udviklingstid at lave COM interfaces med
Delphi/Windows.

Jeg kunne godt tænke mig at se nogle fordele/ulemper ved de forskellige
teknologier - f.eks. kunne jeg forestille mig, at SOAP ikke er alt for
udbredt i alle økonomisystemer, at COM egentlig ikke er en helt dårlig ide
fordi kunden altid kan sætte en Windows computer op til
integrationsformålet, og at CORBA er lidt overkill... men som sagt har jeg
ikke udført den slags opgaver før, så al input vil blive medtaget i
overvejelserne.

Det kan godt være, at vi på længere sigt tilbyder både SOAP, COM, DCOM og
Corba interfaces, men på kort sigt skal vi bare gøre det muligt at
integrere, så vi kan skrive det på feature listen og få nogle kunder som
referencer, som er glade for det, de fik.

Lars Dybdahl.

--
Freelance programmør
Dybdahl Engineering: http://dybdahl.dk/
Delphi brugergruppen DAPUG: http://dapug.dk/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> skrev i en meddelelse
news:3e20c043$0$11021$edfadb0f@dread12.news.tele.dk...
> Jeg har et program, som skal leveres til en masse firmaer, først i norden,
> derefter internationalt. Data fra dette program skal kunne integreres i
> kundernes økonomisystemer, således at man i økonomisystemerne kan se
> økonomidata og data fra mit program sammen.
>
> Er der nogen af jer, der har erfaringer med dette? Hvordan bør jeg gøre
det,
> så kunderne får det, de forventer, når de ser, at programmet "kan
> integreres med deres økonomisystemer"? Umiddelbart havde jeg tænkt mig at
> levere COM interfaces eller SOAP interfaces, men jeg ved ikke rigtig, hvad
> kunderne forventer...
>
> Alle inputs er velkommen.

Jeg forstår godt din tvivl, for jeg skal love for at det er en "bred"
opgaveformulering du der har fået dig pådraget. Det kunne være fristende at
spørge hvilket "økonomisystem" der er tale om, men det nævner du sikkert
ikke bevidst - eller også er du måske pt ikke selv klar over det.

Det er tvivlsomt om mine eller andre debattørers erfaringer mht integration
er direkte brugbare - det afhænger i alle tilfælde af hvad der skal
integreres med - f.eks integrerer man på forskellig måde med outlook og
groupwise. Som jeg tolker første afsnit, og som jeg tolker er essensen i
det, der implicit ligger i kundens forventninger, skal "integration"
forståes på data-niveau, og altså ikke program-niveau. Opgaven handler
derfor om at finde en port ind til økonomisystemet, således at da data du
leverer, kan blive forstået og vist korrekt af dette system.