This content has been archived.

Table of Contents

Nine tactics to reduce your need for custom activities (PRPC 6.2 SP2)


Activity rules allow you to automate work using a procedural, programming-like approach. Some activities do not require Java skills or the need to manually enter Java code. Because of their power and flexibility, activities are often customized or created to perform a wide range of specialized and advanced tasks. While this might seem like an effective approach at first, this technique:

  • Requires programming skills that only some of the development team members may possess.
  • May result in complex solutions that are difficult for system architects or business analysts to understand, implement, and change.
  • Is an obstacle to reuse, particularly if an activity is designed to accomplish more than one purpose.
  • Conflicts with the business-maintained, rule-based logic inherent in the PRPC model.
  • Costs valuable time to develop, debug, and maintain.
  • May create security vulnerabilities due to hand-crafted JavaScript or Java that might not be tested or analyzed by PRPC facilities.

A large array of facilities are included in V6.2 and have been augmented in subsequent releases that provide you with guardrail-compliant and easy-to-use alternatives to activities. This article describes the enhanced capabilities that are available as of V6.2 SP2, plus a few long-established techniques.

Suggested Approach

Use a data transform rule

Introduced in V6.2, the data transform rule (or simply "data transform") quickly transforms and maps clipboard data without using activities. In general, the data transform defines how target data (such as properties and pages) is mapped from and transformed by source data. The data transform rule form is easy to use and understand — it has only two contexts (target and source), presents an intuitive tree grid of the actions, and uses contextual prompting that helps guide you through configuration. See Introduction to Data Transform rules.

Data transforms have been implemented in many areas of the product such as:

  • User interface elements, which include:
    • The Client Event Editor's Refresh This Section action
    • Refresh When conditions used in included sections and harness panels.
    • On-click control rule and navigation rule actions such as Run Data Transform, Landing Page, Refresh Section, Show Harness, Harness, and Open URL In Window
  • Starter flow rules that use the data transform to set initial properties for the work item.
  • Flow action rules that apply the data transform before or after displaying the flow action user interface to the user. See Using a data transform rule in a flow action.
  • Connector flow shapes that apply the data transform before the item reaches the next flow shape. For example, an Integrator shape connector uses a data transform to map PRPC properties to and from data in the target external system. Previously, this action was performed using property set steps in an activity.
  • Activities generated by the connector and metadata accelerator now reference data transforms to setup the request parameters and to map the response back to the work object.

Change work item status on the flow diagram settings

As of V6.2 SP2, the Properties panel on every flow shape contains a work status field. The field enables you to easily change the status at every point in the process. Previously, you had to add Utility shapes and reference activities in those shapes to invoke a status change. For example, you can quickly define work status settings when creating a stage presentation on user forms. See How to use stages to present the chevron view of work item status.

Use linked properties

A special form of property, know as a linked property, can be used to present data from data objects in a harness, section, or flow action form. Linked properties hold the value of a key to Operator ID, Organization, Access Group, or other data objects

Using linked properties eliminates the need for an activity to retrieve this data. In some situations, they improve performance through caching. For example, you can use a linked property to present an Operator ID directly in a section rule rather than use a Utility shape in the flow to fetch the Operator ID record, make it available on the clipboard, and have the section access the Operator ID page. See Use linked properties to display data from related objects

Configure case type dependencies

In hierarchical case management applications, complex activity networks are no longer required to define when cases, across multiple subcase types, can be automatically completed or instantiated. These capabilities were introduced in 6.2 SP2:

  • Mid-flow dependencies — Use a Dependent workbasket assignment shape to instruct the system to complete a case and advance the flow only when another case type instance reaches a specified work status. See When and how to use mid-process dependencies.
  • Instantiation dependencies — Use the Case Designer ( > Process & Rules > Case Management > Case Designer ) to create instantiation dependencies among subcase types. The system instantiates a case type when another case type instance starts, completes, or reaches a specified work status. See When and how to use instantiation dependencies.

Use reports to support user interface displays

As of V6.2, repeating grids, tree grids, and controls all can use report definitions to retrieve data. This can significantly reduce the need for activities to create and populate top-level pages. See Using a report definition rule as a grid layout data source.

Declare pages rules now allow you to source data directly from a report definition instead of using a load activity to create and update declarative pages.

Call Process Engine API activities

The number of process engine APIs has been greatly expanded, reducing the need to create custom activities. For example, there are now APIs for transferring assignments, transferring cases between workbaskets and worklists, linking attachments, creating subcases, and many more. To see a complete list of the APIs, go to  > Process & Rules > Process > APIs.

Use State-based validation

As of V6.2, you can use the validate rule to associate sets of validation conditions for each work item status. The flow actions list the validate rule and the proposed work status, which is passed to the validation rule so that it can execute the correct validation column. When validation passes, you set the status on any shape's Properties panel Status tab. See How to set up validation that depends on work item status.

Use declarative rules

While not a new idea, declarative rules are a proven technique to reduce the need for activities:

Declare Expression rules can ensure that computations involving property values are performed exactly when and as needed. Unlike activities, you don't need to alter flow rules or other rules to explicitly call Declare Expression rules. The contents of Declare Pages rules can be based upon a report definition rule, and the page can be refreshed automatically whenever a value is fetched from the page (or according to a schedule).

Call an existing, standard rule

Before you create a custom activity, check to see whether an existing standard, out-of-the-box rule meets your needs. While the Process Engine API activities are specifically provided to support work item processing, hundreds of other standard rules are available.

Using existing rules reduces your effort and the size of your application.

Additional information

article Ten Guardrails to Success

articleBest practices to avoid cross-site scripting (XSS) vulnerabilities

articleIntroduction to activities

Suggest Edit

95% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.