Workiva kundestøttesenter

I dynamiske integrasjoner, spesielt ved bruk av HTTP-kontakter i automatiserte arbeidsflyter (for eksempel Chains), er det avgjørende å håndtere svaret fra et API-anrop på en effektiv måte. Med Output Parameters kan brukerne fange opp viktige deler av dataene som returneres av API-et - for eksempel svartekst, svarhoder og statuskode - slik at disse dataene kan brukes i senere trinn.

Hvilket problem løser dette?

Utgangsparametere er avgjørende for å skape responsive og intelligente arbeidsflyter.

• Dynamiske arbeidsflyter: Utdataparametere gjør det mulig å skreddersy hva som skjer videre basert på hva API-et returnerer - for eksempel å hente ut et token, sjekke om det finnes en post eller bekrefte en vellykket operasjon.
• Automatisering: Ved å registrere verdier automatisk unngår brukerne manuell inntasting eller hardkoding, slik at arbeidsflytene kan skaleres med mindre vedlikehold.
• Strømlinjeformede integrasjoner: Tilkobling av systemer som autentiseringsservere, CRM eller egendefinerte API-er blir mer sømløs fordi koblingen tilpasser seg basert på dataene den mottar.

Hvem påvirker dette?

• Utviklere og integratorer: De som bygger automatiseringskjeder eller integrasjoner mellom systemer.
• Dataanalytikere: De som er avhengige av nøyaktige datastrømmer i sanntid for å kunne bruke dashbord eller rapportering.
• Systemadministratorer: De som vedlikeholder og feilsøker integrasjoner - tilgang til utdataparametere gjør det enklere å finne problemer raskt.

Hva er utgangsparametere?

Utgangsparametrene i en HTTP Connector brukes til å definere de forventede utdataene fra en HTTP-forespørsel, for eksempel svarhoder, svartekst eller svarkode. Disse definerer de forventede resultatene av en HTTP-forespørsel, som deretter kan gjenbrukes i påfølgende noder eller logiske trinn i en kjede.

Eksempel på utgangsparametere:

• Svaroverskrifter: Metadata som innholdstype, server eller status for hastighetsbegrensning.
• Response Body: Det faktiske innholdet som returneres av API-et - vanligvis i JSON- eller XML-format.
• Svarkode: Angir om det var vellykket (200), klientfeil (400), serverfeil (500) osv.

Eksempel: Innhenting av et tilgangstoken

Anta at et API returnerer et token som dette:

{ "token_type": "Bearer", "expires_in": 600, "access_token": "<access_token_string>", "scope": "graph:write graph_api|r permissions|w ..." }

Du kan definere access_token som en utgangsparameter, og deretter sende den videre til neste trinn (f.eks. for å autentisere et annet API-anrop).

Hvorfor er det behov for et responsorgan?

Det er vanligvis i svarteksten at API-et returnerer den viktigste informasjonen. Disse kan omfatte, men er ikke begrenset til:

• ID-er for nyopprettede poster
• Autentiseringstokener
• Søkeresultater eller datanyttelast

Uten tilgang til svarteksten er du begrenset til metadata, noe som begrenser hvor dynamisk arbeidsflyten din kan være. 

Vi kan nå få tilgang til access_token tilgjengelig under rullegardinmenyen Response.

Vanlige feilhåndteringsscenarier

Typiske problemer du kan støte på når du arbeider med Output Parameters:

• Feil: udefinert utgangsparameter

  Årsak og løsning: Svarets struktur har endret seg eller er nestet. Bekreft at JSON-banen til feltet er riktig.

• Feil: 401 Uautorisert

  Årsak og løsning: Token mangler eller er utløpt. Sørg for at tokenet fanges opp og sendes på riktig måte.

• Feil: 500 Intern serverfeil

  Årsak og løsning: Serverproblem eller ugyldig nyttelast for forespørselen. Sjekk svarteksten for mer kontekst.

• Feil: Ugyldig JSON

  Årsak og løsning: API-et returnerer et feilformet svar. Bruk en Try-Catch-blokk, eller valider utdataene før parsing.

Hva er et Bearer Token, og hvorfor er det nødvendig?

Et Bearer Token er en type tilgangstoken som brukes i OAuth 2.0-autentisering. Den autoriserer en bruker eller et program til å få tilgang til et API. Det kalles "Bearer" fordi du "bærer" tokenet i headeren til HTTP-forespørselen din.

Eksempel på overskrift:

Autorisasjon: Bearer <access_token&gt

Dette tokenet er sikrere enn grunnleggende autentisering fordi:

• Den utløper, noe som reduserer risikoen for tokenlekkasjer.
• Den kan bære omfang og tillatelser.
• Den skiller autentisering fra autorisasjon.

Hvorfor ikke bare bruke Basic Authentication?

Mens Basic Auth sender et brukernavn og passord kodet i hver forespørsel, sender den:

• Er mindre sikker - legitimasjon kan gjenbrukes eller avlyttes.
• Kan ikke enkelt utløpe eller begrense tilgangen.
• Mangler tokenbasert kontroll av tillatelser.

Bearer-tokens støtter tokenutløp, oppdatering og detaljerte tillatelser, noe som gjør dem til et bedre valg for moderne API-er og sikkerhet på bedriftsnivå.