Hi everyone,
I'm building a centralized application management portal in OutSystems Developer Cloud (ODC). Unlike OutSystems 11, ODC does not provide a system entity/table such as Application that stores all application metadata within the environment. To retrieve the available applications, we need to use the ODC Asset Repository API (GET /assets) which returns the list of applications deployed in the environment. - API
Use Case:
My team develops several reusable/common components such as: Audit Framework Notification Framework Feedback Module Other shared platform services. These components require application-specific configuration. During the configuration process, users should be able to select the target application from a list of available applications in the ODC environment.
Possible Approaches:
Option 1: Call the ODC API On Demand Every time a user opens the configuration screen, invoke the Asset Repository API and retrieve the latest list of applications.
Pros:
Cons:
Option 2: Maintain a Local Staging Table Create a local entity/table in the application to store the application metadata retrieved from the Asset Repository API. The configuration screens will read from this local table instead of directly calling the API.
Questions
1. From a best-practice perspective in ODC, is it recommended to call the Asset Repository API every time the application list is required?
2. If maintaining a local staging table is a better approach:
All your inputs are welcome
Thanks,
Gowtham Shanmugam
Hello @Gowtham,
For the first option direct integration you're right that it gives you the most up-to-date data, but since it involves several calls, that introduces some latency into the system.
For the other option cold cache you sync on a schedule (e.g., once a week). The trade-off is that your data might be outdated, but you gain performance. As for which attributes to retrieve, only pull what you actually need the fewer, the better. What counts as "needed" depends on your requirements: I might say I don't need tags in the GET, but you might need them for a specific business case, and that's valid.
For the synchronization strategy, I'd recommend isolating the sync process from the local entity. Why? Because if anything goes wrong with the actual API, your entity stays isolated from that impact.
As for which approach is better as you said, each has its pros and cons, but the right choice depends on what matters most for your business. If your system can tolerate some latency, go with direct integration. If performance is the priority, cold cache is the way to go.
Also you can see this as reference:
Integration Patterns for Core Services Abstraction - OutSystems 11 Documentation
@Gowtham : If you are planning to connect to different environments to fetch the data , its worth while to go for the second approach ( your Option 2 - Cold Cache with batch sync). Also instead of directly caching the output of API to the entities, you can deserialise and store the application attributes relevant for your use case.
btw please have a look at this article : https://blog.product-league.com/near-real-time-erp-integration-to-process-large-data-with-outsystems-667840f2e72b