Page Comparison

...

Innledning

Dette er en enveis integrasjon mellom Unit4 ERP (UBW) og Logiq® dokumentkontroll. Den henter data fra UBW, gjør riktige transformasjoner (som en integrasjonsprosess ville gjort), og sender dem til Logiq® endepunkt.

Nøkkel info

Bakgrunn

Logiq dokumentkontroll stopper faktura med feil før de legges inn i Unit4. Om feil på faktura stoppes de, og leverandør får epost med link til retting av faktura i Logiq sin portal. Overføring av leverandør e-post adresser og begrepsverdi for bestiller referanser fra Unit4 ERP til Logiq. Data hentes fra institusjonene med standart Unit4 API og pushers videre til Logiq ved å kalle Logiq dokument kontroll API. Vil medføre besparelser for institusjonene vedrørende behandling av innkommende fakturaer.

Interessenter

Dette er en leveranse til Unit4 ERP (416002). Kostnadene deles derfor mellom disse 2.

Brukerhistorie

Det er to API-kall mot UBW, det ene er for å hente ‘leverandører med e-post’ og det andre er for ‘fakturareferanser’. Disse dataene vil deretter bli transformert og overført til to Logiq-endepunkter  for å legge til ny leverandør eller å liste referanser.

...

• Involverte systemer er ganske rett frem. Som forklart er det en enveis integrasjon, fra punkt A som er UBW til målsystemet, som er Logiq. Tabellen nedenfor kan forklare hvilke data som hentes fra kilden (ved hjelp av endepunkter) og, etter transformering av formatet, vil bli overført til målsystemet, gjennom tredjeparts endepunkt.

...

• Hvilke data utveksles? 

  • Det er to sett med data:

    • De som er samlet inn fra databasen vår (tre felt for hvert miljø: active og engineId er/kan være forskjellige i hver miljø, men templateId er vanlig blant miljøene),

    • Og de hentet fra UBW API (separat for to forskjellige prosesser: ‘leverandør med e-post’ og 'fakturareferanser')

• Alle attributter som utveksles ?er detaljert i flytdiagrammet lenger nede

Samhandlingsmønster

• Hva driver utvekslingen?

  • HTTP-Request

  eller Push

  • fra UBW (https://prd-svc.ubw.unit.no/UBW)/GET

  • HTTP-Request fra LOGIQ (til å få token eller legger til ny leverandør/fakturareferans)/POST

• Er utvekslingen synkron eller asynkron?

  • Utvekslingene gjøres etter hverandre: først ‘access token’, så overføring av leverandører med e-post data fra UBW til Logiq® og deretter overføring fakturareferanser fra UBW til Logiq®

Om involverte API

• Brukte API endepunkter er UBW og Logiq: data og endepunkter er detaljert i ‘Systemer/tjenester' (rad 4 til 6 og 8 til 9), og prioriteringer er avbildet i avsnitt 'Flytdiagram’.

Tilgangsstyring og logging

• Hva logges?

  • bortsett fra logger som viser fremdrift av handlingen (hvilket ‘Step’ som håndteres, hvilken organisasjon/ShortName eller miljø/env), avslutter og oppsummerer en *** FERDIG *** TransferSummary:-logger prosessen. Den teller antall innkommende organisasjoner og sammenligner det med antallet "SUCCESS" mottatt under prosessen for å vise den generelle suksessen til prosessen (“PASS” for generell suksess og "FAILED" for ufullstendig overføring). For hver organisasjon teller den antall overførende dokumenter og evaluerer status for prosessene separat i medEpost og fakturareferanser. Hvis begge fungerte vellykket, oppdaterer den status som "ALT ER OK!", ellers indikerer statusen “OVERFØRING AV DATA MISLYKTES” og den generelle statusen blir til "FAILED".

• Eventuelle tilgangstyring: admin kan trigge flyten gjennom mulesoft-Runtime Manager> ‘schedules'> 'Run now’

Forretningsregler

• Forretningslogikken i integrasjonen. Feks.

  • Bare dokumenter med ‘active’-status

  X leses etter Y antall dager osv …

  • “true” leses hver dag

Behandlingstid/responstid og volum

• Hva er antallet meldinger pr. døgn i denne forbindelsen (Min, Avg, Max)Behandlingstid/responstid: ca. 22~47s

• Frekvens: kjører en gang om dagen

• Volum (målt: 04 Oct 2023): 54 hits daglig

Feilhåndtering, konsekvenser av feil og overordnet risikoanalyse

• Hva skjer ved overload i kø?

• Hva skjer med ufullstendinge meldinger?

  • resultatet i TransferSummary viser hvilken prosess for hvilken organisasjon som mislyktes. Prosessen vil ikke stoppe, og andre deler (medEpost eller/og fakturareferanser for ShortName) vil kjøre og bli evaluert separat.

• Inneholder meldingene personopplysninger?

  • Ja; receiverName, e-post og companyRegNo

• Noe om viktige feil/situasjoner som må passes ekstra på (som kan ha stor konsekvens). F.eks : Oppgavene som aldri vil publiseres, eller Oppgaver som ikke skal publiseres, publiseres.

...

• :

  • organisasjoner som ikke er klare settes til active:true manuelt ved en feiltakelse.

Flytdiagram

Kommentarer

...