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

[mazzy]

Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

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

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

как передать эти данные в другую Аксапту (назовем ее сервером) через WCF?

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

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

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

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

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

ЗЫ
а может где-нибудь еще есть такое? не только в WCF...

[Vadik]

https://docs.microsoft.com/en-us/dyn...-query-service

[mazzy]

Цитата:

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

https://docs.microsoft.com/en-us/dyn...-query-service

спасибо.
только это и есть разбивать на чанки, насколько я понимаю. только в особо извращенной форме.

во-первых, этот сервис только для запросов к базе.

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

в-третьих, query service только слушатель (т.е. кто-то может запросить query service, а query service этому кому-то может вернуть данные в ответ).
если же нужно передать данные другому, то нужно как-то организовать callback. что то еще удовольствие.

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

[Damn]

Похоже что это вопрос больше для форума разработчиков WCF-сервисов.
Или для stackoverflow, например.

[macklakov]

Цитата:

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

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

Я бы не ограничивался конкретной технологией. В зависимости от конкретных требований, можно подобрать более подходящие инструменты.
С какой периодичностью нужно данные передавать? Вызовы синхронные? Насколько универсальным и масштабируемым должно быть решение? Используется ли middleware? Кто будет публиковать данные и кто будет подписчиками?

[AlexMoskvichev]

Цитата:

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

разрвет все внутренние буфера.
...
возиться и тоже никакой гарантии, что не разорвет...

"Внутренние буфера" конфигурируются https://stackoverflow.com/questions/...ize-quota?rq=1

Можно разной толщины сообщения послать и точно узнать, разорвет или нет. Если сервер свой, то и с настройками поиграться.
По умолчанию вроде 64Кб лимит на сообщение.

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

Цитата:

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

Это похоже на описание какого-то балансировщика нагрузки. Вряд-ли такое будет в голом фреймворке.

Для очень больших объемов есть стриминг https://docs.microsoft.com/ru-ru/dot...-and-streaming
Стриминг как раз автоматически делит данные на куски, но подойдет ли он в конкретном клиенте?

Просто непонятно о чем точно идет речь. Если WCF указан как фреймворк, а не конкретный продукт, тогда можно широко подойти. Или это про AIF?

[mazzy]

Цитата:

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

С какой периодичностью нужно данные передавать? Вызовы синхронные? Насколько универсальным и масштабируемым должно быть решение? Используется ли middleware? Кто будет публиковать данные и кто будет подписчиками?

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

а как влияет на ответ кто будет подписчиком?

Цитата:

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

По умолчанию вроде 64Кб лимит на сообщение.

причем 64Кб несжатого xml. что очень немного.

Цитата:

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

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

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

Цитата:

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

Для очень больших объемов есть стриминг https://docs.microsoft.com/ru-ru/dot...-and-streaming
...
Просто непонятно о чем точно идет речь. Если WCF указан как фреймворк, а не конкретный продукт, тогда можно широко подойти. Или это про AIF?

AIF. net.TCP адаптер
но хотелось бы понять как это влияет на ответ. можем и свой middleware сделать

[macklakov]

Цитата:

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

Но хотелось бы понять как middleware влияет на ответ.

а как влияет на ответ кто будет подписчиком?

Да на всё влияет. Подписчик может иметь очень ограниченные возможности по интеграции. А хорошее middleware имеет все вообразимые коннекторы, а обычно и преднастроенные шаблоны интеграции. Плюс управление очередью сообщений. Но если прямое соединение, то приходится анализировать, какая система на что способна.
Если интеграция ассинхронная, а издатель и подписчик сидят в одной сети, то вообще можно данные выставить как view и пусть таскает когда и сколько ему нужно. Можно вытягивать данные в DW, поближе к подписчику.
Если синхронная, то к предыдущий варант сопровождается сообщением:"данные брать здесь"
Обмен данными можно наладить десятками разных способов. Все зависит от конкретики.
P.S. Универсальное решение писать дело увлекательное, но неблагодарное. Много я их видел, одни лучше, другие хуже. Но выкупаются те, которые созданы школьными друзьями.

[mazzy]

Цитата:

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

Да на всё влияет. Подписчик может иметь очень ограниченные возможности по интеграции. А хорошее middleware имеет все вообразимые коннекторы, а обычно и преднастроенные шаблоны интеграции.

конечные точки - ax2012 и ax2009
предположим, что все под нашим контролем.

Цитата:

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

Плюс управление очередью сообщений.

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

Цитата:

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

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

ax2012 и ax2009. в одном домене.
middlware любой. для начала пустой набор. можно добавлять что угодно.

как правильно?

Цитата:

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

можно данные выставить как view и пусть таскает когда и сколько ему нужно.

вопрос рассматривался.
в аксапте view скорее для чтения. и уж точно НЕ для удаления.

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

точно так же как и в QueryService, которые Vadik предлагал выше.

можно я повторю:

Цитата:

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

Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

Цитата:

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

Можно вытягивать данные в DW, поближе к подписчику.

а зачем?

Цитата:

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

Обмен данными можно наладить десятками разных способов. Все зависит от конкретики.

Всё?! Это обсуждение "как правильно" зависит от конкретики?!
Серьезно?!

Ну, дай вводную "я говорю о таких условиях" и расскажи как правильно в этих условиях.
собственно тема об этом.

Цитата:

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

P.S. Универсальное решение писать дело увлекательное, но неблагодарное. Много я их видел, одни лучше, другие хуже. Но выкупаются те, которые созданы школьными друзьями.

Не спорю.
Могу только повторить свое первое утверждение в моем первом сообщении в этой ветке:

Цитата:

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

Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

[George Nordic]

А не подойдет ли для этой задачи очередь сообщений (RabbitMQ или даже Debezium) + пакетная обработка?
1 мастер система или 2? Т.е. если справочники вбиваются в систему 1, и они должны точно отображаться в системе 2 - это один вариант. Если и в системе 1, и в системе 2 ведутся справочники, которые должны быть синхронизированы, включая контроль совпадений - это уже другой вариант, посложнее.

Просто Change Data Capture не подойдет, так как разные системы и разные RecID. Тогда просто кроликом гоняем изменения во временную таблицу. А раз в час или в 5 минут запускаем пакет, в котором делаем импорт средствами системы и удаляем (помечаем) обработанную запись. Надо предусмотреть не только добавление, но и изменение / удаление данные, что тоже возможно посредством передачи пакетов.

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

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

[mazzy]

Цитата:

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

А не подойдет ли для этой задачи очередь сообщений (RabbitMQ или даже Debezium) + пакетная обработка?

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

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

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

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

[George Nordic]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[Vadik]

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

[George Nordic]

Цитата:

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

синхронизовывать изменения и работать с ней в обеих системах локально ?

Вадим, привет! А как ты представляешь себе синхронизацию таблиц? Что с RecId делать? Я потому и предложил через таблицу, и потом пакетной, чтобы она уже добавила все потроха которые будут уникальны для разной инсталляции. Более того, если это разные системы, как указано в исходном сообщении, то и сама структура таблиц может различаться.

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

[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 необходимо будет делать силами интегрируемой системы, такой как Аксапта. Я знаю про пакетную обработку, возможно, если и другие пути добавления необходимой служебной информации, но я про них не наслышан.

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

[AlexMoskvichev]

Цитата:

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

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

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

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

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

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

Или вообще,
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]

Цитата:

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

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

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

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

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