If there is any documentation about using Keyed DP in constellation, please share it.
I have tried to source the Keyed DP via Data Reference, However it is not visible in the available data pages. Once i created the page list property, In Dev studio I have changed the Source of the property to Keyed DP from a list DP and also updated the keys in the page list property. When i am checking the Same property in App studio, it is getting updated to Property of type Query(List).
Can someone please say what need to be done here and correct me if I have made any mistake in the configuration.
@Sam Alexander @AK___ As of Infinity 24.1, you can also apply “Additional info” when defining the field on the data model. This is then published as a modal overlay using an info icon next to the field whenever it is shown for data capture.
Combined with Sam’s response, this provides the ability to add step-level, group-level and field-level instructions for users completing forms in Constellation UI.
The considerations when choosing which layer you implement your data model are the same for Constellation apps as they have been for traditional apps. Implement data objects as reusably as makes sense for your business need. Defining client- or implementataion-specific data types that inherit from existing data types remains the recommended approach, for all the same reasons that this would be recommended in Object-Oriented Design.
When using an existing data model that was defined in older versions of Pega, beware that the more modern field types may not have been available at that time. PegaData-Contact for example has fields such as Phone number, Primary email and LinkedIn URL which are all defined as “Text”'. Newer data models would implement these fields using modern field types like Phone, Email and URL. Constellation apps will provide better data capture and read-only display behaviour for fields that use these modern types than with “plain text” fields.
If Common Data Model (CDM) provides entities and relationships that align to your application’s data needs, it is recommended. CDM is available for Platform-only apps as of Infinity '23, and has been part of our CRM apps for longer than that. CDM is extensible so that you can add your own entity types and extend the existing ones. CDM also has some neat OTB patterns for managing reference data which is one less thing you have to create a ‘framework’ for in a greenfield implementation. See also:
@SebastiaanH Hi, Sebastiaan. Your overview of DX Component and the Notification service sounds reasonable. I’m not immediately sure where the problem is. Can you open a support ticket for this one?
What is the resistance to using the OOTB Constellation Attachment utility?
What you have described sounds like a simple case type workflow.
Step 1: upload the file as a case attachment
Step 1 post-processing: pxParseExcelFile parses the file into data records and populates an Embedded Data (list) field of the case
Step 2: show the embedded data records for confirmation. Use a multi-step form to allow the user to easily go back and upload a corrected attachment; or provide a Table or Modal UX to allow the parsed records to be edited in place.
Step 2 post-processing: bulk-create the Operators using the data submitted on Step 2. Track success/failure in the embedded data list.
Step 3: confirm success/failure of each Operator creation to the user.
@ShivakumaaranC as you have seen, the notification behavior when there are changes to the data available from a data page that is the source for a list is to let the user know that new data exists and put the user in control of whether they want to receive the updated data.
You can implement custom behavior like what you need by developing a DX Extension Component which subscribes to the message type published by pxC11NPublishDatapageUpdate - or indeed a custom message type (published by pxC11nPublishMessage). The subscriber code in the Extension Component can implement customized behaviour in the front-end on receiving the message, such as accessing the latest datapage data and injecting it into the list view.
Hi @PRUTHVIRAJ. Thank you for this and your earlier question.
Going forward, please post Constellation implementation questions to User Experience Expert Circle | Pega monitored by Pega product managers, competency leaders and Constellation & UX community members from Pega, partner and client organizations.
Re-post your two questions there and you will get your answers in a timely fashion.
Further to @RameshSangili 's response, DX API’s response for showing the View for a workflow step includes metadata which calls out when there are fields on the View that are the targets of declarative calculations. This instructs the Constellation orchestration layer - running in your user’s browser - to automatically issue round-trips to the /refresh DX API operation when editable fields on that View are changed, so that any affected Declare Expressions can re-calculate (on the server) updated values.
A Messaging Service will still need to be operating for any Infinity server that is hosting a Constellation application, but the Messaging Service is not used for this pattern.
The Messaging Service is intended for scenarios where events that change the case state occur separately from a human user’s workings with the case. For example, background processing receives the results of a long-running validation service using a third-party API and makes these results available to the case. Infinity can use the Messaging Service to notify any humans currently working with the case that the validation has completed and its results are available.
The Data pages in constellation are classified into Queryable and Non-Queryable data pages. The Data pages which are populated with RDs are classified as Queryable and ones populated with Data transform are classified as Non-Queryable. Currently the implementation on the table side is limited to displaying these actions on the tables populated with Queryable data pages and so you don’t see the actions available on the tables which are populated with data pges sourced by data transforms.
@josenavas Blueprint’s main focus is to accelerate - for experienced and novice Pega practitioners - the authoring of workflows needed to fulfil the business outcomes needed for an application. With that comes the identification of the data objects and personas needed.
I would let Blueprint run its natural course without strong consideration for the overlap of your data objects with CDM. Defer to the implementation phase (during/after import of the Blueprint into Infinity) whether the data objects identified in the Blueprint should become entities managed by CDM. CDM entities are actually work classes, so once your data objects are identified as entities to use with CDM, follow the CDM implementation guide on extending CDM to include new entities.
@BraamSmithCLSA For what it’s worth: automatically refreshing a table often presents UX challenges. For example, suppose you’re reading a row on a table, but suddenly you lose your place because the table was automatically updated, so the row you were reading is now somewhere else.
By design, we render the “new records have been added” so the user doesn’t lose their place and can optionally decide to refresh.
From given information, I don’t recommend auto-refreshing the table.
Copying my colleague @Chiranit Prateepasen in case she has more to add.
