The Constellation configuration paradigm

Constellation applications are built with an “App Studio first” approach.

App Studio hides the complexity around Rulesets and classes. As a developer, using App Studio means you no longer worry about where to create a Rule - the correct Class and Ruleset. You also no longer manage the complex features of pattern-based inheritance, which makes Rulesets so difficult to maintain. With Constellation, you build everything possible in App Studio, switching to Dev Studio only for the advanced configuration options that are not currently available in App Studio.

The justification for the "App Studio first" mindset is that applications built in App Studio have a consistently shorter development time and include best practices and guardrails, ensuring that the application is built with a true Center-out™, Channel-agnostic, upgrade-proof approach. This means fewer bugs, faster time to value, and a consistent user experience, for both the client and the Pega application development team.

With Constellation, the developer mindset changes to focus on achieving the business outcome, not configuring the specifics of a UI. 

Application developers spend less time figuring out the details of the application UI, such as button placement, and more time thinking about the business outcome that results from the workflow, and the data that must be made available for users to resolve Cases quickly and efficiently. Much of the power of Constellation is about implementing a prescribed design for the basic UI and workflow, allowing application developers and clients to focus on the needs of the customer along their journey.

In Pega’s Traditional architecture, application developers create Sections, where every functional chunk of the UI, including every field and control that is visible on the user’s screen, requires some level of customization. Individual Sections are then incorporated in a Harness, another Section, or a paragraph Rule to create the application’s UI. This process requires extensive decision-making, is time-intensive to build, and is challenging to upgrade.

With Constellation, Sections have been replaced with Views. Each View incorporates a prescribed presentation layer that includes information architecture, interactions, accessibility, and data visualization, all built on React’s cutting-edge front-end library. This enables developers to focus on important decisions about the data that is required to successfully resolve Cases.

A Stateless architecture is generally considered to be more scalable, have better performance, and be easier to maintain. Constellation has embraced this shift towards stateless architecture and, as a result, is the fastest orchestration engine Pega has ever built.

The shift to a stateless architecture comes with lots of upside, but it also results in some significant change. The Constellation application is communicating with a stateless server and so the requestor session is terminated after each request.  As a result, the process of debugging an application has changed significantly. The clipboard is released after each Constellation DX API call. That means it is no longer possible to run Clipboard from the end-user portal or run it from Dev Studio and switch to the user portal thread to investigate live data. Instead of the Clipboard, there are numerous powerful debugging tools available for use with Constellation applications.

Also, Data Page functionality and best practices have changed considerably. Because it is stateless, the Constellation architecture does not support temporary pages – you must use Data Pages instead. 

Check your knowledge with the following interaction: