Podsumowanie
Deweloperzy mogą używać automatyzacji w pakiecie Microsoft Office do tworzenia rozwiązań niestandardowych korzystających z funkcji i funkcji wbudowanych w produkt pakietu Office. Chociaż taki programistyczny rozwój można zaimplementować w systemie klienckim z względną łatwością, może wystąpić wiele komplikacji, jeśli automatyzacja odbywa się z kodu po stronie serwera, takiego jak Microsoft Active Server Pages (ASP), ASP.NET, DCOM lub usługa Windows NT.
W tym artykule omówiono komplikacje, które mogą napotkać deweloperzy. Ten artykuł zawiera również alternatywy dla automatyzacji, które mogą przyspieszyć wydajność. Deweloperzy powinni jednak pamiętać, że sugestie podane w tym artykule są przeznaczone tylko do celów informacyjnych. Firma Microsoft nie zaleca ani nie obsługuje automatyzacji pakietu Office po stronie serwera.
Uwaga: W tym kontekście pakiety redystrybucyjne aparatu bazy danych programu Access i środowisko uruchomieniowe programu Access są traktowane jako składniki pakietu Microsoft Office. Termin "po stronie serwera" ma również zastosowanie do kodu uruchomionego na stacji roboczej systemu Windows, jeśli kod jest uruchomiony ze stacji roboczej systemu Windows innej niż interakcyjna stacja użytkownika, który jest zalogowany. Na przykład kod uruchamiany przez Harmonogram zadań na koncie SYSTEM działa w tym samym środowisku co kod ASP "po stronie serwera" lub jako kod DCOM. Dlatego może wystąpić wiele problemów, które opisano w tym artykule. Aby uzyskać więcej informacji na temat stacji roboczych systemu Windows i com, zobacz sekcję "Więcej informacji" i sekcję "Odwołania".
Więcej informacji
Wszystkie bieżące wersje pakietu Microsoft Office zostały zaprojektowane, przetestowane i skonfigurowane do uruchamiania jako produkty dla użytkowników końcowych na stacji roboczej klienta. Zakładają interakcyjny profil pulpitu i użytkownika. Nie zapewniają one poziomu ponownego wpisania ani zabezpieczeń niezbędnych do zaspokojenia potrzeb składników po stronie serwera, które są przeznaczone do uruchamiania bez nadzoru.
Firma Microsoft obecnie nie zaleca i nie obsługuje automatyzacji aplikacji pakietu Microsoft Office z żadnych nienadzorowanych, nieinterakcyjnych aplikacji lub składników klienta (w tym usług ASP, ASP.NET, DCOM i NT), ponieważ pakiet Office może wykazywać niestabilne zachowanie i/lub zakleszczenie podczas uruchamiania pakietu Office w tym środowisku.
Jeśli konstruujesz rozwiązanie działające w kontekście po stronie serwera, spróbuj użyć składników, które zostały zabezpieczone do wykonywania bez nadzoru. Możesz też spróbować znaleźć alternatywy umożliwiające uruchamianie co najmniej części kodu po stronie klienta. Jeśli używasz aplikacji pakietu Office z rozwiązania po stronie serwera, aplikacja nie będzie mieć wielu niezbędnych funkcji do pomyślnego uruchomienia. Ponadto będziesz podejmować ryzyko ze stabilnością ogólnego rozwiązania.
Problemy z automatyzacją po stronie serwera pakietu Office
Deweloperzy, którzy próbują korzystać z pakietu Office w rozwiązaniu po stronie serwera, muszą mieć świadomość pięciu głównych obszarów, w których pakiet Office zachowuje się inaczej niż przewidywano ze względu na środowisko. Jeśli kod ma zostać pomyślnie uruchomiony, musisz rozwiązać te problemy i zminimalizować ich efekty w jak najszerszym zakresie. Podczas tworzenia aplikacji należy dokładnie rozważyć te problemy. Jedno rozwiązanie nie może rozwiązać wszystkich problemów. Różne projekty wymagają innego priorytetu elementów.
-
Tożsamość użytkownika: Aplikacje pakietu Office przyjmują tożsamość użytkownika podczas uruchamiania aplikacji, nawet gdy automatyzacja uruchamia aplikacje. Aplikacje próbują inicjować paski narzędzi, menu, opcje, drukarki i niektóre dodatki na podstawie ustawień w gałęzi rejestru użytkownika, który uruchamia aplikację. Wiele usług jest uruchamianych na kontach, które nie mają profilów użytkowników (takich jak konto SYSTEM lub konta IWAM_[nazwa_serwera]). Dlatego pakiet Office może nie inicjować poprawnie podczas uruchamiania. W takiej sytuacji pakiet Office zwraca błąd dotyczący funkcji CreateObject lub funkcji CoCreateInstance. Nawet jeśli można włączyć aplikację pakietu Office, inne funkcje mogą nie działać poprawnie, jeśli nie istnieje żaden profil użytkownika.
-
Interakcje z pulpitem: Aplikacje pakietu Office zakładają, że są one uruchamiane pod interakcyjnym pulpitem. W pewnych okolicznościach aplikacje mogą być widoczne, aby niektóre funkcje automatyzacji działały poprawnie. Jeśli wystąpi nieoczekiwany błąd lub do wykonania funkcji potrzebny jest nieokreślony parametr, pakiet Office zostanie zaprojektowany w celu wyświetlenia monitu o wyświetlenie użytkownikowi modalnego okna dialogowego z pytaniem, co użytkownik chce zrobić. Nie można odrzucić modalnego okna dialogowego na nieinterakcyjnym pulpicie. W związku z tym ten wątek przestaje odpowiadać (zawiesza się) na czas nieokreślony. Chociaż niektóre praktyki kodowania mogą zmniejszyć prawdopodobieństwo wystąpienia tego problemu, te rozwiązania nie mogą całkowicie zapobiec problemowi. Sam ten fakt sprawia, że uruchamianie aplikacji pakietu Office ze środowiska po stronie serwera jest ryzykowne i nieobsługiane.
-
Reentrancy i skalowalność: Składniki po stronie serwera muszą być wysoce reentrant, wielowątkowe składniki COM, które mają minimalną obciążenie i wysoką przepustowość dla wielu klientów. Aplikacje pakietu Office są niemal pod każdym względem dokładnie odwrotnie. Aplikacje pakietu Office nie są serwerami automatyzacji opartymi na sta, które są zaprojektowane tak, aby zapewnić zróżnicowane, ale mocno obciążające zasoby funkcje dla jednego klienta. Aplikacje oferują niewielką skalowalność jako rozwiązanie po stronie serwera. Ponadto aplikacje mają stałe limity dotyczące ważnych elementów, takich jak pamięć. Nie można ich zmienić za pomocą konfiguracji. Co ważniejsze, aplikacje korzystają z zasobów globalnych, takich jak zamapowane pliki pamięci, globalne dodatki lub szablony oraz udostępnione serwery automatyzacji. Może to ograniczyć liczbę wystąpień, które mogą działać jednocześnie i może prowadzić do sytuacji wyścigu, jeśli aplikacje są skonfigurowane w środowisku wielu klientów. Deweloperzy, którzy planują jednocześnie uruchomić więcej niż jedno wystąpienie dowolnej aplikacji pakietu Office, muszą rozważyć "łączenie pul" lub serializowanie dostępu do aplikacji pakietu Office, aby uniknąć potencjalnych zakleszczeń lub uszkodzenia danych.
-
Odporność i stabilność: Pakiety Office 2000, Office XP, Office 2003 i Office 2007 używają technologii Instalatora Microsoft Windows (MSI) w celu ułatwienia instalacji i samodzielnej naprawy użytkownikowi końcowi. Msi wprowadza koncepcję "instalowania przy pierwszym użyciu". Dzięki temu funkcje mogą być instalowane dynamicznie lub konfigurowane w czasie wykonywania systemu lub częściej dla określonego użytkownika. W środowisku po stronie serwera powoduje to spowolnienie wydajności i zwiększa prawdopodobieństwo wyświetlenia okna dialogowego z prośbą o zatwierdzenie instalacji lub udostępnienie dysku instalacyjnego. Mimo że ma to na celu zwiększenie odporności pakietu Office jako produktu użytkownika końcowego, implementacja funkcji MSI przez pakiet Office przynosi efekty odwrotne do zamierzonych w środowisku po stronie serwera. Ponadto stabilności pakietu Office w ogóle nie można zapewnić, gdy pakiet Office jest uruchamiany po stronie serwera, ponieważ nie został zaprojektowany lub przetestowany pod kątem tego typu użytkowania. Korzystanie z pakietu Office jako składnika usługi na serwerze sieciowym może zmniejszyć stabilność tego komputera, a tym samym może zmniejszyć stabilność całej sieci.
-
Zabezpieczenia po stronie serwera: aplikacje pakietu Office nigdy nie były przeznaczone do użytku po stronie serwera. Dlatego aplikacje pakietu Office nie uwzględniają problemów z zabezpieczeniami, które napotykają rozproszone składniki. Pakiet Office nie uwierzytelnia żądań przychodzących. Pakiet Office nie chroni też przed niezamierzonym uruchamianiem makr ani przed uruchomieniem innego serwera, na który mogą być uruchamiane makra, z poziomu kodu po stronie serwera. Nie otwieraj plików przekazywanych na serwer z anonimowej witryny sieci Web. Na podstawie ostatnio ustawionych ustawień zabezpieczeń serwer może uruchamiać makra w kontekście administratora lub systemu z pełnymi uprawnieniami, co może stanowić zagrożenie dla twojej sieci. Ponadto pakiet Office używa wielu składników po stronie klienta (takich jak Simple MAPI, WinInet i MSDAIPP), które mogą buforować informacje o uwierzytelnianiu klienta, aby przyspieszyć przetwarzanie. Jeśli pakiet Office jest zautomatyzowany po stronie serwera, jedno wystąpienie może obsługiwać więcej niż jednego klienta. Jeśli informacje uwierzytelniania zostały buforowane dla tej sesji, jeden klient może korzystać z buforowanych poświadczeń innego klienta. W związku z tym klient może uzyskać uprawnienia dostępu bez udzielenia, podszywając się pod innych użytkowników.
Oprócz problemów technicznych należy również rozważyć kwestie licencjonowania. Bieżące wytyczne dotyczące licencjonowania uniemożliwiają używanie aplikacji pakietu Office na serwerze do obsługi żądań klientów, chyba że sami klienci mają licencjonowane kopie pakietu Office. Korzystanie z automatyzacji po stronie serwera w celu zapewnienia funkcji pakietu Office dla nielicencjonowanych stacji roboczych nie jest objęte umową licencyjną użytkownika końcowego.
Oprócz tych problemów podczas próby zautomatyzowania działania po stronie serwera pakietu Office może wystąpić jeden z następujących typowych błędów:
-
Funkcja CreateObject i funkcja CoCreateInstance zwracają jeden z następujących komunikatów o błędach w czasie wykonywania i nie można ich uruchomić w przypadku automatyzacji.
Wiadomość 1
Błąd "429": składnik ActiveX nie może tworzyć obiektu
Wiadomość 2
Błąd "70" w czasie wykonywania: odmowa uprawnień
Wiadomość 3
CO_E_SERVER_EXEC_FAILURE (0x80080005): Wykonanie serwera nie powiodło się
Wiadomość 4
E_ACCESSDENIED (0x80070005): Odmowa dostępu
-
Po otwarciu dokumentu pakietu Office jest wyświetlany jeden z następujących komunikatów o błędach.
Wiadomość 1
Błąd "5981" (0x800A175D): Nie można otworzyć magazynu makr
Wiadomość 2
Błąd czasu wykonywania '1004': metoda '~' obiektu '~' nie powiodła się
-
Funkcja CreateObject i funkcja CoCreateInstance przestają odpowiadać i nigdy nie kończą się lub zwróć je długo. Na niektórych serwerach tworzenie jest szybkie, ale w dzienniku zdarzeń systemu Windows pojawia się 1004 błędy wskazujące, że aplikacja została zatrzymana.
-
Niektóre funkcje nieoczekiwanie nie działają lub przestają odpowiadać na czas nieokreślony z powodu alertu użytkownika lub innego okna dialogowego wymagającego uwagi użytkownika.
-
Uruchomienie wielu żądań lub testów warunków skrajnych powoduje, że kod kończy się niepowodzeniem, przestaje odpowiadać lub ulega awarii podczas tworzenia lub zakończenia aplikacji pakietu Office. W takim przypadku proces pozostaje uruchomiony w pamięci i nie można go zakończyć, albo wszystkie wystąpienia aplikacji, która jest zautomatyzowana, kończą się niepowodzeniem od tego momentu.
Oprócz tych wymienionych tutaj mogą pojawić się inne problemy lub komunikaty, ale zwykle występują one w wyniku pięciu głównych problemów wymienionych wcześniej w tym artykule.
Alternatywy dla automatyzacji po stronie serwera
Firma Microsoft zdecydowanie zaleca deweloperom znalezienie alternatywy dla automatyzacji pakietu Office, jeśli muszą opracować rozwiązania po stronie serwera. Ze względu na ograniczenia projektu pakietu Office zmiany w konfiguracji pakietu Office nie wystarczą, aby rozwiązać wszystkie problemy. Firma Microsoft zdecydowanie zaleca szereg rozwiązań alternatywnych, które nie wymagają instalowania pakietu Office po stronie serwera, a także umożliwiają wykonywanie najbardziej typowych zadań wydajniej i szybciej niż w przypadku automatyzacji. Zanim włączysz pakiet Office jako składnik po stronie serwera w projekcie, rozważ rozwiązania alternatywne.
Większość zadań automatyzacji po stronie serwera obejmuje tworzenie lub edytowanie dokumentów. Pakiet Office 2007 obsługuje nowe formaty plików Open XML, które umożliwiają deweloperom tworzenie, edytowanie, odczytywanie i przekształcanie zawartości plików po stronie serwera. Te formaty plików używają System.IO.Package.IO przestrzeni nazw w programie Microsoft .NET 3.x Framework do edytowania plików pakietu Office bez używania samych aplikacji klienckich pakietu Office. Jest to zalecana i obsługiwana metoda obsługi zmian w plikach pakietu Office z usługi.
Formaty plików Open XML są standardem publicznym.
Firma Microsoft udostępnia pakiet SDK do manipulowania formatami plików Open XML za pomocą programu .NET 3.x Framework. Aby uzyskać więcej informacji o zestawie SDK oraz sposobie tworzenia i edytowania plików Open XML za pomocą tego narzędzia, odwiedź następujące witryny sieci Web Microsoft Developer Network (MSDN):
Jak to zrobić: Manipulowanie dokumentami w formacie Open XML pakietu Office
Manipulowanie plikami Word 2007 za pomocą modelu obiektów Open XML (część 1 z 3)
Manipulowanie plikami Word 2007 za pomocą modelu obiektów Open XML (część 2 z 3)
Manipulowanie plikami Word 2007 za pomocą modelu obiektów Open XML (część 3 z 3)
Podczas przesyłania strumieniowego plików Open XML z asp lub z ASP.NET musisz podać prawidłowy typ rozszerzenia MIME (Multipurpose Internet Mail Extension) dla zawartości przesyłanej strumieniowo. Aby uzyskać listę typów mime plików pakietu Office 2007, odwiedź następującą witrynę internetową:
Typy MIME formatu plików pakietu Office 2007 do strumieniowego przesyłania zawartości HTTP
Jeśli docelowo dotyczy tylko klientów pakietu Office 2007 i nie chcesz wymagać używania w rozwiązaniu formatu Open XML, możesz użyć innych niebinarnych formatów plików pakietu Office, takich jak HTML, XML i RTF. Następnie możesz przesyłać strumieniowo te pliki do klienta, używając typu MIME, aby wynikowy tekst pojawiał się w pakiecie Office. Dokument można edytować, zapisywać, a nawet wrócić na serwer przy użyciu protokołu ASP na serwerze.
Aby uzyskać więcej informacji na dowolny z tych tematów oraz przykłady dotyczące sposobu ich zaimplementowania, kliknij poniższe numery artykułów, aby wyświetlić artykuły z bazy wiedzy Microsoft Knowledge Base:
198703 Jak zautomatyzować program Excel z poziomu języka VBScript po stronie klienta
Jak kwerendować i aktualizować dane programu Excel przy użyciu modelu ADO z asp
286023 Jak używać składnika ActiveX języka VB do automatyzacji Word z programu Internet Explorer
Jeśli Twoja firma wymaga tworzenia formatów plików binarnych pakietu Office 97, Office 2000, Office XP i Office 2003 po stronie serwera, zewnętrzni dostawcy oferują składniki, które mogą Ci pomóc. Firma Microsoft nie udostępnia takich składników, dlatego musisz samodzielnie utworzyć rozwiązanie lub kupić je u innego dostawcy. Dostępnych jest wiele różnych produktów innych firm. Należy zbadać każde rozwiązanie, aby najlepiej dopasować dostawcę do potrzeb biznesowych.
Jeśli chcesz utworzyć własne rozwiązanie, które bezpośrednio edytuje formaty plików binarnych pakietów Office 97, Office 2000, Office XP i Office 2003, możesz uzyskać specyfikacje formatu plików bezpłatnie zgodnie z warunkami obietnicy otwarcia specyfikacji firmy Microsoft (OSP). Nie jest dostępna żadna pomoc techniczna dla dokumentacji ani dla tworzonych produktów, ale jest dostępna dokumentacja.
Rozwiązania po stronie serwera mogą również zezwalać użytkownikom na przekazywanie plików, a następnie umożliwić renderowanie plików na serwerze do wyświetlania w sieci Web lub na innych nośnikach. Firma Microsoft pracuje obecnie nad oferowaniem takich funkcji i udostępnia wczesną wersję tej funkcji w programie Microsoft Usługi programu Excel.
Usługi programu Excel to nowa technologia serwerowa dołączona do programu Microsoft Office SharePoint Server 2007 umożliwiająca ładowanie, obliczanie i wyświetlanie skoroszytów programu Excel w programie Office SharePoint Server 2007. Aby uzyskać więcej informacji na temat Usługi programu Excel, odwiedź następujące witryny sieci Web Microsoft Developer Network (MSDN):
Usługi programu Excel — omówienie
Inicjał: tworzenie aplikacji niestandardowej przy użyciu usług sieci Web programu Excel
Tworzenie aplikacji biznesowych przy użyciu Usługi programu Excel i otwartych formatów XML pakietu Office Word Automation Services to nowa aplikacja usługi w programie SharePoint Server 2010. Word Automation Services zapewnia bez nadzoru konwersję dokumentów po stronie serwera na formaty obsługiwane przez aplikację kliencką firmy Microsoft Word.
Omówienie usług automatyzacji Word
Wprowadzenie do usług automatyzacji Word Musisz ocenić, które opcje opisane w tym artykule odpowiadają Twoim potrzebom i jak najlepiej wdrożyć rozwiązanie. Informacje podane w tym artykule nie są gwarantowane, aby rozwiązać wszystkie problemy dla wszystkich klientów. Zaleca się dokładne przetestowanie rozwiązania przed wdrożeniem rozwiązania.
