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

[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

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

[Vadik]

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

[George Nordic]

Цитата:

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

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

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

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