[BPMN] แก้ปัญหา Stack Size is too large บน Camunda BPMN

หลังจากลองตัว Camunda  BPMN Engine มาสักพัก แล้วจะทดสอบอะไร อยากรู้ว่ามันมีค่าเท่าไหร่ ปกติเราทำพวก Instrument Test เพื่อแสดงให้เห็นว่ากิจกรรมที่สนใจ โดยผมเขียนคำสั่งประมาณนี้

เมื่อนำไป Run กับ BPMN Engine พบว่า Stack Size is too large ครับ

ปัญหา คือ อะไร

  • Operation ในการทำงานมันเยอะเกินไปครับ แทนที่จะให้มันต่อ String ในคำสั่ง ก็แก้ไขให้มันเตรียมข้อมูลอะไรให้เสร็จก่อนครับ
  • การแก้ไข แยกส่วนของเตรียมข้อมูลออกจากการแสดงผลครับ โดย Code ใน Scritp Task ที่ได้ เป็นดังนี้

ทดสอบอีกครั้งครับ

  • ได้ผลลัพธ์สวยงามครับ ^___^

[BPMN] Deploy Process ผ่าน REST-API

จริงๆ ใน Blog ตอนก่อน ช่วงที่ผมได้เล่นกับตัว Camunda BPMN ช่วงแรกจะพบว่าการ Deploy Process นั้นยุ่งยากครับ ต้องทำเป็นไฟล์ .war แล้วนำไปวางที่ Tomcat ครับ แต่จริงๆ มันมีวิธีการที่ง่ายกว่านั้น คือ การใช้ REST-API ครับ โดยมีข้อกำหนดของ Web Service ดังนี้ครับ

สำหรับตอนนี้ เราจะมาลองกันครับ โดยใช้ Tools ที่มีชื่อว่า POST-MAN สำหรับการทดสอบครับ โดยใน Blog ตอนนี้ ผมทดสอบ Create และ Delete BPMN ที่เราได้เพิ่ง Deploy ไปครับ

ก่อนจะ Create สิ่งที่ต้องเตรียม

  • BPMN Engine – Camunda ครับ ที่ผมเลือก ถ้าใช้ JBPM หรือ Activiti ก็สามารถทำได้ครับ
  • POST-MAN
  • ไฟล์ BPMN ครับ โดยมีการกำหนด Process ตามแผนภาพครับ

CREATE ผ่าน REST-API Method = ‘POST’

  • URL : [base-url]  /deployment/create
    • ตัวอย่าง  http://localhost:8080/engine-rest/deployment/create
  • โดยมีการกำหนด Parameter ดังนี้ครับ
  • ผลลัพธ์ที่ได้ครับ

    • id คือ deploymemt id ( 988aa432-824f-11e8-8365-005056c00001) ซึ่งบ่งบอกว่าการ deploy process ของเรา ซึ่งเอาไว้ใช้อ้างอิงใน Operation ต่างๆที่เกี่ยวกับ BPMN ครับ
    • ส่วนที่ผมตีกล่องไว้จะเป็นข้อมูลของ BPMN Process ครับ
  • มาดูในส่วนของ Cockpit พบว่ามี Process ที่ Deploy ไว้ ดังรูป

DELETE ผ่าน REST-API Method = ‘DELETE’

  • URL : [base-url]  deployment {deployment-id}
    • ตัวอย่าง  http://localhost:8080/engine-rest/deployment/988aa432-824f-11e8-8365-005056c00001
  • โดยมีการกำหนด Parameter ดังนี้ครับ

    • cascade = ถ้ามี Process ที่กำลังถูกลบ ยังมี Instance ที่ยังทำงานอยู่ ให้ระบบลบ Instance  ไปด้วย หรือไม่ (true) หรือให้คงอยู่จนจบ (false)
  • กลับมาตรวจสอบในส่วนของ Cockpit พบว่า Process ได้หายไปแล้วครับ

จบไปแล้วครับกับการ Deploy Process ผาน REST-API ยังมี Method อื่นๆ อีกที่น่าสนใจนะครับ REST-API : Deployment

 

[TESTING] มาทำให้ JSON-Server Support Request แบบ Chunked ครับ

หลังจากติดปัญหาเรื่อง BPMN Engine  แล้วพบว่า Service Task ถ้าทำเป็น Web Service แล้วข้อมูล Request ในส่วนของ Body มันหายไปครับ หลังจากไล่ไปไล่มา โดยดูจาก

