И снова про 1С

Последнее время на Хабре стали все чаще появляться статьи, посвященные 1С как среде разработки приложений. Статьи по смыслу более концептуальные, чем прикладные; авторы делают обзор платформы «1C:Предприятие 8» в целом, пытаются понять, хороша или плоха технология создания бизнес-приложений, предлагаемая 1С.

Не буду обсуждать, прав ли каждый из авторов или нет; у платформы 1С, как у любой технологии, есть свои преимущества и недостатки. А есть и свои интересные особенности, свои наработки и механизмы. Вот о них и хочется поговорить. А еще — хочется написать статью про 1С для людей, с 1С незнакомых, статью, которая показывает, какое место 1С занимает в ряду аналогичных программных продуктов. Мне лично такой ознакомительной обзорной статьи очень не хватало, когда я еще не был знаком с 1С, но был знаком с рядом других ERP продуктов.

Итак, начнем!

Что производит фирма 1С?

Думаю, широкая публика на этот вопрос ответит: «1С:Бухгалтерию». Кто-то вспомнит обучающие программы или знаменитую серию игр «ИЛ-2 Штурмовик».

Участники Хабра, конечно, в курсе, что 1С – это не только «1С:Бухгалтерия», что есть целая система программ «1С:Предприятие», включающая средства разработки бизнес-приложений и бизнес-приложения, созданные с помощью этих средств. А уж с помощью средств разработки 1С написаны и бухгалтерия, и CRM, и ERP (с внедрениями на тысячи и десятки тысяч пользователей), и многое другое.

ERP-системы — наиболее интересные и насыщенные по функционалу бизнес-приложения; посмотрим на их примере, какое место технологии «1С:Предприятия» занимают в ряду аналогов.

Какие бывают ERP

Какое самое ценное свойство ERP систем (да и любых бизнес-приложений)? На мой взгляд – это гибкость, возможность приспосабливаться к бизнес-процессам конечного пользователя как можно меньшей ценой.

Понятно, что, программируя ERP систему, все варианты бизнес-процессов предусмотреть невозможно. На помощь приходит параметризация; вводя в систему параметры, которые может изменить в настройках системы пользователь (консультант, администратор), мы повышаем гибкость системы сравнительно небольшой ценой. Первые ERP системы были parameter-driven, т.е. настраиваемые с помощью параметров.

Не все бизнес-кейсы можно предусмотреть и в параметризуемых системах. Когда одной настройкой параметров не обойтись – надо менять исходный код. Тут перед производителем ERP встает вопрос – менять код самому под нужды потребителей и выпускать обновления или поставлять систему в исходных кодах, чтобы пользователи могли сами переписать систему под свои нужды (что, кстати, не освобождает производителя от выпуска обновлений — система должна развиваться, поддерживать новый функционал, чтобы быть конкурентоспособной).

Отдельный вопрос – выбор языка программирования для написания ERP системы. Бо́льшая часть ERP системы – это бизнес-логика, для которой обычные языки программирования типа С++ не всегда подходят наилучшим образом. В идеале бизнес-логику хорошо бы программировать на высокоуровневом языке, способном обеспечить бизнес-программисту максимальный комфорт при написании бизнес-логики, абстрагировать его от низкоуровневых деталей (особенностей работы с базами данных, подсистемой файлового ввода-вывода и печати, оконной подсистемой пользовательского интерфейса и т.п.). Конечно, в этом случае надо еще создать и компилятор/интерпретатор для этого языка и среду разработки.

Имеем матрицу возможных сочетаний:

• открытый или закрытый код приложения (тут я имею в виду не open source в обычном его понимании, а возможность поставки исходного кода приложения, в том числе и за отдельную плату).
• язык программирования бизнес логики – «обычный» (С/Java/Perl/…) или специально разработанный, проприетарный.

Бизнес-приложения, созданные с помощью технологий «1C: Предприятия» — это системы с открытым прикладным исходным кодом, написанным на проприетарном языке, у которого нет короткого названия; официально его называют «Встроенный язык программирования 1С: Предприятие», неофициально и коротко – «язык 1С».

