PDF創建服務器

Question

我的任務是創建一個集中的服務器（或者尋求一些已經工作的），這個服務器具有能夠返回傳遞一些數據的PDF文件的API以及模板名稱成爲一個強大的解決方案，企業就緒。目標如下：

• 一系列用於不同公司事物的模板。 （發票，訂單，訂單計劃等）
• 從外部軟件（網站，ERP等）返回PDF的方法
• 可以是已經準備好的企業解決方案，但他們正在按自定義的一個。
• 可以是任何語言，但我們沒有任何專用的Java程序員。我們是PHP/.NET，我們中的一些人涉足，但學習曲線可能有點陡峭。

所以，我一直在閱讀。我們認爲可能的一種方式是安裝jasper reports服務器，並在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是否是這個問題的正確位置，但我主要是迷路了，冒着「太廣泛的問題」或「脫離主題」標籤冒險似乎並不是那麼糟糕。

EDIT：

• 輸入應具有相同的請求被髮送。如果我們決定C＃路線，我們可以直接從ERP獲得約70％的數據，但無論如何，它應該接受帶有一些數據（模板和該模板所需的模板和數據，如發票數據或發票ID，如果我們有權訪問ERP）。
• 輸出應該是PDF（對其他格式不感興趣，只是PDF）。
• 模板將被更新只有由IT。 （主要是我們，開發團隊）。性能方面，我不知道我們需要多少肌肉，但是現在，沒有任何增加，我們每天約看500/1000份PDF，大多數是從10到10.30和12到13小時打印的。那麼今天剩下的時間可能會多達100次。
• 當行星對齊時，TOP性能不應該超過每天10000個，並且是銷售季節（每年兩次）。這應該是我們今後幾年的最高限額。

• 模板有一些要求：

  • 有無重複塊（發票行，例如）。
  • 將圖像作爲背景，作爲水印和塊。
  • 必須是多語言（可翻譯，具有相同的數據）。
  • 有一些只顯示條件的塊。
  • 塊取決於在頁面上（PDF頁眉/頁的頁眉/頁腳/ PDF頁腳）
  • 模板將也許有過一些數據做計算，我不認爲我們會永遠需要這個，但公司可能會提出這個問題。

• PDF不需要存儲，因爲我們有一個文檔管理系統，也許將來我們可以鏈接它們。

額外的數據：現在我們使用的是「快速報告V2 VCL」

Answer 1

你的問題表明你尋求幫助，所以我之前一直在考慮具體問題確定SO會很友善。

當然你在描述中沒有詳細描述的一件事是更廣泛的功能需求。你提到用錘子打破螺母，但我認爲你主要關注技術/接口。如果您考慮對需要創建的文檔的更廣泛的要求，涉及的變量，它可能是您認爲的更大的問題。

我建議的方法是建立原型解決方案，假設您有一定的空間可以這樣做。從你的研究中，選擇最好的3來嘗試，其中可能包括你想到的自定義構建。讓他們通過一些真實的使用案例，從頭到尾 - 儘可能的粗糙但現實。應該在所有解決方案中使用一到兩個需要輸出的關鍵文檔。確保你覆蓋了最重要或最常見的要求：

1. 輸入格式 - 誰可以/應該更新模板。什麼是理想的要求和最低要求是什麼？ 輸出要求 - 您要交付給誰以及哪些格式是必需/可取的
2. 數據要求 - 您的數據來源是什麼以及從數據源獲取數據到報告的難易程度系統需要的格式？
3. 模板功能 - 如果您使用的是模板，模板需要哪些功能？這包括輸入格式，但我主要考慮引擎的功能，如重複/條件內容，圖像插入，表格操作等。即您的發票，訂單和計劃文檔是簡單還是複雜的
4. API要求 - 您是否有更廣泛的API要求。您提到您使用PHP，因此PHP庫或Web/Web Service可能是一個很好的起點。
5. 性能 - 您尚未提及任何性能特徵，但當然，如果您在規模（企業級）工作，則值得對吞吐量進行粗略測量。

iText和Jasper肯定是您可以信賴的企業級引擎。您可能希望看看Docmosis（請注意我爲公司工作），並且可能會對使用模板的PDF庫進行一些搜索。

Web服務接口可能是您可能想要查看的關鍵功能。 REST API很容易從PHP和幾乎任何技術堆棧調用。這意味着您可能會有關於如何構建解決方案的選項，並且通常很容易針對其進行原型設計。如果您決定走下原型路徑並嘗試Docmosis，那麼從雲服務開始，因爲您可以非常快速地進行原型/集成。

我希望有幫助。

Answer 2

從我多年的經驗與PDF的工作，我認爲你應該注意以下幾點：

1. 性能：你可以做基於API的PDF文件生成的對比最快的性能到HTML或XML到PDF的生成（因爲涉及一個額外的轉換層）。考慮到負載峯值，您可能需要通過添加更多服務器來計算擴展生成的成本（並估算每天額外的pdf文件所需的額外服務器或資源的成本）。

2. 易於迭代和更改：您需要多久調整一次模板？如果你打算只創建一次模板（有一些迭代），但不需要做任何更改，那麼只需使用API​​對它們進行編碼即可。否則，您應該強烈考慮使用HTML或XML模板來簡化更改並降低模板更改的複雜性;

3. 搜索和索引：如果您可能需要在創建的文檔之間運行搜索，那麼您應該考慮存儲生成的文檔的索引，或者可能將源數據存儲在XML中以及生成的PDF文件;
4. 長時間保存：您應該更好地符合PDF/A子格式，以防您正在爲文檔尋找長時間的數字保存。請參閱VeraPDF open source initiative，您可以使用它來驗證生成和傳入的PDF文檔是否符合PDF/A要求;
5. 保留源文件 PDF格式本身並未設計爲可編輯（儘管已經有一些PDF編輯器），因此您可能會考慮保留源數據以便能夠稍後重新生成PDF文檔，並且可能會引入額外的輸出格式。