ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

[George Nordic]

Цитата:

Сообщение от mazzy

А вот хорошая тема. или Kafka. или даже MSMQ. В общем, любой вменяемый брокер сообщений

Только имей в виду, что большинство брокеров - под Linux или Apache стек, как это будет жить с MS средой или Azure - тот еще вопрос.

Цитата:

Сообщение от mazzy

и ты конечно имеешь в виду, что пакетная обработка в обеих конечных точках (ax2012, ax2009).

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

Цитата:

Сообщение от mazzy

но тут возникает вопрос следующего уровня - а как правильно обращаться к этим брокерам сообщений из Аксапты?

Про источник - выше. Про приемник - а что мешает использовать специальную таблицу для синхронизации? Все равно или её, или очередь надо разбирать имеено внутренними средствами Аксы - RecId и прочее сами себя не добавят.

Цитата:

Сообщение от mazzy

причем и с брокерами нужно как-то решать тот же вопрос про 100500 элементов коллекции. или где-то решен вопрос как передавать коллекции через брокер?или в брокер можно передавать элементы по одному и не париться о накладных расходах?

Да, оставь технику брокеру. Просто добавляй в очередь и успевай разгребать приёмник. В первый раз будет больно синхронизация может занять продолжительное время, но потом все будет обрабатываться по мере поступления: на лету (по триггеру или по пакетной обработке) со стороны источника, со стороны приёмника же - по пакетной обработке.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Только имей в виду, что большинство брокеров - под Linux или Apache стек, как это будет жить с MS средой или Azure - тот еще вопрос.

имею. поэтому и говорю о "каком-то брокере"

Цитата:

Сообщение от George Nordic

Про приемник - а что мешает использовать специальную таблицу для синхронизации?

таблица - это уже знания структуре данных на той стороне.
таблица - это права на той стороне

понятно, что можно.
но является ли это правильным подходом?
а как правильнее?

Цитата:

Сообщение от George Nordic

Все равно или её, или очередь надо разбирать имеено внутренними средствами Аксы - RecId и прочее сами себя не добавят.

угу. именно поэтому в вопросе явно указаны аксапты

Цитата:

Сообщение от George Nordic

Да, оставь технику брокеру. Просто добавляй в очередь и успевай разгребать приёмник.

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

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

или правильным является "сделать собственные dll'ки, которые снаружи работают со стримами, а аксапте отдают объекты по одному"?
и чтобы эти собственные dll'ки работали в адресном пространстве аксапты...
https://coub.com/view/12jn53

Цитата:

Сообщение от Vadik

Это сугубо мое личное мнение, но по-моему "правильно" было бы не запрашивать "огромную коллекцию из 100500 элементов" "раз в 5 минут" а держать ее в обеих системах, синхронизовывать изменения и работать с ней в обеих системах локально ?

да, это понятно.

я не стал акцентировать, когда увидел прошлый твой ответ,
но обрати внимание, что в вопросе было "передавать", а ты постоянно отвечаешь "запрашивать"
ты считаешь, что это одинаковые действия? почему?

и понятно, что регулярно раз в 5 минут 100500 элементов передаваться не будут. но при пиковых нагрузках элементов будет много.

собственно об этом и вопрос:
как правильно передавать много элементов коллекции?

[George Nordic]

Цитата:

Сообщение от mazzy

как правильно передавать много элементов коллекции?

Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.

Все эти продукты могут в режиме, близко к реальному, переносить данные из таблицы А в одной среде к таблицы В в другой. Не все могут переносить структуру таблиц - обычно только поля (только Qlik Attuniy умеет, кстати). Почти все (кроме, кажется, Debezeum) умеют маскировать выбранные поля. Ни одна не умеет генерить локальный RecId из другой системы. Это означает одно - синхронизировать-то мы можем, а вот доп. обвязку в виде тех же RecID необходимо будет делать силами интегрируемой системы, такой как Аксапта. Я знаю про пакетную обработку, возможно, если и другие пути добавления необходимой служебной информации, но я про них не наслышан.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.

прирожденный продавец

мы уже давно во взрослом мире.
и как я говорил, решение уже есть.

давай лучше поговорим как правильно? и как правильно делают упомянутые тобой решения?

[George Nordic]

Цитата:

Сообщение от mazzy

прирожденный продавец

Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.

Цитата:

Сообщение от mazzy

и как правильно делают упомянутые тобой решения?

упомянутые мною решения, как платные так и open source, делают одно - он реплицируют данные из системы А в систему В. В режиме, близком в режиму реального времени, хотя временной лаг все равно есть. Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву. И, некоторые, установки агента, что уже не по нраву и безопасникам.

• Если задача стоит "надо сделать так, чтобы в системе В мгновенно отображались данные системы А" - горячее копирование, личный кабинет, репликация баз данных и т.п. - то это только CDC.

