PDF 创建服务器

Question

我的任务是创建（或寻找已经在工作的东西）一个具有 API 的集中式服务器，该 API 能够返回传递一些数据的 PDF 文件，以及模板的名称，它必须是强大的解决方案，企业就绪。目标如下：

• 针对不同公司事物的一系列模板。 （发票、订单、订单计划等）
• 一种从外部软件（网站、ERP 等）返回 PDF 的方法
• 可能是已经准备好的企业解决方案，但他们迫切需要定制解决方案。
• 可以是任何语言，但我们内部没有专门的 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# 路线，我们可以直接从 ERP 获取大约 70% 的数据，但无论如何，它应该接受带有一些数据（模板和该模板所需的数据，如发票数据或如果我们有权访问 ERP，则为发票 ID）。
• 输出应该是 PDF（对其他格式不感兴趣，只对 PDF 感兴趣）。
• 模板将仅由 IT 更新。 （主要是我们，开发团队）。
• 就性能而言，我不知道我们需要多少肌肉，但现在，没有任何增加，我们每天查看约 500/1000 个 PDF，主要在 10 到 10.30 和 12 到 13 小时打印。然后在一天剩下的时间里可能会增加 100 个。
• 当行星对齐并且是销售季节（一年两次）时，TOP 性能每天不应超过〜10000。这应该是我们未来几年的上限。

• 模板有一些要求：

  • 有重复的块（例如发票行）。
  • 将图像作为背景、水印和块。
  • 必须是多语言（可翻译，使用相同的数据）。
  • 有一些仅在条件下显示的块。
  • 依赖于页面的块（PDF 页眉/页眉/页脚/PDF 页脚）
  • 模板可能必须对一些数据进行计算，我认为我们永远不需要这个，但公司可能会要求这样做。李>

• PDF 不需要存储，因为我们有一个文档管理系统，也许将来我们可以链接它们。

额外数据：现在我们正在使用“Fast-Reports v2 VCL”

Answer 1

根据我多年使用PDF的经验，我认为您应该注意以下几点：

1. 性能：与 HTML 或 XML 到 PDF 的生成相比，基于 API 的 pdf 文件生成可能实现最快的性能（因为涉及到额外的转换层）。考虑到负载的峰值，您可能需要计算通过添加更多服务器来扩大生成规模的成本（并估计每天每个额外 pdf 文件所需的额外服务器或资源成本）。

2. 易于迭代和更改：您需要多久调整一次模板？如果您打算只创建一次模板（进行一些迭代）但不需要进行任何更改，那么您只需使用 API 对它们进行编码就可以了。否则，您应该强烈考虑将 HTML 或 XML 用于模板以简化更改并降低更改模板的复杂性；

3. 搜索和索引：如果您可能需要在创建的文档中运行搜索，那么您应该考虑存储生成的文档的索引，或者将更多的源数据存储在 XML 中以及生成的 PDF 文件中；
4. 长期保存：如果您希望对文档进行长期数字保存，最好遵循PDF/A 子格式。请参阅VeraPDF open source initiative，您可以使用它来验证生成的和传入的 PDF 文档是否符合 PDF/A 要求；
5. 保留源文件 PDF 格式本身并不是为编辑而设计的（尽管已经有一些 PDF 编辑器），因此您可能会考虑保留源数据以便以后能够重新生成 PDF 文档的需要，并且可能稍后介绍其他输出格式。

Answer 2

您的问题表明您在寻求帮助之前一直在详细考虑问题，所以我相信 SO 会很友好。

当然，您在描述中没有详细说明的一件事是更广泛的功能要求。您提到用锤子敲碎螺母，但我认为您主要关注技术/接口。如果您考虑到您对需要创建的文档的更广泛要求以及所涉及的变量，那么您认为这可能是一个更大的问题。

我建议的方法是对解决方案进行原型设计，前提是您有一些空间可以这样做。根据您的研究，选择最好的 3 个来尝试，其中很可能包括您心目中的自定义构建。让他们端到端地通过一些真实的用例 - 尽可能粗略但现实。您需要输出的一两个关键文档应在所有解决方案中使用。确保您在以下方面涵盖了最重要或最常见的要求：

1. 输入格式 - 谁可以/应该更新模板。什么是理想要求，什么是最低要求？ 输出要求 - 您要交付给谁以及哪些格式是必要的/理想的
2. 数据要求 - 您的数据来源是什么？以所需格式将数据从您的来源获取到报告系统的难易程度如何？
3. 模板功能 - 如果您使用模板，模板需要哪些功能？这包括输入格式，但我主要考虑的是引擎的功能，例如重复/条件内容、图像插入、表格操作等。即您的发票、订单和计划文件是简单还是复杂
4. API 要求 - 您是否有任何更广泛的 API 要求。您提到您使用 PHP，因此 PHP 库或 Web/Web 服务可能是一个很好的起点。
5. 性能 - 您没有提到任何性能特征，但如果您是大规模（企业）工作，那么即使粗略地测量吞吐量也是值得的。

iText 和 Jasper 无疑是您可以信赖的企业级引擎。您可能希望查看 Docmosis（请注意我为该公司工作）并可能搜索使用模板的 PDF 库。

Web 服务界面可能是您可能想要查看的关键功能。 REST API 很容易从 PHP 和几乎任何技术堆栈调用。这意味着您可能会选择如何构建解决方案，并且通常很容易对其进行原型设计。如果您决定走原型制作路径并尝试 Docmosis，请从云服务开始，因为您可以非常快速地进行原型制作/集成。

希望对你有帮助。