Activex-Компонент - рассылка почтовых сообщений с ASP страниц. Имеет встроенную автоматическую перекодировку из исходной в кодировку принимающей стороны.

Программа представляет собой сервер OLE Automation ,обеспечивающий выполнение всех основных операций Btrieve из Excel,Visual Basic . Программа работает непосредственно с Btrieve Engine с одной стороны и системой OLE с другой.Это обеспечивает ее высокое быстродействие .

Semonitor - это программа для раскрутки сайта. Она состоит из набора утилит, охватывающих различные стороны процесса оптимизации. Предлагаемые решения просты в использовании и успешно применяются как профессионалами, так и начинающими оптимизаторами. Модуль "Определение позиций" - программа, позволяющая узнать, какие позиции ваш сайт занимает в поисковиках по выбранным ключевым словам. Поддерживаются все российские поисковые системы. Кроме традиционной "большой тройки" - Яндекс, Рамблер, Апорт - Semonitor поддерживает также Google.ru и, ставшие популярными в последнее время, Mail.ru и Km.ru. Из международных поисковых систем представлены Google, Yahoo, MSN, AltaVista и другие (всего более 30).

Модуль "Внешние ссылки" - программа для анализа внешних ссылок на ваш ресурс. Большое количество внешних ссылок является одним из определяющих факторов успешной раскрутки в поисковых системах. Semonitor позволяет составить наиболее полный список ссылок на ваш проект, отслеживать их динамику (выявлять новые и устаревшие), а также анализировать конкурентов и искать тематические ресурсы для обмена ссылками. Модуль "Индексация сайта" - программа для проверки индексации сайта поисковыми системами. Прежде чем страница сможет попасть в результаты поиска по ключевым словам, она должна быть проиндексирована поисковыми системами. Semonitor позволяет определить все страницы вашего сайта, присутствующие в индексе того или иного поисковика. Модуль "Лог анализатор" - предназначен для анализа лог-файлов. Позволяет оценить посещаемость ресурса, поисковые запросы, рефереры, географию посетителей и многое другое. Модуль "Page Rank анализатор" - позволяет автоматически определять Google PageRank, тематический индекс цитирования Яндекс (ТИЦ), число внешних ссылок и присутствие в каталогах Яндекс, DMOZ и Yahoo для заданного списка веб-адресов (УРЛ). Модуль "Подбор ключевых слов" - используя различные источники, подбирает релевантные ключевые слова, а также оценивает уровень конкуренции по ним. Модуль "HTML анализатор" - программа для анализа содержимого html страниц. Позволяет определять вес и плотность ключевых слов на странице, искать ключевые фразы и словосочетания. Может быть использована как для предварительного анализа собственного проекта, так и для анализа конкурентов. Модуль "Google дата-центры" - программа для проверки позиций на всех дата-центрах Google, будет полезна при плотной работе с этой поисковой системой. Модуль "Работа со сниппетами" - описания (сниппеты), выдаваемые поисковыми системами для вашего ресурса также очень важны. Привлекательное описание заставит посетителей выбрать именно вашу ссылку среди прочих, предложенных поисковой системой. Программа позволяет вести историю и анализ таких описаний. Использование программы Semonitor позволяет автоматизировать процесс раскрутки сайта, что дает значительную экономию времени при работе над проектом, а также позволяет добиться лучших результатов.

Эта книга адресована всем, кто разрабатывает web-страницы назло препятствиям, заложенным в существующее программное обеспечение.
На ее страницах вы найдете всесторонний анализ программной поддержки, необходимой для размещения динамического сайта в Интернете. Все web-разработчики знают, насколько сложно сделать страницу, одинаково выглядящую при четырех разрешениях монитора и во всех существующих браузерах. С помощью автора вы освоите тонкости DHTML, и разработанный вами web-сайт будет радовать вас, его хозяина, и посетителей.

