Introduction
Almost any Business Process has a conditional flow, which is determined by business logic. An example is to determine the approver for a purchase: In case the order amount does not exceed 50 dollars approval may not be required. However for amounts between 50 and 5000 euro the department-manager may need to approve. Above 5000 euros it may be the business line manager, and above 100000 euros even the CEO.
Cordys BOP-4 allows us to define Business Process logic in multiple ways. This flexibility is nice. However it raises the question: "When to use what"?
Considerations
There are several considerations to make before selecting one of the available alternatives:
Agility:
How frequent are the expected modifications? Should it be possible to perform them without restarting or redeploying the application?
Efficiency:
How much effort does it take to implement the rule?
Complexity/Maintanability:
How complex are the rules: How many steps and different conditions do they contain? Who should be able to perform the change: A business user or an IT engineer.
Functionality:
What functions and data do you need to be able to access? Do you need to be able to access database content? Perform difficult calculations or text operations?
Readability:
Should business be able to read and understand the logic to be able to grasp the business process.
Architecture:
It may be favorable to have your logic itself logically organized, for the following reasons so it is clear for business users and developers where to find certain logic, and to be able to package and deploy logic as much as possible in comprehensible units.
Lets first discuss the options:
Constructs to implement logic
BOP-4 offers the following constructs to implement business logic:
(Note that most of the alternatives above may be used in conjunction with other alternatives.)
BPM Decision steps
The BPM modeling language BPMN allows to directly built logic into Business Process models using the construct "Decision". This step allows to select multiple alternative paths that may be chosen, based on a condition for each path. There may be one default condition that is executed when all other condition evaluate to false. The conditions are defined in "XPath".
+ The logic is visible in the process itself, which contributes to readability and architecture
- Complex logic may explode into an incomprehensible process model
- Changes should pass a complete DTAP cycle
- Advanced functionality will require knowledge of XPath
Recommended usage
- Simple conditions in Business Process, e.g.:
- Checking process inputs
- Checking output from earlier steps
Example of decision step
BPM Mappings
BPM mappings allows the assignment of values in steps in a BPM using Xpath. Xpath contains a number of functions that may be used to implement logic (e.g. Boolean functions, regular expressions and selection expressions).
+ The logic is stored in the BPM model. (Architecture)
- Changes should pass a complete DTAP cycle
- Logic is "hidden" in implementation details
- Limited functionality. More advanced functions require knowledge of XPath
- Logic is less visible / comprehensible to business users
Usage
- Simple logic to influence attribute values
Example of mapping Xpath
Transformation objects
Transformation object transform one data structure into another, using XSLT (which uses XPath underneath). Transformations may be used in BPM or turned into web services.
+ Supports complex logic
+ Reusable
- The logic is stored outside the BPM model. (Architecture)
- Changes should pass a complete DTAP cycle
- More complex logic requires XPath/XSL knowledge.
- Logic is not visible / comprehensible to business users
Usage
- More sophisticated logic used to transform a (business) object into another (business) object
Decision Tables
Decision Tables are a number of rules, containing one or more conditions and one or more (resulting) actions. The conditions use XPath-statements. These use the specified data interface, which is a predefined data structure. The actions concern assigning values to the data structure, or e.g. running a web service.
+ Supports complex logic
+ Reusable
+ The logic is stored in Business comprehensible (=maintainable?) objects.
+- Changes may be delivered in a staging packages, which allows online maintenance by business users. *)
- Best suitable for compact rules: More complexity or functionality may require XPath knowledge
Usage
- More complex IF.. THEN conditions on the the same attributes
- From 2 to 10+ different conditions
- Rules that check values (e.g. amounts) against static numbers, that may be changed frequently (by business users?)
*) For advantages/disadvantages of staging packages, see:
https://wiki.cordys.com/pages/viewpage.action?pageId=164794477
Example of decision table
Business Rules
Business Rules are technically similar to decision tables, but are attached to events on business objects. (e.g. Insert in the database).
Usage
- Validations
- Triggering actions, comparable to stored procedures.
- Triggering BPM-s on specific events
Database queries
Logic may be implemented by executing SQL on the database e.g. via look-up tables, in order to retrieve specific values for specific objects. In order to use the queries with BPM they will have to exposed via a web service.
+ (Static) logic may be altered/extended during run-time. Screens may be offered to Business to alter the look-up tables.
+ May support large amounts of data. (E.g. customer bases)
- Logic is divided over 2 objects: data and query- Logic is separated from business process.
Usage
- Look-up actions of larger amounts of data
- Logic that the user should be able to alter implicitly at run-time by changing the database content
Java
Java allows to write logic in java classes. In order to use it with BPM the java classes will have to be exposed via a WebService.
+ Maximum functionality offered. Suitable for complex rules
- Java requires more objects and more complex settings for deployment
- Changes should pass a complete DTAP cycle
- Require knowledge of Java
- Logic is not visible to business user
Usage
- Complex manipulations of numeric, date or string values.
- Complex logical structures (combined loops, nested IF..THEN-s, switch statements etc)
XForm/java script
Java script may be used in User Interfaces to react on user events and take appropriate actions. This may include validations or UI actions, but also invoking Web Services (which may include business processes and business rules).
+ Directly usable in User Screens
- Not visible nor comprehensible for business users
- Requires java-script skills
- Executed in client, which may cause issues due to different browser types
Usage
- Triggering actions from a User interface (e.g. starting a BPM by a press on a button)
- (Cross) field Validations
It is crucial to select the right option in order to meet the non-functional requirements as stated earlier in this blog.
Regards,
Harald van der Weel
No comments:
Post a Comment