• Если изменений не так много и скорость репликации не так важна, но тоже критична, то можно обойтись брокером сообщений.

• Если изменения необходимо синхронизировать раз в день или раз в неделю, то можно реплицировать таблицы bulk load или просто инкрементом передавать новые / измененые / удаленные данные.

Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.

я тоже!

- пойдем простым логическим путём
- пойдем вместе!
https://www.youtube.com/watch?v=wK1fq2QZbRk

Цитата:

Сообщение от George Nordic

Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву.

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

во-вторых, я не зря упомянул ax2009 и ax2012
в ax2012 (в той самой, где перехерачили главную книгу) перехерачили очень много других таблиц. в результате ОЧЕНЬ много таблиц в ax2012 не совпадают с ax2009

взять тривиальную таблицу единиц измерения.
в единицах измерения разное все - количество таблиц, количество полей, ограничения на поля. даже одинаковые по смыслу enum'ы разные!



Да, я понял что ты хотел сказать про синхронизацию баз данных.
я не считаю этот способ правильным ни для Аксапт, ни для других разнородных клиентов.

Цитата:

Сообщение от George Nordic

Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere.

начинается...
да, я тоже за грамотность.

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

я думаю, что для аксапты не актуально горячее копирование.
я думаю, что для аксапты актуальны эти варианты:

Цитата:

Сообщение от George Nordic

• Если изменений не так много и скорость репликации не так важна, но тоже критична, то можно обойтись брокером сообщений.

• Если изменения необходимо синхронизировать раз в день или раз в неделю, то можно реплицировать таблицы bulk load или просто инкрементом передавать новые / измененые / удаленные данные.

Причём, ни фига НЕ "инкрементом"!
инкремент за dDOS'ит системы нафиг. Для аксапты характерны таблицы, в которых поля обновляются часто. Какая-нибудь последняя себестоимость в карточках номенклатуры, например.

[George Nordic]

Цитата:

Сообщение от mazzy

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

Это не совсем так, есть класс задач, когда по-другому - никак. Например, отображение проводки в личном кабинете. Это или CDC, или триггер на таблице. И там и там есть нюансы. Пример 2 - данные из транзакционных систем в MPP DB для решения оптимизационных задач - next best offer, подбор такси, "рекомендуем посмотреть", контекстная реклама и т.д.

Цитата:

Сообщение от mazzy

Да, я понял что ты хотел сказать про синхронизацию баз данных. я не считаю этот способ правильным ни для Аксапт, ни для других разнородных клиентов.

Для DAX - да, согласен и даже рассказал почему. Про "других разнородных клиентов" - я бы на был настолько категоричен, честно.

Цитата:

Сообщение от mazzy

инкремент за dDOS'ит системы нафиг. Для аксапты характерны таблицы, в которых поля обновляются часто. Какая-нибудь последняя себестоимость в карточках номенклатуры, например.

а насколько нужно ее часто реплицировать? Это и брокера убьет нафик. Плюс возможны будут варианты, когда изменение со старой себестоимостью придет позже сообщения с новой себестоимостью - не факт что брокер будет успевать доставить все по очереди(!) или приёмник - обрабатывать по очереди отправки. Значит, еще и версионность вводить и проверять. Оно точно надо?

С Уважением,
Георгий

[AlexMoskvichev]

Цитата:

Сообщение от mazzy

имею. поэтому и говорю о "каком-то брокере"

В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.

Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа.
При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке)

Возвращаясь к вопросу.
100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?.

Если проблема в размере сообщений, можно попробовать их сжать при отправке.

Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV
Или более современно, в parquet
Может оказаться вполне быстро и автоматизировать не сложно.
Через WCF можно управляющие команды подать, с метаданными файла

[mazzy]

Цитата:

Сообщение от AlexMoskvichev

В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.

Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа.
При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке)

угу.

Цитата:

Сообщение от AlexMoskvichev

Возвращаясь к вопросу.
100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?.

а почему по 1Мб?
я вроде написал "коллекция - список/массив/мап/контейнер/таблица"
В мире аксапты элементы коллекций это максимум размер страницы MS SQL = 8Кб
Очень-очень редко мемо поля до 4Гб. Но про это я бы обязательно сказал.

все-таки для мира аксапты хорошие допущения:
= размер элемента до 8кб
= размер буфера рабочего окна 64Кб (максимальный размер XML в WCF по умолчанию)
= размер коллекции более 100500 элементов

Цитата:

Сообщение от AlexMoskvichev

Если проблема в размере сообщений, можно попробовать их сжать при отправке.

нет, с размером элементов как раз никаких проблем.
вопрос про количество элементов, которое гарантировано не помещается в одно сообщение.

Цитата:

