ในช่วงตั้งแต่ปี 2023 ที่ผ่านมามีหลาย ๆ บริษัทได้เปิดรับสมัคร Power Platform Developer กันจำนวนไม่น้อยหรือแม้แต่พนักงานทั่วไปที่ไม่เคยมีความรู้เกี่ยวกับ Power Platform มาก่อนก็ได้หันมาสนใจเกี่ยวกับ Power App มากขึ้น สะท้อนให้เห็นว่า Power Apps มีการเติบโตมากขึ้นในประเทศไทยมากขึ้นเรื่อย ๆ
Quick Suggest
หากสนใจเรียนรู้เพิ่มเติม ขอแนะนำบทความ
ปัญหาที่มักพบเจอ ?
- กรณีที่ 1: มี 1 แอป
เมื่อต้องแก้ไขแอป ผู้ใช้จะไม่สามารถใช้งานแอปได้ชั่วคราว เพราะแอปตัวนั้นถูกปิดไว้ระหว่างแก้ไข
- กรณีที่ 2: แยกเป็น 2 แอป คือ
- แอปสำหรับพัฒนา (developer)
- แอปสำหรับใช้งานจริง (production)
ปัญหาคือ:
2.1. ต้องอัปเดตการเปลี่ยนแปลงให้ทั้ง 2 แอป ทำให้ยุ่งยากและเสี่ยงผิดพลาด
2.2. ถ้าแก้แอปพัฒนา แต่ลืมแก้แอปใช้งานจริง โค้ดทั้ง 2 แอปจะไม่เหมือนกัน อาจเกิดปัญหาต่างกัน
สรุปง่าย ๆ คือ แอปตัวเดียวเมื่อแก้ไขผู้ใช้ไม่สามารถใช้งานชั่วคราว ส่วนแอปสองตัวต้องคอยจัดการให้ดี ไม่อย่างนั้นภายหลังจะเกิดปัญหาโค้ดไม่ตรงกัน และทำให้เกิดความยุ่งยากในการทำงานมากขึ้น ซึ่งปัญหาเหล่านี้มักเกิดขึ้นเมื่อไม่ได้ทำตามหลัก ALM ที่ดี
Power Platform ของ ALM คืออะไร ?
ALM หรือ Application Lifecycle Management คือ หลักการในการพัฒนาแอปพลิเคชันอย่างเป็นระบบ ช่วยให้การจัดการ ดูแล แก้ไข App ได้อย่างมีประสิทธิภาพในระยะยาว เพื่อไม่ให้เกิดปัญหาภายหลัง ซึ่งในส่วนของ Power Platform ก็มีเครื่องมือที่ออกแบบมาเพื่อสนับสนุนการทำ ALM เช่นกัน นั่นก็คือ Solution
แต่ไม่ต้องเป็นกังวลไป หากคุณเป็นมือใหม่ในการสร้าง App หรือเพิ่งเริ่มใช้ Power Platform แต่เมื่อไหร่ที่ App ของคุณมีเริ่มมีหลาย ๆ ตัวหรือมีความซับซ้อนขึ้น คุณจำเป็นที่ต้องใช้มันเพื่อให้การสร้าง App มีประสิทธิภาพมากขึ้น
Environment บน Power Platform
ในการพัฒนา Application บน Power Platform นั้นจำเป็นต้นแยก Environment ออกเป็นส่วน ๆ เพื่อให้สามารถดูแลได้ง่าย ซึ่งโดยทั่วไปจะแบ่งเป็น 3 ส่วน ดังนี้
- 1. Dev Environment
สำหรับนักพัฒนาหรือคนสร้างแอปใช้ในการสร้าง แก้ไข และทดสอบแอปและโฟลว์ต่าง ๆ
- 2. Test Environment
สำหรับทดสอบแอปก่อนการนำไปใช้งานจริง โดยทีมทดสอบหรือผู้ใช้งานสามารถทดสอบได้ในสภาพแวดล้อมนี้ โดยนำแอปที่ทำเป็น Dev Environment มาติดตั้ง Test Environment เพื่อให้ผู้ใช้งาน (User, Tester) ทดสอบการใช้งาน ซึ่งบางทีจะถูกเรียกว่า UAT หรือ SIT หรือ QAS
- 3. Production Environment
Environment สำหรับการใช้งานจริงของแอปพลิเคชัน เมื่อแอปผ่านการทดสอบและพร้อมแล้ว ตัว App จะถูกนำมาติดตั้งที่ Production Environment และผู้ใช้งานระบบจะใช้งานแอปพลิเคชั่นผ่านตัวแอปที่อยู่บน Environment นี้
และ User, Permission และข้อมูลของทั้ง 3 Environment จะถูกแยกกันอย่างเด็ดขาด เพื่อไม่ให้เกิดปัญหาภายหลัง เช่น เมื่อ Dev Environment เกิดปัญหาระหว่างพัฒนาก็จะไม่ส่งผลกระทบต่อการใช้งานของผู้ใช้งานบน Production Environment อีกทั้งยังช่วยให้นักพัฒนาสามารถแก้ไขและทดสอบแอปให้มั่นใจเสียก่อนที่จะนำมาขึ้นบน Production Environment ทำให้การทำงานของแต่ละฝ่ายมีความสะดวกและเป็นระบบขึ้นนั่นเอง
คำถาม ?
Q: ถ้าเรามี 5 แอป 20 Flow และต้องการนำแอปที่ Dev Environment ไปติดตั้งที่ Test Environment หรือ Production Environment เราจะต้อง Export หรือ Import ทีละอันใช่ไหม
A: ในส่วนนี้เราต้องใช้ Solution เข้ามาช่วย…
Solution คืออะไร ?
หากจะพูดง่าย ๆ เหมือนตอนที่เราต้องการจะย้ายบ้าน Solution ก็เหมือนกล่องใบใหญ่ที่เราสามารถใส่ App, Flow, Table หรืออื่น ๆ ไว้ข้างใน เมื่อต้องการนำแอปพลิเคชันไปติดตั้งที่สภาพแวดล้อมอื่น เช่น Test หรือ Production เราก็เพียงแค่นำกล่อง Solution ทั้งใบไปติดตั้งที่นั่น ไม่ต้องย้ายทีละชิ้นทีละอย่าง ทำให้สะดวกและไม่ลืมองค์ประกอบใดๆ หลงเหลืออยู่ เหมือนเราเคลื่อนย้ายบ้านใหม่ แค่ย้ายกล่องใหญ่ ๆ ไปก็จบ ไม่ต้องแยกย้ายทีละชิ้น ดังนั้น Solution จึงช่วยให้การจัดการแอปพลิเคชันและการเคลื่อนย้ายระหว่างสภาพแวดล้อมง่ายและสะดวกมากขึ้น เหมือนใส่ทุกอย่างลงในกล่องเดียวกันนั่นเอง
และวันนี้ผมจะมาลองสร้าง Solution บน Power Platform ซึ่งผมจะเน้นจุดสำคัญที่คนทั่วไปสามารถใช้ได้นะครับ
- Display Name – ชื่อ Solution ที่แสดง สามารถแก้ไขได้ภายหลัง
- Name – ชื่อภายในระบบ (ไม่สามารถแก้ไขได้ภายหลัง)
- Publisher – ระบุผู้สร้าง/ผู้รับผิดชอบ Solution
- Display Name ชื่อผู้สร้าง เช่น ชื่อบุคคล บริษัท หรือทีม
- Name ชื่อผู้สร้าง (ไม่สามารถแก้ได้)
- Description คำอธิบาย
- Prefix คำนำหน้าสำหรับตั้งชื่อ Object ภายใน Solution
- Version – เวอร์ชั่นเริ่มต้นของ Solution ตั้งเป็น 1.0.0.0 ก่อน
หลังตั้งค่าเรียบร้อย กดสร้าง Solution ใหม่ก็จะได้ Solution พร้อมใช้งาน
การตั้งค่าต่างๆ เหล่านี้ช่วยให้ Solution มีรายละเอียด ผู้รับผิดชอบ และการจัดการเวอร์ชันที่ชัดเจน ซึ่งจะทำให้การจัดการ Solution ทำได้ง่ายและมีประสิทธิภาพมากขึ้น
ส่วนประกอบของ Solution
เมื่อเข้ามาภายใน Solution ก็เปรียบเสมือนพื้นที่ภายในกล่องนั้นเอง ซึ่งเราสามารถสร้างทรัพยากรต่างๆ เช่น:
- App – เราสามารถสร้างแอปพลิเคชัน Power Apps ได้จากภายใน Solution นี้โดยตรง
- Flow – เราสามารถสร้าง Flow สำหรับกระบวนการอัตโนมัติได้
- Table – เราสามารถสร้างตารางข้อมูล (Table) ของ Dataverse ได้ภายใน Solution
กระบวนการสร้าง App และ Flow ก็เหมือนกับการสร้างทั่วไป แต่ทรัพยากรเหล่านั้นจะถูกเก็บไว้รวมกันภายใต้ Solution นี้
การทำงานภายใน Solution จึงเหมือนการจัดการและรวบรวมทรัพยากรต่างๆ ของแอปพลิเคชันไว้ในที่เดียวกัน เพื่อความสะดวกในการจัดการ เคลื่อนย้าย และนำไปติดตั้งในสภาพแวดล้อมอื่นๆ ได้อย่างเป็นระบบต่อไป
หรือถ้าคุณมี App หรือ flow ที่สร้างไว้อยู่แล้ว ก็สามารถกด Add existing แล้วดึงเข้ามาอยู่ภายใน Solution ได้เช่นกัน ซึ่งสิ่งที่อยู่ใน solution ผมเรียกว่า Object
ข้อควรระวังที่สำคัญสำหรับการทำงานกับ Solution
เนื่องจากทรัพยากรต่างๆ ในแอปพลิเคชันมักจะมีการเชื่อมโยงและอ้างอิงถึงกันอยู่ หากเรานำเฉพาะบางทรัพยากรเข้ามาอยู่ใน Solution อาจทำให้ขาดการเชื่อมโยงบางอย่างไป และส่งผลให้เกิดปัญหาได้ คือ ถ้าแอป My Awesome App เชื่อมโยงกับ Flow MAWEAPP – Flow Process A เราควรนำทั้งสองทรัพยากรนี้เข้ามาอยู่ใน Solution ด้วยกัน เพื่อรักษาการเชื่อมโยงไว้
ฟีเจอร์ Power Platform มีความสามารถที่ช่วยในการตรวจสอบความสัมพันธ์และการเชื่อมโยงของทรัพยากรต่างๆ ได้ โดยเราสามารถทำได้ง่ายๆ เพียงแค่คลิก “…” ที่ทรัพยากรนั้น แล้วเลือก “Advanced > Show Dependencies”
ระบบจะแสดงให้เห็นว่าทรัพยากรชิ้นนั้นเชื่อมโยงไปยังทรัพยากรอื่นๆ อะไรบ้าง ช่วยให้เราสามารถตรวจสอบและนำทรัพยากรที่เกี่ยวข้องเข้า Solution ได้ครบถ้วน
การใช้ฟีเจอร์นี้ร่วมกับการวางแผนอย่างรอบคอบจะช่วยป้องกันไม่ให้เกิดปัญหาการขาดการเชื่อมโยงหรือข้อผิดพลาดในขั้นตอนการนำ Solution ไปติดตั้งในสภาพแวดล้อมอื่นๆ ได้เป็นอย่างดี
อีกหนึ่งสิ่งสำคัญเมื่อนำแอปพลิเคชันไปติดตั้งบนสภาพแวดล้อมอื่น คือเราอาจต้องเปลี่ยนแปลงการตั้งค่าบางอย่าง เช่น
- แอปสำหรับการพัฒนา (Dev) ของเราจะเชื่อมต่อกับ SharePoint Site ชื่อ PowerSP
- แอปสำหรับการทดสอบ (Test) ของเราจะเชื่อมต่อกับ SharePoint Site ชื่อ PowerSP-PROD
ถ้าเราไม่ใช้ Environment Variable ทุกครั้งที่นำแอปไปติดตั้ง เราจะต้องค้นหาและเปลี่ยนการตั้งค่าเหล่านี้ด้วยตนเองทีละจุด ซึ่งผมไม่ต้องการทำแบบนั้น
แทนที่จะทำแบบนั้น ผมจะใช้ Environment Variable เพื่อช่วยให้ง่ายขึ้น โดยดำเนินการดังนี้:
1.สร้าง Environment Variable ที่เก็บชื่อ SharePoint Site ของเรา
- Display Name – ให้ตั้งชื่อตัวแปรให้เหมือนกับชื่อของ SharePoint Site ที่คุณต้องการเชื่อมต่อด้วย
- Data Type – เลือกประเภทข้อมูลเป็น “SharePoint” เนื่องจากตัวแปรนี้ใช้สำหรับเชื่อมต่อกับ SharePoint
- Connection – เลือกการเชื่อมต่อ ซึ่งปกติจะแสดงอีเมลของคุณ
- Parameter Type – เลือก “Site” เพราะตัวแปรนี้อ้างอิงถึง SharePoint Site
- Current site – เลือก SharePoint Site ที่คุณต้องการเชื่อมต่อด้วย
- Default site value – เลือก SharePoint Site เดียวกับข้อ 5
- กดปุ่ม “Save” เพื่อสร้างตัวแปรสภาพแวดล้อมสำหรับเชื่อมต่อกับ SharePoint Site
เมื่อทำตามขั้นตอนนี้เรียบร้อยแล้ว คุณก็จะมีตัวแปรสภาพแวดล้อมที่สามารถใช้อ้างอิงถึง SharePoint Site ของคุณได้
2.สร้าง Environment Variable ที่อ้างอิงถึง SharePoint List
เมื่อสร้าง Variable ที่อ้างอิงถึง SharePoint Site เรียบร้อยแล้ว ขั้นตอนต่อไปคือสร้าง Variable ใหม่สำหรับอ้างอิงถึง SharePoint List โดยมีรายละเอียดดังนี้:
Parameter Type – เลือก “List”
Site – เลือกชื่อ Site จากรายการ Variable ที่สร้างไว้ก่อนหน้า
Current list – เลือกชื่อของ SharePoint List ที่ต้องการ
Default list value – เลือกชื่อ List เดียวกับข้อ 3.
กด “Save”
เมื่อทำตามขั้นตอนนี้ คุณจะได้ Environment Variable ใหม่ที่เชื่อมโยงไปยัง SharePoint List ที่เลือก หากมี List หลายตัวที่ต้องใช้ ให้สร้าง Variable ใหม่ตามขั้นตอนเดียวกันจนครบทุก List
3.นำ Environment Variable ไปใช้
เรื่อง Environment Variable นี่ มันก็คือตัวแปรที่ใช้เก็บข้อมูลสำคัญๆ อย่างพวกรหัสผ่าน หรือคีย์สำคัญต่างๆ ไว้ แทนที่จะเอาไปแปะตรง ๆ ในโค้ดหรือแอป ซึ่งจะไม่ปลอดภัยนัก
พอเราตั้งค่า Environment Variable เรียบร้อยแล้วล่ะก็ ก็จะสามารถนำมันมาใช้งานกับแอปหรือโฟลว์ของเราได้ง่าย ๆ เลย
สำหรับใน Canvas App ตอนที่จะเลือก Data Source ให้ไปที่แท็บ Advanced ก็จะเจอรายชื่อ Environment Variables ที่เราตั้งค่าไว้ เลือกตัวที่ต้องการได้เลย เมื่อเลือกเสร็จแล้ว ถ้าจะเลือกรายละเอียดข้างในว่าอยากได้อะไร ก็แค่ไปแท็บ Advanced อีกที แล้วเลือกรายการที่ต้องการ ก็ใช้ข้อมูลจาก Environment Variable ได้แล้ว
ส่วนใน Power Automate Flow ถ้าเป็น Flow ที่อยู่ภายในโซลูชัน ตอนที่จะใส่ค่าต่างๆ ลงไป มันจะมีตัวเลือก Environment Variable ให้เลือกได้เลยจากกล่อง Dynamic Content ทำให้ใช้งานได้ง่ายมาก ๆ เลย
แบบนี้ละครับ ใช้ Environment Variable ได้ง่าย ๆ โดยไม่ต้องไปนำข้อมูลสำคัญ ๆ มาแปะไว้ตรง ๆ ทำให้ปลอดภัยและสะดวกกว่าเยอะ
การ Export Solution
เมื่อเราพัฒนาแอปพลิเคชันจนเสร็จสมบูรณ์และพร้อมที่จะนำไปใช้งานจริงหรือทดสอบแล้ว ขั้นตอนสำคัญต่อไปคือการนำแอปหรือ Solution นั้นไปติดตั้งบนสภาพแวดล้อมหรือ Environment อื่นๆ นอกเหนือจากที่ใช้ในการพั ฒนา
ในขณะนี้ Solution ของคุณอยู่ใน Environment ที่ชื่อว่า “Development” ซึ่งเป็น Environment ที่ใช้สำหรับการพัฒนาเท่านั้น ไม่ได้ถูกออกแบบมาให้เป็นสภาพแวดล้อมสำหรับการใช้งานจริงหรือการทดสอบระบบ
ดังนั้น หากต้องการนำแอปหรือ Solution ไปทดสอบหรือใช้งานใน Environment อื่นๆ เช่น Test Environment หรือ Production Environment ขั้นตอนแรกที่จำเป็นต้องทำคือการ “Export” Solution ออกจาก Development Environment เสียก่อน
การ Export Solution จะช่วยให้คุณสามารถนำ Solution ไปติดตั้งบน Environment ต่างๆ ได้อย่างถูกต้อง เพื่อวัตถุประสงค์ในการทดสอบ หรือการใช้งานจริง
ขั้นตอนการ Export Solution มีดังนี้:
ไปที่แท็บ Overview ของ Solution แล้วเลือกปุ่ม Export
จากนั้นให้กด Publish แล้วกด Next
ระบบจะถามให้กำหนดเวอร์ชั่นสำหรับการ Export ครั้งนี้ โดยเวอร์ชั่นที่ระบุจะต้องมากกว่าหรือเท่ากับเวอร์ชั่นปัจจุบันของ Solution เท่านั้น ไม่สามารถถอยหลังไปใช้เวอร์ชั่นก่อนหน้าได้ ตัวอย่างเช่น ถ้าเวอร์ชั่นปัจจุบันคือ 1.0.0.0 ครั้งต่อไปต้องระบุเป็น 1.0.0.1 ขึ้นไป คุณสามารถกำหนดได้เองว่าจะขึ้นไปทีละ 1 หรือมากกว่านั้น การกำหนดเวอร์ชั่นแบบนี้ช่วยให้สามารถติดตามการเปลี่ยนแปลงได้อย่างเป็นระบบ
ขั้นตอนเหล่านี้เป็นสิ่งจำเป็นก่อนที่จะสามารถ Export Solution ออกมาได้ เพื่อนำไปติดตั้งบน Environment อื่นๆ ต่อไป
ส่วนตัวผมจะชอบตั้งแบบนี้
- ถ้าเป็นการแก้ไขเล็กๆน้อย ๆ ไม่มีการแก้ process หรือแก้ฟีเจอร์ใด ๆ ผมจะขยับเลขหลักสุดท้าย (X.X.X.X+1) เช่น จาก 1.2.3.4 เป็น 1.2.3.5
- ถ้าเป็นการแก้ไขฟีเจอร์การทำงาน แต่ process ยังเหมือนเดิม จะขยับเลขหลักที่ 3 (X.X.X+1.0) เช่น จาก 1.2.3.4 เป็น 1.2.4.0
- ถ้าเป็นการแก้ไขที่กระทบ process จะขยับเลขหลักที่ 2 (X.X+1.0.0) เช่น จาก 1.2.3.4 เป็น 1.3.0.0
- ถ้าเป็นการแก้ไขที่กระทบ process แทบทั้งหมดจะขยับเลขหลักที่ 1 (X+1.0.0.0) เช่น จาก 1.2.3.4 เป็น 2.0.0.0
การ Export ข้อมูลเป็นเรื่องสำคัญมาก
Solution มีอยู่ 2 ประเภท โดยที่เราทำมาทั้งหมดจนถึงตอนนี้คือ Unmanaged solution แต่ตอน Export จะมีให้เลือก 2 ประเภท ได้แก่ Managed และ Unmanaged ซึ่งแบ่งตามการใช้งานดังนี้ (ซึ่งผมแนะนำให้ทำแบบเดียวกับผม)
การนำไปที่ Test หรือ Production environment ให้เลือกเป็น Managed นั่นก็เพราะว่า Managed solution นั้นจะไม่อนุญาตให้มีการแก้ไขโค้ดหรือ flow ใดๆ ของ object ที่อยู่ภายใน ทำให้เรามั่นใจได้ว่าตัวแอปของเรานั้นเหมือนกับตัวที่อยู่บน Dev environment แน่นอน
ถ้าหากเราต้องมีการอัพเดทหรือแก้ไขใด ๆ จะเป็นการ Export จาก Dev แล้วนำไป Import เพื่ออัพเดท
เราจะไม่มีการแก้โค้ดใดๆ ที่ Production เด็ดขาด ไม่มี ห้ามมี และไม่ควรมี
หลังจาก Export เสร็จ เราจะสามารถ Download ออกมาเป็นไฟล์ zip โดยไฟล์นี้แหละคือ solution ของเรา
การ Import Solution
หลังจากที่เราได้ไฟล์ zip ของ solution มาแล้ว เราจะนำไปติดตั้งที่ environment ปลายทาง ซึ่งอาจจะเป็น Test หรือ Production
1. เลือกไปที่ Environment ที่ต้องการ
2. มาที่เมนู Solution แล้วกด Import solution
3. กด Browse เลือกไฟล์ zip ของ solution เสร็จแล้วกด Next
4. ตรวจสอบ connection หากมีตัวไหนขึ้นให้ทำการ login ให้เรียบร้อย แล้วกด Next
5. เปลี่ยนค่าของ Environment Variable ของเรา
โดยอย่างที่ผมสร้างไว้จะมี 2 ตัว ผมก็แค่ทำการเปลี่ยนให้ไปเชื่อมโยงกับ SharePoint Site และ List ที่ผมต้องการ
แทนที่ผมจะต้องเปลี่ยนทุก ๆ จุดทั้งในแอปและใน flow ผมเปลี่ยนที่นี่ที่เดียว
6. กด Import ได้เลย
บางครั้งมันอาจจะขึ้นข้อความตัวสีแดงมาฟ้องว่า You do not have access… ไม่ต้องสนใจครับ
หลังจาก Import เสร็จสิ้น คุณจะเห็น Solution ของคุณปรากฏขึ้น พร้อมกับทุก ๆ object ที่อยู่ภายใน
โดย object ที่อยู่ภายใน Managed Solution จะไม่สามารถแก้ไขได้
การอัปเดตแอป
ทุกๆ Object ที่อยู่ใน Managed solution จะไม่สามารถแก้ไขได้ แต่หากคุณต้องการแก้ไขหรืออัปเดตตัวแอปเพิ่มเติม สามารถทำได้โดยการที่คุณต้องแก้ไขตัวแอปที่ Dev environment ให้เรียบร้อย แล้วทำขั้นตอนเดิม คือการ Export และนำมา Import เหมือนเดิมเลยครับ
ระบบของ Solution จะจัดการให้คุณทั้งหมด หากคุณมีการลบ object ใดๆ ออกจากที่ต้นทาง เมื่อนำมา Import ระบบก็จะลบออกที่ปลายทางให้ด้วย (เฉพาะกรณี Export เป็น Managed Solution) ดังนั้นมั่นใจได้เลยว่าที่ Dev กับ Production จะเหมือนกัน 100% ไม่มีเซอร์ไพรส์
บทสรุป
การใช้ Solution จะช่วยลดขั้นตอน manual ที่คุณต้องดำเนินการในการอัปเดตแอปแต่ละครั้ง การทำครั้งแรกอาจจะกินเวลาสักหน่อย แต่ครั้งถัดๆ ไปไม่ว่าแอปของคุณจะมี Object ภายในจำนวนมากแค่ใด คุณก็สามารถ Deploy ได้ภายในไม่กี่คลิก อีกทั้งยังทำให้การพัฒนาแอปเป็นไปตามขั้นตอน Application Lifecycle Management ที่ควรจะเป็น
เกี่ยวกับ Solution ยังมีรายละเอียดมากมายอีกพอสมควรที่ถัดไปจะเป็นระดับของ Intermediate – Advanced แล้ว ถ้ามีโอกาสจะมาแชร์ให้ทราบกันแน่นอนครับ
แหล่งที่มา : PAWIT.PW
ก้าวเข้าสู่ Digital Business
ดูผลิตภัณฑ์ที่เกี่ยวข้องได้ที่นี่
