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.