Hoppa direkt till innehåll

Stadsnätswebben och PI-API

2018-03-06
Det pågår just nu en hel del arbete kring PI-API (Provider Interface API) och ett projekt för att skapa ett nytt öppet API baserat på det, bland annat. Syftet är givetvis att samordna och standardisera kommunikationen mellan parter där ute.
Men hur förhåller sig vi mot PI-API? Vi har fått en hel del frågor, både relaterat till PI-API men också till GDPR, så jag tänkte gå igenom, lite ytligt, vart vi står och hur framtiden kan tänkas se ut vad gäller dessa bitar.

PI-API "vs" Marknadsdatabasen

I och med den nya versionen av Marknadsdatabasen så har vi anpassat oss till SSNFs adress-specifikation medan vi samtidigt byggt ut och förädlat den samt bibehållit dataintegriteten från den äldre versionen av Marknadsdatabasen.
SSNF's specifikation är delvis baserad på PI-API och dess specifikation även om dom vuxit isär en del

Feasibility

Feasibility-API:et har exakt samma syfte som vår , det vill säga ge en export av KO's hela bestånd av avlämningspunkter. En stor skillnad här är att PI-API innehåller utförlig information om vilka av TL's tjänster som kan aktiveras på porten, vilket är information som inte finns i Marknadsdatabasen.
Här är ett uttag ur Marknadsdatabasen och hur den skulle se ut i "PI-API"-format, så att säga. Jämför med mängden data och format mot Feasibility-länken ovan:
{
        "coId": "Njudung Bredband",
        "accessId": "PK4141",
        "streetName": "Östra Nygatan",
        "streetNumber": "13",
        "streetLittera": null,
        "postalCode": "57433",
        "city": "Vetlanda",
        "countryCode": "SE",
        "premisesType": "COMMERCIAL",
        "mduApartmentNumber": null,
        "mduDistinguisher": null,
        "swerefType": null,
        "swerefNorth": null,
        "swerefEast": null,
        "propertyUnitDesignation": "VETLANDA MAGASINET 4",
        "propertyUnitArea": null,
        "outlet": null,
        "population": "Östersand",
        "media": "FTTH",
        "servicesConnection": "2016-06-06",
        "coCpe": "INTENO XG6846 (4p)",
        "servicePort": "ASAP",
        "dhcpOption": null,
        "lastUpdate": "2018-01-10 13:37:00",
        "keywords": null,
        "netType": "LAYER3",
        "portCapacity": "1000",
        "cpeCapacity": "1000",
        "openTv": "DELIVERABLE",
        "cableTv": "NO",
        "exclusiveTv": "DELIVERABLE"
    }
Som ni ser så har vi mer data, specifikt för att hantera vilken typ av tjänst som porten kan ta emot, snarare än exakt vilka tjänster den kan ta emot.

Availability API

I Availability API så är syftet att göra en förfrågan för ett specifikt accessID vilket delvis har samma funktion som vår , men PI-API har mycket mer data om porten/accessen, exakt vilka tjänster som finns. vilka tjänster som har beställts osv osv.
Med hjälp av vårt så kan vi förädla även får information i det vårt API, men inte utan att våra kunder är överens om vilken information som ska delas med TL.

Anpassning till PI-API?

Vi har planer att ta fram åtminstone Feasibility-API:et och skapa en anpassning för det. Så att de TL som idag anpassar sig till PI-API ska kunna använda det för att få data från Stadsnätsportalens alla Stadsnät "på köpet".

GDPR och Stadsnätsportalen/Stadsnätswebben

Vi har gått ut med information till alla Tjänsteleverantörer att det är dags för dem att anpassa sina rutiner efter vårt API: och att inom kort kommer vi sluta skicka personuppgifter via mail. Så de beställningar som görs via Tjänsteguiden kommer skicka ett mail till TL innehållande en länk till Stadsnätsportalen för manuell hantering (vilket kräver inlogg) samt ett ID för automatiskt hantering via API:et (vilket också kräver inlogg).
Mer information och diskussion om detta på vårens SWAT, som ni verkligen inte borde missa - anmäl er nu! Både Stadsnät och Tjänsteleverantörer!
SENASTE
Visa alla