Question
CVS CareMark
US
Last activity: 4 Oct 2018 11:08 EDT
Inline Java Step
One of the Top 10 Guradrails is to Limit the Custom Java. Could any one please explain me the reason behind why we should not write the Custom Java?
Thanks,
Suman
***Updated by moderator: Lochan to add Categories***
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
US
Hello Venkata -
I am moving your question to the Pega Product Support area where it is more likely to get a reply. The Mesh Help area is for questions on how to use the Mesh community.
Thanks,
Amanda
Pegasystems
IN
Did you get a chance to go through this PDN article - https://pdn.pega.com/guardrail-4-avoiding-java-steps-in-activities
This article describes why it is a good idea to avoid custom Java code in Pega platform.
Pegasystems Inc.
FR
Hello Venkata,
The all concept of PRPC is to break the wall between IT and BUSINESS department. We don’t want to see the business guys writing requirements for two years and developers writing Java for the 2 following years.
A PRPC architect should be able to discuss the business needs and configure dynamic and easy to change rules. Also a PRPC architect doesn’t have to be a Java expert, we don’t want to have a new member of the team looking into hundreds of Java lines to finally understand what should be changed to create a quick evolution for a new business requirements.
I believe this is mainly why writing custom java is mentioned on our guardrails.
CVS CareMark
US
Thanks this helps. But what if the requirement triggers to write a Java because Pega does not have any feature to implement the requirement.
Thanks,
Suman
Pegasystems Inc.
IN
In that case you can use a java step to achieve the requirements and also keep providing feedback on those java stuff so same can be incorporated in product for future if they are reusable enough.
We show this as a warning and not an error since we understand there still could be few scenarios where OOTB functions/methods cannot serve the exact purpose.
Again to keep in mind as mentioned in PDN article it's always better to use OOTB methods as they generate optimized java code and it is easier to understand.
Pegasystems Inc.
FR
yes of course,
This could be happening. For a developer the tentation is high to do everything in Java but the main goal at this point should be, how can I make it simple, how can I make it easy to change, to modify and to eventually re-use. What do I really need to do in Java lines and what can be achieved with RULES. This is how I would do it, try to use RULES as much as I can and maybe create Rule-Utility-Function or a Java step to do the remaining work.