В книге дано описание основных элементов языка Ассемблера семейства IBM PC: системы счисления, машинное представление данных и команд, основы 16- и 32-разрядного программирования, программирование сопроцессора, ввод-вывод информации в DOS и Windows, использование макросредств. Подробно, шаг за шагом на многочисленных примерах законченных программ рассматриваются идеи и принципы организации вычислений на Ассемблере от простого к сложному, используя аналогию и прямую поддержку со стороны алгоритмических языков Pascal (Borland Pascal-7.0. Delphi-5) и C/C++ (Borland C++ 3.1,4.5. 5.02, Borland C++ Builder 5, Visual C++ 6.0).

Книга известного профессионала в области баз данных посвящена новым версиям самой популярной в настоящее время базы данных, рассчитанной на широкий круг пользователей - MySQL. Подробно рассматриваются такие вопросы, как установка и конфигурирование MySQL, выполнение повседневных задач и улучшение производительности. На примере тестовых баз данных он приводит решения проблем, с которыми читатель обязательно должен столкнуться при практическом использовании реляционной СУБД MySQL. Читатель получит навыки интеграции MySQL с такими программными средствами, разработанными сторонними компаниями, как компиляторы языков PHP и Perl, позволяющими создавать с помощью запросов к базе данных динамические Web-страницы. Кроме того, здесь приведен обширный справочный материал, посвященный таким темам, как типы столбцов, операторы, функции, синтаксические конструкции языка SQL, интерфейсам C API, Perl DBI и PHP API. В книге уделено особое внимание доработкам и дополнениям, появившимся в версиях 4.1 и 5.0.
Книга рассчитана на пользователей, администраторов и разработчиков систем клиент/сервер на основе MySQL.

Электронная книга The Art of Deception - "Искусство обмана" - доказывает, насколько мы все уязвимы. В современном мире, где безопасность подчас выходит на первый план, на защиту компьютерных сетей и информации тратятся огромные деньги. Деньги тратятся на технологии безопасности. Эта книга объясняет, как просто бывает перехитрить всех защитников и обойти технологическую оборону, как работают социоинженеры и как отразить нападение с их стороны Кевин Митник и его соавтор, Бил Саймон рассказывают множество историй, которые раскрывают секреты социальной инженерии. Авторы дают практические советы по защите от атак, по обеспечению корпоративной безопасности и снижению информационной угрозы "Искусство обмана" не только демонстрирует, насколько опасна и вредоносна социоинженерия, но поможет разработать собственную программу тренинга по безопасности для сотрудников компании.

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

От автора: "Этот документ для тех, кто хочет писать модули ядра. Хотя я буду касаться в нескольких местах того, как многие задачи выполнены в ядре, это не моя цель. Имеется достаточно много хороших источников, авторы которых проделали работу лучшую чем та, которую я мог бы сделать.
Этот документ также для людей, которые знают как писать модули ядра, но еще не адаптировались к версии 2.2. Если Вы такой человек, я предлагаю, Вам прочитать приложение A, чтобы увидеть все различия, с которыми я столкнулся при модифицировании примеров. Список не всесторонний, но я думаю, что он покрывает большинство базисных функциональных возможностей и его будет достаточно для начала.

Ядро имеет большое количество программирования, и я полагаю, что программисты должны читать по крайней мере некоторые его исходные файлы и понимать их. Сказав это, я также верю в значение игры с системой сначала и выяснением вопросов позже. Когда я узнаю новый язык программирования, я не начинаю с чтения библиотечного кода, а пишу маленькую программу "hello, world". Я не вижу, почему начинающий разбираться с ядром должен быть действовать иначе."

Прикладное программирование для Web начиналось с обработки запросов пользователя и динамической генерации страниц на стороне сервера. Эта же тенденция получила развитие и в языках программирования вставок в HTML-документы. Затем появились языки программирования элементов HTML-документов на стороне клиента. И те, и другие привязаны к модели данных HTML. Сегодня, когда Web мигрирует к стеку спецификаций XML, разработчики средств программирования должны это учесть и правильно отреагировать, позволив, например, манипулировать элементами XML-разметки. Стандарт, призванный обозначить и решить эту задачу, получил название Document Object Model - DOM.

