API Bridge

API Bridge

Inspiration

While working with Pega Platform, I have noticed most of the enterprise Pega projects uses JMS or MQ integrations for various reasons.

There are several advantages with Topics and Queues. Systems can be fully isolated to have increased fault tolerance. For example, source system can send messages to a queue, and target system can pick up messages from the queue. If there any downtime with target system, still the source system can send messages to queue and will be picked up when target systems become available again. Also, it is easier to achieve elasticity with horizontal scaling by cutting down unnecessary infrastructure costs, since any number of systems can pick up messages from queue and process individually. Unnecessary systems can be deprovisioned as workload decreases.

However, modern applications are usually built with REST microservices which are widely compatible. There are modern applications which doesn't support MQ or JMS natively, and in the other hand, there are legacy systems which doesn't support REST API calls. Even Pega is natively support JMS and MQ, newly build apps are architectures with REST APIs to be compatible with future integrations. To Fill this Gap, most of the Pega development projects are having Microservices Development team working in parallel. These microservices become useless when legacy systems are updated.

API Bridge is Pega based component which can be deployed in same application, separate application on same node, different node in the cluster, or totality different system. API bridge converts API calls into different types such as REST to JMS, REST to MQ, MQ to REST, etc. So, the systems can exchange messages/payloads with each other regardless connector interface.

With Pega’s compatibility with multiple web services and connectors, Pega customers can eliminate the need of temporary microservices to bridge between modern applications and legacy applications. API Bridge component also supports to achieve integration rapidly, easily with few clicks. IBM MQ messaging REST API and IBM MQ bridge for HTTP are two examples which are doing similar bridging between IBM MQ and REST API. However, this API Bridge Pega component has lot more capabilities beyond those such as scheduled invocation of API calls, pre-built Serverless function invocations and etc.

What it does

Convert API requests from HTTP, REST, JMS, MQ to HTTP, REST, JMS, MQ and Serverless RSET API endpoints (such as AWS Lambda, Azure Functions, etc.)
Invoke Target API call on a scheduled time.
Retry failed API call again (after a configurable time) to automatically recover from failures.
Asynchronous request processing with true decoupling and load balancing.
Allow businesses to quickly integrate with legacy (JMS, MQ, etc.) systems or Serverless functions with few clicks.

How we built it

Created using in-built Pega JMS, MQ, HTTP, REST and other service and connector capabilities.

Challenges we ran into

One of the challenges was installing JMS or MQ topic or queue to support development of JMS/MQ services and connectors. Installed Apache ActiveMQ in local server, but there were connectivity issues. Therefore, Skipped MQ and JMS implementation. But the design is straight forward and can be implemented easily when topic/queue is available.

Obviously, another challenge was time constrain. Got to know about hackathon bit late, (around end of March) and completed parallelly with office work. Even this is not selected, planned to take this concept forward with Pega Marketplace (Exchange) Component by improving capabilities.

Accomplishments that we're proud of

This is my first step towards a Pega Marketplace component. Proud to have a submission to Pega community Hackathon 2021 to crush complexity of businesses.

What we learned

With this Hackathon, I could improve my knowledge on various services and connectors supported by Pega, Apache ActiveMQ with queues and topics, Serverless function innovation and lot more areas.

What's next for API Bridge

As of now, the component only works with REST API calls. This is due to limited resource availability such as JMS/MQ queues and topics. Component will sooner be updated with JMS and MQ. Also, component will be updated to have API scheduling capabilities and Profile management capabilities to invoke API call to different targets using different auth profiles, etc. Dedicated dashboard (with Cosmos UI) can also be provided to manage connector profiles, scheduling, see exceptions and logs, and more.