ข้ามไปยังเนื้อหาหลัก
FromNine
เมนู

วิศวกรรม

การเชื่อมต่อระบบที่ทำให้ข้อมูลไหลต่อเนื่อง และแสดงให้เห็นเมื่อหยุด

เราเชื่อมต่อระบบ CRM, ERP ระบบงานพิจารณาคำขอ และแพลตฟอร์มภาครัฐ ผ่านข้อตกลง อีเวนต์ และการยืนยันตัวตนที่ทำอย่างถูกต้อง เพื่อให้ข้อมูลเคลื่อนที่อย่างเชื่อถือได้ ข้อผิดพลาดมองเห็นได้ และความสามารถใหม่ รวมถึง AI เชื่อมเข้ามาได้อย่างปลอดภัย

สำหรับองค์กรที่เชื่อมต่อระบบ คู่ค้า และแพลตฟอร์มภายนอก ทั้งในประเทศไทยและกับลูกค้าในยุโรป

ปรึกษาโครงการของคุณดูแพลตฟอร์มที่เราเชื่อมต่อ
การเชื่อมต่อระบบและ API: ชั้นความสามารถสี่ชั้นเรียงซ้อนกัน จากบนลงล่าง ได้แก่ ผู้ใช้ข้อมูล เช่น พอร์ทัล แอปพลิเคชัน และเอเจนต์ เกตเวย์ API พร้อมการยืนยันตัวตน แกนกลางอีเวนต์ และระบบหลักที่เป็นเจ้าของข้อมูลอยู่เบื้องล่าง01พอร์ทัล แอป และเอเจนต์02เกตเวย์ API และตัวตน03แกนกลางอีเวนต์04ระบบหลักเจ้าของข้อมูล
  1. 01API ที่เริ่มจากข้อตกลงด้วย OpenAPI และ AsyncAPI มีการจัดการเวอร์ชันและเอกสาร
  2. 02อีเวนต์ที่รักษาลำดับ ประมวลผลซ้ำได้โดยไม่เกิดผลซ้ำ มีคิวรับข้อความที่ล้มเหลว และเล่นซ้ำได้
  3. 03ติดตามเส้นทางข้อมูลตลอดสาย และคิวข้อผิดพลาดมีทีมที่ระบุชื่อเป็นเจ้าของ

01 ปัญหา

ปัญหาการเชื่อมต่อระบบที่เรามักเข้าไปช่วยแก้

  1. 01

    การเชื่อมต่อแบบจุดต่อจุดที่ไม่มีใครกล้าแก้

    การเชื่อมต่อโดยตรงหลายสิบเส้นระหว่าง CRM, ERP และระบบที่พัฒนาเฉพาะ การแก้ฟิลด์เดียวหมายถึงการทดสอบอินเทอร์เฟซสิบตัว

  2. 02

    รายการซ้ำและความล้มเหลวที่ไม่มีใครเห็น

    การลองส่งซ้ำสร้างคำสั่งซื้อรายการที่สอง ข้อความที่ส่งไม่สำเร็จหายไป และฝ่ายธุรกิจรู้เรื่องจากลูกค้า

  3. 03

    ทุกช่องทางใหม่หมายถึงงานเชื่อมต่อใหม่

    พอร์ทัล แอปพลิเคชันมือถือ และตอนนี้ผู้ช่วย AI ต่างต้องการข้อมูลชุดเดียวกัน และแต่ละช่องทางได้ไฟล์ดึงข้อมูลแยกของตนเอง

  4. 04

    การเชื่อมต่อกับระบบภาครัฐกลายเป็นโครงการแยก

    การเชื่อมต่อกับแพลตฟอร์มแลกเปลี่ยนข้อมูลหรือระบบยืนยันตัวตนของรัฐ ใช้เวลาหลายเดือนทุกครั้งสำหรับงานด้านความมั่นคงปลอดภัยและการขึ้นทะเบียนเชื่อมต่อ

02 สิ่งที่เราส่งมอบ

