Сервер создания PDF-файлов

Мне было поручено создать (или найти что-то, что уже работает) централизованный сервер с API, который может возвращать файл PDF, передающий некоторые данные и имя шаблона, это должно быть надежное решение, предприятие готово. Цель следующая:

  • Серия шаблонов для разных вещей компании. (Счета, заказы, планы заказов и т. Д.)
  • Способ возврата PDF-файла из внешнего программного обеспечения (веб-сайтов, ERP и т. Д.)
  • Может быть уже готовое корпоративное решение, но они настаивают на нестандартном.
  • Может быть любым языком, но у нас нет собственных программистов на Java. Мы PHP / .NET, некоторые из нас балуются, но кривая обучения может быть немного крутой.

Итак, я читал. Один из способов, который, как мы думали, может быть возможным, - это установить сервер отчетов jasper и создать шаблоны в Jaspersoft Studio, а затем использовать API для возврата файлов PDF. Коллега поддерживает этот вариант, потому что в основном это делается, но 1º - это java, а 2º, я думаю, это все равно, что молотком расколоть орех.

Другой вариант, который мы использовали, - это использовать C # с iTextSharp для создания сервера и создать собственный API, который возвращает именно PDF-файл с необходимыми нам данными. При этом мы могли бы получить некоторые преимущества, например, использование уже созданного коннектора базы данных и извлечение большей части данных из базы данных, вместо того, чтобы передавать большой кусок данных, но поскольку он голый , на самом деле у него нет системы шаблонов. Мы могли бы создать что-то с помощью XMLWorker или классов C #, но это не совсем так просто, как перетаскивание. В этом случае я тоже читал про XFA, но документация на сайте iText вводит в заблуждение и непонятна.

Я также читал о некоторых других альтернативах, таких как PrinceXML, PDFBox, FOP и т. Д., Но концепция будет такая же, как у iText , нам придется сделать это самим.

Мой голос, даже если это больше работы, - это пойти по пути iText и использовать HTML / CSS для шаблонов, но мои коллеги утверждают, что шаблоны можно менять каждые две недели (я сомневаюсь, что это), и быть легким. HTML / CSS - это слишком много работы.

Итак, настоящий вопрос заключается в том, как к этому подходят другие компании? Я что-то упустил при поиске? Есть ли более простой способ добиться этого?

PS: Я не знал, будет ли SO подходящим местом для этого вопроса, но я в основном заблудился и рисковать «слишком широким вопросом» или тегом «не по теме» не кажется таким уж плохим.

ИЗМЕНИТЬ:

  • Вход должен быть отправлен с тем же запросом. Если мы выберем маршрут C #, мы сможем получить ~ 70% данных из ERP напрямую, но в любом случае он должен принять почтовый запрос с некоторыми данными (шаблоном и данными, необходимыми для этого шаблона, такими как данные счета-фактуры или идентификатор счета-фактуры, если у нас есть доступ к ERP).
  • На выходе должен быть PDF (не интересны другие форматы, только PDF).
  • Шаблоны будут обновляться только ИТ-специалистами. (В основном мы, команда разработчиков).
  • Что касается производительности, я не знаю, сколько мышц нам понадобится, но прямо сейчас, без какого-либо увеличения, мы ежедневно просматриваем ~ 500/1000 PDF-файлов, в основном печатаемых с 10 до 10:30 и с 12 до 13 часов. Затем, возможно, еще 100 человек до конца дня.
  • ТОП-производительность не должна превышать ~ 10000 в день, когда планеты выравниваются, и в сезон распродаж (два раза в год). Это должно быть нашим потолком на долгие годы.

  • К шаблонам предъявляются некоторые требования:

    • Have repeating blocks (invoice lines, for example).
    • Используйте изображения в качестве фона, водяных знаков и блоков.
    • Должен быть многоязычным (переводимым, с теми же данными).
    • Есть несколько блоков, которые отображаются только при условии.
    • Блоки, зависящие от страницы (верхний колонтитул PDF / верхний колонтитул страницы / нижний колонтитул страницы / нижний колонтитул PDF)
    • Шаблон возможно должен будет произвести вычисления над некоторыми данными, я не думаю, что нам это когда-нибудь понадобится, но в будущем компания может попросить об этом.

  • PDF-файлы не нужно хранить, так как у нас есть система управления документами, возможно, в будущем мы сможем связать их.

Дополнительные данные: сейчас мы используем "Fast-Reports v2 VCL"


