ON-API

ON-API är ett API för Öppna Nät, det är en förgrening av ComHem's PI-API och började utvecklas för runt 4-5 år sedan. Redan 2011 så utvecklade vi API:er för Stadsnätssverige, men vår utgångspunkt var att vi helt enkelt inte har resurser för att anpassa oss till de olika (eventuella) API:er som finns för att läsa in adresser, uttag och liknande från de system som finns, så vi var tvungna att utveckla ett eget API för detta.
I och med PI-API och sedermera ON-API så började en arbetsgrupp jobba mot en branschstandard för hur alla dessa system ska prata med varandra, något vi varit väldigt positiva till från början.
Vår sits är dock lite annorlunda än för många andra. Både PI-API och ON-API är menade för direktkommunikation mellan Tjänsteleverantör och Stadsnät/nätägare, och för en del Stadsnät är detta inga konstigheter, utan kan utveckla stöd för ON-API så att Tjänsteleverantörer kan kontakta dem direkt. Dock har alla inte samma tur, så många nät kom till oss, vi har ju redan en hel del av det data som TL efterfrågar i till exempel Marknadsdatabasen, så varför kan vi inte stödja ON-API med det datat? Det var ju givetvis ett behov vi med glädje ville tillfredsställa så "accesses"-metoden i ON-API stöds nu av Stadsnät som använder Stadsnätswebben: api ON-API
Sen finns det delar av ON-API som vi har svårare att erbjuda våra kunder, delar som kräver integration mot de lokala systemet, som till exempel order-API:et, där TL kan aktivera tjänster på portar i Stadsnätet automatiskt. Det kräver som sagt att integrationen mot ON-API måste byggas av den lokala nätägaren.
Vem äger kunden?
Orders-API:et är ju byggt kring ett behov där TL äger kunden, så till exempel via TL's hemsida eller kundtjänst så kan en beställning skapas tillsammans med en kund, och sedan en order via API:et, där TL's referenser skickas med. Orders-API:et är tänkt att fungera så här:
sequenceDiagram %%{init: {"theme":"base","themeVariables":{"actorBkg":"#3a88fe","actorTextColor":"#ffffff","labelTextColor":"#000000","signalTextColor":"#000000","loopTextColor":"#000000"}}}%% participant A as Kund participant B as Tjänsteleverantör participant C 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 accesses-API:et B-->>C: Aktivera Tjänst AB100100
på accessId AB123 note over B, C: AB100100 är transmissionstjänsten hos KO C-->>B: Klart B->>A: Tjänsten är nu aktiverad
I punkt nummer 4 så skickar TL med information om ordernummer och kundnummer så att KO kan tagga den här beställningen korrekt, och TL senare kan fråga om just den här ordern (den kanske inte kunde direktaktiveras, utan får ett annat status.
För Tjänsteguiden är beställningsförfarandet annorlunda, och Tjänsteguiden stöder i dagsläget inte ON-API, men utveckling sker för att försöka stödja det så gott det går. Anledningen till att vi inte kan använda order-API:et är för att det är byggt runt att kunden och beställningen redan finns hos TL. Vi använder i dagsläget våra egna API:er där TL kan hämta ut vilka beställningar (api Tjänsteguiden: XSP Beställningar) som gjorts och sedan via ON-API prata med KO. Så här funkar det:
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
Punkt 5-9 sker separat i processen, TL frågar periodiskt om nya beställningar från Tjänsteguiden och därför kan tjänsten inte direktaktiveras.
Version 2.5
I nästa version av ON-API så finns det lite nya funktioner som kan underlätta Tjänsteguiden som "mellanhand" i den här processen. Bland annat möjligheten att TL kan svara på ON-API-förfrågningar via en endpoint som i utvecklingen heter "sp/order", alltså en beställning som kommer från KO/Stadsnätet, i vårt fall via Tjänsteguiden. Processen är tänkt att fungera så här:
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 ON-API
Tjänsteleverantör participant D as ON-API
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: Kunddata, tjänstedata och accessdata samlas in B->>C: [kunddata] vill beställa
[tjänstdata] på
[accessdata] alt Kan aktivera note over C: Spara kund och order i databas C->>D: Aktivera [tjänst] på [access] D->>C: Klart C->>B: Klart note over B: Spara kund och order i databas B->>A: Tjänsten är nu aktiverad end alt Kan inte aktivera note over C: Spara kund och order i databas C->>D: Aktivera [tjänst] på [access] D->>C: Nej C->>B: Mottaget, ej aktiverad note over B: Spara kund och order i databas B->>A: Tjänsten är nu beställd end alt Kan inte beställa note over C: Efter kreditkontroll eller annan
teknisk anledning nekar TL att aktivera kund C->>B: Nej B->>A: Tyvärr kan du inte
beställa den här tjänsten end