Most Recent

Blog Post

Creating a SOAP Service in Pega

SOAP has been with us for quite a while now and has come a long way since the W3C´s recommendation of version 1.2 in 2007. Many application platforms adopt this standard protocol for the exchange of information in XML formatted messages and so does Pega. Still SOAP just provides (and is just supposed to just provide) the groundwork to build services on. The current trend is to build microservices to ease reuse and maintainability. One could think of these as services that provide a clear API consisting of set of operations on a single specific data object. This data object should preferable represent a well-known entity in real life for the service to make sense. Common examples of these entities would be a Customer, Product, Order, etc. but I leave this to the practice of Master Data Management for now. Typical generic entities in the world of PRPC are Case, WorkParty, Attachment or any object classes that you might have implemented and would like to operate on from outside of PRPC. Let me show you how to construct such a service like I´ve done for a Dutch insurance company... [Edgar] (2/4/2020 1:11:28 PM)

 

Generating unique numbers in Pega

Big Data Still a lot of structure data Most of it in the form of lists Data table Unique numbers GUID vs Sequence Auto-numbering sequence Predefined number ranges Brings us to writing another convenience function in PRPC... [Edgar] (2/9/2020 3:33:40 PM)

 

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)

 

Twitter Feed

@edgarverburg

Bio

About Edgar

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.

In his spare time Edgar reads SOS and Empire, mixes house music, blogs and writes film reviews or goes running.


Currently employed by SynTouch he is specifically looking for a PRPC project. Feel free to contact him for challenging assignments through LinkedIn.