Server Pembuatan PDF

Saya ditugaskan untuk membuat (atau mencari sesuatu yang sudah berfungsi) server terpusat dengan API yang memiliki kemampuan untuk mengembalikan file PDF dengan meneruskan beberapa data, dan nama templatnya, itu harus menjadi solusi yang kuat, perusahaan siap. Tujuannya adalah sebagai berikut:

  • Serangkaian templat untuk berbagai hal perusahaan. (Faktur, Pesanan, Perencanaan Pesanan, dll)
  • Cara mengembalikan PDF dari perangkat lunak eksternal (Situs Web, ERP, dll)
  • Ini bisa menjadi solusi perusahaan yang sudah siap pakai, namun mereka mendesak untuk mencari solusi khusus.
  • Bisa dalam bahasa apa pun, tapi kami tidak memiliki pemrogram Java khusus. Kami adalah PHP / .NET, beberapa dari kami mencoba-coba, namun kurva pembelajarannya mungkin sedikit curam.

Jadi, saya sudah membaca. Salah satu cara yang kami pikir mungkin dilakukan adalah menginstal server laporan jasper, dan membuat templat di Jaspersoft Studio, lalu menggunakan API untuk mengembalikan file PDF. Seorang kolega mendukung opsi ini, karena sebagian besar sudah selesai, tetapi 1º adalah java dan 2º menurut saya seperti menggunakan palu untuk memecahkan kacang.

Opsi lain yang telah kami mainkan adalah menggunakan C# dengan iTextSharp untuk membuat server, dan membuat API kami sendiri yang mengembalikan PDF dengan data yang kami perlukan. Dengan melakukan hal ini kita bisa mendapatkan beberapa manfaat, seperti menggunakan konektor database yang telah kita buat dan mengekstraksi sebagian besar data dari database, daripada harus meneruskan sejumlah besar data, namun karena data tersebut telanjang, sebenarnya tidak memiliki sistem templating. Kami akan membuat sesuatu dengan XMLWorker atau dengan kelas c# tetapi itu tidak "semudah" seperti drag dan drop. Untuk kasus ini saya sudah membaca tentang XFA juga, tapi dokumentasi di situs iText menyesatkan dan tidak jelas.

Saya juga telah membaca tentang beberapa alternatif lain, seperti PrinceXML, PDFBox, FOP, dll, tetapi konsepnya akan sama dengan iText , kami harus melakukannya sendiri.

Pilihan saya, meskipun lebih banyak pekerjaan yang harus dilakukan adalah menggunakan iText dan menggunakan HTML / CSS untuk templatnya, namun kolega saya mengklaim bahwa templat tersebut harus dapat diubah setiap dua minggu sekali (saya ragu itu), dan jadilah mudah. HTML/CSS akan terlalu merepotkan.

Jadi pertanyaan sebenarnya adalah, bagaimana pendekatan bisnis lain terhadap hal ini? Apakah saya melewatkan sesuatu dalam pencarian saya? Apakah ada cara yang lebih mudah untuk mencapai hal ini?

PS: Saya tidak tahu apakah SO akan menjadi tempat yang tepat untuk pertanyaan ini, tapi saya kebanyakan tersesat dan mempertaruhkan tag "pertanyaan yang terlalu luas" atau "di luar topik" sepertinya tidak terlalu buruk.

EDIT:

  • Masukan harus dikirim dengan permintaan yang sama. Jika kita memutuskan rute C#, kita bisa mendapatkan ~70% data dari ERP secara langsung, namun bagaimanapun juga, ERP harus menerima permintaan kiriman dengan beberapa data (templat, dan data yang diperlukan untuk templat itu, seperti data faktur, atau ID faktur jika kita memiliki akses ke ERP).
  • Outputnya harus berupa PDF (tidak tertarik dengan format lain, hanya PDF).
  • Templat akan diperbarui hanya oleh TI. (Kebanyakan kami, tim pengembangan).
  • Dari segi kinerja, saya tidak tahu berapa banyak tenaga yang kami perlukan, namun saat ini, tanpa peningkatan apa pun, kami melihat ~500/1000 PDF setiap hari, sebagian besar dicetak dari pukul 10 hingga 10.30 dan dari pukul 12 hingga 13. Lalu mungkin 100 lagi sepanjang sisa hari itu.
  • Kinerja TOP tidak boleh lebih dari ~10.000 setiap hari ketika planet-planet sejajar, dan merupakan musim penjualan (dua kali setahun). Itu harus menjadi batas atas kita untuk tahun-tahun mendatang.

  • Templat memiliki beberapa persyaratan:

    • Have repeating blocks (invoice lines, for example).
    • Miliki gambar sebagai latar belakang, sebagai tanda air, dan sebagai blok.
    • Harus multi bahasa (dapat diterjemahkan, dengan data yang sama).
    • Miliki beberapa blok yang hanya ditampilkan dengan syarat.
    • Blok bergantung pada halaman (header PDF / header halaman / footer halaman / footer PDF)
    • Templat mungkin harus melakukan penghitungan terhadap beberapa data, menurut saya kita tidak akan memerlukannya, tetapi ini adalah sesuatu yang mungkin diminta oleh perusahaan di masa mendatang.

  • PDF tidak perlu disimpan, karena kami memiliki sistem manajemen dokumen, mungkin di masa mendatang kami dapat menghubungkannya.

