ระบบประมวลผลกฎทางธุรกิจ (Business Rules Engine)คือระบบซอฟต์แวร์ ที่ประมวล ผลกฎทางธุรกิจอย่างน้อยหนึ่งข้อในสภาพแวดล้อมการ ทำงานจริง กฎเหล่านี้อาจมาจากข้อบังคับ ทางกฎหมาย ("พนักงานสามารถถูกไล่ออกได้ด้วยเหตุผลใดๆ ก็ได้ หรือไม่มีเหตุผลเลยก็ได้ แต่ต้องไม่ใช่เหตุผลที่ผิดกฎหมาย") นโยบายของบริษัท ("ลูกค้าทุกคนที่ใช้จ่ายมากกว่า 100 ดอลลาร์ในครั้งเดียวจะได้รับส่วนลด 10%") หรือแหล่งอื่นๆ ระบบประมวลผลกฎทางธุรกิจช่วยให้สามารถกำหนด ทดสอบ ดำเนินการ และบำรุงรักษานโยบายของบริษัทและข้อตัดสินใจในการดำเนินงานอื่นๆ แยกต่างหากจากโค้ดแอปพลิเคชันได้

โดยทั่วไปแล้ว ระบบประมวลผลกฎจะรองรับกฎ ข้อเท็จจริง ลำดับความสำคัญ (คะแนน) การยกเว้นร่วมกัน เงื่อนไขเบื้องต้น และฟังก์ชันอื่นๆ

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

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

บทความในComputerworld ติดตามเอ็นจิ้ น กฎเกณฑ์ในช่วงต้นทศวรรษ 1990 และผลิตภัณฑ์จากบริษัทต่างๆ เช่นPegasystems , Fair Isaac Corp, ILOG ^{[ 1 ]}และ eMerge ^{[ 2 ]}จากSapiens

องค์กรหลายแห่งพยายามสร้างกฎเกณฑ์โดยผสมผสานแง่มุมของสิ่งที่โดยทั่วไปถือว่าเป็นการ ออกแบบ เวิร์กโฟลว์เข้ากับการออกแบบกฎเกณฑ์แบบดั้งเดิม ความล้มเหลวในการแยกสองแนวทางนี้อาจนำไปสู่ปัญหาในการนำกฎทางธุรกิจและเวิร์กโฟลว์กลับมาใช้ใหม่และควบคุมได้ แนวทางการออกแบบที่หลีกเลี่ยงปัญหาดังกล่าวจะแยกบทบาทของกฎทางธุรกิจและเวิร์กโฟลว์ดังนี้: ^{[ 3 ]}

• กฎเกณฑ์ทางธุรกิจก่อให้เกิดความรู้
• เวิร์กโฟลว์ทำหน้าที่ดำเนินการทางธุรกิจ

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

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

ในการสร้างสถาปัตยกรรมที่ใช้กลไกการประมวลผลกฎทางธุรกิจ จำเป็นอย่างยิ่งที่จะต้องสร้างการบูรณาการระหว่าง แพลตฟอร์ม BPM (Business Process Management) และBRM (Business Rules Management) ซึ่งอยู่บนพื้นฐานของกระบวนการที่ตอบสนองต่อเหตุการณ์หรือตรวจสอบการตัดสินใจทางธุรกิจที่กำหนดโดยกฎทางธุรกิจ มีผลิตภัณฑ์บางอย่างในตลาดที่ให้การบูรณาการนี้โดยตรง ในบางกรณี การสร้างนามธรรมและการบูรณาการประเภทนี้จะต้องพัฒนาขึ้นภายในโครงการหรือองค์กรเฉพาะนั้นๆ

เอนจินกฎที่ใช้ Java ส่วนใหญ่มีอินเทอร์เฟซระดับการเรียกใช้ทางเทคนิค โดยอิงตาม มาตรฐาน อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API) JSR-94 เพื่อให้สามารถบูรณาการกับแอปพลิเคชันต่างๆ ได้ และเอนจินกฎจำนวนมากยังอนุญาตให้มี การบูรณา การแบบบริการเป็นหลัก ผ่านมาตรฐานบนเว็บ เช่นWSDLและSOAP

