ONEWEB เป็นแพลตฟอร์มการพัฒนาแอพพลิเคชันที่สร้างขึ้นจากเทคโนโลยี Java EE และรองรับสถาปัตยกรรม 3 ระดับซึ่งประกอบด้วย Web Tier, Application Tier และ Database Tier เทคโนโลยีนี้ ได้รับการพัฒนาให้เป็นแอพพลิเคชันระดับองค์กรที่จะช่วยให้คุณสามารถขยายขีดความสามารถ เพื่อรองรับการเติบโตของธุรกิจของคุณ

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

• สถาปัตยกรรมอิสระ (Standalone Architecture)

• สถาปัตยกรรมความพร้อมใช้งานสูง (High Availability Architecture)

• สถาปัตยกรรมคลาวด์ (Cloud Architecture)

ก่อนที่คุณจะเริ่มการติดตั้ง โปรดดำเนินการดังต่อไปนี้

• ออกแบบ server architecture สำหรับ ONEWEB ของคุณตามความต้องการของแอพพลิเคชัน

• ประเมินขนาดสำหรับเซิร์ฟเวอร์ของคุณตามโหลดที่คาดไว้

• ตรวจสอบข้อกำหนดเบื้องต้นของระบบสำหรับการติดตั้ง ONEWEB

High Availability Architecture จะต้องได้รับการพิจารณาสำหรับระบบที่วิกฤตร้ายแรง ซึ่งสามารถทนต่อความล้มเหลวและข้อผิดพลาดจำนวนหนึ่งก่อนที่จะทำงานไม่ถูกต้องอีกต่อไป การออกแบบสถาปัตยกรรมนี้มาจากมาตรฐานหลักของความสามารถของบริการของคุณเพื่อให้เป็นไปตามข้อตกลงระดับการให้บริการ (SLA) ที่คาดไว้

ประเด็นสำคัญในการออกแบบ High Availability Architecture มีดังนี้

หลีกเลี่ยงความล้มเหลวเพียงจุดเดียว (Avoid single points of failure)

1. ความซ้ำซ้อนของฮาร์ดแวร์ (Hardware redundancy) กำจัดจุดล้มเหลวเพียงจุดเดียวในระบบโดยรวมความซ้ำซ้อนของฮาร์ดแวร์ มีเทคนิคมากมายในการออกแบบความซ้ำซ้อนของฮาร์ดแวร์ ใช้มาตราส่วนแนวนอนเพื่อกระจายเซิร์ฟเวอร์แอพพลิเคชันไปยังเครื่องจริงหลายเครื่อง (Active-Active) - เซิร์ฟเวอร์สำรองข้อมูลผู้ใช้ (Active-Standby)

2. ความซ้ำซ้อนของกระบวนการ (Process redundancy) จัดให้มีความซ้ำซ้อนของกระบวนการและการแยกส่วนเพื่อให้เซิร์ฟเวอร์ที่ล้มเหลวไม่ส่งผลกระทบต่อเซิร์ฟเวอร์ที่ใช้งานได้ดีที่เหลืออยู่

โหลดบาลานซ์ (Active-Active) ใช้เทคนิค Load balancing เพื่อให้แน่ใจว่าเซิร์ฟเวอร์แต่ละเครื่องไม่ถูกร้องขอจากไคลเอนต์มากเกินไปในขณะที่เซิร์ฟเวอร์อื่นไม่ได้ใช้งาน

การสนับสนุนเมื่อเกิดข้อผิดพลาด (Active-Standby) สภาพแวดล้อมต้องสามารถประมวลผลคำขอของไคลเอ็นต์ต่อไปได้ แม้ว่าคอมโพเนนต์อย่างน้อยหนึ่งรายการจะออฟไลน์อยู่ก็ตาม

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

จำนวนคอร์ของ CPU สามารถประมาณได้โดยจำนวนผู้ใช้หารด้วย 200 ตัวอย่างเช่น ผู้ใช้งาน 500 ราย = 500/200 = 2.5 ดังนั้นจำเป็นต้องปัดเศษ CPU สูงสุด 3 คอร์ เพื่อความแม่นยำยิ่งขึ้น ควรคำนึงถึงความซับซ้อนของแอพพลิเคชันและธุรกรรมของคุณด้วย

