Összefoglalás
A fejlesztők a Microsoft Office Automation szolgáltatásával olyan egyéni megoldásokat hozhatnak létre, amelyek az Office-termékbe beépített képességeket és funkciókat használják. Bár az ilyen programozott fejlesztés viszonylag könnyen implementálható egy ügyfélrendszeren, számos bonyodalmat okozhat, ha az automatizálás kiszolgálóoldali kódból történik, például a Microsoft Active Server Pages (ASP), a ASP.NET, a DCOM vagy a Windows NT szolgáltatásból.Ez a cikk azokat a bonyodalmakat ismerteti, amelyekkel a fejlesztők szembesülhetnek. A cikk az Automation olyan alternatíváit is tartalmazza, amelyek felgyorsíthatják a teljesítményt. A fejlesztőknek azonban tisztában kell lenniük azzal, hogy a jelen cikkben ismertetett javaslatok csak tájékoztatási célokra szolgálnak. A Microsoft nem javasolja vagy támogatja az Office kiszolgálóoldali automatizálását.
Megjegyzés: Ebben az összefüggésben az Access adatbázismotor újraterjeszthető és access-futtatókörnyezete Microsoft Office-összetevőknek minősül. A "kiszolgálóoldali" kifejezés a Windows-munkaállomáson futó kódra is vonatkozik, ha a kód a bejelentkezett felhasználó interaktív állomásától eltérő Windows-munkaállomásról fut. A System fiókban a Feladatütemező által indított kód például ugyanabban a környezetben fut, mint a "kiszolgálóoldali" ASP-kód vagy DCOM-kód. Ezért a cikkben ismertetett problémák közül sok előfordulhat. A Windows-munkaállomásokról és a COM-ról a "További információ" és a "Hivatkozások" című szakaszban talál további információt.
További információ
A Microsoft Office összes jelenlegi verzióját úgy tervezték, tesztelték és konfigurálták, hogy végfelhasználói termékként fussanak az ügyfél munkaállomásán. Interaktív asztalt és felhasználói profilt feltételeznek. Nem biztosítják a felügyelet nélküli futtatásra tervezett kiszolgálóoldali összetevők igényeinek kielégítéséhez szükséges újrarezentálás vagy biztonság szintjét.A Microsoft jelenleg nem javasolja és nem támogatja a Microsoft Office-alkalmazások automatizálását semmilyen felügyelet nélküli, nem interaktív ügyfélalkalmazásból vagy összetevőből (beleértve az ASP-t, a ASP.NET, a DCOM-ot és az NT-szolgáltatásokat), mert az Office instabil viselkedést és/vagy holtpontot okozhat, ha az Office ebben a környezetben fut.Ha kiszolgálóoldali környezetben futó megoldást hoz létre, érdemes olyan összetevőket használnia, amelyek biztonságossá lettek téve a felügyelet nélküli végrehajtáshoz. Vagy próbáljon meg olyan alternatív megoldásokat találni, amelyek lehetővé teszik a kód legalább egy részének az ügyféloldali futtatását. Ha egy kiszolgálóoldali megoldásból származó Office-alkalmazást használ, az alkalmazás nem fogja tudni használni a sikeres futtatáshoz szükséges képességeket. Emellett kockázatokat is vállal a teljes megoldás stabilitásával.
Az Office kiszolgálóoldali automatizálásával kapcsolatos problémák
Azok a fejlesztők, akik kiszolgálóoldali megoldásban próbálják használni az Office-t, öt fő területtel kell tisztában lenniük, amelyekben az Office a környezet miatt a várttól eltérően viselkedik. Ha a kód futtatása sikeres, meg kell oldania ezeket a problémákat, és a lehető legkisebbre kell csökkentenie a hatásukat. Az alkalmazás létrehozásakor alaposan vegye figyelembe ezeket a problémákat. Az egyik megoldás nem tudja kezelni az összes problémát. A különböző kialakítások megkövetelik az elemek eltérő rangsorolását.
-
Felhasználói identitás: Az Office-alkalmazások felhasználói identitást feltételeznek az alkalmazások futtatásakor, még akkor is, ha az Automation elindítja az alkalmazásokat. Az alkalmazások megpróbálják inicializálni az eszköztárakat, menüket, beállításokat, nyomtatókat és néhány bővítményt a felhasználói beállításjegyzék-struktúra beállításai alapján az alkalmazást megnyitó felhasználó számára. Számos szolgáltatás olyan fiókok alatt fut, amelyek nem rendelkeznek felhasználói profilokkal (például SYSTEM-fiók vagy IWAM_[kiszolgálónév] fiók). Ezért előfordulhat, hogy az Office indításkor nem inicializálható megfelelően. Ebben az esetben az Office hibát ad vissza a CreateObject függvényben vagy a CoCreateInstance függvényben. Még ha az Office-alkalmazás elindítható is, előfordulhat, hogy más funkciók nem működnek megfelelően, ha nincs felhasználói profil.
-
Interaktivitás az asztallal: Az Office-alkalmazások feltételezik, hogy interaktív asztal alatt futnak. Bizonyos körülmények között előfordulhat, hogy bizonyos Automation-függvények megfelelő működéséhez láthatóvá kell tenni az alkalmazásokat. Ha váratlan hiba történik, vagy ha egy függvény végrehajtásához meghatározatlan paraméterre van szükség, az Office úgy van kialakítva, hogy a felhasználót egy modális párbeszédpanellel kérje, amely megkérdezi a felhasználót, hogy mit szeretne tenni. Nem interaktív asztal modális párbeszédpanelje nem zárható ki. Ezért a szál határozatlan ideig nem válaszol (lefagy). Bár bizonyos kódolási eljárások segíthetnek csökkenteni a probléma valószínűségét, ezek a gyakorlatok nem akadályozhatják meg teljesen a problémát. Ez önmagában kockázatossá és nem támogatottvá teszi az Office-alkalmazások kiszolgálóoldali környezetből való futtatását.
-
Újraterjedés és méretezhetőség: A kiszolgálóoldali összetevőknek nagy mértékben reentrant, többszálú COM-összetevőknek kell lenniük, amelyek több ügyfél esetében minimális többletterheléssel és magas átviteli sebességgel rendelkeznek. Az Office-alkalmazások szinte minden tekintetben pontosan az ellenkezőjét képezik. Az Office-alkalmazások nem újraértelmezett, STA-alapú Automation-kiszolgálók, amelyek úgy vannak kialakítva, hogy sokszínű, de erőforrás-igényes funkciókat biztosítsanak egyetlen ügyfél számára. Az alkalmazások kevés méretezhetőséget biztosítanak kiszolgálóoldali megoldásként. Emellett az alkalmazások rögzített korlátozásokkal rendelkeznek a fontos elemekre, például a memóriára. Ezek konfigurációval nem módosíthatók. Ennél is fontosabb, hogy az alkalmazások olyan globális erőforrásokat használnak, mint a memórialeképezett fájlok, a globális bővítmények vagy sablonok, valamint a megosztott Automation-kiszolgálók. Ez korlátozhatja az egyidejűleg futtatható példányok számát, és versenyhelyzetekhez vezethet, ha az alkalmazások többügyfél-környezetben vannak konfigurálva. Azok a fejlesztők, akik egynél több Office-alkalmazáspéldányt szeretnének egyszerre futtatni, fontolóra kell venniük a "készletezést" vagy az Office-alkalmazáshoz való hozzáférés szerializálását a lehetséges holtpontok és adatsérülések elkerülése érdekében.
-
Rugalmasság és stabilitás: Az Office 2000, az Office XP, az Office 2003 és az Office 2007 a Microsoft Windows Installer (MSI) technológiával könnyíti meg a telepítést és az önjavítást a végfelhasználók számára. Az MSI bevezeti a "telepítés első használatkor" fogalmát. Ez lehetővé teszi a szolgáltatások dinamikus telepítését vagy konfigurálását a rendszer futásidejű vagy gyakrabban egy adott felhasználó számára. Kiszolgálóoldali környezetben ez is lelassítja a teljesítményt, és növeli annak valószínűségét, hogy megjelenik egy párbeszédpanel, amely megkéri a felhasználót, hogy hagyja jóvá a telepítést, vagy adjon meg egy telepítőlemezt. Bár ez az Office végfelhasználói termékként való rugalmasságának növelésére lett kialakítva, az MSI-képességek Office-beli megvalósítása kiszolgálóoldali környezetben kontraproduktív. Továbbá az Office stabilitása általában nem biztosítható, ha az Office kiszolgálóoldalon fut, mert nem ilyen típusú használatra tervezték vagy tesztelték. Ha az Office-t szolgáltatás-összetevőként használja egy hálózati kiszolgálón, azzal csökkentheti a számítógép stabilitását, így csökkentheti a teljes hálózat stabilitását.
-
Kiszolgálóoldali biztonság: Az Office-alkalmazások soha nem kiszolgálóoldali használatra készültek. Ezért az Office-alkalmazások nem veszik figyelembe az elosztott összetevőkkel kapcsolatos biztonsági problémákat. Az Office nem hitelesíti a bejövő kéréseket. Az Office emellett nem nyújt védelmet a nem szándékolt makrók, illetve a makrókat futtató másik kiszolgáló indításától sem a kiszolgálóoldali kódból. Ne nyissa meg a kiszolgálóra névtelen webhelyről feltöltött fájlokat. Az utolsóként beállított biztonsági beállítások alapján a kiszolgáló teljes jogosultságokkal futtathat makrókat rendszergazdai vagy rendszerkörnyezetben, így veszélyeztetheti a hálózatot. Emellett az Office számos ügyféloldali összetevőt (például Simple MAPI, WinInet és MSDAIPP) használ, amelyek gyorsítótárazhatják az ügyfél-hitelesítési adatokat a feldolgozás felgyorsítása érdekében. Ha az Office kiszolgálóoldali automatizált, egy példány több ügyfelet is kiszolgálhat. Ha az adott munkamenet hitelesítési adatai gyorsítótárazva vannak, az egyik ügyfél használhatja egy másik ügyfél gyorsítótárazott hitelesítő adatait. Ezért előfordulhat, hogy az ügyfél más felhasználók megszemélyesítésével nem biztosított hozzáférési engedélyeket kap.
A technikai problémák mellett a licencelési problémákat is figyelembe kell vennie. A jelenlegi licencelési irányelvek megakadályozzák, hogy az Office-alkalmazásokat a kiszolgálón használva kiszolgálják az ügyfélkéréseket, kivéve, ha maguk az ügyfelek rendelkeznek az Office licenccel rendelkező példányával. A végfelhasználói licencszerződés (EULA) nem terjed ki arra, hogy a kiszolgálóoldali Automation használatával office-funkciókat biztosítson a nem licencelt munkaállomásokhoz.Ezen problémák mellett az alábbi gyakori hibák egyike is előfordulhat az Office kiszolgálóoldali automatizálásának megkísérlésekor:
-
A CreateObject függvény és a CoCreateInstance függvény az alábbi futásidejű hibaüzenetek egyikét adja vissza, és nem indítható el az Automation esetében.
1. üzenet
429-os futásidejű hiba: Az ActiveX-összetevő nem tud objektumot létrehozni
2. üzenet
70-edik futásidejű hiba: Engedély megtagadva
3. üzenet
CO_E_SERVER_EXEC_FAILURE (0x80080005): A kiszolgáló végrehajtása sikertelen
4. üzenet
E_ACCESSDENIED (0x80070005): Hozzáférés megtagadva
-
Amikor megnyit egy Office-dokumentumot, az alábbi hibaüzenetek egyike jelenik meg.
1. üzenet
"5981"-os futásidejű hiba (0x800A175D): Nem sikerült megnyitni a makrótárolót
2. üzenet
"1004"-os futásidejű hiba: A(z) ~objektum ~metódusa nem sikerült
-
A CreateObject függvény és a CoCreateInstance függvény nem válaszol, és soha nem fejeződik be, vagy hosszú időt vesz igénybe a visszatérés. Egyes kiszolgálókon a létrehozás gyors, de 1004-hiba jelenik meg a Windows eseménynaplójában, amely azt jelzi, hogy az alkalmazás le lett állítva.
-
Bizonyos függvények váratlanul meghiúsulnak, vagy határozatlan ideig nem válaszolnak egy felhasználói riasztás vagy más párbeszédpanel miatt, amely felhasználói beavatkozást igényel.
-
Ha több kérést vagy stressztesztet futtat, a kód meghibásodik, nem válaszol, vagy összeomlik egy Office-alkalmazás létrehozásakor vagy leállásakor. Ha ez történik, a folyamat a memóriában marad, és nem állítható le, vagy az automatizált alkalmazás összes példánya ettől a ponttól meghiúsul.
Az itt felsoroltakon kívül más problémák vagy üzenetek is megjelenhetnek, de ezek a problémák általában a cikkben korábban felsorolt öt fő probléma miatt fordulnak elő.
A kiszolgálóoldali automatizálás alternatívái
A Microsoft határozottan javasolja a fejlesztőknek, hogy keressenek alternatív megoldásokat az Office automatizálása helyett, ha kiszolgálóoldali megoldásokat kell fejleszteniük. Az Office kialakításának korlátozásai miatt az Office konfigurációjának módosítása nem elegendő az összes probléma megoldásához. A Microsoft számos olyan alternatívát javasol, amelyek nem igénylik az Office kiszolgálóoldali telepítését, és amelyek hatékonyabban és gyorsabban tudják elvégezni a leggyakoribb feladatokat, mint az Automation. Mielőtt az Office-t kiszolgálóoldali összetevőként bevonja a projektbe, fontolja meg az alternatívákat.A legtöbb kiszolgálóoldali Automation-feladat a dokumentumok létrehozását vagy szerkesztését foglalja magában. Az Office 2007 támogatja az új Open XML fájlformátumokat, amelyekkel a fejlesztők fájltartalmakat hozhatnak létre, szerkeszthetnek, olvashatnak és alakíthat át a kiszolgálóoldalon. Ezek a fájlformátumok a Microsoft .NET 3.x keretrendszer System.IO.Package.IO névterét használják az Office-fájlok szerkesztéséhez az Office-ügyfélalkalmazások használata nélkül. Ez az ajánlott és támogatott módszer az Office-fájlok módosításainak kezelésére egy szolgáltatásból.Az Open XML fájlformátumok nyilvános szabványnak számítanak.
A Microsoft egy SDK-t biztosít az Open XML-fájlformátumok .NET 3.x keretrendszerből történő kezeléséhez. Az SDK-val és az SDK nyílt XML-fájlok létrehozására vagy szerkesztésére való használatával kapcsolatos további információkért látogasson el a Microsoft Developer Network (MSDN) alábbi webhelyeire:
Az OPEN XML SDK dokumentációja
Útmutató: Az Office Nyílt XML-formátumok dokumentumainak kezelése
Word 2007 fájlok manipulálása az Open XML-objektummodellel (1. rész a 3-ból)
Word 2007 fájlok manipulálása az Open XML-objektummodellel (2. rész a 3-ból)
Word 2007-fájlok manipulálása az Open XML-objektummodellel (3. rész, 3. rész)
Amikor open XML-fájlokat streamel az ASP-ből vagy ASP.NET, meg kell adnia a megfelelő többcélú internetposta-bővítmény (MIME) típust a streamelt tartalomhoz. Az Office 2007-fájlok MIME-típusainak listájáért látogasson el a következő webhelyre:
Office 2007 fájlformátumú MIME-típusok HTTP-tartalomstreameléshez
Ha csak az Office 2007 előtti ügyfeleket célozza meg, és nem szeretné az Open XML használatát a megoldásban használni, más nem bináris Office-fájlformátumokat is használhat, például HTML, XML és RTF formátumokat. Ezeket a fájlokat ezután MIME-típussal streamelheti egy ügyfélnek, hogy az eredményül kapott szöveg megjelenjen az Office-ban. A dokumentum szerkeszthető, menthető és akár vissza is adható a kiszolgálóra az ASP használatával a kiszolgálón.Az alábbi témakörökről és azok implementálását bemutató példákért kattintson a következő cikkszámokra a Microsoft Tudásbázis cikkeinek megtekintéséhez:
198703 Az Excel automatizálása ügyféloldali VBScriptből
Excel-adatok lekérdezése és frissítése az ASP-ből származó ADO használatával
286023 VB ActiveX-összetevő használata az Internet Explorer Word automatizálásához
Ha vállalata megköveteli az Office 97, az Office 2000, az Office XP és az Office 2003 bináris fájlformátumának kiszolgálóoldali létrehozását, a külső gyártók olyan összetevőket kínálnak, amelyek segíthetnek Önnek. A Microsoft nem biztosít ilyen összetevőket, ezért önnek kell létrehoznia egy megoldást, vagy meg kell vásárolnia egyet egy külső gyártótól. Számos különböző, külső gyártótól származó termék érhető el. Érdemes megvizsgálnia az egyes megoldásokat, hogy a legjobban megfeleljen a szállítónak az üzleti igényeinek.
Ha közvetlenül az Office 97, az Office 2000, az Office XP és az Office 2003 bináris fájlformátumait szerkesztő saját megoldást szeretne létrehozni, a fájlformátum-specifikációkat ingyen beszerezheti a Microsoft Open Specification Promise (OSP) feltételei szerint. A dokumentációhoz és a létrehozott termékekhez nem áll rendelkezésre technikai támogatás, de a dokumentáció elérhető.
A kiszolgálóoldali megoldások azt is lehetővé tehetik, hogy a felhasználók fájlokat töltsenek fel, majd a kiszolgáló renderelje a fájlokat megtekintésre a weben vagy más adathordozókon. A Microsoft jelenleg azon dolgozik, hogy ilyen funkciókat kínáljon, és ennek a funkciónak a korai verzióját biztosítja a Microsoft Excel Services. Excel Services egy új kiszolgálótechnológia, amely a Microsoft Office SharePoint Server 2007 részét képezi, és lehetővé teszi Excel-munkafüzetek betöltését, kiszámítását és megjelenítését az Office SharePoint Server 2007-ben. A Excel Services kapcsolatos további információkért látogasson el a Microsoft Developer Network (MSDN) alábbi webhelyeire:
Útmutató: Egyéni alkalmazás fejlesztése az Excel Web Services használatával
Üzleti alkalmazások létrehozása Excel Services és Office Open XML formátumok használatával Word Automation Services egy új szolgáltatásalkalmazás a SharePoint Server 2010-ben. Word Automation Services felügyelet nélküli, kiszolgálóoldali dokumentumkonvertálást biztosít a Microsoft Word ügyfélalkalmazás által támogatott formátumokba.
Word Automation Services áttekintése
A Word Automation Services bemutatása Ki kell értékelnie, hogy a jelen cikkben ismertetett lehetőségek közül melyik felel meg az igényeinek, és hogyan lehet a legjobban üzembe helyezni a megoldást. A cikkben található információk nem garantáltan minden ügyfél összes problémáját megoldják. Javasoljuk, hogy a megoldás üzembe helyezése előtt alaposan tesztelje a megoldást.
