Файл Excel можно сохранить в другом формате. Для этого на вкладке Файл выберите пункт Сохранить как . Форматы файлов, доступные в диалоговом окне Сохранение документа , зависят от типа активного листа (обычный лист, лист диаграммы или другой тип листа).
Примечание: При сохранении файла в другом формате может быть утрачена часть форматирования, данных и возможностей.
Чтобы открыть файл, созданный в другом формате (в более ранней версии Excel или в другой программе), откройте вкладку Файл и выберите команду Открыть . Книги Excel 97-2003 автоматически открываются в режиме совместимости. Чтобы получить доступ ко всем новым возможностям Excel 2010, сохраните эту книгу в формате Excel 2010. Однако можно продолжать работать в режиме совместимости, сохраняя исходный формат файла для обратной совместимости.
Форматы файлов Excel
Формат | Расширение | Описание |
|---|---|---|
|
Книга Excel |
Стандартный формат файлов Excel 2010 и Excel 2007, основанный на языке XML. В этом формате нельзя сохранять код макросов Microsoft Visual Basic для приложений (VBA) и листы макросов Microsoft Office Excel 4.0 (XLM). |
|
|
Книга Excel с поддержкой макросов |
Формат Excel 2016, Excel 2013, Excel 2010 и Excel 2007 на основе XML с поддержкой макросов. Позволяет сохранять код макросов VBA и листы макросов Microsoft Excel 4.0 (XLM). |
|
|
Двоичная книга Excel |
Формат двоичных файлов (BIFF12) для Excel 2010 и Excel 2007. |
|
|
Формат файлов по умолчанию для шаблонов Excel в приложениях Excel 2010 и Excel 2007. В этом формате нельзя сохранять код макросов VBA и листы макросов Excel 4.0 (XLM). |
||
|
Шаблон (код) |
Формат файлов с поддержкой макросов для шаблонов Excel в приложениях Excel 2010 и Excel 2007. В этом формате можно сохранять код макросов VBA и листы макросов Excel 4.0 (XLM). |
|
|
Книга Excel 97-2003 |
Формат двоичных файлов Excel 97-Excel 2003 (BIFF8). |
|
|
Шаблон Excel 97-2003 |
Формат двоичных файлов Excel 97-Excel 2003 (BIFF8) для хранения шаблонов Excel. |
|
|
Книга Microsoft Excel 5.0/95 |
Формат двоичных файлов Excel 5.0/95 (BIFF5). |
|
|
XML-таблица 2003 |
Формат файлов XML-таблиц 2003 (XMLSS). |
|
|
Данные XML Data |
Формат данных XML. |
|
|
Надстройка Microsoft Excel |
Формат файлов надстроек Excel 2010 и Excel 2007 на основе XML с поддержкой макросов. Надстройка - это программа, обеспечивающая возможность выполнения дополнительного кода. Позволяет использовать проекты VBA и листы макросов Excel 4.0 (XLM). |
|
|
Надстройка Excel 97-2003 |
Надстройка Excel 97-2003, дополнительная программа, предназначенная для выполнения дополнительного кода. Поддерживает использование проектов VBA. |
|
|
Книга Excel 4.0 |
Формат файла Excel 4.0, в котором сохраняются только обычные листы, листы диаграмм и макросов. В приложении Excel 2010 можно открыть книгу в этом формате, но сохранить в нем файл Excel нельзя. |
|
|
Таблица, сохраненная в приложении Microsoft Works версий 6.0-9.0. Примечание: Этот формат поддерживается только в Excel Starter. |
Форматы текстовых файлов
Формат | Расширение | Описание |
|---|---|---|
|
Формат для Lotus с разделителями в виде пробелов. Сохраняется только активный лист |
||
|
Сохраняет книгу в виде текстового файла, разделенного знаками табуляции, для использования в другой операционной системе Microsoft Windows и гарантирует, что символы табуляции, разрывы строк и другие знаки будут интерпретироваться правильно. Сохраняется только активный лист. |
||
|
Текст (Macintosh) |
Сохраняет книгу в виде текстового файла, разделенного знаками табуляции, для использования в операционной системе Macintosh и гарантирует, что символы табуляции, разрывы строк и другие знаки будут интерпретироваться правильно. Сохраняется только активный лист. |
|
|
Текст (MS-DOS) |
Сохраняет книгу в виде текстового файла, разделенного знаками табуляции, для использования в операционной системе MS-DOS и гарантирует, что символы табуляции, разрывы строк и другие знаки будут интерпретироваться правильно. Сохраняется только активный лист. |
|
|
Текст в Юникоде |
Сохраняет книгу в виде текста в Юникоде - стандартной кодировке символов, разработанной организацией Unicode Consortium. |
|
|
CSV (разделители - запятые) |
Сохраняет книгу в виде текстового файла с разделителями-запятыми для использования в другой операционной системе Windows и гарантирует, что символы табуляции, разрывы строк и другие знаки будут интерпретироваться правильно. Сохраняется только активный лист. |
|
|
Сохраняет книгу в виде текстового файла с разделителями-запятыми для использования в операционной системе Macintosh и гарантирует, что символы табуляции, разрывы строк и другие знаки будут интерпретироваться правильно. Сохраняется только активный лист. |
||
|
Сохраняет книгу в виде текстового файла с разделителями-запятыми для использования в операционной системе MS-DOS и гарантирует, что символы табуляции, разрывы строк и другие знаки будут интерпретироваться правильно. Сохраняется только активный лист. |
||
|
Формат обмена данными. Сохраняет только активный лист. |
||
|
Формат Symbolic Link. Сохраняет только активный лист. |
Примечание: При сохранении книги в любом текстовом формате теряются все элементы форматирования.
Другие форматы файлов
Формат | Расширение | Описание |
|---|---|---|
|
dBase III и IV. Файлы этого формата можно открывать в Microsoft Excel, но сохранять файлы Microsoft Excel в формате dBase нельзя. |
||
|
Таблица OpenDocument |
Таблица OpenDocument. Файлы приложения Excel 2010 можно сохранять в формате, который позволяет открывать их в приложениях электронных таблиц, поддерживающих формат таблиц OpenDocument, таких как Google Docs или OpenOffice.org Calc. Таблицы в формате ODS также можно открывать в приложении Excel 2010. При сохранении и открытии ODS-файлов может быть потеряно форматирование. |
|
|
Этот формат файла сохраняет форматирование документа и позволяет совместно использовать файлы. Формат PDF гарантирует, что при просмотре файла на компьютере и при его печати будет сохранено исходное форматирование и данные файла нельзя будет легко изменить. Формат PDF также удобно использовать для печати документов в типографии. Примечание: |
||
|
Документ XPS |
Этот формат файла сохраняет форматирование документа и позволяет совместно использовать файлы. Формат XPS гарантирует, что при просмотре файла на компьютере и при его печати будет сохранено исходное форматирование и данные файла нельзя будет легко изменить. Примечание: Этот формат не поддерживается в Excel 2007. |
Форматы файлов, использующие буфер обмена
Из буфера обмена Microsoft Office в Microsoft Excel с помощью команд Вставить или Специальная вставка (вкладка Главная , группа Буфер обмена , кнопка Вставить ) можно вставить данные перечисленных ниже форматов.
Формат | Расширение | Идентификаторы типа буфера обмена |
|---|---|---|
|
Рисунки в формате Windows Metafile (WMF) или Windows Enhanced Metafile (EMF). Примечание При копировании метафайла Windows (WMF) из другой программы Microsoft Excel вставляет рисунок в виде расширенного метафайла (EMF). |
||
|
Точечный рисунок |
Рисунки, сохраненные в растровом формате (BMP). |
|
|
Форматы файлов Microsoft Excel |
Двоичные форматы файлов для Excel версий 5.0/95 (BIFF5), Excel 97-2003 (BIFF8) и приложения Excel 2010 (BIFF12). |
|
|
Формат Symbolic Link. |
||
|
Формат обмена данными. |
||
|
Текст (разделители - знаки табуляции) |
Текстовый формат со знаками табуляции в качестве разделителей. |
|
|
CSV (разделители - запятые) |
Формат с разделителями-запятыми |
|
|
Форматированный текст (разделители - пробелы) |
RTF. Только из Excel. |
|
|
Внедренный объект |
GIF, JPG, DOC, XLS или BMP |
Объекты Microsoft Excel, объекты правильно зарегистрированных программ, поддерживающих OLE 2.0 (OwnerLink), а также Picture или другой формат презентации |
|
Связанный объект |
GIF, JPG, DOC, XLS или BMP |
OwnerLink, ObjectLink, Link, Picture или другой формат. |
|
Рисованный объект Office |
Формат объекта-рисунка Office или Picture (EMF). |
|
|
Отображаемый текст, текст ПВТ. |
||
|
Веб-страница в одном файле |
Веб-страница в одном файле (MHT или MHTML). Этот формат файла объединяет встроенные рисунки, приложения, связанные документы и другие вспомогательные элементы, на которые есть ссылки в документе. Примечание: Этот формат не поддерживается в Excel 2007. |
|
|
Веб-страница |
Формат HTML. Примечание: При копировании текста из другой программы Microsoft Excel вставляет этот текст в формате HTML независимо от формата исходного текста. |
Форматы файлов, не поддерживаемые в Excel
Указанные ниже форматы файлов больше не поддерживаются в Excel 2016, Excel 2013, Excel 2010, Excel Starter и Excel 2007. Открывать такие файлы или сохранять файлы в этих форматах невозможно.
Форматы файлов, не поддерживаемые в Excel Starter
Кроме того, в Excel Starter больше не поддерживаются форматы файлов, указанные ниже. Открывать такие файлы или сохранять файлы в этих форматах невозможно.
Открытие и просмотр файлов в неподдерживаемых форматах
Если Microsoft Excel не поддерживает формат файлов, который предполагается использовать, можно предпринять действия, описанные ниже.
Попробуйте найти в Интернете компанию, выпускающую конвертеры файлов для форматов, не поддерживаемых Excel.
Интеграционная шина данных предназначена для построения композитных приложений, использующих различные стандарты и технологии взаимодействия, построенные по разным принципам. Особое внимание уделено интеграции приложений на платформе «1С:Предприятие».
Поддержка различных стандартов и сценариев интеграции с помощью интеграционной шины данных
Довольно часто при построении композитных приложений приходится сталкиваться с ситуацией, когда различные типы приложений рассчитаны на различные стандарты и схемы интеграции. Также не редка ситуация, когда изменение интеграционных механизмов существующих приложений невозможно или трудоемко по ряду причин: отсутствие разработчика, отсутствие исходного кода и т.д. Интеграционная шина позволяет объединять такие приложения в единое целое, скрывая различия в интеграции на уровне механизмов и настроек типовых коннекторов , что приводит взаимодействие приложений к единой управляемой схеме интеграции.
В DATAREON ESB существуют следующие типы коннекторов:
- Коннектор SOAP-сервисов, включая web-сервисы «1С:Предприятие 8»
- Коннектор REST-сервисов, включая web-сервисы «1С:Предприятие 8»
- Коннектор MS SQL
- Коннектор IBM DB2
- Коннектор Oracle
- Коннектор PostgreSQL
- Коннектор SharePoint
- Коннектор OData 1C
- Коннектор TCP
- Коннектор Siemens Team Center
- Коннектор SAP и другие.
Все коннекторы имеют возможности параметрической настройки подключения к системе-источнику и взаимодействию с ней.
Список доступных коннекторов постоянно расширяется, полный перечень необходимо уточнять в компании DATAREON .
В составе DATAREON ESB присутствует механизм, позволяющий самостоятельно разрабатывать различные коннекторы на языке Java или языках платформы.Net. Таким образом может быть реализован любой пользовательский сценарий подключения к системам-источникам.
В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали - теперь это улица Марии Ульяновой, а дом 25 по этой улице - хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…
Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.
Как это было раньше? Один банк отправлял другому электронное сообщение (Уж извините, я тогда в Инкомбанке работал, потому про банки буду рассказывать). Второй банк сообщение получал и отправлял на него квитанцию. Все это десять раз шифровалось, заверялось цифровой подписью, в квитанцию включалась хеш-функция исходного сообщения … номера входящих и исходящих, отметки времени (тоже, кстати, криптографические) и т.д. и т.п. Наиболее обсуждаемый вопрос тех лет, а нужно ли на квитанцию формировать квитанцию о получении квитанции и что делать, когда квитанция не доставлена. В общем, страшно вспомнить до какого уровня сложности можно довести процесс синхронизации состояний множественных виртуальных образов одного реального документа. С бумагой было проще. По крайней мере, до изобретения ксерокса.
Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли
Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример — моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе — MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр. Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)
Интеграция приложений - вопрос, который рано или поздно встает перед ИТ-подразделением любой организации, в которой этих приложений больше одного. Вот далеко не полный перечень задач, укладывающихся в понятие «интеграция»:
- необходимость ведения общих справочников (например, справочников клиентов или сотрудников);
- запуск активностей в одной информационной системе при наступлении событий в другой;
- бизнес-процесс (организованная последовательность действий, выполняемых как людьми, так и информационными системами), протекающий в нескольких приложениях;
- информационное взаимодействие с бизнес-партнерами (например, автоматический запрос цен на комплектующие у поставщика);
- унификация информационных обменов и бизнес-процессов в филиалах компании.
Если выполнение подобного рода действий происходит на предприятии редко (например, раз в день), то организовать эти действия можно кустарным путем - например с помощью ручной выгрузки данных из одного приложения в формате Excel и загрузки их в другое приложение или вообще с помощью дублированного ввода информации сразу в две системы. Однако если потребность в информационном взаимодействии приложений возникает много раз в день, то встает вопрос о неэффективном использовании человеческих ресурсов и, как следствие, возникает необходимость автоматизации этой процедуры.
Интеграция по типу «точкаточка»
Задача интеграции «точкаточка» относительно проста. Нужно понять, каким образом каждая из двух взаимодействующих систем готова передавать и получать данные, создать соответствующие технические решения для обращения к этим интерфейсам, а также реализовать механизм преобразования данных из формата системыисточника в формат системыприемника. В лучшем случае информационные системы предоставляют для интеграции специальный программный интерфейс (API), а в худшем - чтение и запись информации приходится производить непосредственно в базу данных приложения. В результате возникает локальное интеграционное решение - некий обособленный программный модуль собственной разработки со всеми вытекающими требованиями к его обслуживанию и поддержанию актуальности.
Интеграция «точка-точка»
Это не составляет большую проблему до тех пор, пока интеграций «точкаточка» мало - одна-две. Однако практика показывает, что количество интеграций «точкаточка» имеет склонность возрастать, а качество управления этими интеграциями - наоборот, стремительно падать. Причин тому много: возрастает число модулей интеграции, из организации уходят разработчики, делавшие тот или иной модуль, изменяются форматы данных в интегрируемых системах и т.д. Печальным итогом эволюционного развития интеграций «точкаточка» является сложнейший «фарш» интеграционных взаимодействий между приложениями предприятия, отношение к которому сотрудников ИТ-подразделения проще всего выразить в нескольких словах: «Пока работает - лучше не трогать». Однако такая ситуация не устраивает ни само ИТ-подразделение, ни бизнес-заказчиков.
Интеграционный «фарш»
Единая сервисная шина
Пережив несколько поколений различных подходов к интеграции приложений, мировая индустрия программного обеспечения пришла к концепции единой сервисной шины предприятия (Enterprise Service Bus, ESB). С точки зрения архитектуры, ESB - это программное решение, обеспечивающее взаимодействие всех интегрируемых приложений через единую точку, единообразно, предоставляя разработчикам и администраторам унифицированные и централизованные средства разработки, тестирования и контроля протекания всех интеграционных сценариев.
Основными компонентами, составляющими современную сервисную шину, являются:
- брокер сообщений - это высокопроизводительная магистраль для обмена сообщениями в унифицированном формате между приложениями в режиме реального времени;
- адаптеры - технологические адаптеры и адаптеры к бизнес-системам обеспечивают взаимодействие с приложениями в том формате, который для них приемлем, представляя информацию из этих сообщений в унифицированном формате, воспринимаемом брокером - чем больше различных адаптеров предоставляет та или иная интеграционная платформа, тем больше шансов, что для ее внедрения в вашей организации не потребуется дополнительных работ по созданию адаптеров, специфичных для ваших систем;
- среда разработки интеграционных сценариев - чем проще и быстрее происходит разработка сценариев интеграции, тем меньше вложения средств в эту разработку, а следовательно, быстрее возврат от вложенных средств. Современная интеграционная шина предоставляет в распоряжение разработчика визуальные средства конструирования интеграционных сценариев, позволяющих в большинстве случаев обходиться без низкоуровневого кодирования;
- SOA-средства - следование принципам сервис-ориентированной архитектуры является безусловным стандартом для всех интеграционных решений типа «единая сервисная шина» (что понятно по его названию). Информационные системы рассматриваются здесь как поставщики и потребители сервисов, все опубликованные в шине сервисы помещаются в единый реестр с возможностью повторного использования и управления политиками, связанными с сервисами;
- различные инструменты контроля и управления (аудиты, протоколирование, централизованный мониторинг, контроль соблюдения соглашения об уровне услуг и т.д.).
Преимуществами использования единой сервисной шины можно назвать:
- масштабирование - возможность строить решения любого размера и нагруженности;
- гибкость - возможность реализовывать и изменять интеграционные сценарии без существенного вовлечения разработчиков;
- безопасность - встроенные средства аутентификации и авторизации обеспечивают контроль доступа к сервисам на уровне самой шины, избавляя разработчиков интеграционных сценариев от задач по реализации этих механизмов;
- использование открытых стандартов - позволяет уменьшить вовлеченность дорогостоящих специалистов по проприетарным технологиям;
- централизация средств контроля и администрирования - позволяет избежать «размытия» точки ответственности за интеграционные сценарии, обеспечить оперативное наблюдение и раннее оповещение в случае сбоев.
Еще одним важным требованием к функционалу ESB-среды является возможность реализации интеграции с внешними организациями - бизнес-партнерами, поставщиками, корпоративными клиентами, удаленными филиалами. Особенностями такой интеграции является непредсказуемое качество каналов, отсутствие гарантий доставки информации и слабая готовность к интеграции как таковой - как правило, организация-партнер предоставляет очень ограниченный спектр форматов обмена данными. На этот случай в составе интеграционной шины должно присутствовать средство построения B2B-взаимодействия, позволяющее осуществлять информационный обмен по открытым, в том числе отраслевым, стандартам, обеспечивать гарантированную доставку, обладать средствами настройки информационного обмена в разрезе конкретного бизнес-партнера и, конечно же, работать в полном соответствии с принципами самой интеграционной платформы, изолируя разработчика интеграционных сценариев от технических деталей взаимодействия с партнером.
Enterprise Service Bus
Управление бизнес-процессами
Существенная доля интеграционных сценариев подразумевает, что в информационный обмен вовлекаются не только приложения, выступающие в роли источников или приемников информации, но и люди - сотрудники организации, выполняющие различные задания или принимающие решения. В этом случае мы можем говорить о выходе за рамки «чистой» интеграции и появлении в фокусе нашего внимания новой сущности - бизнес-процессов, а в требованиях к интеграционной платформе - новой функциональности по управлению бизнес-процессами (Business Process Management, BPM). При наличии BPM-требований интеграционная платформа должна предоставить в распоряжение разработчика:
- средство визуального проектирования бизнес-процессов - оптимально, чтобы этими средствами могли воспользоваться люди, далекие от ИТ, - например бизнес-аналитики или методологи. Кроме того, чрезвычайно полезным является возможность переноса моделей бизнес-процессов из специализированных средств моделирования в среду разработки. Это же средство должно давать возможность проектировать формы заданий для участников процессов, причем максимально ограждая разработчиков от программирования;
- среду исполнения бизнес-процессов - специальный движок, обеспечивающий обработку бизнес-правил, передачу заданий между пользователями и информационными системами в соответствии с разработанными моделями бизнес-процессов, а также обработку исключительных ситуаций (например, превышения исполнителем времени, отведенного для выполнения задания);
- портал участников бизнес-процессов - специализированный портал, позволяющий пользователям запускать процессы, участвовать в них, контролировать ход запущенных процессов и осуществлять административные воздействия в соответствии с установленными для них правами;
- средства мониторинга и контроллинга. Возможность оперативного и ретроспективного анализа протекания бизнес-процессов - важная часть любой платформы BPM.
На данный момент многие производители ПО склонны объединять BPM-среду и интеграционную шину в единую платформу промежуточного ПО, убирая существовавшее несколько лет строгое разделение между BPM-системами и средствами для интеграции приложений. Такой подход очень прогрессивен. Некоторые вендоры идут еще дальше и присоединяют к платформе профессиональные средства для моделирования бизнес-процессов. Пионером в этом является компания Software AG, предлагающая решение, объединяющее в себе известное средство моделирования ARIS Platform и интеграционную/BPM среду webMethods.
Комплексное использование интеграционной платформы
Предложения на рынке
На текущий момент можно выделить три группы предложений ПО для построения ESB. Эти группы разнятся как по цене, так и по предлагаемой функциональности.
Первая группа - предложения от фирм, чьи продукты лидируют в исследованиях аналитических агентств по всем обозначенным в статье категориям (ESB, SOA Governance, BPM, B2B). В эту группу входят:
- IBM с линейкой продуктов WebSphere;
- Software AG c интеграционной платформой webMethods;
- Oracle с целой серией предложений;
- Tibco с линейкой Business Integration.
В принципе, тем, кто не любит компромиссы, можно выбирать любого из этих производителей - все перечисленные компании предлагают полноценные линейки продуктов (правда, в случае с Oracle не всегда понятно, о каком именно продукте идет речь, поскольку после покупки ряда компаний Oracle предлагает сразу несколько продуктов, не всегда в достаточной степени интегрированных между собой). Немного особняком стоит Tibco, так как размер этой компании гораздо меньше размера остальных участников данной четверки, что может вызвать некоторые сомнения в ее стабильности. Software AG - пока не очень известный на российском рынке производитель, но у платформы webMethods, которая является сегодня ключевым предложением этой компании, большой потенциал. IBM и ее продукты знают и используют уже очень многие предприятия, но у некоторых из них возникают претензии по стоимости самого внедрения и обслуживания системы.
Вторая группа предложений - это компании, сконцентрированные в основном на «чистом» ESB-функционале и достигшие здесь успеха. В эту группу попадают: Sun (Glassfish), Progress (Sonic) и Fujitsu.
Предложения от этих компаний хороши, если вы не собираетесь расширять сферу применения своей платформы в сторону BPM и/или B2B. В противном случае вы рискуете оказаться наедине с недостаточно проработанной функциональностью и существенно увеличить свои расходы на ее доработку до соответствия своим потребностям.
Третья группа наиболее многочисленна и включает все предложения, не вошедшие в предыдущие две группы. Перечисление всех предложений на тему ESB в данной статье бессмысленно, вы можете получить такой список в любом поисковике. Если ваш бюджет на интеграцию ограничен, а сами вы склонны к экспериментам - вы вполне можете попытать счастья с любым из них. Однако риски, касающиеся как недостаточно проработанной функциональности, так и возможных проблем с надежностью, технической поддержки и перспектив развития продуктов, вы принимаете на себя.
Заключение
В заключение хотелось бы дать читателям несколько простых советов по выбору интеграционной шины:
- задумывайтесь о построении интеграционного решения, не дожидаясь, когда проблемы взаимодействия приложений прижмут вас к стенке. Чем больше завал, тем сложнее его разгребать;
- тщательно подойдите к выбору платформы. Ищите вендора, который удовлетворяет вас по всем позициям, благо сейчас есть из чего выбрать. Вас должны интересовать и технологические параметры платформы, и методологические аспекты внедрения;
- думайте о перспективе. Функциональные требования, которые осознаются вами сейчас, могут существенно измениться через год, и если платформа не будет их удовлетворять, то вам придется «переезжать» на другую. А один переезд, как известно, равен двум пожарам.
Интеграция приложений - вопрос, который рано или поздно встает перед ИТ-подразделением любой организации, в которой этих приложений больше одного. Вот далеко не полный перечень задач, укладывающихся в понятие «интеграция»:
- необходимость ведения общих справочников (например, справочников клиентов или сотрудников);
- запуск активностей в одной информационной системе при наступлении событий в другой;
- бизнес-процесс (организованная последовательность действий, выполняемых как людьми, так и информационными системами), протекающий в нескольких приложениях;
- информационное взаимодействие с бизнес-партнерами (например, автоматический запрос цен на комплектующие у поставщика);
- унификация информационных обменов и бизнес-процессов в филиалах компании.
Если выполнение подобного рода действий происходит на предприятии редко (например, раз в день), то организовать эти действия можно кустарным путем - например с помощью ручной выгрузки данных из одного приложения в формате Excel и загрузки их в другое приложение или вообще с помощью дублированного ввода информации сразу в две системы. Однако если потребность в информационном взаимодействии приложений возникает много раз в день, то встает вопрос о неэффективном использовании человеческих ресурсов и, как следствие, возникает необходимость автоматизации этой процедуры.
Интеграция по типу «точкаточка»
Задача интеграции «точкаточка» относительно проста. Нужно понять, каким образом каждая из двух взаимодействующих систем готова передавать и получать данные, создать соответствующие технические решения для обращения к этим интерфейсам, а также реализовать механизм преобразования данных из формата системыисточника в формат системыприемника. В лучшем случае информационные системы предоставляют для интеграции специальный программный интерфейс (API), а в худшем - чтение и запись информации приходится производить непосредственно в базу данных приложения. В результате возникает локальное интеграционное решение - некий обособленный программный модуль собственной разработки со всеми вытекающими требованиями к его обслуживанию и поддержанию актуальности.
Интеграция «точка-точка»
Это не составляет большую проблему до тех пор, пока интеграций «точкаточка» мало - одна-две. Однако практика показывает, что количество интеграций «точкаточка» имеет склонность возрастать, а качество управления этими интеграциями - наоборот, стремительно падать. Причин тому много: возрастает число модулей интеграции, из организации уходят разработчики, делавшие тот или иной модуль, изменяются форматы данных в интегрируемых системах и т.д. Печальным итогом эволюционного развития интеграций «точкаточка» является сложнейший «фарш» интеграционных взаимодействий между приложениями предприятия, отношение к которому сотрудников ИТ-подразделения проще всего выразить в нескольких словах: «Пока работает - лучше не трогать». Однако такая ситуация не устраивает ни само ИТ-подразделение, ни бизнес-заказчиков.
Интеграционный «фарш»
Единая сервисная шина
Пережив несколько поколений различных подходов к интеграции приложений, мировая индустрия программного обеспечения пришла к концепции единой сервисной шины предприятия (Enterprise Service Bus, ESB). С точки зрения архитектуры, ESB - это программное решение, обеспечивающее взаимодействие всех интегрируемых приложений через единую точку, единообразно, предоставляя разработчикам и администраторам унифицированные и централизованные средства разработки, тестирования и контроля протекания всех интеграционных сценариев.
Основными компонентами, составляющими современную сервисную шину, являются:
- брокер сообщений - это высокопроизводительная магистраль для обмена сообщениями в унифицированном формате между приложениями в режиме реального времени;
- адаптеры - технологические адаптеры и адаптеры к бизнес-системам обеспечивают взаимодействие с приложениями в том формате, который для них приемлем, представляя информацию из этих сообщений в унифицированном формате, воспринимаемом брокером - чем больше различных адаптеров предоставляет та или иная интеграционная платформа, тем больше шансов, что для ее внедрения в вашей организации не потребуется дополнительных работ по созданию адаптеров, специфичных для ваших систем;
- среда разработки интеграционных сценариев - чем проще и быстрее происходит разработка сценариев интеграции, тем меньше вложения средств в эту разработку, а следовательно, быстрее возврат от вложенных средств. Современная интеграционная шина предоставляет в распоряжение разработчика визуальные средства конструирования интеграционных сценариев, позволяющих в большинстве случаев обходиться без низкоуровневого кодирования;
- SOA-средства - следование принципам сервис-ориентированной архитектуры является безусловным стандартом для всех интеграционных решений типа «единая сервисная шина» (что понятно по его названию). Информационные системы рассматриваются здесь как поставщики и потребители сервисов, все опубликованные в шине сервисы помещаются в единый реестр с возможностью повторного использования и управления политиками, связанными с сервисами;
- различные инструменты контроля и управления (аудиты, протоколирование, централизованный мониторинг, контроль соблюдения соглашения об уровне услуг и т.д.).
Преимуществами использования единой сервисной шины можно назвать:
- масштабирование - возможность строить решения любого размера и нагруженности;
- гибкость - возможность реализовывать и изменять интеграционные сценарии без существенного вовлечения разработчиков;
- безопасность - встроенные средства аутентификации и авторизации обеспечивают контроль доступа к сервисам на уровне самой шины, избавляя разработчиков интеграционных сценариев от задач по реализации этих механизмов;
- использование открытых стандартов - позволяет уменьшить вовлеченность дорогостоящих специалистов по проприетарным технологиям;
- централизация средств контроля и администрирования - позволяет избежать «размытия» точки ответственности за интеграционные сценарии, обеспечить оперативное наблюдение и раннее оповещение в случае сбоев.
Еще одним важным требованием к функционалу ESB-среды является возможность реализации интеграции с внешними организациями - бизнес-партнерами, поставщиками, корпоративными клиентами, удаленными филиалами. Особенностями такой интеграции является непредсказуемое качество каналов, отсутствие гарантий доставки информации и слабая готовность к интеграции как таковой - как правило, организация-партнер предоставляет очень ограниченный спектр форматов обмена данными. На этот случай в составе интеграционной шины должно присутствовать средство построения B2B-взаимодействия, позволяющее осуществлять информационный обмен по открытым, в том числе отраслевым, стандартам, обеспечивать гарантированную доставку, обладать средствами настройки информационного обмена в разрезе конкретного бизнес-партнера и, конечно же, работать в полном соответствии с принципами самой интеграционной платформы, изолируя разработчика интеграционных сценариев от технических деталей взаимодействия с партнером.
Enterprise Service Bus
Управление бизнес-процессами
Существенная доля интеграционных сценариев подразумевает, что в информационный обмен вовлекаются не только приложения, выступающие в роли источников или приемников информации, но и люди - сотрудники организации, выполняющие различные задания или принимающие решения. В этом случае мы можем говорить о выходе за рамки «чистой» интеграции и появлении в фокусе нашего внимания новой сущности - бизнес-процессов, а в требованиях к интеграционной платформе - новой функциональности по управлению бизнес-процессами (Business Process Management, BPM). При наличии BPM-требований интеграционная платформа должна предоставить в распоряжение разработчика:
- средство визуального проектирования бизнес-процессов - оптимально, чтобы этими средствами могли воспользоваться люди, далекие от ИТ, - например бизнес-аналитики или методологи. Кроме того, чрезвычайно полезным является возможность переноса моделей бизнес-процессов из специализированных средств моделирования в среду разработки. Это же средство должно давать возможность проектировать формы заданий для участников процессов, причем максимально ограждая разработчиков от программирования;
- среду исполнения бизнес-процессов - специальный движок, обеспечивающий обработку бизнес-правил, передачу заданий между пользователями и информационными системами в соответствии с разработанными моделями бизнес-процессов, а также обработку исключительных ситуаций (например, превышения исполнителем времени, отведенного для выполнения задания);
- портал участников бизнес-процессов - специализированный портал, позволяющий пользователям запускать процессы, участвовать в них, контролировать ход запущенных процессов и осуществлять административные воздействия в соответствии с установленными для них правами;
- средства мониторинга и контроллинга. Возможность оперативного и ретроспективного анализа протекания бизнес-процессов - важная часть любой платформы BPM.
На данный момент многие производители ПО склонны объединять BPM-среду и интеграционную шину в единую платформу промежуточного ПО, убирая существовавшее несколько лет строгое разделение между BPM-системами и средствами для интеграции приложений. Такой подход очень прогрессивен. Некоторые вендоры идут еще дальше и присоединяют к платформе профессиональные средства для моделирования бизнес-процессов. Пионером в этом является компания Software AG, предлагающая решение, объединяющее в себе известное средство моделирования ARIS Platform и интеграционную/BPM среду webMethods.
Комплексное использование интеграционной платформы
Предложения на рынке
На текущий момент можно выделить три группы предложений ПО для построения ESB. Эти группы разнятся как по цене, так и по предлагаемой функциональности.
Первая группа - предложения от фирм, чьи продукты лидируют в исследованиях аналитических агентств по всем обозначенным в статье категориям (ESB, SOA Governance, BPM, B2B). В эту группу входят:
- IBM с линейкой продуктов WebSphere;
- Software AG c интеграционной платформой webMethods;
- Oracle с целой серией предложений;
- Tibco с линейкой Business Integration.
В принципе, тем, кто не любит компромиссы, можно выбирать любого из этих производителей - все перечисленные компании предлагают полноценные линейки продуктов (правда, в случае с Oracle не всегда понятно, о каком именно продукте идет речь, поскольку после покупки ряда компаний Oracle предлагает сразу несколько продуктов, не всегда в достаточной степени интегрированных между собой). Немного особняком стоит Tibco, так как размер этой компании гораздо меньше размера остальных участников данной четверки, что может вызвать некоторые сомнения в ее стабильности. Software AG - пока не очень известный на российском рынке производитель, но у платформы webMethods, которая является сегодня ключевым предложением этой компании, большой потенциал. IBM и ее продукты знают и используют уже очень многие предприятия, но у некоторых из них возникают претензии по стоимости самого внедрения и обслуживания системы.
Вторая группа предложений - это компании, сконцентрированные в основном на «чистом» ESB-функционале и достигшие здесь успеха. В эту группу попадают: Sun (Glassfish), Progress (Sonic) и Fujitsu.
Предложения от этих компаний хороши, если вы не собираетесь расширять сферу применения своей платформы в сторону BPM и/или B2B. В противном случае вы рискуете оказаться наедине с недостаточно проработанной функциональностью и существенно увеличить свои расходы на ее доработку до соответствия своим потребностям.
Третья группа наиболее многочисленна и включает все предложения, не вошедшие в предыдущие две группы. Перечисление всех предложений на тему ESB в данной статье бессмысленно, вы можете получить такой список в любом поисковике. Если ваш бюджет на интеграцию ограничен, а сами вы склонны к экспериментам - вы вполне можете попытать счастья с любым из них. Однако риски, касающиеся как недостаточно проработанной функциональности, так и возможных проблем с надежностью, технической поддержки и перспектив развития продуктов, вы принимаете на себя.
Заключение
В заключение хотелось бы дать читателям несколько простых советов по выбору интеграционной шины:
- задумывайтесь о построении интеграционного решения, не дожидаясь, когда проблемы взаимодействия приложений прижмут вас к стенке. Чем больше завал, тем сложнее его разгребать;
- тщательно подойдите к выбору платформы. Ищите вендора, который удовлетворяет вас по всем позициям, благо сейчас есть из чего выбрать. Вас должны интересовать и технологические параметры платформы, и методологические аспекты внедрения;
- думайте о перспективе. Функциональные требования, которые осознаются вами сейчас, могут существенно измениться через год, и если платформа не будет их удовлетворять, то вам придется «переезжать» на другую. А один переезд, как известно, равен двум пожарам.