* สมมติว่าผู้ใช้ 1 คนสร้างคำขอหรือธุรกรรม 2 รายการไปยังเซิร์ฟเวอร์ทุก 1 นาที

เมื่อคุณพิจารณาสถาปัตยกรรมของแอพพลิเคชันของคุณ คุณควรถามคำถามต่อไปนี้

คุณกำลังพิจารณาสภาพแวดล้อมใด?

Production การกู้คืนความเสียหายหรือการทดสอบ Environment

แอพพลิเคชันเป็นระบบที่สำคัญหรือไม่?

หากแอพพลิเคชันของคุณเป็นระบบที่สำคัญ เช่น จำเป็นต้องออนไลน์ตลอด 24 ชั่วโมงทุกวัน เช่น การประมวลผลการชำระเงินหรือธุรกรรมที่สำคัญ คุณอาจต้องพิจารณา Active-Active หรือ Cluster Environment เพื่อให้แน่ใจว่าการดำเนินการของคุณสามารถทำงานได้อย่างต่อเนื่อง

ระบบนี้สามารถหยุดทำงานเพื่อการบำรุงรักษาได้หรือไม่? SLA คืออะไร?

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

คุณต้องการการ Disaster Recovery หรือไม่ RPO (Recovery Point Target) และ RTO (Recovery Time Target) ของคุณคืออะไร?

หากคุณต้องการ DR (Disaster Recovery) สำหรับแผนสำรองในกรณีที่คุณไม่สามารถใช้งาน Production Environment ได้ คุณต้องพิจารณา RPO (Recovery Point Objective) และ RTO (Recovery Time Objective) เพื่อเลือกโซลูชันที่เหมาะสมสำหรับ DR ของคุณ

มีผู้ใช้งานกี่คน?

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

สามารถเลือกแยกเซิร์ฟเวอร์ของคุณเป็นสถาปัตยกรรมแบบ Active-Active ด้วยโหลดบาลานเซอร์เพื่อกระจายภาระงานของคุณไปยังเซิร์ฟเวอร์หลายเครื่อง

จำนวนธุรกรรม (ต่อปีหรือต่อเดือน)?

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

จำนวนการทำธุรกรรมในช่วงเวลาสูงสุดหรือเหตุการณ์สูงสุด?

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

ข้อมูลของคุณจะถูกเก็บไว้ในระบบจำนวนเท่าใดและนานเท่าใด (ในแง่ของบันทึกและขนาด)

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

แบนด์วิธของเครือข่ายระหว่าง Web Server, Application Server และ Database Server ขอแนะนำให้ใช้อย่างน้อย 1 Gbps สำหรับ Productionc และ DR environment สำหรับการทดสอบ environment คุณสามารถใช้แบนด์วิธ 100 Mbps แต่ถ้าเป็นไปได้ขอแนะนำให้ใช้ 1 Gbps ในทุก environment

แบนด์วิธของเครือข่ายระหว่างเว็บเซิร์ฟเวอร์และเครื่องไคลเอ็นต์ สำหรับอินเทอร์เน็ต (LAN network) ถ้าเป็นไปได้ขอแนะนำให้ใช้ 1 Gbps (Gigabit LAN) แต่คุณยังสามารถใช้อย่างน้อย 100 Mbps

For Internet or WAN network เราแนะนำแบนด์วิธอินเทอร์เน็ตอย่างน้อย 10 Mbps สำหรับการใช้งานปกติ (ไม่เกิน 50 ช่องข้อมูลต่อ 1 แบบฟอร์ม/หน้า) หากแอพพลิเคชันของคุณมีข้อมูลมากกว่า 50 ช่องหรือมีรูปภาพมากกว่า 3 ภาพต่อ 1 แบบฟอร์ม/หน้า คุณควรเพิ่มแบนด์วิธอินเทอร์เน็ตเพื่อให้สัมพันธ์กับข้อมูลของคุณ ในการคำนวณแบนด์วิธที่คุณควรมี เราควรพิจารณาจาก 10 Mbps + ขนาดข้อมูลเพิ่มเติมของคุณ (ฟิลด์ข้อมูลที่มากกว่า 50 ฟิลด์และรูปภาพเพิ่มเติมหรือไฟล์แนบของคุณ)

