Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

Initiesering av flyt

scheduled Polling

Flyt mønster

Bruk av meldingskø

Nei

Open API

Nei

 

IntArk

Ikke brukt

 

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.

Systemer/tjenester

  • 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 (nedepunkter)

Config-databasen

Henter organisasjoner fra databasen (configDb.org-samling) som har aktiv miljøverdi (i.e. lister over alle institusjoner med UBWLOgiq.<env>.aativ satt til “true”). Felt som skal hentes fra hvert dokument er: organisasjonsnavn (det blir referert til som ShortName), AgressoClientCode(“TF", “HS” eller “MF”), templateIdog engineId (dette feltet er forskjellig i hvert miljø for organisasjonen).

MongoDatabase (getOrgs)

Config-databasen

Henter svartelistefilter (i henhold til module-id) som skal brukes i Slack-connector. Denne listen/arrayen med data bygges opp manuelt for hver app separat for å ignorere visse feil som oppstår i prosessen, enten de må ignoreres eller rapporteres til en kanal (i henhold til miljøet de bruker)

MongoDatabase (getSlackBlacklist)

Logiq

Dette vil be om token fra Logiq-endepunkt (grant_type, username, password (for tilsvarende miljø), scope, client_id og client_secret (for tilsvarende miljø), og det vil bli brukt når data sendes til Logiq-endepunktene (for å legge til ny leverandør, og fakturareferanser).

API kall mot Logiq: HTTP request (POST: logiq-token-host/auth/realms/document-control/protocol/openid-connect/token)

Logiq

Sender transformert datasett (inkludert engineId, receiverOrgno, receiverName, distribution, engineId, og noen statiske datastrenger som template, channel, active, created, updated, templateId og channelId) til Logiq-endepunkt.

API kall mot Logiq: HTTP request (POST: logiq-host/message/api/1.0/customer/configuration

Logiq

Sender transformert datasett (inkludert engineId, referenceValue, receiverName, og noen statiske datastrenger som referenceType, organizationNumber, referenceAlternative, referenceNumberFrom, referenceNumberTo, referenceRegEx og senderOrganizationNumber) til Logiq-endepunkt.

API kall mot Logiq: HTTP request (POST: logiq-host/reference/api/1.0/update-references)

Slack

Sender feilmeldinger (inkludert også data på module-idog submodul, organisasjons shortName, path osv.)

Slack-kanalen (mule-prod)

LaaS

Projiserer auditInfoMap til Humio (LaaS) i henhold til module-id og env

do Index

UBW

Henter leverandører med e-post (og gitt tilganng til bruker lqapi). Dataene hentet fra databasen (ShortName, AgressoClientCode, templateIdog engineId) brukes her som nyttelast. AgressoClientCode brukes har også som companyId. De hentede dataene vil senere bli overført til et nytt format og kombinasjon som sendes til Logiq-endepunket.

API kall mot UBW: HTTP request (GET: https://prd-svc.ubw.unit.no/UBWShortName-web-api/v1/objects/logiqeposts")

UBW

Henter fakturareferanser (her er det attributeValue som er fakturareferansen). URI-parametere er statiske strenger, "attributeId": "XB01" og "status": "N" (bortsett fra companyId som tilsvarer AgressoClientCode i databasen). Disse dataene vil også bli transformert til et nytt format og en ny kombinasjon som sendes til Logiq-endepunket.

API kall mot UBW: HTTP request (GET: https://prd-svc.ubw.unit.no/UBWShortName-web-api/v1/objects/attribute-values?filter=attributeId%20eq%20'XB01'%20and%20status%20eq%20'N'")

  • Hvilken kø-mekanisme brukes evt.?

  • Om Int-ark komponenter er brukt og eventuelt hvilke deler

Data

  • Hvilke data utveksles?  Alle attributter som utveksles?

Samhandlingsmønster

  • Hva driver utvekslingen? Request eller Push

  • Er utvekslingen synkron eller asynkron?

Om involverte API

  • Brukte API endepunkter

Tilgangsstyring og logging

  • Hva logges?

  • Eventuelle tilgangstyring

Forretningsregler

  • Forretningslogikken i integrasjonen. Feks. Bare dokumenter med status X leses etter Y antall dager osv …

Behandlingstid/responstid og volum

  • Hva er antallet meldinger pr. døgn i denne forbindelsen (Min, Avg, Max)

Feilhåndtering, konsekvenser av feil og overordnet risikoanalyse

  • Hva skjer ved overload i kø?

  • Hva skjer med ufullstendinge meldinger?

  • Inneholder meldingene personopplysninger?

  • 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.

Flytdiagram ?

Kommentarer

Lenken

 link to ubw-tjenester

/wiki/spaces/IPM/pages/274399317

  • No labels