เครื่องมือสร้างกฎส่วนใหญ่มีความสามารถในการพัฒนานามธรรมของข้อมูลที่แสดงถึงเอนทิตีทางธุรกิจและความสัมพันธ์ที่ควรใช้ในการเขียนกฎ โดยทั่วไปแล้วแบบจำลองเอนทิตีทางธุรกิจ นี้ สามารถเติมข้อมูลได้จากแหล่งข้อมูลที่หลากหลาย รวมถึงXML , POJO , ไฟล์ข้อความธรรมดาฯลฯ ไม่มีภาษามาตรฐานสำหรับการเขียนกฎเอง เครื่องมือหลายตัวใช้ ไวยากรณ์คล้าย Javaในขณะที่บางตัวอนุญาตให้กำหนดภาษาที่กำหนดเองซึ่งเป็นมิตรกับธุรกิจได้

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

มีกลไกการสร้างกฎหลายประเภท โดยทั่วไปแล้ว กลไกเหล่านี้จะแตกต่างกันในวิธีการกำหนดเวลาการทำงานของกฎ

ระบบประมวลผลกฎส่วนใหญ่ที่ธุรกิจใช้กันนั้นเป็นการประมวลผลแบบส่งต่อ (forward chaining ) ซึ่งสามารถแบ่งย่อยออกเป็นสองประเภทได้แก่:

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

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

นอกจากนี้ กลไกการค้นหาบางระบบยังรองรับการเชื่อมโยงย้อนกลับ (backward chaining ) ในกรณีนี้ กลไกการค้นหาจะพยายามแก้ไขข้อเท็จจริงเพื่อให้สอดคล้องกับเป้าหมายที่กำหนดไว้ มักเรียกกันว่ากลไกที่ขับเคลื่อนด้วยเป้าหมายเนื่องจากพยายามตรวจสอบว่าสิ่งใดมีอยู่จริงหรือไม่โดยอาศัยข้อมูลที่มีอยู่

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

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

มีบางสถานการณ์ที่ การอนุมานตาม ตรรกะคลุมเครืออาจเหมาะสมกว่า โดยใช้ฮิวริสติกในการประมวลผลกฎ แทนที่จะใช้กฎบูลีน ตัวอย่างเช่น การจำแนกประเภทลูกค้า การอนุมานข้อมูลที่หายไป การคำนวณมูลค่าลูกค้า เป็นต้น ภาษา DARL ^{[ 4 ]}และเครื่องมืออนุมานและตัวแก้ไขที่เกี่ยวข้องเป็นตัวอย่างของแนวทางนี้

หนึ่งในกรณีการใช้งานทั่วไปของเอนจินกฎคือการควบคุมการเข้าถึงแอปพลิเคชันแบบมาตรฐานOASISกำหนดสถาปัตยกรรมเอนจินกฎและมาตรฐานเฉพาะสำหรับการควบคุมการเข้าถึงที่เรียกว่าXACML (eXtensible Access Control Markup Language) ความแตกต่างที่สำคัญอย่างหนึ่งระหว่างเอนจินกฎ XACML กับเอนจินกฎทางธุรกิจคือ เอนจินกฎ XACML นั้นไม่มีสถานะและไม่สามารถเปลี่ยนแปลงสถานะของข้อมูลใดๆ ได้ เอนจินกฎ XACML ซึ่งเรียกว่าจุดตัดสินใจนโยบาย (Policy Decision Pointหรือ PDP) จะคาดหวังคำถามแบบไบนารี ใช่/ไม่ใช่ เช่น "อลิซสามารถดูเอกสาร D ได้หรือไม่" และส่งคืนการตัดสินใจ เช่น อนุญาต/ไม่อนุญาต

• กฎทางธุรกิจ
• ระบบการผลิต
• เครื่องมืออนุมาน
• อัลกอริทึม Rete
• กฎการแผ่ขยายแบบลูกโซ่
• ระบบจัดการกฎทางธุรกิจ
• ตัวให้เหตุผลเชิงความหมาย
• เครื่องมือจัดการเวิร์กโฟลว์
• ภาษาการดำเนินการกระบวนการทางธุรกิจ (BPEL)
• รายชื่อเครื่องมือ BPEL
• รายชื่อเครื่องมือประมวลผล BPMN 2.0

• เทย์เลอร์, เจมส์; ราเดน, นีล (2007). ระบบอัจฉริยะ (ที่เพียงพอ). เพรนทิซ ฮอลล์. ISBN 0-13-234796-2.
• David Linthicum (14 กุมภาพันธ์ 2550). "Rules Engines and SOA". InfoWorld, 14 กุมภาพันธ์ 2550. สืบค้นเมื่อ 23 กันยายน 2552 จากhttp://www.infoworld.com/d/architecture/rules-engines-and-soa-158

• มีแนวทางใดบ้างในการตัดสินใจว่าจะใช้ระบบประมวลผลกฎหรือไม่?