Standalone Architecture เรียบง่าย บำรุงรักษาง่าย และประหยัดงบประมาณมากที่สุด สถาปัตยกรรมนี้เหมาะสำหรับระบบที่มีความสำคัญน้อยซึ่งสามารถยอมรับการหยุดทำงานบางส่วนเพื่อกู้คืนหรืออัปเกรดระบบ สถาปัตยกรรมนี้มีส่วนประกอบ 3 ระดับซึ่งประกอบด้วย Web Tier, Application Tier และ Database ดังแสดงในแผนภาพต่อไปนี้

Web tier ระดับนี้ใช้เพื่อรับคำขอจากไคลเอ็นต์หรือโหลดบาลานเซอร์ จากนั้นประมวลผลคำขอเนื้อหา Static content และส่งต่อคำขอตรรกะทางธุรกิจไปยังเซิร์ฟเวอร์แอพพลิเคชันในระดับแอพพลิเคชัน

Application tier ระดับนี้ใช้เพื่อประมวลผลคำร้องของไคลเอ็นต์ โดยใช้ Application Server Middleware

Database tier ระดับนี้สำหรับบันทึกข้อมูลลงในอุปกรณ์จัดเก็บข้อมูล

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

Monitoring in ONEWEB

ONEWEB ใช้ ELK stack สำหรับตรวจสอบโครงสร้างพื้นฐานของคลาวด์รวมถึง platform services.

Cloud Architecture เป็นอีกวิธีหนึ่งในการโฮสต์แอพพลิเคชันของคุณ บนผู้ให้บริการระบบคลาวด์ สถาปัตยกรรมประเภทนี้มีประโยชน์มากมาย เช่น ต้นทุนการบำรุงรักษาเซิร์ฟเวอร์ที่ต่ำกว่า ต้นทุนการลงทุนด้านฮาร์ดแวร์ที่ต่ำกว่า เป็นต้น หากคุณกำลังมองหาระบบคลาวด์โซลูชั่นคลาวด์มีตัวเลือกมากมายเช่น PaaS (Platform as a Service), IaaS (Infrastructure as a Service), และ SaaS (Software as a Service) ONEWEB สามารถโฮสต์บนคลาวด์เป็นโซลูชัน PaaS หรือ SaaS ได้ตามความต้องการของลูกค้า

ONEWEB สามารถตั้งค่าเป็นการกำหนดค่า ที่แตกต่างกันตามความต้องการของลูกค้า ลูกค้าสามารถเลือกผลิตภัณฑ์ที่ต้องการรวมอยู่ในการสมัครสมาชิก

8GB RAM เป็นขนาดหน่วยความจำขั้นต่ำสำหรับ development environment

16GB RAM เป็นขนาดหน่วยความจำขั้นต่ำที่แนะนำสำหรับ environment การใช้งานจริง และรองรับผู้ใช้ที่ใช้งานอยู่สูงสุด 500 คน

32GB RAM เป็นขนาดหน่วยความจำขั้นต่ำที่แนะนำสำหรับ environment การใช้งานจริง และรองรับผู้ใช้ที่ใช้งานอยู่สูงสุด 1,500 คน

เพื่อความแม่นยำยิ่งขึ้น ควรคำนึงถึงความซับซ้อนของแอพพลิเคชันและธุรกรรมของคุณด้วย

ONEWEB มี 3 องค์ประกอบหลัก

Web Server Web Server ต้องการพื้นที่ดิสก์อย่างน้อย 2 GB ทั้งนี้ขึ้นอยู่กับเว็บเซิร์ฟเวอร์ที่คุณใช้ โปรดตรวจสอบกับเว็บไซต์ของพวกเขา

Application Server Application Server มี 2 ส่วนที่ต้องพิจารณาเกี่ยวกับพื้นที่ดิสก์

