Distributed application case interactions

You can expose Pega case types to the external application by generating mashup code or by generating microservice code from within the case type settings in Dev Studio. The method you choose depends on your use case and requirements.

Pega Web Mashup, formerly known as the Internet Application Composer (IAC), allows you to embed mashup code in any website architecture. Use this option when you need to embed Pega UI content into the organization's website, whether it is hosted on-premise or on Cloud. For example, you could embed a credit card application case type into a bank's corporate website.

For more information on deployment and configuration options, see the Create a Web Mashup landing page on the Pega Community.

A microservice architecture is a method for developing applications using independent, lightweight services that work together as a suite. In a microservices architecture, each service participating in the architecture:

• Is independently deployable
• Runs a unique process
• Communicates through a well-defined, lightweight mechanism
• Serves a single business goal

The microservice architectural approach is usually contrasted with the monolithic application architectural approach. For example, instead of designing a single application with Customer, Product, and Order case types, you might design separate services that handle operations for each case type. Exposing each case type as a microservice allows the service to be called from multiple sources, with each service independently managed, tested, and deployed.

While Pega Platform itself is not a microservice architecture, the Pega Platform complements the microservice architectural style for the following reasons:

• You can expose any aspect of Pega (including cases) as a consumable service, allowing Pega to participate in microservice architectures. For more information on Pega API, see the Pega API for the Pega Platform Pega Community article.
• You can create this service as an application or as an individual service that exists in its own ruleset.
• You can reuse services you create across applications, leveraging the Situational Layer Cake for additional flexibility in what each service can do, without overloading the service.