Workiva supportcenter

I dynamiska integrationer, särskilt när HTTP-anslutningar används i automatiserade arbetsflöden (t.ex. Chains), är det viktigt att hantera svaret från ett API-anrop på ett effektivt sätt. Output Parameters gör det möjligt för användare att samla in viktiga delar av data som returneras av API:et - t.ex. svarskropp, svarshuvuden och statuskod - så att dessa data kan användas i senare steg.

Vilket problem löser detta?

Utgångsparametrar är avgörande för att skapa responsiva och intelligenta arbetsflöden.

• Dynamiska arbetsflöden: Utdataparametrar gör det möjligt att skräddarsy vad som händer härnäst baserat på vad API:et returnerar - till exempel extrahera en token, kontrollera om en post finns eller bekräfta en lyckad operation.
• Automatisering: Genom att fånga värden automatiskt slipper användarna manuell inmatning eller hårdkodning, vilket gör att arbetsflödena kan skalas upp med mindre underhåll.
• Strömlinjeformade integrationer: Att ansluta system som autentiseringsservrar, CRM eller anpassade API:er blir mer sömlöst eftersom anslutningen anpassas utifrån de data den tar emot.

Vem påverkas av detta?

• Utvecklare och integratörer: De som bygger automationskedjor eller integrationer mellan system.
• Dataanalytiker: De som förlitar sig på korrekta dataflöden i realtid för att driva instrumentpaneler eller rapportering.
• Systemadministratörer: De som underhåller och felsöker integrationer - att ha tillgång till utdataparametrar hjälper till att snabbt hitta problem.

Vad är utdataparametrar?

Utdataparametrarna i en HTTP Connector används för att definiera förväntade utdata för en HTTP-begäran, t.ex. svarshuvuden, svarskropp eller svarskod. Dessa definierar det förväntade resultatet av en HTTP-begäran, som sedan kan återanvändas i efterföljande noder eller logiksteg i en kedja.

Exempel Utgångsparametrar:

• Svarsrubriker: Metadata som innehållstyp, server eller status för hastighetsbegränsning.
• Response Body: Det faktiska innehåll som returneras av API:et - vanligtvis i JSON- eller XML-format.
• Svarskod: Indikerar framgång (200), klientfel (400), serverfel (500), etc.

Exempel: Fånga upp ett åtkomsttoken

Anta att ett API returnerar en token så här:

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

Du kan definiera access_token som en utdataparameter och sedan skicka den vidare till nästa steg (t.ex. för att autentisera ett annat API-anrop).

Varför behövs svarsorganet?

Svarskroppen är vanligtvis den del där API:et returnerar den viktigaste informationen. Dessa kan omfatta, men är inte begränsade till:

• ID för nyligen skapade poster
• Autentiserings-tokens
• Frågeresultat eller datapayloads

Om du inte har tillgång till svarskroppen är du begränsad till metadata, vilket begränsar hur dynamiskt ditt arbetsflöde kan vara. 

Vi kan nu få access_token tillgänglig under rullgardinsmenyn Response.

Vanliga felhanteringsscenarier

Typiska problem som du kan stöta på när du arbetar med Output Parameters:

• Fel: odefinierad utdataparameter

  Orsak och åtgärd: Svarsstrukturen har ändrats eller är kapslad. Bekräfta att JSON-sökvägen till fältet är korrekt.

• Fel: 401 Obehörig

  Orsak & åtgärd: Token saknas eller har löpt ut. Se till att token fångas upp och skickas på rätt sätt.

• Fel på: 500 Internt serverfel

  Orsak och åtgärd: Serverproblem eller ogiltig nyttolast för begäran. Kontrollera svarstexten för mer information.

• Felmeddelande: Ogiltig JSON

  Orsak och åtgärd: API:et returnerar ett felaktigt svar. Använd ett Try-Catch-block eller validera utdata före parsning.

Vad är en Bearer Token och varför behövs den?

En Bearer Token är en typ av access-token som används i OAuth 2.0-autentisering. Den auktoriserar en användare eller applikation att få tillgång till ett API. Det kallas "Bearer" eftersom du "bär" token i rubriken för din HTTP-begäran.

Exempel på rubrik:

Auktorisering: Bearer <access_token&gt

Denna token är säkrare än grundläggande autentisering eftersom:

• Den upphör att gälla, vilket minskar risken för tokenläckage.
• Den kan bära kikarsikten och behörigheter.
• Den skiljer autentisering från auktorisering.

Varför inte bara använda Basic Authentication?

Medan Basic Auth skickar ett användarnamn och lösenord kodat i varje begäran, skickar den:

• Är mindre säker - referenser kan återanvändas eller fångas upp.
• Kan inte enkelt upphöra eller omfatta åtkomst.
• Saknar tokenbaserad behörighetskontroll.

Bearer-tokens har stöd för tokenutgång, uppdatering och granulerade behörigheter, vilket gör dem till ett bättre val för moderna API:er och säkerhet i företagsklass.