รวมบรรยากาศและสรุปเนื้อหาในงาน LINE Thailand Developer Conference 2019
#LINEDEVCONF2019
สวัสดีท่านผู้อ่านทุกท่าน ผู้เขียนได้มีโอกาสไปงาน LINE Thailand Developer Conference 2019 เมื่อวานนี้ (25 พฤษภาคม 2019) ก็ได้รับสิ่งใหม่ ๆ มาเยอะมาก จึงอยากมาแชร์ให้ท่านผู้อ่าน จะแชร์ให้มากเท่าที่ทำได้นะครับ
หัวข้อและกำหนดการ
ผู้เขียนจะแบ่งเป็นหัวข้อการเดินทาง, การลงทะเบียน และบูทกิจกรรม จากนั้นจะไล่ไปแต่ละหัวข้อตามกำหนดการของงาน สามารถคลิกที่หัวข้อข้างล่างนี้ เพื่อไปยังเนื้อหาครับ
เนื่องจากว่าช่วงบ่าย จะแยกเป็น 2 Hall ในช่วงเวลาเดียวกัน ผู้เขียนจะเขียนเฉพาะ Hall ที่เข้า แต่จะยังคงหัวข้อและชื่อ Speaker แต่ละท่านไว้นะครับ
- การเดินทาง
- ลงทะเบียน
- บูธกิจกรรม
- Registration (Coffee break provided)
- Welcome & Opening
- Keynote: What’s new in LINE Platform & LINE API Ecosystem Overview
- Catching up new features of LINE API with 100% live demonstration
- Lunch Break
- HALL A — How LINE using LIFF in e-Commerce
- HALL B — How LINE ScaleUp help Startup to be a Unicorn
- HALL A — LINE Things: Connecting the Unconnectable
- HALL B — Enhance Customer’s Payment Experience with Rabbit LINE Pay API
- HALL A — Handle a Huge Traffic of Messages with HBase
- HALL B — SCB Connect inside Banking Infrastructure
- Coffee Break
- HALL A— Micro Frontend: The New Era of Frontend Edge Technology
- HALL B — AutoML in Chatbot Builder Framework
- HALL A — Live Coding a Chatbot
- HALL B — Monetizing in LINE API Platform
- Closing
การเดินทาง
สำหรับการเดินทางมา BITEC Bangna นี้ ถือว่าสะดวกเพราะอยู่ใกล้ทางด่วนและติดกับ BTS สถานีบางนา ไม่ว่าจะมารถส่วนตัว หรือรถสาธารณะก็สบายใจได้
ผู้เขียนเดินทางมาด้วย BTS เมื่อลงสถานีแล้วก็เดินมาเรื่อย ๆ จะพบกับทางเชื่อมเข้าอาคาร BITEC ครับ
เมื่อเข้ามาในอาคารแล้ว ผู้เขียนก็มองหาป้าย Events today พบว่าอยู่ที่ Zone GH201-GH203 ครับ ลุย !!
ลงทะเบียน
มาถึงที่งานแล้ว ทำการลงทะเบียนก่อนเลย ก็ราบรื่นดีครับไม่มีปัญหาอะไร สะดวกและรวดเร็ว
บูธกิจกรรม
งาน Conference วันนี้มีบูธกิจกรรมให้ร่วมสนุกด้วยนะ จะเปิดให้เข้ามาสอบถาม มาพูดคุยในช่วงเวลาพัก มีทั้งหมด 10 บูธด้วยกันดังนี้
- LINE Career
- LINE Things
- LINE Man
- LINE API Expert
- LINE Dev
- Rabbit LINE Pay
- LINE Shopping
- OA Plus e-commerce
- LINE Biz-Solutions
คนค่อนข้างเยอะครับ แต่ละบูธจะมี Stamp ให้ผู้เข้าร่วม Scan QR Code เมื่อครบ 10 บูธก็จะสามารถนำไปแลกเสื้อได้ครับ
Registration (Coffee break provided)
เปิดมาก็บริการให้ท้องอิ่มกันก่อนเลย แถมคุณภาพอาหารก็ดีด้วย ถือว่าใจปล้ำจริง ๆ ต้องนับถือในความใส่ใจของทีมงาน LINE Thailand Developer Conference นี้จริง ๆ
ส่วนตัวแล้วชอบกาแฟมาก ๆ มีความเข้มแต่ไม่มากเกินไป ดื่มง่าย นุ่ม สุดยอดครับ
Welcome & Opening
โดย คุณ Xinming Zhao: Head of Engineering at LINE Thailand
Speaker ท่านแรกคือ คุณ X ได้กล่าวต้นรับและกล่าวถึงการเติบโตของ LINE ซึ่งปัจจุบันมีผู้ใช้ LINE Application จำนวนกว่า 44 ล้าน Account โดยมีตัวเลขที่น่าสนใจอีกอย่างคือ 95% ของผู้ใช้ Smartphone ทั้งหมดบนโลกนี้ มี LINE Application อยู่ในเครื่อง !! ซึ่งการเติบโตนี้จริงอยู่ว่าถือเป็นโอกาสหลาย ๆ อย่างทางธุรกิจ แต่ก็เป็นความรับผิดชอบที่สำคัญอีกด้วย
คุณ X ก็กล่าวอีกว่ามีความรู้สึกยินดีที่ LINE Developers Group Thailand นั้นมีจำนวนผู้เข้าร่วมกว่า 8,000 คนแล้ว ซึ่งใน Group ก็มีการสนับสนุนช่วยเหลือกันอย่างดี ไม่ใช่แค่การช่วยเหลือโดยทีมงานเท่านั้น แต่ยังเห็น Developer ยังช่วยเหลือกันเองด้วย และยังกล่าวอีกว่าการช่วยเหลือ การแชร์กันนี่แหละ จะก่อให้เกิด Idea ใหม่ ๆ ทำให้วงการพัฒนาไปได้อย่างต่อเนื่อง
Keynote: What’s new in LINE Platform & LINE API Ecosystem Overview
โดย คุณ พฤทธิสิทธิ์ ประทีปะวณิช (Terry Prateepavanich) (เทอร์รี่): Team Lead Product and Platform Management at LINE Thailand
และ คุณ วริศ วรรณวิธู (Warit Wanwithu) (แทน): Developer Relations at LINE Thailand
และ คุณ จิรวัฒน์ กรัณย์วิทยาการ (Jirawatee) (ตี๋): Technology Evangelist at LINE Thailand (พี่ตี๋จะมาอีกรอบคือ Live Coding a Chatbot ด้วย)
LINE Redesign
เริ่มที่คุณเทอร์รี่ก่อน คุณเทอร์รี่พูดถึง Redesign ที่ผ่านมา และอธิบายเกี่ยวกับ Open Platform Timeline และ Road Map ของ LINE ว่าแต่ละช่วงเป็นอย่างไร มีอะไรใหม่
จากนั้นมีการโชว์หน้า Account Page และ Home Tap ที่มีการปรับเปลี่ยนใหม่ให้ดู
มีมุขดีดนิ้วด้วยนะครับ เกี่ยวกับการ Redesign ของ LINE นั้น ได้ทำลายข้อจำกัดที่นักพัฒนาส่วนใหญ่ไม่ชอบคือ เลข 50
ภาพรวมของ Redesign แต่ละจุดที่เด่น ๆ
- New มี CMS ที่มีประสิทธิภาพมากขึ้น
- Unify API มีการ Unlock 50 follower
- Scalability ส่วนของ Broadcast จาก 1,000 ปรับเป็น 100,000/min
- Availability มีความแข็งแรงมากขึ้น
การ Integration ที่ดีที่สุด คุณเทอร์รี่แบ่งไว้ 3 ข้อใหญ่ คือ
- Concept ทุกสิ่งทุกอย่างที่จะทำ ต้อง Focus ไปที่ User เพราะ User เป็นคนใช้ เป็นคนเรียกร้อง การจะพัฒนาเพื่อให้ชีวิต User ดีขึ้นจะต้องคำนึงถึง User First
- Experience เมื่อรู้ว่า User ต้องการอะไร เราก็ต้องดูว่า การตอบสนองความต้องการของ User ควรจะอยู่ในรูปแบบไหนดีที่สุด สะดวกสบายที่สุด ควรจะเลือก Msg Type ที่ดีในด้าน Experience ของผู้ใช้
- API หัวใจหลักก็คือการตอบกลับ มี 2 สิ่งที่ว่า แต่การตอบกลับไม่ดี ไม่ตรงจุดก็ไม่ Success
คุณเทอร์รี่ได้นำข้อมูลมาแสดงให้เห็นว่า App บนโลกที่ available มีทั้งหมด 4.6 ล้าน แต่ค่าเฉลี่ย App ที่อยู่ใน Smartphone จะอยู่ที่ 30 และใน 1 วันจะมี User ใช้ App บน Smartphone ของ User นั้นเพียง 7–9 App ทำให้เรามองเห็นว่าการทำธุรกิจบางอย่าง โดยเริ่มจากการสร้าง App อาจจะไม่ตอบโจทย์ตรงที่ต้องดึงให้ User เริ่มใช้ App ที่พัฒนามา ซึ่งแน่นอนว่าการลงทุนทั้งค่าใช้จ่าย และเวลาก็ไม่ใช่น้อย
จึงเป็นอีกทางเลือกที่ว่า หากมาใช้ Open platform ของ LINE ซึ่งมีเป็น Application ที่มีอยู่บน Smartphone ของ User เกือบทุกเครื่องอยู่แล้ว
LINE Ecosystem
ต่อไปในส่วนของคุณแทน จะกล่าวถึง LINE API ใน LINE Ecosystem ล่าสุดของปีนี้ ในหัวข้อต่าง ๆ ดังภาพด้านล่าง
- LINE Login
- LINE Notify
- Messaging API
- LIFF (LINE Front-End Framework)
- Rabbit LINE Pay
- LINE Things — LINE Beacon
- Social API
- Clova
LINE Login
ก็คือ Social login หากมีระบบอะไรซักอย่างที่จะต้องมีการลงทะเบียน เพียงแค่นำ LINE Login ไป Integrate ไม่ว่าจะ Website หรือ Mobile จะทำระบบเข้าถึงข้อมูลของ User ได้ เช่น รูป Profile, ชื่อ, Status message และ Email
ทำให้ User สะดวกในการ Login โดยสามารถกดปุ่มเดียวจบ ไม่ต้องกรอกข้อมูลอะไรมากมาย
LINE Notify
เป็นการแจ้งเตือนแบบ One-Way ซึ่งจะนำไป Integrate ที่ Web หรือ Mobile หรือแม้กระทั่ง IoT ก็ได้ ยกตัวอย่างหากมีระบบ E-commerce จากเดิมเราจะใช้การส่ง SMS หรือ Email ในการแจ้งเตือน ก็อาจใช้ LINE Notify เพิ่มเติมอีกช่องทางได้
ตัวอย่าง Application ที่คุณแทนทำมาคือ เป็นการเข้าไป Like รูป แล้วจะมี Notify แจ้งไปที่เจ้าของภาพ
Messaging API
และนี่คือพระเอกของจักรวาล ก่อนจะเริ่มพูดถึง คุณแทนก็มี VDO มาให้เรารับชมครับ
จาก VDO จะเห็นว่ามีสาว ๆ ชวนคุยกันว่าจะกินอะไรดี และมีสาวคนหนึ่งดึง Bot เข้ามาในกลุ่ม ก็มีการโต้ตอบกันเกิดขึ้น มีการ filter ว่าต้องการราคาเท่าไร อาหารประเภทอะไร และจบที่การจองร้านอาหารแห่งหนึ่ง
Chatbot สามารถช่วยนสนับสนุนได้หลายรูปแบบธุรกิจ มีข้อดีเข้าถึง User ที่มีอยู่แล้วได้เลย เป็นจำนวน 44 ล้าน User แถมยังใช้งานง่าย Lerning Cuve ต่ำ และข้อดีสำหรับการพัฒนา Software คือ เขียนทีเดียวรองรับมากกว่า 1 Platform
คุณแทนได้ยกตัวอย่าง LINE@ ที่มีผู้ใช้จำนวนมาก นั่นคือ LINE ดูดวง, Wongnai, SCB Connect ก็จะเห็นได้ว่า 3 ตัวนี้ มี Business ที่ต่างกัน
ส่วนการโต้ตอบระหว่าง Chatbot กับ User จะแบ่งเป็น Push และ Reply
การ Push จะหมายถึงการที่เราส่ง Promotion, ข้อความ เข้าสู่ห้องแชทไปหา User เลยโดยไม่ต้องมีการรับข้อความจาก User ก่อน
แต่การ Reply นั้นจะมี Step ดังภาพด้านล่าง นั่นคือ
อธิบายได้ดังนี้
- รับ Message หรือ Event จาก User (เช่น การพิมพ์ข้อความถาม, กด Rich Menu, การ Add Chatbot) เข้าไปที่ LINE Platform
- LINE Platform จะส่ง Events Webhook ที่เตรียมไว้ เพื่อนำไปประมวลผลต่าง ๆ ไปทำ Query database หรือ Machine learning
- ทำการ Reply เข้าสู่ LINE Platform
- LINE Platform จะตอบกลับไปหา User
Chatbot จะมี Tools ต่าง ๆ ที่ให้ใช้ คือ
- Rich Menu คือ Menu ที่อยู่ด้านล่าง หากเป็นก่อนหน้านี้จะมี 4–5 ปุ่มให้กด แต่พอเป็น API แล้วมีได้มากกว่า 20 จุด ทำ Personalize ได้ด้วย หมายความว่า User 2 คน สามารถเห็น Rich Menu ได้ต่างกัน
- Quick Reply สำหรับคำถามที่ Chatbot ถาม เราสามารถใส่ Quick Reply ได้ด้วย ทำให้ User ไม่ต้องพิมพ์เอง ตัวอย่างด้านล่าง (Modify prev, 1, 2, 3, 4, 5)
- Message Type และ Advanced Message Type คือ รูปแบบ Message ที่จะตอบกลับมีหลายแบบ แต่คุณแทนแยกให้เห็นว่าส่วนของ Advanced จะเป็นตัวที่ ChatBot ส่งได้แต่คนส่งไม่ได้
และตัวที่มีความสวยงามและสะดวกในการแก้ไข หรือเปลี่ยนแปลงที่เด่นชัดคือ Flex Message ซึ่งสามารถออกแบบได้อย่างอิสระ กำหนด X,Y จุดที่กดได้ ทำให้เป็นมิตรต่อ UX มาก ๆ แถมยังรองรับ Display ทั้ง Desktop App และ Mobile App
LIFF (LINE Front-End Framework)
คือ Web view ที่สามารถใส่ Web site ของผู้พัฒนาเข้าไปได้เลย โดยมันสามารถใช้ LINE API ได้ ทำให้ Get profile ของ User ได้ และ ส่ง Message กลับไปที่ห้องแชทได้อีกด้วย และการที่ทำเป็น Web ได้ แน่นอนว่าทำให้เพิ่มความสามารถได้อีกหลายทาง เช่น การทำเกมบนหน้า Web, การใช้ JavaScript เพื่อเพิ่มลูกเล่น หรือการแสดงสินค้าจำนวนมาก ๆ ก็จะทำสะดวกต่อ User
คุณแทนยกตัวอย่างการซื้อชานมไข่มุขที่ LINE Acount ของ KOI Thé ทางผู้เขียนจึงลองเล่นและนำมาแชร์ครับ
มี Events แห่งหนึ่ง แบ่งทีม User และให้เข้าไปที่ LIFF ตัวนั้น จากนั้นทำการเขย่าแข่งกัน โดยใช้ JavaScript เป็นตัวดักเก็บ Score
Rabbit LINE Pay
สำหรับการ Integrate สามารถทำได้ทั้ง Web และ Mobile ซึ่งมีความง่ายและปลอดภัย โดยตัว Rabbit LINE Pay นี้ สามารถจ่ายได้ทั้ง Wallet และบัตร Credit
LINE Things — LINE Beacon
- LINE Things สามารถใช้ LINE เชื่อมต่ออุปกรณ์ต่าง ๆ ได้ เช่น ต่อ IoT, เปิด-ปิดเครื่องใช้ไฟฟ้า หรือรับ Noti จากอุปกรณ์เหล่านั้นมาที่ LINE ก็ได้ จะเห็นว่าทาง LINE เริ่มไปทางอุปกรณ์บ้างแล้ว ไม่ใช่แค่ใน Desktop และ Mobile แต่ตอนนี้ LINE Things ยังเป็น Developer Trial อยู่ รออีกนิดนะครับ
คุณแทนเคยเขียน Blog เกี่ยวกับ LINE Things เอาไว้แล้ว สามารถอ่านเพิ่มเติมได้ที่
- LINE Beacon จะปล่อยสัญญาณออกมา เมื่อ LINE ได้รับ จะสามารถทำให้แสดง Banner เพื่อโฆษณา หรือ Promotion ได้ดังภาพ
คุณแทนได้นำตัวอย่างงาน NIKE GoBKK ที่ใช้ LINE Beacon มาให้ชมด้วยครับ
Social API
ตัวนี้จะคล้าย ๆ กับ LINE Login โดยสามารถ Get user profile ค่าที่ได้คือ รูป Profile, Status message, UserID ที่มีความ Unique ซึ่งเป็นคนละค่ากันกับ LINE ID
Clova
เป็น Speaker ของ LINE ซึ่งสามารถสั่งให้ส่งไลน์ไปหาเพื่อนได้ และมี SDK ให้เราเรียกใช้เพื่อเพิ่มความสามารถอีกด้วย แต่ปัจจุบันยังไม่เปิดให้ใช้ในประเทศไทย ตอนนี้ Support ที่ญี่ปุ่นและเกาหลีใต้อยู่ ต้องอดใจรออีกสักนิด
What’s new in LINE platform 2019
ต่อไปเป็นส่วนของคุณตี๋ เริ่มต้นกับสถิติที่น่าสนใจ นั่นคือจำนวน LINE Chatbot ในประเทศไทยที่ Active อยู่นั้นมีจำนวนกว่า 60,000 ตัว
ยิ่งไปกว่านั้น ใน 60,000 ตัวนี้ ไม่ใช่แค่ใน กทม. เท่านั้น แต่ว่ามีทั้ง เชียงใหม่ ขอนแก่น โคราช นนทบุรี นครปฐม และสงขลา กล่าวได้ว่ามีอยู่ทุกภาคของประเทศไทยกันเลยทีเดียว
และปัจจุบันมีหลายเจ้าที่มีความมั่นใจใน LINE Official ในปัจจุบันมีดังนี้ครับ
จากนั้นพี่ตี๋ก็ได้กล่าวต่อในแต่ละหัวข้อดังนี้
Messaging API
จากเดิมมีลิมิตของ Follower ที่ 50 คน สำหรับ LINE@ ทำให้เป็นอุปสรรค์ต่อการขึ้น Production แต่หลังจากเดือนมิถุนายน 2019 เป็นต้นไปนั้น มีข่าวดีมาก ๆ คือ LINE@ จะถูกย้ายไปใช้ Platform ของ LINE Official Account แบบ Plan free ทำให้รองรับ Follower ได้ไม่จำกัด ย้ายแบบอัตโนมัติ
และสำหรับใครที่ย้ายมา จะเปลี่ยนจากเดิมที่ไป Manage จาก LINE@ Manager ไปที่ LINE Official Account Manager ซึ่งตัวใหม่นี้ก็จะ Feature ที่มากกว่า อย่างเช่น เรื่องของ Demographic สามารถ Filter เพศ, สถานที่ของผู้ใช้ ทำให้ระบุ Target ได้ตรงจุดมากกว่าเดิม
Rich Menu
การ Set Personalized สำหรับ Rich Menu เพื่อให้ User แต่ละคนเห็นเมนูที่แตกต่างกัน จากเดิมการส่ง 1 Request จะรองรับ 1 user ID ทำให้ LINE Official Account ที่มี Follower เป็นหลักแสน จะมีปัญหาในการทำ Personalized อาจจะก่อให้เกิด Timeout
แต่ปัจจุบันถูกปรับให้สามารถส่ง user ID เป็นจำนวนสูงสุดที่ 150 ซึ่งจะทำให้ลด Request ไปได้มาก ๆ
Broadcast API
สมมติว่าตอนนี้เรามี Follower จำนวน 5,000 คน เราสามารถส่งครั้งเดียวแต่ได้รับทั้ง 5,000 คนได้ด้วย Broadcast API
พี่ตี๋เตือนว่า แต่ต้องใช้แบบระวัง เพราะมันมีผล UX ต่อ User
ปกติการส่ง Reply หรือ Push ผ่าน Broadcast ที่ตัว LINE Official Account จะส่งได้ 3 Bubbles แต่ถ้าหากเราส่งแบบ Request ในแบบ Developer จะสามารถส่งได้ถึง 5 Bubbles ได้เลย
1 Bubble คือ การส่ง 1 ครั้งในการตอบกลับแต่ละครั้งของ Bot เช่น ส่ง Message, Sticker หรือ Image
Destination Property
เดิมทีนักพัฒนาที่ทำ API ตัวเดียว เพื่อให้รองรับ Bot หลาย ๆ ตัว จำเป็นจะต้องส่งชื่อ Bot เพื่อให้รู้ว่า Bot ตัวไหนที่วิ่งเข้า API โดยการส่งผ่าน Query string แต่ปัจจุบันตัว Payload ที่ได้รับจาก Bot จะมี Property ที่ชื่อว่า Destination แล้ว ซึ่งจะมีค่าเป็น ID ของ Bot นั้น ๆ
ImageMap
ImageMap Message เป็น 1 รูปแบบที่ใช้กันค่อนข้างมาก เพราะเราสามารถแต่งรูปให้มันทำให้ดูสวยงาม ปัจจุบันถูกเพิ่มความสามารถให้ใส่ Video ลงไปบน ImageMap และเล่นเองได้ทันที แถมยังกำหนดจุด X, Y ได้เหมือนเดิมอย่างไม่มีปัญหา
New Webhook Events
ปีนี้มีเพิ่มมาอีก 2 Events คือ member Joined กับ memberLeft และเราสามารถเก็บ UserID เพื่อใช้งานได้ตั้งแต่จุดนี้ได้เลย
LINE Bot Designer
คือ Application มีให้ Download ทั้ง Mac และ Windows จะช่วยให้ Design หรือทำ Prototype ได้ง่ายขึ้นโดยการลากวางและตัว Application จะ Generate JSON มาให้ใช้และที่สำคัญ Support กับ Flex Message
ประเทศไทยมีการ LINE Application เป็นอันดับ 2 ของโลก แต่มีการใช้งาน LINE Bot Designer เป็นอันดับ 1 ของโลก
ว่าแล้วก็โหลดได้ที่ลิงค์ด้านล่างเพื่อครองอันดับหนึ่งกันต่อ
LIFF (LINE Front-End Framework)
สิ่งที่ช่วยเติมเต็ม Chatbot แต่จะมีความยากต่อการ Handle อยู่อย่างหนึ่งคือ 1 ในเงือนไขที่ LIFF ขอ คือขอส่ง Message กลับไปที่ห้องแชท ถ้า User ไม่ให้ มันจะไม่ขึ้นมาให้กดอีกเลย ทำให้เกิด Error เวลาที่ Developer จะส่ง Message กลับมาเพื่อจบ Business Logic วิธีแก้ที่ทำได้คือ แจ้งให้ User ทำตาม Step ซึ่งยากมาก
แต่ตอนนี้มันจะแจ้งเตือนทุกครั้งแล้ว ทำให้ชีวิต Developer สบายขึ้น
ปัจจุบัน LIFF Support iPad แล้ว
การเปิด LIFF จะสามารถ Get ข้อมูล User Profile ได้เลย แต่กรณีที่จะส่งไปที่หลังบ้าน มีหลาย ๆ Case ที่จำเป็นต้องส่งแบบ Raw text ซึ่งมันจะดีกว่าถ้ามีทางอื่น
แต่ปัจจุบันตัว LIFF สามารถ Get Access Token ได้แล้ว ซึ่งนำไปส่งต่อที่หลังบ้าน ทำให้หลังบ้านไป Get User Profile ได้แล้ว
และใน Step ต่อไปคือการประกาศที่แรกที่ไทย ยังไม่ได้ประกาศที่ไหนในโลก
…..
นั่นคือ LIFF 2.0 !! โดยมี Feature ใหม่ ๆ ดังนี้
- QR Code Scanner แต่เดิมการใช้ LIFF จะสามารถใช้ JavaScript ได้เกือบทุกอย่างแต่ไม่สามารถเปิดกล้องและ Scan QR Code ได้ แต่ใน Version นี้สามารถเปิด Scan ได้แล้ว
และนี่คือ request ที่ส่งเสียงดังผ่านทีมงาน LINE Thailand ทำให้ Global พัฒนา Feature มาให้
- Supported in desktop ก่อนหน้านี้หากอยากให้ Desktop ใช้ URL เดียวกันกับ LIFF กรณีที่จะ Get User Profile ต้อง Implement LINE Login แต่ LIFF 2.0 ไม่ต้องทำอะไรเลย จะใส่มาให้แล้ว
- Define scopes สามารถ Define ได้ เช่นเดียวกับ LINE Login
- Acquire friends แนะนำ Chatbot ได้ในขณะที่อยู่ในหน้าของ LIFF
- Get OS รู้ได้ว่าเป็น OS อะไร ทำให้เลือก Feature ได้อย่างเหมาะสม
- Is in LIFF ? รู้ได้ว่าเปิดใน LIFF หรือไม่
- Is Logged in ? รู้ได้ว่า Login อยู่หรือไม่
- More …
ตอนนี้ก็อยู่ในขั้นทดสอบอยู่ รออีกนิดนะครับ
LINE SDK v5.0
การมาของ LINE SDK v5.0 นี้ สำหรับ iOS ที่ใช้ภาษา Swift มี Library ให้ใช้แล้ว แต่ Object-C Version นี้จะ Support เป็น Version สุดท้าย
การมาของ LINE SDK 5.0 ตัว LINE Login และ Social API จะเป็น v2.1 ซึ่งจะสามารถกำหนด Scope และแนะนำ Chatbot ให้กับ User ผ่านตัว Bot Prompt ได้เลย
ส่วนของตัว Web ใครที่ใช้ LINE SDK อยู่แล้ว จะได้ Feature ใหม่ คือ QR Code Login เข้าไปอัตโนมัติ โดยไม่ต้องแก้ Code
LINE SDK 1.0 for Unity
สำหรับสายเกม ก็สามารถใช้ LINE Login ได้แล้วเช่นกัน
ต่อไปคือ 2 เรื่องสุดท้ายที่จะประกาศ ที่นี่เป็นที่แรก นั่นคือ
BUILDING LINE CHATBOT USING DIALOGFLOW
เป็นคอร์สเรียนฟรีที่เปิดให้บริการเรียบร้อยแล้ว สามารถลงทะเบียนที่เว็บไซต์ Skooldio.com ที่ลิงค์ด้านล่าง
ส่วนอีกเรื่องก็คือ
LINE Certified Coach for API
แต่เดิม LINE มี Program ให้ผู้เชี่ยวชาญ LINE API Expert และ LINE@ Certified Coach แต่ว่าตอนนี้ไม่มี LINE@ แล้ว จึงเปิดตัว Program ใหม่ ในชื่อว่า LINE Certified Coach for API ซึ่งจะต้องมีเชี่ยวชาญการตลาด OA (Official Account) และ LINE API
โดยจะต้องออกไป Contribute ข้อมูลให้กับนักพัฒนา และด้านธุรกิจ ไปบรรยายที่ Events หรือ Workshop ของประเทศไทย และทาง LINE ประเทศไทย จะ Promote ให้คุณทุกช่องทางทั้ง LINE TV, LINE Today และทุกอย่างที่เกียวกับ Official ของ LINE
และแน่นอนว่าท่านจะได้ข้อมูลล่าสุดก่อนใครทั้งด้าน Business และ Develop
การรับสมัครจะรับสิ้นเดือนนี้ (31 May 2019) เท่านั้น
Catching up new features of LINE API with 100% live demonstration
โดย คุณ Kazuki Nakajima: Developer Advocate at LINE Corporation.
ตามชื่อเลยครับ นาคาจิม่าซัง จะมาแสดง Demo แบบจัดเต็มให้เราได้ชมกัน
มีการอธิบายถึง Timeline แต่ละช่วงที่ทาง LINE มี Feature ใหม่ ๆ มาแต่ละช่วง
ส่วนตัว Demo จะเป็นการแสดง Flow ของการสั่งอาหารที่มีการโต้ตอบกันระหว่างผู้ซื้อ ผู้ขาย และ Chatbot โดย Step มีดังนี้
- ผู้ซื้อสอบถามอาหารที่ LINE Official Account
- Bot เป็นผู้รับคำสั่ง และตอบกลับแสดงเมนูอาหาร
- ผู้ซื้อสอบถามรายละเอียดต่าง ๆ
- Bot จะตอบกลับหากรายละเอียดนั้นได้ถูกสอนมาแล้ว เช่น อาหารร้อนหรือไม่
- ผู้ซื้อสั่งซื้ออาหาร
- ผู้ขายได้รับ Order และเมื่อทำอาหารเสร็จจะทำการอัพเดท Status จากหลังบ้าน
- ผู้ซื้อได้รับ Receipt
ถ่าย VDO มาให้ชมกันด้วยนะ (เพิ่งมาสังเกตว่าคุณภาพวีดีโอไม่ดีเลย ต้องขออภัยด้วยครับ)
ตอนสุดท้าย นาคาจิม่าซัง เปิด Code ตัวอย่างให้ดู และชี้ให้ดูว่าจะ Handle อะไรได้ที่ส่วนไหน และเน้นย้ำตลอดว่า Code Clean มาก ๆ
และแจกลิงค์เพื่อเข้าไปชมตัว Source code ทั้งหมด ท่านผู้อ่านเข้าไปดูได้ที่ลิงค์นี้ครับ
Lunch Break
มื้อกลางวันเป็น Buffet ครับ ไม่ต้องถามว่าอิ่มแค่ไหน ถามว่ากินครบทุกอย่างหรือไม่ดีกว่า ต้องขอขอบคุณในความใส่ใจของทีมงาน LINE อีกเช่นเคย
HALL A — How LINE using LIFF in e-Commerce
โดย คุณ เนติ (Nati Namvong): Team Lead Line Commerce Engineering at LINE Thailand
สำหรับหัวข้อนี้ชาว Frontend คงไม่พลาด เพราะการมาของ LIFF มันส่งผลดีต่อ UX มากขึ้นไปอีกระดับ อย่างเช่น ต้องการแสดงรายการอาหารหรือเครื่องดื่มจำนวน 30 อย่าง หากจะมาปัดซ้าย-ขวาในห้องแชทก็คงจะดูยากไป ด้วยความเป็น Web เรายังทำเรื่องการ Filter ได้อีกด้วย
คุณเนติอธิบายถึง LIFF ว่าเราสามารถให้มันทำงานร่วมกับ Messaging API ได้ เพราะฉะนั้นการให้ User เข้ามากระทำ Action ใด ๆ เราก็สามารถใช้ Messaging API ในการตอบกลับไปที่ห้องแชทได้ ไม่มีปัญหาเรื่อง Business Flow
ในหัวข้อนี้คุณเนติมี Demo ที่ใช้ LIFF และเป็น Project ที่ดูแลคุณเนติอยู่มาอธิบายให้ฟังอยู่ 2 ตัวคือ
LINE Shopping
- เป็นระบบ Market Place ที่ใหญ่ ใช้ LIFF ร่วมกับ Official Account
- โดยปกติจะส่ง Campaign หรือ Promotion ต่าง ๆ ซึ่งสิ่งที่ส่งมาเหล่านั้นเมื่อกดแล้วจะไปหน้า LIFF ที่เราระบุไว้ รวมไปถึง ทางลัดที่ Rich Menu ก็เช่นกัน
- หน้าสินค้าจะสามารถ Favorite ได้ ซึ่งเมื่อออกไปและเข้ามาใหม่ ก็จะยังแสดงได้ถูกต้องเพราะว่า LIFF สามารถ Get profile ทำให้เราเก็บค่าได้ว่า User คนนี้ชอบสินค้าค้านี้
- ในหน้าต่าง ๆ ของ LIFF เช่น หน้า Collection หรือ หน้า Search ทุกหน้าล้วนเป็น LIFF เพียงตัวเดียว เราไม่ต้องทำหลายตัวแต่ใช้ QueryString ในการเช็คว่าจะ Render หน้าไหน
OA Plus E-commerce
- ระบบนี้คือ 2 ระบบรวมกันนั่นคือ OA Plus และ ระบบ E-commerce ที่ไปเกาะอยู่กับ OA Plus ตัว
- OA Plus ถูกสร้างเพื่อตรงความต้องการคนไทยในการซื้อสินค้า
- มีความต่างกันกับ LINE Shopping ตรงที่ LINE Shopping เหมือนไป Super market จะต่อรองราคาไม่ได้ ต้องซื้อราคานั้น ๆ แต่ถ้าเป็น OA Plus เหมือนซื้อของกับแม่ค้าที่สามารถต่อรองราคาได้
- ซึ่งใน OA Plus ผู้ซื้อจะสอบถาม และถามรายละเอียดได้เลยเป็นการติดต่อผู้ขายโดยตรง และสั่งซื้อได้ด้วย ทางผู้ขายก็กรอกข้อมูลตามคำสั่งซื้อ และจะได้ราคาเพื่อส่งให้ผู้ซื้อทราบว่าราคาเท่าไหร่ เมื่อซื้อแล้วระบบยังสามารถดูสถานะสินค้าได้อีกว่า อยู่ในขั้นตอนไหนที่ผู้ขายได้ทำไว้ เช่น สถานะกำลังจัดเตรียม สถานะกำลังส่ง และหากเป็นการส่งสินค้าก็มีการกรอกหมายเลข Tracking number ได้อีกด้วย
ในตอนท้ายก่อนจบมี Live Code ด้วยนะ
HALL B — How LINE ScaleUp help Startup to be a Unicorn
โดย คุณ Jayden Kang: Executive Director at LINE Thailand
สำหรับหัวข้อนี้ผู้เขียนไม่ได้เข้า เพราะไปเข้าอีก Hall ถ้าหาข้อมูลได้แล้วจะมาอัพเดทอีกที ขออภัยด้วยนะครับ
HALL A — LINE Things: Connecting the Unconnectable
โดย คุณ อุกฤษ (Ukrit Pongsathaporn) (หลุยส์): Embedded Systems Team Lead at LINE Thailand
สำหรับหัวข้อนี้ผู้เขียนไม่ได้เข้า เพราะไปเข้าอีก Hall ถ้าหาข้อมูลได้แล้วจะมาอัพเดทอีกที ขออภัยด้วยนะครับ
HALL B — Enhance Customer’s Payment Experience with Rabbit LINE Pay API
โดย คุณ สิทธิ เทียมเมฆา (Sitthi Thiammekha)(หนึ่ง): LINE API Expert, Lead Software Engineer at Emetworks
เริ่มต้น Session คุณหนึ่งได้พูดถึง LINE API Expert ทั่วโลกมี 36 ท่าน ในขณะที่ประเทศไทยมีอยู่ 5 ท่าน จึงเชิญชวนท่านที่สนใจและมีความสามารถตามเงื่อนไขสมัครครับ
คุณหนึ่งถนัดเรื่อง LINE Messaging API, LINE Frontend Framework, LINE Beacon และ Rabbit LINE Pay API และใน Session นี้จะพูดเรื่อง Rabbit LINE Pay API ครับ
เริ่มต้นคุณหนึ่งก็มี VDO เกริ่นแนะนำเกี่ยวกับ Rabbit LINE Pay
การชำระเงินที่สะดวกในปัจจุบัน นักพัฒนาจะต้องทำในส่วนของ Payment Gateway ซึ่งค่อนข้างจะใช้เวลาและปวดหัวอยู่ไม่น้อย
แต่ถ้าหากใช้ Rabbit LINE Pay ก็จะมีขั้นตอนที่ไม่เยอะและไม่ยาก โดยคุณหนึ่งจะอธิบายภาพรวมแต่ละ Step ให้ฟังครับ
เริ่มตัว Web ของเราที่พัฒนาไว้แล้ว นำปุ่ม LINE Pay ไปแปะไว้ และเมื่อ User กดที่ปุ่มแล้ว มันจะทำการ Reserve API เพื่อโชว์จำนวนเงินและรายละเอียดที่ต้องชำระเงิน
และเมื่อ User กดปุ่มมันจะทำการ Call Back มาตามที่เรากำหนดไว้ได้ (Server/Client) และทำการ Confirm API
และต่อไปคุณหนึ่งจะอธิบายรายละเอียดแต่ละ Step เริ่มจากการสมัครบัญชีก่อน แต่หากสมัคร Rabbit LINE Pay อาจจะมี Process ที่ต้องใช้เวลาระยะหนึ่ง เพราะฉะนั้นให้สมัคร Sandbox เพื่อทดสอบระหว่างรอได้
โดยเข้าที่ URL นี้
หน้าตาของ Sandbox ตามภาพด้านล่างครับ
ในส่วนของ Reserve API เมื่อ User กดปุ่ม LINE Pay เราจะ Call Reserve API เพื่อให้ได้ URL และทำการ Redirect ไปหา URL นั้น ซึ่งการ Call เพื่อให้ได้ Response มา คุณหนึ่งก็อธิบาย Params แต่ละตัว
คุณหนึ่งแนะนำว่าควรจะกรอกให้ครบและชัดเจนเพื่อที่ User จะได้รู้และมีผลต่อความน่าเชื่อถือ
ในส่วนของ Params ที่ชื่อว่า confirmUrl จะเป็น Url สำหรับ Confrim ที่มี 2 แบบ โดยระบุที่ confirmUrlType คือ Client กับ Server
ถ้าเลือกเป็น Client ทาง LINE จะ Redirect ไปที่ URL นั้น แต่ถ้าเป็น Server ทาง LINE จะ Call Request มาที่ URL
Response ที่ได้มา จะมี URL มาให้ 2 ชุดคือ เป็น Web กับ App ให้นำ URL นี้ไปใช้ Redirect ได้เลย แต่หากใช้ Sandbox จะ Test ได้แค่ Web อย่างเดียว
พอ Reserve API แล้ว User ก็จะทำการชำระเงิน ระบบก็จะยิง Request ไปที่ LINE และ Redirect / CallBack ตามที่เราระบุ confirmUrlType ซึ่งมี 2 แบบ ได้ผลลัพธ์ดังภาพ
จากนั้นเมื่อทำการชำระเงินสำเร็จเราจะต้อง Confirm กับทาง LINE ด้วย
มี API อื่น ๆ ที่น่าสนใจ คือเมื่อ User Cancel การชำระเงิน Transaction นั้นจะมีสถานะเป็น Cancel แต่ถ้าชำระเงินจะมีสถานะเป็น AUTH และเมื่อ Confirm แล้ว หาก Capture ที่ส่งไปคือ false จะมีสถานะเป็น CAPTURE_WAIT แต่ถ้าเป็น true จะมีสถานะเป็น CAPTURE
มี Demo ให้เราเล่นกันด้วย
สุดท้ายคุณหนึ่งก็รวมลิงค์มาให้ครับ
ผู้เขียนเห็นว่าคุณหนึ่งได้เขียนบทความไว้แล้วก่อนหน้านี้ด้วย สามารถเข้าไปดูได้ที่
HALL A — Handle a Huge Traffic of Messages with HBase
โดย คุณ พิเชฐ อิฐงาม (Pichet Itngam) (น็อตซึ): Software Engineer at LINE Thailand
สำหรับหัวข้อนี้ผู้เขียนไม่ได้เข้า เพราะไปเข้าอีก Hall ถ้าหาข้อมูลได้แล้วจะมาอัพเดทอีกที ขออภัยด้วยนะครับ
HALL B — SCB Connect inside Banking Infrastructure
โดย คุณ โจ (Chanintorn Asavavichairoj) Software Engineer Specialist (Assistant Vice President) at Digital Banking, SCB
และ คุณ ไมค์ (Kasidej Phulsuksombati): Tech Lead at SCB 10X
หัวข้อนี้ คือ 1 หัวข้อที่มีคนให้ความสนใจเยอะมาก ๆ
เริ่มที่คุณโจก่อนท่านแรก คุณโจ Recap ว่า ตัว SCB Connect สามารถทำอะไรได้บ้าง
- คอยแจ้งเตือนทุกครั้งที่มี Transaction
- บริการข้อมูลสินเชื่อ
- ส่ง Gift และ Rewards ให้ User
- จองคิวล่วงหน้าเพื่อเข้าใช้บริการที่ SCB สาขาต่าง ๆ
- บอกสาขาที่อยู่ใกล้ที่สุด
- Chatbot มีการต่อกับ Dialogflow ทำให้ฉลาดมากขึ้น โดยทีม SCB 10X
และ Agenda ที่คุณโจจะพูดถึงมีดังนี้
- Handling Chatbot Flow
- Customer On-boarding
- The anatomy of SCB Connect (Infrastructure)
- Pushing tremendous messages
- Made the Chatbot more intelligent
Handling Chatbot Flow
เมื่อ User พิมพ์หรือคลิกที่ Rich Menu เราจะได้ Event ทางไลน์ Forward ไปเข้า Webhook
หากเขียน Cloud function หรือ Ramda คนส่วนใหญ่ จัดการ Process เป็น Synchronous ซึ่งทำให้บางครั้งมันช้าเกินไป
จึงเปลี่ยนไปเป็น Asynchronous เพื่อทำให้ Chatbot ตอบกลับไปได้ก่อน และมีการแตกอีก Thread เพื่อ Process อีกที
แต่ว่าก็ยังมีเรื่องที่อาจทำให้ Chatbot ไม่ตอบกลับ กรณีที่ Process ใด ที่ใช้เวลานานมาก ๆ จนนานเกิน Limit ที่กำหนดไว้ในการตอบกลับ ทาง SCB จึงใช้วิธีเก็บข้อมูลมากไว้ที่ตะกร้าที่หนึ่ง ไม่ว่าจะเป็น follow, unfollow, message ก็ทำการเก็บไว้ และจะมีตัวที่หยิบจากตะกร้านี้ไป Process อีกที ทำให้หาเกิดการ Fail เกิดขึ้นก็สามารถ Retry ได้
ส่วนเรื่องการทำให้ LINE ChatBot มีความ Secure มากขึ้น อันดับแรกคือให้ทำตามที่ LINE กำหนด Spec ไว้ และเมื่อได้รับ Web Hook เข้ามาเช็ค LINE -Signature คือ การเอา payload ที่ได้รับ เข้า HMAC-SHA256 Algorithm และมาเทียบ X-LINE-Signature ถ้าเทียบแล้วไม่ตรงก็มองไปได้เลยว่าคือ Hacker
จริง ๆ แล้วทาง LINE Expect ให้เราตอบ Webhook ภายใน 1 วินาที หากมีการเกินกว่า 10 วินาที จะมี tire ทาง Mechanic และตอบกลับเป็น Error ไปแทน
ซึ่ง 1 วินาทีมันเร็วมาก การที่เราใช้วิธีพักไว้และหยิบไปทำ Process จึงดีมาก ๆ สำหรับ Pattern นี้
การที่ขาตอบไปหา Messaging API เราสามารถทำการ IP Whitelisting ในส่วนของ IPv4 โดยนำ Length IP ของทาง SCB ไป Whitelisting ที่ทาง LINE เพราะฉะนั้นไม่ว่าใครจะ Call API ไปหา LINE ก็ไม่สามารถทำได้นอกจาก SCB เท่านั้น
หากทำครบแล้วก็แสดงว่าทำครบตามมาตรฐานของ LINE ซึ่งก็ทำให้ Chatbot ของคุณมีความ Secure
Customer On-boarding
เรารู้ว่าคนที่เข้ามาคือใคร เป็น Profile ของลูกค้าคนใดใน SCB
Mechanic ที่ใช้คือใช้การ KYC ของลูกค้า ถามข้อมูลบัตรประชาชนหรือเบอร์โทรศัพท์ และตรวจสอบที่ทางหลังบ้านของ SCB จากนั้นทำการ Binding ID ข้อมูลระหว่าง LINE และ SCB เข้าด้วยกัน เก็บไว้ในฐานของ SCB Connect
เพิ่งมีการ Launch SCB Easy Authen คือ ถ้ามี SCB Easy อยู่แล้ว สามารถกด Function ของ SCB Connect จะทำให้ Register ได้เลยไม่ต้องทำการกรอกเบอร์โทรใด ๆ เพราะว่ามีการทำ KYC ที่ SCB Easy ไว้แล้ว ซึ่งเป็นการ Integrate กันระหว่าง SCB Easy และ SCB Connect
SCB Connect จะมี 2 ส่วนหลัก ๆ คือ Register ไว้สำหรับสมัครเข้ามา และ Setting มีไว้สำหรับปรับ Profile
ตัวแรกที่ใช้คือ Channel Web App แต่ปัจจุบัน LINE ได้ยกเลิกไปแล้ว
จึงมาใช้ LINE Login ใน Chatbot จะทำการ Auto Login ให้ และเอา Authorization code แกะ LINE ID ออกมาและมาผูกกับ SCB
และสุดท้ายมาเปลี่ยนเป็น LIFF เพราะ Get Access Token ส่งกลับไปที่ Server ของ SCB ทำให้ Get Profile ของ LINE กลับมา
และข้อดีคือทำเป็น Deeplink ได้ เพราะเป็น schema ที่เป็น Friendly กับ Mobile และนี่ทำให้ SCB Easy โหลดข้าม App ได้เพราะใช้ Deeplink
The anatomy of SCB Connect (Infrastructure)
แบ่งออกเป็น 3 โซ่น คือ Internet, DMZ และ Intranet
DMZ ย่อมาจาก Demilitarized Zone คือ Zone ที่มีความปลอดภัยน้อยขึ้นมาหน่อย สามารถออก Internet ได้ง่าย
Core Bank และระบบทั้งหมดจะอยู่ใน Intranet จากในภาพคือส่วนที่เป็น SCB Enterprise System และเมื่อประมาณ 2 ปีที่แล้วก็มีส่วนที่เป็น Layer หุ้มอีกทีคือ SCB Enterprise API ทำให้มีความ Modern API มากขึ้น เป็น Restful
มี Enterprise PubSub เวลาที่มี Transaction ที่ Core Bank ตัวที่สนใจ Transaction เหล่านี้อย่าง SCB Connect ก็จะ Feed data มา และส่งต่อให้ User
ในส่วนของ SCB Connect จะแบ่งเป็น 2 ส่วนคือ ส่วนด้านแรกจะวางพวก Reverse Proxy ที่ DMZ เป็นทางเข้าและจะ Reverse ไปหา Service ที่อยู่ในส่วน Intranet ของ SCB Connect
SCB Connect จะมี Service มากมาย แต่ก่อนจะเป็น Standalone Application เรียกได้ว่าเป็น กึ่ง ๆ monolith ด้วยซ้ำ เวลา Scale จะต้องทำเป็น VM คือ ขอเครื่อง ขอ Firewall และมี Process มากมาย
แต่ปีที่แล้วมีการเปลี่ยนไปใช้ Containerize มีการใช้ Framework Kubernetes cluster ทำให้การ Scale Microservice ง่ายขึ้นมาก
มีการใช้ Open source มากมาย ไม่ว่าจะเป็น Kafka, Grafana, ELK Stack, Prometheus
ถ้าเป็นเรื่องของ Web Flow ไม่ว่าจะเป็น LIFF หรือว่า LINE Login ในการ on-board ลูกค้าตัว Flow จะเกิดมาจาก Client ที่เป็น Browser ของ User มาโดยตรง connect ถึง SCB
ส่วน Chatbot จะมาจาก Webhook แล้วก็ค่อยยิงกลับไป แบ่งออกเป็น 2 ส่วน
และยังมีการใช้ Cloud Service ของตัว AWS และ Google Cloud ด้วย
ตัว AWS ใช้ S3 และ Cloudfront เพราะว่า Data ที่เป็นรูปภาพถ้าไปใช้ CDN ก็จะทำให้โหลดรูปภาพได้ดีกว่า
ส่วน Google Cloud หลัง ๆ มาใช้มากขึ้น หลัก ๆ เลยคือ Dialogflow เพื่อเพิ่มความสามารถของ ChatBot ซึ่งในส่วนนี้คุณไมค์จะมาพูดต่อ
Pushing tremendous messages
ถ้าพูดถึง Transaction ที่เกิดจากการรูดบัตร Credit หรือการถอนเงิน Events ต่าง ๆ จะมาจาก Call Bank ผ่าน Enterprise PubSub ซึ่งข้อความทั้งหมดนั้น มีหลักเป็น 10 ๆ ล้าน
Handle อย่างไร ?
แต่ดั้งเดิม มี Microserveice ที่ไปรับจาก PubSub ก็มีการ Call Restful API เก็บไว้ใน Que และจะมี Worker หยิบไปส่งหา LINE แต่พอมีจำนวน User ที่มากขึ้นเรื่อย ๆ เริ่มมีปัญหา Scale แล้วไม่ Balance มันจึง Lost
HTTP มีความเป็น Signature ระดับนึง เพราะ Restful ไม่ใช่สิ่งที่ดีที่สุด มันอาจจะเหมาะกับ Synchronous มันมีความเป็น Point to Point มาก ๆ แต่ถ้ามี Service ที่มี 100 Flow ก็จะเริ่มไม่เหมาะ
เพราะฉะนั้นการเปลี่ยนจาก Restful มาเป็น Event ใน SCB Connect จึงทำให้มีความคล่องตัวมากขึ้น มอง Input และ Output เป็น Event
และนี่คือ Event Sourcing ทาง SCB ใช้ Event Sourcing ในการคุยกันระหว่าง Microservice ทำให้เกิดการ Timeout ลดน้อยลง เพราะว่า Consumer มีแรงดึงเท่าไหร่ ก็ดึงกลับไปเท่านั้น ไม่เกินกำลัง
Pattern ที่ใช้ส่งมี 3 แบบคือ คือ Request / Reply, Publish / Subscribe, Streaming
ความแตกต่างระหว่าง PubSub และ Streaming คือ
ถ้ามี 3 Service คือ x, y, z กรณีที่เป็น PubSub หาก x ตายคือจบ แต่ถ้าเป็ฯ Streaming มันสามารถนำ x มา Replay ได้ ที่ SCB ใช้แบบ Streaming ส่วน Framework ที่ใช้ก็คือ Kafka
แต่ก่อนรับ Events มาจาก LINE มาเก็บไว้ใน Redis และยิงหา Microservice ต่าง เปลี่ยนใหม่เป็น เก็บ Events ต่าง ๆ มาที่ Kafka และแยก lane ให้เลยตามประเภทไม่ว่าจะเป็น follow, unfollow, beacon, message หากตัว Service ไหนที่สนใจก็จับมา Subscribe topic นั้น ๆ อย่างเช่น Chatbot จะสนใจ Message ก็จะ Subscribe เฉพาะ Message เท่านั้น
ในส่วนของการยิง API กลับไปหา Message API ทาง SCB ได้เคยเกิดปัญหาเกี่ยวกับการ Scale Worker
คือมี Worker ได้ไม่จำกัด แต่ถ้าแบ่ง Worker เป็นตัวละ 150 TPS ก็จะไม่ได้มากกว่านี้แล้ว เพราะว่า LINE API แต่เดิมจะยอมให้ 10,000 Request / Min หรือประมาณ 166 TPS
แต่ว่าหลังจากที่ LINE Redesign ก็ปรับให้จากเดิมที่เป็น 10,000 ตอนนี้กลายเป็น 100,000 / Min หรือก็คือขยาย Worker ได้อีก 10 เท่าจากเดิม
แต่ถ้าพูดถึงว่าแต่ก่อนที่เป็น 166 TPS เราจะ Handle อย่างไร เพราะต้องยิง Transaction เยอะมาก คำตอบคือทำ Classification โดย SCB จะแบ่ง Message ของลูกค้าออกเป็นหลาย ๆ Type และมองถึงการใช้งานว่าเรียงลำดับความสำคัญอย่างไร สุดท้ายจึงกำหนดว่าเราสามารถกำหนดช่วงเวลาการตอบกลับได้ดังนี้
- ChatBot / Inquiry : ≤ 5 Sec
- Transaction Alert : ≤15 Sec
- Personalize Campaign : ≤ 60 Sec
- Batch / Reminder : Chill Chill
- Retargeting : ≤ 15 Sec
- Broadcast Campaign : ≤ 60 Sec
ในส่วนของ Inquiry Flow การถามเกี่ยวกับข้อมูลวงเงินบัตรเครดิต เราก็จะ Forward Events จาก LINE จากนั้นก็ Query กับ Core Bank และตอบกลับไป ซึ่งการตอบ SCB Connect จะใช้การตอบแบบ Reply เพื่อที่จะเป็นการลด Cost ของตัว Messaging API นั่นเอง
ในการตอบกลับของ Chatbot จากเดิม ตัว SCB Connect จะต้องใช้การพิมพ์ตามที่กำหนดไว้ทุกตัวอักษร ตอนหลังจึงมีการใช้ Dialogflow เพื่อให้ตัว Chatbot มีความฉลาดมากขึ้น รวมไปถึงการรับมือกับข้อความอื่น ๆ เช่น สวัสดี, ดีจ้า หรือ โย่ว ๆ ก็ต้องตอบกลับไปได้
และใครจะไปรู้ว่า Message ที่ User ส่งหา SCB Connect มากที่สุด ก็คือ … จุดนี่แหละครับ
ด้วยความน่าสงสัยและหาวิธีรับมือ คุณโจบอกว่าต้องยกความดีความชอบให้คุณไมค์ที่เป็นคนหาว่าจะตอบอย่างไร และนี่คือสิ่งที่ตอบ (อ่านแล้วก็ทำตา ปิ๊ง ๆ)
Made the Chatbot more intelligent
ต่อไปคุณไมค์จะมาพูดต่อ คุณไมค์จะมาพูดถึงทำอย่างไรให้ ChatBot ฉลาดด้วย Dialogflow
เปิดมาด้วยให้ชมสถิติที่น่าสนใจ ระหว่าง Broadcast และ Chatbot โดยสถิติที่ว่าเกี่ยวกับการปล่อยสินเชื่อ สำหรับ Broadcast จะอยู่ที่ 6.8% แต่ตัว Chatbot ที่ชี้นำ ให้ไปสมัครตัวสินเชื่อผ่าน SCB Easy อยู่ที่ 24.4% และพบว่าการเตรียม UX ที่ดีมันเกิด Conversion จริง ๆ
การสร้าง Chatbot ประกอบด้วย 2 อย่างใหญ่ ๆ คือ NLU และ UX
NLU คือ National Language Understanding คือ tools ที่ทำให้คอมพิวเตอร์เข้าใจภาษามนุษย์ได้ เช่น Dialogflow ของ google หรือ Luis ของ Microsoft
NLU ที่ดีจะเรียนรู้เรื่องผิดถูกได้ แต่จากประสบการณ์ของคุณไมค์ที่ทำ Bot หลายตัว บอกว่า NLU มีผลเพียงประมาณ 5% แต่ส่วนที่เหลืออีก 95% คือการวาง User Experience ที่ดี การเข้าใจ User journey
ความแตกต่างระหว่าง Application ทั่วไปที่สร้างขึ้นมาเพื่อแก้ปัญหาบางอย่าง กับ ChatBot สิ่งหนึ่งคือ Requirement
การจะสร้าง Application ทั่วไปจะวาง Requirement โดยการคิดถึงสิ่งที่จะต้องทำ แต่สำหรับ ChatBot คือ สิ่งที่ User ให้มาเองเลยผ่านการถามและ Chatbot ไม่รู้จัก นั่นคือ Requirement ของ Chatbot
และนีคือ Chatbot Maintenancd Model ของ SCB
Message ที่เข้ามาจาก LINE จะมี Adapter ตัวหนึ่งช่วยกรอง Type Message อาจจะเป็นรูป หรือ Sticker จะแปลงและส่งไปให้ Dialogflow
ซึ่งตัว Adapter เป็นตัว Log Monitor เกือบทุกอย่าง และทำการห่อข้อมูลใส่เข้าไปที่ BigQuery จากนั้นหา Insight ด้วย Data Studio และมี Chatbase ที่คอยดู Stat และ Flow ของ User
และจะมี Operator 1 คน จะคอยดูว่ามีอะไรที่น่าสนใจ น่าเอามาทำเป็น Intent ทาง Operator ก็จะสร้าง Intent ที่ Production ทันที ถ้า User ถามอะไรที่ Operator ไม่สามารถตอบได้ จำเป็นต้อง Call API ก็จะไปบอก Engineer ว่าช่วยทำ Fulfillment ให้หน่อย ทาง Engineer ก็จะ Develop และเอาขึ้นไปที่ Fulfillment
Process เหล่านี้จะทำให้สิ่งที่เคยตอบ User ไม่ได้ ก็จะทำได้ เพราะฉะนั้นการหา Insight ของ Data ก็จะมีความสำคัญเป็นอย่างมาก
แนะนำ Stack หนึ่ง คือ SBD Stack (ย่อมาจาก Stackdriver, BigQuery, Data Studio)
จากนั้นคุณไมค์จะ Demo ให้ดู แต่เอาตัว Production มาทำให้ดูนะครับ
คุณไมค์บอกว่า มันสามารถ Log interactions ต่าง ๆ เข้า Google Cloud ได้ด้วย
เปิด Logs ให้ดู จากนั้นจะทำการ Export ออกมา ทำได้โดยการสร้าง Log sink ซึ่งมันสามารถเลือกได้เลยว่าจะให้ไปที่ไหน อยากจะให้ไปเก็บที่ Cloud Storage, BigQuery, Cloud Pub/Sub ก็ได้หมด ในตัวอย่างนี้เลือก BigQuery
มาดูต่อที่ BigQuery จะเห็น Log ทั้งหมดถูกเก็บอย่างเป็นระเบียบและถูกเก็บทุกวัน
จะเห็นเป็นผลลัพธ์ที่ดูเข้าใจยาก คุณไมค์จึง Query ใหม่ ให้เป็น SQL Syntax
ก็จะพบว่าเป็นหน้าตาที่เข้าใจง่าย จากนั้นเราสามารถทำ Visualization ต่อที่ Data Studio ได้อีกด้วย
จากนั้นก็สามารถทำ Analysis ต่อได้ โดยนำไปสร้าง Topic modeling
สุดท้ายผลลัพธ์ที่เห็นชัดจากการทำ Topic modeling คือคำว่า “อยากเปลี่ยนเบอร์มือถือ” ก็ทำให้เห็นภาพมากขึ้นว่าเราสามารถใช้ประโยชน์จากสิ่งที่ทำมา เพื่อทำ Intent ใหม่ สร้าง Feature ใหม่นี้เพื่อตอบโจทย์ User และหากทำแบบนี้บ่อย ๆ ก็จะยิ่งให้ ChatBot สามารถเรียนรู้ได้เร็ว
Coffee Break
เหมือนกับช่วง Registration (Coffee break provided) นะครับ ต่างกันที่ขนม จะเป็นขนมปังที่มีไส้ต่างกัน และบราวนี่ อิ่มกันไปทั้งเช้า เที่ยง เย็นกันเลยทีเดียว ขออนุญาตนำภาพเดิมมาประกอบ
HALL A — Micro Frontend: The New Era of Frontend Edge Technology
โดย คุณ สิรภพ ร่มโพธิ์ (Siraphob Rhompo) (เต้): Software Engineer at LINE Thailand
เริ่มต้นคุณเต้ได้บอกถึง Concept การทำงานร่วมกัน Micro Frontend ดังนี้
- Technology Agnostic การเลือกใช้ Framework หรือ Technology ไม่ควรจะมีปัญหาระหว่างกัน สามารถทำงานร่วมกันได้
- Development Autonomy การแบ่งทีมสำคัญ แต่ถ้าทีม A, B, C ไม่อิสระต่อกัน ทำให้งานสะดุด เช่น จุดแรกก็ทำไป จุดสองก็ทำไป
- Isolated Deployment การ Release ควรจะไม่มีปัญหา ไม่ติด Block กันระหว่างทีม ไม่ต้องรอใคร จะทำให้ Devilry ได้เร็วขึ้น
- High Resilience พอแบ่งย่อย แล้วเสี่ยง ไม่ เราต้องมีความสามารถในการจัดการกรณีที่ Service แต่ละจุดตาย แต่ก็ยังทำให้ระบบดำเนินการต่อไปได้
คุณเต้พูดถึงองค์ประกอบการทำเว็บในปัจจุบัน โดยปกติแล้ว จะแบ่งเป็นส่วนต่าง ๆ เช่น Header, Footer, Left, Right หรือ Component ต่าง ๆ และสุดท้ายจะนำทั้งหมดมารวมกันเป็น Page ซึ่งจะเรียกว่า Layout
หากมองว่าเป็นเรื่องของ SPA ก็จะมี Component ตัวนึงเป็นตัวหลักในการ Control Layout ต่าง ๆ
ในการทำ Micro Frontend ตัว Layout ก็เป็น Core หลักในการจัดการแต่ละส่วน
แต่ละส่วนต่าง ๆ ของ Micro Frontend จะเรียกว่า Fragment สาเหตุที่ไม่เรียกว่า Component เพราะว่ามันจะหมายถึง Component ของ React, Vue ซึ่งมันเป็น Root Single Element
แต่ Fragment เป็นส่วนของ HTML ที่เรา Serve อะไรออกมาก็ได้ที่ตอบสนองต่อ Domain นั้น ที่จะใช้ในหน้า Page
ใน Layout จะแบ่งเป็น Slot ที่ Define เอาไว้และเจ้าตัว Layout จะเลือกว่าจะเอา Fragment มาแปะใน Slot ไหน ทั้งหมดนี้เรียกว่า Layout Service ซึ่งเป็น Core หลักของ Micro Frontend ดังภาพด้านล่าง
Layout Service
มีหลักการทำงานหลัก คือ เป็น Transclusion อธิบายสั้น ๆ ก็คือ เป็นการรวม Document ต่าง ๆ เข้ามารวมกัน ไม่ว่าจะเป็น image, JavaScript, HTML หรือ CSS
Transclusion มีหลายเทคนิค ไม่ใช่แค่ Serve มาจาก Server และ Render ออกไปที่ Client หากเกิดที่ Client ก็จะเรียกว่า Client Transclusion แต่ถ้าเกิดจาก Server ก็จะเป็น Server Transclusion
Client Transclusion
- IFrame คือการใส่ Document มาแปะอีก Document ได้โดยไม่กระทบส่วนอื่น
- AMD จะเป็นเรื่องของ Modules Loader ที่ทำได้จากฝั่ง Client ได้เลย
- System.js ลักษณะเดียวกับ AMD
- single-spa คือเอา Framework ต่าง ๆ ที่ใช้ SPA มารวมกันหน้าเดียว
- HTML import ตัวนี้จะยังไม่ได้ใช้แพร่หลาย
Server Transclusion
- SSI คือ Server side include ปกติจะอยู่ใน Web server เจ้าดัง ๆ เช่น NGINX เราสามารถสั่งให้ Render ที่ฝั่ง Server ไปโชว์ที่ Client ได้
- Pre-rendered composition คล้าย ๆ กับ SSI แต่ทำขึ้นมาเอง เป็น Framework ที่โหลด Asynchronous จาก Service และรวมเป็น Layout และส่งไปที่ Client
Fragment Service
โดยปกติการออกแบบ หรือการทำ Modules ของ Service เรามักจะแบ่งเป็น 3 Tier architecture คือ UI Layer, Business และ Data แต่ Fragment จะไม่ถึงขั้นนั้น เป็นแค่ Fragment ของ HTML อาจจะเป็นรูป หรือ HTML ของตัวมันเอง
ยกตัวอย่างสมมติว่ามี 3 Framework หลัก คือ
- React.js เราก็จับมาคู่ Registry และ Serve ออกไป
- Angular.js ก็ต่อเข้ากับ Web Server ก็ได้
- Vue.js Serve มาจาก CDN ก็เป็น Fragment service
และถ้าถามว่าจะไปทิศทางไหน เลือกตัวไหน วิธีไหน คุณเต้กล่าวว่าขึ้นอยู่กับกำลังทีม และความพร้อมของทีมมากกว่า เพราะตอนนี้ Micro Frontend ยังเป็นเรื่องที่ค่อนข้างใหม่ ยังไม่มีอะไรแน่ชัดว่า วิธีไหนดีที่สุด
ภาพรวม Architecture คือภาพนี้ครับ
คุณเต้มีผู้ช่วยมาสาธิต Demo มาแสดงให้ดูว่าการทำ Service 2 ตัวขึ้นไปมารวมที่หน้า Web จะทำงานอย่างไร
เริ่มแรกจะนำ Service ที่แสดง Banner มาต่อเข้ากับ Layout หลัก ตามภาพด้านล่าง
จากนั้นจะทำ Service เกี่ยวกับแสดงบทความที่เกี่ยวข้อง โดย Service ตัวนี้ จะเปลี่ยนข้อมูลไปด้วย หากตัว Layout เดิม มีการเปลี่ยนหน้าโดยการคลิกที่ ข่าวถัดไป และ ข่าวก่อนหน้า
ต่อไปจะทำ Ads Banner และใส่ลูกเล่นเป็นหิมะ (หรือป่าว) ใส่มาแทนที่ Service ข่าวที่เกี่ยวข้อง ผลลัพธ์ที่ได้คือ
จะเห็นว่าหิมะไม่ได้แสดงแค่ส่วนของ Ads Banner แต่แสดงทั้งหน้า Layout
หากมี Service ตัวใดตัวนึง Down ก็จะต้องมีการจัดการ Error เหล่านั้นได้ คุณเต้ก็ได้แสดงให้ดูว่า กรณีที่ Service ของ Banner ใช้งานไม่ได้ ก็สามารถ Handle ได้
และนั่นคือตัวอย่างของการทำงานร่วมกันของ Micro Frontend จากนั้นคุณเต้ทิ้งท้ายไว้ว่า หลาย ๆ ท่านคงมีคำถามต่าง ๆ ไม่ว่าจะเป็น
- มี Fragment จะสื่อสารกันอย่างไร
- Routing ยังทำงานได้ดีเหมือนเดิมหรือไม่
- หากมี Framework หรือ Libs ที่มี Conflict กันจะจัดการอย่างไร
คุณเต้บอกว่า ในคำถามเหล่านี้ Session นี้อาจจะตอบได้ไม่หมด แต่ถ้าหากมีใครที่สนใจและอยากจะช่วยกันแชร์ คุณเต้ก็เรียนเชิญให้มาแชร์กันได้นะครับ
HALL B — AutoML in Chatbot Builder Framework
โดย คุณ Jaewon Lee: Data Scientist in NLP at NAVER & LINE Corp in South Korea.
สำหรับหัวข้อนี้ผู้เขียนไม่ได้เข้า เพราะไปเข้าอีก Hall ถ้าหาข้อมูลได้แล้วจะมาอัพเดทอีกที ขออภัยด้วยนะครับ
HALL A — Live Coding a Chatbot
โดย คุณ จิรวัฒน์ กรัณย์วิทยาการ (Jirawatee) (ตี๋): Technology Evangelist at LINE Thailand
และนี่คือ 1 ใน Session สุดท้าย พี่ตี๋จะมาโชว์ Live Code และทางพี่ตี๋ก็ได้โชว์ความ Professional โดยการเล่นมุก Wrap โย่ว ๆ …. !!
กลับมาที่สาระกันดีกว่า
เปิดมาพี่ตี๋แกก็โชว์ความ Challenge ด้วยการสัญญาว่า ภายใน 45 นาทีต่อจากนี้
จะสร้าง Chatbot ที่มีการรายงานผลฟุตบอล UEFA Champions League นัดชิงชนะเลิศ ระหว่าง Tottenham Hotspur VS Liverpool
โดยตัว Chatbot ที่ว่ามีเงื่อนไขดังนี้
- Realtime updating หากมีการทำประตูเกิดขึ้นต้องมีการแจ้งให้ทราบทันที
- Support iOS and Android หากมีเวลาน้อยและทำ Mobile App เองก็ต้องผ่านการ Review ที่ต้องใช้เวลา
- Fastest way to develop and publish โครงสร้างไม่ยาก และเมื่อเขียนเสร็จก็ Deploy ได้ทันที
- Scalability with Serverless วันนี้ให้ทุกคนโหลดก็ยังใช้ได้ ต่อไปมีอีกกี่คนก็ตามระบบก็ยังใช้งานได้ปกติ โดยไม่ต้องเข้าไปปรับ config หรือยุ่งกับ Server
- Build something WOW like a magic เขียนทั้งที่ก็ต้อง wow wow wow
เนื่องจากว่าภาพที่ผู้เขียนถ่ายมาไม่ชัด และกว่าจะเขียนบทความนี้เสร็จทางพี่ตี๋ก็มีบทความที่อัพเดทล่าสุดหลังจากงาน LINEDEVCONF นี้ไว้แล้ว ซึ่งเท่าที่ดูคือละเอียดมาก ๆ และชัดเจนทุกขั้นตอน ผู้เขียนจึงขอนุญาติแปะลิงค์ และในหัวข้อนี้ ทางผู้เขียนจะลงภาพบรรยากาศ และ VDO ผลลัพธ์ที่ออกมาเท่านั้น ขออภัยด้วยครับ
และนี่คือบรรยากาศตอนที่ Live Code ครับ
เมื่อการ Deploy ต้องใช้เวลา Developer ที่จะต้องนั่งหน้าคอมนาน ๆ มีความเสี่ยงต่อโรค Office syndrome พี่ตี๋ก็เลยเชิญชวนให้ใช้เวลาระหว่างรอทำแบบนี้ครับ
ใน Chatbot ตัวนี้มี Flow ที่ WOW อย่างหนึ่งคือ การให้ User อัพโหลดรูปภาพ และจะมี AI ประมวลผลกับภาพ จากนั้นจะตอบกลับเป็นชื่อทีมให้ User เลือก พี่ตี๋ก็เลยขออาสาขึ้นมาเวทีเพื่อถ่ายรูปด้วย
เก็บ VDO มาให้ชมบรรยากาศด้วย (ขออภัยในความไม่ชัดของ VDO)
และนี่คือภาพรวมของ Chatbot ที่พี่ตี๋ทำครับ
HALL B — Monetizing in LINE API Platform
โดย คุณ ธฤต ศิริพรธนากุลท (Trit Siriporntanakul) (เตร): Business Connect Consultant, LINE Thailand
สำหรับหัวข้อนี้ผู้เขียนไม่ได้เข้า เพราะไปเข้าอีก Hall ถ้าหาข้อมูลได้แล้วจะมาอัพเดทอีกที ขออภัยด้วยนะครับ
Closing
สำหรับการจบงาน LINE Thailand Developer Conference 2019 นี้ ก็มีการระบุ Timeline ของงานต่าง ๆ เพื่อให้ทุกท่านได้ติดตาม
และเราสามารถติดตามข่าวสารของ LINE Thailand Developer ได้ดังภาพด้านล่าง
เพื่อความสะดวกในการคลิกลิงค์ผู้เขียนได้แนบมาไว้ให้ด้านล่าง
ขอขอบคุณ
ต้องขอขอบคุณทีมงานที่เกี่ยวข้องของ LINE ทุกท่านที่มาแชร์ความรู้ มาดูแลพวกเราเป็นอย่างดี นอกจากงาน Conference แล้วก็ยังคอย Support ตามช่องทางต่าง ๆ อีกด้วย ขอบคุณที่ให้โอกาสพวกเรา ผู้เขียนหวังเป็นอย่างยิ่งว่าการเขียนบทความนี้จะช่วยกระจายเสียงของทีมงานทุกท่านได้อีกแรงครับ
ล่าสุดทาง LINE Developers Thailand ได้ปล่อย VDO ออกมาให้ดูย้อนหลังแล้วนะครับ
หากท่านผู้อ่านมีคำถามหรือข้อสงสัย หรือมีคำแนะนำ ติชม สามารถติดต่อผู้เขียนได้เลยครับ
