Серверы автоматизации excel что это

Обновлено: 07.07.2024

В данной статье рассматриваются те сложности, с которыми могут столкнуться разработчики. Также в ней предложены альтернативы автоматизации, которые могут повысить производительность. Но разработчикам следует иметь в виду, что рекомендации в данной статье предоставлены исключительно в информационных целях. Корпорация Майкрософт не советует производить и не поддерживает серверной автоматизации Office.

Примечание. В данном контексте системный драйвер Microsoft Office 2007 и ядро СУБД Access 2010 рассматриваются в качестве компонентов Microsoft Office. В этом контексте термин «серверный» относится также к программному коду, который запускается на рабочих станциях под управлением Windows, если его запуск осуществляется с другой рабочей станции Windows (по отношению к станции, на которой работает вошедший в систему пользователь). Например, программы, запущенные планировщиком с помощью учетной записи SYSTEM, выполняются в той же среде, что и «серверный» программный код ASP или DCOM. Следовательно, могут возникнуть многие из рассмотренных в статье проблем. Ссылки на источники дополнительных сведений о рабочих станциях Windows и COM содержатся в разделах «Дополнительные сведения» и «Ссылки» этой статьи.

Дополнительная информация

Все современные версии Microsoft Office были созданы, проверены и настроены для применения на рабочих станциях конечными пользователями. Их использование предполагает наличие интерактивного рабочего места и профиля пользователя. Кроме того, эти продукты не обеспечивают уровень безопасности и возможности повторного входа, удовлетворяющие требованиям серверных компонентов, которые запускаются автоматически.

Если вы создаете решение, которое работает при участии сервера, для автоматизации сначала стоит попытаться использовать специально разработанные для этого компоненты. Или попытаться найти альтернативы, которые позволяют исполнять хотя бы часть кода на стороне клиента. Если вы используете приложение Office в серверном решении, для него будет отсутствовать ряд важных возможностей, необходимых для корректной работы. Кроме того, таким образом вы поставите под угрозу стабильность всего решения в целом.

Проблемы при использовании серверной автоматизации Office

Разработчикам серверных решений для приложений Office необходимо знать о пяти крупных областях, в которых поведение Office отличается от ожидаемого в силу используемой среды. Для успешной работы программ эти отклонения должны быть обязательно учтены, а их влияние минимизировано. Внимательно изучите эти вопросы при создании приложения. Все эти проблемы невозможно устранить одним решением. В зависимости от задач проекта приоритетность элементов будет изменяться.

Идентификация пользователей. Приложения Office, даже в случае запуска в автоматическом режиме, предполагают наличие определенного пользователя. Так, например, инициализация панелей инструментов, меню, параметров, принтеров и некоторых надстроек выполняется на основе конфигурации запустившего приложение пользователя, которая хранится в соответствующем кусте реестра. Многие службы запускаются из учетных записей которые не содержат пользовательских профилей (например, учетная запись SYSTEM или IWAM_[servername]). Поэтому при запуске Office может возникнуть проблема инициализации. При возникновении данной проблемы Office возвращает ошибку функции CreateObject или CoCreateInstance. Даже после успешного запуска приложения Office при отсутствии пользовательского профиля другие функции могут работать некорректно.

Взаимодействие с рабочим столом. Работа приложений Office предполагает наличие интерактивного рабочего стола. В некоторых условиях для корректной работы определенных функций автоматизации приложение необходимо сделать видимым. Office сконструирован таким образом, что всякий раз при возникновении ошибки или необходимости указания параметра выводится соответствующее модальное диалоговое окно. Модальное диалоговое окно на не интерактивном рабочем столе не может быть отвергнуто , что приводит к остановке (зависанию) потока на неопределенное время. Даже если некоторые методы написания программ позволяют снизить возможность возникновения такой ситуации, полностью исключить ее нельзя. Уже только этот факт делает запуск приложений Office из серверного окружения рискованным и непредсказуемым.