สิ่งที่เราส่งมอบ

  1. 01 กลยุทธ์และการบริหาร API

    การออกแบบแบบ API-first ด้วยข้อตกลง OpenAPI และ AsyncAPI นโยบายการจัดการเวอร์ชัน เกตเวย์ที่บังคับใช้นโยบายนั้น และพอร์ทัลนักพัฒนาที่ทำให้ทีมค้นหาและใช้ซ้ำสิ่งที่มีอยู่แล้วได้

    สิ่งที่เราทำ

    • แผนผังภาพรวม API และความเป็นเจ้าของ
    • แนวทางการออกแบบและกระบวนการทบทวน
    • นโยบายเกตเวย์ด้านความมั่นคงปลอดภัย โควตา และเวอร์ชัน
    • พอร์ทัลนักพัฒนาและแค็ตตาล็อก API

    สิ่งที่คุณได้รับ

    • แนวทาง API ที่ทีมของคุณนำไปใช้
    • การตั้งค่าเกตเวย์ที่เขียนเป็นโค้ด
    • แค็ตตาล็อก API ที่มีเอกสาร

  2. 02 การเชื่อมต่อแบบขับเคลื่อนด้วยอีเวนต์

    Broker, change data capture และ outbox pattern พร้อมรายละเอียดที่ตัดสินว่าระบบจะใช้ได้จริงหรือไม่ ได้แก่ ลำดับของข้อความ ผู้รับที่ประมวลผลซ้ำได้โดยไม่เกิดผลซ้ำ การจัดการข้อความที่ล้มเหลว และการเล่นซ้ำ

    สิ่งที่เราทำ

    • โมเดลอีเวนต์และหลักการตั้งชื่อ
    • Outbox และ CDC บนระบบต้นทาง
    • การรับประกันลำดับและการประมวลผลซ้ำอย่างปลอดภัยฝั่งผู้รับ
    • คิวข้อความที่ล้มเหลวพร้อมเครื่องมือเล่นซ้ำ

    สิ่งที่คุณได้รับ

    • แกนกลางอีเวนต์ที่ใช้งานจริง
    • ทะเบียน schema และกฎความเข้ากันได้
    • คู่มือการเล่นซ้ำและการกู้คืน

  3. 03 แพลตฟอร์มเชื่อมต่อระบบ เลือกตามเส้นทางข้อมูล

    SAP Integration Suite, MuleSoft และบริการเชื่อมต่อระบบบนคลาวด์ต่างมีจุดที่เหมาะสม เราบอกคุณได้ว่าเมื่อใด iPaaS ดีกว่าโค้ดที่พัฒนาเอง และเมื่อใดไม่ใช่

    สิ่งที่เราทำ

    • ประเมิน middleware ที่มีอยู่
    • เลือกแพลตฟอร์มพร้อมต้นทุนรวมตลอดอายุการใช้งาน
    • การแปลงข้อมูลและตัวเชื่อมที่นำกลับมาใช้ได้
    • การย้ายออกจาก middleware เดิม

    สิ่งที่คุณได้รับ

    • บันทึกการตัดสินใจเลือกแพลตฟอร์มเชื่อมต่อระบบ
    • คลังรูปแบบการเชื่อมต่อระบบ
    • แผนย้ายอินเทอร์เฟซที่มีอยู่

  4. 04 ตัวตนและความไว้วางใจระหว่างระบบ

    OAuth 2.0 และ OpenID Connect, mutual TLS ตัวตนระหว่างบริการ และการเชื่อมต่อกับระบบยืนยันตัวตนอิเล็กทรอนิกส์ (eID) ของประชาชนและธุรกิจในยุโรป ได้แก่ itsme, DigiD และ eHerkenning, BundID, FranceConnect, Cl@ve, SPID และ CIE

    สิ่งที่เราทำ

    • สถาปัตยกรรมตัวตนสำหรับผู้ใช้งานและบริการ
    • การออกแบบโทเคน ขอบเขตสิทธิ์ และความยินยอม
    • การสนับสนุนการขึ้นทะเบียนและการรับรอง eID
    • การเตรียมพร้อมสำหรับ EU Digital Identity Wallet

    สิ่งที่คุณได้รับ

    • การออกแบบตัวตนและการวิเคราะห์ภัยคุกคาม
    • การเชื่อมต่อ eID ที่ใช้งานจริง
    • ตัวตนของบริการและการหมุนเวียนข้อมูลลับที่ใช้งานแล้ว

  5. 05 การทำงานร่วมกันกับระบบภาครัฐ

    การเชื่อมต่อกับแพลตฟอร์มแลกเปลี่ยนข้อมูลภาครัฐในยุโรป เช่น Federal Service Bus และ MAGDA ในเบลเยียม Digikoppeling และ Common Ground ในเนเธอร์แลนด์ มาตรฐาน XÖV และ FIT-Connect ในเยอรมนี PDND ในอิตาลี และ API Entreprise ในฝรั่งเศส รวมถึง Once-Only Technical System ของสหภาพยุโรป

    สิ่งที่เราทำ

    • การขึ้นทะเบียนเชื่อมต่อร่วมกับผู้ดูแลแพลตฟอร์ม
    • การจับคู่กับมาตรฐานข้อมูลของแต่ละประเทศ
    • ข้อกำหนดด้านความมั่นคงปลอดภัยและการบันทึกล็อกของแต่ละแพลตฟอร์ม
    • การออกแบบการแลกเปลี่ยนหลักฐานตามหลักขอครั้งเดียว

    สิ่งที่คุณได้รับ

    • การเชื่อมต่อที่ได้รับการรับรองกับแพลตฟอร์มแลกเปลี่ยนข้อมูล
    • เอกสารการจับคู่ข้อมูล
    • ขั้นตอนปฏิบัติงานร่วมกับผู้ดูแลแพลตฟอร์ม

  6. 06 การมองเห็นการทำงานสำหรับฝ่ายธุรกิจ

    การติดตามเส้นทางข้อมูลที่ฝ่ายธุรกิจอ่านเข้าใจ การกระทบยอดระหว่างระบบ และคิวข้อผิดพลาดที่มีเจ้าของและได้รับการจัดการ

    สิ่งที่เราทำ

    • การติดตามเส้นทางข้อมูลในระดับธุรกิจ
    • รายงานการกระทบยอดระหว่างระบบ
    • การจัดประเภทและส่งต่อข้อผิดพลาด
    • การแจ้งเตือนถึงเจ้าของเส้นทางข้อมูลแต่ละราย

    สิ่งที่คุณได้รับ

    • แดชบอร์ดการเชื่อมต่อของแต่ละกระบวนการทางธุรกิจ
    • การตรวจกระทบยอดที่ใช้งานจริง
    • แผนผังความเป็นเจ้าของของทุกคิวข้อผิดพลาด

