API för Stadsnät:
API för Tjänsteleverantörer:
API för Tjänsteleverantörer:
Flödeschema för TL
När en slutkund lägger en order via Tjänsteguiden så skapas en order per tjänst. Det går ett mail till Tjänsteleverantören med en länk för manuell hantering, samt en maskinellt läsbar info-del med ett Order-ID som kan användas för att hämta data om ordern via API. Vår rekommendation är att för att automatisera detta så ignorera mailet och använd metoden orders för att hämta orders sen senast ni kontrollerade.sequenceDiagram
%%{init: {"theme":"base","themeVariables":{"actorBkg":"#3a88fe","actorTextColor":"#ffffff","labelTextColor":"#000000","signalTextColor":"#000000","loopTextColor":"#000000"}}}%%
participant A as Kund
participant B as Tjänsteguiden
participant C as Tjänsteleverantör
participant D as ON-API hos Stadsnät
A->>B: Jag vill beställa Tjänst 100/100
B->>A: Vad är din adress?
A->>B: Demogatan 123, Demostad
note over A, B: Vilket är accessId AB123 enligt Marknadsdatabasen
B->>B: Spara kund och order i databas
B->>A: Tack för din beställning
B-->>C: Ny beställning
note over C: Detta skickas som ett mail med
information för att hämta via API alt Tjänsteleverantör agerar på mailet C->>B: Hämta beställningen C->>D: Aktivera Tjänst AB100100
på accessId AB123 end alt Tjänsteleverantör hämtar periodiskt nya beställningar C-->>B: Nya beställningar? B-->>C: Dessa är de nya beställningarna C->>D: Aktivera Tjänst AB100100
på accessId AB123 end
information för att hämta via API alt Tjänsteleverantör agerar på mailet C->>B: Hämta beställningen C->>D: Aktivera Tjänst AB100100
på accessId AB123 end alt Tjänsteleverantör hämtar periodiskt nya beställningar C-->>B: Nya beställningar? B-->>C: Dessa är de nya beställningarna C->>D: Aktivera Tjänst AB100100
på accessId AB123 end
För TL så använder ni alltså orders för att se senast inkomna ordrar. Där ser ni ett ID per order, då använder ni order_info för att hämta information om ordern, samt customer_info för att hämta info om kunden.
När TL har hämtat ordern så använder TL metoden set_status för att sätta status till "received", på så sätt kan TL hålla reda på vilka ordrar som redan är inlästa, plus att både TL och KO kan se att ordern är mottagen. TL använder sedan set_status för att reflektera orderns status tills dess att status är "delivered".
Om ordern har status "delivered" när den läses in av TL så betyder det att tjänsten är direktaktiverad och TL behöver bara läsa in data i sitt ordersystem och hantera kunden därifrån.
Vid problem med en order så används metoden add_message för att spara ett logmeddelande på ordern med rätt typ. När ni använder status via set_status så sparas det även ett log-meddelande om att ni ändrat status. Använd add_message för att meddela KO om några problem vid den automatiska hanteringen - lita dock inte på detta som en meddelandefunktion som KO's tekniska avdelning har koll på. Var noga med att flagga ordern internt att den kan behöva manuell uppföljning.
Flödesschema för KO
I de flesta fall så är KO inte inblandad i orderhanteringen utan den är upp till TL att hantera. I vissa fall så har KO slutkundsrelation och kan därmed via sitt API hämta samma information som TL om order och kund.Även KO har tillgång till set_status och add_message för att hantera information kring en order, samt kan se loggen och den information som TL har lagt till. KO kan till exempel sätta status till "active" när dom fått förfrågan från TL om aktivering, eller "cancelled" om något fel uppstår vid hantering av ordern.