Middleware (Application Server) : ขึ้นอยู่กับว่า Application Server ใดที่คุณใช้ สำหรับกรณีทั่วไป คุณควรมีพื้นที่ว่างในดิสก์อย่างน้อย 5 GB สำหรับส่วนนี้ สำหรับขนาดที่ถูกต้อง โปรดตรวจสอบกับเว็บไซต์ทางการของ Application Server ของคุณ

ONEWEB binary :คือ Application ที่ทำงานบน Application Server ประกอบด้วย App Designer, App Runtime, Process Designer, Process Runtime, Page Designer, Page Runtime, Microflow Designer, Microflow Runtime, AppSpace และอื่นๆเป็นต้น ต้องการพื้นที่ดิสก์อย่างน้อย 2 GB

Database Server ONEWEB ต้องการฐานข้อมูลเชิงสัมพันธ์เพื่อจัดเก็บข้อมูลการกำหนดค่าและธุรกรรม พื้นที่ดิสก์สำหรับซอฟต์แวร์ฐานข้อมูลมักต้องการอย่างน้อย 2 GB แต่คุณต้องตรวจสอบกับเว็บไซต์ของพวกเขาเพื่อความแน่ใจ อีกส่วนหนึ่งของฐานข้อมูลคือข้อมูล ONEWEB และข้อมูลธุรกรรมของคุณ ข้อมูล ONEWEB ต้องการอย่างน้อย 200 MB และข้อมูลการทำธุรกรรมขึ้นอยู่กับการใช้งานของแอพพลิเคชัน

คุณต้องพิจารณาประเภทของ environment ที่คุณต้องมีเมื่อต้องการพัฒนาแอพพลิเคชันอันดับแรก คุณสามารถพัฒนาแอพพลิเคชันของคุณบนเครื่องของลูกค้าได้ เมื่อคุณทำงานเสร็จแล้ว จะต้องมีการทดสอบ เพื่อสิ่งนั้น คุณควรมี environment ในการทดสอบ หากแอพพลิเคชันของคุณทำงานได้ดีใน environment ของการทดสอบ และคุณมีความมั่นใจที่จะเผยแพร่ คุณต้องโปรโมตแอพพลิเคชันของคุณใน environment production หากคุณต้องการให้ธุรกิจมีความต่อเนื่อง คุณอาจต้องใช้ Disaster Recovery เป็นแผนสำรองในกรณีที่ environment production ของคุณประสบปัญหาบางอย่าง นี่เป็นสถานการณ์ที่พบบ่อยที่สุดในการพัฒนาแอพพลิเคชัน

Production Environment

ประเภทการใช้งาน (Type of your Application) เป็นแอพพลิเคชันแบบเรียลไทม์หรือไม่ มีการรวมเข้ากับระบบอื่นหรือไม่ ต้องประมวลผลข้อมูลจำนวนเท่าใด มันทำงาน 24 ชั่วโมงต่อวันหรือไม่

ประเภทของธุรกิจ (Type of your Business) ธุรกิจของคุณมีความสำคัญแค่ไหน ใครจะได้รับผลกระทบหากแอพพลิเคชันนี้ล่ม จำนวนของผู้ใช้ (Active user and Name user)

จำนวนผู้ใช้ (ผู้ที่ใช้งานอยู่และผู้ใช้ชื่อ)

จำนวนธุรกรรม (Number of Transactions) จำนวนธุรกรรมภายในระยะเวลาหนึ่ง เช่น จำนวนธุรกรรมในหนึ่งเดือน

ยอมรับการหยุดทำงาน (Accepted downtime) จำนวนเวลาหยุดทำงานในหนึ่งปี และเวลาที่หยุดทำงานที่ยอมรับแต่ละครั้งนานเท่าใด

Disaster Recovery Environment

Disaster Recovery Environment เป็นสิ่งแวดล้อมสำรองสำหรับ environment production ของคุณและไม่สามารถดำเนินการได้เป็นระยะเวลานาน ในการออกแบบ Disaster Recovery Environment คุณต้องพิจารณาประเด็นต่อไปนี้

• RPO (Recovery Point Objective) จำนวนข้อมูลของคุณจะหายไป เมื่อคุณตัดสินใจเปิด Disaster Recovery Environment

• RTO (Recovery Time Objective) ใช้เวลานานเท่าใดเมื่อคุณตัดสินใจเปิด Disaster Recovery Environment