03 สถาปัตยกรรม

ตัวอย่างสถาปัตยกรรมอ้างอิง

ข้อมูลออกจากระบบหลักได้สองเส้นทาง คำขอแบบซิงโครนัสผ่าน API ของระบบและเกตเวย์ที่ตรวจตัวตน ขอบเขตสิทธิ์ และโควตา ส่วนการเปลี่ยนแปลงเผยแพร่เป็นอีเวนต์ผ่าน outbox หรือ change data capture และผู้รับประมวลผลโดยไม่เกิดผลซ้ำ

ข้อความที่ล้มเหลวไปอยู่ในคิวข้อความที่ล้มเหลวพร้อมการเล่นซ้ำ ไม่ใช่ในไฟล์ล็อก แถบการติดตามแสดงทุกเส้นทางข้อมูลในภาษาธุรกิจ เพื่อให้เจ้าของกระบวนการเห็นได้เมื่อข้อมูลหยุดไหล

ชั้นในแผนภาพ

ระบบหลักเจ้าของข้อมูล
ERP, CRM และระบบงานพิจารณาคำขอยังคงเป็นผู้มีอำนาจเหนือข้อมูลของตน
API แบบซิงโครนัส
API ของระบบที่จัดการเวอร์ชัน อยู่หลังเกตเวย์ที่ใช้ OAuth 2.0, mTLS และโควตา
อีเวนต์
Outbox, broker คิวข้อความที่ล้มเหลว และการแปลงข้อมูลบนแพลตฟอร์มเชื่อมต่อระบบ
ผู้ใช้ข้อมูล
พอร์ทัล แอปพลิเคชัน เอเจนต์ คู่ค้า และการแลกเปลี่ยนข้อมูลกับภาครัฐ โดยใช้ eID เมื่อเกี่ยวข้องกับประชาชน
ตัวอย่างประกอบ

  1. ระบบหลักเจ้าของข้อมูล

    • ERP, CRM และระบบงานพิจารณาคำขอ

  2. API แบบซิงโครนัส

    • API ของระบบ
    • เกตเวย์ API: OAuth 2.0, mTLS และโควตา

  3. อีเวนต์

    • Outbox และ CDC
    • Broker อีเวนต์
    • คิวข้อความที่ล้มเหลวและการเล่นซ้ำ
    • การแปลงข้อมูลบนแพลตฟอร์มเชื่อมต่อ

  4. ผู้ใช้ข้อมูล

    • พอร์ทัล แอป และเอเจนต์
    • การแลกเปลี่ยนกับคู่ค้าและภาครัฐ
    • ตัวตน: OIDC, mTLS และ eID

  5. การดูแลระบบ

    • ติดตามเส้นทางข้อมูล กระทบยอด และคิวข้อผิดพลาดที่มีเจ้าของ
