cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

The community will undergo maintenance on October 16th at 10:00 PM PDT and will be unavailable for up to one hour.

Create Custom Business Logic Guide

100% helpful (1/1)

Create Custom Business Logic 

 

Overview

 

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. 

 

Step 1: Completed Example

 

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.

 

Step 2: Rules Engine Introduction

 

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.

 

 

Step 3: Establish Rules

 

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.

 

CategoryDescription
Decision RulesSet of conditions regarding business choices
Validation RulesSet of conditions regarding data verifications
Generation RulesSet of conditions used for data object creation in the system
Calculation RulesSet 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/identifierService Name
Ruleset Thing/ThingTemplate
Rule definition Service Implementation
Rule conditionsService Implementation
Rule actionsService Implementation
Data managementDataTables/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.

 

Step 4: Scenario Business Rule Engine 

 

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.

 

High Level Flow

1Customer makes an order with a Company (Merchant).
1.ACustomer to Merchant order information is created.
2The Merchant creates an order with our delivery company, PTCDelivers.
2.AMerchant order information is populated.
2.BMerchant sets delivery speed requested.
2.CMerchant sets customer information for the delivery.
3The package is added to a vehicle owned by PTCDelivers.
4The vehicle makes the delivery to the merchant's customer.

 

Lower Level: Vehicles

1Package is loaded onto vehicle
1.iBased on the speed selected, add to a truck or plane.
1.iiGround speed option is a truck.
1.iiiAir and Expedited speed options are based on planes usage and trucks when needed.
2Delivery system handles the deliveries of packages
3Delivery system finds the best vehicle option for delivery
4An airplane or truck can be fitted with a limited number of packages.

 

Lower Level: Delivery

1Delivery speed is set by the customer and passed on to PTCDelivers.
2Delivery pricing is set based on a simple formula of (Speed Multiplier * Weight) + $1 (Flat Fee).
2.iGround arrives in 7 days. The ground speed multiplier is $2.
2.iiAir arrives in 4 days. The air speed multiplier is $8.
2.iiiExpedited arrives in 1 day. The expedited speed multiplier is $16.
3Deliveries can be prioritized based on a number of outside variables.
4Deliveries can be prioritized based on a number of outside variables.
5Bulk 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.

 

Step 5: Scenario Data Model Breakdown

 

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.

 

Thing Shapes

ClientThingShapeShape used to represent the various types of clients the business faces (merchants/customers).
VehicleThingShapeShape used to represent different forms of transportation throughout the system.

 

Templates

PlaneThingTemplateTemplate used to construct all representations of a delivery plane.
TruckThingTemplateTemplate used to construct all representations of a delivery truck.
MerchantThingTemplateTemplate used to construct all representations of a merchant where goods are purchased from.
CustomerThingTemplateTemplate used to construct all representations of a customer who purchases goods.

 

Things/Systems

PTCDeliversBusinessLogicThis Thing will hold a majority of the business rule implementation and convenience services.
PTCDeliversA Thing that will provide helper functions in the application.

 

DataShapes

PackageDeliveryDataShapeDataShape used with the package delivery event. Will provide necessary information about deliveries.
PackageDataShapeDataShape used for processing a package.
OrderDataShapeDataShape used for processing customer orders.
MerchantOrderDataShapeDataShape used for processing merchant orders.
MerchantDataShapeDataShape used for tracking merchants.

 

DataTables

OrdersDatabaseDataTable used to store all orders made with customers.

MerchantDatabase

DataTable used to store all information for merchants.

 

 

Step 6: Next Steps

 

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

 

 
Version history
Last update:
‎Nov 14, 2022 09:37 AM
Updated by:
Attachments
Contributors