Прием данных
Top  Previous  Next

1. Внутренний формат

Прием данных, отправленных в адрес данной фирмы от других участников обмена, осуществляется на закладке "Прием данных":

clip0146

Для иллюстрации процесса предположим, что текущая база данных принадлежит фирме "Полюс", как это было проиллюстрировано в примере в разделе Отправка данных:

clip0028

и ее общие настройки выглядят так:

clip0147

Предположим также, что сообщения, отправленые в примере раздела Отправка данных, поступили в почтовый ящик polus@demo.com фирмы "Полюс".

Прием сообщений от узла-источника состоит из двух этапов:
   1) собственно прием входящих сообщений;
   2) обработка принятых сообщений.

Особый случай приема сообщений рассмотрен далее в специальном разделе Прием сообщений в формате XML+ZIP на web-сайтах.

1.1. Этап 1 - Прием входящих сообщений во внутреннем формате

Прием сообщений, переданных посредством файлов заключается в простом переносе этих файлов сообщений с носителя данных (флэш-диск, CD-диск и т.д.) в каталог входящих.

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

clip0148

Нажатие на кнопку "Да" эквивалентно нажатию на кнопку "Обработать принятые сообщения" на закладке "Прием данных" (см. "Этап 2").

ВНИМАНИЕ: Обратите внимание, что принято было 3 сообщения: 2 из них были предназначены для обмена между программами "Агентство недвижимости", а третье - оказалось случайным (699 байт, по поводу этого же сообщения в журнал была выведена строка "Предупреждение: в принятом сообщении нет ни одного присоединенного файла"). Программа по специальным признакам узнает сообщения, которые она может обработать, и обрабатывает только их (в нашем случае 2 сообщения от узла "Экватор". Следует также отметить, что программа удаляет с почтового сервера успешно принятые сообщения, поэтому почтовые ящики, задействованные в обмене данными между узлами "Агентства недвижимости", категорически не рекомендуется использовать для какой-либо другой корреспонденции, в т.ч. для традиционной переписки.

1.2. Этап 2 - Обработка принятых сообщений во внутреннем формате

Процесс обработки принятых сообщений принимает во внимание как сообщения, принятые по e-mail, так и сообщения, скопированные в каталог входящих с различных носителей информации. После нажатия на кнопку "Обработать принятые сообщения" программа просматривает каталог входящих и выбрасывает из рассмотрения те сообщения, которые:
1)созданы данным узлом для данного узла (т.е., например, сообщения от узла 48 узлу 48 приняты не будут);  
2)предназначены не данному узлу (в нашем примере адресатом сообщений должен быть узел 48);  
3)узел-отправитель не содержится в справочнике участников обмена данными (в нашем примере в этом справочнике содержится только участник "Экватор");  
4)являются "чужими" сообщениями, т.е. отправленными не программой "Агентство недвижимости".  
   
Среди оставшихся сообщений программа пытается выделить сообщения, являющиеся составными частями ранее разбитого сообщения (если такое разбиение имело место). Если все части, необходимые для соединения (сборки) в исходное сообщение (каким оно было до разбиения, см. Отправка данных) имеются, то программа собирает это исходное сообщение, а части перемещает в каталог "\Обработанные". Может оказаться, что для сборки первоначального сообщения не хватает каких-либо частей - это может произойти по различным причинам: обрыв связи во время приема данных, переполнение почтового ящика (особенно на бесплатных почтовых сервисах) и т.д. Такие неполные комплекты частей сообщений останутся в каталоге входящих нетронутыми. Если необходимые дополняющие части не приходят длительное время (часы, дни, недели - в зависимости от установившегося графика обмена данными), то эти части можно удалить - либо с помощью кнопки "Удалить сообщение", либо напрямую из каталога входящих.

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

В процессе импорта заявок выполняются следующие действия:

1)Параметры «Город», «Муниципальный округ», «Микрорайон», «Улица», «Метро», «Источник заявок», «Тип квартиры» импортируемых заявок вносятся в свою базу данных, если до этого они там отсутствовали. При этом гарантируется отсутствие дубликатов (для географических параметров см. далее: "Особенности: Импорт географических данных");  
2)Импортированная заявка изменяет некоторые свои параметры:  
Пользователь = <ТекущийПользователь>,  
Агент = «?»  

