Veierland, 21. mars 2021
Endret 18. august 2021
EDI-klokka
Jeg skrev litt om versjon 15 da den kom omkring St.Hans i fjor. Og januar i år kom versjon 15.10. Jeg har ligget litt etter; har jobbet mye med en spennende kunde med høyt transaksjonsvolum. En dag skal jeg skrive litt mer om det.
Det er mange ulike importmetoder i Visma Business (VBus). En av de eldste er med EDI-klokka. Laget først og fremst for å lese inn ordre fra annet system. Mange har en egen WebShop hvor kunder kan bestille varer og så lager WebShop’en en EDI-melding til VBus som leses inn med EDI-klokka. Jeg har skrevet generelt om EDI tidligere, så jeg skriver ikke mer om det nå.
Et problem med EDI-kokka er at den kjøres av en bruker. Det er et eget menyvalg i nedtrekk-menyen ved siden av Importer-knappen helt til venstre for å starte og stanse EDI-klokka. Her kan man angi hvor lang tid det skal ta mellom hver gang VBus skal lete etter og lese inn nye EDI-meldinger. VBus leter i en mappestruktur under en filsti som er angitt i systemopplysninger i feltet EDI-sti. Når EDI-klokka startes oppretter VBus en firma-mappe for hvert firma med navn på fem tegn eller mer på formen Fxxxx (hvor xxxx er firmanummer, minst 4 siffer – om nødvendig med innledende 0 – f.eks. F0001). Dersom det i systemopplysninger også er krysset av i feltet EDI-mapper opprettes en mappe for hver type melding som kan leses inn; IMPORTS (standard importfiler), ORDERSR (nye ordre), ORDCHGR (ordreendringer), INVIOCER (fakturaer til bunt og bilag), QUOTESR (tilbud), DIRDEBR (bunt med bilag). Det er en feil i hjelpeteksten hvor det står at meldingene i IMPORTS-mappa leses inn etter alle de andre meldingene (for samme firma), men dette ble endret i versjon 14.01.0 og jeg husker hvorfor: Nye kunder kan leses inn med en ORDERSR-melding, men ikke endringer. Endinger i kundeopplysninger kan leses inn med en standard importfil (fra IMPORTS) og siden det er felt som kopieres fra kunde til ordre, men som ikke kan leses inn med en ORDERSR-melding – så bør IMPORTS-filene leses inn før de andre. EDI-klokka oppretter to mapper til; CREAPPR (aktiviteter) og PARTINR (aktører), men de brukes ikke til noe.
Men tilbake til problemet med at EDI-klokka kjøres av en bruker. Det betyr at denne brukeren blir avbrutt hver gang det leses inn en eller flere EDI-meldinger. Og når brukeren logger seg av så stanser også EDI-klokka. Derfor har de fleste satt opp EDI-klokka til å kjøre i bakgrunn (av en tidsstyrt oppgave, gjerne på en server). Det gir to problemer. Det første er at om man importerer standard importfiler, så kan de dukke opp en dialogboks med en advarsel eller bare en beskjed til bruker – og så er det ingen der til å klikke på [OK]-knappen slik at EDI-klokka går videre. Og dermed står EDI-klokka og det tar som regel noe tid før noen oppdager at EDI-meldingene ikke lenger leses inn. EDI-klokka har fått et ganske frynsete rykte på grunn av dette. I 2015 foreslo jeg (ticket 34322) at det ble tatt inn en mulighet for å kjøre EDI-klokka uten meldinger i dialog, at meldingen heller ble skrevet til tabellen EDI-feilmelding. Senere kom jobbplanleggeren i VBus og det har blitt mulig å gjøre oppgaver med jobbplanleggeren som ellers roter det til for EDI-klokka. Men ikke alle. Det er for eksempel ikke mulig å utføre Lagre om med jobbplanleggeren noe jeg foreslo (ticket 1260357) i 2019. De som bruker Reservasjon ved lagring, bør gjennomføre Lagre om i prinsippet etter hvert varemottak, særlig om man også har avgrenset reservasjonen til å være innenfor leveringstiden. Da er det fristende å sette opp EDI-klokka til å Lagre om slik at reservasjon kan skje. Men så er det det ulykksalige da at Lagre om av og til kommer med en tilbakemelding. Og så er det full stans i EDI-klokka.
Det andre problemet med å kjøre EDI-klokka i bakgrunn, er at man må legge brukernavn og passord inn som oppstart-parameter sammen med /EDI. Det er ett sikkerhetsproblem. Så kan man hevde at om noen som ikke skal ha tilgang til VBus, har klart å logge seg inn på applikasjonsserver – så har man så allikevel et sikkerhetsproblem.
Personlig mener jeg at det største problemet med å kjøre EDI-klokka i bakgrunnen, er at man ikke ser meldingene som eventuelt dukker opp og at den eneste måten å stanse EDI-klokka på er å logge seg på den serveren hvor VBus-sesjonen går og avslutte Windows-sesjonen. Det er mulig å se hvilken sesjon i VBus som kjører EDI-klokka; det fremgår av Sesjonstype i tabellen Aktive sesjoner. Og den som er Systemansvarlig i VBus kan stanse VBus-sesjonen slik at en annen bruker kan starte EDI-klokka. Men dette avslutter ikke Windows-sesjonen som i utgangspunktet kjørte EDI-klokka. Og denne holder på EDI-loggfilen. Så for å få startet EDI-klokka hos en ny bruker uten å avslutte Windows-sesjonen, må man bruke en annen EDI-loggfil. I og for seg enkelt nok, men plundrete. De fleste forhandlere har laget løsning for automatisk restart av EDI-klokka med jevne mellomrom (enten det er hver natt eller hver time) slik at den også knerter den gamle Windows-sesjonen. Strengt tatt ikke nødvendig siden man med Task Scheduler kan starte VBus med EDI-klokka f.eks. kl. 05:00 hver morgen og sette at den skal kjøre i 18 timer. Da vi Windows avslutte VBus-sesjonen (og med den EDI-klokka) kl. 23:00. Og så kan vedlikeholdsjobber som backup og liknende gå uten at noen EDI-import skjer samtidig.
Men det er altså det å kunne stanse EDI-klokka utenom plan når den går i bakgrunnen som det ikke er noen god løsning på. Jeg foreslo for Visma (ticket 1260355) i 2019 følgende:
Svært mange av de som bruker EDI-klokka har satt opp en tidsstyrt oppgave på en server som starter denne på gitte tidspunkt. Så hender det at EDI-klokka stanser; noen ganger fordi det dukker opp en melding med en [OK]-knapp som ingen klikker på - eller bare at VBus går ned. Og det hender at bruker har behov for å stanse EDI-klokka, men da må man inn på rett server og finne rett instans i Windows etc. EDI-klokka har et ufortjent rufsete rykte fordi det for brukere er så vanskelig å kontrollere den, når den går i bakgrunn på en server.
Jeg ønsker meg en mulighet for å kjøre EDI-klokka fra Jobb-planlegger i VBus. Og å kunne stanse den. Slik at en jobb kan være å starte den hver virkedag kl. 06:00 og stanse den kl. 22:00.Meldinger som kommer opp på skjermen på en vanlig sesjon kan plasseres i tabellen EDI-feilmelding.
Dette vil være en hjelp for alle som bruker EDI-klokka og gi bedre kontroll med den.
Svar fra Visma: Redd for at dette ikke lar seg gjøre av to grunner
Det ene er at vi nok må regne med at EDI klokka, slik den ser ut i dag, ikke vil kunne fungere i all fremtid. Metodene er gamle, og sikkerhetsmessig antar vi at det på sikt ikke vil være ønskelig å vedlikeholde denne funksjonen. - det anses som mer riktig å bruke tid på å tilgjengeliggjøre VBS for de oppgavene som pr i dag gjøres via EDI klokka.
Det andre går på at jobbplanleggeren i dag kjører innen rammen av en sesjon, mens EDI biten vil kreve ganske omfattende endringer i dette. Ut fra signalene vi har pr i dag, ønsker en heller å benytte ressurser på å utvide tilbudet av jobber innenfor eksisterende rammer.
Jeg har sagt til mine kollegaer at den dagen Visma pensjonerer EDI-klokka, gjør jeg det samme. Men så kom det i versjon 15.10 en mulighet for å importere EDI-filer med jobbplanleggeren! Og det fungerer glimrende. Det er riktignok slik at man må angi enten bedriftsnummer eller bedriftsgruppe, men det er helt OK. Standard intervall med EDI-klokka er 15 sekunder. Det er altfor kort intervall om det skal leses inn meldinger til mange firma. Korteste intervall med jobbplanleggeren er ett minutt. Litt irriterende at det kommer en loggføring av hver gang jobbplanleggeren har sett etter EDI-meldinger å lese. Har du satt opp jobbplanleggeren til å se etter EDI-filer hvert minutt og det til 10 firma, så dukker det opp 15.000 loggføringer i døgnet. Helt unødvendig. Det kunne greid seg om loggingen var begrenset til de gangene det faktisk ble behandlet noe, men det er en underordnet problemstilling. Det viktigste er at det nå har blitt enkelt stanse importen uten å måtte finne ut hvilken server EDI-klokka går på og deretter hvilken Windows-sesjon som skal knertes.
Men merk at ikke alle menyvalg er tilgjengelig. Dersom det ligger en standard importfil i IMPORTS-mappa som inneholder et behandlingsvalg som ikke er implementert i jobbplanleggeren – slik som Lagre om – så slettes EDI-filen (som tegn på at den er innlest), men det er ingen advarsel om at behandlingsvalget ikke er gjennomført. Dersom du setter opp en egen jobb for Lagre om, så får du en feilmelding med Feilkode 28 [Utførelsen feilet i behandling som ikke er oppgradert til nytt mønster] med den noe klarere Melding: This processing is not exposed to Visma Business Services. I versjon 16.10 er det åpnet for Lagre om med jobbplanleggeren. Se for øvrig Oversikt over behandlingsvalg som kan benyttes i jobbplanleggeren.
Jeg tenker at om du har EDI-import med EDI-klokka, så har du nå en god grunn til å oppgradere til versjon 15.10.
Hvis du har EDI-meldinger med mer enn 2 desimaler (etter komma) i antall og starter EDI-kokka med Task Scheduler i Windows (som på godt norsk heter Oppgaveplanlegger) – så bør du vite at det er en feil i versjonene fra 14.10 til 17.10; Antall får bare to desimaler etter komma. Denne feilen er ikke i versjon 14.01 og er rettet i versjon 18 uten at det er nevnt med en stavelse i releasenotes. Løsningen er enten å oppgradere til versjon 18 eller lese inn EDI-meldingene med jobbplanleggeren til VBus.
Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg
Frode Antun
Løsningsrådgiver
m: + 47 911 46 751
a: Smeltedigelen 1, 0195 Oslo