Microsoft CoE Starter Kitin DLP Impact Analysis ei näytä kaikkia konnektoreita: juurisyy ja korjaus
CoE Starter Kitin Data Policy Impact Analysis näytti DLP-säännössä vain 54 konnektoria, vaikka Power Platform admin centerissä niitä oli kaikkiaan noin 1 600 jaettuna eri luokkiin. Synkronointi toimi, ja Dataverse-inventaario oli kunnossa. Ongelma löytyi lopulta DLP-sovelluksen omasta App.OnStart-kaavasta. Tässä kirjoituksessa näytämme, miten vika tunnistetaan ja korjataan.
Oire
Sovelluksen Edit Policy -näkymä näytti vain käytäntöön erikseen luokitellut konnektorit sekä kourallisen erikoistapauksia: HTTP-konnektorit, Teams-webhookin ja Copilot Studion virtuaalikonnektorit. Business-välilehdellä oli 24 riviä ja Blocked-välilehdellä 18. Loput noin 1 550 konnektoria puuttuivat ilman virheilmoitusta.
Mikä ei ollut vikana
Kävimme läpi kaikki ilmeiset epäillyt, ja jokainen osoittautui syyttömäksi:
Synkronointi toimi. Admin | Sync Template v3 (Connectors) -työnkulku ajoi onnistuneesti ja käsitteli 1 585 konnektoria.
Inventaario oli kunnossa. CoE-ympäristön PowerApps Connector -taulussa oli 1 598 riviä.
Versio oli uusin. Päivitimme kitin viimeisimpään julkaisuun (helmikuu 2026). Sama vika.
Ratkaisukerrokset olivat puhtaat. Ei hallitsemattomia mukautuksia, jotka peittäisivät päivityksen alleen.
Tässä vaiheessa moni lopettaa ja toteaa työkalun rikkinäiseksi. Me purimme sovelluksen auki.
Juurisyy: sovellus ei lue omaa inventaariotaan
Veimme mukautetun sivun ratkaisupakettina ulos ja luimme sen kaavat. Löydös yllätti: Data Policy Impact Analysis ei käytä CoE:n Dataverse-inventaariota lainkaan. Se hakee konnektoriluettelon suorana API-kutsuna sovelluksen käynnistyessä:
ClearCollect(
temp_col_connectors_fromAPI,
PowerAppsforMakers.GetConnectors(
{ '$filter': "environment eq '~Default'", '$top': 1000 }
).value
)
Kutsussa on kaksi ongelmaa. Ensimmäinen: se hakee konnektorit tenantin oletusympäristöstä `~Default`-aliaksella, ja kun kutsu epäonnistuu, virhe katoaa Concurrent-lohkon sisään ilman ilmoitusta. Sovellus jatkaa käynnistymistä tyhjällä luettelolla ja näyttää vain kovakoodatut HTTP-konnektorit ja virtuaalikonnektorit. Juuri ne 18 riviä, jotka me näimme. Toinen ongelma: `$top: 1000` rajaa tuloksen tuhanteen riviin. Sovellus ei siis näyttäisi koko luetteloa edes silloin, kun kutsu onnistuu, koska konnektoreita on jo yli 1 600.
Diagnoosin voi varmistaa avaamalla sivun Power Apps Studiossa, ajamalla OnStartin ja katsomalla kokoelman `temp_col_connectors_fromAPI` sisällön. Jos se on tyhjä, vika on tämä.
Korjaus
Microsoft arkistoi CoE Starter Kitin GitHub-repositorion 2.7.2026. Arkistoitu repositorio on vain luku -tilassa: siihen ei voi enää avata normaalisti käsiteltäviä issueita tai pull requesteja, joten organisaatioiden on varauduttava ylläpitämään mahdollisia paikallisia korjauksia itse. Jos ongelma esiintyy omassa ympäristössä, käytännön vaihtoehdot ovat tällä hetkellä paikallinen korjaus, toiminnallisuuden korvaaminen omalla ratkaisulla tai siirtyminen Power Platform admin centeriin, jolloin vaikutusanalyysi tosin jää pois. Me valitsimme paikallisen korjauksen, koska kyse on yhden rivin muutoksesta mukautetun sivun App.OnStart-kaavaan:
1. Avaa CoE-ympäristössä ratkaisu Center of Excellence - Core Components, valitse Pages ja avaa DLP Impact Analysis -sivu muokattavaksi.
2. Valitse puunäkymästä App ja avaa OnStart-kaava.
3. Korvaa `'~Default'` oletusympäristön oikealla nimellä, muotoa `Default-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`. Nimen näkee esimerkiksi Connectors-synkronointityönkulun ajohistoriasta tai admin centerin ympäristöluettelosta.
4. Nosta samalla `'$top': 1000` arvoon 2000.
5. Tallenna ja julkaise.
Kaksi käytännön varoitusta. Kun avaat sivun nykyisessä Studiossa, editori päivittää sivun koodikomponentit (PowerCAT-kontrollit) automaattisesti. Julkaistu sovellus voi sen jälkeen näyttää hetken rikkinäiseltä: painikkeet puuttuvat ja taulukot kutistuvat. Aja silloin ratkaisulle Publish all customizations ja testaa sovellus yksityisessä selainikkunassa, koska komponenttien selainvälimuisti on sitkeä. Koska kitti ei enää saa päivityksiä, hallitsematon mukautuskerros ei myöskään haittaa: mikään tuleva julkaisu ei jää sen alle. Paluutie on silti aina olemassa: sivun ratkaisukerroksista voi poistaa aktiiviset mukautukset, jolloin alkuperäinen hallittu versio palaa.
Mitä havaitsimme
Nämä ovat tapauksen todennetut faktat, eivät tulkintoja:
Sovellus ohittaa CoE-inventaarion. DLP-työkalun konnektoriluettelo tulee suorasta API-kutsusta, ei kitin omasta Dataverse-taulusta, jota synkronointityönkulut ylläpitävät.
Virhe on käyttäjälle näkymätön. Epäonnistunut kutsu ei tuota mitään ilmoitusta. Sovellus näyttää vajaan luettelon samalla varmuudella kuin täyden.
Yläraja on sisäänrakennettu. Kutsun 1 000 rivin katto alittaa nykyisen konnektorimäärän, joten täyttä luetteloa ei saa edes toimivalla kutsulla.
Kitin kehitys on päättynyt. Microsoftin oman ohjeistuksen mukaan CoE Starter Kit ei enää saa uusia ominaisuuksia eikä päivityksiä ("no longer actively maintained"), ja GitHub-repositorio arkistoitiin vain luku -tilaan 2.7.2026. Termit kannattaa pitää erillään: kitti ei ole poistunut käytöstä, mutta sen ylläpito on siirtynyt käytännössä käyttäjäorganisaatioille itselleen.
Mitä siitä päättelemme
Tästä eteenpäin puhumme omista johtopäätöksistämme. DLP-käytäntöjen ensisijaisena hallinta- ja tarkistuspaikkana kannattaa käyttää Power Platform admin centeriä. Haasteena on, että vastaava vaikutusanalyysi (Impact Analysis) sieltä toistaiseksi puuttuu, joten CoE-työkalulla on yhä paikkansa. Omassa tapauksessamme admin center näytti koko konnektoriluettelon, kun CoE Starter Kitin DLP-sovellus näytti vain murto-osan siitä. CoE-kitin sovelluksia kannattaa käyttää vain, jos joku organisaatiossa omistaa ne: ymmärtää, miten ne on rakennettu, ja pystyy korjaamaan ne itse. Hallintatyökalu, jonka virheet eivät näy käyttäjälle, on työkaluista vaarallisin: se ei riko mitään näkyvästi, vaan rapauttaa päätösten tietopohjan hiljaa.
Jos oma CoE-ympäristösi näyttää samalta, tarkista luvut, ennen kuin luotat niihin. Me Claritossa autamme mielellämme päivittämään hallintamallin CoE-kitin jälkeiseen aikaan tai rakentamaan kokonaan uuden, jos sellaista ei vielä ole. Rakennamme mallin niin, että se kattaa myös agentit ja niiden hallinnan, sillä seuraava hallintahaaste ei tule sovelluksista, vaan agenteista.
Kirjoittaja
Jocke Wilén