Do you transport queries or create them in prod?

[Former Member]

We are looking at transporting all queries all the time except special ad-hoc reports. I was wondering how many people out there follow this model as opposed to just creating queries directly in prod. Are there pros and cons to either way? What is the recommended best practice?

[former_member181964]

Hi,

Don't create any object in Production, you must create in Dev and then Transport the Objects.

Thanks

Reddy

[Former Member]

Normally creating queries directly in Production is not recommended way.

There are so many dis-advantages in that.

1. Testing and quality are not assurance if it is directly in Production.

2. We have to do so many restrictions for the developers and end users in production.

3. usually Production system should be non-modifiaible system. if modifiable, we cannot maintain the queries and other reports as standard one.

Hope this would help you .

[Former Member]

Hi,

Pros and Cons of transporting Queries across systems

PRO:

1. Consistency in Queries can be maintained

2. Not every user will be allowed to create queries, so less junk

3. Duplicity is avoided - same thing not available in 100 versions

CON:

1. Transporting Queries is a tedious job, you can miss out elements which can result in bombing of your queries

2. It has a certain time lag, which can annoy users

3. tech savvy users cannot apply their skills to create their own reports\views and have to depend on developers for the same. (but since very few user understand the fundamentals of queries, its ok)

But what ever approach you take, don't mix both of them., that can be pretty disastrous 😛

Godhuli

[Former Member]

Hi Jaime,

My company's policy is directly create queries/workbook/web templates in PRD system. The advantage is users can change their report in minutes without transportation, and developers feel easy to use query to explore data. We only assign create/modify/delete query authorizations to key users so the frequently used queries will not be deleted or overwritten.

I understand if we transport queries from Dev is more consistent. But we are leveraging between users convenience and D/Q/P system consistency. I don't think there would be very big problem if we directly create queries in PRD. Queries would not affect modeling and data, and will not cost much space.

The disadvantage is we have lots of queries in PRD. Sometimes after copying query and testing data, developers forget to delete the test queries. But it's not a big problem.

By the way, we refresh our Q system from P on a regular basis so it's also possible to use/test P queries in Q system.

In short, I prefer creating queries in P system directly.

Regards,

Frank

Edit:

Talking about best practice, my company has been using BW for 9 years and nominated as 'Best Practice in BI' several times.. And I/users really like the query policy.

Edited by: Frank Lee on Jul 16, 2009 11:41 AM

[dennis_scoville4]

I was wondering how many people out there follow this model as opposed to just creating queries directly in prod.

For standard reports, you're going to find that most companies use the create/maintain in development and promote via transport to landscape more than allowing unlimited create/maintain in production.

Are there pros and cons to either way?

There are pro and cons for both sides of the coin. For instance, if you use the transport means for production reports no one will be allowed to change the report whenever they feel like it (big pro in my view), but it limits/eliminates the ability of the end users to create customized, personal versions of those reports (con). With a wide open production environment, the end users will have the ability to create customized reports that suit their individual needs (pro), but it also gives the end users the ability to maintain standard reports to suit their needs, but may not and probably will not suit the needs of others that use that same report in which case you'll have hundreds of versions of each report in your system (huge con from a maintenance and break/fix analysis perspective).

What is the recommended best practice?

The recommended approach is the transport to production methodology. It allows for standard reports to remain standard and mitigates risks that might be introduced because and end user does not understand the underlying data or just does not care.

In the future, with the SAP Business Objects tools, you'll be able to create standard reports in Crystal Reports, Web Intelligence (rich and thin client - Web Intelligence rich client used to be called Desk Intelligence), Xcelsius, et. al. and still give the ability to the end users to save versions of their own reports, in their own personal folder or team folder, so that you have basically the best of both worlds.