Большинство лидеров современного ERP рынка – это системы с открытым кодом. Возможность изменять исходный код «на местах» дает огромную гибкость и конкурентное преимущество. Продукты с закрытым кодом вынуждены использовать другие приемы; самый распространенный ход – аналог CallBacks, возможность повесить кастомный код на предопределенные события, как визуальные (открытие-закрытие формы, выбор из списка значений, …), так и бизнес-событие (обработка заказа, ввод счета на продажу, …). В некоторых системах есть возможность написать свои обработчики на C# (или других распространенных языках), в других для этого есть Visual Basic for Applications, лицензированный у Microsoft и т.п.

Как устроены ERP

ERP системы с открытым кодом приложения состоят из собственно исходного кода, реализующего бизнес-логику, и среды исполнения этого бизнес-кода (т.н. платформы).

Платформа, как правило, написана на низкоуровневом языке (C, C++), часто исходные коды платформы закрыты для конечных пользователей. Задача платформы – позволить программисту абстрагироваться от низкоуровневых деталей (особенности ОС и СУБД и т.п.) и сосредоточиться на написании собственно бизнес-логики. К платформе также часто относят средства разработки бизнес-приложений и средства администрирования системы (и я согласен с этим подходом). Не обходятся, кстати, без платформы и системы, где бизнес-логика написана на «обычных» языках программирования. Интерпретировать код приложения там не надо, но потребность в платформенном функционале остается (например, «обертках» вокруг БД или унифицированном доступе к списку пользователей и их прав).

Платформу как среду исполнения бизнес-приложений можно охарактеризовать как виртуальную машину. Как правило, платформа должна эмулировать для ERP три основные вещи:

• Среда исполнения бизнес-логики.
• База данных.
• Графическая подсистема для отображения клиентского приложения. Клиентское приложение может быть графическим, отрисованным штатными средствами ОС (в том числе и мобильной ОС), а может быть веб-приложением. В случае веб-приложения платформа или реализует свой веб-сервер, или обеспечивает поддержку стандартных веб-серверов (IIS, Apache и т.д.)

В принципе, модифицируя платформу, можно заставить ERP, написанную на проприетарном языке, запускаться под любой ОС и хранить данные практически в любой СУБД. Обычно производители ERP ограничиваются одной-двумя ОС и одной-двумя СУБД. Поддержка дополнительных ОС и СУБД – это увеличение затрат на разработку и тестирование; нередко производители ERP в новых версиях продуктов объявляют о прекращении поддержки какой-либо СУБД.

Платформа 1С в плане поддержки ОС и СУБД предлагает следующее:

• Среда исполнения бизнес-логики: отказоустойчивый кластер серверов приложений с балансировкой нагрузки; ОС — Windows или Linux
• База данных: собственная файловая СУБД (рекомендуемая для разработки и небольших инсталляций), MS SQL, Oracle, IBM DB2, PostgreSQL
• Клиент:
  
  • тонкий клиент (только отображение и ввод информации на клиенте) – Windows и Linux. Может работать с сервером приложений через локальную сеть или через веб-сервисы (в этом случае на серверной стороне должен быть развернут Microsoft IIS или Apache)
  • Веб-клиент – на серверной стороне Microsoft IIS или Apache, на клиентской – любой из четырех браузеров — Internet Explorer, Chrome, Firefox, Safari
  • толстый клиент (с возможностью исполнять на клиенте часть бизнес-логики) – Windows и Linux. Обладает рядом ограничений (например, может работать только в пределах одной локальной сети с сервером приложений). Считается устаревшим, далее его развивать фирма «1С» не планирует.
  • Мобильный офлайн-клиент (с возможностью периодической синхронизации) – iOS и Android.

Если мы используем при написании программы 1С технологию управляемого приложения (доступна с 2008 года) – то из одного прикладного кода мы получаем и тонкого клиента для Windows/Linux, и веб-клиента.

Язык приложений ERP

Отдельная тема – язык, на котором пишется бизнес-логика. Для эффективной работы бизнес-программиста этот язык должен быть как можно ближе к предметной области бизнеса (в идеале – DSL, Domain Specific Language) и подальше от технических деталей ОС и СУБД.

Возьмем типичную для бизнеса задачу: нам надо добавить в системе возможность введения и обработки нового типа документов (например, наряд-заказа). В системе, написанной на «обычном» языке программирования, для этого требуется:

