The business process management tool Horus Business Modeler as well as the new Tool Horus 3.0, which is currently in development, are now both certified to run on an Oracle Autonomous Database Cloud instance. This comes in handy if you do not have a spare database instance or if you do not want to perform the management of an ordinary (Oracle) Database. It is even possible to run it with the free tier of the database, within the limits of the instance which include limited storage (20 Gigabyte) and only 1 compute node for the database. The following will describe what was necessary to enable both tools to run on Oracle Autonomous Database as a data storage option. I want to thank a lot to Daniel Wieland who implemented this, made the necessary changes to the tools and shared his detailed experiences!
To be able to use Horus 3.0 with the Oracle Autonomous Database we had to first upgrade all our jdbc driver jars (ojdbc8.jar in 19.3 version, see https://www.oracle.com/database/technologies/appdev/jdbc-ucp-19c-downloads.html
) to the latest versions to add support for the wallet-based connections. After the upgrade we configured the tool to use the existing tablespace (tablespaces are managed on the autonomous cloud instance and cannot be controller by the user, see https://docs.oracle.com/en/cloud/paas/autonomous-data-warehouse-cloud/user/experienced-database-users.html#GUID-604A08F8-8021-43CE-AA95-823045E14BD8
) and the tool was ready to run.
Horus Business Modeler
As with Horus 3.0 we first upgraded all the jdbc drivers and added support for the wallet-based connections. Up until this point everything looked fine. But as it turned out to run the Horus Business Modeler on the Autonomous Cloud instance was more of a challenge. We encountered multiple problems all basically linked to storing XML in the database tables. The Oracle Autonomous Database has some limitiations that are described in https://docs.oracle.com/en/cloud/paas/atp-cloud/atpdg/experienced-database-users.html#GUID-B58C3262-EB61-470D-9060-730763FBCE32
. To solve those problems, we implemented switches in the database setup to have more fine-grained control over the code executed during the database initialization. If it is run on a normal database instance, we needed it to perform all operations as usual and manage its own tablespaces, datafiles and xml storage. On the autonomous instance the tablespaces and datafiles are managed by the database itself and cannot be changed by us, thus we needed to disable managing the database on our own and adapt to the existing tablespaces and limitations. The last limitation we had to bypass was the limited support for XML schema storage. To fix this we utilized the switches during the database setup to completely alter the executed code and changed the affected parts to use only features supported by the Oracle Autonomous Cloud. Basically this was changing the storage option for the XMLType columns from Object Relational or CLOB (which we were using on traditional databases) to “Binary XML”.
In the end we managed to get both tools to run on the Oracle Autonomous Database. Adding the support to our newly developed Horus 3.0 did result in less issues and for any application which does not use unsupported features, running them on an Oracle Autonomous Database should be a piece of cake. If your tool does use unsupported features, you may have to change some code and bypass the limitations with some creative thinking to get it to run. But in the end the autonomous cloud is a flexible & easy to use database and especially handy if you need a database quickly but don’t want to setup or manage one yourself. If you want to know more about the limitations you can read the documentation
(https://docs.oracle.com/en/cloud/paas/atp-cloud/atpdg/experienced-database-users.html#GUID-B58C3262-EB61-470D-9060-730763FBCE32) Author: Johannes Michler