Возможность повторного входа и масштабируемость. Серверные компоненты должны представлять собой многопоточные СОМ-компоненты с хорошо развитыми возможностями повторного входа, минимальным использованием ресурсов и высокой производительностью для нескольких клиентов. Приложения Office во многих отношениях обладают прямо противоположными характеристиками. Их возможности повторного входа не развиты, они представляют собой серверы на базе STA, сконструированные для предоставления разнообразных, но ресурсоемких функциональных возможностей одному клиенту. Приложения обладают ограниченной масштабируемостью с точки зрения серверного решения. Кроме того, приложения имеют разные ограничения на важные элементы, например память. Их невозможно изменить в настройках. Что еще более важно, приложения используют глобальные ресурсы, такие как проецируемые в память файлы, глобальные надстройки или шаблоны и общие сервера автоматизации. Это может накладывать ограничения на число запускаемых одновременно экземпляров, что может привести к условиям гонки, если приложения настроены в среде с несколькими клиентами. Если планируется одновременный запуск нескольких экземпляров приложения Office, для предотвращения зависания программы и повреждения данных необходимо рассмотреть возможность объединения в пул или последовательного удовлетворения запросов на доступ к данному приложению.

Устойчивость и стабильность. Office 2000, Office XP, Office 2003 и Office 2007 для упрощения процесса установки и самовосстановления используют установщик Windows (MSI). Одним из принципов работы установщика MSI является «установка при первом использовании». Он позволяет динамически устанавливать и настраивать функции во время работы системы или, чаще, для конкретного пользователя. В серверном окружении это, с одной стороны, снижает производительность, а с другой — увеличивает вероятность того, что появится диалоговое окно с требованием одобрить установку или вставить необходимый диск. Таким образом, повышая устойчивость пакета Office как продукта для конечного пользователя, функции установщика Windows имеют обратный эффект в серверном окружении. Помимо всего прочего, стабильность Office при запуске с сервера не может быть гарантирована в принципе, потому что пакет не был создан и протестирован для такого рода использования. Использование Office в качестве компонента службы на сетевом сервере может снизить стабильность этой машины и, как следствие, сети в целом.

Безопасность на стороне сервера: Приложения Office не были спроектированы для использования на сервере. Поэтому в ходе разработки приложений Office во внимание не принимались те проблемы безопасности, с которыми сталкиваются распределенные компоненты. Office не осуществляет проверку входящих запросов. Office не обеспечивает защиту от непреднамеренного запуска макроса или другого сервера, который, в свою очередь, может запустить макрос. Не открывайте файлы, загруженные на сервер с анонимного веб-узла! На основании последних выполненных настроек сервер может запустить макрос в контексте администратора или системы (а значит, со всеми полномочиями) и повредить сеть! Кроме того, Office использует многие клиентские компоненты (например, Simple MAPI, WinInet и MSDAIPP), которые для ускорения обработки данных кшируют сведения о прохождении клиентами проверки. Если Office был автоматизирован на сервере, один экземпляр может работать более чем с одним клиентом. Если в ходе сессии были кэшированы данные проверки подлинности, кэшированные данные одного клиента могут быть использованы другим. Следовательно, клиент может получить закрытые для него разрешения доступа, выдавая себя за другого пользователя.

Помимо технических проблем, вам также следует учитывать вопросы лицензирования. Применяемые в данный момент времени условия лицензирования предусматривают использование приложений Office на сервере для обслуживания клиентов только в том случае, если клиенты также обладают лицензированными копиями Office. Применение серверной автоматизации для предоставления нелицензированным рабочим станциям доступа к приложениям Office не предусмотрено лицензионным соглашением (EULA).

Помимо этих проблем, при попытке автоматизации Office на сервере могут возникнуть следующие распространенные ошибки:

Ошибка времени выполнения '429': Компоненту ActiveX не удается создать объект

Автоматизация позволяет приложению манипулировать объектами, реализованными в другом приложении, или предоставлять объекты, чтобы их можно было манипулировать. Сервер автоматизации — это приложение, которое предоставляет программируемые объекты (называемые объектами автоматизации) другим приложениям (называемым клиентами автоматизации). Серверы автоматизации иногда называются компонентами автоматизации.

Предоставление объектов автоматизации позволяет клиентам автоматизировать определенные процедуры путем прямого доступа к объектам и функциям, которые сервер делает доступным. Предоставление объектов таким способом полезно, когда приложения предоставляют функциональные возможности, которые удобно использовать для других приложений. Например, текстовый процессор может предоставлять свои функции проверки орфографии, чтобы другие программы могли его использовать. Таким образом, раскрытие объектов позволяет поставщикам улучшить функциональность своих приложений с помощью готовых функций других приложений.

Эти объекты автоматизации имеют свойства и методы в качестве внешнего интерфейса. Свойства являются именованными атрибутами объекта автоматизации. Свойства подобны элементам данных класса C++. Методы — это функции, которые работают с объектами автоматизации. Методы подобны открытым функциям-членам класса C++.

Хотя свойства подобны элементам данных C++, они недоступны напрямую. Чтобы обеспечить прозрачный доступ, настройте внутреннюю переменную в объекте автоматизации с помощью пары функций-членов Get/Set для доступа к ним.

благодаря предоставлению функциональных возможностей приложения через общий, четко определенный интерфейс автоматизации позволяет создавать приложения на едином общем языке программирования, таком как Microsoft Visual Basic, а не на различных языках макросов, зависящих от приложения.

Поддержка серверов автоматизации

Visual C++ и платформа MFC обеспечивают расширенную поддержку серверов автоматизации. Они обрабатывали большую часть издержек, связанных с созданием сервера автоматизации, поэтому вы можете сосредоточиться на работе с функциями приложения.

Основной механизм платформы для поддержки автоматизации — это схема диспетчеризации, набор макросов, который дополняет объявления и вызовы, необходимые для предоставления методов и свойств OLE. Типичная схема диспетчеризации выглядит следующим образом:

Мастер классов и представление классов помогают поддерживать карты диспетчеризации. при добавлении в класс нового метода или свойства Visual Studio добавляет соответствующий DISP_FUNCTION DISP_PROPERTY макрос или с параметрами, указывающими имя класса, внешние и внутренние имена метода или свойства, а также типы данных.

Диалоговое окно Добавление класса также упрощает объявление классов автоматизации и управление их свойствами и операциями. При использовании диалогового окна Добавление класса для добавления класса в проект необходимо указать его базовый класс. Если базовый класс позволяет автоматизировать, в диалоговом окне Добавление класса отображаются элементы управления, используемые для указания того, должен ли новый класс поддерживать автоматизацию, является ли он "OLE-создаваемым" (то есть, можно ли создавать объекты класса в запросе от клиента COM) и внешнее имя для использования клиентом COM.

Затем диалоговое окно Добавление класса создает объявление класса, включая соответствующие макросы для указанных компонентов OLE. Он также добавляет скелет кода для реализации функций члена класса.

Мастер приложений MFC упрощает выполнение действий, связанных с началом работы с сервером автоматизации. Если установить флажок Автоматизация на странице Дополнительные компоненты , мастер приложений MFC добавляет в InitInstance функцию приложения вызовы, необходимые для регистрации объектов автоматизации и запуска приложения в качестве сервера автоматизации.

Все началось около четырех лет назад. Работая над очередным проектом по автоматизации бизнес-процессов для крупной российской сети розничной торговли, я заинтересовался разработкой надстроек для офисных приложений, в частности, для Excel. Стоило мне несколько дней понаблюдать, как сотрудники компании-заказчика тратят уйму времени на рутинные повторяющиеся операции, как у меня появилось множество идей о том, как бы я мог упростить им жизнь.

  • VBA (Visual Basic for Applications);
  • VSTO (Visual Studio Tools for Office).



Думаю, всем разработчикам надстроек для Excel хорошо известны преимущества и недостатки обоих подходов. Большим преимуществом и того, и другого является очень богатое API, позволяющее автоматизировать практически любые задачи. К недостаткам же стоит отнести сложности в установке подобных расширений. Особенно это касается надстроек на базе VSTO, где, зачастую, для инсталляции требуются административные права, получение которых может быть проблематичным для конечных пользователей.

По ряду причин, обсуждение которых выходит за рамки данной статьи, я выбрал для себя вариант с VSTO. Так родилась наша первая надстройка для Microsoft Excel — XLTools. В первую версию продукта вошли инструменты, позволяющие:

  • производить очистку данных в ячейках Excel (удалять лишние пробелы и непечатные символы, приводить регистр к единому виду, и т.д.);
  • преобразовывать таблицы из «двумерного вида» в «плоский» (unpivot);
  • сравнивать данные в столбцах;
  • инструмент для автоматизации всех вышеперечисленных действий.