ในที่สุดก็พบปัญหาแล้วครับ เนื่องจากตัว BPMN Engine ที่ผมเลือกได้ใช้ Tomcat HTTP 1.1 connector ซึ่งมีการเปิด transfer encoding ให้เป็น Mode = “Chunked” ซึ่งมีการส่งข้อมูลเป็นชิ้นๆครับ และที่สำคัญ ถ้าทำ Request แบบนี้มันจะไม่ระบุขนาดของ Request ไปด้วยครับ ซึ่งนี่แหละที่ทำให้ JSON-Server มันมอง Request-Body ว่าไม่ได้ส่งอะไรมาครับ งงอยู่ตั้ง 2 สัปดาห์ครับ

ถ้าจะไปแก้เป็นตัว HTTP 1.0 มันก็ไม่ควรครับ เพราะจะทำให้ตัว Camunda BPMN Engine ทำงานผิดปรกตืในส่วนอื่นได้ครับ หลังจากค้นๆดูแล้ว ตัว JSON-Server มันยอมให้เราทำ Middleware มาครอบ เพื่อจัดการ Request แทนครับ สำหรับ Code ที่เชียนจะใช้ Code ต่อจาก Blog ตอนก่อนครับ โดยเพิ่มการดัก Request ที่เป็นประเภท Chunked

  • Request – ON ให้รอรับ Chunked ที่เข้ามาครับ
  • Request – END เมื่อรับ Request มาหมดแล้ว ให้ทำอะไรต่อครับ สำหรับผมให้แปลงเป็น JSON ครับ
  • ส่งต่อให้ตัว JSON-Server คำสั่ง Next()
  • Code ที่ใช้ทั้งหมดครับ โดยตัว Request แบบ Chunked ให้ทำงานตอนมีการส่งข้อมูลแบบ POST / PUT และ PATCH ครับ และปรับให้ Request – ON กับ Request – END ทำงานต่อกัน

Code ของ Middleware ทั้งหมดครับ

Reference

[TESTING] มา Debug Request ที่ส่งเข้าไปใน JSON-SERVER ครับ

หลังจากที่ได้ลง JSON-Server ไปแล้วใน Blog ตอนก่อนครับ หลังจากที่ลอง Service Task บน BPMN แล้วพบว่ามันไม่ส่งข้อมูลไป คราวนี้ผมเลยต้องมาไล่ดู Request ที่ส่งไปที่ JSON-Server มันส่งไปจริง หรือป่าว และส่งอะไรไปบ้างครับ โดยสิ่งที่มีก่อนครับ

  • Node.js
  • Editor อะไรก็ได้ครับ เพราะ เราเขียน JavaScript เรียกใช้งาน JSON-Server ครอบอีกทีนึงก่อนครับ

สำหรับขั้นตอนมาลุยไปพร้อมๆกันเลยครับฃ

  • สร้าง Project สำหรับ Node ด้วยคำสั่ง  npm init -y  ซึ่งได้ผลลัพธ์เป็น  package.json  ที่ทำหน้าที่เก็บข้อมูลของ Project และ Package ที่เกี่ยวข้อง
  • ลง JSON-Server
    • ถ้าไม่มีใช้คำสั่ง  npm install json-server --save  ติดตั้งที่ Local เลยครับ
    • ถ้าใน Global แล้วใช้คำสั่ง Link ครับ
  • ทดสอบ Code ดังนี้ครับ โดยใช้ Lib ของ bodyParser ซึ่งจะเป็น dependency ที่ JSON-Server Require อยู่แล้วครับ ไม่ต้อง Download เพิ่มเติมอะไรครับ
    • โดย Code ที่เราทำ มีการเรียกใช้ bodyParser แล้วทำการพ่นสิ่งที่ซ่อนใน request (req) ผ่าน console.log() ใน req.body ครับ
    • และ ถ้าเป็น Method POST ให้เพิ่มเวลาที่สร้างไปใน Property “CreateAt”
    • ส่วนของ Code ที่ทำตรงนี้ อยู่ด้านล่างครับ
  • Code สมบูรณ์ทั้งหมด ไฟล์  middleware.js ครับ
  • ทดสอบ Run ครับ สิ่งที่ต้องมี
    • ไฟล์ db.json << ใน Code Require ครับ ถ้าไม่มีมันสร้างไฟล์เปล่ามาให้ครับ สำหรับผมก็ใช้จาก Blog ตอนที่แล้วครับ อิอิ
    • Run ด้วยคำสั่ง node  middleware.js  ครับ
  • ลองยิง Request เข้ามาครับ
    • ลองจาก Postman
    • ลองจาก BPMN << ปัญหาที่ทำให้ต้องเกิด Blog นี้เลยครับ
    • มาดูผลลัพธ์ที่ Console นะครับ สิ่งที่ Highlight เกิดจากคำสั่ง Console.log ที่เราได้ Customize ไปครับ

