In the lesson "Ad Hoc Work and Process Design" and in the page "Understanding Ad Hoc Case Functionality" and in the Section "Adding tasks in the Ad Hoc Case Dashboard", it is given as "The Ad Hoc Case Dashboard action references the section pyAdhocCaseQuickActions, which we can extend."
But pyAdhocCaseQuickActions is a flow action which references the actual section "pyAdhocCaseActions". The screenshot shows the section "pyAdhocCaseActions" correctly, but the description is given incorrectly.
In the case study for "User Interface", it requires importing of a base application "Travel.zip". However, there are no links provided anywhere to obtain that file, including sidebar "Related". Where else can I obtain that file?
TL-4239034 is refering to a property called “.pyLSAName” instead of “.pySLAName”.
Kindly correct this.
Understanding the Difference between Work and Task SLAs
It is also possible to define “.pySLAGoal” and “.pySLADeadline” DateTime properties on each case. For these properties to take effect, the ServiceLevel rule represented by “.pyLSAName” must be configured to use those properties as the Goal and Deadline times, respectively.
Your request was forwarded but the response was the same as the one I would have provided.
Would it be possible to get a hide / unhide option for the left panel. This will help us with reading. As such I am relying heavily on horizontal scrolling to read.
All 7.1 courses are built using 7.1's "Responsive" UI. There is no horizontal scrolling. When you shrink the UI horizontally, the left panel automatically hides itself. Also components on the right move downward.
What browser are you using where you are seeing horizontal scroll bar? Are you perhaps using an older IE browser that is set to use "quirks" mode, i.e., non-HTML5 compatibility mode?
Could you identify where you are seeing a "Database Architecture" lesson within the 7.1 Lead System Architect course? Please start from the major topic, e.g.,"Architecture", then mention the lesson, e.g., "JEE and PRPC", then the page within that lesson.
Business Rules > Features and Behavior of Triggers
The last paragraph is misleading. It sounds like
1. a trigger is responsible for tracking the value change of properties.
2. a trigger will be executed if a property value get changed
Pega 7 creates a clipboard page named pyDeclarativeContext that is available during the life of the trigger activity. This page is of type Code-Pega-DeclarativeContext and has a value list of the changed properties. In some cases it may be useful to programmatically examine this page to see which properties caused the trigger to execute.
>Is your suggestion that the last paragraph about Declare Triggers can be confused with Declare OnChange?
Yes, I think it is more natrual to introduce "pyDeclarativeContext" in the next lesson about OnChange rule.
Since OnChange is the rule designed to track value change of properties and considering one OnChange rule can track multiple properties, there are chances that developers may want to know which properties caused the OnChange Activity to execute.
>3.The Trigger Activity can programmatically refer to that page to determine what properties caused it to execute.
Is it appropriate to say "a property" can cause the Trigger Activity to execute ?
Isn't it a database event like "save" or "delete" triggers the Trigger Activity to execute?
I will forward your suggestion about OnChange. Obj-Save and Obj-Delere add to the deferred list. The "trigger" event is when a Commit is issued I would think. Properties do not cause Commits to be issued - Activities decide that. The values of certain Properties may be evaluated to decide whether or not to call a certain Trigger's Activity. That Activity may want to know the values of the Properties that caused the Activity to be executed. Does that make sense?
>The "trigger" event is when a Commit is issued I would think.
Help document of Declare Trigger rule states, that Obj-Save or Obj-Delete is the valid option for trigger event. "Committed save" or "Committed delete" is distinct option from "Save" and "Delete".
Trigger When an Instance Is
To cause this rule to execute when an instance in the class is saved (usually with the Obj-Save method).
To cause this rule to execute when an instance in this class is deleted (usually with the Obj-Delete method).
To cause this rule to execute when an instance is saved and properties listed have values different from the previous values.
To cause the rule to execute when a Commit method occurs and the previous method for the instance was Obj-Save. (Also, an Obj-Save method that executes with the WriteNow option selected causes trigger rules with Committed Save to execute.)
To cause the rule to execute when a Commit method occurs and the previous method for the instance was Obj-Delete.
If you want processing to occur whether the instance is deleted or saved, create two Declare Trigger rules, one for each situation.
However below description in the same help document sounds like a trigger activity always runs during database commits. Hence, I am confused again :-(
Identify the second key part — the Activity Name — of an activity to trigger when any of the specified properties change. The system uses the Applies To key part of this Declare Trigger rule as the Applies To key part of the activity.
Cick() to open the activity.
If Immediately is selected for the Execute field, only activities with the Activity Type of Trigger appear in the SmartPrompt list for this field. Use of Triggeractivities is recommended and avoids a warning condition reported when you save this rule. You can type in the name of an existing activity of another Activity Type, but the activity must conform to these restrictions:
The activity cannot itself commit database transactions, because a triggered activity runs during database commits.
Preconditions and transitions in the activity cannot use when condition rules and cannot call functions.
Although your application can contain more than Trigger activities for oneApplies To class, you cannot control the order that they run when two or more are triggered. Create activities that provide correct results when run in any order, and when run either independently or simultaneously.
>That Activity may want to know the values of the Properties that caused the Activity to be executed. Does that make sense?
The concept of "Properties cause the Trigger Activity to execute" doesn't make sense for me, however It might be possible that a trigger activity can evaluate the properties listed under the "..One of these properties was modified" section which appears only when you choose "Saved and..." for "Trigger When an Instance Is" option.
I will see if the wording can be improved by forwarding your comments. My understanding is that there are conditions that decide whether or not the Trigger should be considered at all based on the event, such as Obj-Save as you pointed out, plus there are conditions derived from Property values that are evaluated to decide whether or not to call the Trigger Activity - that Activity allowed to "introspect" the Properties that caused It to be invoked.