Activity rules provide us with one way to automate the processing of work in pega applications using a program-like approach.
A data transform rule provides a purpose-built rule for easily transforming and mapping clipboard data without using activities. In general, the data transform defines how target data (properties, pages, etc.) is mapped from and transformed by source data (properties, pages, etc.).
Activities are harder to maintain and not as easy to construct as other rules in PRPC.
We should not use an activity for calculations or property validations that we can implement as constraints rules or Declare Expression rules. Use of a declarative rule (rather than an activity) eliminates the need to control how and when an activity executes. A best practice is to use declarative processing rather than activities when feasible.
For data manipulations, we can use a Data Transform instead of an activity.
To query from an external DB, we can use Report Definition rules instead of activities.
We may need to automate the processing of cases with a sequence of steps to be executed. Most of the time, this is possible with the steps in the case designer or multiple shapes in a flow rule or with declarative rules or data transform rules or a combination of those and other rules.
Also remember that before writing our own activities, take a look at the standard activities that come with PRPC.
There are certain scenarios where we cannot avoid writing an activity. For example:
To perform Case related functions such as creating a case instance, routing the case, or updating the work status, as part of certain operations such as parsing an input file.
To send requests to external systems or to receive requests from external systems.
To perform functions such as writing to a log file or to the history database.
A data transform rule provides a purpose-built rule for easily transforming and mapping clipboard data without using activities. In general, the data transform defines how target data (properties, pages, etc.) is mapped from and transformed by source data (properties, pages, etc.).
Activities are harder to maintain and not as easy to construct as other rules in PRPC.
We should not use an activity for calculations or property validations that we can implement as constraints rules or Declare Expression rules. Use of a declarative rule (rather than an activity) eliminates the need to control how and when an activity executes. A best practice is to use declarative processing rather than activities when feasible.
For data manipulations, we can use a Data Transform instead of an activity.
To query from an external DB, we can use Report Definition rules instead of activities.
We may need to automate the processing of cases with a sequence of steps to be executed. Most of the time, this is possible with the steps in the case designer or multiple shapes in a flow rule or with declarative rules or data transform rules or a combination of those and other rules.
Also remember that before writing our own activities, take a look at the standard activities that come with PRPC.
There are certain scenarios where we cannot avoid writing an activity. For example:
To perform Case related functions such as creating a case instance, routing the case, or updating the work status, as part of certain operations such as parsing an input file.
To send requests to external systems or to receive requests from external systems.
To perform functions such as writing to a log file or to the history database.