Why Java code is not recommended?
May I know why directly put Java code is not recommended? But it is so frustrating to seek the right method to use from your DSL oceans. Have you ever count how many DSLs have you invented?
When rule, expression Builder, activity, Data transform, parameter, all have their won syntax. Why?
Pegasystems Inc.
IN
Hi ParisQ07,
Thanks for posting on PSC.
I do understand convenience and ease of implementing with Java code directly.
But I feel it's not recommended due to multiple reasons, foremost being maintainability and upgrade. Pega takes care of the changed logic in Engine, Integration or any other layer of the application while upgrading environment to latest Pega version. And Pega's main objective is agility with less coding rather providing OOTB feature for implementing most of the business requirement. Though for some additional requirement which couldn't be fulfilled with existing feature, we do accept an Enhancement request/feedback on product subject to review.
DSLs are small, expressive programming languages custom designed for specific tasks, like BPM and progressing towards complete CRM with SaaS for non-programmer as well. Another reason is security, which I don't have much idea but Java code is less promoted it being a reason as well.
We do have multiple rules having their own syntax for different use-cases.
A small example: When we do have an expression which is expected to be used at multiple places, for reusability purposes developer is expected to create a "When" rule having expression and later configuring it everywhere required. There are small pre-created codes for some intended purposes.
Hope this answer was satisfactory, though feel free to raise your queries.
Thanks,
Hi ParisQ07,
Thanks for posting on PSC.
I do understand convenience and ease of implementing with Java code directly.
But I feel it's not recommended due to multiple reasons, foremost being maintainability and upgrade. Pega takes care of the changed logic in Engine, Integration or any other layer of the application while upgrading environment to latest Pega version. And Pega's main objective is agility with less coding rather providing OOTB feature for implementing most of the business requirement. Though for some additional requirement which couldn't be fulfilled with existing feature, we do accept an Enhancement request/feedback on product subject to review.
DSLs are small, expressive programming languages custom designed for specific tasks, like BPM and progressing towards complete CRM with SaaS for non-programmer as well. Another reason is security, which I don't have much idea but Java code is less promoted it being a reason as well.
We do have multiple rules having their own syntax for different use-cases.
A small example: When we do have an expression which is expected to be used at multiple places, for reusability purposes developer is expected to create a "When" rule having expression and later configuring it everywhere required. There are small pre-created codes for some intended purposes.
Hope this answer was satisfactory, though feel free to raise your queries.
Thanks,
Asif
Accepted Solution
NCS Group
SG
So basically you are saying that:
1. The reason we shouldn't write JAVA, because that the Engine API may get upgraded.
2. OOTB features are all we need. If there is no such feature, we should drop you guys a feature request.
3. You want to provide training to Non-programmer. instead of teaching them Programming language, DSLs are taught, due to their simplicity.
Here is my thoughts:
1. Most of the reasons are very true, and are most likely very necessary as well. But those pros comes with cons.
2. By saying OOTB features, you actually mean reinvented wheels. Beware those wheels will age. the more you create, the more you have to maintain, upgrade, there will also be more combinations to test.
3. Pega can be very programmer-unfriendly. If I miss coding, I should switch job. If I love Pega, I need to beware the concept of pega rules may or may not be the same with what we get used to. e.g. the PegaUnit is not unit test, the pega Class is not a Java class. Also when ever I can write one liner, I need to search for the right rule from the ocean of pega OOTB features. 1 DSL can be simpler than JAVA, but 10 is certainly not.
My suggestion is try making it a bit more programmer friendly by following measures:
1. Reduce the DSLs involved, select a subset of JAVA libraries. Most likely they will be very similar.
So basically you are saying that:
1. The reason we shouldn't write JAVA, because that the Engine API may get upgraded.
2. OOTB features are all we need. If there is no such feature, we should drop you guys a feature request.
3. You want to provide training to Non-programmer. instead of teaching them Programming language, DSLs are taught, due to their simplicity.
Here is my thoughts:
1. Most of the reasons are very true, and are most likely very necessary as well. But those pros comes with cons.
2. By saying OOTB features, you actually mean reinvented wheels. Beware those wheels will age. the more you create, the more you have to maintain, upgrade, there will also be more combinations to test.
3. Pega can be very programmer-unfriendly. If I miss coding, I should switch job. If I love Pega, I need to beware the concept of pega rules may or may not be the same with what we get used to. e.g. the PegaUnit is not unit test, the pega Class is not a Java class. Also when ever I can write one liner, I need to search for the right rule from the ocean of pega OOTB features. 1 DSL can be simpler than JAVA, but 10 is certainly not.
My suggestion is try making it a bit more programmer friendly by following measures:
1. Reduce the DSLs involved, select a subset of JAVA libraries. Most likely they will be very similar.
2. Advocate the idea of "pure function"(1 input 1 output, no side-effects). Those things can be actually unit tested. Instead of worrying about when, expression, defined expression, validation, edit validation, activity, data transform, on click event, etc. A map-reduce-filter is all we need. So many rules can be replaced by a simple elegant fully-tested pure function rule
3. The overall system will be much easier to test, easier to do pear review & version control as well. As result the PEGA system and all the apps built on top of it will have less chance to go wrong.
You guys have added too many features in, maybe it's the time for you to do some subtractions in your future product.