API และแกนกลางอีเวนต์ทำงานเคียงกัน

ตัวอย่างสถาปัตยกรรม ไม่ใช่ระบบของลูกค้า

อ่านแผนภาพในรูปแบบข้อความ

เส้นทางหลักวิ่งจากระบบหลักที่เป็นเจ้าของข้อมูล ผ่าน API ของระบบที่จัดการเวอร์ชันและเกตเวย์ API ไปยังพอร์ทัล แอปพลิเคชัน และเอเจนต์

ในเวลาเดียวกัน ระบบหลักเผยแพร่การเปลี่ยนแปลงผ่าน outbox และ change data capture ไปยัง event broker ซึ่งส่งต่อไปยังการแลกเปลี่ยนข้อมูลกับคู่ค้าและภาครัฐ และไปยังแพลตฟอร์มเชื่อมต่อระบบสำหรับการแปลงข้อมูล ข้อความที่ล้มเหลวไปยังคิวที่เล่นซ้ำได้ บริการตัวตนที่ใช้ OAuth, mTLS และ eID รักษาความปลอดภัยของการแลกเปลี่ยนกับคู่ค้า

แถบการติดตามด้านล่างแสดงสถานะเส้นทางข้อมูล การกระทบยอด และคิวข้อผิดพลาดที่มีเจ้าของ

04 ข้อพิจารณาและข้อจำกัด

ข้อพิจารณาทางวิศวกรรมและข้อจำกัด

  • การส่งครั้งเดียวพอดีเป็นงานออกแบบ ไม่ใช่การตั้งค่า

    วิธีที่เราจัดการ

    เราสมมติว่าข้อความอาจมาถึงสองครั้งหรือไม่เรียงลำดับ และออกแบบผู้รับให้ประมวลผลซ้ำได้โดยไม่เกิดผลซ้ำ โดยตกลงคีย์และกฎลำดับสำหรับอีเวนต์แต่ละประเภท

    ข้อจำกัดและเงื่อนไข

    ระบบเดิมบางระบบรับ idempotency key ไม่ได้ หรือรายงานไม่ได้ว่าประมวลผลอะไรไปแล้ว สำหรับระบบเหล่านั้นเราเพิ่มการกระทบยอดแทนการทำเป็นว่าไม่มีปัญหา

  • iPaaS ไม่ใช่คำตอบเสมอไป

    วิธีที่เราจัดการ

    แพลตฟอร์มได้เปรียบสำหรับตัวเชื่อมและการแปลงข้อมูลมาตรฐานจำนวนมาก บริการที่พัฒนาเองได้เปรียบสำหรับตรรกะที่ซับซ้อน ปริมาณข้อมูลสูง หรือข้อกำหนดด้านความหน่วงที่เข้มงวด เราบันทึกการเลือกไว้สำหรับการเชื่อมต่อแต่ละเส้น

    ข้อจำกัดและเงื่อนไข

    รูปแบบสิทธิ์การใช้งานเปลี่ยนได้ แพลตฟอร์มที่ถูกในวันนี้อาจกลายเป็นรายการใหญ่ที่สุดในงบประมาณการเชื่อมต่อระบบ เราจึงคำนวณต้นทุนในระยะหลายปี

  • แพลตฟอร์มภาครัฐกำหนดจังหวะของตนเอง

    วิธีที่เราจัดการ

    เราเตรียมเอกสารขึ้นทะเบียน หลักฐานด้านความมั่นคงปลอดภัย และแผนทดสอบตั้งแต่เนิ่น ๆ และทำงานร่วมกับผู้ดูแลแพลตฟอร์มตั้งแต่สัปดาห์แรก

    ข้อจำกัดและเงื่อนไข

    กรอบเวลาการรับรองและการขึ้นทะเบียนกำหนดโดยผู้ดูแลแพลตฟอร์ม ไม่ใช่โดยเรา เราวางแผนให้สอดคล้องกับกรอบเวลาเหล่านั้น และบอกคุณว่าอยู่ตรงไหนบนเส้นทางวิกฤต

  • ผู้ใช้ข้อมูลที่เป็น AI ต้องใช้ API ที่จำกัดขอบเขต

    วิธีที่เราจัดการ

    เอเจนต์และผู้ช่วย AI ได้ API เฉพาะที่จำกัดสิทธิ์ มีขีดจำกัดและบันทึกการตรวจสอบ ไม่ใช่สิทธิ์กว้างแบบเดียวกับบริการภายใน

    ข้อจำกัดและเงื่อนไข

    การเปิด API ให้เอเจนต์เพิ่มความเสี่ยง เราทบทวน API แต่ละตัวร่วมกับทีมความมั่นคงปลอดภัยของคุณก่อนเปิดใช้งาน

