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.
Initiesering av flyt | scheduled Polling | |
|---|---|---|
Flyt mønster | ||
Bruk av meldingskø | Nei | |
Open API | Nei |
|
IntArk | Ikke brukt |
|
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.
Dette er en leveranse til Unit4 ERP (416002). Kostnadene deles derfor mellom disse 2.
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.
System | Data | Brukt API (endepunkter) |
|---|---|---|
Config-databasen | Henter organisasjoner fra databasen (configDb.org-samling) som har aktiv miljøverdi (i.e. lister over alle institusjoner med | MongoDatabase (getOrgs) |
Config-databasen | Henter svartelistefilter (i henhold til | MongoDatabase (getSlackBlacklist) |
LaaS | Projiserer auditInfoMap til Humio (LaaS) i henhold til | do Index |
Logiq | Dette vil be om token fra Logiq-endepunkt ( | API kall mot Logiq: HTTP request (POST: |
Logiq | Sender transformert datasett (inkludert | API kall mot Logiq: HTTP request (POST: |
Logiq | Sender transformert datasett (inkludert | API kall mot Logiq: HTTP request (POST: logiq-host/reference/api/1.0/update-references) |
Slack | Sender feilmeldinger (inkludert også data på | Slack-kanalen (mule-prod) |
UBW | Henter leverandører med e-post (og gitt tilganng til bruker lqapi). Dataene hentet fra databasen ( | API kall mot UBW: HTTP request (GET: https://prd-svc.ubw.unit.no/UBW |
UBW | Henter fakturareferanser (her er det attributeValue som er fakturareferansen). URI-parametere er statiske strenger, | API kall mot UBW: HTTP request (GET: https://prd-svc.ubw.unit.no/UBW |
Hvilken kø-mekanisme brukes evt.?
Scheduler
Schedule Strategy: “cron>Everyday” i begge miljøene
Int-ark komponenter er ikke brukt
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
Hva driver utvekslingen?
HTTP-Request 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®
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’.
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’
Forretningslogikken i integrasjonen.
Bare dokumenter med ‘active’-status “true” leses hver dag
Behandlingstid/responstid: ca. 22~47s
Frekvens: kjører en gang om dagen
Volum (målt: ): 54 hits daglig
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):
organisasjoner som ikke er klare settes til active:true manuelt ved en feiltakelse.
Lenken |