November 21-24, 2023 | DOAG 2023 Conference + Exhibition

November 21-24, 2023 | DOAG 2023 Conference + Exhibition


The DOAG 2023 Conference + Exhibition takes place from November 21 to 24 at the Nuremberg Convention Center (NCC) and will once again present a wide-ranging conference program on the latest trends in the Oracle environment. Around 400 lectures provide new impulses and pure knowledge - top-class keynotes, valuable tips & tricks, demos, Best Practices and modern networking elements optimally round off the conference highlight of the German-speaking Oracle Community.


November 21-24, 2023
Nuremberg Convention Center (NCC)

The four-day user conference kicks off on Tuesday with the theme day to dive deep into just one topic. On Wednesday and Thursday you can look forward to two classic conference days with sessions in the four streams Database & Infrastructure, Development & Middleware, Strategy & Soft Skills and Data Analytics & AI.

PROMATIS will be at the start with the following contributions:

  • OCI für Anfänger Teil 1 – Grundlagen (Thementag der DOAG Infrastructure & Middleware Community)
    Tuesday, November 21, 2023 | 09:00 - 09:45 | Room: Neu-Delhi
  • Oracle Database Service for Azure (Teil 2 Thementag)
    Tuesday, November 21, 2023 | 15:00 – 15:45 | Room: Neu-Delhi
  • PROMATIS goes digital – mit Oracle APEX im Gepäck
    Thursday, November 23, 2023 | 11:00 - 11:45 | Room: Istanbul
  • Von Druckerpresse zur Cloud – Hyperion Essbase Ablösung bei Saarbrücker Zeitung
    Thursday, November 23, 2023 | 09:00 - 09:45 | Room: Helsinki

More information to DOAG 2023 Conference + Exhibition you can find here.

Automating DNS Management for E-Business Suite on OCI

Automating DNS Management for E-Business Suite on OCI

Johannes Michler PROMATIS Horus Oracle

Executive Vice President – Head of Platforms & Development

When automating operations of Oracle E-Business Suite using OCI and especially Oracle Cloud Manager – which is now even easier and faster with the latest release 22.1, as described in my previous blog post –, it is often necessary to modify DNS entries. For example, if you replace your testing instance with a new P2T copy you usually want to retain your database hostname (e.g., so that other systems can still reach the new P2T copy. Let’s see how we can achieve this:

DNS Private View

First of all, DNS Private Views, as I described over there, are very helpful. Using them, it is possible to define DNS entries within OCI. It is then possible to:

  • modify those entries using the OCI APIs, e.g. using the OCI CLI,
  • setup your regular DNS server to resolve some domains using the OCI DNS Server.

Modifying OCI DNS entries by API

Modifying DNS entries using the OCI console is quite straightforward:

I prefer to have CNAME (=Aliases) over a "static" (within DNS) name, such as, to the actual current instance name that is maintained/created automatically through Cloud Manager (e.g.

So how can we change this mapping (column RDATA) with the API? Just use a command as follows:

oci dns record domain update --domain --zone-name-or-id --items
"[{\"domain\":\"\",\"rdata\":\"${HOST_DB}\",\"rtype\":\"CNAME\",\"ttl\":300}]" --force

This command can be included in the cloning script and then updates the static database hostname to the newly created hostname (${HOST_DB}).

Delegating Windows Active Directory / DNS

The above Private Views can be resolved anywhere within your OCI Virtual Cloud Network. Often, however, there is an additional DNS server in place managing the "Non-OCI" company-internal DNS entries. Without any special configuration, this DNS server is not able to resolve * hostnames defined within the Virtual Cloud Network. To overcome this issues, first you have to create a (DNS) Listening Endpoint within the OCI network:


With that, you then have to create a new primary forward-lookup zone "":

Within that new zone, create a new "delegation" for (in this case) both and

At last, test the name resolution with your standard DNS server:


With DNS Private Views and a Listening Endpoint, you can configure your company DNS server to resolve OCI hostnames using the DNS functionalities of the OCI Virtual Cloud Network. Since those can be easily modified with OCI APIs, it is possible to fully automate changes to the DNS of E-Business Suite-related hostnames.

Automating DNS Management for E-Business Suite on OCI

Initializing E-Business Suite Context for a Read-Only-User

Johannes Michler PROMATIS Horus Oracle

Executive Vice President – Head of Platforms & Development

Recently I described how a read-only user can be created for Oracle E-Business Suite.

This works great, however, when trying to access the pre-built views of E-Business Suite, many of them do not show any data:

Let’s see how we can remedy this.

Initializing Context

When connected with the APPS user, this can be solved by running:
exec mo_global.init(‘M’);
This internally populates session-specific information on which operating units are accessible in a “M”ulti-Org.

Then, the above Statement returns all invoices as expected:

However, this query obviously can not run with the XXREAD user as created in the previous blog post, since we did not grant execute privileges to mo_global.

More grants

Let’s fix this:

Unfortunately, this is not enough since the MO_GLOBAL package calls more procedures and is defined with AUTHID CURRENT_USER (see

There are basically two options to solve this problem:

  • You can create a “proxy package” with “AUTHID DEFINER” in the APPS schema, grant execute privs on that package to XXREAD and then call mo_global.ini from there. This approach can be used for other functions as well.
  • You need to grant the following privileges to XXREAD:

Afterwards, the mo_global.init procedure can also be run as XXREAD.

Extending the Logon-Trigger

If you prefer to not run the mo_global.init function after each session-creation, you can extend the logon-trigger as follows:
create or replace TRIGGER xxread.xxread_query_logon_trg


By extending the XXREAD user created according to my previous blog post as described above, it is easily possible to access VPD-protected views and tables. It is thus even easier to replace (more dangerous) access as the APPS user with a less privileged user; in many scenarios where 3rd party systems are only reading the APPS user can be replaced with this XXREAD user without further modifications in the 3rd party systems.

Automating DNS Management for E-Business Suite on OCI

Creating a Read-Only APPS User

Johannes Michler PROMATIS Horus Oracle

Executive Vice President – Head of Platforms & Development

In Oracle E-Business Suite environments it is often necessary to query data. Typically, all data can be accessed through the APPS user. However, that user is highly privileged and, when in use, can easily “break things”. This is obviously a big compliance issue. Having a dedicated read-only user is thus a much better approach. Let’s see how such a “XXREAD”-user can be created.


In order for the APPS user to be able to grant access to objects the user doesn’t actually own (e.g. tables in XX schemes), the APPS user needs to have privileges on those objects “including grant option”. This can be achieved with a script such as the following one, which should be run whenever new custom objects are created (as the XX scheme user):

set echo off;
set verify off;
FOR r IN (
‘grant all on ‘
|| object_name
|| ‘ to apps with grant option’ statement_to_run
user_objects dbos
(object_type IN ( ‘SEQUENCE’, ‘TABLE’ )
or object_type=’VIEW’ and object_name like ‘%#’)
user_tab_privs privs
privs.table_name = dbos.object_name
AND privs.type = dbos.object_type
AND privs.grantable = ‘YES’
AND privs.owner = user
order by object_type asc
EXECUTE IMMEDIATE r.statement_to_run;


Creating a user and granting privileges

First, create a XXREAD user and produce a script to grant privs:

sqlplus -s system/
create user XXREAD identified by MyAppsReadPwd;
grant create session to XXREAD;
grant alter session to XXREAD;
SET echo off
SET feedback off
SET term off
SET pagesize 0
SET linesize 200
SET newpage 0
SET space 0

spool grant_privs.sql
select ‘exec AD_ZD.GRANT_PRIVS(”READ”,”’||VIEW_NAME || ”’, ”XXREAD”);’ from all_views where OWNER =’APPS’ and view_NAME not like ‘%/%’;
select ‘exec AD_ZD.GRANT_PRIVS(”READ”,”’||table_NAME || ”’, ”XXREAD”);’ from all_tables where OWNER =’APPS’ and table_NAME not like ‘%/%’;
select ‘exec AD_ZD.GRANT_PRIVS(”READ”,”’||SYNONYM_NAME || ”’, ”XXREAD”);’ from all_synonyms syns, all_objects objs where
syns.OWNER =’APPS’ and syns.SYNONYM_NAME not like ‘%/%’
and syns.table_owner=objs.owner and syns.table_name=objs.object_name
and objs.object_type in (‘TABLE’,’VIEW’);
spool off

Then, run the spooled script and register the XXREAD user:

sqlplus apps/ @grant_privs.sql
sqlplus apps/ @$AD_TOP/patch/115/sql/ADZDREG.sql apps XXREADsqlplus apps/ @/u01/install/APPS/fs1/EBSapps/appl/ad/12.0.0/sql/adutlrcmp.sql


First tests and logon trigger

After having initially created the user, sign in as XXREAD and do some initial testing by accessing apps.* tables.
Unfortunately, so far, it is still necessary to do all selects with an “apps.” prefix. This can be solved with two approaches:

  • Create a synonym in XXREAD for each APPS object.
  • Create a logon trigger that changes the CURRENT_SCHEMA.

Such a trigger can look as follows:

create or replace TRIGGER xxread.xxread_query_logon_trg



With the above procedure, it is possible to create a XXREAD user that can access (in a reading fashion) everything from the APPS user. This is a lot more secure than really using the APPS user/password since in that way, no one can accidentally run a “truncate” on some table. Also keep in mind, though, that such a XXREAD user is not the perfect solution and allows a lot of (reading) access, which still might be a GDPR issue; obviously, you also want to limit access to this XXREAD user as restrictive as possible.