forum.clarionlife.net

Есть программа A1 (app+dct) в которой обрабатываются и хранятся данные. Данные из программы A1 надо залить в интернет магазин B1. Пишем модуль для данного интернет магазина С1. Так как интернет магазины (С1....С10) и структура данных в них разные, то приходится писать разные модули в зависимости от БД интернет магазина. Хочется не засорять DCT A1, как разъединить данные которые используются в С1 с интернет магазином при том, что некоторые данные С1 использует из DCT А1? Возможно Вы сталкивались с данной проблемой, буду рад увидеть Ваши варианты.

Логично предположить, что нужен некий универсальный файл обмена данными (формат TPS, TXT, XML - не важно),
который описан в словарях A1 и C1-C10. Программные модули A1 и С1-С10 выполняют обмен данными через этот файл
(загружают/выгружают данные в/из свою структуру БД). В этом случае вообще параллельно, какая структура данных (DCT)
используется в модулях A1 и C1-C10.

Опционально:

1. А если для файла обмена данными используется некий универсальный формат (TXT, CSV, XML, SQLite и т.д.), то в общем-то
все равно и на каких языках программирования написаны программы A1 и C1-C10, какой формат БД используют и под какими операционными системами они работают (Windows, Android, iOS и т.д.)

2. Если для файла обмена данными используется ЭЦП, хеш и / или шифрование - это гарантирует достоверность обмена данными.

Наверно так. Но это придумано очень давно (и конечно же не мною).
Например, Вы работу этой схемы наблюдаете, когда выгружаете платежки в клиент-банк, передаете сведения в ФНС или ПФР ...

Игорь Столяров писал(а):Логично предположить, что нужен некий универсальный файл обмена данными (формат TPS, TXT, XML - не важно),
который описан в словарях A1 и C1-C10. Программные модули A1 и С1-С10 выполняют обмен данными через этот файл
(загружают/выгружают данные в/из свою структуру БД). В этом случае вообще параллельно, какая структура данных (DCT)
используется в модулях A1 и C1-C10. ...

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

когда-то на форуме уже было что-то такое...
вот нашел навскидку http://forum.clarionlife.net/phpbb/view ... 0%B8%D0%BD
http://forum.clarionlife.net/phpbb/view ... D&start=15

У нас обратная ситуация (импорт из х.з. чего в нашу базу), так просто вручную все файлы объявлены в той dll что используется для интеграции и всё. С импортируемыми файлами ведь не надо работать через ABC-классы в общем случае. А еще есть DynaLib, с ней вообще ничего заранее объявлять не нужно

P.S. Я бы не рекомендовал делать приложения С1 - С10. Лучше сделать одно, а внутри кейсы

В контексте обмена данными - есть давняя и нереализованная мечта .... (мозгов не хватает).
Если бы можно было в программе A сформировать In-Memory таблицу и записать ее как область памяти в бинарный файл,
а в программе B загрузить этот бинарный файл в память и присвоить ему указатель на In-Memory таблицу - это было бы супер.
Никто не умеет, случайно, делать такой пассаж ? Или хотя бы такой же ход с QUEUE ...

Игорь Столяров писал(а): программе A сформировать In-Memory таблицу и записать ее как область памяти в бинарный файл,а в программе B загрузить этот бинарный файл в память и присвоить ему указатель на In-Memory таблицу

Это называется "сериализация" и "десериализация".

Дед Пахом писал(а): Это называется "сериализация" и "десериализация".

Угу. JSON в помощь
К сожалению, сохранение In-memory файла в виде буфера не реализовано велосипедистами. То ли из-за лени, то ли из-за того, что сразу была принята неправильная идеология.

RaFaeL писал(а):P.S. Я бы не рекомендовал делать приложения С1 - С10. Лучше сделать одно, а внутри кейсы

Я бы рад, но как это вообще без описания в DCT

Игорь Столяров писал(а):Если бы можно было в программе A сформировать In-Memory таблицу и записать ее как область памяти в бинарный файл,а в программе B загрузить этот бинарный файл в память и присвоить ему указатель на In-Memory таблицу - это было бы супер.Никто не умеет, случайно, делать такой пассаж ? Или хотя бы такой же ход с QUEUE ...

Тоже мозгов не хватает

Ммм... Стесняюсь спросить, а нафига выходные структуры для интернет-магазинов описывать в dct?

gopstop2007 писал(а):Я бы рад, но как это вообще без описания в DCT

Можно описание таблиц не делать в dct, а сделать в теле программы. Допустим, название таблицы одно, а структура разная в зависимости от условий.

gopstop2007 писал(а): Я бы рад, но как это вообще без описания в DCT

Ну так, в глобал ембедс пишешь структуру FILE
Если руками сразу описать сложно, то сначала делаешь описание в dct, генерируешь приложение, лезешь в основной clw что он тебе нагенерил, копируешь оттуда описание файла
Вот тут вставки, каждая условно для одного из "интернет-магазинов", в dct этих файлов нет, используются только в этой dll

finsoftrz писал(а):Ммм... Стесняюсь спросить, а нафига выходные структуры для интернет-магазинов описывать в dct?

Стесняюсь ответить Попросили связать программу с интернет магазином сначала один клиент, пошел по пути наименьшего сопротивления. Сейчас уже не один клиент просит и решил усовершенствовать механизм Как к БД интернет магазина достучатся, помимо DCT ? Я для этого и создал топик , чтобы люди которые возможно сталкивались с данным вопросом, указали путь в какую сторону смотреть. Я знаю массу вариантов предполагаемого решения данного вопроса, но чтобы "изобретать велосипед" надо иметь вторую жизнь И думаю при нынешнем развитии, дальше больше будут сталкиваться с данным вопросом все больше пишущих на кларионе.

kreator писал(а):Можно описание таблиц не делать в dct, а сделать в теле программы. Допустим, название таблицы одно, а структура разная в зависимости от условий.

названия таблиц могут тоже отличаться

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

А зачем какие-то структуры использовать? Обмен с интернет-магазином обычно делается через csv или xml файлы. На крайний случай, если нужно буферизировать, можно использовать обычные локальные или app-шные очереди. Для своих интернетовских модулей я предпочитаю сразу создавать sqlite файлы в том виде, как они используются в вебе. Но это если все в своих руках - во много раз быстрее и проще...