เซิร์ฟเวอร์การสร้าง 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 คงจะใช้งานมากเกินไป

คำถามที่แท้จริงก็คือ ธุรกิจอื่นจะเข้าถึงสิ่งนี้ได้อย่างไร ฉันทิ้งอะไรไว้ในการค้นหาหรือไม่? มีวิธีที่ง่ายกว่านี้ในการบรรลุเป้าหมายนี้หรือไม่?

ป.ล.: ฉันไม่รู้ว่า SO จะเป็นสถานที่ที่ถูกต้องสำหรับคำถามนี้หรือไม่ แต่ส่วนใหญ่ฉันหลงทางและการเสี่ยงที่แท็ก "คำถามที่กว้างเกินไป" หรือ "นอกหัวข้อ" ก็ไม่ได้ดูแย่ขนาดนั้น

แก้ไข:

  • ควรส่งข้อมูลเข้าพร้อมกับคำขอเดียวกัน หากเราตัดสินใจเลือกเส้นทาง C# เราก็สามารถรับข้อมูลประมาณ 70% จาก ERP ได้โดยตรง แต่อย่างไรก็ตาม ERP ควรยอมรับคำขอโพสต์ที่มีข้อมูลบางส่วน (เทมเพลตและข้อมูลที่จำเป็นสำหรับเทมเพลตนั้น เช่น ข้อมูลใบแจ้งหนี้ หรือ ID ใบแจ้งหนี้หากเราสามารถเข้าถึง ERP ได้)
  • ผลลัพธ์ควรเป็น PDF (ไม่สนใจรูปแบบอื่น เป็นเพียง PDF)
  • เทมเพลตจะได้รับการอัปเดต เท่านั้น โดยฝ่ายไอที (ส่วนใหญ่เป็นพวกเราทีมพัฒนา)
  • ประสิทธิภาพที่ชาญฉลาด ฉันไม่รู้ว่าเราต้องการกล้ามเนื้อมากแค่ไหน แต่ตอนนี้ หากไม่มีการเพิ่มขึ้นใดๆ เรากำลังดูไฟล์ PDF ประมาณ ~500/1,000 ครั้งต่อวัน โดยส่วนใหญ่จะพิมพ์ตั้งแต่ 10.00 น. ถึง 10.30 น. และ 12.00 น. ถึง 13.00 น. แล้วอาจจะอีก 100 ที่เหลือของวัน
  • ประสิทธิภาพสูงสุดไม่ควรเกิน ~10,000 ครั้งต่อวันเมื่อดาวเคราะห์จัดเรียงตัว และเป็นช่วงฤดูการขาย (ปีละสองครั้ง) นั่นควรจะเป็นเพดานของเราในปีต่อ ๆ ไป

  • เทมเพลตมีข้อกำหนดบางประการ:

    • 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 และพบเฉพาะข้อมูลอ้างอิงและตัวอย่าง ไม่ใช่เอกสาร ต่อตัว ฉันไม่สามารถประเมินได้จริงๆ ว่าผลิตภัณฑ์ตรงกับความต้องการของฉันหรือไม่ ไม่ใช่ 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 - 1,000 pdfs ทุกวัน โดยส่วนใหญ่เป็น peek hour แต่ถ้าเรารวมทุกอย่างไว้ในระบบนี้ตามที่วางแผนไว้ ปีนี้ควรพิมพ์ ~5,000 ครั้งต่อวัน (~10,000 ในสองสามเดือนของยอดขายสูงสุด) และเติบโตทุกปี เรามีเทมเพลตเพียงประมาณ 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