Data tambahan: Saat ini kami menggunakan "Fast-Reports v2 VCL"


server enterprise pdf c# pdf-generation
person TJSoler    schedule 21.03.2016    source sumber
comment
dokumentasi di situs iText menyesatkan dan tidak jelas - klaim tanpa referensi seperti itu sangatlah tidak adil.   -  person mkl    schedule 29.03.2016
comment
Maaf saya tidak menjelaskannya sendiri, bukan berarti dokumennya tidak jelas, saya akan mengeditnya, maksud saya saya masuk ke developers.itextpdf.com dan hanya menemukan referensi dan contohnya, bukan dokumentasi per se, saya tidak dapat mengevaluasi apakah produk tersebut sesuai dengan kebutuhan saya, bukan XFA mudah dipahami, kemampuan templating atau apa yang ada atau tidak. Saya harus membacanya dari situs itext. Saya tahu pastinya adalah saya, dan ekspektasi saya terhadap dokumen.   -  person TJSoler    schedule 30.03.2016

Jawaban (2)


arrow_upward
1
arrow_downward

Pertanyaan Anda menunjukkan bahwa Anda telah mempertimbangkan masalah secara detail sebelum meminta bantuan, jadi saya yakin SO akan ramah.

Tentu saja satu hal yang belum banyak Anda jelaskan dalam uraian Anda adalah persyaratan fungsional yang lebih luas. Anda menyebutkan memecahkan masalah dengan palu, tapi menurut saya Anda sebagian besar fokus pada teknologi/antarmuka. Jika Anda mempertimbangkan persyaratan yang lebih luas untuk dokumen yang perlu Anda buat, variabel yang terlibat, mungkin ini adalah hal yang lebih besar menurut Anda.

Pendekatan yang saya sarankan adalah membuat prototipe solusi, dengan asumsi Anda memiliki ruang untuk melakukannya. Dari penelitian Anda, pilihlah 3 yang terbaik untuk dicoba yang mungkin mencakup bangunan khusus yang Anda pikirkan. Letakkan mereka melalui beberapa kasus penggunaan nyata secara menyeluruh - sekasar mungkin namun realistis. Satu atau dua dokumen penting yang perlu Anda keluarkan harus digunakan di semua solusi. Pastikan Anda memenuhi persyaratan paling penting atau paling umum dalam hal:

  1. Format Masukan - siapa yang dapat/harus memperbarui templat. Apa syarat idealnya dan berapa syarat minimalnya? Persyaratan Keluaran - kepada siapa Anda mengirim dan format apa yang penting/diinginkan
  2. Persyaratan Data - apa sumber data Anda dan seberapa sulit/mudahnya mendapatkan data dari sumber Anda ke sistem pelaporan dalam format yang diperlukan?
  3. Fitur templat - jika Anda menggunakan templat, fitur apa saja yang dibutuhkan templat tersebut? Ini termasuk format input tetapi saya lebih banyak memikirkan fitur-fitur mesin seperti konten berulang/bersyarat, penyisipan gambar, manipulasi tabel, dll. yaitu apakah faktur, pesanan, dan dokumen perencanaan Anda polos atau rumit
  4. Persyaratan API - apakah Anda memiliki persyaratan API yang lebih luas. Anda menyebutkan bahwa Anda menggunakan PHP sehingga perpustakaan PHP atau Layanan Web/Web mungkin menjadi titik awal yang baik.
  5. Kinerja - Anda belum menyebutkan karakteristik kinerja apa pun, tetapi tentu saja jika Anda bekerja dalam skala besar (perusahaan), akan ada gunanya mengukur throughput secara kasar.

