Configuring Advanced Settings in Pega's App Express
Why Application Layers? In traditional application development enterprise solutions almost always consist of certain modules. In theory this makes it easier for software designers to select or even maintain what prefab feature is needed. However given the often countless - or even endless life cycle of - versions this challenge of selection can be much harder in practice. In today´s (object oriented) programming languages we have the notion of libraries and packages representing functional modules. Libraries and packages can bundle classes defined by source code amongst other resource files. The obvious goal here is practical reuse which in turn can be improved with the proper separation of concerns. For example, it makes perfect sense to have a package containing all that is needed regarding regular expressions (java.util.string). Or have a common framework to render 3D graphics (OpenGL). For any application bigger than a throwout mock-up it will become apparent that the architecture of the application itself is rather important. In Pega a typical business solution consists of multiple application layers. The base application is usually PegaRULES with is the name of the CRM engine; the heart of the Pega platform. Or it can be one of the industry specific modules such as Healthcare or Insurance. Note: In the mindset of Pega modules always refer to their off-the-shelf solutions which require a separate license. Yet a stack of application layers can accomplish the same as a licensed module albeit more work for your team. Let´s take a deeper look at how App Express can assist you in creating a suitable "Layer Cake". Framework versus Implementation It is important to understand the difference between a framework and an implementation type of application in PRPC although both types can co-exist in Pega applications. Where the sole purpose of a framework is to provide standardized reusable [interface] rules it should not maintain case instance data. That would be the responsibility of the application implemented on top of (or next to) this framework. - Framework and Implementation - Framework only - Implementation only* Flexibility and Complexity All sounds great and powerful that the Pega platform allows for such flexibility. Remember: With great power comes great responsibility &mdash Spiderman (2002). This is way often the likes of a Lead System Architect (LSA) takes special care of this architectural topic. Don´t let this stop you from reading on... The choices made impact the behaviors of rule resolution. Rule Resolution is the patented algorithm which is responsible for selecting the most appropriate business rule in the system. You want this to be flexible and powerful, yet sufficiently intuitive to work with. Recall: Rule Resolution performs pattern inheritance before directed inheritance. Class Hierarchy Before we return to the implications of layering let´s have another look at what the typical class hierarchies can look like within each application layer. We provide an overview of what structure is generated out of the box using App Express. This overview is shown side-by-side and in color to see what the effect is of each option. Choosing for reusable Division and even Unit records with inject more levels into the class hierarchy(!) While this could make sense for single or two layer applications it could be hard to use and maintain for higher "cakes". The essential two questions to answer here are: - Will any of your Divisions have the need for share rules over multiple applications that are not common to the Organization as a whole? (given that they all work on the same PRPC system) - Will any of your Units have the need for share rules over multiple applications that are not common the Organization as a whole? (given that they all work on the same PRPC system) Shared rules could include Integration (-Int), Data (-Data) and Generic kind of rules. If the answer is YES then tick for reuse to maximize pattern inheritance or consider an application layer with its associated pros and cons (TODO: You might need to set directed inheritance appropriately?) Tip: In case you have multiple teams make sure you agree on which team or manager has ownership of which application. Keep in mind the following: - Each Application refers to at least one Built on application — Stick to just one to keep it simple. - Each Application can still consist of (packages as) multiple Rulesets - Each Application allows for distinct access control — thus per layer - Within each application you can have adistinct class hierarchy — not necessarily the same as the class hierarchy in applications below it(!) [Edgar] (2/4/2020 1:07:11 PM)
@edgarverburgTweets by @edgarverburg
Edgar is a software engineer with experience in TIBCO Middleware and Pega Case Managemement. He holds a master's degree in Computer Science with a specialization in Data Visualization & Computer Graphics.