Skip to main content

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

About Components

Suggest edit Updated on March 24, 2008

Summary

A component is a set of rules which contain encapsulated functionality.  Components hold a standalone process which can be embedded in multiple applications; they do not depend upon one application’s rules or functionality.   Use a component when you have functionality that could be applied to more than one application, such as a credit score calculator. 

Components are built in a component RuleSet.  They should be self-contained; all the necessary rules for the execution of their process should be in this RuleSet (not in an application or another Component). 

There are two component wizards to aid in implementing components; both are available from the File > New menu.

These tools are part of the optional Direct Capture of Objectives feature. The wizards are available to developers whose RuleSet list includes the Pega-AppDefinition RuleSet.

 

Suggested Approach

As stated above, components should be created when you have some functionality that could be used in multiple applications.  Components hold a standalone process which can be embedded in an application to help process that application’s work objects.  The phrase “standalone” does not mean that the Component can exist completely independently, however; it must be embedded in applications, but its functionality is independent - it does not depend upon any application’s rules.

Once a component is embedded into a application, it can receive inputs from a work object in that application.  The component processes these inputs, and creates output data; the application then accesses the resulting output using Declarative Expressions.

Components should not create work objects. There are two kinds of processing that may be included in components:

  • activities – use these for components which are doing calculations (like computing a credit score – see below). 
  • flows – use these for component functionality that needs user interaction, and will require a harness or other user interface

These flows and activities are considered the entry points to the component, where the application can enter to call the functionality of the component.  You can have other flows or activities in the component which are called by the entry point flows and activities, but only the entry points are used directly by the application.

When testing your component, you should be able to run the entry point flow or activity, enter the appropriate inputs, and have the component produce the correct output.

Components should be contained within one component RuleSet; any functionality needed to run the components should be in that RuleSet (as opposed to in the application or the prerequisite application). 

Not all functionality, even a stand-alone process, is suitable to become a component.  As stated above, if a set of rules contains a complete, fully-functional application (which creates work objects which are saved to the database), then that is not a component – that is an application.  Likewise, if features are defined in more than one RuleSet, they should not be defined as a component, as a component should be contained all in one RuleSet.

You might also have a set of rules which you need to include in a number of applications, but they don’t include flows or activities (such as corporate logo rules).   Instead of defining this group of rules as a component, define it as a shared RuleSet

There might also be a set of rules which provide some functionality, but which aren’t involved in work object processing.  For example, the “Bulk Operator Load” tool was designed to load information for multiple users into Operator ID records.  This is very useful functionality, and would apply to multiple applications.  However, it isn’t involved in work object processing, so it would be considered more of a tool than a component.

Component Examples

An example of a component would be a Credit Score calculator.  A bank has three applications that it uses:  CarLoan, MortgageApplication, and HomeEquityCreditLine.  All of these applications require knowing the applicant’s credit score. 

A Credit Score component might use an activity to go to external systems to request the applicant’s:

  • payment history
  • outstanding balances
  • credit history length
  • types of credit used

It would then calculate the credit score of this applicant, and enter the information as part of their application.

Components may provide more than one function.  Another example of a component would be the Outlook Calendar component, which might schedule appointments or meetings as part of processing home loans.  This could include a number of activities:

  • AddAppointment
  • UpdateAppointment
  • RemoveAppointment
  • AddLiveMeeting
  • UpdateLiveMeeting
  • RemoveLiveMeeting

Not all of these activities may be called in a particular application, depending upon what features that application requires.

How Components Work

Components must be embedded into applications; they must get their inputs from this application, and do some calculations or processing via a flow or an activity.  Then the application accesses the resulting output.

A component will have one main class defined for all of its rules; the flow or activity would be defined on this class, along with the property or properties which hold the output data from the processing.  As shown in the examples above, a component could have multiple entry points and thus multiple flows or activities.

An application using this component must be able to provide inputs to the component activity or flow, and also access its output data.   Therefore, as part of the work object, you create a page property which has an embedded page of the class of the component.  This allows your application processing to access the component, provide inputs, and receive outputs. 

For each of the component output properties, you also create a target property in the application, and then set the value of the target property to the value of the output property using a Declarative Expression.  (If there is more than one output property, there would also be multiple application target properties and multiple Declare Expression rules.)  Thus, each time the component does its calculation or processing and changes the output property value, the application property is automatically updated with the new data.

As a best practice, use the wizards to create and embed components. See How to create a component and How to embed a component into an application.

Did you find this content helpful? YesNo

85% found this useful

Have a question? Get answers now.

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

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us