05 วิธีการทำงาน

วิธีการทำงานของเรา

เราคลี่ปมก่อนสร้าง และทุกเส้นทางข้อมูลที่ส่งมอบต้องมีเจ้าของ

  1. 01

    ทำแผนผังเส้นทางข้อมูล

    ทุกอินเทอร์เฟซ ปริมาณข้อมูล ประวัติการขัดข้อง และเจ้าของฝ่ายธุรกิจ

    ผลลัพธ์ภาพรวมการเชื่อมต่อระบบและการจัดลำดับความเสี่ยง

  2. 02

    กำหนดกฎ

    แนวทาง API หลักการของอีเวนต์ โมเดลตัวตน และการเลือกแพลตฟอร์ม

    ผลลัพธ์แนวทางการเชื่อมต่อระบบและบันทึกการตัดสินใจ

  3. 03

    ย้ายทีละเส้นทาง

    เริ่มจากเส้นทางที่เสี่ยงที่สุด โดยรันการกระทบยอดคู่กับอินเทอร์เฟซเดิมจนตัวเลขตรงกัน

    ผลลัพธ์เส้นทางที่ย้ายแล้วพร้อมหลักฐานการกระทบยอด

  4. 04

    ดูแลให้มองเห็นสถานะได้

    แดชบอร์ดของแต่ละกระบวนการทางธุรกิจ และคิวข้อผิดพลาดที่มีเจ้าของระบุชื่อ

    ผลลัพธ์แผนผังความเป็นเจ้าของเส้นทางข้อมูลและแดชบอร์ด

06 การควบคุมโดยมนุษย์

จุดที่คนยังเป็นผู้ควบคุม

การเชื่อมต่อระบบทำงานได้เองโดยไม่ต้องมีคนเฝ้า แต่ความรับผิดชอบเมื่อเกิดปัญหาต้องมีเจ้าของเสมอ

  • ทุกคิวข้อผิดพลาดมีเจ้าของ

    ข้อความที่ล้มเหลวไปยังทีมที่รับผิดชอบ พร้อมบริบทและปุ่มเล่นซ้ำ ไม่ใช่ไปยังล็อกส่วนกลาง

  • การเปลี่ยนข้อตกลงผ่านการทบทวน

    การเปลี่ยน API หรืออีเวนต์ที่กระทบผู้ใช้ข้อมูลต้องผ่านการทบทวนร่วมกับผู้ใช้ข้อมูลก่อนเผยแพร่

  • การเล่นซ้ำต้องตั้งใจ

    การเล่นซ้ำข้อความเข้าสู่ระบบหลักเป็นการกระทำที่ต้องได้รับอนุญาต และบันทึกว่าใครทำและเพราะอะไร

07 เทคโนโลยี

เทคโนโลยีที่เราใช้

แพลตฟอร์มเชื่อมต่อระบบ
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • บริการเชื่อมต่อระบบของ AWS และ Google Cloud
อีเวนต์และสตรีมมิง
  • Apache Kafka
  • RabbitMQ
  • Event broker บนคลาวด์
  • Debezium สำหรับ change data capture
API
  • OpenAPI และ AsyncAPI
  • เกตเวย์ API และพอร์ทัลนักพัฒนา
  • GraphQL ในจุดที่เหมาะสม
  • การทดสอบข้อตกลง
