Enriching an integration from data in a database or DBaaS (Database as a Service) is not an unusual requirement. Many integration use cases today need to access a database that is on-premises. The means to connect to the database is fairly obvious – the connection agent. Our book goes into a lot more detail as to why that is, and the implications of using database connections.
However when it comes to Oracle’s DBaaS a service it would be very easy to assume that given that you’re using two different parts of Oracle’s PaaS that it would be straight forward to connect the two together without an agent. However, at least today whether its on-premises or DBaaS you need to use a connection agent. This does mean that you’ll need an IaaS node to host the connection agent.
This quirk is driven by the fact that there are some scenarios that this does actually make sense. For example – the Oracle domains need to have a high level of isolation, so when the DBaaS is in another domain then the decoupling via the agent makes sense. When your database is in a different zone of the cloud – then you’re running DB calls across what is effectively a wide are network – not good.
Connecting DBaaS Option
There are other ways to solve this problem depending upon which version of DBaaS you areusing. Within Oracle databases is a compnent available called APEX (or Application Express) which can include something called ORDS (Object REST Data Services). The use of ORDS means that we can expose parts of the database with a REST service. This makes it relatively simple to now open the database without needing the IaaS node and the deployment of the connection agent. The details for using ORDS with DBaaS can be found here.