1. Создать таблицы в БД, где будет храниться информация о документе.
2. Написать класс (или классы), реализующие бизнес-логику работы с документом. Помимо бизнес-логики классы должны также реализовывать взаимодействие с БД — чтение и запись данных документа.
3. Создать пользовательский интерфейс для редактирования нового типа документа. Часто нужно бывает еще создать форму, отображающую список документов с возможностью поиска по разным полям и т.п.

Если мы работаем на C# в Visual Studio – все шаги можно сделать внутри одной среды разработки (включая дизайн БД).
В ряде ERP систем, использующих проприетарные языки, также надо пройти все три описанных выше шага, как правило, внутри одной среды разработки.

Эти 3 шага обеспечат необходимый минимум; а ведь еще надо создать пользовательский интерфейс для работы с документом, сделать его доступным в отчетах, уметь регистрировать изменения, сделанные пользователями в документах нового типа, в журнале (логе) системы и т.п.

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

• Создаст структуры в СУБД для хранения данных.
• Создаст формы для редактирования документа, показа списка документов этого типа и т.д. Если автоматически созданные формы нас чем-то не устроят – можно сделать свои, расширив и/или изменив стандартные.
• Документ станет доступен в отчетах.
• Документ и его поля станут доступны для раздачи прав на чтение/запись в системе безопасности приложения.
• Поля документа станут доступны для полнотекстового поиска по всей системе (с учетом синонимов, поддержкой транслитерации, нечеткого поиска и т.д.).
• Все изменения в документах нового типа будут регистрироваться в журнале регистрации приложения.
• Будут автоматически созданы методы для сохранения и чтения документа в/из XML и JSON.
• Документ станет доступен по интерфейсу REST (через протокол OData).
• И многое другое

Особенностью разработки в 1С является то, что в системе существуют порядка 20 встроенных типов объектов, и все новые объекты, которые разработчик создает, должны принадлежать к одному из этих типов. Большая часть этих типов описывают объекты из сферы учетной деятельности предприятия – справочники, документы, планы счетов и т.д. Другая часть типов объектов – технологические, например, Web- и HTTP-сервисы; они позволяют программам 1С общаться с внешним миром.


Конфигуратор 1С – в нем создаются прикладные решения. Слева — дерево встроенных типов 1С; под каждой веткой — прикладные объекты данного типа.

Разработка прикладных решений делается в Конфигураторе (Designer в англоязычной версии). Недавно была выпущена ознакомительная версия инструмента «1C:Enterprise Development Tools», позволяющая вести разработку решений 1С в популярной среде Eclipse. Промышленную разработку в «1C:Enterprise Development Tools» вести пока нельзя, но понять, куда в технологическом плане движется компания, по этой версии вполне можно. В частности, поддерживается коллективная разработка с использованием популярных систем управления версиями (Git, SVN и любых других, для которых есть плагины к Eclipse); есть также возможность написать к IDE Eclipse собственные плагины, расширяющие возможности среды разработки по работе с 1С.


Enterprise Development Tools — разработка приложения 1С в IDE Eclipse

Собственно язык программирования 1С по синтаксису напоминает больше всего JavaScript. Язык, строго говоря, не является объектно-ориентированным. В нем нет наследования; но, поскольку все объекты программ 1С принадлежат к одному из встроенных типов объектов – это можно назвать упрощенным наследованием: встроенные типы объектов реализуют предопределенный функционал, который прикладной программист может в своих объектах-наследниках переопределить. Такое наследование – одноуровневое, наследовать от прикладных объектов уже нельзя; похожий подход к наследованию принят в концепции прототипного программирования (prototype-based programming); одним из популярных представителей этой концепции как раз является JavaScript.

Такой подход осознанно ограничивает свободу разработчика прикладных решений, заставляя его для реализации своих задач выбирать нужный тип объекта из разумно ограниченной палитры встроенных типов. Взамен разработчик получает богатый функционал, реализованный платформой, и действительно быструю разработку. Плюсы такого подхода очевидны – учетные системы на 1С создавать легко и быстро. Есть и минусы – если нужно реализовать что-то, для чего в платформе нет встроенных типов (например, работу с SFTP), то нужно либо ждать новой версии платформы, в которой будет реализован этот функционал, либо писать свою реализацию на «обычном» языке и вызывать её из 1С через технологию внешних компонент.

Несколько фактов о встроенном языке программирования 1С:

