@Bret Grinslade - Oracle Analytics-Oracle Bret, good to hear, that "you are looking at options". But what is a sad story is a fact, that this Idea has been created in June 2020 (so it is almost 3 years old) and so far there does not seem to be any solution implemented (not even planned in roadmap). I have summarized all paint points around deployment/Dev2Prod DV product gaps in discussion within this Idea:

https://community.oracle.com/products/oracleanalytics/discussion/comment/51083#Comment_51083

So I am more than curious to hear about some good news in this area.

Thanks

Michal

@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):

https://community.oracle.com/products/oracleanalytics/discussion/10337/oas-inclusion-of-file-based-data-into-snapshot

https://community.oracle.com/products/oracleanalytics/discussion/19201/dv-owner-of-workbook-and-dataset-should-be-preserved-while-importing-in-new-oac-instance

https://community.oracle.com/products/oracleanalytics/discussion/19200/allow-api-access-to-dataset-edit-definition#

https://community.oracle.com/products/oracleanalytics/discussion/18832/api-for-programmatically-manipulating-dv-objects-data-visualization-and-automate-dv-tasks-in-oas

https://community.oracle.com/products/oracleanalytics/discussion/19166/dv-connection-selection-option-to-be-available-while-importing-workbook-data-flow

https://community.oracle.com/products/oracleanalytics/discussion/10008/ability-to-easily-change-connection-assigned-to-external-database-data-set-in-dv

https://community.oracle.com/products/oracleanalytics/discussion/10478/preserve-namespace-owner-of-ds-connection-during-dva-package-deployment

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