Появление Office Store

Буквально через год после выхода в свет первой версии надстройки XLTools, мы узнали, что Microsoft запускает новую платформу для продвижения расширений под Office – Office Store. Моя первая мысль – а можем ли мы опубликовать там нашу новую надстройку XLTools? Может к сожалению, а может к счастью, но ответ на этот вопрос – НЕТ. Ни VBA, ни VSTO надстройки не могут быть опубликованы в Office Store. Но стоит ли расстраиваться? К счастью, и здесь ответ – НЕТ, не стоит. Далее я объясню – почему.

Новая концепция Add-Ins для Office

Что же такое Office Store и для чего он нам нужен? Если кратко, то это платформа, которая помогает пользователям и разработчикам искать, скачивать, продавать и покупать надстройки, расширяющие стандартный функционал Office-программ, будь то Excel, Word, Outlook, OneNote или PowerPoint. Если раньше конечным пользователям приходилось искать нужные им надстройки в поисковиках, то сейчас для этого создано единое место – Office Store, доступ к которому возможен прямо из интерфейса офисных программ. Пункт меню «Вставка» -> «Мои надстройки»:


Как мы уже выяснили, опубликовать надстройки, разработанные с использованием VBA или VSTO, в Office Store не получится. С выходом Office 365 и Office Store, Microsoft предложила нам новый способ разработки надстроек с использованием JavaScript API для Office, подразумевающий разработку приложений с использованием веб-технологий, таких как HTML5, CSS, JavaScript и Web Services.

Новый подход обладает как преимуществами, так и недостатками. К преимуществам можно отнести:

  • Простоту установки надстроек из Office Store;
  • Кроссплатформенность из коробки (Excel 2013/2016, Excel Online, Excel for iPad);
  • Возможность использования накопленного опыта веб-разработки (нет необходимости изучать новые технологии, если в команде уже есть веб-разработчики);
  • Готовая инфраструктура, позволяющая продавать надстройки по фиксированной цене или по подписке.
  • Менее богатое API по сравнению с VSTO и VBA (надеюсь, эта проблема будет становиться все менее и менее актуальной с выходом новых версий API).

Разработка надстроек для Excel «по новым правилам»


Итак, с чего же начать, если мы хотим идти в ногу со временем и не упустить новую волну приложений для Office?

Есть два варианта. На текущий момент, разрабатывать приложения на базе JavaScript API мы можем в:

  • Napa – легковесная веб-версия среды разработки для быстрого старта. Будет полезна разработчикам, у которых нет Visual Studio, или тем, кто хочет разрабатывать под операционной системой, отличной от Windows;
  • Visual Studio, начиная с версии 2012, с установленным пакетом Office Developer Tools – более мощная и функциональная среда разработки. Те, кто раньше разрабатывал под VSTO, могут сразу начинать с этого варианта, т.к. Visual Studio у них уже есть.
  • Первое отличие заключается в том, что, разрабатывая надстройки на VBA или VSTO, мы могли создавать так называемые «пакетные» продукты, в состав которых входил целый ряд функций. XLTools является отличным примером – надстройка включает в себя множество опций для работы с ячейками, таблицами, столбцами, и т.д. При разработке надстроек для Office Store о таком подходе придется забыть. Планируя разработку, мы должны задуматься над тем, какие именно законченные, изолированные друг от друга функции мы хотим предоставить конечным пользователям. В случае с XLTools, те функции, которые изначально были реализованы в одной надстройке, сейчас представлены пятью отдельными приложениями в Office Store. Такой подход позволяет сделать решения более узконаправленными и повысить количество скачиваний надстроек целевыми пользователями;
  • Второе отличие заключается в разнице между JavaScript API и VSTO/VBA API. Здесь стоит детально изучить возможности, предоставляемые JavaScript API. Для этого советую воспользоваться приложениями API Tutorial (Task Pane) и API Tutorial (Content) от Microsoft.

Разработка надстройки для Excel c использованием Visual Studio и JavaScript API

