Добрый Всем День!

Вот уже какой день мучаюсь с вопросом: "Где лучше создавать репорты: на серваке или на клиенте?"

Имеем: Корпоративная сеть с удаленными отделами, работающими через web-браузер
Сервер IIS, MSSQL, VBnet

На документах есть рабочие бар-коды. Количество страниц в документе может исчисляться сотнями, в некоторых — более тысячи.

Варианты решения:

1) готовить документы в pdf на серваке, передавать чз http (уверенность в том, что доки будут везде(!) работать)
2) готовить док на клиенте html из json с сервера (смущает обилие страниц, не возможность сделать просто по шаблону, интересует браузерная зависимость.)
3) готовить док на клиенте pdf из json с сервера (знаю только java pludig "джедай-путь" в этом случае, не работал так никогда, не знаю, может и хорошо)

Если готовить на серваке, по получ прим по 10-20мб.
Объем json не мерил.

Сам склоняюсь к pdf на серваке


Что скажете, Бояре ?

Заранее Спасибо, Илья

P>Сам склоняюсь к pdf на серваке

при таких объёмах я бы броузер-сайд вообще не рассматривал

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

A>при таких объёмах я бы броузер-сайд вообще не рассматривал

Что имеется ввиду ? Вообще как браузер-решение , или то, что точно на серваке нужно все это делать ?

Здравствуйте, Аноним, Вы писали:

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

A>>при таких объёмах я бы броузер-сайд вообще не рассматривал

А>, что точно на серваке нужно все это делать ?

да

A>да


Почему, объясните плз. Есть какие-то аргументы кроме размера?

В моем понимании для объективного сравнения нужно сделать а-ля два приложения (как минимум) и на одном просто скачать (хотя бы) подготовленный pdf файл, в другом притащить все данные по jsonу и сделать на них хоть какой-нибудь но корявенький html. Затем сравнить что получается во времени. Но ведь это ж надо делать...

Кроме того, есть мнение, что генерация pdf на серваке дело затратное.. Затратное ли оно будет на клиенте ?


Также есть вопрос по архитектуре: отдельный репорт сервис должен быть или хватит встроенного в приложение?
Нужно ли прикручивать в таком случае reporting serive? Если "хорошо бы", то как ? Он (репорт-сервис) должен быть (пока в моем представлении) реализован как отдельная web-служба?
Т.е. грубо говоря, папка основного веб приложения и папка репорт-службы отличается. Кроме того, разные веб-приложения могут ссылаться на репорт-сервис, и он, в зависимости от прав пользователя, взятого из сессии осн приложения, может поставлять тот или иной отчет.

пс: с reporting serive никогда не работал

Спасибо

А>В моем понимании для объективного сравнения нужно сделать а-ля два приложения (как минимум) и на одном просто скачать (хотя бы) подготовленный pdf файл, в другом притащить все данные по jsonу и сделать на них хоть какой-нибудь но корявенький html. Затем сравнить что получается во времени. Но ведь это ж надо делать...

Броузер колом встанет на таких объёмах, юзеры начнут теребить рефреш, что ни прибавит производительности ни на клиенте ни на сервере.

Я в 2010 (или 2011, не помню) делал статический хтмл с таблицей на 500т ячеек (по ~40 в строке) — ни один броузер на тот момент этот хтмл открыть не смог. Прошло, конечно, не мало лет, но я не думаю, что броузеры кардинально улучшили для работы с такими объёмами.

А>Кроме того, есть мнение, что генерация pdf на серваке дело затратное.. Затратное ли оно будет на клиенте ?

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

А>Также есть вопрос по архитектуре: отдельный репорт сервис должен быть или хватит встроенного в приложение?

Если он отчёты будет потоково делать (== не строить всю можель в памяти), то можно и встроить. А если целиком — лучше отдельно, чтобы рестартовать не жалко было.

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

A>Если он отчёты будет потоково делать (== не строить всю можель в памяти), то можно и встроить. А если целиком — лучше отдельно, чтобы рестартовать не жалко было.

потоково — это имеется ввиду отдавать сразу в http-поток? Как это делается ? Есть примеры?