Сообщение от AlexMoskvichev

Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV
Или более современно, в parquet
Может оказаться вполне быстро и автоматизировать не сложно.
Через WCF можно управляющие команды подать, с метаданными файла

файла? какого файла? каким магическим образом вдруг файл передался?

[Vadik]

Цитата:

Сообщение от mazzy

но обрати внимание, что в вопросе было "передавать", а ты постоянно отвечаешь "запрашивать"
ты считаешь, что это одинаковые действия?

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

Цитата:

А как ты представляешь себе синхронизацию таблиц?

Я наверное не понял вопрос. Упрощенно - издатель публикует данные (все или инкремент), подписчик читает и овновляет свою локальную копию (в том виде, в котором он может с ней эффективно работать)

Цитата:

Что с RecId делать?

Снова не понял вопрос, потому ответ будет дурацкий - по классику, чаще мыть

Цитата:

Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир

Я всегда немного смущаюсь когда начинают сыпать названиями продуктов и аббревиатурами. Поэтому просто напомню что AIF в 2012 (за 2009 не скажу, не уверен) вполне себе умеет change tracking "из коробки" и отойду в сторонку, послушаю остальных

[George Nordic]

Цитата:

Сообщение от Vadik

Снова не понял вопрос, потому ответ будет дурацкий

Дело в том, что сторонние решения реплицируют таблицу или частично (часть полей), но тогда с системе B поле RecId будет пустое, или целиком, но тогда в системе B поле RecId будет такое же, как и в системе А, что некорректно.

Если можно использовать стандартный транспорт силами DAX, тот же AIF, который возьмет часть данных в А и выгрузить их в В, добавив и заполнив все обязательные системные поля, это круто. Есть такие способы?

С Уважеинием,
Георгий

[mazzy]

Цитата:

Сообщение от Vadik

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

А ты в этом смысле понимаешь слово передать.
Нет, я не имел в виду транспортный уровень.

Да, надо было использовать глагол "отправить"
вопрос звучал бы "как правильно отправить".

Я имел в виду, что Аксапта (как endpoint) инициирует процесс подготовки и отправки данных в другую Аксапту (другой endpoint). В WCF это означает Аксапта должна заполнить коллекцию с элементами и вызвать какой-нибудь осмысленный метод для этой коллекции.

для какого-нибудь другого брокера это будет нечто похожее.
Аксапта готовит данные в специальном формате и вызывает что-нибудь осмысленное для этих данных.

И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов.

вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint.

современный правильный ответ - использовать потоки.
но в Аксапте нет потоков.

какой способ отправить много элементов коллекции является правильным для Аксапты?

[S.Kuskov]

Цитата:

Сообщение от mazzy

Я имел в виду, что Аксапта (как endpoint) инициирует процесс подготовки и отправки данных в другую Аксапту (другой endpoint). В WCF это означает Аксапта должна заполнить коллекцию с элементами и вызвать какой-нибудь осмысленный метод для этой коллекции.

для какого-нибудь другого брокера это будет нечто похожее.
Аксапта готовит данные в специальном формате и вызывает что-нибудь осмысленное для этих данных.

И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов.

вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint.

современный правильный ответ - использовать потоки.
но в Аксапте нет потоков.

какой способ отправить много элементов коллекции является правильным для Аксапты?

Я может чего-то не понимаю, но если в самой Аксапте нет потоков, а все остальное устраивает, то нужно решить только два технических вопроса:
- Как из первой аксапты писать сообщения в исходящий поток WCF?
- Как во второй аксапте читать сообщения из входящего потока WCF?

Как эта задача решается на .net: https://weblogs.asp.net/cibrax/strea...rred-execution

Если непосредственно из аксапты нельзя это повторить, то наверняка можно сделать сборку-адаптер, который будет удобно использвать из аксапты.
Нет?

[mazzy]

Цитата:

Сообщение от S.Kuskov

...то нужно решить только два технических вопроса:

именно поэтому в вопросе нет слова поток (stream).
нет слова поток, чтобы не ограничивать возможные ответы.

есть ли еще какой-нибудь другой способ?

Цитата:

Сообщение от S.Kuskov

Если непосредственно из аксапты нельзя это повторить, то наверняка можно сделать сборку-адаптер, который будет удобно использвать из аксапты.
Нет?

наверняка можно.
почему вы считаете этот способ правильным?

===========
давайте я повторю вопрос в безнадежной попытке:

как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?

[Skvorcal]

Цитата:

Сообщение от mazzy

давайте я повторю вопрос в безнадежной попытке:

как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?

Напомнило анекдот...

Цитата:

Удар головой — штанга!
Еще удар головой — штанга!
Опять удар головой — снова штанга!!!....
Дайте ему наконец мяч или как-нибудь прекратите эту истерику!