I den här artikeln hittar du vad du bör och inte får göra när du skickar in en API-supportticket. Utöver det förklarar vi hur du kan skicka in en sådan ticket.
Hur du skickar in en API support ticket
När du skickar in en API-supportticket är det viktigt att välja rätt ärendeformulär, nämligen att välja typen "Integrationspartner".
Att göra och inte göra när du skapar en API-supportticket
Målet med den här artikeln är att ge tydliga riktlinjer för bästa praxis när du skapar en API-biljett. Att rapportera ett problem i Nmbrs-gränssnittet skiljer sig från att rapportera ett problem i API:t och vi vill göra kommunikationen så smidig som möjligt med våra kunder.
Gör
- Ange alla parametrar som används i anropet som har problem
- Bifoga Nmbrs applikationsskärmdumpar för att bättre förklara vad som är problemet, när det är möjligt.
- Dela det exakta felmeddelandet.
- Precisera exakt det problem ni stöter på
Gör inte
- Använd inte generiska meningar som beskrivning
- Bifoga inte bilder från andra applikationer än Nmbrs
- Skicka inte loggar som genereras av integrationspartnerapplikationen
Ange alla parametrar som används i anropet som har problem
Låt oss till exemepel överväga anropet: Address_GetList: den tillhandahåller tre parametrar i rubriken och tre parametrar i brödtexten. Därför skulle det bästa vara att specificera alla dessa parametrar när du skapar en ticket (förutom token, på grund av säkerhetsskäl).
- Användarnamn
- Domän
- Anställd ID
- Period
- År
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Header>
<AuthHeaderWithDomain xmlns="https://api.nmbrs.nl/soap/v3/EmployeeService">
<Username>string</Username>
<Token>string</Token>
<Domain>string</Domain>
</AuthHeaderWithDomain>
</soap:Header>
<soap:Body>
<Address_GetList xmlns="https://api.nmbrs.nl/soap/v3/EmployeeService">
<EmployeeId>int</EmployeeId>
<Period>int</Period>
<Year>int</Year>
</Address_GetList>
</soap:Body>
</soap:Envelope>
Bifoga Nmbrs-skärmdumpar för att bättre förklara vad som är problemet, när det är möjligt
Vi hade till exempel en bugg i anropet Contract_GetAll_AllEmployeesByCompany vilket inte gav tillbaka alla kontrakt per anställd.
För att bättre förklara problemet tillhandahöll användaren en skärmdump av kontrakten i användargränssnittet och en av vad som returnerades av API:et. Eftersom han också tillhandahöll domänen och Anställd ID som saknade data, kunde vi enkelt identifiera, replikera och sedan snabbt åtgärda felet.
Om du får ett felmeddelande, dela exakt vad det står
Många olika felmeddelanden kan returneras av Nmbrs API. Till exempel, när du gjorde ett anrop, returnerades resultatet nedan.Vi har en artikel med Nmbrs API error codes. Genom att gå igenom den här artikeln är det väldigt lätt att se vad problemet är och hur man åtgärdar det.
Oväntade felmeddelanden kan dyka upp, och om så är fallet bör en ticket skapas. Glöm inte att berätta exakt vilket felmeddelande som returneras och till ange alla parametrar som används i samtalet som har problem.
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Server was unable to process request. ---> 2004: Unauthorized access</faultstring>
<detail />
</soap:Fault>
</soap:Body>
</soap:Envelope>
Var exakt på det problem du har
Om du till exempel har problem med att hämta data om Schema, nämn specifikt vilka anrop som inte fungerar som förväntat. För närvarande har vi fyra olika anrop för att returnera schemadata:
För bättre och snabbare svar från både supporten och utvecklingsteamet är det viktigt att nämna exakt vilka av samtalen du använder som inte ger det förväntade resultatet.
Om du inte kan mycket om API:er, be om hjälp från ditt tekniska team för att kunna tillhandahålla all information som behövs
Det är svårt att förklara vad problemet är om du aldrig har sett ett API-anrop eller inte vet hur de fungerar. För att underlätta kommunikationen är det mycket användbart att begära mer information från ditt tekniska team. Kom alltid ihåg att to Provide all parameters used in the call that is having problems.
Använd meningar som "API fungerar inte", "API är långsam", etc. Vi behöver veta i vilka anrop du har problem!
Meningar som ovan är väldigt generiska. För närvarande har vi 200+ anrop på API:t och det är viktigt att vara specifik på exakt vilket anrop som inte fungerar som förväntat för att vi ska kunna analysera det. Om möjligt skulle det vara bäst att förklara med några bevis för att underbygga det.
Till exempel, istället för att säga att API:et är långsamt, kan du säga att anropet PersonalInfo_Get brukade ta 2 sekunder i genomsnitt och tar nu 10 sekunder. Med tydlig information och ett specifikt anrop kan vi analysera på ett bättre sätt.
Bifoga bilder från andra applikationer än Nmbrs. Vi kan inte undersöka andra programvarufel!
När skärmdumpar från andra applikationer än Nmbrs bifogas supporttickets hjälper de oss inte att identifiera vad som är problemet som ska åtgärdas. De flesta av integrationspartnerna använder Nmbrs API för att ansluta till sina system. Därför är det de som vet hur Nmbrs fungerar och måste se till att deras integration fungerar som förväntat.
Vi har inte tillgång till partnerns ansökningskod och vi vet inte heller hur de hanterar de olika svaren från Nmbrs. I denna situation ber vi partnern att kontakta oss med information om vad som går fel i anslutningen.
Skicka loggar genererade av integrationspartnerns applikation
Detta är mycket likt föregående punkt. En integrationspartner kan skapa sin egen kod i valfritt programmeringsspråk för att integrera med Nmbrs API. Om loggar från partneransökan bifogas kan vi inte använda dem för att undersöka någonting. Vi behöver biljetten för att vara exakt på problemet som händer.
Kommentarer