Site Studio (SSXA): Cache de consultas RIDC

Una de las novedades de Site Studio for eXternal Applications (SSXA) es la posibilidad de "cachear" los resultados procedentes de consultas RIDC.

Por ello únicamente es necesario añadir, en las consultas "cacheables", los siguientes parámetros:

  • __ssxaCacheEnabled: Flag que establece si vamos a cachear la consulta. Para ello establecerlo a true.
  • __ssxaCacheKey: Para el caso en el que se quiera especificar la clave de caché a utilizar.
  • __ssxaCacheFields: Campos que se van a usar para "cachear" el contenido. Si no se especifica utilizará toda la información local.
  • __ssxaCacheTTL: Es el tiempo de vida del contenido en caché medido en milisegundos. Por defecto, si no se especifica valor es de 5 minutos.
Un ejemplo de uso:

Ejemplo de servicio RIDC cacheado

En el caso de querer administrar/monitorizar la caché manualmente. Se puede acceder a su administración desde la consola del Content Server de Oracle WebCenter Content (UCM):
  • Navegar hasta Administration > Site Studio Administration > External Applications Administration.
    Administración de SSXA Caché
Por último comentar que el contenido cacheado queda almacenado en archivos de formato .hda en una estructura de carpetas con la siguiente nomenclatura:

/idc-service/service_name/user_name/cacheID.hda

Donde:
  • service_name: Es el nombre del servicio RIDC ejecutado. Por ejemplo: get_search_results.
  • user_name: Nombre del usuario que ejecutó el servicio RIDC.
  • cacheID: Compuesto por el __ssxaCacheKey y __ssxaCacheFields en el caso de haber sido proporcionados.
Un saludos a todos.

Referencia: Documentación oficial de Oracle para SSXA.

PD: Espero tener el ejemplo de integración WebCenter Spaces API - WebCenter Portal pronto :).

Comments

Post a Comment

Popular posts from this blog

OJET: Inter-Module communication in TypeScript Template

Image
In this post I bring another example on how to Communicate Modules using the Oracle JET - TypeScript Template based on the Oracle JET Cookbook: InterModule Communication From now and so on will create multiple examples using TypeScript for those who are not familiar with it and wants to turn the Cookbook examples into TypeScript :). The example ( ojet-typescript-list-detail ) can be found as usual in my GitHub repository: https://github.com/DanielMerchan/ojet-examples This example is a bit different compared to the Cookbook example where the modules are not running at the same time within a Module. This example is built as described in the following images: Customers module acts as the Wrapper Module. It coordinates when to load the list and detail modules. Customers module makes use also of signals npm module for communication between Customers-List, Customers-Detail. Explanation of the Example customers.js is the coordinator responsible module for: initiali
Read more

OJET: Build and Deploy in an Application Server

Image
There are some other sources where an Oracle JET Application is packaged and deployed as a WAR in Oracle WebLogic Application Server (Arda Eralp) https://blogs.oracle.com/ardaeralp/deploy-oracle-jet-application-to-weblogic-server (Andrejus Baranovski's) http://andrejusb.blogspot.com/2016/07/serving-oracle-jet-application-from.html They may look bit old or maybe because they call directly grunt tasks by using the grunt-cli . In this post I will update a bit these posts in Oracle JET 6.1.0 and the usage of ojet build (instead of calling the grunt tasks) for also building the corresponding WAR file. The example can be found in my GIT repository: https://github.com/DanielMerchan/ojet-examples Let's start... Install grunt-war module in your Oracle JET Application. npm install grunt-war --save-dev Create a war.js (or call it whatever you want) in /scripts/grunt/config folder under your souce files. This is a sample code inside of it, check https://www.npmjs.com/packag
Read more

OJET: Select All options using only Checkboxset

Image
This is an example on how to select all other options by using another oj-checkboxset. GitHub: ojet-checkbockset-select-all The idea is to keep track of the selection and make use of the on-value-changed as described in the following code. self.colorOptions = ko.observableArray([ { id: "blueopt", value: "blue", color: "Blue" }, { id: "greenopt", value: "green", color: "Green" }, { id: "redopt", value: "red", color: "Red" }, { id: "limeopt", value: "lime", color: "Lime" }, { id: "aquaopt", value: "aqua", color: "Aqua" }, ]); self.selectAll = ko.observableArray([]); self.currentColor = ko.observableArray(["red"]); self.selectAllOptionChanged = (event) => { const newSelection = event.detail.value; if (newSelection.indexOf('all')
Read more