User interface
Case management
Designer Studio
Project delivery
Decision management
Decision management
The PDN provides overview articles, best-practice solutions to common development challenges, news of the latest product features, access to the latest version of the product help documentation, and many more learning resources. Learn from the experts. Pega Academycourses provide design and implementation best practices that cover Pega 7 Platformapplication development as well as specialized topics. Pega Academy courses provide the knowledge and hands-on experience that you need to successfully design and deploy Pega 7 Platformsolutions. These courses also prepare you to become a Pega Certified Professional. User interface
Case management
Designer Studio
Project delivery
Decision management
Decision management
Mobility
Offline mobility
Core engine
Data management
Integration
Pega Mobile is an add-on product for PRPC 6.2 SP2 and later releases, offering mobile device users the capability to participate, collaborate, and monitor PRPC work from most major mobile devices, including tablets, phones, and iPods. Access Access your application on a mobile device using a WebKit-based browser and the same URL and login as the desktop version of an application. You can also access the application using the free Pega Mobile app, available at on-line app stores, which delivers your PRPC application to your mobile device while giving you convenient access to native device features, such as the camera. The app also allows you to save multiple application configurations, including URLs, logins, and passwords. Portal and navigation The Pega-Mobile RuleSet delivers an extensible portal, based closely on the Case Manager portal, that provides mobile device users with access to the PRPC application. Customizable navigation rules define how users move about the application. Navigation is controlled by main and toolbar navigation rules, and the list of items, actions, labels, and icons is completely configurable. You can even prevent display of navigation rules on phones and tablets. Layouts and controls Use a set of layouts and controls that are supported for use in sections and harnesses that render on mobile devices. Over 100 PRPC controls are mapped to mobile versions of those controls to facilitate the mobile rendering of existing applications. Specialization and circumstancing Most existing harnesses and sections render on mobile devices with no additional work. However, if your application includes features not yet optimized for mobile devices, you may create a specialized version of the section rule that includes features that are optimized for mobile devices. You can also circumstance your entire UI experience based on the device type. Use Save As to save the portal rule to a new name, and for the circumstance, enter property pxRequestor.PxDeviceTypeand the value phoneor tablet. When you log in using this portal, the application determines the User Agent, and displays the portal, sections, harnesses, and flow actions with a user interface for the specified device type. Testing and debugging To test and debug your mobile application, use a physical mobile device when possible. Additionally, configure Apple's Safari or Google's Chrome with a specific User Agent, such as iPad or iPhone, so that you can run the mobile application on your desktop as it would appear on the tablet or phone device. The Mobile Clipboard is useful for examining property values, rule types, and identifying the Remote Tracer Session ID. Other resourcesThese PDN articles are relevant:
Note: If your application was developed in 6.2SP2 and uses RuleSets ending in _mobile, and you want to operate in ABA mode for best performance, note that _mobile RuleSets appear higher in the RuleSet list in ABA mode than in rules assembly mode. While it is unlikely that this change affects results of your application, some analysis and testing is recommended. Mobile
Decision Management
Case Management
Designer Studio
Project Delivery
User Interface
Reporting
Integration
System Management
http://example.com/prweb/?[QueryString] Most applications require access to data or computations that are provided by another system, or need to respond to requests from other systems for data or computations. PRPC offers many approaches, technologies, and facilities collectively known as Integration. (Internally, these facilities are in the Pega-IntSvcs RuleSet.) They include:
ConnectorsRule types provide direct support for these protocols and technologies:
How connectors workConnector interfaces consist of a call or outgoing message (known as the request), followed by a return or arriving message, known as the response. You can parse, convert, and map data in either direction to or from the clipboard.
Arriving information can be an XML file format (and accepted by the Parse XML rule), in a fixed record structure (accepted by the Parse Structured rule), or a text file with input fields separated by a tab character or other specific characters (accepted by the Parse Delimited rule). Your flows can include Integrator shapes, which execute activities that use connector rules to gather data or request processing from another system. For most connector types, you can simulate the operation of a connector before you build the connector. This allows your application development and testing to proceed when the external system is unavailable or is difficult to test with. See Creating connector simulators. Mapping and ResourcesSeveral rule types facilitate two-way mapping between property values (on a requestor clipboard) and the messages, records, or structures used by the external system or technology. These rule type belong to the Integration-Mapping category. See Data mapping in services and connectors — Concepts and terms. Resource identifiers — such as URLs, port numbers, usernames, passwords, and the like — may vary between a development or test environment and a production system, and may change during the operation of a production system. Such information is usually better stored in data instances, rather than rules. The data classes belong to the Integration-Resources category. Landing pagesFour Integration landing pages provide access to integration rules and resources: A flow describes a business process. One representation of a flow is a network of shapes and connectors (directed arrows), each with associated parameters and values. Flows govern:
Some applications don't require users to interact with user forms. Flows that implement straight-through-processing operate without user input. External portals and systems can execute flows through Active Server Pages, JavaServer Pages, Service Portlet or Service JSR94 rules, or other means. Informally, these are known as "headless" BPM applications. A collection of standard activities, flows, and flow actions known as the Process API simplifies building such applications. Runtime processing — The simple case At runtime, a user can start the execution of a flow by entering a new work item. The system examines the property pyFlowName, in the data transform instance for the class, to determine which flow to start. The flow operates on the work item to advance it through the business process that the flow implements, performing automated steps automatically, or creating assignments for users as appropriate. You can think of a work item as located "on" one shape or arrow of the flow at any one instant, until the work item becomes resolved or the flow ends. Alternatively, you can think of the flow operating on the data (properties) in the work item until the flow finishes or the work item becomes resolved. Both points of view are correct. A flow may define many optional detours, side trips, and branches reflecting decisions reached along the way. The path that one work item follows through the flow depends on its own requirements, automatic decisions in rules (such as decision trees and map values) and on available resources. For example:
Parallel processing with Split Join In some business processes, the order of certain steps is not important as long as all the steps get done. In other situations, a step can be considered complete when either of two other steps finishes. The Split Join facility ( or ) supports such asynchronous operation, by allowing processing of two or more subprocesses to proceed in parallel. For example, a contract may need approval of both a legal reviewer and a purchasing department reviewer, but order is not important. In the 1980's era of paper forms and in-boxes, only one of these two has the paper — artificial sequencing. With a work-object and a flow that uses Split Join, each subprocess can create an assignment, and the two reviewers can proceed independently. See Flow form — Editing in Process Modeler — Split Join shape properties Split Join parallel processing occurs only when considered at the business process level. Although two assignments exist, they both belong to a single work item. During the minutes or seconds that either user performs the assignment (thus updating the work item), the system locks the work item, and the work item is not available to the other user. Similarly, at a more atomic level, if the two users both access a single-node PRPC system that has a single JVM and single CPU chip, no parallel processing occurs at the Java thread level, even when the two users work on different work items. Parallel processing with Split For Each The Split For Each facility () causes multiple subprocesses to start, one for each page of a Page List property. Processing can resume after any one, or all, of the subprocesses end. See Flow form — Process Modeler — Editing a Split For Each shape. Parallel processing with Spinoff A Spinoff shape starts asynchronous execution of a different flow, on the same work item or a different work item. Processing of the current flow does not pause or wait for results from the other flow. To create a spinoff, use a Subprocess shape (). Select the Spinoff Flow checkbox. See Flow form — Editing with Process Modeler — Editing the Subprocess shape properties. Parallel processing with Start a New Process and flow actions PRPC offers ways for a flow execution to be started for an existing (open) work item. These are alternatives to calling a subprocess, using a Split Join shape, or using a Split for Each shape:
Several system-maintained properties in a work item record the current state of flow executions in process. For example, the integer property @baseclass.pxFlowCount indicates how many flow executions are in process for the work item. The Page Group property @baseclass.pxFlow contains a page of facts about each execution:
Based on HTML and XML standards, PRPC can support a wide range of user interaction facilities and approaches. Your application's user interface can take into account the environment, the domain knowledge of your users, their skills, locale, and language. The appearance, branding, and interaction dynamics of your user interface can match the context and language that is natural to your application's users. Evolving an application's user interface is best done by designers and developers who have both application domain knowledge and usability skills. Producing HTML displays and forms PRPC includes standard facilities for those workers and managers who use PRPC-based applications throughout the workday. These facilities support:
Defining user input forms and displays For access through the standard portal, PRPC uses harnesses (Rule-HTML-Harness rule type) for work items. Six other rules support the presentation of work items:
The HTML text you enter into HTML rules is known as source HTML. It contains ordinary HTML code plus JSP tags or directives — server-side instructions that PRPC evaluates at runtime to compose the final HTML it sends to the HTTP server (and ultimately to a user's browser session). Known as stream processing, this evaluation accesses the clipboard for text values to insert into the output HTML, incorporates the text of other HTML rules, provides conditional if-then-else testing, and looping through arrays. Harness forms use the pega:include JSP tag to incorporate multiple sections, which in turn use standard styles and fragments to present properties, labels, and images. For your application, you can copy and tailor parts of these forms as necessary, while inheriting the standard parts. Tools
These tools support your evolution of the user interface of your applications:
When a user submits an HTML form, PRPC records the values entered into input fields as property values on the clipboard. The values that users enter may not be in the format required by the property definition, or may not pass validation tests. Federated Case Management (FCM) enables you to connect version 6.3 and 7.1 PRPC applications. Users in a federation (a group of applications connected by FCM) work in their local application portal, which can display cases and assignments from other applications in the federation. It uses Internet Application Composer (IAC) for intersystem communications. Each local application processes and maintains its own cases and data, and publishes data to a centralized database, the Federated Case Management Repository (FCMR). Users in a federation (a group of applications connected by FCM) work in their local application portal, which can display cases and assignments from other applications in the federation. Each local application processes and maintains its own cases and data, and publishes data to a centralized database, the Federated Case Management Repository (FCMR). In a federated system, the terms local and remote are relative to a specific user and to a specific case. Each user on a federated system logs into a single application, his or her local application. Remote cases (that is, cases in other applications within the federation) can be created, viewed, and worked on from within the user’s local application portal. No re-design of any application’s user interfaces is required. FCM enables users to create, view, and work on remote cases of that type from within the local application portal as though they were local cases, even though all processing for each case still occurs in its local application, and all of the data related to each case is still stored in its local application’s database. The diagram below illustrates an example in which a user logged into the CPM-FS application will be able to create, view, and work on DisputeTransaction cases in a separate application, SmartDispute. In practice, the distinction between local and remote cases is irrelevant to the user. The FCMR consolidates work items and makes them available to all users in the federation. Users generally need not know the source of a case or assignment. All work performed on a case occurs in its local application, and all data for a case is stored in its local application’s database.
The FCMR contains class tables for federated versions of key PRPC classes, e.g. Work-Federated and Assign-Worklist-Federated. Instances of the federated classes serve as lightweight pointers to class instances residing in a federation’s local application databases. To make publishing data to the FCMR as efficient as possible, federated classes in the repository contain no BLOB fields, only a handful of key properties such as ID and status needed to identify and open each case in its local application. The full data for a case resides in only one place, its local application database, and all processing for that case occurs within its local application, even when that processing is being done by a user within a remote application portal. For information about setting up FCM, see the PDN article Setting up and configuring Federated Case Management. FCM Limitations:
Case type dependency relationships control automatic case instantiation, or the completion of a workbasket assignments (also referred to as a "mid-process dependency"). The case types must belong to the same top-level case type, and should not have parent/child covering relationships (to help avoid deadlocks).
Instantiation dependencyThis relationship exists when a dependent case type automatically instantiates only when one or more other case type instances (under the same top-level case type, and at sibling or cousin-levels) are created, completed, or reach a specified work status. Top-level case types cannot have instantiation dependencies. To create this relationship:
A case type is a work class that inherits from Work–Cover– and contains a case type rule. A case type can cover or be covered by other case types. A case management structure can also include work classes that inherit from Work-. These work classes may be covered by case types, but cannot cover other work classes or case types. The covering relationships among case types are defined in case type rules. As a best practice, configure the case type structure in the Case Explorer.
When a case type work item (case) is created, the case is said to be instantiated. Be careful not to confuse a case with a case type, which is sometimes referred to as a case. Work classes that inherit from Work– are commonly called work types. Case Management is the business practice that involves managing work that, for processing and reporting purposes, differs from classic Business Process Management work items. Cases may involve:
Case Management design is governed by the Cases Explorer, which is used to configure case type dependencies and related work processing. Using this Explorer you can:
|
Categories
All
Archives
October 2020
Categories
All
|