Integrating with external applications
Modern enterprise applications and the data they process are rarely self-contained. Integration protocols and interoperability standards provide access to read and write data that is housed in a variety of systems of record; you can design applications that link multiple physically distributed resources. Pega Platform™ provides a comprehensive range of data and integration capabilities that simplify the task of connecting your application to distributed resources and gain access to the processes and data they offer.
Pega Platform supports a range of integration standards and communication protocols, allowing you to focus on addressing the business requirements of your application rather than on connectivity development. For example, your application can connect to an external database or consume data from an external web service.
However, many external systems still in use today were not designed to share data with other applications. These external systems do not have an API for sharing data. Other systems may have an API that you cannot access, or the API is insufficient to support your business requirements. In these situations, you can use the Pega Robotic Process Automation (RPA) integration capability when no other integration option is feasible.
Achieving the best business outcome requires you to align the business requirements and IT infrastructure with the most appropriate Pega integration capability. Knowing when to apply Pega RPA as opposed to a Pega integration connector helps yield an even higher return on investment.
The following example applies the appropriate Pega integration capability to achieve an optimal business outcome.
U-Plus Bank has recently acquired several banks; as a result, there are multiple customer systems of record (SOR). When customers contact the bank to change their address, a customer service representative (CSR) initiates a Pega change of address service case. The case prompts the CSR to enter the new address. Once customers validate the new address, the case workflow proceeds to update the address to one of many possible systems of record. If the address is stored within U-Plus Bank's own customer SOR, the case updates the address in real time by using a standard API connector, which exchanges the data between the Pega application and the SOR immediately. This update is possible because both Pega and the customer system of record understand and support a standard protocol for information exchange.
When repeating this example for customers who opened their account with one of the acquired banks, the SOR is an older legacy system that does not support an API for data exchange. For this customer, the Pega change of address case allows the CSR to initiate Pega Robotic Process Automation in attended mode. Attended RPA refers to automation that works alongside a human involved in the process. This automation triggers a robot to update the address by opening the SOR’s front end, which could be a desktop or web application or even a terminal screen. The robot then fills in the new address fields by interacting with the user interface in real time, effectively performing the same job that the CSR does manually but in a fraction of the time.
Both address change updates can also run in the background, in unattended RPA mode. The difference is that the address change request is placed in a queue for processing later. Unattended RPA offers the advantage of optimizing system resources and reduces peak loads. This approach is also ideal when the update process takes time because it allows the CSR to continue servicing the customer instead of waiting for the address change to complete.
Robots execute real-time attended or unattended RPA tasks. To help manage and provide insight into robot performance, Pega provides a control tower application: Pega Robot Manager™. Pega Robot Manager allows you to monitor and schedule RPA robots and provides performance analytics for all robots.
U-Plus Bank's approach to using both Pega RPA and integration connectors to connect to different customer systems of record aligns with the bank’s long-term strategy of unifying on a single, modernized customer SOR. Pega Platform separates the application functionality from the integration details so that it is easy to replace robotic automations with an integration connector once the bank unifies on a single system of record. The data source and integration layer are separated from the application layer so that future changes to the systems of record have a minimal impact on the application.