Skip to Content
avatar image
Former Member

Failed Data Reporting - Alias Names across Environments

We have Info Steward on 3 environments : Dev, Integ, Prod.

There are also have 3 Failed Data Repositories, 1 for each of the above.

Now we want to do some custom reporting against the FDR.

Normal process would dictate to develop these views on the Dev FDR, then migrate to Integ and through to Prod.

However, what I am seeing  is this.

I have table ECC.MARA in my IS project, and on Dev, the failed data gets dumped into FDR with alias "MARA_123"

But if I now look in the same project on Iteg, the alias for the same data tables is 'MARA_345'.

Again, looking in prod, the alias if different again 'MARA_567'.

Obviously this make it impossible to create a view against the alias in Dev, and simply migrate it through to the other environments.

Yes, of course I can work around this, but the effort, in my opinion, is way way above what should otherwise be a simple process.

(I'm currently looking at scripts that accept FQ table attributes and then look up alias to dynamically build views/procedures from template)

So now I am curious ... do other people see this same phenomenon ?

Is there a mechanism to 'fix' aliases across environments ?

How do you work with it/around it/fix it ?

Appreciate any enlightenment on strategies for custom reporting in this context !

Many Thanks

Simon.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Oct 18, 2015 at 10:54 PM

    Simon,

    I have seen the same behaviour.  By design, the failed rule tables appear to be generated with a unique Id to avoid potential conflicts with existing objects.  This is painful when doing what you suggest although I have not yet formally received a requirement for custom DQ rule failure reporting that would necessitate a Universe on the failed rules repository/ repositories.

    I have not tried building my own tables of the same name in each environment and this seems risky and would shy away from this approach.  So you may need to look at a DB view solution where a DB stored proc/ package auto generates the view based on names in the FD and FR tables and then auto grants this to the Universe connection user.

    I previously raised idea D19898 as the failed rules repo does not update when you add / change an existing column, however I do not think I raised another for this issue.

    Be good to know what solution you end up with.

    regards

    Adrian

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Adrian Storen

      Ah, ok .. sorry Adrian I misunderstood your intent 😉

      In that case - thanks for the suggestion!

      So I guess that brings me to the latter part of my question(s)

      "How do you work with it/around it/fix it ?"

      My company has quite strict policies, whereby the Integ & Production systems are heavily locked down.

      For example, we can import projects, execute tasks, view scorecards .... but very little else.

      It's an absolute no-no to change any part of the 'design' of a project by altering views/rules/bindings etc.

      Sitting in my isolated box... I guess I am curious as to how other organisations set up their environments.

      Maybe especially as far as the FDR goes.

      The FDR has very minimal effect on the actual application itself.; but still get's caught up in this process.

      Would be interested to hear how anyone else has their Dev-Itg-Prod environments set up for Info Steward & the FDR.... ?

      Many Thanks