• คุณคาดว่าจะใช้กำลังการผลิต production environment กี่เปอร์เซ็นต์ใน environment การกู้คืนจาก Disaster Recovery Environment

Testing Environment

การทดสอบ environment ใช้สำหรับทดสอบแอพพลิเคชันในการออกแบบการทดสอบ environment คุณต้องพิจารณาประเด็นต่อไปนี้

• มีผู้ทดสอบหรือผู้ที่เกี่ยวข้องกี่คน ที่คุณวางแผนที่จะใช้ในการทดสอบ environment

• คุณต้องรวมเข้ากับระบบกี่ระบบ?

• คุณวางแผนที่จะใช้ข้อมูลเท่าใด ในกระบวนการทดสอบ

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

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

TCP/IP Network จำเป็นต้องมีเครือข่าย TCP/IP สำหรับ ONEWEB เครื่องไคลเอ็นต์ เว็บเซิร์ฟเวอร์ เซิร์ฟเวอร์แอพพลิเคชันเซิร์ฟเวอร์ฐานข้อมูล และ Load Balancer ทั้งหมดสื่อสารกันโดยใช้เครือข่ายนี้ ติดตั้งอะแดปเตอร์เครือข่ายอย่างน้อยหนึ่งตัวในคอมพิวเตอร์แต่ละเครื่องที่ใช้งาน ONEWEB

Load balancing จำเป็นเมื่อใช้เว็บเซิร์ฟเวอร์หรือเซิร์ฟเวอร์แอพพลิเคชันตั้งแต่สองตัวขึ้นไปสำหรับการเรียกใช้ ONEWEB ในการกำหนดค่าคลัสเตอร์ สามารถใช้โหลดบาลานซ์ฮาร์ดแวร์หรือซอฟต์แวร์ก็ได้

ไฟร์วอลล์ (Firewall) ONEWEB รองรับไฟร์วอลล์เพื่อเพิ่มความปลอดภัยของคุณ สามารถใช้ได้ทั้งฮาร์ดแวร์หรือซอฟต์แวร์ไฟร์วอลล์ ไฟร์วอลล์ที่แนะนำในสถาปัตยกรรม ONEWEB แสดงอยู่ในรูปภาพด้านล่าง

ไฟร์วอลล์ระหว่างอินเทอร์เน็ตและโซน DMZ ได้รับการแนะนำมากที่สุดในการปกป้องแอพพลิเคชันและเครือข่ายของคุณจากอินเทอร์เน็ต ไฟร์วอลล์ระหว่าง DMZ Zone และ Internal Network Zone เพื่อปกป้อง local network นของคุณเป็นชั้นที่สองจากอินเทอร์เน็ต เนื่องจากนโยบายความปลอดภัยเครือข่ายบางอย่างอาจต้องการไฟร์วอลล์เพิ่มเติมระหว่าง Application Server และ Database Server ONEWEB ยังสนับสนุนกรณีดังกล่าว แต่บางกรณีอาจต้องปรับพารามิเตอร์นโยบายไฟร์วอลล์เพื่อป้องกันปัญหาการเชื่อมต่อฐานข้อมูล

SSL - ONEWEB รองรับ SSL/TLS โดยใช้คุณสมบัติ Application Server เช่น Wildfly ,JBoss EAO หรือ IBM WebSphere Application Server คุณสามารถกำหนดค่า SSL Certificate ได้ที่ Application Server ซึ่งโดยทั่วไปจะรองรับ Self Sign Certificate หรือ Certificate จาก CA

Git Server ในการจัดการซอร์สโค้ดที่ปรับแต่งได้เพื่อให้ทีมสามารถปรับแต่งและทำงานร่วมกันได้เราขอแนะนำให้ใช้ Git ทำหน้าที่เป็นพื้นที่เก็บข้อมูลและระบบควบคุมเวอร์ชั่น คุณสามารถใช้เซิร์ฟเวอร์ Git ใดๆ เพื่อควบคุมเวอร์ชันบนคลาวด์หรือในเครื่อง

