Привет.

Наша компания уже несколько лет разрабатывает CRM-систему (C#, .Net 2.0, MS SQL 2000).
Заказчик – зарубежная компания, которая потом нашу программу ставит клиентам и саппортит. Т.е. у нас только разработка. Обновление версий программы происходит вручную – т.е. саппорт заказчика обходит клиентов и ставит на каждый комп новую версию + обновляет их БД. У разных клиентов могут стоять разные версии программы. Часто клиенты хотят, чтоб у них формировались какие-то новые репорты. – это наиболее частая причина выхода новой версии.
Заказчик хочет иметь возможность динамически добавлять клиентам разработанные репорты без обновления версии программы.
Видит он это так:
— мы разрабатываем новую форму для репорта.
— исходный код заказчик заливает в БД соответствующему клиенту. Т.к. заказчик саппортит их БД, то он может это сделать дистанционно.
— наша программа, обнаружив в БД новый репорт, компилирует/загружает/работает с ним.

Мне не очень-то нравится такой вариант. Как это реализовать по другому?
Возможно кто-то решал подобные задачи. Поделитесь опытом или идеями по этому поводу.
Заранее всем большое спасибо.

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

А>Мне не очень-то нравится такой вариант. Как это реализовать по другому?

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

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

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

Посмотрите активную в данный момент тему Формирование отчётов

Автор: and_hom
Дата: 11.07.07

— описывал один из вариантов. При использовании XSL-FO новый вид отчета — это текстовый XML-файл, то есть чтобы добавить новый вид отчета не нужно пересобирать или дописывать код, а обновить на клиенте текстовый файл, думаю, не составит проблем... через ту же БД, или через Интернет. По ссылке все касаемо Java, но это непринципиально: в первом номере RSDN Magazine за этот год, кажется, была статья, описывающая использования nFOP (.NET-компиляция Apache FOP) в C#. Гм... Правда, скорее всего, данный вариант вам будет неприемлем, ведь придется переписать всю подсистему отчетов.

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

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

Так и предполагается: сам репорт описывается на спец. языке, но, как правило, для формирования такого репорта клиентом ему нужна будет формочка, в кот. он может ввести/выбрать параметры репорта. Заказчик хочет, чтоб эта форма (логически привязанная к репорту) так же создавалась с репортом...
надо как-то хранить ещё и форму....

TK>- Можно сделать репорт опциональной компонентой приложения и устанавливать их параллельно уже существующему приложению (например, как add-in)

Заказчик саппортит только БД у клиентов. Закидывать dll нового add-in в БД?

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

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

R>Посмотрите активную в данный момент тему Формирование отчётов

Автор: and_hom
Дата: 11.07.07

— описывал один из вариантов. При использовании XSL-FO новый вид отчета — это текстовый XML-файл, то есть чтобы добавить новый вид отчета не нужно пересобирать или дописывать код, а обновить на клиенте текстовый файл, думаю, не составит проблем... через ту же БД, или через Интернет. По ссылке все касаемо Java, но это непринципиально: в первом номере RSDN Magazine за этот год, кажется, была статья, описывающая использования nFOP (.NET-компиляция Apache FOP) в C#. Гм... Правда, скорее всего, данный вариант вам будет неприемлем, ведь придется переписать всю подсистему отчетов.

Репорт описывается на спец. скриптовом языке (библиотека третьих разработчиков), но, как правило, для формирования такого репорта клиентом ему нужна будет формочка, в кот. он может ввести/выбрать параметры репорта. Заказчик хочет, чтоб эта форма (логически привязанная к репорту) так же создавалась с репортом... — этого библиотека репортов не умеет.

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

А>Так и предполагается: сам репорт описывается на спец. языке, но, как правило, для формирования такого репорта клиентом ему нужна будет формочка, в кот. он может ввести/выбрать параметры репорта. Заказчик хочет, чтоб эта форма (логически привязанная к репорту) так же создавалась с репортом...
А>надо как-то хранить ещё и форму....

Форму тоже можно описывать аналогичным образом. Либо, сразу клать в БД сборку с нужной функциональностью... раз, доступа к локальным машинам все равно нет.

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

TK>Форму тоже можно описывать аналогичным образом. Либо, сразу клать в БД сборку с нужной функциональностью... раз, доступа к локальным машинам все равно нет.

Как считаете, что лучше класть в БД новую сборку, или исходный код — как это предложил заказчик?

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

TK>>Форму тоже можно описывать аналогичным образом. Либо, сразу клать в БД сборку с нужной функциональностью... раз, доступа к локальным машинам все равно нет.

А>Как считаете, что лучше класть в БД новую сборку, или исходный код — как это предложил заказчик?

Я бы положил в БД сборку — ее ненадо компилировать (меньше потенциальных проблем) и меньше вероятность, что кому-то захочется этот код "подправить"

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

А формализовать форму ввода параметров для отчета и описывать ее, к примеру, тем же XML-ем нельзя?

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

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

TK>>>Форму тоже можно описывать аналогичным образом. Либо, сразу клать в БД сборку с нужной функциональностью... раз, доступа к локальным машинам все равно нет.

А>>Как считаете, что лучше класть в БД новую сборку, или исходный код — как это предложил заказчик?

TK>Я бы положил в БД сборку — ее ненадо компилировать (меньше потенциальных проблем) и меньше вероятность, что кому-то захочется этот код "подправить"

у обоих подходов свои +/-:

Сборка в БД:
+ ненадо компилировать (меньше потенциальных проблем)
+/- заказчик иногда лазит в код своими кривыми ручками. Но корректно изменить, напр., текст лейбы он в состоянии.
— используются некоторые библиотеки компонентов, — если надо сделать несколько таких сборок с разными версиями этих библиотек, то на машине девелопера прийдётся эти библиотеки переставлять, чтоб сделать нужные билды.

Исходники в БД:
см. пред. пункт и инвертируй +/-

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

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

R>А формализовать форму ввода параметров для отчета и описывать ее, к примеру, тем же XML-ем нельзя?

К сожалению нет. Формы могут быть абсолютно разными....

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

А>Репорт описывается на спец. скриптовом языке (библиотека третьих разработчиков), но, как правило, для формирования такого репорта клиентом ему нужна будет формочка, в кот. он может ввести/выбрать параметры репорта. Заказчик хочет, чтоб эта форма (логически привязанная к репорту) так же создавалась с репортом... — этого библиотека репортов не умеет.
хм.. а не смотрели в сторону Microsoft Reporting Services ?
там репорты можно клепать в студии в репорт дизайнере
деплоить можно прямо от туда же или с использованием коммандлайн тулзы
все репорты централизованы на сервере отчетов
из своей программы неважно ASP.NET или Winforms можно просматривать отчеты
при помощи нативной компоненты от микрософта.
для формы в дизайнере можно определять параметры отчета
вводимые пользователем (поля ввода / поля со списками с возможностью выбора как только одного варианта из списка так и с возможностью выбора подмножества вариантов())

Использовал, не так давно, все это достаточно интенсивно и пользователей волне устраивало.
Да, вот еще что, можно сформированные пользователем конечные отчеты экспортить в pdf/excel/xml.

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

А>К сожалению нет. Формы могут быть абсолютно разными....
Я говорил не о формализации внешнего вида форм, а о формализации передаваемых в отчет параметров — это формализовать, по-моему, всегда можно. А по поводу внешнего вида самих форм, смотрите, сколько всего есть: Open Source XML UI Toolkits in Java — думаю, для .NET тоже найдется.

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

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

А>>Репорт описывается на спец. скриптовом языке (библиотека третьих разработчиков), но, как правило, для формирования такого репорта клиентом ему нужна будет формочка, в кот. он может ввести/выбрать параметры репорта. Заказчик хочет, чтоб эта форма (логически привязанная к репорту) так же создавалась с репортом... — этого библиотека репортов не умеет.
J>хм.. а не смотрели в сторону Microsoft Reporting Services ?
J>там репорты можно клепать в студии в репорт дизайнере
J>деплоить можно прямо от туда же или с использованием коммандлайн тулзы
J>все репорты централизованы на сервере отчетов
J>из своей программы неважно ASP.NET или Winforms можно просматривать отчеты
J>при помощи нативной компоненты от микрософта.
J>для формы в дизайнере можно определять параметры отчета
J>вводимые пользователем (поля ввода / поля со списками с возможностью выбора как только одного варианта из списка так и с возможностью выбора подмножества вариантов())

J>Использовал, не так давно, все это достаточно интенсивно и пользователей волне устраивало.
J>Да, вот еще что, можно сформированные пользователем конечные отчеты экспортить в pdf/excel/xml.


Нет. В сторону SSRS не смотрели. — для формирования репортов изначально и уже давно используется библиотека третьих разработчиков. Переходить на SSRS просто нет времени.

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

А>+/- заказчик иногда лазит в код своими кривыми ручками. Но корректно изменить, напр., текст лейбы он в состоянии.
1. Если бы задачу формировал я, то требование к простоте внесения изменений в отчеты для конкретного заказчика я бы обозначил с наиболее высоким приоритетом. Постарайтесь выяснить приоритетность требований.
2. Что касается отчетов (со скриптами) это хорошо. Насколько я понял, проблем с самими отчетами оно не создает.
3. Что касается форм — то возможно вам поможет XAML. Собственно он для этого и предназначен. У него есть хостинги.здесь

А>Нет. В сторону SSRS не смотрели. — для формирования репортов изначально и уже давно используется библиотека третьих разработчиков. Переходить на SSRS просто нет времени.

Посмотрели. SSRS не подходит по ряду причин, которые объяснять не буду.

ПЫСЫ: я не топикстартер. МЫ просто сидим рядом.

Сам делал такое, правда на Delphi/FastReport/FIBPlus/Firebird, но задача была более комплексная
— обновление программы
— обновление данных
— обновление дополнительных фильтров и отчетов

Обновление программы осуществлялось бинарными дельтами (рекомендую xdelta3)
Обновление данных шло дополнительным файлом БД
Отчеты и фильтры были кастомными, т.е. пользователь их мог править и делать самостоятельно, встроенные построены на том же механизме, лежали в базе ...
Ну и плюс механизм версий, т.е. на сайте лежат все обновления и файл с версиями. Клиент читает этот файл и определяет какие обновления ему нужно установить. Обновление данных происходит практически каждый день, программных файлов, отчетов и фильтров гораздо реже.

Все прекрасно работает. Чего и всем остальным желаю

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

N>Сам делал такое, правда на Delphi/FastReport/FIBPlus/Firebird, но задача была более комплексная
N>- обновление программы
N>- обновление данных
N>- обновление дополнительных фильтров и отчетов

N>Обновление программы осуществлялось бинарными дельтами (рекомендую xdelta3)
N>Обновление данных шло дополнительным файлом БД
N>Отчеты и фильтры были кастомными, т.е. пользователь их мог править и делать самостоятельно, встроенные построены на том же механизме, лежали в базе ...
N>Ну и плюс механизм версий, т.е. на сайте лежат все обновления и файл с версиями. Клиент читает этот файл и определяет какие обновления ему нужно установить. Обновление данных происходит практически каждый день, программных файлов, отчетов и фильтров гораздо реже.

N>Все прекрасно работает. Чего и всем остальным желаю

Спасибо. Точно так делать не будем, но это натолкнуло на идею.

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

А>Мне не очень-то нравится такой вариант. Как это реализовать по другому?
А>Возможно кто-то решал подобные задачи. Поделитесь опытом или идеями по этому поводу.
А>Заранее всем большое спасибо.
ставим заказчику MS SQL Server Reporting Services.
регулярно поставляем ему новые файлы описания отчетов. волосы становятся мягкими и шелковистыми.

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

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

А>>Мне не очень-то нравится такой вариант. Как это реализовать по другому?
А>>Возможно кто-то решал подобные задачи. Поделитесь опытом или идеями по этому поводу.
А>>Заранее всем большое спасибо.
S>ставим заказчику MS SQL Server Reporting Services.
S>регулярно поставляем ему новые файлы описания отчетов. волосы становятся мягкими и шелковистыми.

А если софт соИт у 50-100 клиентов и они не хотят стаить себе никаких серверов, сервисов или чего-либо другого? Вот такие у нас пироги.