Настоящая книга является с одной стороны, подробным справочником по Visual Basic for Applications (VBA), а с другой стороны, самоучителем по составлению и разработке приложений, написанных на этом языке. Это уникальное сочетание, которое, следуя рекламному подходу, можно назвать "два в одном", обеспечивает большую гибкость при решении читателем своих собственных задач. Самоучитель на большом количестве примеров умело и доступно обучает, как можно быстро и эффективно решать разнообразные задачи. В справочнике приводится подробное описание возможностей VBA, имея такие сведения под рукой у читателя исчезнет необходимость бегать по магазинам в поиске дополнительной литературы при написании самостоятельных приложений, что несомненно сбережет время и кошелек.
Самоучитель состоит из уроков. В каждом из уроков разрабатывается пример пользовательского приложения и дается подробный анализ. Тексты всех программ снабжены доскональными комментариями. Можно сказать, что все рассматриваемые программы разложены буквально по маленьким разжеванным кусочкам, которые читателю только и остается проглотить. По завершению урока предлагается самостоятельное задание, выполнение которого поможет лучше закрепить разобранный материал.

С помощью VBA можно легко и быстро создавать пользовательские приложения, используя единую для всех офисных программ среду и язык. Научившись разрабатывать приложения для одной офисной программы, например Excel (которой, как наиболее популярной офисной программе, в основном и посвящена данная книга), можно создавать приложения и для других офисных программ, например Access. Внимательно читая эту книгу, можно стать искусным разработчиком и научиться пользоваться мощными средствами разработки приложений Excel для того, чтобы конструировать эффективные и применимые к реальной жизни приложения. Кроме того, по своей структуре, интерфейсу и синтаксису VBA образует ядро Visual Basic. Поэтому тот, кто изучит программирование на VBA очень быстро может освоить и Visual Basic.

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

Для операционной системы Linux долгое время не было достаточно простой среды быстрой разработки приложений. Многие программисты, которые успешно создают программы для Windows, используют среду Borland Delphi. В нашей стране Delphi пользуется особой популярностью как среди начинающих разработчиков, так и среди профессионалов. Многие из них готовы создавать программы для среды Linux, но не было среды, похожей на Delphi. Наконец, летом 2001 года фирма Borland выпустила среду для быстрой разработки приложений в среде Linux и назвала ее Kylix (Kylix — это античная винная чаша, расписанная с внешней и внутренней стороны). На первый взгляд, эта среда — практически копия Delphi, но есть некоторые отличия. Причем эти отличия являются довольно опасными, т. к. одна и та же команда в Delphi и Kylix может привести к совершенно разным последствиям. Данная книга представляет собой краткий обзор среды Kylix версии Kylix Server Developer. С помощью нее вы узнаете особенности среды Kylix и ее отличия от Delphi. Кроме того, заключительная часть книги расскажет вам о методах переноса приложений из Delphi в Kylix и создании межплатформенных приложений.

Книга предназначена для всех желающих изучить среду Kylix и научиться создавать работоспособные программы под Linux. Стиль изложения материала — от простого к сложному, приведены многочисленные примеры. Конечно, желательно, чтобы читатель был знаком (хотя бы поверхностно) с операционной системой Linux и программированием. Данная книга будет читаться еще легче, если вы знакомы с программированием в Delphi.

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

Цель этой книги — познакомить разработчиков с технологиями использования XML в программах на Java. Вместо того чтобы рассказывать о теоретической стороне дела, авторы сразу переходят к практическому применению этих технологий на примере построения коммерческого web-сайта.