server enterprise pdf c# pdf-generation
person TJSoler    schedule 21.03.2016    source источник
comment
документация на сайте iText вводит в заблуждение и непонятна - такое утверждение без ссылок не очень справедливо.   -  person mkl    schedule 29.03.2016
comment
Извините, я не объяснил себя, я не имел в виду, что документы непонятны, я отредактирую это, я имел в виду, что я вошел в developers.itextpdf.com и нашел только ссылку и примеры, а не документацию per se, я не могу реально оценить, соответствует ли продукт моим потребностям, это не легко понять XFA, возможности шаблонов, а также то, что есть, а что нет. Мне пришлось прочитать это с сайта itext. Я точно знаю, что это я и мои ожидания от документов.   -  person TJSoler    schedule 30.03.2016

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

  1. Формат (ы) ввода - кто может / должен обновлять шаблоны. Какое требование является идеальным и минимальным? Требования к выходным данным - кому вы доставляете сообщения и какие форматы необходимы / желательны
  2. Требования к данным - каковы ваши источники данных и насколько сложно / легко получить данные из ваших источников в систему отчетности в необходимом формате?
  3. Возможности шаблона - если вы используете шаблоны, какие функции им нужны? Это включает формат (ы) ввода, но я в основном думал о функциях движка, таких как повторяющееся / условное содержимое, вставка изображений, манипуляции с таблицами и т. Д., То есть ваши счета-фактуры, заказы и документы планирования простые или сложные
  4. Требования к API - есть ли у вас более широкие требования к API. Вы упомянули, что используете PHP, поэтому хорошей отправной точкой, вероятно, будет PHP-библиотека или веб-служба.
  5. Производительность - вы не упомянули какие-либо характеристики производительности, но, безусловно, если вы работаете в масштабе (на предприятии), стоит даже приблизительно измерить пропускную способность.

iText и Jasper, безусловно, являются движками корпоративного уровня, на которые вы можете положиться. Возможно, вы захотите взглянуть на Docmosis (обратите внимание, что я работаю в компании) и, возможно, поищите библиотеки PDF, в которых используются шаблоны.

Интерфейс веб-службы, возможно, является ключевой функцией, на которую вы, возможно, захотите обратить внимание. REST API легко вызвать из PHP и практически из любого технологического стека. Это означает, что у вас, скорее всего, будут варианты построения решения, и его обычно легко создать прототипом. Если вы решили пойти по пути прототипирования и попробовать Docmosis, начните с облачной службы, поскольку вы можете очень быстро создать прототип / интегрировать.

Надеюсь, это поможет.

person Paul Jowett    schedule 22.03.2016
comment
Спасибо! Я отредактирую вопрос, добавив еще несколько деталей, когда у меня будет немного времени, но сейчас, с устаревшим решением, которое мы используем прямо сейчас (быстрые отчеты 3, интегрированные в индивидуализированную erp), мы производим около 500 - 1000 pdf ежедневно, в основном в часы пик, но если мы централизовать все в этой системе, как и планировалось, в этом году должно печататься ~ 5000 ежедневно (~ 10000 в пиковые пару месяцев продаж) и расти с каждым годом. У нас всего ~ 10 шаблонов, но они довольно сложные (повторяющиеся / условные / многослойные / изображения / ...), и шаблоны будут редактироваться нами (командой разработчиков). - person TJSoler; 22.03.2016

arrow_upward
0
arrow_downward

Исходя из своего многолетнего опыта работы с PDF, я считаю, что вам следует обратить внимание на следующие моменты:

  1. Производительность: вы можете добиться максимальной производительности с помощью создания файлов PDF на основе API по сравнению с созданием HTML или XML в PDF (из-за задействованного дополнительного уровня преобразования). Принимая во внимание пики нагрузки, вы можете рассчитать стоимость масштабирования генерации путем добавления дополнительных серверов (и оценить стоимость дополнительных серверов или ресурсов, необходимых для каждого дополнительного файла PDF в день).

  2. Простота итераций и изменений: как часто вам нужно будет корректировать шаблоны? Если вы собираетесь создавать шаблоны только один раз (с некоторыми итерациями), но при этом никаких изменений не требуется, тогда все будет в порядке, просто закодировав их с помощью API. В противном случае вам следует настоятельно рассмотреть возможность использования HTML или XML для шаблонов, чтобы упростить изменения и уменьшить сложность внесения изменений в шаблоны;

  3. Поиск и индексирование: если вам может потребоваться выполнить поиск среди созданных документов, вам следует подумать о сохранении индексов сгенерированных документов или, возможно, сохранить больше исходных данных в XML вместе с созданным файлом PDF;
  4. Длительное сохранение: лучше соответствовать PDF / A подформат на случай, если вы хотите сохранить свои документы в цифровом виде в течение длительного времени. См. инициативу VeraPDF с открытым исходным кодом, которую вы можете использовать для проверки сгенерированных и входящих документов PDF на соответствие требованиям PDF / A;
  5. Сохранение исходных файлов. Сам формат PDF не предназначен для редактирования (хотя уже есть некоторые редакторы PDF), поэтому вы можете рассмотреть необходимость сохранения исходных данных, чтобы иметь возможность повторно создавать документы PDF позже и, возможно, Позже будут представлены дополнительные форматы вывода.
person Eugene    schedule 23.03.2016