Процесс импорта сопровождается прогрессором:

clip0046

clip0047

clip0048

Наконец, пользователь извещается о завершении процесса:

clip0149

Особенности: Импорт географических данных

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

1)В импортируемом гео-справочнике округ принадлежит непосредственно городу. Импорт не будет выполнен, если в гео-справочнике в базе данных уже присутствуют микрорайоны или улицы, принадлежащие непосредственно данному городу;  
2)В импортируемом гео-справочнике микрорайон принадлежит непосредственно городу. Импорт не будет выполнен, если в гео-справочнике в базе данных уже присутствуют округа или улицы, принадлежащие непосредственно данному городу;  
3) В импортируемом гео-справочнике улица принадлежит непосредственно городу. Импорт не будет выполнен, если в гео-справочнике в базе данных уже присутствуют округа или микрорайоны, принадлежащие непосредственно данному городу;  

В случае появления перечисленных несоответствий все необходимые диагностические сообщения будут выведены, как и в случае отправки данных (см. Отправка данных), в "Журнал обмена данными".


2. Прием сообщений в формате XML+ZIP на web-сайтах

Сообщение в формате XML+ZIP оформляется в файл вида 47=20051107-2220.xml.zip (см. пример в разделе Отправка данных), где фрагмент .zip означает, что сообщение запаковано методом ZIP, фрагмент .xml означает, что исходное сообщение представлено в формате XML, 47 - номер узла-отправителя, 20051107-2220 - сообщение было сформировано 7 ноября 2005 года в 22 ч. 20 мин.

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

1. Сообщение упаковано методом ZIP, поэтому может быть легко распаковано. После распаковки будет получен исходный файл, в нашем случае - 47=20051107-2220.xml.

2. Структура файла *.XML позволяет получить необходимые параметры объектов недвижимости для загрузки их из файла в базу данных сайта. Ниже приведен фрагмент одной заявки:

clip0054

3. Англоязычные идентификаторы в файле, как правило, позволяют легко уяснить их смысл. Поясним здесь только 3 поля:

RLT_MAIN_OBJECTCODE - Вид объекта недвижимости:
   1 - квартира
   2 - комната
   3 - дом
   4 - участок
   5 - нежилое помещение
   6 - нежилое строение
   7 - торговое помещение/здание
   8 - участок под застройку

RLT_MAIN_ACTIONCODE - Операция:
   1 - продам
   2 - куплю
   3 - сдам
   4 - сниму

RLT_MAIN_ID - Номер заявки. Например, номер 2800047 означает, что заявка была сформирована на узле 00047 (пять младших цифр) и имеет на этом узле номер 28.

При возникновении затруднений с интерпретацией других полей разработчики сайта могут обратиться в службу технической поддержки www.realty-soft.ru
.

3. Прием сообщений в форматах "XML+Документы" и "Дельта XML+Документы" на web-сайтах

5 категорий файлов, образующих формат XML+Документы (3 категории из 5 используются при формировании отправляемых собщений "Формат: XML+Документы. Способ отправки: Не отправлять", все 5 категорий используются при формировании отправляемых собщений "Формат: Дельта XML+Документы. Способ отправки: <XXX>") рассмотрены в разделе Отправка данных:

1) XML-файл параметров заявок. По структуре идентичен формату XML+ZIP - см. выше параграф "Прием сообщений в формате XML+ZIP на web-сайтах".

2) Набор файлов документов (в частности - иллюстраций) по объектам недвижимости.

3) Индексный XML-файл для упрощения навигации по файлам двух предыдущих категорий. Элементы этого XML-документа:

0
REALTY_IDX
Главный элемент
1
COMMON
Общие сведения об экспортируемых данных. Содержит вложенные элементы:
1.1
COUNT
число заявок в сообщении
1.2
QU_ZIP_FILE_NAME
имя ZIP-архива XML-файла с параметрами заявок
1.3
QU_ZIP_FILE_SIZE
размер в байтах ZIP-архива XML-файла с параметрами заявок
1.4
QU_ZIP_FILE_CRC32
контрольная сумма CRC32 для ZIP-архива XML-файла с параметрами заявок
2
FIELDS
Список имен всех параметров заявки. Содержит вложенные элементы:
2.1
FIELD
имя параметра заявки
3
MAINROWS
Список номеров и контрольных сумм CRC32 всех заявок в сообщении. Содержит вложенные элементы:
3.1
ROW
элемент для каждой из заявок. Атрибуты:
ID=<ПолныйНомерЗаявки>
CRC32=<CRC32СтроковогоЭквивалентаЗаявки>
4
FILES
Список присоединенных файлов в заявках. Содержит вложенные элементы:
4.1
FILE
описание отдельного присоединенного файла. Атрибуты:
FILE_NAME=<ИмяФайла>
FILE_SIZE=<РазмерФайлаВБайтах>
FILE_CRC32=<CRC32Файла>
DOCID=<ПолныйНомерДокумента>
RLTMAINID   =<ПолныйНомерЗаявки>


4) "Дельта"-XML-файл параметров заявок. По структуре идентичен формату XML+ZIP - см. выше параграф "Прием сообщений в формате XML+ZIP на web-сайтах".

5) "Дельта"-Индексный-XML-файл. Элементы этого XML-документа:

0
REALTY_DELTA_IDX
Главный элемент
1
COMMON
Общие сведения об экспортируемых данных. Содержит вложенные элементы:
1.1
COUNT
число заявок в сообщении
1.2
QU_ZIP_FILE_NAME
имя ZIP-архива "Дельта"-XML-файла с параметрами заявок
1.3
QU_ZIP_FILE_SIZE
размер в байтах ZIP-архива "Дельта"-XML-файла с параметрами заявок
1.4
QU_ZIP_FILE_CRC32
контрольная сумма CRC32 для ZIP-архива "Дельта"-XML-файла с параметрами заявок
2
FIELDS
Список имен всех параметров заявки. Содержит вложенные элементы:
2.1
FIELD
имя параметра заявки
3
MAINROWS_DELTA_CHANGED
Список заявок, измененных по сравнению с предыдущей выгрузкой заявок на сервер FTP. Содержит вложенные элементы:
3.1
ROW
элемент для каждой из заявок. Атрибуты:
ID=<ПолныйНомерЗаявки>
CRC32=<CRC32СтроковогоЭквивалентаЗаявки>
4
MAINROWS_DELTA_ADDED
Список заявок, которые были добавлены по сравнению с предыдущей выгрузкой заявок на сервер FTP. Содержит вложенные элементы:
4.1
ROW
Аналогично 3.1
5
MAINROWS_DELTA_DELETED
Список заявок, которые были удалены по сравнению с предыдущей выгрузкой заявок на сервер FTP. Содержит вложенные элементы:
5.1
ROW
Аналогично 3.1
6
FILES_CHANGED
Список присоединенных файлов в заявках, которые (файлы) были изменены по сравнению с предыдущей выгрузкой заявок на сервер FTP. Содержит вложенные элементы:
6.1
FILE
описание отдельного присоединенного файла. Атрибуты:
FILE_NAME=<ИмяФайла>
FILE_SIZE=<РазмерФайлаВБайтах>
FILE_CRC32=<CRC32Файла>
DOCID=<ПолныйНомерДокумента>
RLTMAINID   =<ПолныйНомерЗаявки>
7
FILES_ADDED
Список присоединенных файлов в заявках, которые (файлы) были добавлены по сравнению с предыдущей выгрузкой заявок на сервер FTP. Содержит вложенные элементы:
7.1
FILE
Аналогично 6.1
8
FILES_DELETED
Список присоединенных файлов в заявках, которые (файлы) были удалены по сравнению с предыдущей выгрузкой заявок на сервер FTP. Содержит вложенные элементы:
8.1
FILE
Аналогично 6.1