หลังจากเขียน Blog นี้เสร็จคงต้องกลับไปลองดู Script ที่เขียนแล้วว่ามันผิดตรงไหนครับ T___T

[TESTING] Mock Data สำหรับ API Test ด้วย JSON-Server กันครับ

หลังจากทำ BPMN ที่เป็น Servicer Task เสร็จและ โดยลองใช้ Mock REST-API จาก http://www.mocky.io เพื่อ POC (Proof of concept) แล้วนั้น สิ่งถัดมาที่ผมทำ คือ ต้องมาลองสร้างข้อมูลให้มัน Dynamic มากก่านี้ครับ ซึ่งผมได้เจอ Open Source ตัวนึงที่น่าสนใจมากครับ แท่นแท๊นนน มัน คือ JSON Server ครับ เป็น Tools ที่เกิดมาเพื่อทำ Mock REST-API โดยแท้เลยครับ มันเลยเป็นที่มาของ Blog ตอนนี้ด้วยครับ

สิ่งที่ต้องมี

  • node.js ครับ เพราะต้องใช้คำสั่ง  npm install  ครับ ถ้าใครเพิ่งลงก็อย่าลืม Log-off และ Log-on เครื่องใหม่ หรือเอาง่ายสุด Restart เครื่องครับ
  • Internet เอาไว้สำหรับ Download Tools ครับ
  • data สำหรับ Test ครับ API แต่ละตัว ต้อง Return อะไรมาบ้างครับ

ลุยเลยครับ

  • ติดตั้ง JSON Server ด้วยคำสั่ง  npm install -g json-server  ** ผมใส่ -g เพราะต้องการให้เป็น Global ใช้งานได้กับทั้งเครื่องผมครับ
  • รอไปสักพัก
  • ทดสอบ โดยการลองพิมพ์ json-server จะพบ help ขึ้นมาครับ ดังรูป
  • จะลองส่อง Version ก็ได้ครับ โดยใช้คำสั่ง  json-server --version  ผลลัพธ์ที่ได้

สร้าง db.json

  • ไฟล์ db.json เป็นไฟล์ที่เก็บข้อมูลการ Mock ของ API แต่ละอันครับ
  • อย่างไฟล์ตัวอย่างด้านบน มี API ของ requests และ projects ครับ
  • NOTE: ถ้าสังเกตุดีๆ พบว่ามี Property Id ที่ต้องอยู่ใน db.json อาจจะงงว่าทำต้องใช้ Id เพราะมันเป็ฯที่นิยมในการใช้ครับ แต่จริงๆ มัน Custom ได้จากคำสั่ง  json-server --id  ครับ

Deploy Mock API

  • เมื่อมีไฟล์ db.json แล้ว จะรออะไรหละครับ CD เข้าไปที่ Path ที่เก็บไฟล์ แล้ว Start Server ขึ้นมาเลยครับ ด้วยคำสั่ง  json-server --watch db.json  ตอนนี้ตัว JSON Server สร้าง API ขึ้นมา 2 ตัวครับ คือ requests และ projects ดังรูปครับ
  • ถ้าลองเข้าที่ http://localhost:3000/requests พบข้อมูลที่เรา Mock ไว้ ดังรูปครับ

ทดสอบผ่าน Postman บ้างครับ

  • Postman เป็น Tools ที่เข้ามาช่วยจัดการ API-Test เลยครับ

