Traditional Starter Packs
Traditional Starter Packs provide a technology stack that uses the capabilities of Traditional DX API with section-based UI to build a custom front-end experience for Pega applications.
The starter packs include an interpreter that can automatically process the DX API responses and initialize appropriate front-end components in the design system of your choice. You can use the starter packs to create, view, and update cases and assignments. If your application uses standard assets such as sections and harnesses, Traditional Starter Packs are the optimal choice. The starter packs are bundled with a sample application, CableConnect, that enables you to build and modify components using the starter pack. You can use the code as-is or update it to match your coding practices.
The starter packs are currently offered in the following platforms in Pega Marketplace to make front-end development more fluid depending on your development framework:
Click the logo to access the corresponding starter pack. Detailed documentation for setting up and using the starter packs is available in the starter pack's downloadable file.
Compatibility
Starter pack compatibility with Pega platform:
Pega InfinityTM Version | Angular | React | Vue |
---|---|---|---|
8.7 | ✓ | ✓ | ✗ |
8.6 | ✓ | ✓ | ✓ |
8.5 | ✓ | ✓ | ✓ |
8.4 | ✓ | ✓ | ✓ |
8.3 | ✓ | ✓ | ✓ |
Authentication
The starter packs support the following authentication types:
- Basic authentication
- OAuth 2.0
Server development guidelines
DX APIs use cloud-friendly stateless REST APIs, data updates are saved to the database upon each submit, thereby preserving changes in the System of Record (SOR) between API calls. Requestor and Thread-level data pages are treated the same. UI Data binding is provided for Case and Data pages; however, System and Named pages are not accessible. Clipboard is released after each server call. Data changes within the scope of the Case object.
UI-design best practices
- Ensure that you use a screen layout as the top container in harnesses.
- Ensure that you do not use circumstancing in harnesses and sections.
- Visibility expressions must consist of When rule references only.
- Sections must be auto-generated.
- Sections must use one of the following layouts:
- Table
- Dynamic layout
- Repeating dynamic layout (not sourced from data pages)
- Embedded section
- If a flow action uses editable pages (named pages, thread-level data pages or requestor-level data pages), edited values are not available in post-processing data transforms or activities. In such cases, use the pattern of auto-populated properties (which obtain data from data pages) and Savable data pages in the post-processing of flow actions.
- Ensure that you do not design your application for pessimistic locking. Your application's configuration is overridden to always use optimistic locking.
- If using Pega PlatformTM 8.4.5, 8.5.5, 8.6.1, and 8.7, set the Dynamic System Settings (DSS) v1MergeStrategy value to UPDATE. For more information, see Page-Merge-Into Method (Keep - option 3).
- Invoke the Obj-Save method when using flow action preprocessing activities to ensure the field values persist in the DB. Otherwise, the field values might disappear when you edit another field or refresh the data.
Next topic Application implementation examples