Глава 1. В этой главе вы найдете введение в XML с объяснениями всех каверзных моментов этого языка и типичных способов его использования. Также в этой главе приводится обзор двух моделей обработки данных XML с помощью Java — DOM и SAX.

Глава 2. Эта глава посвящена решению вопросов, возникающих при разработке каталога товаров на XML. Этот язык является настолько гибким, что иногда бывает непросто выбрать один из многих способов представления данных. Выбранная структура каталога иллюстрирует многие важные задачи, которые вам придется решать при разработке собственного проекта подобного рода. Построенный нами каталог, который дорабатывается в следующих главах, включает описания более сотни наименований товаров.

Глава 3. Эта глава начинается с обзора интерфейсов API для сервлетов Java и JSP-страниц, используемых для создания динамических web-страниц Затем мы рассматриваем стандартные интерфейсы API Java для извлечения данных из документов XML, после чего мы объединяем все эти функции в сервлете Java, предназначенном для получения информации из каталога и отображения ее в формате HTML. В числе прочих этот сервлет реализует возможность поиска товаров по ключевым словам.

Глава 4. В этой главе мы расширяем классы для представления каталога из главы 3 и создаем действующую корзину покупателя, которая позволяет покупателю заказывать товары через Интернет. В процессе создания этого приложения мы рассказываем о том, как концепция мониторинга сеанса реализована в сервлетах Java.

Глава 5. Теперь, когда у нас имеется корзина покупателя, нам нужно обеспечить возможность получения денег от клиента и оформления заказа (разумеется, с использованием XML). В нашем примере для представления соответствующей информации клиенту используется технология JavaServer Pages.

Глава 6. В этой главе мы исследуем задачу обновления каталога, отформатированного средствами XML, через специальный интерфейс в режиме подключения к сети.

Глава 7. Насущной потребностью для любого коммерческого сайта является способность собирать информацию о своих клиентах. В этой главе приводится основанная на XML система опроса, в которой предусмотрена возможность ветвления (возможность задавать различные вопросы различным пользователям в зависимости от их ответов на определенные специальные вопросы). Возникающая задача анализа собранных результатов дает нам возможность продемонстрировать, как с помощью интерфейса SAX обрабатывать большие документы XML.

Глава 8. Каждому коммерческому сайту необходимо как-то информировать клиентов о новостях компании. В этой главе на основе XML разрабатываются гибкая система для отображения новостей компании, а также сервлеты и JSP-страницы для ее поддержки.

Глава 9. В наши дни многие коммерческие сайты включают в свои домашние страницы заголовки новостей, пытаясь тем самым заинтересовать пользователей и стимулировать их к частому посещению сайта. Как показано в этой главе, вы можете обеспечить присутствие на вашем сайте текущих новостей буквально по сотням тематических категорий, и для этого не нужен целый штат репортеров — всего лишь XML и Java.

Глава 10. В предыдущих главах рассказывается о деталях организации ресурсов для web-приложения на Java. В этой главе мы приводим обзор спецификации Sun для версии API 2.2 сервлетов Java и обсуждаем интерфейсы для Java и XML следующего поколения.

Основным, простейшим, но в то же время чрезвычайно мощным инструментом поддержки больших наборов документов является SSI (Server-Side Includes - включения на стороне сервера). Если кто-то из вас знает Си, то он быстро поймет, что SSI чрезвычайно похож на макроязык. С помощью SSI можно не только в зависимости от некоторых условий выводить определенные части документа, не только формировать документ из заранее определенных кусочков, но и вставлять результат работы некоторого CGI сценария или программы прямо в документ.

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

Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.



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

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

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

В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.

В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.

Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.

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

Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).



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

константа,

элемент справочника,

документ,

календарь,

счет бухгалтерского учета,

типовая операция.

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

Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().

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

Сам ведущий объект;

Идентификатор той ИБ, в которую должно быть передано изменение;

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

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

Выгрузка и загрузка изменений

Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.

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

В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.