กรณีทดสอบของ Mock API ครับ

  • ดึงข้อมูล requests ตาม id
    • คำสั่ง GET: http://localhost:3000/requests/1
  • ดึงข้อมูล projects ตาม id
    • คำสั่ง GET: http://localhost:3000/projects/123
  • ดึงข้อมูล request ที่ requeststatus มีค่าเท่ากับ “wait-for-proceed”
    • คำสั่ง GET: http://localhost:3000/requests?requeststatus=wait-for-proceed
  • ดึงข้อมูล request ที่ requeststatus มีค่าเท่ากับ “wait-for-proceed” โดยเรียงตาม Id จาก มากไปน้อย DESC
    • คำสั่ง GET: http://localhost:3000/requests?requeststatus=wait-for-proceed&_sort=id&_order=desc
  • ดึงข้อมูล request ที่ requeststatus มีค่าเท่ากับ “wait-for-proceed” โดยเรียงตาม Id จาก มากไปน้อย ASC ที่ละ 1 รายการ
    • คำสั่ง GET: http://localhost:3000/requests?requeststatus=wait-for-proceed&_sort=id&_order=asc&_limit=1
  • Update ข้อมูล request ที่ Id = 1 ให้ requeststatus มีค่าเท่ากับ “completed”
    • คำสั่ง PATCH: http://localhost:3000/requests/1
    • จากอันเมื่อกี้จริงๆ ส่งคำสั่ง PUT ก็ได้นะ แต่ PUT ต้องส่งไปทั้ง Object เท่านั้น โดย Object ที่ส่งไป
      • ถ้า PATCH
      • ถ้า PUT
  • เพิ่ม Request บ้าง
    • คำสั่ง POST: http://localhost:3000/requests/
  • NOTE: พวก PATCH / POST / PUT อย่าลืมกำหนด Content-Type ด้วยนะครับ
  • ลบ Request ที่ Id มีค่าเท่ากับ 5 ออก
    • คำสั่ง DELETE: http://localhost:3000/requests/5

 

[BPMN] Service Task with REST-API (OTHER) Example

หลังจากได้ลองไปแล้วกับ REST API ผ่าน Service Task บน BPMN ไป 2 เรื่อง

คราวนี้ก็มาลองแบบที่เหลือบ้างว่าอันไหน Work หรือไม่ Work ครับ โดยผมได้สร้าง BPMN ที่มีกระบวนการทำงาน ดังรูปครับ

  • ถ้าสังเกตุในแบบจำลองที่ผมทำ มันมีสัญลักษณ์ที่ถูกเขียนกำกับว่า JSON-Server ตัวนั้น คือ DataStore อันนี้ในตัว BPMN Engine ไม่ได้สนใจครับ แต่เป็นสัญลักษณ์ทีแสดงให้เห็นภาพรวมของกระบวนการให้ครบ
  • ไฟล์ BPMN ครับ ถ้าสนใจพวก Config สามารถแงะตามได้ครับ

โดยแต่ละ Service Task มีการเรียกใช้ REST-API Method ที่แตกต่างกันครับ ได้แก่

  • GET
  • PATCH
  • POST
  • DELETE
  • PUT

ทดสอบ Run ครับ โดยผมใช้ Mock API ของ JSON-Server อีกเช่นเคยครับ

  • โดยมีการกำหนดข้อมูลในไฟล์ db.json ดังนี้
  • เมื่อกด Run ครับดู Response ที่ได้จากการ Request ไปครับ

สำหรับ Blog นี้เขียนเสร็จ ปุบได้ขอ Request แก้ Document ของตัว Camunda เลย เพราะมันใส่ไม่ครบครับ ^__^

[BPMN] Service Task with REST-API (PATCH) Example

หลังจาก Blog ตอนก่อน ผมได้ลอง Service Task เชื่อมกับ Web Service ผ่านวิธีการ GET เพื่อที่ดึงข้อมูลมาแสดงผลครับ คราวนี้หลังจาก GET ข้อมูลไปแล้วคราวนี้ เราลองมาทำการแก้ไขข้อมูลครับ ซึ่งการแก้ไขข้อมูลบางส่วน อันนี้ทาง Web Service (REST API) เค้ามีวิธีการที่เรียกว่า PATCH ครับ ส่วนจะทำอย่างไรนั้นมาลุยกันเลยครับ

เตรียมตัวครับ

กระบวนการที่สร้างกันก่อนครับ

  • สำหรับกระบวนการที่สร้างคราวนี้ผมทั้ง JSON Server ขึ้นมาเองครับ โดยใช้ข้อมูล Request ซึ่งผู้ใช้ต้องใส่ ID เพื่อให้ระบบดึงข้อมูล Request ขึ่นมาครับ หลังจากดูเสร็จ แล้วกด Complete ข้อมูลของ Request ในช่อง “requeststatus” ถูกแก้ไขค่าจาก “wait-for-review” เป็น “completed” ครับ

