Októberben már írtam egy cikket arról, hogy milyen galibával szembesültünk egyik ügyfelünknél a .NET framework 3.5 SP1 telepítése után. A sztori azóta is “kísért”, vissza-visszatér a probléma/kérdés, nem hagy nyugodni.
A MSFT MCS-től, illetve angol blogom egyik kommentjében kaptam tippet, ami arra vonatkozott, hogy a híres-hírhedt loopback check okozhatja a problémát. Ha nem lennék olyan, amilyen vagyok, nyugodtan hátradőlhettem volna, azzal a tudattal, hogy megvan a megoldás, ha már egyszer “mindenki ezt mondja” – ám nem ezt tettem: elkezdtem utánajárni a dolognak, hogy vajon tényleg ez lehet-e a megoldás (mindenesetre gyanús, ha több helyről is ugyanaz a javaslat érkezik), és ha igen, akkor pontosan miért is.
Néhány tény:
- A Records Center problémára október elejétől kerestük a megoldást, blogbejegyzésem október 31-én született a tanulságokról.
- Ugyancsak a SharePoint és a .NET framework 3.5 SP1 kapcsolatáról október 30-án jelent meg egy cikk, amely ugyan nem közvetlenül a Records Centerről szól, de a loopback check lényegét jól leírja (kiemelés tőlem, a későbbiekben még fontos lesz):
“The purpose of the loopback check is to eliminate denial of service attacks however it causes issues with access SharePoint sites locally from the server.”
Szóval a lényeg: a loopback check kikapcsolása akkor segíthet, ha lokálisan, a szerveren belüli hívások történnek, hiszen ezek okozhatnak galibát. Igen ám, de a Records Center esetében mi bizony távoli gépekről is teszteltünk, nemcsak a MOSS szerverről! Ebben az esetben csakis akkor lehet tehát gond, ha a háttérben, a Records Center működése közben történnek a szerveren belüli hívások. Nézzünk tehát utána!…
A Records Center működése dióhéjban, felhasználói oldalról: a Records Center maga egy speciális webhelysablonból (site template) jön létre, amelyet célszerű legalább külön webhelycsoportba (site collection) tenni, de több szempont (például adatbázis-optimalizálás) is a szeparált webalkalmazás (web application) mellett szól. Arra is van azonban lehetőségünk, hogy teljesen különálló farmon lévő Records Centert használjunk.
Miután létrehoztuk a Records Center webhelyet, bekonfiguráltunk néhány dolgot (pl. records routing, amely azt mondja meg, milyen tartalomtípusú dokumentumok melyik dokumentumtárba kerüljenek), a produkciós környezetben is beállítjuk, hogy onnan ezt az adott Records Centert szeretnénk használni. Ez a beállítás a Records Center egy speciális web service-ének (_vti_bin/officialfile.asmx) megadását jelenti – ennek később még nagy jelentősége lesz.
Látszólag tehát amikor egy dokumentumot szeretnénk beküldeni a Records Centerbe, a RC egy webszolgáltatása kerül meghívásra:
Ha azonban jobban megnézzük, mi történik ilyenkor, a következőt láthatjuk: a “Send To –> My Records Center” menüpont kiválasztásakor nem közvetlenül a Records Center web service kerül meghívásra, hanem az adott produkciós környezet LAYOUTS mappájában található SendToOfficialFile.aspx. Ezután a következő hívások történnek a háttérben:
Vagyis az ASPX mögötti code behind-nak köszönhetően először jónéhány SharePoint API-hívás történik, s csak ezután kerül a vezérlés az officiealfile.asmx web service-hez! Ha pedig a Records Center ugyanazon a szerveren (farmon) található, ahol a produkciós környezet, akkor ez az áthívás a webszolgáltatásba lokális hívás lesz! – Így már érthető, hogy a loopback check kikapcsolása miért jelenthet megoldást a problémánkra!
Sőt, ez arra is magyarázatot ad, miért kaptuk ugyanezt a hibaüzenetet, ha az adott farmon újabb Records Centert hoztunk létre, s oda próbáltuk küldeni a dokumentumokat.
Ha pedig távoli (másik szerveren/farmon található) Records Centerbe küldjük a file-okat, akkor annyi a különbség, hogy a SendToOfficialFile.aspx lokálisan, a produkciós környezet LAYOUTS mappájából kerül meghívásra, az OfficialFile.asmx webszolgáltatás viszont a Records Center szerverén található példány, így az áthívás távoli, nem pedig lokális.
Úgy tűnik tehát, a rejtélyes probléma megoldódott, teszteléseim és a fenti nyomozás is ezt támasztják alá. Sajnos a hibaüzenetek nem túl egyértelműek, az itt kapott üzenet (”The DevRC Records Center could not be found or accessed.”) például több más, általánosabb esetben is előfordul. Ugyanezt kapjuk például, ha a konfigurálás során a Records Center URL-jét rosszul állítjuk be, illetve akkor is, ha az adott felhasználónak nincs joga file-t küldeni a Records Centerbe. Ennek oka, hogy a Records Center mögötti hibakódok egy elég rövid enum-ban vannak definiálva, a következő értékekkel:
Gyakran szoktam azzal zárni írásaimat, hogy “Folyt. köv.” – Igazából most azt remélem, hogy ebben az esetben nem lesz folytatás, és nem derül ki valami újabb turpisság a dologgal kapcsolatban… (Persze ha Te ilyet tapasztalsz, ne kímélj, mindenképp írd meg!…)