• Поддерживается английский (if… then) и русский (если… тогда) синтаксис.
• Язык обладает полнотой по Тьюрингу.
• Это язык с динамической типизацией. Переменная связывается с типом в момент присваивания значения, а не в момент объявления переменной. Объявляя переменную, нельзя указать ее тип.
  Можно так:

  var а; а = 1;
  

  
  Нельзя так:

  var a as Int; a = 1;
  

• Для чтения данных из СУБД у 1С есть свой язык запросов, похожий на SQL. Собственно, в SQL он и транслируется при выполнении программ 1С.

Как все это работает

Как решения 1С поставляются конечным пользователям? И как они работают у этих самых конечных пользователей?

Чтобы полнее ответить на этот вопрос, надо вспомнить об одной характерной особенности 1С.
Проект в 1С называется конфигурацией. Конфигурация – это законченная самодостаточная программа, например, бухгалтерия или ERP; она включает в себя все объекты и код, нужные для полноценного функционирования бизнес-приложения. Особенность 1С в том, что конфигурация хранится в базе данных, в той же самой, в которой лежат данные самого приложения (проводки, данные справочников и документов и т.п.), т.е. программа хранится вместе с данными. База данных с конфигурацией (и данными приложения) в терминологии 1С называется информационной базой (сокращенно – инфобазой).

Конфигурация может выгружаться в файл; в виде файла она обычно от разработчика поступает конечным пользователям, на клиентской системе этот файл импортируется в инфобазу. После этого решение готово к работе.


Архитектура решений 1С

Где какой софт установлен:

• Сервер СУБД – одна или несколько СУБД, поддерживаемых 1С (MS SQL, Oracle, IBM DB2, PostgreSQL). Если на сервере 1С установлено несколько приложений 1С — приложения могут использовать разные СУБД; например, бухгалтерия – MS SQL, а ERP – Oracle.
• Сервер – один или несколько серверов отказоустойчивого масштабируемого кластера. Тут должен быть установлен программный продукт «Сервер 1С» (набор библиотек и исполняемых файлов). Отказоустойчивость и масштабируемость кластера, а также балансировка нагрузки между серверами кластера обеспечиваются средствами ПО «1С». В составе одного кластера могут быть сервера под Windows и Linux, в системе может быть предусмотрен резервный кластер.
• Клиент: ОС Windows или Linux, должен быть установлен тонкий клиент (1cv8c.exe/1cv8) или толстый клиент 1С (1Cv8.exe для Windows, 1cv8 – для Linux).
  
  • Тонкий клиент умеет исполнять ограниченный набор функциональности встроенного языка 1С. Оперирует ограниченным набором типов встроенного языка, предназначенным лишь для отображения и изменения данных в памяти. Вся работа с базой данных, объектными данными, исполнение запросов выполняется на стороне сервера. Тонкий клиент только получает готовые данные, подготовленные для отображения.
  • Толстый клиент может исполнять практически всю функциональность, предоставляемую встроенным языком 1C сам, прибегая к помощи сервера только когда надо записать или считать данные из базы. Ограничения: требует значительного количества аппаратных ресурсов и может «общаться» с кластером серверов 1С только по локальной сети. Считается устаревшим, поддерживается для обратной совместимости.
• Веб-сервер – IIS или Apache. От 1С – ставится набор расширений для веб-серверов.
• Веб-клиент – любой из четырех поддерживаемых браузеров: Internet Explorer, Chrome, Firefox, Safari.
• Мобильный клиент: iOS или Android и любое мобильное приложение 1С. Способ общения мобильного приложения 1С с сервером зависит от конкретного приложения; чаще всего используются Web- или HTTP-сервисы.

Между собой компоненты 1С — сервер, тонкий и толстый клиенты и веб-расширения — общаются или по собственному протоколу (реализованному поверх TCP), или по http.

Что особенного в 1С

Что выгодно отличает технологию «1С: Предприятие»? Благодаря инновационному подходу к организации разработки (о нем ниже) в «1С: Предприятии» легко делать две вещи: создавать бизнес-решения с нуля и кастомизировать существующие решения под потребности конечных пользователей.

Разработка