ลองมือทำ โดยมี Task ที่เกี่ยวข้อง ดังนี้

  • Task “Enter Request Id” เป็น User Task เอาไว้สำหรับกรอก Id ของ Request ครับ
  • Task “Test REST-API (GET)” เป็น Service Task ที่ติดต่อกับ Web Service โดยมี Config ดังนี้
    • Connector Id = “http-connector”
    • Input มีค่าตามตารางด้านล่างครับ
      ์NameTypeScript FormatData
      urlscriptgroovy  “http://localhost:3000/requests/${RequestId}”.toString()
      methodtext  GET
      headermap  Key = “Accept”
      Value = “application/json”
    • Output เนื่องจากข้อมูลที่ได้เป็นอยู่ในรูปแบบ JSON จึงต้องมีการแปลงค่า และยัดลง Process ของ BPMN ได้แก่ id, projectid, requestid, requestby และ requeststatus ครับ โดยมี Code ดังนี้
  • Task “View Result” เป็น User Task ที่เอาผลลัพธ์ที่ได้จาก Task “Test REST-API (GET)” มาแสดงผลครับ
    • Connector Id = “http-connector”
    • Input มีค่าตามตาราง
      ์NameTypeScript FormatData
      urlscriptgroovy  “http://localhost:3000/requests/${RequestId}”.toString()
      methodtext  GET
      headermap  Key = “Accept”
      Value = “application/json”
        Key =”Content-Type”
      Value = “application/json”
      payloadscriptgroovy
  • Task “REST-API(PATCH) request status” เป็น Service Task ที่ทำหน้าที่เปลี่ยน “requeststatus” ถูกแก้ไขค่าจาก “wait-for-review” เป็น “completed” ครับ โดยมี Config ดังนี้ครับ
  • เมื่อสร้าง Task เสร็จแล้ว นำไฟล์ BPMN ที่ได้เตรียมไป Deploy ครับ

ทดสอบ

  • เตรียมข้อมูลสำหรับ Mock Server กันก่อนครับ โดยข้อมูลที่ได้มีหน้าตา ดังนี้ (ถูกเก็บไว้ในไฟล์ db.json ครับ)
  • Start JSON Server ด้วยคำสั่ง  json-server --watch db.json
  • เข้าไปที่ Camunda Task List จากนั้น Execute Task ชื่อ “HttpConnectorRequestPatch”
    • กรอก Request Id = 2
    • ดูรายการ Request จากนั้นกดปุ่ม Complete
    • ลองไปดูที่ Console ครับ พบว่า ช่อง “requeststatus” ถูกแก้ไขค่าจาก “wait-for-review” เป็น “completed” แล้วครับ

[BPMN] Service Task with REST-API (Get) Example

หลังจากงมๆมานานพอสมควรแล้วกับการใช้งาน Service Task กับ Web Service กับ Camunda BPMN Engine ครับ โดยสิ่งที่ผมใช้ คือ ตัว Camunda Connector ที่ช่วยให้เราสามารถ Config Web Service ได้ง่าย ไม่ต้องส่งงานให้ Delegate Code อย่าง BPMN Engine ของค่ายอื่นๆครับ สำหรับ

NOTE: สำหรับเรื่อง Service Task ตัว Spec ของ BPMN ไม่ได้ระบุใน Spec ชัดเจน ว่าต้องมีขั้นตอนการทำงานอย่างไร จึงเปิดให้ BPMN Engine แต่ละเจ้าสามารถเสริมเติมแต่ง Feature ได้เต็มที่ครับ

Camunda Connector

  • มี 3 รูปแบบ อ้างอิงจากเวอร์ชันที่ 7.9.0 ได้แก่
      • HTTP Connector – พวก REST API  ทั้งหลาย ใช้วิธี GET / POST และอื่นๆ แล้วเอา XML หรือ JSON มาใช้งานต่อ
    • SOAP Connector – พวก WSDL หรือ SOAP แบบเดิม
    • Custom – เขียน Code แล้วจัดการเองเลย

