Pega—System Architect

一、升级迟到工作

1. 已过截止时间间隔【passed deadline interval】

目的：定义何时采取下一步行动

手段：
形式：重复固定次数或直到用户完成分配

应用：继续增加分配的紧迫性，并在每次超过最后期限时发送升级操作

紧急度：最高设置为100，Pega会忽略进一步的紧急度调整并继续其他升级操作

注意点：如果经过升级操作的多个截止期限间隔过去了，则重复升级操作

二、决策表和树

1. 决策表【decision tables】

应用：根据条件逻辑设置属性值并返回相应的状态、判断是否满足设定阈值

功能：

• App Studio
  计算字段的值
• Dev Studio
  维护决策逻辑、扩展结果选项(返回所有成功的结果或设置其他属性的值）、直接流程处理

注意点：

1. 在App Studio中创建一个决策表来计算某个字段的值时，会在Dev Studio的work类中创建一个决策表规则
2. 用于计算属性值的决策表根据决策逻辑返回单个结果
3. 可以通过使用决策形状返回基于多个可测试条件的结果来确定流程的结果
4. 连接器不能用于评估

2. 决策树【decision trees】

应用：根据不同的测试条件和属性进行评估处理从一组测试条件返回结果的逻辑

应用范围：

1. flow rules
2. declare expressions
3. activities
4. routers

构成：
注意点：决策表对同一组属性或条件的多种组合进行评估以返回一个值或属性，而决策树则对不同的属性或可能依赖于其他条件的不同属性的条件进行评估

3. 决策规则冲突【Decision rule conflicts】

1. 冲突测试
   1. 检查冲突
      判断决策规则是否会阻止使用其中的一行或多行或分支
   2. 显示冲突
      验证不正确的条件，指定未评估的条件
2. 完整性测试
   应用查找决策规则中缺失的件或分支

三、级联审批

1. 级联审批【cascading approvals】

模型：

1. 报告结构reporting structure

   需要用户的直接经理以及更高级别的经理的批准

   可配置业务逻辑来设置阈值以确定所需批准的数量

   Custom 自定义可以由哪个上级批准

   One 需要直属上级批准

   All 需要多名上级批准

2. 权限矩阵authority matrix

   需要配置标识批准者的数据结构

   填充数据结构的方法有决策表、数据页、活动、数据转换

注意点：

1. 当批准不仅仅基于报告结构时，就使用权限矩阵模型
2. 权限矩阵规则可以将批准链指向组织外部的个人

四、创建和管理用户团队

1. 用户团队

1. 工作组work group
   包含管理人和工作队列的跨职能团队
2. 工作队列work queue
   包含与该工作组关联的所有操作员的共享工作
3. 工作列表 work list
   仅包含分配给特定操作员的工作
4. 操作员operator
   必须与至少一个工作组相关联，并且可以属于多个工作组
5. 管理人 manager
   分配、监控和报告在每个工作组中执行的工作
6. 授权管理人Authorized managers
   帮助转移任务，不需要成为工作组的一部分，也不能执行批准或完成任务

注意点：

1. Dev Studio中的Operators在App Studio中被称为users和people

2. 每个工作组包含一个工作队列

3. 管理人使用用户门户访问在工作组中执行的工作

4. 使用基于决策的路由器----分配作业给基于案例属性值的特定用户

   为团队创建队列----分配作业给特定工作组的任何成员

五、为多设备设计UI

1. 响应行为【Responsive behavior】

应用：在可用显示空间中最大限度地减少水平滚动和最大化数据呈现

2. 响应断点【Responsive breakpoints】

目的：定义显示宽度

断点行为：

1. 隐藏组件
2. 转换为其他格式
3. 转换为列表
4. 删除具有重要性的列Other

注意点：

1. 显示宽度>断点时，响应行为将应用于布局
2. 动态布局下，会根据显示区域的宽度更改字段的布局

3. 响应表格【Responsive table】

目的：从用户界面中删除不太重要的信息来最大限度地减少水平滚动

构造：有一个或多个列，每个列都有一个配置的重要性设置；有两个断点(宽+窄)

列重要性：Primary(默认在最左侧)，Secondary, Other

注意点：对于网格或树状网格等表格样式布局，始终将宽度设置为100%

4. 移动应用程序设计【Mobile app design】

考虑因素：

1. 离线使用

• 启用客户端决策和验证
  客户端决策和验证发生在移动设备上。当移动设备离线时，用户可以完成并提交表单。在线后，表单才被递交至服务器并处理。

• 使用数据页作为数据源

  当移动设备离线时，数据页面存储所有已完成的工作。当移动设备在线时，数据页面会同步到服务器。

• 使用布局组来利用响应式UI
  根据分辨率大小自动切换到特定布局

2. 设备特性

• 创建简单的用户界面
• 使用自动生成的控件
• 包含本地特征
• 支持手指点击
• 可测试应用程序
• 使用相对定位

六、自定义表单的外观

1. 信息和用户界面【Information and the user interface】
字段：属性和控件的组合。
控件：收集用户输入或在用户界面上执行操作。用于确定数据、文本、图像和其他信息如何显示在用户表单上

验证用户对控件的输入：

1. 控件类型

• 预定时间Data Time
  从日历图标中选择日期
• 单选按钮Radio buttons
  将选择限制为一组有效值，并允许用户仅选择一个值
• 下拉Dropdown
  将有效值限制为出现在列表中的值
• 自动完成Autocomplete
  输入一个或多个值时，过滤可用的选项
• 复选框Checkbox
  可选中该复选框或将其留空

3. 必填字段
   确保用户输入值
4. 可编辑设置
   将输入值限制为有效格式

属性：在App Studio创建一个字段，则后台会自动创建一个属性来管理数据
属性模式：

1. 值模式Value modes
   描述单个信息。控件用于显示Value modes属性的值

2. 页面模式Page modes
   描述一种数据类型。布局或属性容器均为页面模式属性；页面模式属性不能映射到日历控件或按钮

布局：out-of-the-box模板。只有Dev Studio允许创建或更新布局模板

注意点：

1. 数据类型或属性可以是与任何其他值没有预期关联的单个值，也可以是一组相关值
2. 定义新字段时，系统会分配一个默认控件，但控件不一定与数据关联
3. App Studio中，在案例生命周期可以配置视图，在Views tab可以修改视图，在运行时可以更改设计模板来修改视图布局

2. 动态布局【Dynamic layouts】
应用：将格式自动调整到屏幕大小来排列指定的项目
模板：预先格式化的模板。通过设计模板之间的切换来更新表单的结构

3. 重复布局【Repeating layouts】
定义：用于组织列表、表格和其他重复结构的布局
目的：确保一致地呈现内容

形式：

1. 表格布局
   在一系列列和行中显示表格数据。响应能力有限
2. 重复动态布局
   以非线性、更美观的格式对内容进行分组和呈现。与动态布局的响应能力相同

应用：在重复结构中使用动态布局的格式化；使用列表为每个项目显示一个部分，每个部分可以包含任意数量的布局；包含图像或其他图形

七、分组视图中的字段

1. 布局组【layout groups】

前提：面板数量有限

应用：将内容分成单独的面板，并允许用户一次就可以查看一个面板的相关数据

格式：

1. Stacked list layout
   显示为垂直堆叠的信息面板列表，一般在大屏幕上显示内容时使用

2. Tab layout group
   显示为一系列信息面板选项卡，当选项卡宽度>可用容器宽度时会显示菜单

3. Accordion布局
   显示为垂直堆叠的信息标题列表

4. menu layout
   显示为可从菜单访问的信息面板组，减少较小​​设备上的垂直滚动

八、本地化应用程序内容

1. 本地化【Localization】

途径：翻译文本、转换区域特定的组件

范围：文本(流操作等)、HTML文本

构成：

1. 字段值规则
   捕获标签和注释

2. 段落规则
   存储格式化的长文本，使内容可重复使用

3. 通信规则
   生成电子邮件和其他通信

注意点：

1. 在App Studio中配置电子邮件通信时，会自动创建通信规则
2. 导入并测试所有语言的规则集后，Pega会根据用户的区域设置自动使用规则集
3. 如果缺失语言包，需先导出所有必填字段并翻译，再导入自定义翻译包
4. 字段值和消息规则出现在XML文件中，通信规则和段落规则导出为HTML文件以进行翻译

九、在应用程序中启用辅助功能

1. 应用程序可访问性【Application accessibility】

WAI-ARIA roles：应用于用户界面元素的特定属性，默认分配给UI控件和其他组件

WAI-ARIA roles类型：

1. Landmark
   由一个标题(包含logo)和跨多种形式共享的标准内容组成
2. Document structure
   可识别用户提交的一系列先前案例的表中的行
3. Component/Widget
   包含辅助设备的链接

2. 辅助功能检查器【Accessibility Inspector】
辅助功能：enter event、landmark role、helper text

Pega平台功能：

1. Device Preview
   允许查看应用程序
2. Live UI
   识别当前UI上的元素、查看UI层次结构并打开相关规则
3. Tracer
   打开Tracer结果窗口，包括显示来自规则执行和数据操作的事件

问题分类：

1. Content
   控件配置

2. Structural
   门户中内容的组织

3. Interactivity
   UI导航

4. Compatibility
   表单上使用的Pega UI元素

十、应用安全性

1. 安全清单【The Security Checklist】

目的：确保AIC Triad(可用性、完整性、机密性)

安全性类型：

1. Application-level security

   保护应用程序免受外部人员和未授权用户的侵害

2. Feature security

   确定授权用户可以或不能访问的案例类型、功能和数据

如何实现保护：

注意点：

1. Pega和客户端都负责应用程序的安全部署
2. 保证护栏的合规性是最重要的安全要求
3. 为保护应用程序，不可使用个人代码
4. 确保安全设置正确的最佳做法是将安全要求添加到每个功能的DoD中

2. 安全策略【Security policies】
类型：

1. Frequently required policies

• Password

• CAPTCHA

• Lockout
  定义用户输入错误密码时的系统行为

• Audit
  针对安全问题，确定写入系统日志的详细信息量

2. Other policies

• Multi-factor authentication
  提供多项证据来验证其身份后才能获得访问权限

• Operator disablement
  自动禁用在指定天数内不活动的用户的访问权限

十一、管理应用程序访问

1. 应用程序访问【Application access】

Access role：根据用户的工作职能对用户进行分类

Access group：每个访问组标识一个或多个与一组权限相关联的访问角色

Operator ID：对用户进行身份验证

Operator record：引用一个或多个有访问特定功能的权限的访问组

RBAC(基于角色的访问控制)：控制用户可以访问的应用程序特性和功能，通过定义具有所需授权和特权的角色来配置访问

控制因素：

1. 身份验证authentication
   确认用户的身份并验证用户是否被允许访问应用程序，如Operator ID的记录

2. 授权authorization
   决定用户可以查看哪些数据以及用户可以执行哪些操作，如访问组和应用程序的记录

注意点：

1. 每个角色都有一个默认的频道界面(用户界面)用于定义用户在登录时将看到的屏幕
2. 当一个访问组列出多个角色时，Pega会在所有列出的角色中应用最宽松的设置
   ＝需要考虑与其他访问角色关联的权限

2. 访问控制【Access control】

简化安全记录的配置：

1. App Studio——Persona access (多数情况) 创建、编辑
2. Dev Studio——Access Manager 删除

应用：

1. 案例类型

• ARO：角色对对象的访问，为特定访问组的成员指定特定类别的项目的权限
• Access Deny：访问拒绝，覆盖ARO以明确拒绝访问

2. 系统类型

   Production levels：分为0～5级别来控制允许更改的类型并指定环境的目的

注意点：

1. ARO＝No Access表示拒绝用户访问；Production levels＝0表示拒绝操作
2. 更新Access Manager中的访问控制设置时，ARO或Access Deny的记录也会更新为0或5

十二、调试应用程序错误

1. 追踪【The Tracer】

目的：捕获和查看每个事件及其完整日志，识别执行错误的来源，排除故障

应用：

1. App Studio——Runtime toolbar
2. Dev Studio——Developer toolbar

返回状态：GOOD、FAIL

分类：

1. Gray
   活动处理

2. Orange
   来自流程、决策或声明规则的事件

3. Light blue
   PegaRULES数据库和缓存操作

优化：配置Tracer仅捕获所需的信息，暂停记录日志，再运行有故障的部分

注意点：

1. 每个节点每个操作员只能有一个Tracer
2. 想要限制显示的信息量可以在错误发生之前启动Tracer或直到错误发生都保持Tracer暂停

十三、测试应用程序

1. 单元测试【Unit tests】

对象：单个规则

目的：减少配置错误，验证每个元素是否按预期工作

断言Assertion：描述一个或多个要测试的条件以及每个条件的预期结果

断言类型：

1. Property
   测试指定属性的值，前提：已定义属性的页面、一个比较操作、一个比较值

2. Decision result
   测试决策规则返回的值，前提：返回预期结果所需的每个输入属性的值

3. Expected run time
   测试规则能否在允许的时间内执行，前提：比较操作、允许的时间(单位秒)

4. Page
   测试内存中是否存在页面，前提：页面名称、比较操作

配置：

1. 创建自动化单元测试
   考虑优先级(高→低)

2. 构建覆盖范围
   保证足够的验证，测试用例逻辑简短且可见

3. 构建维护
   易于理解，模块化

注意点：可以将单元测试用例分组到一个测试套件，但批量运行测试套件时，是按顺序运行

2. 场景测试【Scenario testing】

记录方法：portal、case type

交互：记录在一系列可视化的步骤中

断言框：表示可以测试的受支持的用户界面元素

LSA：

1. 审查失败的测试用例并采取纠正措施
2. 为案例类型和门户规则添加更多测试案例以增加测试覆盖率
3. 审查并指示更新任何现有测试用例

注意点：场景测试必须在记录它们的同一门户中运行

3. 测试覆盖率【Test coverage】

目的：验证哪些规则需要测试

前提：SysAdm4/ User4①②、pzStartOrStopMasterAppRuleCoverage②

报告类型：

1. User-level test coverage reports用户级
   确定哪些可执行规则被测试覆盖和未覆盖

2. Application-level coverage reports应用程序级
   来自多个用户的测试覆盖率结果

注意点：

1. 生成应用程序级报告时，系统会将每个测试实例记录为单独的测试报告
2. 用户级报告在Dev Studio的Application Quality Dashboard上不可见