Легко создавать решения с нуля — благодаря встроенным объектам, реализующим базовый функционал учетных систем. Именно продуманная система встроенных объектов (а не язык, который в общем-то обычный скриптовый) делает «1С:Предприятие» мощным инструментом создания бизнес-приложений. Разработчику не нужно писать слой доступа к данным, базовый UI и т.п. – можно сразу сосредоточиться на решении бизнес-задачи. Для решения бизнес-задач также многое уже реализовано во встроенных объектах (читай – базовых библиотеках) – например, поддержка иерархических справочников, учетные машины для реализации бухгалтерского и товарного учета, механизмы для сложных периодических расчетов (например, расчета зарплаты) и многое другое.

«Из коробки» разработчик получает встроенные объекты (справочники, документы, регистры и т.д.), реализованные платформой; это паттерны из мира учетных систем. В прикладном решении (конфигурации) разработчик реализует эти паттерны, наполняя их конкретной бизнес-логикой.

Прикладное решение в «1С:Предприятии» не пишется в прямом смысле на языке программирования. Два краеугольных камня идеологии разработки – разработка от метаданных (Metadata-driven development) и построение приложения на основе модели (Model-driven development).

В основе бизнес-приложения лежат метаданные, представляющие собой декларативное описание самого приложения. Прикладное решение описывается не в терминах реляционных таблиц, классов объектного языка программирования и т.д., как в большинстве систем. Решение в «1С: Предприятии» описывается метаданными в виде совокупности прикладных объектов, выбираемых из определенного набора прототипов-паттернов (справочников, документов, планов счетов, …).

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

Метаданными описываются структуры данных, состав типов, связи между объектами, особенности их поведения и визуального представления, система разграничения прав доступа, пользовательский интерфейс и т. д. В метаданных сосредоточены сведения не только о том, что хранится в базе данных, но и о том, зачем хранится та или иная информация, какова ее роль в системе и как связаны между собой информационные массивы. Использование языка программирования ограничено в основном решением тех задач, которые действительно требуют алгоритмического описания (расчет налогов, проверка корректности введенных данных и т. д.). Коротко сформулировать основной принцип разработки на «1С: Предприятии» можно так: «Давайте программировать только там, где это действительно необходимо, и предоставим платформе выполнять всю рутинную работу».

В «1С: Предприятии» изначально заложена ориентация на построение прикладного решения на основе определенной модели. Под моделью понимается вся идеология построения прикладного решения. Это способы построения структур данных, типы связей между данными, принципы манипулирования ими, формы описания бизнес-логики, способы связи данных с интерфейсными объектами, разделение функциональности по уровням системы и многое другое.

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

Наличие единой модели положительно сказывается на простоте освоения системы. Вся разработка ведется в рамках одной сквозной системы понятий, в едином пространстве типов данных. Описание в метаданных тех или иных объектов (сущностей) сразу определяет и соответствующие типы встроенного языка программирования, и необходимые для их хранения структуры БД. Все последующие манипуляции этими объектами как в памяти, так и в БД выполняются единообразно, не требуя преодоления барьеров между различными нотациями, принятыми при работе с СУБД и универсальными языками программирования.

Готовое приложение (конфигурация), поставляемое в открытых исходных кодах (например, бухгалтерия или ERP), для программиста на стороне клиента – это уже практически DSL (Domain Specific Language, предметно-специфичный язык). Программист может использовать готовые объекты конфигурации (справочник контрагентов, план счетов, расчет зарплаты) для модификации поведения системы под нужды заказчика.

Кастомизация и поддержка

Коротко о бизнес-логике прикладного решения можно сказать следующее: её меняют. Её меняют сотрудники IT-отделов клиента, адаптируя решение под бизнес-процессы предприятия. И её меняет поставщик решения, добавляя новый функционал, поддерживая изменения законодательства и периодически выпуская обновления.

Процедура установки обновления там, где бизнес-логика была изменена «на местах» под нужды клиента, часто бывает нетривиальной операцией, иногда чреватой ошибками. По большому счету, это слияние исходных кодов нового приложения от поставщика с измененным (по сравнению с предыдущей версией от поставщика) приложением клиента. С одной стороны, надо получить новый функционал, пришедший с обновлением; с другой стороны – не потерять свои наработки.

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

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

Описанное выше – одна из самых непростых задач в жизненном цикле практически любой бизнес-системы с открытым кодом приложения. От того, насколько успешно производитель ПО решит эту задачу, во многом зависит успех приложения на рынке. В случае «1С» объединение в ходе обновления двух конфигураций (поставщика и пользователя) – это не просто объединение исходных кодов двух приложений, это прежде всего объединение моделей приложений, которое должно проходить по определенным правилам.

