The community will undergo maintenance on October 16th at 10:00 PM PDT and will be unavailable for up to one hour.
This project will introduce you to creating your first ThingWorx Business Rules Engine.
Following the steps in this guide, you will know how to create your business rules engine and have an idea of how you might want to develop your own. We will teach you how to use your data model with Services, Events, and Subscriptions to establish a rules engine within the ThingWorx platform.
NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 60 minutes.
Download the attached, completed files for this tutorial: BusinessLogicEntities.xml.
The BusinessLogicEntities.xml file contains a completed example of a Business Rules Engine. Utilize this file to see a finished example and return to it as a reference if you become stuck during this guide and need some extra help or clarification. Keep in mind, this download uses the exact names for entities used in this tutorial. If you would like to import this example and also create entities on your own, change the names of the entities you create.
Before implementing a business rule engine from scratch, there are a number of questions that should first be answered. There are times in which a business rule engine is necessary, and times when the work can be down all within regular application coding.
When to Create a Rules Engine:
When there are logic changes that will often occur within the application. This can be decisions on how to do billing based on the state or how machines in factories should operate based on a release.
When business analysts are directly involved in the development or utilization of the application. In general, these roles are often non-technical, but being involved with the application directly will mean the need for a way to make changes.
When a problem is highly complex and no obvious algorithm can be created for the solution. This often covered scenarios in which an algorithm might not be the best option, but a set of conditions will suffice.
Advantages of a Rules Engine
The key reward is having an outlet to express solutions to difficult problems than can be easily verifiable.
A consolidated knowledge base for how a part of a system works and a possible source of documentation. This source of information provides people with varying levels of technical skill to all have insight into a business model.
Business Logic with ThingWorx Core Platform:
A centralized location for development, data management, versioning, tagging, and utilization of third party applications.
The ability to create the rules engine within the ThingWorx platform and outside of ThingWorx platform. Being that the rules engine can be created outside of the ThingWorx platform, third party rules engines can be used.
The ThingWorx platform provides customizable security and provided services that can decrease the time in development.
In order to design a business rules engine and establish rules before starting the development phase, you must capture requirements and designate rule characteristics.
Capture Requirements
The first step to building a business rules engine is to understand the needs of the system and capture the rules necessary for success.
Brainstorm and discuss the conditions that will be covered within the rules engine
Construct a precise list
Identify exact rules and tie them to specific business requirements.
Each business rule and set of conditions within the business rule will need to be independent of other business rules. When there are several scenarios involved, it is best to create multiple rules – one handling each. When business rules are related to similar scenarios, the best methodology is to group the rules into categories.
Category | Description |
Decision Rules | Set of conditions regarding business choices |
Validation Rules | Set of conditions regarding data verifications |
Generation Rules | Set of conditions used for data object creation in the system |
Calculation Rules | Set of conditions that handle data input utilized for computing values or assessments |
Designate Rule Characteristics
Characteristics for the rules include, but are not limited to:
Naming conventions/identifiers
Rule grouping
Rule definition/description
Priority
Actions that take place in each rule.
After this is completed, you will be ready to tie business requirements to business rules, and those directly to creating your business rules engine within the platform.
Rules Translation to ThingWorx
There are different methods for how the one to one connections can be made between rules and ThingWorx. The simplified method below shows one way that all of this can be done within the ThingWorx platform:
Characteristic | ThingWorx Aspect |
Rule name/identifier | Service Name |
Ruleset | Thing/ThingTemplate |
Rule definition | Service Implementation |
Rule conditions | Service Implementation |
Rule actions | Service Implementation |
Data management | DataTables/Streams |
Much of the rule implementation is handled by ThingWorx Services using JavaScript. This allows for direct access to data, other provided Services, and a central location for all information pertaining to a set of rules. The design provided above also allows for easier testing and security management.
An important aspect to think about before implementing your business rules engine, is how the Service implementation will flow.
Will you have a singular entry path for the entire rules engine? Or will you have several entries based on what is being requested of it?
Will you have create only Services to handle each path? Or will you create Events and Subscriptions (Triggers and Listeners) in addition to Services to split the workload?
Based on how you answer those questions, dictates how you will need to break up your implementation. The business rules for the delivery truck scenario are below. Think about how you would break down this implementation.
1 | Customer makes an order with a Company (Merchant). |
1.A | Customer to Merchant order information is created. |
2 | The Merchant creates an order with our delivery company, PTCDelivers. |
2.A | Merchant order information is populated. |
2.B | Merchant sets delivery speed requested. |
2.C | Merchant sets customer information for the delivery. |
3 | The package is added to a vehicle owned by PTCDelivers. |
4 | The vehicle makes the delivery to the merchant's customer. |
1 | Package is loaded onto vehicle |
1.i | Based on the speed selected, add to a truck or plane. |
1.ii | Ground speed option is a truck. |
1.iii | Air and Expedited speed options are based on planes usage and trucks when needed. |
2 | Delivery system handles the deliveries of packages |
3 | Delivery system finds the best vehicle option for delivery |
4 | An airplane or truck can be fitted with a limited number of packages. |
1 | Delivery speed is set by the customer and passed on to PTCDelivers. |
2 | Delivery pricing is set based on a simple formula of (Speed Multiplier * Weight) + $1 (Flat Fee). |
2.i | Ground arrives in 7 days. The ground speed multiplier is $2. |
2.ii | Air arrives in 4 days. The air speed multiplier is $8. |
2.iii | Expedited arrives in 1 day. The expedited speed multiplier is $16. |
3 | Deliveries can be prioritized based on a number of outside variables. |
4 | Deliveries can be prioritized based on a number of outside variables. |
5 | Bulk rate pricing can be implemented. |
How would you implement this logic and add in your own business logic for added profits? Logic such as finding the appropriate vehicle to make a delivery can be handled by regular Services. Bulk rates, prioritizing merchants and packages, delivery pricing, and how orders are handled would fall under Business Logic. The MerchantThingTemplate Thing contains a DataChange Subscription for it's list of orders. This Subscription triggers an Event in the PTCDelivers Thing.
The PTCDelivers Thing contains an Event for new orders coming in and a Subscription for adding orders and merchants to their respective DataTables. This Subscription can be seen as the entry point for this scenario. Nevertheless, you can create a follow-up Service to handle your business logic. We have created the PTCDeliversBusinessLogic to house your business rules engine.
This guide will not go into detail of the data model of the application, but here is a high level view of the roles played within the application.
ClientThingShape | Shape used to represent the various types of clients the business faces (merchants/customers). |
VehicleThingShape | Shape used to represent different forms of transportation throughout the system. |
PlaneThingTemplate | Template used to construct all representations of a delivery plane. |
TruckThingTemplate | Template used to construct all representations of a delivery truck. |
MerchantThingTemplate | Template used to construct all representations of a merchant where goods are purchased from. |
CustomerThingTemplate | Template used to construct all representations of a customer who purchases goods. |
PTCDeliversBusinessLogic | This Thing will hold a majority of the business rule implementation and convenience services. |
PTCDelivers | A Thing that will provide helper functions in the application. |
PackageDeliveryDataShape | DataShape used with the package delivery event. Will provide necessary information about deliveries. |
PackageDataShape | DataShape used for processing a package. |
OrderDataShape | DataShape used for processing customer orders. |
MerchantOrderDataShape | DataShape used for processing merchant orders. |
MerchantDataShape | DataShape used for tracking merchants. |
OrdersDatabase | DataTable used to store all orders made with customers. |
MerchantDatabase | DataTable used to store all information for merchants. |
Congratulations! You've successfully completed the Create Custom Business Logic guide, and learned how to:
Create business logic for IoT with resources provided in the ThingWorx platform
Utilize the ThingWorx Edge SDK platforms with a pre-established business rule engine
We hope you found this guide useful.
The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Implement Services, Events, and Subscriptions.