Oracle Communities

Oracle Analytics and AI

Child Item

OAS 2023: Connection should not get overwrite while importing the DVA

While promoting/migrating any DVA file from one instance to another, the connection got write in the target instance.

Example: I am using a Oracle Application connect with classic home as source, while promoting any DVA file overwrite this connection and manually i need to correct this.

If we get any option to include/exclude the connection details, just like the option "Include Credentials" then it will be a good solution to this problem and a very useful feature added to the application.

Find more posts tagged with

Data Modelling and Datasets

Needs Votes

Connector

Oracle Analytics Server

Status: Needs Votes

Comments

Jean-Pierre Hoedenaeken

Hello,

I had the same issue when promoting a bunch of workbooks from Dev to Prod, needing to update the connection in Prod.

I think the same principle could apply to the Dataset used in the workbook, so that the import could only take into account the workbook without the dataset and connection.

Jean-Pierre

User_YSIXF

Promoting projects will always break the connection so has to be done out of hours when no users are active. It would also be useful to have an option to preserve connection permissions so not accidentally removed on promotion

Jean-Pierre Hoedenaeken

Hello,

Another painpoint that we have just encountered … any workbook having a dataset based ona "System" connection count not be imported (error message).

So we will need to define two connections to the same datasource … one for the subject area in the semantic model (RPD) and another one for the datasets (to be able to import any workbook that is based on the same datasource) … a little bit clumsy !

If you also refer to the painpoints already described by Michal for some … years now … it's clear that to DEV2PROD process need a real solution.

Regards.

Jean-Pierre

Michal Zima

@Jean-Pierre Hoedenaeken Jean-Pierre, as I learned recently (since we have encountered exactly same behavior with data sets, created out of Connection, having System flag) during a call with @Bret Grinslade - Oracle Analytics-Oracle , system connections are exclusively intended for usage in Semantic Modeler (Connection Pool objects) and should not be used for data sets. At least this is current status (which may possibly change in a future - more question to Bret….). Even if this is the case, in the DV UI it is possible to use this connection to create a dataset - which seems like unwanted behavior 😥

Kartik Mali-Oracle

Team, any plan for the feature to not touch the connection while promoting DVAs in the upcoming release for OAS ?

Chad Williams

I know this an old item, but what if you have a semantic model in Dev and you want to promote to a higher environment? It seems like then your connection information would potentially break as well?

Haven't tried the semantic modeler yet to see if this is the case.

But the overwriting the connection when importing workbooks/dataflows continues to be a big red flag for us.

Chad Williams

What's really odd is that when you export a workbook, you have the option to "not include Connection information" but then you do the import and it's clearly being included regardless of what you pick on that screen.

@Bret Grinslade - Oracle Analytics-Oracle Any updates or comments on this behavior?

Chad Williams

I think the only way around this is to manage multiple connections on each server. So for instance, if I have a dev database and a prod database, I would need the dev workbook to already point to production database connection before I migrated the workbook. However, if I began work on dev database, I'm not sure that you can just switch from one connection to another in your dataset. I realize this kind of operation is probably what Oracle envisioned, but unfortunately, this is how many IT Operations run their development lifecycles and it's hard to let go of that kind of process when you have very important business operations that can't be disrupted in your Production environment.

Chad Williams

Also, if we did have productions for Prod/Dev versions of the same environment, that would require opening up firewalls that we currently do not allow to happen in our systems. For us, pointing a Dev environment to a prod a Production environment is a very big no-no.