Для решения данной задачи фирма 1С разработала механизм поддержки (входит в состав платформы «1С: Предприятие»), позволяющий поставщику решения определять, какие объекты конфигурации (справочники, документы и т.п.) клиент может менять, а какие – нет, т.к. их изменение нарушит работоспособность системы или сделает невозможной ее дальнейшую централизованную поддержку поставщиком.

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

В идеале хотелось бы, чтобы пользовательские изменения существовали как бы «в стороне» от стандартной конфигурации поставщика и включались в работу только в момент непосредственного выполнения кода. В этом случае процесс установки обновлений от поставщика станет автоматическим процессом, не требующим вмешательства человека. 1С предлагает два подхода, покрывающих значительный процент сценариев кастомизации.

Первый подход — использование внешних обработок и внешних отчетов. Эти механизмы позволяют надстраивать дополнительную функциональность «сверху» системы, не изменяя исходного кода конфигурации. По сути это скрипты с графическим интерфейсом, предназначенные для запуска на конкретном прикладном решении. Эти механизмы породили свой аналог «App Store», онлайновый магазин, где независимые программисты выкладывают, а конечные пользователи приобретают нужные дополнения для разных программ.

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

Что еще?

Что еще есть интересного/важного в технологической линейке 1С? В списке – наиболее значимые механизмы, о каждом из которых можно написать отдельную статью (или несколько):

• Облачное решение 1cFresh — «облако из коробки», горизонтально масштабируемая среда для работы с прикладными решениями 1С (и фирм-партнеров) в модели сервиса (SaaS). Продукт содержит в себе все нужные для работы SaaS функции – регистрация и управление пользователями, возможность быстрой публикации новых прикладных решений, создание резервных копий пользовательских данных и т.п. Фирма 1С сама использует продукт 1cFresh для предоставления своих продуктов в аренду (http://1cfresh.com), а также продает решение 1cFresh как коробочный продукт, позволяя партнерам и клиентам разворачивать собственные облака для прикладных решений на основе технологий «1С: Предприятие».
• Мобильная платформа 1С (упомянутая выше), позволяющая создавать приложения для мобильных ОС (iOS, Android) из одного исходного кода, используя ту же методику и среду разработки (Конфигуратор), что и для «обычных» приложений 1С.
• Мощная и гибкая система отчетности. Отчеты – крайне важный механизм в любой бизнес-системе; многие ERP используют внешние генераторы отчетов от других производителей, т.к. создание хорошего генератора отчетов – непростая задача с особой спецификой. В 1С отчеты разрабатываются в той же среде (Конфигураторе), что и само приложение; в основе механизма отчетов лежит система компоновки данных (СКД) – механизм декларативного описания отчетов. Одна из важных особенностей отчетов в 1С – это то, что конечный пользователь, может изменить созданный разработчиком отчет «под себя», используя те же возможности по дизайну отчетов, что и разработчик.
• Механизм обмена данными, позволяющий создавать территориально распределенные информационные системы, обменивающиеся данными в офлайн режиме, без постоянного соединения. Обмен данными возможен как между приложениями «1С: Предприятия», так и между приложениями «1С: Предприятия» и сторонними системами.
• И еще много интересного

«1С:Предприятие» — технологии и инструменты

Вместо заключения

Надеюсь, у не знакомых с 1С читателей сложилась более-менее ясная картинка – что такое 1С, как она работает и какие возможности она предоставляет разработчикам. За рамками обзора осталось много интересных тем; о них — в следующий раз.

Платформенно-ориентированный подход к архитектуре приложений был выбран фирмой 1С еще в середине 1990-х. Это своеобразное сочетание мощной платформы и разумно-ограниченного прикладного языка хорошо себя показало – на технологиях 1С создано более 1000 официально сертифицированных фирмой 1С решений для самых разных областей бизнеса, от автоматизации малого бизнеса до систем управления предприятиями с тысячами одновременно работающих пользователей.

Понятно, что при таком подходе особые требования предъявляются к платформе. При разнообразии поддерживаемых технологий платформа должна обеспечивать быструю и надежную работу прикладных решений. Фирма «1С» уже много сделала в этом направлении, и эта работа продолжается.

Comments are welcome:)


Петр Грибанов