Oracle Analytics Cloud and Server Idea Lab

Products Banner

Preserve namespace/owner of data sets/connections during DVA package deployment/import


Organization Name (Required - If you are an Oracle Partner, please provide the organization you are logging the idea on behalf of):

CESKA NARODNI BANKA (Czech National Bank)

Description (Required):

We have following requirement, dealing with ownership of data sets, connections objects, which are "transfered" on target OAS environment via DVA package.

But when you apply DVA package on target OAS environment, "artefacts", contained in DVA packages (meaning data sets and connections) does not keep namespace (which is part of unique identifier of DV object along with its name - '<<Namespace>>'.'<<Object Name>>') and owner from OAS environment, where DVA package has been created, but instead those DV objects are created in target environment with namespace/owner of user who is performing import of DVA packages.

This is unwanted situation for us, since we want to keep on target OAS environment (usually production OAS environment) "ownership" of DV objects from "source" OAS environment (dev/test), despite the fact, that import has been made by someone else (administrator in charge of performing deployment from DEV to PROD - ordinary users, who has privilege to create DV objects on Dev/Test environment dont have privilege to perform DVA package import on production OAS environment - it is sole responsibility of administrator).

This is really must requirement for us - this should be either the option of DVA import (in import dialog - keeping namespace/ownership of DV objects) or (less preferred option, but still acceptable) to have the ability to change (by admin person) namespace/ownership of DV objects (data sets, connections or data flows) afterwards (as operation in UI or via API call - which is still missing in product as well).

Use Case and Business Need (Required):

Maintain data stewardship and governance within OAS for DV objects with same level of "granularity" and flexibility as for "classical" OBIEE objects.

Enhancement Request / Service Request:

1 votes

Submitted · Last Updated