По умолчанию в Visual Studio есть предустановленные шаблоны проектов для разработки надстроек под Office Store, поэтому создание нового проекта занимает буквально секунды.


Сам проект состоит из файла-манифеста и веб-сайта. Файл манифеста выглядит так:


Основное, что нужно отметить в этом файле:

  • Id – должен быть уникальным для каждого приложения;
  • Version – должна совпадать с версией, указываемой при публикации надстройки через Seller Dashboard (личный кабинет вендора/разработчика, через который осуществляется все управление надстройками, публикуемыми в Office Store);
  • IconUrl и SupportUrl – ссылки должны быть работающими и указывать на расположение картинки-логотипа и страницы с описанием функционала надстройки. В случае, если ссылки будут указаны неверно, манифест не пройдет проверку при публикации через Seller Dashboard;
  • Permissions – определяет уровень доступа надстройки к данным документа. Может принимать такие значения как Restricted, Read document, Read all document, Write document, Read write document;
  • SourceLocation – путь к «домашней» странице приложения на веб-сайте.
  • Добавление «привязки» к выбранному пользователем диапазону ячеек в Excel для дальнейшей работы с ними:
  • Получение данных из диапазона ячеек с использованием ранее созданной «привязки»:
  • Обновление данных в диапазоне ячеек с использованием ранее созданной «привязки»:

Все методы JavaScript API хорошо документированы, их подробное описание можно посмотреть на сайте MSDN.

В зависимости от сценария, обработка данных может происходить как непосредственно на клиенте, т.е. в JavaScript-коде, так и на сервере. Для обработки данных на сервере можно добавить нужные сервисы прямо на сайт, к примеру, с использованием Web API. Общение клиента (надстройки) с веб-сервисами происходит так же, как мы привыкли это делать на любом другом сайте – при помощи AJAX-запросов. Единственное, что нужно учитывать – если Вы планируете использовать сторонние сервисы, расположенные на чужих доменах, то непременно столкнетесь с проблемой same-origin policy.

Публикация надстройки в Office Store


Выводы

В заключение стоит сказать, что надстройки XLTools являются отличным примером того, как можно трансформировать существующие решения на базе технологий VBA/VSTO в кроссплатформенные решения для Office 365. В нашем случае, мы смогли перенести в Office Store добрую половину функций из Desktop-версии XLTools, реализовав шесть отдельных приложений.

Поводом для заметки послужила статья на Хабре, в которой автор описывал, как он решал на Python задачу сбора и анализа метаданных из файлов Excel.

Эта заметка более подробно раскрывает всем известный тезис: Под конкретную задачу надо выбирать наиболее подходящий инструмент применимо к офисной автоматизации.

VBA и Python

VBA (Visual Basic for Applications), де-факто, самый популярный язык для автоматизации Microsoft Office. Доступен из коробки, помимо Excel, работает в PowerPoint, Outlook, Access, Project и других приложениях.

Если задать вопрос: «Какой язык программирования выбрать первым», то где-то в 90% всех случаев будет предложен Python. На практике здесь может быть и любой другой язык, но, исходя из популярности языка и своего опыта, буду сравнивать с ним.

В общем виде можно описать ситуацию через подобный график:


Детального сравнения не будет, рассмотрим основные killer-фичи, в ситуации, когда junior-программист/офисный сотрудник хочет автоматизировать что-либо, связанное с MS Office, и у него есть возможность выбора между языками.

Если в силу разных причин возможности выбора нет, то и сравнивать нечего.

