Pega Exchange Guidelines
Before submitting a component to the Pega Exchange, please review these guidelines to assure that your contribution meets all of the necessary requirements to be accepted. This overview includes a set of best practices that you should follow to create the easiest and simplest experience for people that want to download and install your components.
Ease of use is paramount in making the Pega Exchange successful, and in ensuring that each component is used to its fullest potential. Ease of use is important not only for a component once it is installed, but also for the installation procedures for each component. Thus, the focus of the blueprint is to eliminate all difficult or cumbersome steps involved in both the installation of a component, and the eventual use of that component.
Elements of an Exchange Component
There are three essential elements of a component: (1) the installation manual, (2) the administration console, and (3) any supporting JAR files. NOTE: The Printsoft plug-in, which includes all the above elements to the specifications below, should serve as your template for component development.
The installation manual needs to include the following:
- Version of PRPC used during development,
- Application server name and version that the component was built on
- Version of the java JDK installed at the time of development.
- Min/Max JVM memory setting for application server
- Version of Visio used to create any process diagrams
- Any frameworks that the component may rely on (i.e., Retail Banking Industry Framework (RBIF), Multi-channel Insurance Framework (MCIF), etc.)
- PRPC database and version information
- What JDBC driver was used during development
In addition, the manual must include screen shots of each step of the installation process. Please refer to the Printsoft plug-in as an example of best practice documentation for the Exchange.
The administration console needs to include the following:
- A portal view
- An access group (using the portal view for the component)
- Admin user (with the access group above)
- My rules section (containing all rules related to your component)
- Admin wizards (most likely a screen flow) to use and setup component. The wizards should be accessible through the new work gadget
As a general rule, people who want to use a component should NOT be forced to do any of the following manually:
- Create or delete classes
- Create or delete properties
- Create or delete activities
- Copy activities to the class containing the business process where the component will be used
Wizards should take input from the user, and generate the above rules in the appropriate classes.
The administration console consists of a portal view for people who need to use the component. Any rules that are involved in the use of the component must be delegated to the administrator account.
The name of the administrator should be easy to remember. For example, the Printsoft component's admin account is printsoftadmin, and the Documentum component's admin account is documentumadmin.
Some components may require supporting Java classes. These Java classes should be packaged as JAR files to simplify deployment. Make sure to include a description of how to deploy the JAR files in your installation procedure documentation.
Just as important as the class packaging (i.e., in a JAR file) is the way the class is used within PRPC. Your custom Java classes should NOT be used directly within a Java step in an activity. All access to your Java classes should be through Rule-Utility-Functions, and these Rule-Utility-Functions should be in a Rule-Utility-Library with a name relevant to the component. For example, the Printsoft plug-in contains a Rule-Utility-Library called Printsoft, and within the library resides several Rule-Utility-Functions that access elements of the Printsoft jar files deployed on the application server. Once again, please download and install the Printsoft plug-in as a template for your component development.