BRP
Business Rule Processor (BRP) is a diamond in the configurators toolkit, and it should be at the forefront of Oracle's marketing efforts to license more copies of Siebel. If you've never heard of BRP, then you've never lived Siebel, just imagine an Application that is fast, which can be complex and flexible, and at the same time being virtually script free.
Amazing as it is, it has a few flaws, rules cannot be validated, there are UI bugs that make development annoying, rules dont synchronise across multiple OMs, procedures don't support parameters, but the most obvious flaw is the debugging capabilities, every thing is just dumped to the OM logs, no workflow instance monitor, or TBUI like debugger around here, just old fashion log files.
However the design approach of BRP is apparent, the first release of BRP was meant to deliver a fast and stable tool, anything else was second priority, but there is a question that hangs around the future of BRP, with OPA being crowned the rules engine of choice within Oracle. There seems to be a gap in the strategy, OPA is a policy determination engine, while BRP is an eScript replacement, one is business focused, while the other is technically focused, two different things in my opinion.
So what if you dont have BRP on your project? I was engaged by a customer to design solutions to a common problem, getting rid of a sea of code and improving maintainability. All the standard Siebel declarative and non declarative options were considered and weighed up against another. One of the key components of this redesign was a rules engine, and BRP was the primary choice, but due to various factors, including whether BRP could be sourced. I was engaged to build a BRP replacement: a custom rules engine that overcomes some of BRP's limitations that is declarative and fully customisable.
JL Engine
For the sake of identity, the rules engine is conveniently referred to as JL Engine.
Imagine that you could extend the native Siebel Query Language Expressions, and create your own functions, that can be accessed declaratively. This is a powerful feature that allows developers to bypass many of the complexities around implementing rules using the traditional Siebel expressions, and potentially replace a large amount of scripting.
What kind of complexities do you ask? To fire your imagination, how about we solve the EAI Scriptless Phone challenge using this new engine? Previously I demonstrated the power of BRP, and showed how BRP can be used to solve this challenge. It required 15 expressions to complete the task
If you had control over your expressions, you could design convienent utitlities to more effectively solve this challenge, and also re-use these utilities across the application, or you could cheat and design a fancy expression that solves the EAI phone challenge in 1 step, but in consideration of good application design, we are going to design components which are re usable, hence this new rules engine solves the challenge in 8 steps.
Here are some of the new exotic expressions that will aid us in this Challenge
Solving the EAI Challenge with JL Engine
1. Getting the LF character
This was the original stumbling block to solve this challenge when it was first announced. I presented a solution using XSLT. Impossible Siebel reader Dos, then chimed in with other 2 solutions.
BS: SSSE Address Parser
Method: GetCRLF
This business service returns a CRLF, which is actually two characters chr(10) + chr(13), so the return string has to be post processed to return only chr(10)
SetProfileAttr("LF","\n")
Using SetProfileAttr to set \n, and retrieving it using GetProfileAttr is elegant, but requires two steps. Using our JL Engine expression below allows us to complete this in one step
2. Separating the Phone and Format from the EAI Phone String
Once we have the LF character, string expressions can be used get our string. In BRP this is done using two expressions Instr is used to find the position of the LF character, then Left/Right is used to chop the string.
"+44123456789LF(00) 00 000 000"
Using our JL Engine expression below allows us to complete this in one step. GetArrayPart splits the string, and returns the desired index.
To make things harder, the phone value has the international prefix, which is additional to the number and should not have the format applied to it. BRP and the original XSLT solution solved this by using two cursors, one to track the position of a Mask character, and the other to track the position of phone digit that corresponds to this mask characters, and involved looping and recursion. Using our JL Engine expression below allows us to complete this in one step (three nested expressions)
JL Engine solution step by step
The screen shots below provide the step by step detail, of how the solution is physically implemented in the JL Engine.
1. Create a rule and define all the properties
2. Create a Main procedure, and create the 8 steps as shown, thats all.
3. Test the Rule in Business service simulator, or if you are a lucky customer that has SiebUnits on your project, you could write a declarative test case, to test your declarative rules engine.
The test results applet shows the correct output value for our challenge, with the test case passing in 32ms.
Conclusion
This new custom rules engine passes the EAI Phone challenge with flying colors, and manages to do it more nimbly, with less steps of declaration, thanks to its custom inbuilt functions, but is this enough to make it a superior solution than BRP? Both engines are built for different purposes, but share a lot of similiarities.
BRP is a speed demon, and was built for handling complex calculations, which just happened to come with a declarative engine that allows a project to banish casual scripting, but sadly it is not a universal module, and looks likely to be sidelined from future updates.
JL Engine was also designed to remove scripting, comes built with connectors to a custom application framework, it achieves speed by taking shortcuts and also provides a declarative interface for developers, but best of all it is openly extensible, allowing developers to build upon the gaps of BRP with custom requirements.
Want a real time instance monitor that shows step by step execution, condition determination and variable assignment. You got it, JL Engine comes with a rule audit history view to do just this. Want a visulizer that shows the rule composition in a graphical UI? No problem, JL Engine comes with this as well. Want a expression builder that allows developers to build rules faster? Yes Sir, we have that covered.
So how about some performance figures? In the next episode of the EAI Scriptless phone challenge. I will compare all the declarative solutions to this challenge, and provide performance metrics to determine which is the fastest and the best, so be prepared to be blown away.
1. XSLT using Xalan Engine
2. XSLT using Saxon Engine
3. BRP Engine
4. JL Engine
Note 1: While other solutions exist that simply strip away the phone format mask, the above script less solutions apply the format to the phone and have the flexibility to deal with the international prefix.
Note 2: The JL Engine is not available commercially. The product has a limited audience, and is only available to selected customers.
Business Rule Processor (BRP) is a diamond in the configurators toolkit, and it should be at the forefront of Oracle's marketing efforts to license more copies of Siebel. If you've never heard of BRP, then you've never lived Siebel, just imagine an Application that is fast, which can be complex and flexible, and at the same time being virtually script free.
Amazing as it is, it has a few flaws, rules cannot be validated, there are UI bugs that make development annoying, rules dont synchronise across multiple OMs, procedures don't support parameters, but the most obvious flaw is the debugging capabilities, every thing is just dumped to the OM logs, no workflow instance monitor, or TBUI like debugger around here, just old fashion log files.
However the design approach of BRP is apparent, the first release of BRP was meant to deliver a fast and stable tool, anything else was second priority, but there is a question that hangs around the future of BRP, with OPA being crowned the rules engine of choice within Oracle. There seems to be a gap in the strategy, OPA is a policy determination engine, while BRP is an eScript replacement, one is business focused, while the other is technically focused, two different things in my opinion.
So what if you dont have BRP on your project? I was engaged by a customer to design solutions to a common problem, getting rid of a sea of code and improving maintainability. All the standard Siebel declarative and non declarative options were considered and weighed up against another. One of the key components of this redesign was a rules engine, and BRP was the primary choice, but due to various factors, including whether BRP could be sourced. I was engaged to build a BRP replacement: a custom rules engine that overcomes some of BRP's limitations that is declarative and fully customisable.
JL Engine
For the sake of identity, the rules engine is conveniently referred to as JL Engine.
Imagine that you could extend the native Siebel Query Language Expressions, and create your own functions, that can be accessed declaratively. This is a powerful feature that allows developers to bypass many of the complexities around implementing rules using the traditional Siebel expressions, and potentially replace a large amount of scripting.
What kind of complexities do you ask? To fire your imagination, how about we solve the EAI Scriptless Phone challenge using this new engine? Previously I demonstrated the power of BRP, and showed how BRP can be used to solve this challenge. It required 15 expressions to complete the task
If you had control over your expressions, you could design convienent utitlities to more effectively solve this challenge, and also re-use these utilities across the application, or you could cheat and design a fancy expression that solves the EAI phone challenge in 1 step, but in consideration of good application design, we are going to design components which are re usable, hence this new rules engine solves the challenge in 8 steps.
Here are some of the new exotic expressions that will aid us in this Challenge
ApplyMask(Mask,MaskCharacter,Value) //Usage: ApplyMask("$XX.XX","X","1234") = $12.34
AscFromChar(AsciiCode) //Usage: AscFromChar("65") = A
GetArrayPart(ArrayString,Delimiter,ArrayIndex) //Usage: GetArrayPart("A,B,C",",","1") = B
CountChar(Value,CharToCount) //Usage: CountChar("$XX.XX","X") = 4
Solving the EAI Challenge with JL Engine
1. Getting the LF character
This was the original stumbling block to solve this challenge when it was first announced. I presented a solution using XSLT. Impossible Siebel reader Dos, then chimed in with other 2 solutions.
BS: SSSE Address Parser
Method: GetCRLF
This business service returns a CRLF, which is actually two characters chr(10) + chr(13), so the return string has to be post processed to return only chr(10)
SetProfileAttr("LF","\n")
Using SetProfileAttr to set \n, and retrieving it using GetProfileAttr is elegant, but requires two steps. Using our JL Engine expression below allows us to complete this in one step
AscFromChar("10")
2. Separating the Phone and Format from the EAI Phone String
Once we have the LF character, string expressions can be used get our string. In BRP this is done using two expressions Instr is used to find the position of the LF character, then Left/Right is used to chop the string.
"+44123456789LF(00) 00 000 000"
Using our JL Engine expression below allows us to complete this in one step. GetArrayPart splits the string, and returns the desired index.
GetArrayPart("+44123456789LF(00) 00 000 000" ,"LF","0")3. Applying the Format Mask to the Phone Value
To make things harder, the phone value has the international prefix, which is additional to the number and should not have the format applied to it. BRP and the original XSLT solution solved this by using two cursors, one to track the position of a Mask character, and the other to track the position of phone digit that corresponds to this mask characters, and involved looping and recursion. Using our JL Engine expression below allows us to complete this in one step (three nested expressions)
CountChar("(00) 00 000 000","0")Counts the number of format characters, which we then use to perform a Left/Right on the phone string to split the prefix and phone Once we have the phone without the international prefix, we use the following Expression to get the formatted number.
ApplyMask("(00) 00 000 000","0","123456789")The joined expression looks like this
ApplyMask("(00) 00 000 000","0",Right("+44123456789",CountChar("(00) 00 000 000","0")) )The final step is to concat the Prefix with the result from the above step to get our result
JL Engine solution step by step
The screen shots below provide the step by step detail, of how the solution is physically implemented in the JL Engine.
1. Create a rule and define all the properties
2. Create a Main procedure, and create the 8 steps as shown, thats all.
3. Test the Rule in Business service simulator, or if you are a lucky customer that has SiebUnits on your project, you could write a declarative test case, to test your declarative rules engine.
The test results applet shows the correct output value for our challenge, with the test case passing in 32ms.
Conclusion
This new custom rules engine passes the EAI Phone challenge with flying colors, and manages to do it more nimbly, with less steps of declaration, thanks to its custom inbuilt functions, but is this enough to make it a superior solution than BRP? Both engines are built for different purposes, but share a lot of similiarities.
BRP is a speed demon, and was built for handling complex calculations, which just happened to come with a declarative engine that allows a project to banish casual scripting, but sadly it is not a universal module, and looks likely to be sidelined from future updates.
JL Engine was also designed to remove scripting, comes built with connectors to a custom application framework, it achieves speed by taking shortcuts and also provides a declarative interface for developers, but best of all it is openly extensible, allowing developers to build upon the gaps of BRP with custom requirements.
Want a real time instance monitor that shows step by step execution, condition determination and variable assignment. You got it, JL Engine comes with a rule audit history view to do just this. Want a visulizer that shows the rule composition in a graphical UI? No problem, JL Engine comes with this as well. Want a expression builder that allows developers to build rules faster? Yes Sir, we have that covered.
So how about some performance figures? In the next episode of the EAI Scriptless phone challenge. I will compare all the declarative solutions to this challenge, and provide performance metrics to determine which is the fastest and the best, so be prepared to be blown away.
1. XSLT using Xalan Engine
2. XSLT using Saxon Engine
3. BRP Engine
4. JL Engine
Note 1: While other solutions exist that simply strip away the phone format mask, the above script less solutions apply the format to the phone and have the flexibility to deal with the international prefix.
Note 2: The JL Engine is not available commercially. The product has a limited audience, and is only available to selected customers.