Traditional PegaApp (or manual Rule-Application) as Constellation app

 1. Open Rule-Application, set pyIsConstellationApp=true, pxUseDXAPI=true. Save the app record.

2. Execute pzRegisterConstellationAppAsOAuth2Client in the context of Rule-Applicaiton.

3. It should create oAuth client registration record.

Database indexes

Index unique scan

It occurs when the db looks up a single unique row and is able to stop searching the very instant that row is found. No sequential reading.

Two strict requirements - A unique constraint exists (PK, Unique), An equality operator is used. 

Index range scan

 Accesses a continuous segment of pre-sorted index entries using leading columns.

The database locates the starting value in an index and reads consecutive leaf blocks sequentially until it hits the upper boundary of the range

Requires the query's WHERE clause to reference the leading (leftmost) column of a composite index

Best used for range operators (BETWEEN, <,>,>=,<=) or equality conditions (=) on primary prefix of the index.  (works well if the first column in the index where clause applied with equality check, and rest with ranges)

Highly efficient and selective when fetching small percentage of total table rows

Index skip scan

The database finds distinct values of the omitted leading column and performs a separate mini-range scan for each distinct prefix value.

Triggers on a composite index even when the leading column is missing from the WHERE clause

Best used for composite indexes where the leading column has low cardinality (very few distinct values like gender, status_code..etc) and subsequent columns are well-filtered.

Can prevent expensive full table scans, but can degrade performance significantly if the skipped leading column has high cardinality because it multiplies the number of internal lookups.

Index full scan

An index full scan is a DB operation where the system reads every single block of a B-tree index from start to finish in sorted key order.

When and shy it is used? Avoiding sorts : (1) The optimizer chooses an index full scan when a query has an ORDER BY or GROUP BY clause that matches the sorted columns in the index. (2) If all the columns requested by the query exist inside the index, the db can process the entire request without touching the main base table

Kafka vs REST

 

REST API = synchronous request-response communication.

Kafka = asynchronous event streaming/message broker.

Throughput

Suppose you need to process 100,000 transactions per second.

REST

Every request:

• Opens/uses connection
• Executes logic
• Returns response

The API server becomes the bottleneck.

Kafka

Messages are:

• Batched
• Sequentially written to disk
• Consumed independently

Kafka is designed for extremely high throughput.

Winner for throughput:

✅ Kafka

Example:

• Website clickstream events
• Telemetry data
• IoT sensor data
• Log aggregation

Scalability

REST

Scaling often means:

• More API instances
• Load balancers
• Database scaling

All consumers hit the same API.

Kafka

You can independently scale:

• Producers
• Brokers
• Consumer groups

If traffic doubles:

• Add more consumers
• Rebalance partitions

Winner:

✅ Kafka

Reliability Under Load

REST

If a downstream service is unavailable:

• Requests timeout
• Retries increase load
• Cascading failures may occur

Kafka

Messages remain in the broker:

• Consumers can be offline
• Processing resumes later
• No message loss (with proper configuration)

Winner:

✅ Kafka

Fan-Out Performance

Suppose an order event must be consumed by:

• Billing service
• Inventory service
• Analytics service
• Notification service

REST

Order Service
    |
    |--> Billing API
    |--> Inventory API
    |--> Analytics API
    |--> Notification API

Many network calls.

Kafka

Order Service --> Kafka Topic

Billing Consumer
Inventory Consumer
Analytics Consumer
Notification Consumer

Single publish, many consumers.

Winner:

✅ Kafka

Resource Usage

REST

Good for:

• Interactive user operations
• CRUD applications
• Real-time queries

Kafka

Good for:

• Massive event streams
• Decoupled microservices
• Event sourcing
• Data pipelines

Aspect	REST API	Kafka
Communication	Synchronous	Asynchronous
Latency	Very low (milliseconds) for direct request	Slightly higher end-to-end due to broker hop
Throughput	Limited by API server capacity	Extremely high (millions of messages/sec possible)
Scalability	Scale API servers horizontally	Scale producers, brokers, and consumers independently
Reliability	Client retries required	Built-in persistence and replay
Backpressure handling	Difficult	Native consumer lag handling
Fan-out to multiple consumers	Multiple API calls needed	Publish once, consume many times
Real-time response	Excellent	Not ideal for immediate response

Pega dirty dialog

 Dirty Dialog - Troubleshooting | Support Center

Theme cosmos : Shareable links

 https://forums.pega.com/t/theme-cosmos-open-work-object-in-full-portal-on-copy-sharable-link/635

AI Prompts

 Build out the content for this agent instructions file for this project. This is an instructions file specifically for the LLM's to adhere to the coding standards for this project. Agent instructions will be separated out into separate .md markdown files localted in the /docs directory

Pega passivation

1.  Passivation allows a requestor, service, or clipboard page to be saved into the Pega Platform database and reactivated later, helping to free up JVM memory and making more memory available to other requestors.
2. When a page is passivated, other pages for that requestor remain in memory, and requestor processing continues normally until that page is needed (such as for read access or for update) and is reactivated into memory. When an entire thread is inactive, the thread context is passivated (including the associated clipboard pages). If the requestor remains idle, eventually the entire requestor context is passivated.When a requestor is activated, the pages that had previously been passivated remain in storage until they need to be activated.
3. The initialization/PersistRequestor prconfig setting or dynamic system setting controls whether time-out passivation occurs. If the setting is not defined or equals OnTimeout, time-out passivation occurs. Time-out passivation is required for high availability environments. To prevent time-out passivation, set this to Never.
4. Passivation occurs through three distinct mechanisms:
1. Page passivation 
1. Used for individual pages, threads, or entire requestors. Page passivation is used to improve system performance by removing pages from the clipboard that have not been accessed by a requestor for a specified period of time. Other pages for that requestor remain in memory, and requestor processing continues normally until that page is needed (such as for read access or for update) and is reactivated into memory. By default, passivation occurs for:
1. Pages that are idle for at least 15 minutes
2. Threads that are idle for at least 30 minutes
3. Requestors that are idle for at least 60 minutes
2. You can configure the time-out periods with the prconfig.xml or dynamic system settings timeout/page, timeout/thread, and timeout/browser. These settings signify numbers of seconds.
2. Timeout passivation – Used for entire requestors. Timeout passivation in a single-node system allows users to resume work without loss of context after a specific period of no activity, with the possibility that they will have to reauthenticate.To enable timeout passivation, use the following prconfig.xml setting or Dynamic System Setting:<env name="Initialization/PersistRequestor" value="OnTimeout"/> (the requestor is persisted to the database based on the timeout/browser setting)
3. HTTP session passivation – Used to free JVM memory and support failover. HTTP session passivation helps to provide high availability in a multinode environment by allowing a cluster to operate in a resilient manner, reducing the risk of loss of data if a node fails.When the Pega Platform is running in high availability mode, the Initialization/PersistRequestor prconfig.xml setting or Dynamic System Setting should be set to "OnTimeout". When set to AtInteractionEnd, the requestor is passivated at the end of each user interaction.
5. Passivation storagePega Platform provides two passivation storage mechanisms: database and filesystem. The default passivation storage is database, which is most efficient and robust. You can override the default storage mechanism by setting the prconfig setting "inititlization/persistrequestor/storage" to either "database", "filesystem", or "custom".With database storage, the passivation daemon saves requestor information as an instance of the System-Requestor-Context class, corresponding to the pr_sys_context database table. The daemon saves page details as an instance of the System-SavedPages class in the pr_page_store database table.