หลังจากเกริ่นนำได้ทดสอบ ตัว Connector แต่ละตัวกันแล้ว ตอนนี้มาดูตัวอย่างดีกว่าครับ โดยตัวอย่างที่ผมเขียนเป็นการใช้งาน HTTP Connector โดยใช้วิธี GET และผลลัพธ์ที่ได้ออกมาเป็นไฟล์ JSON ครับ เอาหละมาดูกันเลย ว่าเรา HTTP Connector แบบต้องใส่อะไรไปบ้าง

  • url => บอกว่าให้ไปเอาข้อมูลมาจาก Domain ไหน อะไร ถ้าเป็นแบบ GET ต้องยัด Parameter ลงไปในนี้ด้วยครับ
  • method => อันนี้กำหนดเป็น GET
  • header => บอกว่า Request ของเรามีอะไรบ้าง โดยกำหนดเป็น Key
    • key => Accept
    • value => application/json
  • payload => ไม่จำเป็นสำหรับ Method GET นะครับ ใส่เข้าไป จากการที่ลองไล่ Code ดูมันไม่ได้สนใจนะครับ

มาดูตัวอย่างกันบ้างดีกว่าครับ โดยผมทำเป็น Process ของการดึงข้อมูลของกระทู้ครับ

  • ข้อมูลจะถูก Mock มาจาก Open Source จาก https://jsonplaceholder.typicode.com/ อันนี้ผมเอาข้อมูล Mock จากตัว Web เลยครับ โดยใช้ URL https://jsonplaceholder.typicode.com/posts ซึ่งข้อมูลที่ได้มีผลลัพธ์ ดังนี้
  • Note: แต่เราสนใจเฉพาะ Id นะครับ ไม่ได้ ดึงมาหมด ดังนี้ URL อยู่ในรูป  https://jsonplaceholder.typicode.com/posts/<POST-ID>
  • ตัว BPMN Process – เดี๋ยวจะกล่าวในช่วงถัดไปครับ

มาเจาะลึกที่ BPMN Process ครับ ประกอบด้วย Task ย่อย 3 Task ครับ

  • Task “Enter Post Id” : เป็น User Task ให้ User กรอก Id ของ Post ที่ต้องการเรียกดูครับ
  • Task “Test REST-API (GET)” : สำหรับ Task นี้ เป็น Service Task ครับ โดย Task นี้เป็นพระเอกเลยครับ เพราะใช้เชื่อมกับ Web Service ครับ
    • กำหนด Config เป็น Connector
    • ภาพรวมของข้างในของ Connector
    • มาดูที่ส่วน Input ของตัว Connector ครับ
      • Connector-Id : ต้องเป็น http-connector เท่านั้น ห้ามตั้งชื่อเองนะครับ Engine ไม่รู้จัก
      • URL – สังเกตุว่า ผมไม่ได้ Map เป็น Text ครับ ผมใช้เป็น Script แทน เพราะต้องการเอา Post Id เช่น 1  จากตัวแปรของ Process ${PostId} มาใส่ต่อท้าย URL ตามคำสั่ง ดังนี้

        ภาพรวมของ URL
      • Method
      • Header
    • การจัดการ Output ครับ – ผลลัพธ์ของ Web Service อยู่ในรูปของ JSON ซึ่งผมจะเก็บไว้ใน postResult ครับ

      • แต่เนื่องจาก ผมต้องการเอาผลลัพธ์ที่เป็น JSON มายังลงใน Variable ของ Process ครับ เพื่อเอาไปแสดงผลใน Task ถัดไปครับ เลยต้องทำเป็น Script เพื่อกำหนดค่าครับ
  • Task “View Result” : เอาผลลัพธ์ที่ได้มาแสดงผลครับ โดยมีการ Config ดังนี้
  • BPMN Model สามารถดูได้จาก GitHub เลยครับ

ทดสอบครับ

  • Task “Enter Post Id” : ดึงข้อมูลของ Post Id 2
  • Task “Test REST-API (GET)” : หน้าที่ของ Engine ทำครับ เราต้องจัดการอะไร
  • Task “View Result” :

จบไปแล้วกับการงมๆ Web Service กับ BPMN ครับ โดยผมคิดว่าคงใช้ json-server ซึ่งเป็น Standalone JSON Mock REST-API มาใช้ทำ Thesis ครับ

 

[BPMN] ลองคิดตัวอย่างของ Completion Condition กัน

