28. august 2002 - 12:36Der er
23 kommentarer og 2 løsninger
Javaapplikation der læser/skriver til Concorde XAL
Vores system kommer til at bestå af en Java applikation der skal trække en række data ud fra XAL. Dette kan dreje sig om ordreoplysninger m.m. Disse oplysninger skal kunne ses og evt rettes i. Da vi desværre kun besidder ODBC driver der kan læse, kommer vi til at simulere en skrivning. Dette er et skoleprojekt,så vi har kun til starten af november til at bliver færdige (indbefatter analyse,design, realisering). Er det muligt at forstå og lave et sådan program indenfor 3 måneder ?
EN anden løsning er at konveretere XAL databasen til f.eks. en MS SQL databasen. Derved bliver det ikke så svært at læse/skrive til databasen. Men det kræver self. en konvertering af databasen, og vi har ingen anelse om dette er muligt (om der evt findes programmer til dette). Det kan også give problemer med den grafiske overbygning, som er tilpasset trykkeribranchen, da den vel skal ændres til at snakke med MS SQL serveren ?
Du kan sagtens konvertere fra Native til SQL på XAL. Det koster bare nogle penge, og så vidt jeg ved, er det ret dyrt. Om I kan nå det på 3 måender afhænger meget af hvor mange I er, om virksomheden har de nødvendige ressourcer til at hjælpe jer, og om I har den nødvendige viden eller om I først skal erhverve den undervejs.
Vi er 3 personer som aldrig har arbejdet med XAL før, og jeg tvivler på at virksomheden har lyst til at punge ud da det er et skole projekt og dermed ikke garanti for at de får noget ud af det.
Den umiddelbare løsning er at der findes en konverteringsværktøj til XAL der virker (gratis) eller at det ikke var det store problem at kommunikere med XAL via Java(ODBC)
IMHO ... hvis bare jeres projekt var præsentation af data (rapportgenerator etc), via en java-applikation, så var der ingen problemer. MEN det at sætte en andet system til at rette direkte i XALs database, er et temmeligt kompliceret projekt. Det skyldes at den forretningslogik der holder XALs database konsistent faktisk KUN kan skrives i XALs eget programmeringssprog (i hvert tilfælde hvis det skal gå godt). I sær omkring alt med lagerposteringer (som ordremodulet har forbindelse med) i det bestemt ikke en nem opgave, at få et andet system til at ændre på dataene, hvis databasen skal være konsistent.
Nu skriver I ikke meget om hvad jeres applikation skal kunne, men umiddelbart lyder det for mig som om at opgaven ikke kan løses inden for den tidshorisont I nævner.
Systemet er for et trykkeri. Når ordren kommer ind er alle informationer ikke til rådighed. De kommer løbende. Derfor vil det være smart at folk nede i trykkeriet selv kan opdaterer ordren uden at skulle løbe op til adminitrationen hver gang. Det er derfor meningen at de skal bruge vores (kommende) java applikation (som kun viser ting der er relevant for dem) til at opdaterer evt manglende oplysninger...
De informationer I nævner som kommer til i produktionsforløbet, hvad er det for informationer ? Er det informationer som relaterer sig til de salgsordredata som registreres i XAL, eller er det informationer udover disse ? I skriver at løsningen er til et trykkeri, så kunne man jo godt tænke sig at det var informationer som var specielle for trykkeribranchen eller måske endda for det firma I skal lave projektet for ???
Den funktionalitet, I nævner, er allerede standard i XAL. Hvis jeres censor ved det, så dumper I med et brag. Det vil tage under en dags arbejde at finpudse skærmbillede osv, så det er ikke engang dyrt - og ikke i nærheden af de omkostninger, som vil være forbundet med jeres løsning.
Det hjælper jer ikke meget omkring skoleopgaven, det beklager jeg.
Ja se det er jo en anden sag. Men det ændrer ikke at I vil bruge hardwaren som "undskyldning" for at lave en løsning, som allerede er standard. I vil dumpe på det.
Med hensyn til konverteringen, så er det nu ikke det helt store problem, hvis der enten kun er tale om ringe datamængde eller en "engangskonvertering".
Den normale måde er at bruge xal'ens standard data export funktion til at smide al data ud i komma sep. filer og så indlæse disse i sql versionen.
Jeg tror også nok vi er ved at hælde mere til en løsning der indbefatter : - Evt opdatering fra nuværende Concorde XAL 2.6 til den nyeste (men der er jo nok økonomi indbefattet, så ved endnu ikke om det bliver) - Konvertering af native DB til SQL (Lettere tilgang til java app.)
Når det er sagt er det rigtig nok at den optimale løsningen ville være at lave det i XAL, men til det har vi en række spørgsmål for at belyse emnet (det er jo vigtig at have alle oplysninger før man vælger) Der eksisterer allerede en overbygning kaldet Graphware. Denne bliver brugt af administrationen. Folkene nede i trykkeriet skal derfor have et andet dialog vindue. Generelle oplysninger om ordren. - Er det _meget_kompliceret at lave sådan et vindue i XAL eller muligt indenfor 3 mdr ? - Vi har svært ved at overskue databasestrukturen i XAL, findes der sider der forklarer det ? (Det er en anden grund til vi heller så en konvertering af DB, plus af det er en mere "moderne" løsning)
Et vindue med generelle ordreoplysninger i XAL kan nok laves på en 7-8 timer (med test).
Selvom I konverterer dataene til en SQL-server, er der stadig et problem med at skrive i XAL'ens database fra en anden applikation. 98% af den logik som anvendes for at holde databasen konsistent, kan ikke kaldes udefra.
Hvis produktions/trykkerifolkene skal kunne ændre i data i en javaapplikation, så skal man skrive hele den forretningslogik, som anvendes til vedligeholdelse af ordrer om igen i Java.
Det kommer selvfølgelig an på HVILKE data man ændrer. Hvis det bare er f.eks. ændringer til betegnelsen på den enkelte ordrelinie, så er det ikke et problem. Men hvis man begynder at ændre på f.eks. antal på en ordrelinie, så kan det ikke lade sig gøre fra Java, uden at skulle lave en helt masse logik, som behandler relaterede data i forhold til ændringen.
Det vil være den bedste løsning at lave det i XAL.
Der findes et digert værk som hedder XAL in Case, men det er lavet til version 2.52 og vedligeholdes ikke mere.
Nogle få tommelfingerregler omkring tabelnavne i XAL:
Hvis tabellen hedder Table eller Kart som det sidste i navnet er det stamdata. Hvis tabellen hedder Trans eller Post er det posteringer/transaktioner/historik.
Ellers kan man skelne mellem de forskellige modulers tabeller ved at kigge på den første del af navnet:
wilco -> Men SQL kan vil ikke bare uden videre læse den kommasep. fil ?
jasma -> Vi betragter en ekstern database (SQL, Oracle) som en bedre løsning idag, da det jo er nemmere at arbejde med og overføre til andre ting. Begrundelsen for at ligge det over i en anden DB ville være at så skulle vi ikke håndtere synkroniseringsproblemet.
7-8 timer..også hvis man er total nybegynder til XAL ? Vi har fået fat i en programmeringsmanual til 3.5, men det er jo 2.6 vi arbejder med. Vi ved ikke hvor meget der har ændret sig. Desuden kan det vel også være at dem der har lavet den grafiske overbygning har låst XAL'en, så vi ikke kan udvilke på den ?
Ja ok, 7-8 timer er for en erfaren XAL-programmør, desværre. Men det er svært at tidbestemme mere nøjagtigt når man ikke kender alle detaljerne. "Et skærmbillede med generelle ordreoplysninger" og "Når ordren kommer ind er alle informationer ikke til rådighed" siger jo ikke ret meget om detaljerne.
mariaf : "Ja se det er jo en anden sag. Men det ændrer ikke at I vil bruge hardwaren som "undskyldning" for at lave en løsning, som allerede er standard. I vil dumpe på det."
Nu skal det ikke dreje sig om dette, men normalt analysere man virksomheden for at finde ud af hvad passer bedst til dem. Det er en selvfølge af hvis det kommende system besværligøre arbejdsgange o.l. bliver det ikke brugt. Det er jo bevidst at hvis folk skal til at gå efter noget (f.eks. opslag på en Windows maskine), bliver det udskudt eller ikke gjort. At bruge ordet "undskyldning" fatter jeg simpelthen ikke, da det er virksomhedens bedste man skal have for øje. Ellers er det jo dig selv der ender med en "undskyldning"... ----------------- Vi undersøger muligheden for at opgraderer til den nyeste version af XAL og derved bruge den eksterne database. Med denne skulle det være let at kontakte en evt java applikation.
wilco : du skriver at man bare skal installere sql versionen ? kan du ikke lide uddybe det, da jeg ikke helt forstår det.
Man skal vel sikre at XAL versionen har et SQL modul (er det det du mener ?) Men man skal vel også konveretere selve dataerne fra native til MSSQL ? Og kan det passe det er så let, når der er firmaer der har specialiseret sig i denne proces ?
Der findes idag 3 forskellige XAL kerner. cxalw32 (native), oxalw32 (Oracle) , sxalw32 (Mssql) (hvis jeg husker rigtigt)
De fleste mindre virksomheder starter på cxalw32 og når de så skifter op til en "sql" version, gør man det at man installerer en ny version f.eks. oxal kernen til oracle.
Du har naturligvis ret i at Oxal kernen ikke er gratis.
og jo - jeg må beklage det er den, af Navision godkendte måde. :)
essencen er at data modelen jo ikke ændre sig, det er "blot" database handleren neden under. Det man gør gavn af her er at det er Navisions egen export/import og ikke et specielt program fra hverken Oracle eller MS.
dog var wilco også meget behælpsom..håber det stille alle tilfredse
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
