Understanding Microservice Client Extensions
Applications often need to integrate with external systems, react to platform events, or extend platform behaviors without modifying the platform itself. When custom logic is tightly coupled to Liferay's internal services, solutions are harder to maintain, slower to scale, and difficult to upgrade. Microservice client extensions are decoupled, standalone applications that communicate with Liferay through OAuth 2.0-secured headless APIs. This is particularly essential for cloud-native applications and businesses requiring rapid iteration and independent scaling for their services.
Common scenarios for microservice client extensions include:
- Creating communication channels between Liferay and external systems.
- Offloading tasks from Liferay to a secondary system.
- Prioritizing a loosely coupled architectural design.
- Empowering independent teams to maintain a cohesive overall strategy while managing their own build and release processes.
In this lesson, you'll learn how microservice client extensions work, the types Liferay provides, and the considerations for using them effectively.
Integration Using Microservice Client Extensions
Microservice client extensions integrate through REST endpoints, which empowers you to consume external services directly within Liferay without implementing additional portal logic. This provides a distinct advantage over traditional OSGi modules that tightly couple with platform components.
These are the essential components of a microservice client extension:
- A descriptor
client-extension.yamlfile for the extension. - The elements that make up the microservice.
The Liferay Sample Workspace provides example microservice client extension projects using Node.js and Spring Boot, which you'll explore later in this course. Node.js and Spring Boot are starting points only; the REST-based communication of microservice client extensions empowers you to use any technology that can produce headless API requests and consume the responses, with adaptability to follow best practices for that specific technology.
Types of Microservice Client Extension
Microservice client extensions include several types that handle business logic, manage data, integrate third-party systems, and perform other data-driven actions, depending on the type. These are the primary types:
| Type | YAML Definition | Example Use Case |
|---|---|---|
| Object Action | type: objectAction |
Call external APIs when a custom object is created to synchronize the data with another system, such as a CRM or ERP, or trigger some internal business logic. |
| Object Validation | type: objectValidationRule |
When data is entered into an object field, implement your own custom check for validation, preventing the entry to be saved in case the validation fails. |
| Workflow Action | type: workflowAction |
Run external checks verifying with third party systems when a workflow reaches an approval stage. |
| Notification Type | type: notificationType |
Send personalized emails or SMS notifications when users complete object forms, integrating with third party messaging platforms to handle the communication. |
| Captcha | type: captcha |
If you want to integrate a different third-party CAPTCHA provider from the ones natively supported OOTB by Liferay, to verify a human user is accessing your site and not a bot or malicious code attacking it you must use a CAPTCHA client extension. |
With the exception of cron jobs, microservices share the same basic execution behavior. When the extension is deployed, Liferay processes the package and registers a new client extension. These microservice extensions then hook into a Liferay process and offload tasks to the specified endpoint.
These are some typical use cases where microservice client extensions are ideal:
- Enterprise System Integration: Integrating with CRM or ERP systems where sensitive data and strong authentication are essential.
- Data Processing: Handling data-intensive tasks that require secure and controlled access.
- Microservice Architectures: Managing integrations with multiple microservices that require varying levels of access.
Examples: Object Action
Consider a scenario where a system must notify users if their account is accessed from an unusual location. This can be implemented with an Object Action using the On After Login trigger. After a user signs in successfully, Liferay invokes the configured Object Action, which sends a payload to a microservice client extension. The microservice compares the request's IP address against the user's login history. If the location is unfamiliar, the microservice calls back to Liferay to generate a security notification. Because the On After Login trigger is a post-login event, it does not intercept or block authentication. The user's session is unaffected, and the microservice executes its logic in the background.
Alternatively, Object Actions can be configured as Standalone, meaning they run only when invoked manually rather than by an automatic system trigger. Standalone actions are asynchronous and always return HTTP 204 No Content, making them ideal for fire-and-forget workflows. For example, a user could click a button to trigger a background data sync; the UI instantly registers the 204 success, allowing the user to keep working while the microservice processes the payload externally.
Example: Object Validation
Consider a scenario where an application requires a valid business tax ID before an entry can be saved. This can be enforced by configuring an Object Validation rule that calls a microservice client extension to verify the submitted ID against an external registry. If the validation fails, the microservice returns an error message, and Liferay blocks the entry from being created.
Because Object Validation is synchronous, it is best suited for lightweight, fast checks like format validation or quick external lookups. For checks involving slower external services or complex approval logic, a workflow is a better choice. Workflows decouple the data submission from the validation latency and provide more control over the overall lifecycle.
Benefits of Microservice Client Extensions
Microservice client extensions offer several benefits for integrating and extending Liferay DXP with external systems:
- Flexible Integration: Integrate with any system or service, regardless of underlying technology, as long as it supports REST.
- Decoupled Systems: Reduce dependencies by facilitating loose coupling between Liferay and external systems.
- Improved Maintainability: Lower total cost of ownership and improve maintainability by enabling independent teams to work on separate microservices, supporting parallel development and efficient resource allocation.
- Software and Asset Reuse: Use existing systems and services within your current infrastructure to improve development time.
Considerations for Leveraging Microservices
Before deciding whether microservice client extensions are right for a specific use case, consider these important factors. These extensions are backend services with no frontend or visual element added to Liferay. Similarly, microservice client extensions are only registered through deployment and cannot be manually added through Liferay's administration UI. Microservice client extensions are primarily suited for offloading tasks to separate systems and are not always ideal for other integration scenarios.
Troubleshooting Microservice Client Extensions
When working with microservice client extensions, keep these specific troubleshooting suggestions in mind:
- Replace hard-coded paths and only reference injected route information.
- If you observe issues related to scopes, redeploy the client extension as a first troubleshooting step.
- Avoid creating excessive API calls. Too many calls will exhaust the system's available threads, causing performance issues. Connection pooling and rate limiting help prevent thread exhaustion. GraphQL queries are another approach for resolving such issues.
Clarity's Microservice Client Extensions
Clarity plans to use microservices to offload distributor management account creation. They've created a workflow managing the approval process and configured an object action to trigger on application approval. When its trigger fires during runtime, the action invokes the registered extension's REST endpoint and waits for a response. The microservice queues the object action's request, processes it, and sends a response back to Liferay to create a new account.
With a microservice client extension, Clarity can independently develop components of the approval process using diverse technologies suited to specific needs. These pieces are then orchestrated to achieve the overall objective, while their loose coupling ensures easy modification and scalability.
Conclusion
Microservice client extensions empower flexible, agile development through standards-based headless APIs. These extensions act as a bridge between Liferay and external microservices, handling business logic, managing data, and integrating third-party systems.
Next, you'll explore how scheduled microservices automate background tasks on a defined frequency.
Capabilities
Product
Education
Knowledge Base
Contact Us