Oracle Rest Dataservices (ORDS) is truly an underrated feature of the Oracle Database, and now with it being an embedded feature in the Cloud Autonomous Databases, it's truly a feature that is a MUST!
Click on the images to zoom in!
So what? How is it useful? Well, here is a use case where Oracle Integration Cloud is interfacing with Visual Builder to push and pull data from the VBCS Business Objects (BO's) using the REST API layer on the BO's. This is a real use case that many Oracle clients have, specially those that implemented OIC and VBCS back in the Gen 1 days, and using the REST support at the BO layer was the best approach to integrate with VBCS.
In the above we can see that the individual calls to update BO attributes can take a long time, because OIC is iterating through a lot of data, making decisions and making updates. There's also plenty of opportunities for disruption during the API chains, and retriggering is far too complex.
Let us know observe the same scenario, but utilizing ORDS instead:
As noted above, this is far simpler, performs better, less failure points, easier to maintain and support, this is the power of ORDS!
It is a perfect match for VBCS because visual builder wants to speak REST, and ORDS provides an excellent opportunity for that to happen while also taking advantage of the power of the stored procedures to manipulate the BO's at the database level without hitting the VBCS middle tier and relying on complex API interactions.
Below are some additional use cases:
To expand further on the above:
VBCS calls a logging/audit stored procedure exposed as REST via ORDS, to log exceptions being raised in the action chains in VBCS (blocks of code), because right now we have to have user sessions and capture the problem real time via dev tools, unless the message is being handled and shown to the user on the screen, and a lot of them are not, so this is a great way to be proactive and see trends of errors and warnings from user activity.
Many are in the process of replacing BIP reports being used as custom API’s and called from VBCS (which is a common pattern that many have used), by instead utilizing ERP/HCM API’s where feasible, but there's always cases where we will still need to use BIP in this manner, because API support doesn't have the columns or filters required, or the API may just not exist, as an example.
My recommendation here is to instead schedule the BIP extracts and load the data to the VBCS ATP (if you have your own tenant database for VBCS, which you should), then create stored procedures to retrieve it from VBCS via REST, and that way you do not hammer ERP/HCM via the BIP layer, and just hit it once when the scheduled job runs instead. If you don't use VBCS but extract data out of ERP/HCM into your own downstream database, you can do the same rather than allowing direct API traffic into ERP/HCM, and this isn't limited to BIP extracts. Meaning, you can extract data from Fusion using BICC, and other means better than BIP, into a warehouse or data lake and then use ORDS to create an API layer for systems, if the frequency of data needs align.
Lastly, the below talks about the simplicity of deploying ORDS assets, which is very important due to stringent requirements from TO Security around code quality scanning and vulnerabilities with tools like SonarQube. Since ORDS and APEX when exported are just SQL and PLSQL files, there's not much to be concerned about, unlike with high code frameworks with extensive projects with hundreds of files in the build artifacts).
ORDS is an excellent tool on it's own right, and when paired with APEX it can do wonders, but that's a topic for another day!
No comments:
Post a Comment