ตัวตน
  • OAuth 2.0 และ OpenID Connect
  • Mutual TLS
  • Keycloak และผู้ให้บริการยืนยันตัวตนบนคลาวด์
  • ระบบ eID ของแต่ละประเทศ

การระบุชื่อเทคโนโลยีเป็นการบอกประสบการณ์ด้านวิศวกรรมของเรา ไม่ได้หมายความว่าเราเป็นพันธมิตรหรือได้รับการรับรองจากเจ้าของเทคโนโลยีนั้น

08 ตัวอย่าง

ตัวอย่างประกอบ

ตัวอย่างประกอบ

ERP ที่ส่งใบแจ้งหนี้ผ่าน Peppol ให้ลูกค้าในยุโรปและใช้ e-Tax Invoice ในประเทศ

01สถานการณ์
ตัวอย่าง: ผู้ส่งออกเฟอร์นิเจอร์ขายให้ทั้งลูกค้าในประเทศไทยและผู้จัดจำหน่ายในยุโรป ลูกค้าในยุโรปบางรายขอรับใบแจ้งหนี้ผ่าน Peppol ส่วนใบกำกับภาษีในประเทศยังออกเป็นไฟล์ PDF และทีมบัญชีต้องคีย์ข้อมูลซ้ำในหลายระบบ
02ระบบที่เราจะสร้าง
ชั้นการเชื่อมต่อที่ส่งใบแจ้งหนี้จาก ERP ไปยังผู้ให้บริการจุดเชื่อมต่อ Peppol สำหรับลูกค้าในยุโรป และไปยังระบบ e-Tax Invoice & e-Receipt สำหรับใบกำกับภาษีในประเทศ ในกรณีที่บริษัทเลือกเข้าร่วม พร้อมการตรวจความถูกต้องและการกระทบยอด
03จุดที่คนเป็นผู้ตัดสินใจ
ฝ่ายบัญชีอนุมัติการจับคู่ข้อมูลกับแต่ละรูปแบบ และใบแจ้งหนี้ที่ไม่ผ่านการตรวจจะส่งไปยังทีมที่ระบุชื่อ ไม่ส่งซ้ำโดยอัตโนมัติ
04สิ่งที่เราจะวัดผล
สัดส่วนใบแจ้งหนี้ที่ส่งแบบอิเล็กทรอนิกส์ จำนวนใบที่ถูกปฏิเสธ และเวลาที่ใช้แก้ไขใบที่ไม่ผ่านการตรวจ

09 มุมมองรายอุตสาหกรรม

ในอุตสาหกรรมของคุณ

  • ภาครัฐ

    การแลกเปลี่ยนข้อมูลตามหลักขอครั้งเดียวกับแหล่งข้อมูลต้นฉบับ eID สำหรับประชาชนและธุรกิจ และการบันทึกล็อกที่แพลตฟอร์มภาครัฐกำหนด ดูงานภาครัฐของเราในยุโรป

  • การผลิตและอุตสาหกรรม

    ERP, MES และพอร์ทัลซัพพลายเออร์ที่เชื่อมต่อกันผ่านอีเวนต์ เพื่อให้การวางแผน การผลิต และงานบริการเห็นภาพเดียวกัน

  • บริการทางการเงิน

    ระบบหลัก CRM และ API ของคู่ค้า ที่เชื่อมต่อกันด้วยการยืนยันตัวตนที่เข้มแข็ง บันทึกการตรวจสอบ และการกระทบยอดที่ฝ่ายการเงินเชื่อถือ

ประเทศไทย

จากใบกำกับภาษีในประเทศถึงใบแจ้งหนี้อิเล็กทรอนิกส์ในยุโรป

ผู้ส่งออกไทยมักต้องรองรับสองฝั่งพร้อมกัน ลูกค้าในยุโรปบางรายขอรับใบแจ้งหนี้อิเล็กทรอนิกส์ (e-invoice) ผ่านเครือข่าย Peppol ขณะที่ในประเทศไทย ระบบใบกำกับภาษีอิเล็กทรอนิกส์และใบรับอิเล็กทรอนิกส์ (e-Tax Invoice & e-Receipt) ของกรมสรรพากรเป็นระบบที่ผู้ประกอบการเลือกใช้โดยสมัครใจ ข้อมูลอิเล็กทรอนิกส์และลายมือชื่ออิเล็กทรอนิกส์มีผลทางกฎหมายตาม พ.ร.บ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 และที่แก้ไขเพิ่มเติม