พอดีช่วงนี้ได้ลองเล่น BPMN แล้ว ปัญหาที่สำคัญของ Spec ตัว BPMN เอง คือ ตัวอย่างน้อย และไม่ครอบคลุมตามคุณสมบัติที่ได้ระบุไว้ใน Spec ครับ อย่างที่ผมโคตรงง ตอนนี้ คือ Attribute ของ Multi-Instance ของ Task ครับ ลองมาคิดตัวอย่างกันดีกว่าครับ

  • Task “Monitor Shipment” – Completion Condition คือ
    • สินค้าถึงจุดหมายปลายทางแล้ว
  • Task “Approval TOR” – Completion Condition คือ
    • คณะกรรมการ 2 ใน 3 ของทั้งหมดอนุมติ
  • Task “Process Transaction” – Completion Condition คือ
    • ยอดรวมของทุกสินค้า และบริการทั้งหมดต้องเกินจาก Budget ที่ตั้งไว้ หรือ ทุก Transaction สามารถประมวลผลได้ โดยไม่มีปัญหา
    • ** ถ้าเกินจาก Budget เข้า Flow การตัดสินใจของ User
    • ** ถ้าไม่เกินส่งต่อให้ Supplier จัดการ

เดี๋ยวคิดออกอีกแล้วมาเขียนเพิ่มครับ

[BPMN] มาลองใช้ Timer Start Event กันครับ

จาก Blog ตอนที่แล้ว หลังจากไปตบตีกับ Timer Start Event  ที่ไม่สามารถ Deploy ได้มา 5 เต็มๆ หลังจากแก้ปัญหาได้แล้ว คราวนี้มาลองดูตัวอย่างกันครับ หลายคนที่อ่าน Spec ของ BPMN เอาน่าจะงงกันครับ

มาดูกระบวนการแบบง่ายๆกันก่อนครับ

  • Note: กระบวนการที่ไม่ได้เป็นตัวอย่างของกระบวนการทางธุรกิจจริงๆนะครับ แค่เพียงทดสอบ Start Timer Event โดยมีส่วนประกอบ ดังนี้
  • Start Timer Event – จุดนี้พระเอกเลยครับ เพราะมีการกำหนดตาม Spec ของ BPMN ครับ ตาม Date Pattern   R4/2018-06-03T00:00/PT5M Task นี้จะถูก Execute ครั้งแรก ในวันที่ 2018-06-03 เวลาเที่ยงคืน และทำงานไปต่ออีก 4 ครั้ง และทิ้งช่วงครั้งละ 5 นาทีครับ
    • ถ้าดูใน XML ในอยู่ในส่วนของ Timer  <bpmn:timerEventDefinition> และ  <bpmn:timeCycle>  ซึ่งมีการกำหนดรูปแบบของวันที่ตาม ISO 8601 ครับ
    • การ Config ใน Camunda Modeler ตามรูปเลย
  • Script Task “Collect Order Data” – อันนี้ไม่มีอะไรมากครับ แต่ Print “Task Execute” ตามรูปครับ
  • User Task “Accept Data” – สำหรับ Task นี้จริงๆ ผมแค่อยากทดสอบว่า Task ถูก  Execute จริงไหม โดยให้ Task ถูก Assign ที่ user mary และต้องทำ Task ให้เสร็จ (property duedate)ภายใน  2018-07-30T12:00:00  ครับ โดยมี Config ตามรูป
  • End Event – จบการทำงานครับ

รอที่ Job ทำงานครับ

  • ต้องรอเวลา 2018-06-03 เวลาเที่ยงคืน ถ้าขี้เกียจก็เปลี่ยนเวลาเครื่องได้เลยครับ (ถ้าบน Windows ที่ยังไม่ Activate จะไม่สามารถย้อนเวลาได้ครับ)

ดูผลลัพธ์

  • ดูที Console ของ Tomcat ครับ มีการ Execute 5 ครั้ง ครั้งแรกตอน Task Start ครับ และอีก 4 ครั้งตาม Config ครับ (เสียดายที่ลืมเขียนเวลาครับ)
  • มาดูที่ Task ของ Mary ครับ  มีงาน 5 งานมารอให้ mary สะสางครับ
    • เวลา 00:00
    • เวลา 00:05
    • เวลา 00:10
    • เวลา 00:15
    • เวลา 00:20

จบไปแล้วกับ Blog ตอนนี้ครับ ต่อไปถ้าว่าง ผมคงลองเขียน Timer Start Event ตามกระบวนการธุรกิจจริงๆครับ ^__^