При загрузке файла переноса данных помимо загрузки измененных данных выполняется так называемый прием подтверждений.

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

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

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

Изменения конфигурации

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

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

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

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

Заметим, что конфигурация считается измененной при любых изменениях метаданных, форм, модулей, таблиц конфигурации, наборов прав, пользовательских интерфейсов, описаний. В состав конфигурации не входит список пользователей, а также внешние по отношению к файлу конфигурации (1CV7.MD) файлы (внешние отчеты, отдельно записанные таблицы и тексты). И эти внешние файлы не переносятся механизмом управления распределенной ИБ. Поэтому при конфигурировании распределенной системы не рекомендуется использовать в конфигурации находящиеся в отдельных файлах модули, таблицы и отчеты.

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

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

Продолжение статьи


[pagebreak]

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

Коллизии

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

Один и тот же объект изменен более чем в одной ИБ.

Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются.

Объект, измененный в одной ИБ, удален в другой.

В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.

Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.

Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.

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

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

При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.

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

Параметры миграции

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

Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.

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

Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.

В случае выбора такого варианта области распространения, объекты данного вида помимо места их создания попадают еще и на центральную ИБ. То есть, в случае, если для некоторого вида объектов установлена область распространения "Место создания и центр", то для объектов этого вида, созданных на периферийной ИБ, их изменения будут передаваться между местом их создания и центральной ИБ. Для объектов того же вида, созданных на центральной ИБ, изменения не будут передаваться никуда. С помощью такого варианта области распространения можно добиться такого эффекта, что все объекты того или иного вида будут "собираться" на центральной ИБ, а на любой из периферийных ИБ будут находиться только те объекты, для которых она является местом создания.

В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.

Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".

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

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

Наиболее простой случай - это смена любого из вариантов области распространения на вариант "Место создания". В этом случае из таблицы регистрации изменений удаляются все записи по данному виду объектов. То есть все изменения объектов, еще не переданные в другие ИБ, не будут переданы. При этом, все объекты для которых данная ИБ не является местом создания, не будут удалены. Просто их изменения (как и изменения других объектов данного вида) не будут больше передаваться в другие ИБ.

Следующий случай - это смена области распространения "Место создания" на варианты "Все информационные базы" или "Место создания и центр". В этом случае в таблицу регистрации изменений заносятся записи для передачи всех объектов, для которых текущая ИБ является местом создания во все ИБ, в которые должны передаваться изменения в соответствии с вновь заданной настройкой. В случае, если такая смена производится для объектов, для которых место создания не определено (константы, календари, корректные проводки), то записи в таблицу регистрации изменений будут произведены только в центральной ИБ. Этими двумя вариантами и ограничиваются возможные случаи изменения параметров миграции для такого рода объектов. Все остальные случаи возможны только для тех объектов, для которых место создания можно определить.

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

Последний и самый сложный случай - это изменение области распространения объектов с "Все информационные базы" на "Место создания и центр" или изменение списка дополнительных ИБ в варианте "Место создания и центр". Действия, производимые в данном случае различаются в зависимости от того, производятся они в центральной ИБ или в периферийной. В центральной ИБ для каждой из периферийных ИБ, не попавших в новый перечень дополнительно включаемых в область распространения, выполняется удаление из таблицы регистрации изменений записей соответствующих данному виду объектов, но только для тех объектов, для которых эта периферийная ИБ не является местом создания. Затем определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. Естественно, что в случае, если предыдущим вариантом настройки области распространения было "Все информационные базы", то этот список окажется пустым. Затем, как и в предыдущем случае, производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.

Проблемы конфигурирования и администрирования

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

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

Более сложной проблемой является ситуация, когда возникает необходимость использования некоторого нового объекта в двух и более узлах одновременно, до осуществления передачи данных. Например, новый товар должен быть введен и на центральной ИБ и на периферийной. Важно понимать, что созданный ведущий объект системы 1С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.

Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.

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

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

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

Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".