ฝั่งยุโรป eIDAS 2 กำหนดให้ประเทศสมาชิกจัดให้มี EU Digital Identity Wallet และระบบแลกเปลี่ยนข้อมูลกับระบบ eID ยังแตกต่างกันไปในแต่ละประเทศ เราออกแบบชั้นการเชื่อมต่อที่ให้ระบบภายนอกแต่ละระบบเป็นตัวแปลงที่อยู่หลังข้อตกลงภายในที่คงที่ การเพิ่มช่องทางหรือประเทศใหม่จึงหมายถึงการเพิ่มตัวแปลงและการขึ้นทะเบียน ไม่ใช่การรื้อระบบเบื้องหลัง

คำถามเกี่ยวกับการเชื่อมต่อระบบและ API

ควรใช้แพลตฟอร์มเชื่อมต่อระบบหรือพัฒนาการเชื่อมต่อเอง

ใช้ทั้งสองแบบสำหรับเส้นทางข้อมูลที่ต่างกัน ตัวเชื่อมมาตรฐาน การแปลงข้อมูล และการเชื่อมต่อคู่ค้ารายใหม่เหมาะกับแพลตฟอร์ม ส่วนเส้นทางที่มีปริมาณสูง ไวต่อความหน่วง หรือมีตรรกะมาก มักเหมาะกับบริการที่พัฒนาเอง เราตัดสินใจทีละเส้นทางและบันทึกเหตุผลไว้

FromNine เชื่อมต่อ Salesforce, SAP และ Odoo หรือไม่

เชื่อมต่อเป็นประจำ ทั้งระหว่างกันเอง และกับระบบที่พัฒนาเฉพาะและระบบภาครัฐ FromNine เป็นพันธมิตรของทั้งสามแพลตฟอร์ม (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner) ทีมเชื่อมต่อระบบของเราจึงทำงานร่วมกับผู้เชี่ยวชาญด้านแพลตฟอร์ม ดูงานเชื่อมต่อระบบ SAP ของเรา

จำเป็นต้องใช้การเชื่อมต่อแบบขับเคลื่อนด้วยอีเวนต์หรือไม่

เมื่อหลายระบบต้องตอบสนองต่อการเปลี่ยนแปลงเดียวกัน หรือเมื่อต้องการแยกรอบการเปิดใช้งานของแต่ละระบบออกจากกัน อีเวนต์ช่วยได้ สำหรับการรับส่งคำขอและคำตอบแบบง่ายระหว่างสองระบบ API มักเพียงพอ ระบบส่วนใหญ่ใช้ทั้งสองแบบ

เชื่อมต่อกับระบบ eID ของรัฐได้หรือไม่

ได้ สำหรับบริการในยุโรป เราเชื่อมต่อระบบ eID ของประชาชนและธุรกิจ และออกแบบให้รองรับ EU Digital Identity Wallet ที่ประเทศสมาชิกกำลังนำมาใช้ภายใต้ eIDAS 2 ข้อกำหนดในการขึ้นทะเบียนแตกต่างกันในแต่ละระบบ และเราวางแผนรองรับตั้งแต่เนิ่น ๆ

เรามี middleware เดิมอยู่ ต้องเปลี่ยนหรือไม่

ไม่ต้องเปลี่ยนทั้งหมดในครั้งเดียว เราจัดทำแผนผังสิ่งที่ทำงานอยู่บน middleware นั้น ย้ายเส้นทางที่เสี่ยงที่สุดหรือแพงที่สุดก่อน และคงการกระทบยอดไว้จนกว่าแต่ละเส้นทางที่ย้ายแล้วจะพิสูจน์ได้ว่าถูกต้อง

นำอินเทอร์เฟซที่ล้มเหลวบ่อยที่สุดมาคุยกับเรา

เราจะแสดงว่าจะทำให้อินเทอร์เฟซนั้นติดตามได้ ประมวลผลซ้ำได้อย่างปลอดภัย และมีเจ้าของได้อย่างไร และการทำแบบเดียวกันกับส่วนที่เหลือต้องใช้อะไรบ้าง

ปรึกษาโครงการของคุณดูโซลูชันผู้ช่วยงานบริการ