Solved

ODX Dev/Prod refresh

  • 30 January 2023
  • 4 replies
  • 71 views

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!

icon

Best answer by Thomas Lind 30 January 2023, 13:18

View original

4 replies

Userlevel 6
Badge +5

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?

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?

Userlevel 6
Badge +5

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.

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