Enterprise Software Installation & Pega PRPC Quiz

Access Roles in PRPC control which workpools a user can access. Workpools determine which work items a user can open and work on. Option A is incorrect because Access Roles are not only for defining Work Parties - they have broader scope. Option C describes Work Parties more accurately than Access Roles. Option D is incorrect - using predefined roles is not recommended because they may not match organizational security requirements.

A Work Party represents a person, group, or organization that has a stake in the work but typically does not perform the work themselves. Examples include customers, suppliers, or stakeholders who need to be notified or involved in the process. Option B is incorrect because a Work Party is external to the Workgroup. Option C is too narrow - Work Parties extend beyond just originators and managers.

Windows Installer (msiexec.exe) operates as a system service that manages the installation, modification, and removal of software packages. It runs in the background with appropriate privileges to handle file operations, registry changes, and system configuration required during installation. While it uses technology and provides automation capabilities, fundamentally it is a Windows system service.

Windows Installer supports three upgrade types: Small Updates (minor changes like hotfixes, same version), Minor Upgrades (changes to some files, version change within same major version), and Major Upgrades (significant changes, new major version). The question lists 'Small update', 'Minor upgrade', and 'Small upgrade' (likely meant Major), so 'All of the above' is the correct choice.

Administrative installation creates a network installation point by extracting files from the MSI but does NOT actually install the software, register DLLs, or make registry changes on the local machine. It's essentially an unpacking operation for deployment. Commit, Silent, and Rollback installations are all actual installations that register components and modify the system.

From an end-user's perspective in Windows Installer, a Feature is the smallest selectable unit they see and can choose to install. Users select features like 'Documentation', 'Application Core', or 'Tools' in the installation tree. Features are composed of one or more components, but components are developer-level constructs that users don't directly interact with.

From an installation developer's perspective, a Component is the smallest installable unit. Components contain the actual installation items: files, registry keys, shortcuts, etc. Each component has a unique GUID and is installed as an atomic unit - either all its items are installed or none. Features group together components to present user-facing selections. Developers work with components; users interact with features.

In Windows Installer, REINSTALLMODE controls how files are reinstalled during maintenance operations. The vomus mode ensures a comprehensive reinstall: v recalculates install state, o handles versioned files, m covers missing files, u handles user registry, and s manages machine registry entries.

The REINSTALL property with ALL value instructs Windows Installer to only process features that were previously installed. It does not install new features - for that, you would use ADDDEFAULT or similar properties.

Key files (usually the main executable) and key paths are detection mechanisms Windows Installer uses to locate a valid installation source. When performing repair or modification operations, the installer verifies these files exist at expected locations before proceeding.

InstallShield, the popular installation software for Windows, was founded in 1987 by Viresh Bhatia and Rick Harold. It became the de facto standard for software installation on Windows platforms throughout the 1990s and 2000s.

Access Groups in PRPC control all aspects of user access: the work pools available to users, the portal layout they see, and the access roles and privileges they hold. Access Groups are the primary mechanism for configuring what users can see and do in the system, making 'All of the above' the correct answer.

Access Roles in PRPC control the workpools that a user can access - they define which sets of work objects a user can open and work with. Access Roles are not just for Work Parties (that's what Work Parties are for), don't directly represent authority levels (that's more about privileges), and custom roles are frequently needed beyond the default ones.

A Work Party in PRPC is a person, organization, or other actor identified in a work object who can be the recipient of correspondence such as emails. Work Parties represent the real-world participants in a business process. They are not merely Role/Class associations, entries in Access Group records, or entries in OperatorID records - those are different PRPC concepts.

In the early stage of design for PRPC integrations, you should create a list of systems to interact with, information types needed, and interconnect mechanisms - but NOT the detailed message specifications. Message details come later in the design process. Option A includes message details (too early), B excludes them (correct approach), C includes message-to-property maps (too detailed), and since B describes the correct early-stage approach, 'None of the above' suggests the question's options don't properly capture the right answer.

A PRPC Application is a solution designed to support the business processes of a single company or organization. It's built for one specific client's needs. A PRPC Product (option B) is different - it's a reusable solution that can support multiple companies. Applications are single-client implementations, while Products are multi-client frameworks.

A PRPC Product is a reusable solution that can support the business processes of multiple companies or organizations. Products are designed to be customizable frameworks that different clients can implement. In contrast, PRPC Applications (option C) are single-company solutions. The generic name for any PRPC solution is simply 'PRPC solution' not 'Product' specifically.

Pega's naming convention for RuleSets recommends PascalCase (compound words with each word capitalized, no spaces or hyphens). 'MyCoOrders' follows this convention correctly. 'MyCo-Orders' uses a hyphen (incorrect), 'Orders' is a single word (not a proper compound), and 'mycoorders' is lowercase (incorrect). The correct format is company name concatenated with purpose, both in PascalCase.

RuleSets in PRPC are NOT designed to provide security - they are version control and packaging mechanisms for rules. Security is handled by Access Groups, Access Roles, and Privileges. Using RuleSets for security is a misunderstanding of their purpose. RuleSets organize and version rules, but don't control who can access them.