Вот еще вопрос: Sql Server Reporting Server может упростить мне жизнь в этом вопросе?

Здравствуйте, Аноним, Вы писали:

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

A>>Если он отчёты будет потоково делать (== не строить всю можель в памяти), то можно и встроить. А если целиком — лучше отдельно, чтобы рестартовать не жалко было.

А>потоково — это имеется ввиду отдавать сразу в http-поток? Как это делается ? Есть примеры?


А>Вот еще вопрос: Sql Server Reporting Server может упростить мне жизнь в этом вопросе?

Здравствуйте, Аноним, Вы писали:

А>потоково — это имеется ввиду отдавать сразу в http-поток? Как это делается ? Есть примеры?

Это типа рендерить сразу в ResponseStream чтоли ?

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

P>Здравствуйте, Аноним, Вы писали:

А>>потоково — это имеется ввиду отдавать сразу в http-поток? Как это делается ? Есть примеры?

P>Это типа рендерить сразу в ResponseStream чтоли ?

Сразу в респонс стрим — хрупко. Я бы сначала в файл стрим (чтобы память поберечь), а как будет готово — отдать клиенту.

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

А>Вот еще вопрос: Sql Server Reporting Server может упростить мне жизнь в этом вопросе?

Опыта не имею с ним, но, полагаю, что упростить должен.

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

A>Сразу в респонс стрим — хрупко. Я бы сначала в файл стрим (чтобы память поберечь), а как будет готово — отдать клиенту.
вот и мне кажется "хрупко". Но стрим — тоже весит..., потому и спросил

Как вариант думал еще давать задание на генерацию в отдельном, не привязанном к request потоке(thread, no stream!), а затем по готовности дать на скачку. Но это ибо гиммор, как мне кажется.
Лучше бы с отдельной службой вопрос решить. Вот только что с аутификацией что делать?..

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

A>Опыта не имею с ним, но, полагаю, что упростить должен.
Я так понял, Вы обошлись без служб. Так ?

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

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

A>>Сразу в респонс стрим — хрупко. Я бы сначала в файл стрим (чтобы память поберечь), а как будет готово — отдать клиенту.
P>вот и мне кажется "хрупко". Но стрим — тоже весит..., потому и спросил

Файл стрим, считай, ничего не весит, по сравнению с генерацией в памяти.

P>Как вариант думал еще давать задание на генерацию в отдельном, не привязанном к request потоке(thread, no stream!), а затем по готовности дать на скачку. Но это ибо гиммор, как мне кажется.

Одно другому не мешает, и отдельный thread — хорошая идея, если отчет генерируется 30+ сек

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

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

A>>Опыта не имею с ним, но, полагаю, что упростить должен.
P>Я так понял, Вы обошлись без служб. Так ?

Я только JFreeReport и JasperReports использовал, (и CrystalReports — но очень давно).

Эти 2 — просто библиотеки, если предполагаются большие отчеты в памяти строить, то лучше вынести в отдельное приложение (назови как хочешь), чтобы возможные падения не мешали основному сервису. Если в потоковом режиме (и для входа и для выхода), то много проще их инпроцесс иметь.

Про МС СКЛ репортинг сервис лучше спросить на форему Базы данных

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

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

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

A>>>Опыта не имею с ним, но, полагаю, что упростить должен.
P>>Я так понял, Вы обошлись без служб. Так ?

A>Я только JFreeReport и JasperReports использовал, (и CrystalReports — но очень давно).

A>Эти 2 — просто библиотеки, если предполагаются большие отчеты в памяти строить, то лучше вынести в отдельное приложение (назови как хочешь), чтобы возможные падения не мешали основному сервису. Если в потоковом режиме (и для входа и для выхода), то много проще их инпроцесс иметь.

A>Про МС СКЛ репортинг сервис лучше спросить на форему Базы данных

Спасибо, Верои сенкс

P>Варианты решения:

P>2) готовить док на клиенте html из json с сервера (смущает обилие страниц, не возможность сделать просто по шаблону, интересует браузерная зависимость.)

проще всего html в pdf конвертить через phantomjs — это webkit браузер который работает как сервис через консоль, там можно еще и png,jpg экранные скрины делать...