@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
Categories
- All Categories
- 118 Oracle Analytics News
- 21 Oracle Analytics Videos
- 14.4K Oracle Analytics Forums
- 5.5K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 48 Oracle Analytics Trainings
- 6 Oracle Analytics Data Visualizations Challenge
- 4 Oracle Analytics Career
- 7 Oracle Analytics Industry
- Find Partners
- For Partners
Ability to easily change connection assigned to external (database) data set in DV
Organization Name
CESKA NARODNI BANKA
Description
It would be really great, if there would be an option (similar to easily switch between data sources in RPD by modifying connection info in Connection Pool) for external (database) data set to change Connection assigned to this data set (changing the property "Connection" for data set). This will give good flexibility to "redirect" data set to different DB (for example easily switching from DEV Db to TEST Db). From deployment/DevOps point of view, this is "must-have" feature.
Use Case and Business Need
Flexible redirection of external data set to different location (Db). Must have feature from deployment/DevOps point of view.
Original Idea Number: c3158a1c2e
Comments
-
I agree that this is a must have feature. The only way around this is to rebuild the dataset from scratch against the different databases. We need to be able to develop in DEV against a non-prod database then promote that dataset to production and swap out the connection to use the prod database. Otherwise, Oracle is promoting the process of developing in production which is clearly not ideal.
0 -
Our organization is in need of this as well. This will become a change management nightmare if this feature is not enabled.
0 -
Is anybody from development looking at this Idea ? It hase been created almost 2 yers ago and it it still in Submitted status. Thanks
0 -
Oracle is reviewing options to more gracefully migrate datasets with associated connections between environments, e.g avoid overwriting connection details in the target environment.
1 -
@Alan Lee - Oracle-Oracle .Hi Alan, looking forward for better way to migrate DV objects between environments. Current status via DVA package is very very limiting. What I would suggest as well for improvement (except being able to change/assign different Connection on target environment) is possibility (when chosen) to “preserve” namespace (thus ID of user who created object on source environment) and also owner of object from source environment when migrating DV object to target environment. Current DVA package functionality assign to both this ID of user, who performed import of DVA package on target environment - which is in our organization administrator of environment (to which DVA package had been passed from authors from source environment). And thus we are completely loosing on target environment “the trace” who is the real creator/owner of DV object (from source environment). So pls, considet this option within your revision (as you mentioned). Thanks
1 -
My team and I have recently made a rule that we CANNOT use the import DVA feature AT ALL because it breaks way too many things in the process, such as permissions. Anxiously looking forward to improvement here. Current state, we have resorted to rebuilding everything from scratch because that is the only way we know it will work without breaking something else in the process.
2 -
The ability to switch the connection of a dataset would be of huge value to our organization.
Use cases:
- swapping between environments in a migration path
- swapping between databases
- swapping ownership of datasets/connections allowing creation of a dataset and transferring to someone else that can truly "own" and edit the definition of the dataset. DV won't allow the definition to be edited unless both the dataset and connection are owned.
2 -
The ability to transfer ownership of datasets and connections was a nice first step, but does not solve the problem at large. We see use cases where individuals have changed job functions or orgs and need to transfer datasets to a new responsible person, but retain their connection. We also see use cases where creation of the dataset should occur against DEV or QA DW and then change to PRD. Use cases also exist for people leaving the company and transferring their datasets to someone else, but now that person has to maintain multiple connections generally to the same DBs, which is cumbersome and inefficient. All of these use cases would be solved by the ability to change the connection a dataset uses as the owner of the dataset - without having access to the existing connection the dataset is using.
3 -
@Sean McArthur for the comment on edit definition -- you need read access to a connnection (that is the ability to use it) to edit definition. You don't need the ability to modify a connection to use edit definition. If you are seeing something else, let us know.
For the overall topic - we looking at options.
0 -
@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:
So I am more than curious to hear about some good news in this area.
Thanks
Michal
3