iText dan Jasper tentunya merupakan mesin kelas perusahaan yang dapat Anda andalkan. Anda mungkin ingin melihat Docmosis (harap diperhatikan saya bekerja untuk perusahaan tersebut) dan mungkin melakukan beberapa pencarian untuk perpustakaan PDF yang menggunakan templat.

Antarmuka layanan web mungkin merupakan fitur utama yang mungkin ingin Anda lihat. REST API mudah dipanggil dari PHP dan hampir semua tumpukan teknologi. Ini berarti Anda mungkin memiliki pilihan tentang bagaimana Anda dapat merancang sebuah solusi, dan biasanya mudah untuk membuat prototipe. Jika Anda memutuskan untuk mengambil jalur pembuatan prototipe dan mencoba Docmosis, mulailah dengan layanan cloud karena Anda dapat membuat prototipe/integrasi dengan sangat cepat.

Saya harap itu membantu.

person Paul Jowett    schedule 22.03.2016
comment
Terima kasih! Saya akan mengedit pertanyaan dengan beberapa detail lagi setiap kali saya punya sedikit waktu, tetapi untuk saat ini, dengan solusi tertanggal yang kami gunakan saat ini (laporan cepat 3, terintegrasi di dalam erp yang dibuat khusus), kami memproduksi sekitar 500 - 1000 pdf setiap hari, sebagian besar pada jam-jam mengintip, tetapi jika kita memusatkan segala sesuatu dalam sistem ini sesuai rencana, tahun ini akan mencetak ~5000 setiap hari (~10000 pada puncak beberapa bulan penjualan) dan bertambah setiap tahun. Kami hanya memiliki ~10 templat, tetapi cukup rumit (berulang / bersyarat / multilang / gambar / ...) dan templat akan diedit oleh kami (tim pengembang). - person TJSoler; 22.03.2016

arrow_upward
0
arrow_downward

Dari pengalaman saya selama bertahun-tahun bekerja dengan PDF, saya rasa Anda harus memperhatikan hal-hal berikut:

  1. Kinerja: Anda dapat mencapai kinerja tercepat dengan pembuatan file pdf berbasis API dibandingkan dengan pembuatan HTML atau XML ke PDF (karena ada lapisan konversi tambahan yang terlibat). Mengingat puncak beban, Anda mungkin ingin menghitung biaya peningkatan produksi dengan menambahkan lebih banyak server (dan memperkirakan biaya server tambahan atau sumber daya yang diperlukan per file pdf tambahan per hari).

  2. Kemudahan dalam iterasi dan perubahan: seberapa sering Anda perlu menyesuaikan template? Jika Anda akan membuat templat hanya sekali (dengan beberapa iterasi) tetapi tidak diperlukan perubahan, maka Anda akan baik-baik saja dengan hanya mengkodekannya menggunakan API. Jika tidak, Anda harus mempertimbangkan penggunaan HTML atau XML untuk templat guna menyederhanakan perubahan dan mengurangi kerumitan dalam membuat perubahan pada templat;

  3. Pencarian dan pengindeksan: Jika Anda perlu menjalankan pencarian di antara dokumen yang dibuat, maka Anda harus mempertimbangkan untuk menyimpan indeks dokumen yang dihasilkan atau mungkin menyimpan lebih banyak data sumber dalam XML bersama dengan file PDF yang dihasilkan;
  4. Pelestarian jangka panjang: sebaiknya Anda mematuhi PDF/A sub-format jika Anda mencari pelestarian digital jangka panjang untuk dokumen Anda. Lihat inisiatif sumber terbuka VeraPDF yang dapat Anda gunakan untuk memvalidasi dokumen PDF yang dihasilkan dan masuk terhadap kesesuaian dengan persyaratan PDF/A;
  5. Melestarikan file sumber Format PDF itu sendiri tidak dirancang untuk diedit (walaupun sudah ada beberapa editor PDF) jadi Anda mungkin mempertimbangkan perlunya melestarikan data sumber agar dapat membuat ulang dokumen PDF nanti dan mungkin perkenalkan format keluaran tambahan nanti.
person Eugene    schedule 23.03.2016