Skip to main content
To homepage To homepage
Solved

ODX Dev/Prod refresh

S
Explorer

Hi,

I have the following setup in my Dev/Prod environments:

  • ODX Shared, all on my live environment
  • DSA / MDW separate for each environment

A daily refresh starts with ODX and on success moves to DSA. So far so good.

On the ODX step, there's a Usage condition for Environment (project variable) = ‘Prod’.
I added this because I don't want to start 2 refreshes of the same ODX from both Prod&Dev.

However, the Dev environment goes straight into the DSA refresh because the ODX ‘starts’ and finishes instantly. Meaning the DSA only gets a few thousand rows from the still-refreshing ODX (largest table has 2000 rows where I'd expect 2million+).

  • Is my assumption correct in using the Usage condition?
  • How can I use the same Execution packages for Dev/Prod while still using the same ODX ?

Thanks for any help!

Best answer by Thomas Lind

​Hi Stefan

That is what I wanted to be sure off.
It is not a good idea to share the same database for two environments. You should have a specific DEV and PROD BU Staging database. If you share a database between two environments you can see many issues with settings not being the same.

We have had a few tickets regarding this and you will see that every time you deploy a table in DEV or Prod that it will affect the other.

 

And to answer your other question. Yes, you need to have specific execution packages with usage conditions on them.

I usually call mine what they are, so I will have a Prod, Test and so. In this I do not have a DEV as I usually only run that whenever I have made a change. Prod and Test are set to run at different times, so they will not run at the same time.

View original
Did this topic help you find an answer to your question?

4 replies

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Thomas Lind
  • Community Manager
  • 1017 replies
  • January 30, 2023

Hi Stefan

Here is how I would do it when limiting the amount of rows in DEV compared to Prod.

With the ODX you are not allowed to do Custom Data Selection rules, so I have a fixed date range.
I would generally make sure that it is the same data every time so testing of my changes will give the best results.

One question I have.

The ODX is not a Business Unit, right?

S
Explorer
  • StefanS
  • Author
  • Explorer
  • 5 replies
  • January 30, 2023

Hi Thomas, sorry but I think I was not clear enough.

This is not a question on how to limit the amount of rows in DSA. I have that in place already.

 

Yes the ODX is a business unit. It only exists on server A (Prod).

The question is, should I use a Usage condition on the Execution package to refresh the ODX?

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Thomas Lind
  • Community Manager
  • 1017 replies
  • Answer
  • January 30, 2023

​Hi Stefan

That is what I wanted to be sure off.
It is not a good idea to share the same database for two environments. You should have a specific DEV and PROD BU Staging database. If you share a database between two environments you can see many issues with settings not being the same.

We have had a few tickets regarding this and you will see that every time you deploy a table in DEV or Prod that it will affect the other.

 

And to answer your other question. Yes, you need to have specific execution packages with usage conditions on them.

I usually call mine what they are, so I will have a Prod, Test and so. In this I do not have a DEV as I usually only run that whenever I have made a change. Prod and Test are set to run at different times, so they will not run at the same time.

Christian Hauggaard
Trine Stuhr
2 people like this
  • Christian Hauggaard
    Christian Hauggaard
  • Trine Stuhr
    Trine Stuhr
S
Explorer
  • StefanS
  • Author
  • Explorer
  • 5 replies
  • January 30, 2023

Hi Thomas,

Alright thanks! This was setup with a consultant who didn't see any issues, but unfortunately I'm running into some now, so I'll go by your advice and split the ODX for both environments, adding in a Data selection rule to reduce the amount of data.

Thank you!

Reply


Most helpful members this week

Terms and ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings