Categories
- All Categories
- 75 Oracle Analytics News
- 7 Oracle Analytics Videos
- 14K Oracle Analytics Forums
- 5.2K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 40 Oracle Analytics Trainings
- 59 Oracle Analytics Data Visualizations
- 2 Oracle Analytics Data Visualizations Challenge
- 3 Oracle Analytics Career
- 4 Oracle Analytics Industry
- Find Partners
- For Partners
OAC import bringing over connection even if it's not part of export
Our OAC NPE and OAC PROD both have the same connection names setup by the same owner and username. Even when I exclude the options – Connection and Data on the export of a workbook from NPE, OAC creates a clone of the NPE connection in production on each import. This is a problem because we have to go in and delete the additional connection every single time we import a new workbook.
The connection names are identical between the two environments. What's different are the connection strings - one points to our OCI NPE ADW and the other points to our OCI PROD ADW. Both connections use TLS Encryption Type.
Ideally, we’d like that OAC does not bring over NPE connections to PROD or at least warn the user that it’ll create a clone of the NPE connection and provide an option to not do so. However, there’s no such warning/option and once the import is successful, I need to delete the additional NPE connection.
Speaking to the SR support person tied to SR 3-35013349171, they indicated that we need to submit an Enhancement Request.
Comments
-
@Gabby Rubin-Oracle @Bret Grinslade - Oracle Analytics-Oracle @Alan Lee - Oracle-Oracle One of quite overlooked area in term of improvements (whatever with great importance if you take care of governance and good practices) are tools/support for incremental DEV2PROD deployment of DV objects between OAC/OAS environments (mainly connections and data sets, workbooks are part of BI catalog and thus can be transferred by old good and mature tools for BI catalog). But for DV this is simply disaster (I cannot find other more polite words for it), we are fighting with this process since we "jumped" into usage of Data Visualization in our institution.
I have created couple of Ideas on this topic (or up voted for Ideas, which resonates similar needs ) so far without much attention by Product Mgmt/Developemt (or without clear plan, that it will be implemented in some near future):
What are the possibilities now :
1) Snapshots
Not usable for incremental deployments (deploy from DEV to PROD just data sets which has been changed on DEV environment) and beside this (at least this is valid for OAS) files (Excel/CSV) for file-based data sets are not part of snapshots
2) DVA package export/import
So far the only option how to incrementally transfer definitions of data sets/connections from one environment to other (DEV2PROD) , but very poor (and very clumsy) functionality - I will list all "issues" we are strongly fighting with:
a)
DVA package always overwrites (or create new one) connection objects bounded to data sets included in DVA package.
This is unwanted behavior in majority of imports, since we already have connection object in place on target environment for data set (we want to transfer just changes in data set definition) and connection object (with same Object ID as on source environment is usually pointing to different database - on source DEV OAS environment connection is pointing to DEV database, while on target PROD OAS environment connection is pointing to PROD database).
There should be ability to transfer just definition of data sets between environments (without a need to import/replace connection definition from source environment - if connection already exists on target environment)
b)
DVA package is modifying (while importing to target environment) so called namespace (User Id of creator of object) which is part of unique identifier of object (data set, connection....) to User ID of user, who is executing import (without taking into consideration, what namespace was on source environment).
Again this is unwanted "feature" - I will explain why:
In our setup, person, doing import of DVA package is Administrator of OAS environment (and this is different user than the user who has created DV objects on source environment and who is requesting deployment of "his" objects to PROD).
And this leads to change of Namespace (part of Object unique identifier used for referencing DV object - for example referencing data set in DV workbook, analysis definitions).
DVA import "handles" this situation for DV workbooks which are part of the same DVA package as corresponding data sets (it changes the reference to data set to new namespace).
But our authors are using often "mixed" setup - they create data sets in DV (because it is convenient for them, no need to model simplier structures in RPD) and then they use Answers/Dashboards (on top of DS) - since Answers/Dashboards are more mature for complex reporting then DV (so far).
And when Admin deploys data sets on PROD, unique identifier of data sets changes (since namespace "converts" to Admin username) and thus their reports in Answers on PROD (deployed on PROD via Archive/Unarchive operations in BI catalog) are broken, since they refer data set with original namespace from DEV environment.
Pretty tricky situation....
So we need a option during DVA import of DS to preserve original namespace (part of DS unique identifier) from source environment (not to be overwritten by importer's namespace on target environment).
I would like to ask all involved people from Product Mgmt/Development to put more effort in this area - to achieve the same level of flexibility for DEV2PROD processes as which are in place for DEV2PROD processes for classics (BI catalog objects along with RPD deployment from DEV2PROD). This area really deserves more effort and attention.
Thanks
Michal
1 -
Thanks Michal. Very useful information.
0 -
It's very serious issue while migration workbooks from Test environment to Production env, database connections are overwriting even though we excluded connections!
1 -
Hi team,
We are facing the same issue in Oracle Analytics Server in both 2022 and 2024 versions. 3-37515860051 SR was created for the same.
This issue is extremely critical as the connections are getting moved when not intended. This is impacting all DV migrations and causing immense confusion and inconvenience to users and developers apart from migrators.
0