Eclipse ในการปรับแต่งแอพพลิเคชันที่ออกแบบโดย ONEWEB คุณต้องใช้เครื่องมือ Eclipse เป็นตัวแก้ไขโค้ดสำหรับโค้ดที่กำหนดเอง หากต้องการดาวน์โหลด eclipse โปรดไปที่ https://www.eclipse.org/downloads/packages/ จากนั้นเลือก Eclipse IDE for Java EE Developers. ขอแนะนำให้ใช้ Mars Version หรือใหม่กว่ากับ JAVA เวอร์ชั่น 8

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

ฐานข้อมูลที่รองรับ (Supported Databases) ด้านล่างเป็นเซิร์ฟเวอร์ของฐานข้อมูลที่รองรับ

Oracle 11g or later , PostgreSQL 9.6 or later only a sample name., MySQL 5.6 or later

DB2 10.5 or later , MS SQL Server 2012 or later, MariaDB 10.1.22 or later, Tibero 6.0 or later

สคีมา (Schemas) ONEWEB ต้องการสคีมาฐานข้อมูล 8 รายการสำหรับข้อมูลการกำหนดค่า ONEWEB และ 2 สคีมาสำหรับข้อมูลธุรกรรมของคุณ

ONEWEB กำหนดค่าสคีมาข้อมูลดังต่อไปนี้ eaf_master การจัดเก็บข้อมูล การกำหนดค่า AppDesigner erp_oneweb เพื่อจัดเก็บข้อมูลธุรกรรม AppDesigner ONEWEB สามารถใช้ชื่อสคีมาใดก็ได้ นี่เป็นเพียงชื่อตัวอย่างเท่านั้น pd การจัดเก็บ ProcessDesigner และการกำหนดค่า Microflow page การจัดเก็บการกำหนดค่า PageDesigner bpm เพื่อจัดเก็บข้อมูลการประมวลผลธุรกรรม asp เพื่อจัดเก็บการกำหนดค่าAppSpace dpc เพื่อจัดเก็บการกำหนดค่า Deployment Center iam2 เพื่อจัดเก็บข้อมูลผู้ใช้และข้อมูลการอนุญาตสำหรับ IAM dashboard_widget เพื่อจัดเก็บการกำหนดค่าแดชบอร์ดวิดเจ็ต survey_rabbit สำหรับจัดเก็บการกำหนดค่าการสำรวจ

Tablespaces เราแนะนำให้แยกพื้นที่ตารางด้วยอย่างน้อยหนึ่งสคีมาต่อหนึ่งพื้นที่ตาราง

สำหรับแนวทางปฏิบัติที่ดีที่สุด เราขอแนะนำให้แยกพื้นที่ตารางสำหรับข้อมูลและพื้นที่ตารางสำหรับดัชนีเพื่อให้ได้ประสิทธิภาพที่ดีที่สุด คุณปรับแต่งได้โดยทำตามเทคนิคเหล่านี้

• แยกพื้นที่ตารางสำหรับตารางข้อมูลธุรกรรมและตารางข้อมูลดัชนี

• แยกพื้นที่ตารางตามขนาดข้อมูลของตาราง

• วางไฟล์พื้นที่ตารางในฟิสิคัลดิสก์อื่น

Data Files เป็นไฟล์ฟิสิคัลของพื้นที่ตาราง พื้นที่หนึ่งตารางต้องมีไฟล์ข้อมูลอย่างน้อยหนึ่งไฟล์ สำหรับการออกแบบไฟล์ข้อมูล โปรดปรึกษา DBA ของคุณ

ข้อกําหนดฮาร์ดแวร์ (Hardware Specification)

CPU: x86-64 (Intel or AMD) 1.5 GHz or faster Processor RAM: 8 GB or higher

ข้อกําหนดซอฟต์แวร์ (Software Specification)

OS:

Windows: Windows 8 or Windows 10 Linux: Ubuntu 16.04.3 LTS or Later MacOS: OS 10.10 or Later

Web browsers: Google Chrome 60 or higher Mozilla Firefox 57 or higher Microsoft Edge 40 or higher

ด้านล่างนี้เป็นข้อกำหนดของซอฟต์แวร์ในการติดตั้งและเรียกใช้ ONEWEB บนเครื่อง