The calling activity can provide input parameters to the called activity, or it can share its own parameter page with the called activity, an approach known as call-by-reference.
The preferred means for passing a single page from one activity to another is to identify the page in the Step Page field of the calling activity. The called activity receives this page as its primary page.
If you need to pass more than one page, use the indirect page mechanism:
In the called activity, identify an indirect page by the keyword prompt as the Mode field in the
Pages & Classes tab.
In steps of the called activity, refer to these pages using the syntax promptpagename. No corresponding entry is required in the Parameters tab.
In the calling activity, pass the additional pages as arguments to the Call instruction that invokes the second activity.
Indirect pages provide a generic way to pass pages not only between activities, but also to other rule types such as list view rules and summary view rules.
Note: The clipboard page created will be only DataPage not promptDataPage.
Problem Flows and Connection Problem Flow
Flow problems are error conditions that a flow execution encounter as it executes that
prevents it from continuing. For example, the flow may reference a rule that is not found at runtime. This is considered a flow problems (or a problem flow), and can arise from many different sources.
The system halts the progress of that flow execution and starts a flow named Work-.FlowProblems. This flow normally notifies a user named Administrator@ org.com, where org.com is the organization of the user (requestor) who encountered the problem, and creates an assignment. Your application can override the standard activity Work-.ToProblemFlowOperator to designate a different operator as the recipient of these flow problems.
If you can fix the problem through a change in the flow rule, by modifying a rule, or creating a new rule, the processing can resume.
Your organization can copy and override the FlowProblems flow and the ToProblemFlowOperator routing activity to meet your needs.
Through an Integrator task — represented by the shape in the Visio diagram of a flow rule — a flow execution can call an external system such as a relational database, Enterprise JavaBean, or Web service. The activity referenced in the Integrator shape references a connector rule (for example, a Connect SOAP rule) that controls the communication and data exchange with the external system.
For various reasons, a tested connector interface may fail or time out, causing work object processing in the flow rule to halt. To facilitate detection and analysis or repair of such events, you can designate in your application a flow rule for connector exceptions. Failure of an Integrator task causes the designated flow rule to start. The flow rule can send out e-mail correspondence, attempt retries, skip over the integrated step, or send an assignment to someone.
Development
See Using Error Handler Flows for Connectors, a document on the Integration area of the Pega
Developer Network, for detailed development instructions, summarized here.
To use this facility, specify the second key part — Flow Type — of a flow rule in the Error Handler Flow field on a connector rule form. Process Commander uses the Applies To key part of thecalling flow as the first key part when retrieving the exception flow rule.
If you leave the Error Handler Flow field blank, a connector problem causes the flow execution to fail and is reported only as Java exceptions in the Pega log of type:
com.pega.pegarules.pub.services.ConnectorException.
parameters:
1 Operator ID of a user to notify (not used)
1 The Applies To and Flow Type key parts of the original flow execution 1 The name of the shape in which the problem arose
1 A ConnectorException type 1 An error message
1 An assignment type (Workbasket or Worklist), indicating where to place a resulting assignment.
For all the exception types other than ResourceUnavailable, processing continues in a FlowProblems flow. See Working with the Flows with Problems report.
If the exception type is ResourceUnavailable, up to five retries are attempted, at intervals determined by a service level rule.
A developer accessing the workbasket can cancel the assignment (ending both the ConnectionProblem flow and the original flow) or attempt to restart the original flow, perhaps after taking corrective action.
Logging:
Each node on a Process Commander system produces two logs:
The Pega Log — also known as the console log or system log — contains messages created since the server was most recently started. The log file is usually named PegaRULES-YYYY- MMM-DD.log, where the date portion of the name indicates the date the application server was recently started (on the current node).
The Alert log contains only alerts and supports performance-related monitoring.
Viewing or downloading the Pega log
Select Tools > Log Files to view or download the current Pega log from the server to your workstation. Listeners operate as Java threads rather than as full requestors, and so cannot be accessed with the Tracer. Accordingly, use logs to debug listeners.
Follow the steps in the following procedures to configure a listener or service requestor to send log messages to your workstation. Then, using a modified version of the LogFactor5 log analysis module, you can review detailed or filtered messages. (LogFactor5 was an open source project of the Apache Software Foundation.)