SharePoint-vienti Exceliin: missä päivitys todella suoritetaan
Seuraa SharePoint-Excel-vientiä kyselytiedoston, Officen oman HTTP-pyynnön ja tallennetun päivityksen läpi ja selvitä, mikä vaihe todella epäonnistui.
Vienti Exceliin tuottaa käyttöönotosta riippuen kolme erilaista artefaktia, ja virhe kuuluu täsmälleen yhteen niistä. Ladattu kyselytiedosto, staattinen CSV ja päivittyvä yhdistetty taulukko eivät ole sama tulos, ja jokainen niistä epäonnistuu eri vaiheessa. Tieto siitä, mikä artefakti sinulla on, ratkaisee, kuuluuko seuraava askel verkkotiimille, identiteettitiimille vai luettelon omistajalle. Alla oleva mekanismi seuraa siirtoa selaimesta Excelin omaan pyyntöön.
Mitä vienti todella luovuttaa
Klassisissa SharePoint-luetteloissa Vie Exceliin lataa pienen tekstitiedoston, jonka runko on URL-osoite, ja sitten Excel lukee tiedoston ja lähettää oman pyyntönsä sen takana olevista tiedoista. Ladattu tiedosto on osoitin, ei luettelo. CSV-vienti sen sijaan sisältää rivit itse eikä sillä ole yhteyttä päivittämiseen. Uudempi yhdistetty taulukko voi upottaa kyselyn suoraan työkirjaan, joten mitään ei päädy Lataukset-kansioon lainkaan.
Jokainen yhdistetty muoto on yksisuuntainen. Päivitys vetää nykyiset rivit luettelosta työkirjaan, eikä taulukon muokkaaminen lähetä mitään takaisin. Tällä epäsymmetrialla on merkitystä diagnoosille, sillä työkirja, joka avautuu viime viikon riveillä, on jo todistanut, että tiedosto on olemassa ja yhteys tallennettiin, mutta ei kerro mitään siitä, toimiiko päivitys tänään.
Ensimmäinen kysymys ei siis ole, miksi vienti epäonnistui, vaan mitä artefaktia käyttäjä odotti. Vastaus rajaa tutkinnan yhteen kolmesta prosessista.
Kolme prosessia, kolme eri identiteettiä
Selaimen lataus käyttää selainistuntoa omine evästeineen, välityspalvelinasetuksineen ja kirjautumistiloineen. Tiedoston avaava Excel käyttää Officen HTTP-pinoa, joka yleensä noudattaa käyttäjäkohtaista Internet-asetusten välityspalvelinta koneenlaajuisen WinHTTP-asetuksen sijaan ja joka todentaa millä tahansa Office-identiteetillä, joka käyttäjällä on. Myöhempi päivitys käyttää uudelleen tallennettua yhteyttä ja voi noutaa välimuistiin tallennetut tunnistetiedot Windowsin Tunnistetietojen hallinnasta sen sijaan, että kysyisi.
Nämä kolme kontekstia voivat olla eri mieltä yhdellä koneella, ja siksi selain, joka avaa luettelon hyvin, ja Excel-päivitys, joka palauttaa kirjautumiskehotteen, on johdonmukainen tulos eikä ristiriita. Tunneli muuttaa koneen reititystä kaikille kolmelle, mutta välityspalvelimen automaattinen määritystiedosto voi silti lähettää Office-pyynnöt muualle.
Kirjaa kussakin vaiheessa käytetty identiteetti ennen kuin muutat mitään niistä. Selaimeen tehty korjaus ei voi korjata pyyntöä, jonka Excel tekee toisen tilin alla.
Lue siirtotiedosto ennen kuin muutat mitään
Ladattu tiedosto on puhdasta tekstiä ja yleensä lyhyt, joten lue se ensin. Se nimeää isäntäkoneen ja päätepisteen, jonka Excel kutsuu, ja se isäntä on se, joka on ratkaistava ja todennettava käyttäjän koneelta, ei välttämättä se osoite, joka näkyy selaimen osoitepalkissa.
Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy
Vertaa tiedoston isäntää sivustoon, josta käyttäjä uskoo vieneensä. Uudelleenohjaus viennin aikana, vanha sivustokokoelma tai siirretty luettelo voi jättää osoittimen nimeen, joka ei enää toimita tietoja, ja siitä syntyvä virhe näyttää verkkohäiriöltä. Jos nimi ratkeaa ja päätepiste vastaa, jäljellä olevat ehdokkaat ovat todentaminen ja itse kysely.
Älä korvaa isäntänimeä IP-osoitteella saadaksesi sen toimimaan. Se rikkoo varmenteen nimitaristuksen ja kätkee todellisen ongelman kiertotien taakse, joka epäonnistuu seuraavassa varmenteen uusinnassa.
Erottele nimi-, kirjautumis- ja kyselyvirheet
Neljä lopputulosta kattaa lähes jokaisen raportin, ja jokaisella on eri omistaja. Nimi, joka ei ratkea, kuuluu DNS:lle. Yhteys, joka aikakatkaistaan, kuuluu reititykselle tai välityspalvelimelle. Kirjautumiskehote tai 401 kuuluu identiteetille. Vastaus, joka saapuu mutta jota ei voi jäsentää, kuuluu kyselylle tai päätepisteelle, jonka luettelo nyt paljastaa.
| What the user sees | Stage that failed |
|---|---|
| Data source could not be found | Name resolution or the pointer in the file |
| Repeated sign-in prompt | Office identity or cached credential |
| Timeout while refreshing | Route, proxy or the VPN path |
| Refresh succeeds, rows look wrong | Query scope or list view, not connectivity |
Viimeinen rivi on se, jonka ihmiset diagnosoivat väärin. Päivitys, joka valmistuu ja palauttaa väärät rivit, on todistanut, että jokainen verkko- ja identiteettikerros toimii, ja jäljelle jäävä kysymys on, mitä näkymää tai suodatinta kysely kantaa. Sen lipun lähettäminen verkkotiimille tuhlaa päivän.
Tallenna tarkka virheteksti ja ensimmäisen epäonnistumisen aika. Se ratkaisee, missä taulukon rivissä olet, ja se on ainoa todiste, jonka perusteella luettelon omistaja voi toimia.
Testaa päivitys uudelleen samalla luettelolla
Kun epäonnistuva vaihe on tunnistettu, toista se toiminto, joka epäonnistui, älä halvempaa. Päivitä sama luettelo aiotusta Excel-ympäristöstä odotetulla tilillä ja hyväksytyllä verkkopolulla ja vahvista, että rivimäärä tai tunnettu muuttunut arvo todella päivittyy. Tallennetun työkirjan avaaminen ei todista mitään yhteydestä.
Vastusta laajoja korjauksia: kaikkien tallennettujen tunnistetietojen tyhjentäminen, Officen suorittaminen korotettuna tai suojausominaisuuden poistaminen käytöstä voi muuttaa oiretta korjaamatta vaihetta. Jos todentaminen on epäonnistuva kerros, pyydä luettelon omistajaa vahvistamaan tili ja tuettu kirjautumisvirtaus sen sijaan, että arvaisit asiakkaassa.
Tarjoa CSV:tä vain, kun irrotettu tilannekuva täyttää tehtävän ja kyseinen vienti on tuettu ympäristössä. Tulostemuodon muuttaminen muuttaa työnkulkua eikä selitä, miksi yhdistetty toiminto lakkasi toimimasta.