В пользу VBA


  • Отличная работа с объектной моделью Excel и других приложений MS Office. Написание кода на VBA для большинства внутренних операций тривиально. У Python, в сравнении с VBA, поддержка объектной модели Office очень слабая.
  • Поддержка разных форматов MS Office. Самая большая проблема для внешних языков — это работа с разными форматами файлов MS Office. Например, xls, xlsx, xlsm файлы могут требовать разных библиотек, так как каждая хорошо работает только со своим форматом файла. Для VBA — это все "файл Excel", работа с которыми в целом одинаково хороша.
  • Работа с MS Exchange. Если необходимо обеспечить работу с корпоративной почтой/календарем на Exchange, то далеко не каждом языке есть нормальная библиотека для работы протоколом Exchange. В VBA это решается относительно просто через использование в макросе объектной модели MS Outlook.
  • Легкая установка и дистрибуция. К уже установленному офису не надо ничего устанавливать. Чтобы коллега мог воспользоваться программой, достаточно передать ему файл с макросом. Легко сделать надстройку, которая позволит "установить" модель макроса в фон офиса.
  • Интерактивность внутри приложений MS Office. Внутри офисных программ можно как просто поставить кнопки запуска макросов, так и (чуть сложнее) сделать целый отдельный UI. Сюда же относится написание своих формул в Excel и то, что макросы могут воздействовать на объекты внутри документов Office в реальном времени.
  • Запись макросов. Удобный инструмент, который позволяет записать действия человека в готовый код, для последующего редактирования использования.

В пользу Python (и других внешних языков программирования)


  • Приятный синтаксис и синтаксический сахар. Если коротко, то VBA не отличается выразительностью и удобством. Это вопрос личного вкуса, но для меня Python намного удобнее.
  • Богатая экосистема библиотек. Огромный выбор готовых библиотек для работы с внешним миром. Пытаться сделать на VBA программу, взаимодействующую с каким-нибудь внешним API, та еще боль. Занимательно, что как раз для работы с файлами Office библиотеки того же Python — откровенно "на троечку".
  • Хорошие средства разработки. Можно выбрать из огромного выбор программ, которые облегчают процесс разработки. Стандартный редактор VBA из Office предлагает очень бедный функционал и, в сравнении с альтернативами из мира Python, откровенно неудобен. Писать код VBA в внешнем редакторе, а потом копировать внутрь офиса для отладки — тоже неудобно.
  • Скорость работы. Не проверял скорость однопоточной работы, но, предположу, что в случае однопоточной работы преимущество будет за Python. В любом случае, достаточно тривиально организуется многопоточная обработка данных/файлов, что позволяет говорить в большей достижимой скорости.

Кейсы


Далее приведены конкретные задачи, которые я сам решал или автоматизировал, и когда мне надо было выбрать стек: VBA или Python. Для каждой задачи указан выбранный стек и даны пояснения почему:

  • Задача: Программа для проверки всех файлов Excel в директории на предмет наличия скрытых листов
    • Мой выбор: VBA. Причины: простота работы с разными форматами файлов Excel и отсутствие внешних взаимодействий.
    • Сервис был реализован как почтовый бот, на адрес которого пользователь может переслать файлы Office, а в ответ пользователю по почте приходит ответ с файлами PDF.
    • Мой выбор: Логика VBA + Python для мониторинга
      • Во-первых, внутренние функции гарантированно сохраняли PDF, аутентичный файлу PowerPoint (внешние библиотеки плохо справляются с рендером PowerPoint).
      • Во-вторых, реализация почтового бота, как макроса в MS Outlook решала проблемы работы с корпоративной Exchange почтой. Так, в Python нет нормальной библиотеки для работы с MS Exchange.
      • Python использовался для организации мониторинга работы сервиса и нотификации о возможных проблемах
      • Мой выбор: VBA. Задача решалась через конвертацию двух файлов в PDF и их объединением с Riffle Shuffle. Так как важно качество конвертации в PDF, то использовались встроенные функции офиса для экспорта в PDF.
      • Мой выбор: Python.
        • Чтобы вытаскивать из html карточек данные пригодилась библиотека для парсинга html BeautifulSoup.
        • Excel-файл создает программа, поэтому мы сами можем решать, какую аналитику рассчитывать уже в нем, а какую еще на стадии подготовки данных в Python.
        • Мой выбор: VBA. Важно было аккуратно работать с текстом во внутренних объектах файла PowerPoint. Для перевода использовался API от Яндекса, так как он бесплатен для небольших объемов и прост в подклюении. Например, API переводчика Bing я так и не смог заставить работать в VBA, так как там для работы нужен OAuth со своими заморочками. Если бы пришлось работать с Bing, то, наверное, я бы делал сервис-посредник на Python.
        • Мой выбор: Python. Хотя API — простой (не требует какой-либо подписи запросов или авторизации) и выдает данные в CSV, выбран Python, так как нет причин выбирать VBA, а на Python писать удобнее.