Привет всем,

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

ERP может передавать данные разным способом (файл, сокет, RFC) и в разном формате. Предлагается следующая трехслойная модель (кодировать предполагается в , чтобы можно было с на винды без проблем портировать). Для определенности возьмем путь -> наша система:

1-й слой — прием данных от ERP. Он конечно для каждой ERP свой. Может быть сделан или отдельным процессом или библиотекой. Данные переводятся в стандартный формат.
2-й слой (от этого места — стандарт!) — читает данные в соответствии с описанием, которое задает структуру данных в информационном блоке (порядок следования записей, тип, количество полей,...) и вызывает обработчик
3-й слой (обработчик) — проверяет данные в соответствии с параметрированием, декодирует в тот формат в котором должны храниться в базе, если нужно собирает данные из нескольких записей, которые должны закачиваться в одну таблицу и закачивает в нашу базу.

Вопрос по поводу 2-го слоя и интерфейса к 3-му: не хочу изобретать велосипед, наверняка задача уже тысячу раз решена. Как описывать данные? Может что-то типа XML использовать? У кого есть какие идеи?

Заранее спасибо

Здравствуйте, LoginRSDN, Вы писали:

LRS>Вопрос по поводу 2-го слоя и интерфейса к 3-му: не хочу изобретать
LRS>велосипед, наверняка задача уже тысячу раз решена. Как описывать
LRS>данные? Может что-то типа XML использовать? У кого есть какие идеи?

Можно использовать XSLT. Целиком или местами, если его функциональности
окажется не достаточно или по каким-другим причинам не подойдет.

Hello LoginRSDN,

я так полагаю что будет лучше использовать XML,
у нас по такой системе получает данные Управляющая Контора(УК)
из нашей действующей системы, по схеме:
1. каждое утро у нас формируется набор файлов с данными и выкладывается на
FTP;
2. в течении дня сотрудники УК проверяют данные и загружают их в свою систему;
3. сотрудники УК пишут ответ нам о правильности данных, если какие-то данные
не вырны,
то формируем данные заново(тока те кот. ошибочны) пока всё делается вручную

В дальнейшем хоцца автоматизировать процесс обработки ответа от системы УК,
чтоб они выкладывали на FTP XML-файл, в кот. бует содержаться ответ их системы.
например: файл 111.xml содержит след. ошибки и список ошибок (еще не определился
со структурой XML)

WBR,
and_vs

L>
L> Вопрос по поводу 2-го слоя и интерфейса к 3-му: не хочу изобретать
L> велосипед, наверняка задача уже тысячу раз решена. Как описывать
L> данные? Может что-то типа XML использовать? У кого есть какие идеи?
L>
L> Заранее спасибо
L>

Здравствуйте, LoginRSDN, Вы писали:

LRS>Привет всем,

LRS>ставится задача стандартизации процесса перекачивающего данные из внешней ERP-системы в нашу базу данных и (другие данные) обратно.


То, что вам нужно (в теории) называется ETL — Extract-Transform-Load процесс (общие слова читать здесь). Конкретная реализация может быть ваша, а может быть уже что-то из готового софта. У нас была своя реализация, поскольку стадия Transform была весьма специфическая.

Погуглите по ETL — много информации.

Здравствуйте, LoginRSDN, Вы писали:

LRS>2-й слой (от этого места — стандарт!) — читает данные в соответствии с описанием, которое задает структуру данных в информационном блоке (порядок следования записей, тип, количество полей,...) и вызывает обработчик
LRS>Вопрос по поводу 2-го слоя и интерфейса к 3-му: не хочу изобретать велосипед, наверняка задача уже тысячу раз решена. Как описывать данные? Может что-то типа XML использовать? У кого есть какие идеи?

если большой объем данных XML может быть очень медленно (SAX не поможет)....
у меня был один пример когда файлы XML по 50 мб каждый обрабатывался 0,5-1 часа... все думали что все будет ОК, даже тестировали на тестовом потоке....
пока не воткнули в реальный объем
1000 файлов в сутки
проект пришлось переписывать....